1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-30 18:52:42 +01:00
Commit graph

9 commits

Author SHA1 Message Date
epriestley
af6ffd8c7b Allow Almanac devices to have SSH keys
Summary: Ref T5833. Expose a key management interface for Almanac devices.

Test Plan: {F231962}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10825
2014-11-11 08:20:08 -08:00
epriestley
2b495f1f03 Implement PhabricatorProjectInterface on Almanac Services and Devices
Summary:
Ref T5833. Allow services and devices to be tagged with projects.

(These fluff apply implementations are a good example of the issue discussed in T6403.)

Test Plan: {F229569}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10782
2014-11-05 15:30:00 -08:00
epriestley
fcad9435ea Allow Almanac Devices and Bindings to have properties
Summary:
Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings.

  - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc.
  - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc.

Test Plan: Added properties to Devices and Bindings.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10781
2014-11-05 15:28:36 -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
epriestley
d5b70e2c1c Add AlmanacBinding, to bind a service to an interface
Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 13:39:36 -07:00
epriestley
3e516e40f3 Build AlmanacInterface
Summary: Ref T5833. An interface is an IP (maybe v4, maybe v6) and port on a specified network (public internet, VPN, NAT block, etc).

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10718
2014-10-17 05:04:24 -07:00
epriestley
3e704f6c78 Build AlmanacNetwork
Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 05:04:02 -07:00
epriestley
247cb94d5a Build AlmanacDevice UI
Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 05:02:14 -07:00
epriestley
796921021b Build AlmanacService
Summary: Ref T5833. See that task for functional goals and some discussion of design.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 05:01:57 -07:00