Re: [openstack-dev] [Neutron] Advanced Services Common requirements IRC meeting

2014-03-15 Thread Eugene Nikanorov
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
sumitnaiksa...@gmail.comwrote:

 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
 sumitnaiksa...@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Advanced Services Common requirements IRC meeting

2014-03-14 Thread Sumit Naiksatam
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
sumitnaiksa...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Neutron] Advanced Services Common requirements IRC meeting

2014-03-12 Thread Sumit Naiksatam
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev