Add ConnectionType enum (STANDARD, TEST, MONITORING) - #57
Add ConnectionType enum (STANDARD, TEST, MONITORING)#57bpescato-amazon wants to merge 2 commits into
Conversation
Introduce a ConnectionType enum to distinguish between ordinary customer connections and special-purpose connections used for testing or monitoring. The new optional 'connectionType' field on Connection defaults to CONNECTION_TYPE_STANDARD when not specified. Connection types: - STANDARD: ordinary customer connections - TEST: reserved for provider dev teams; may use sub-minimum bandwidths, does not count against capacity, partners may enforce a small quota - MONITORING: reserved for active monitoring sessions; may use small bandwidths, does not count against capacity, limited to 1 per interconnect to enable monitoring across all underlying links
| size (e.g. 50 Mbps). Bandwidth consumed by test connections must not | ||
| count against interconnect or environment capacity totals. Partners may | ||
| enforce a small quota on the number of active test connections. | ||
| CONNECTION_TYPE_MONITORING - Monitoring connections are reserved for |
There was a problem hiding this comment.
Are we expecting any specific routing behavior from the monitoring connections (i.e. the reflector attachments) or just standard routing?
If we're expecting any special routing config here we probably want to document how it would work differently.
There was a problem hiding this comment.
I do think that the expectation of the MONITORING type is that any special routing that local provider must do to enable the agreed upon monitoring for the remote provider should be present.
I don't know if we want to distinctly document exactly what that should be per the API, as each provider may have differing requirements here.
There was a problem hiding this comment.
SGTM to avoid documenting exactly how it works, but it is worth documenting that this can have provider-specific behavior.
I also think that the quota here should be 2 monitoring connections allowed; one owned by one provider, a second owned by the other. E.g. if I ask AWS to create a monitoring connection, it may have different behavior than when you ask GCP to create one.
Final thing: should we consider documenting that a monitoring connection may not have a customer resource / key associated with it, or is that also something to leave up to each provider?
dkarwowski
left a comment
dkarwowski
left a comment
There was a problem hiding this comment.
Approving, only thing I'm thinking really needs to change is saying the quota is 2 per interconnect (allowing each provider to have a monitoring setup specific to them).
2 participants
Introduce a ConnectionType enum to distinguish between ordinary customer connections and special-purpose connections used for testing or monitoring.
The new optional 'connectionType' field on Connection defaults to CONNECTION_TYPE_STANDARD when not specified.
Connection types:
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.