Open Stack

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
<sumitnaiksatam at gmail.com>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
> <sumitnaiksatam at gmail.com> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140315/f3dcc3d6/attachment.html>