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