1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2025-02-07 20:38:32 +01:00
Commit graph

5 commits

Author SHA1 Message Date
epriestley
f7d5904e4b Expose modern *.search Conduit endpoints in Almanac
Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff.

Test Plan:
  - Made a bunch of calls to the new endpoints with various constraints/attachments.
  - Created and edited services, devices, interfaces, bindings, and properties on everything.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10246, T10411

Differential Revision: https://secure.phabricator.com/D15329
2016-02-23 08:20:57 -08:00
epriestley
ab86523ac4 Allow Almanac properties to be deleted, use EditEngine instead of CustomField
Summary:
Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings.

The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff).

Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks.

This also makes the internal storage for properties JSON instead of raw text.

Test Plan:
  - Created, edited and deleted properties on services, devices and bindings.
  - Edited and reset builtin properties on repository services.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10410

Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 11:28:26 -08:00
epriestley
db50d0fb11 Rough-in Almanac namespaces
Summary:
Ref T6741. Ref T10246.

Root problem: to provide Drydock in the cluster, we need to expose Almanac, and doing so would let users accidentally or intentionally create a bunch of `repo006.phacility.net` devices/services which could conflict with the real ones we manage.

There's currently no way to say "you can't create anything named `*.blah.net`". This adds "namespaces", which let you do that (well, not yet, but they will after the next diff).

After the next diff, if you try to create `repo003.phacility.net`, but the namespace `phacility.net` already exists and you don't have permission to edit it, you'll be asked to choose a different name.

Also various modernizations and some new docs.

Test Plan:
  - Created cool namespaces like `this.computer`.
  - Almanac namespaces don't actually enforce policies yet.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6741, T10246

Differential Revision: https://secure.phabricator.com/D15324
2016-02-22 04:58:35 -08:00
epriestley
3fa519da74 Allow Almanac service types to define default properties
Summary:
Ref T5833. This allows Almanac ServiceTypes to define default properties for a service, which show up in the UI and are more easily editable.

Overall, this makes it much easier to make structured/usable/consistent service records: you can check a checkbox that says "prevent new allocations" instead of needing to know the meaning of a key.

Test Plan: {F251593}

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10996
2014-12-17 11:10:50 -08:00
epriestley
2f1b5ae010 Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:

  - Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
  - Make properties more generic so Services, Bindings and Devices can all have them.

The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.

I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.

This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.

Test Plan: {F229172}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10777
2014-11-05 15:27:16 -08:00