-
Notifications
You must be signed in to change notification settings - Fork 18
Change stream.provider to stream.provisionerHost #86
Comments
I think we should consider inverting this thinking... rather than renaming the field to match the lower level implementation detail, we should consider "provider" to be a higher level concept and all that a user should be thinking about when creating a stream. How that maps to "provisioning" (which might vary widely when we add other types of streams, and which might move into the scope of the "gateway" itself). Along these same lines, we should consider whether "gateway" is a more appropriate name than "provider", e.g. change the |
I totally agree with that, but the problem now that we have loose providers, is that there is no (easy) way to identify such a provider. IMO, doing the following would be an acceptable compromise:
and require provider to have a Feel free to mentally PS: created bsideup/liiklus#220 to track provisioning as a liiklus responsibility |
all good points @ericbottard - I guess rather than renaming the provider CRDs we could add a |
What should the next steps for this be?
|
I don't see
|
At first glance My main question is who create the StreamGateway? If users are responsible for creating the StreamGateway resource, it could in turn create a Service with a matching selector and the provider is then responsible for defining the deployment that matches the selector. If the provider is responsible for creating the StreamGateway, it's logically not much different than the current situation with the provisioner Service. In both cases, what should happen if a StreamGateway is removed and replaced with a new resource of the same name? Should each stream detect this change and re-provision? This is not possible with the current model. |
Adding new Gateway and *Gateway resources along side the existing *Providers. Updated the Stream resource to be able to specify and track the Gateway in addition to the provisioner. Deprecated all providers. Refs #86 and RFC 0011 Co-Authored-By: Eric Bottard <[email protected]>
When creating a stream, the --provisioner flag is now --gateway, and its value is the same name the stream gateway was created with. Refs rfc 0011 Fixes projectriff/system#86
When creating a stream, the --provisioner flag is now --gateway, and its value is the same name the stream gateway was created with. Refs rfc 0011 Fixes projectriff/system#86
This better reflects what that field really is while preserving loose coupling
The text was updated successfully, but these errors were encountered: