I'd like to clarify on providers/vendors: The idea is that provider/vendor attribute (technically ProviderResourceAssociation) is still used for dispatching calls to the drivers. We may, or may not show this attribute to a tenant. And it's not an attribute that can be provided by admin or tenant, it's always a result of scheduling, e.g. readonly.
Thanks, Eugene. On Sat, Mar 15, 2014 at 12:25 AM, Sumit Naiksatam <[email protected]>wrote: > Here is a summary from yesterday's meeting: > > ** Flavors (topic lead: Eugene Nikanorov) > * Hide the provider implementation details from the user > - The admin API would still need to be able to configure the > provider artifacts > - Suggestion to leverage existing provider model for this > - Also suggestion to optionally expose vendor in the tenant-facing API > * It should have generic application to Neutron services > * It should be able to represent different "flavors" of the same > service (supported by the same or different backend providers) > * Should the tenant facing abstraction support exact match and/or > loose semantics for flavor specifications? > - This does not necessarily have to be mutually exclusive. We could > converge on a base set of attributes as a part of the generic and > common definition across services. There could be additional > (extended) attributes that can be exposed per backend provider (and > might end up being specific to that deployment) > * Name of this abstraction, we did not discuss this > > ** Service Insertion/Chaining (topic lead: Sumit Naiksatam) > * Service context > - general agreement on what is being introduced in: > https://review.openstack.org/#/c/62599 > * Service chain > - Can a flavor capture the definition of a service chain. Current > thinking is yes. > - If so, we need to discuss more on the feasibility of tenant > created service chains > - The current approach specified in: > > https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering > does not preclude this. > > ** Vendor plugins for L3 services (topic lead: Paul Michali) > * how to handle/locate vendor config files > * way to do vendor validation (e.g. validate, commit, apply ~ to > precommit/postcommit) > * How to tell client what vendor capabilities are > * How to report to plugin status, when there are problems > * I've seen a bunch of these issues with VPN development and imagine > other svcs do to. > * Should we setup a separate IRC to discuss some ideas on this? > > ** Requirements for group policy framework > * We could not cover this > > ** Logistics > * The feedback was to continue this meeting on a weekly basis (since > lots more discussions are needed on these and other topics), and > change the day/time to Wednesdays at 1700 UTC on #openstack-meeting-3 > > Meeting wiki page and logs can be found here: > https://wiki.openstack.org/wiki/Meetings/AdvancedServices > > Thanks, > ~Sumit. > > > On Wed, Mar 12, 2014 at 9:20 PM, Sumit Naiksatam > <[email protected]> wrote: > > Hi, > > > > This is a reminder - we will be having this meeting in > > #openstack-meeting-3 on March 13th (Thursday) at 18:00 UTC. The > > proposed agenda is as follows: > > > > * Flavors/service-type framework > > * Service insertion/chaining > > * Group policy requirements > > * Vendor plugins for L3 services > > > > We can also decide the time/day/frequency of future meetings. > > > > Meeting wiki: https://wiki.openstack.org/wiki/Meetings/AdvancedServices > > > > Thanks, > > ~Sumit. > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
