Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-06 Thread Prasad Vellanki
...@noironetworks.com*
 dh...@noironetworks.com wrote:


I agree. Also, as this does not preclude using the incubator when it
is ready, this is a good way to start iterating on implementation in
parallel with those issues being addressed by the community.

In my view, the issues raised around the incubator were significant
enough (around packaging, handling of updates needed for
horizon/heat/celiometer, handling of multiple feature branches, etc) that
we we will probably need a design session in paris before a consensus will
emerge around a solution for the incubator structure/usage. And if you are
following the thread on nova for 'Averting the Nova crisis ...', the final
consensus might actually BE to use separate stackforge project for plugins
anyways, and in that case we will have a head start ;-)

Regards,
Mandeep
-


On Thu, Sep 4, 2014 at 10:59 PM, Prasad Vellanki 
*prasad.vella...@oneconvergence.com*
prasad.vella...@oneconvergence.com wrote:
   Sumit
   Thanks for initiating this and also good discussion today on the
   IRC.

   My thoughts are that it is important to make this available to
   potential users and customers as soon as possible so that we can get the
   necessary feedback. Considering that the neutron cores and community are
   battling nova parity and stability now, I would think it would be tough 
 to
   get any time for incubator or neutron feature branch any time soon.
   I would think it would be better to move GBP into stackforge and
   then look at incubator or neutron feature branch when available.

   prasadv


   On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam 
   *sumitnaiksa...@gmail.com* sumitnaiksa...@gmail.com wrote:
  Hi,

  There's been a lot of lively discussion on GBP a few weeks back
  and we
  wanted to drive forward the discussion on this a bit more. As you
  might imagine, we're excited to move this forward so more people
  can
  try it out.  Here are the options:

  * Neutron feature branch: This presumably allows the GBP feature
  to be
  developed independently, and will perhaps help in faster
  iterations.
  There does seem to be a significant packaging issue [1] with this
  approach that hasn’t been completely addressed.

  * Neutron-incubator: This allows a path to graduate into
  Neutron, and
  will be managed by the Neutron core team. That said, the
  proposal is
  under discussion and there are still some open questions [2].

  * Stackforge: This allows the GBP team to make rapid and
  iterative
  progress, while still leveraging the OpenStack infra. It also
  provides
  option of immediately exposing the existing implementation to
  early
  adopters.

  Each of the above options does not preclude moving to the other
  at a later time.

  Which option do people think is more preferable?

  (We could also discuss this in the weekly GBP IRC meeting on
  Thursday:
 *https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy*
  https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy)

  Thanks!

  [1]
  
 *http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html*
  
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html
  [2]
  
 *http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html*
  
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html

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


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


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




 --
 Kevin Benton___
 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

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-05 Thread Prasad Vellanki
Sumit
Thanks for initiating this and also good discussion today on the IRC.

My thoughts are that it is important to make this available to potential
users and customers as soon as possible so that we can get the necessary
feedback. Considering that the neutron cores and community are battling
nova parity and stability now, I would think it would be tough to get any
time for incubator or neutron feature branch any time soon.
I would think it would be better to move GBP into stackforge and then look
at incubator or neutron feature branch when available.

prasadv


On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
wrote:

 Hi,

 There's been a lot of lively discussion on GBP a few weeks back and we
 wanted to drive forward the discussion on this a bit more. As you
 might imagine, we're excited to move this forward so more people can
 try it out.  Here are the options:

 * Neutron feature branch: This presumably allows the GBP feature to be
 developed independently, and will perhaps help in faster iterations.
 There does seem to be a significant packaging issue [1] with this
 approach that hasn’t been completely addressed.

 * Neutron-incubator: This allows a path to graduate into Neutron, and
 will be managed by the Neutron core team. That said, the proposal is
 under discussion and there are still some open questions [2].

 * Stackforge: This allows the GBP team to make rapid and iterative
 progress, while still leveraging the OpenStack infra. It also provides
 option of immediately exposing the existing implementation to early
 adopters.

 Each of the above options does not preclude moving to the other at a later
 time.

 Which option do people think is more preferable?

 (We could also discuss this in the weekly GBP IRC meeting on Thursday:
 https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy)

 Thanks!

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html

 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Prasad Vellanki
GBP is about networking policy and hence limited to networking constructs.
It enhances the networking constructs. Since it follows more or less the
plugin model, it is not in one monolithic module but fans out to the policy
module and is done via  extension.


On Fri, Aug 8, 2014 at 12:45 PM, Armando M. arma...@gmail.com wrote:

 On 8 August 2014 10:56, Kevin Benton blak...@gmail.com wrote:

 There is an enforcement component to the group policy that allows you to
 use the current APIs and it's the reason that group policy is integrated
 into the neutron project. If someone uses the current APIs, the group
 policy plugin will make sure they don't violate any policy constraints
 before passing the request into the regular core/service plugins.


 This is the statement that makes me trip over, and I don't understand why
 GBP and Neutron Core need to be 'integrated' together as they have. Policy
 decision points can be decentralized from the system under scrutiny, we
 don't need to have one giant monolithic system that does everything; it's
 an architectural decision that would make difficult to achieve
 composability and all the other good -ilities of software systems.

 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Prasad Vellanki
On Fri, Aug 8, 2014 at 2:21 PM, Armando M. arma...@gmail.com wrote:

 Adding the GBP extension to Neutron does not change the nature of the
 software architecture of Neutron making it more or less monolithic.


 I agree with this statement...partially: the way GBP was developed is in
 accordance to the same principles and architectural choices made for the
 service plugins and frameworks we have right now, and yes it does not make
 Neutron more monolithic but certainly not less. These same very principles
 have unveiled limitations we have realized need to be addressed, according
 to Neutron's busy agenda. That said, if I were to be given the opportunity
 to revise some architectural decisions during the new groundbreaking work
 (regardless of the nature), I would.

 For instance, I hate that the service plugins live in the same address
 space of Neutron Server, I hate that I have one Neutron Server that does
 L2, L3, IPAM, ...; we could break it down and make sure every entity can
 have its own lifecycle: we can compose and integrate more easily if we did.
 Isn't that what years of middleware and distributed systems taught us?

 I suggested in the past that GBP would best integrate to Neutron via a
 stable and RESTful interface, just like any other OpenStack project does. I
 have been unable to be convinced otherwise, and I would love to be able to
 change my opinion.





 One advantage of the service plugin is that one can leverage the neutron
common framework such as Keystone authentication where common scoping is
done. It would be important in the policy type of framework to have such
scoping

While the service plugin has scalability issues as pointed above that it
resides in neutron server, it is however stable and user configurable and a
lot of common code is executed for networking services. So while we make
the next generation services framework more distributed and scalable, it is
ok to do it under the current framework especially since it has provision
for the user to opt in when needed.




 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Prasad Vellanki
Jay
Doesnt the current plugin model in neutron work the way you are saying. We
have a a core set of APIs that there is a reference model for and
individual vendors have substituted plugins that enhance and sometimes
replace networking component. GBP in that respect does not change. There is
a reference implementation in neutron for declarative model in neutron and
vendors can substitute their implementation to enhance what is in
reference.

But what you need to understand is the declarative model that it provides
which Ryan has elaborated which current neutron does not provide.

prasadv


On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:

 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:

 I believe the referential security group rules solve this problem (unless
 I'm not understanding):


 I think the disconnect is that you are comparing the way to current
 mapping
 driver implements things for the reference implementation with the
 existing
 APIs. Under this light, it's not going to look like there is a point to
 this
 code being in Neutron since, as you said, the abstraction could happen
 at a
 client. However, this changes once new mapping drivers can be added that
 implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks
 this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must
 support
 security groups and there is nowhere except for the firewall rules on
 that
 port to implement it without violating the user's expectation. With the
 latter, a mapping driver could determine that communication between these
 two hosts can be prevented by using an ACL on a router or a switch, which
 doesn't violate the user's intent and buys a performance improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Kevin, you have captured the GBP value prop and difference very
 succinctly. The major difference is in the declarative (GBP) versus
 imperative (current) style of programming.

 This has been stated very clearly and explicitly in the blueprint
 spec. If one does not appreciate the difference or advantage of one
 over the other, then this discussion is pointless.


 One does appreciate the value of having porcelain APIs overlay a
 plumbing API. This discussion was about the proper way and place to
 introduce such functionality.

 However, it seems to me that the end-goal of the GBP effort is *actually*
 to provide a higher-layer API to Neutron that would essentially enable
 proprietary vendors to entirely swap out all of Neutron core for a new set
 of drivers that spoke proprietary device APIs.

 If this is the end-goal, it should be stated more clearly, IMO.

 The classic plumbing versus porcelain API conversation [1] is a good one,
 and one worth having in the context of Neutron.

 It's almost like some Neutron contributor folks are saying let's add a
 porcelain API so we can ditch all the existing plumbing APIs and replace
 with our own stuff. And that's not what the point of plumbing vs.
 porcelain is.

 -jay

 [1] http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain


 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Prasad Vellanki
It seems like Option  1 would be preferable. User can use this right away.

The code and to a large extent BP has gone through quite a bit of review
already so it seems to me that there actually going lot less than usual. I
dont see a whole of lot Con on this. Though there are still some issues
with naming which can be cleared fairly quickly


On Wed, Aug 6, 2014 at 4:28 PM, Pedro Marques pedro.r.marq...@gmail.com
wrote:


 On Aug 6, 2014, at 3:56 PM, Armando M. arma...@gmail.com wrote:


 On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote:

 I think we should merge it and just prefix the API for now with
 '/your_application_will_break_after_juno_if_you_use_this/'


 And you make your call based and what pros and cons exactly, If I am ask?

 Let me start:

 Option 1:
   - pros
 - immediate delivery vehicle for consumption by operators


 Since our collective goal is to maximize the benefits for OpenStack
 users/operators, that seems to be the winner.

   - cons
 - code is burder from a number of standpoints (review, test, etc)


 Any piece of code is a burden.


 Option 2:
   - pros
 - enable a small set of Illuminati to iterate faster


 This is probably not intentional from your part ,but your choice of words
 make it seem that you are deriding the efforts of the team behind this
 effort. While i may disagree technically here and there with their current
 design, it seems to me that the effort in question is rather broad based in
 terms of support (from multiple different organizations) and that the team
 has put a non trivial effort in making the effort public. I don't think we
 can characterize the team either as a secret group or a small set.

   Pedro.


   - cons
 - integration burden with other OpenStack projects (keystone, nova,
 neutron, etc)

 Cheers,
 Armando
 ___
 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


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


Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Prasad Vellanki
I don't think people are choosing because of the shortest route but rather
these may be two different items that are not completely exclusive but
different enough.
Nova parity addresses the scope to have existing well understood and stable
api currently supported in nova to be supported in neutron and a dash to
make that code stable. The goal is to move quickly to enable replacement of
nova networking.
While group policy is offering additional abstractions which are richer
that enables easier usage of networking.

Both teams have been working diligently towards that goal. As pedro points
out there are several people from different organizations working on GBP to
ensure stability and closely reviewed code is checked in.

I think both nova parity and GBP can go in parallel, hence my choice of
option 1


On Wed, Aug 6, 2014 at 6:13 PM, Armando M. arma...@gmail.com wrote:

 On 6 August 2014 17:34, Prasad Vellanki 
 prasad.vella...@oneconvergence.com wrote:

 It seems like Option  1 would be preferable. User can use this right
 away.


 People choosing Option 1 may think that the shortest route may be the
 best, that said the drawback I identified is not to be dismissed either
 (and I am sure there many more pros/cons): an immature product is of good
 use to no-one, and we still have the nova parity that haunts us.

 I think this could be another reason why people associated GBP and
 nova-network parity in this thread: the fact that new abstractions are
 introduced without solidifying the foundations of the project is a risk to
 GBP as well as Neutron itself.


 ___
 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][group-based-policy] Should we revisit the priority of group-based policy?

2014-05-23 Thread Prasad Vellanki
Great to see the discussions on the ML.
Mohammad - Good summary.

I would like to make few  points
1) The current GP API is tuned towards person deploying the application as
opposed to the networking person. This is probably a better way as one
starts to think about self service infrastructure model and person
deploying applications. We had debated about this on IRC and thought that
policies/contract applied to the end point group would be easier
abstraction. The complexity of networking is transformed to the
implementation while still retaining the flexibility for network admin to
provide additional policies.
2) I agree with mohammad that the feedback received for policy driven model
was very positive. I heard in one of the BOF sessions a large operator
commenting on this specifically in a very positive way. It would be sad to
see this relegated to lesser priority. I am not saying that we should not
address other issues in neutron but this should be addressed with equal
priority. Especially when a lot of thought and PoC is already being done.
3) It was to good see consensus on the IRC today about the process
particularly around code simplification, checkins and reviews as raised in
the emails.

thanks
prasadv


On Thu, May 22, 2014 at 9:10 PM, Mohammad Banikazemi m...@us.ibm.com wrote:

 Thanks to everyone who participated in the Group Policy meeting [1]
 earlier today. A lot of good discussion that hopefully will continue with
 participation from the larger community. I wanted to first make a comment
 about how the Group Policy work was received outside the Neutron community
 and then focus on finding a way for us to make progress.

 I think we had a really good feedback from the larger OpenStack community
 and I would say a wide support for addition of policy abstractions to
 Neutron. If the feedback we received at the summit in Hong Kong was mostly
 positive, in Atlanta the support was overwhelmingly positive in my opinion.
 I just wanted to make sure this does not get lost in our discussions.

 Needless to say, we will work on a path to have the Group Policy work
 included in Neutron in a way that keeps the quality of code in Neutron
 preserved. To rephrase what Armando said in the IRC meeting earlier today,
 we all share a common goal and that is to do what's right. I think it may
 be beneficial that for the moment and for the next few days as we try to
 find the best path forward, we forget about any particular
 cycle/milestone/priority and look for the best path forward and see where
 that leads us. To this end, the group policy team will be setting up a
 meeting with Armando (and others who are interested) to in particular
 discuss the possibility of making the code less tightly coupled with
 Neutron core. We will also consider how we can address Marun's and Mark's
 concerns by trying to have a simpler but functional set of patches that can
 be reviewed more effectively such that we can build on them in an iterative
 manner.

 Meanwhile, please do continue the discussion on the mailing list.

 Best,

 Mohammad

 [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

 [image: Inactive hide details for Armando M. ---05/22/2014 11:24:35
 PM---On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com]Armando
 M. ---05/22/2014 11:24:35 PM---On 22 May 2014 13:59, Mandeep Dhami 
 dh...@noironetworks.com wrote: 

 From: Armando M. arma...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org,
 Date: 05/22/2014 11:24 PM
 Subject: Re: [openstack-dev] [neutron][group-based-policy] Should we
 revisit the priority of group-based policy?
 --



 On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote:
 
  Maru's concerns are that:
  1. It is large
  2. It is complex
 
  And Armando's related concerns are:
  3. Could dev/review cycles be better spent on refactoring
  4. If refactored neutron was available, would a simpler option become
 more
  viable

 This is not what I meant to say, and if this was the message that came
 across I apologize for the confusion; let me rephrase:

 After looking (and relooking) at the initial patches proposed I
 started to question why the GP plugin functionality was so tightly
 integrated with the Neutron core functionality; even though I might
 guess the thinking process, I wonder if such tight coupling was the
 result of design decisions made without thoroughly considering
 alternative approaches. Without going too much into details during
 this email, I can see in the above mentioned patches that lots of
 plumbing code (like Nova and dhcp notifiers handling code) is put in
 place to make direct calls to core plugin methods: this spills
 implementation details across multiple parts of the project; it's
 fragile because it's prone to ripple effects due to lack of proper
 encapsulation: if a change is made in the plugin API or its
 implementation, the whole thing needs to 

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

2014-04-21 Thread Prasad Vellanki
Aaron
One use case is that tenant would like to put all the servers in a single
broadcast domain (thus single IP/subnet  domain). The servers can include
the 3 tier servers (web database and application server). Why would he do
that - Because it is simpler.

Then the tenant would like to put security appliance firewalls between
them. Lets say a database firewall appliance before the database tier or
only app servers can access database servers.

This is done in physical world but one needs to add switches and wire them
from one broadcast domain to other. It is a pain. But in the virtual world
this is lot simpler and convenient.

prasadv


On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 This is true. Several people have asked this same question over the years
 though I've yet to hear a use case why one really need to do this. Do you
 have one?


 On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah ro...@nuagenetworks.netwrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in
 different subnet, they have to be in different network as well (container
 for the subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet interfaces
 with IP of single subnet. Is this supported now in openstack ? Any
 suggestion ?


 Thanx



 ___
 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



 ___
 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] [heat] Sofware Config progress [for appliances]

2014-02-06 Thread Prasad Vellanki
On Thu, Feb 6, 2014 at 1:19 AM, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Mike Spreitzer's message of 2014-02-05 22:17:50 -0800:
   From: Prasad Vellanki prasad.vella...@oneconvergence.com
   To: OpenStack Development Mailing List (not for usage questions)
   openstack-dev@lists.openstack.org,
   Date: 01/21/2014 02:16 AM
   Subject: Re: [openstack-dev] [heat] Sofware Config progress
  
   Steve  Clint
  
   That should work. We will look at implementing a resource that spins
   up a shortlived VM for bootstrapping a service VM and informing
   configuration server for further configuration.
  
   thanks
   prasadv
  
 
   On Wed, Jan 15, 2014 at 7:53 PM, Steven Dake sd...@redhat.com wrote:
   On 01/14/2014 09:27 PM, Clint Byrum wrote:
   Excerpts from Prasad Vellanki's message of 2014-01-14 18:41:46 -0800:
   Steve
  
   I did not mean to have custom solution at all. In fact that would be
   terrible.  I think Heat model of software config and deployment is
  really
   good. That allows configurators such as Chef, Puppet, Salt or Ansible
 to
  be
   plugged into it and all users need to write are modules for those.
  
   What I was  thinking is if there is a way to use software
  config/deployment
 to do initial configuration of the appliance by using agentless
 system
   such  as Ansible or Salt, thus requiring no cfminit. I am not sure this
   will work either, since it might require ssh keys to be installed for
   getting ssh to work without password prompting. But I do see that
  ansible
   and salt support username/password option.
   If this would not work, I agree that the best option is to make them
   support cfminit...
   Ansible is not agent-less. It just makes use of an extremely flexible
   agent: sshd. :) AFAIK, salt does use an agent though maybe they've
 added
   SSH support.
  
   Anyway, the point is, Heat's engine should not be reaching into your
   machines. It talks to API's, but that is about it.
  
   What you really want is just a VM that spins up and does the work for
   you and then goes away once it is done.
   Good thinking.  This model might work well without introducing the
   groan another daemon problems pointed out elsewhere in this thread
   that were snipped.  Then the modules could simply be heat
   templates available to the Heat engine to do the custom config setup.
  
   The custom config setup might still be a problem with the original
   constraints (not modifying images to inject SSH keys).
  
   That model wfm.
  
   Regards
   -steve
  
 
  (1) What destroys the short-lived VM if the heat engine crashes between
  creating and destroying that short-lived VM?
 

 The heat-engine that takes over the stack. Same as the answer for what
 happens when a stack is half-created and heat-engine dies.

  (2) What if something goes wrong and the heat engine never gets the
 signal
  it is waiting for?
 

 Timeouts already cause failed state or rollback.

  (3) This still has the problem that something needs to be configured
  some(client-ish)where to support the client authorization solution
  (usually username/password).
 

 The usual answer is that's cloud-init's job but we're discussing
 working around not having cloud-init, so I suspect it has to be built
 into the image (which, btw, is a really really bad idea). Another option
 is that these weird proprietary systems might reach out to an auth
 service which the short-lived VM would also be able to contact given
 appropriate credentials for said auth service fed in via parameters.

 The idea I thought was that the short lived VM will act as a proxy to the
configuration engine such as Puppet or chef to bootstrap ie get the
credentials for appliance. Once the initial bootstrap is done, then regular
configuration process as suggested by Heat will work.

Though I had one question as to how heat will send configuration
information to puppet or chef that configures the VM in tenant domain.
Assuming that the chef or puppet can be reachable from tenant VM, how does
heat reach chef server.

One scenario  that needs a little thought is if the service VM is actually
owned by the provider but is  invoked in the tenant domain. The management
of such will come  via Neutron API but then on the backend driver for that
service will configure the service VM. It would be great if Heat is used
for this.

 (4) Given that everybody seems sanguine about solving the client
  authorization problem, what is wrong with code in the heat engine opening
  and using a connection to code in an appliance?  Steve, what do you mean
  by reaching into your machines that is critically different from
 calling
  their APIs?
 

 We can, and should, poke holes from heat-engine, out through a firewall,
 so it can connect to all of the endpoints. However, if we start letting
 it talk to all the managed machines, it becomes a really handy DoS tool
 and also spends a ton of time talking to things that we have no control
 over, thus taking up

Re: [openstack-dev] [Heat] How to model resources in Heat

2014-01-30 Thread Prasad Vellanki
Zane
Thanks for putting this together. This will guide us as we develop some
resources in Heat.
As chmouel said it would be great if this can be converted to blog article.

thanks
prasadv


On Wed, Jan 29, 2014 at 11:09 PM, Chmouel Boudjnah chmo...@enovance.comwrote:

 Zane Bitter zbit...@redhat.com writes:

  As I said, figuring this all out is really hard to do, and the
  existing resources in Heat are by no means perfect (we even had a
  session at the Design Summit devoted to fixing some of them[1]). If
  anyone has a question about a specific model, feel free to ping me or
  add me to the review and I will do my best to help.

 Thanks for writing this up Zane, I have been often confused with the
 modeling system of Heat, it may be worthwhile to store this in
 documentation or a blog article.

 Cheers,
 Chmouel.

 ___
 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] [heat] Sofware Config progress

2014-01-20 Thread Prasad Vellanki
Steve  Clint

That should work. We will look at implementing a resource that spins up a
shortlived VM for bootstrapping a service VM and informing configuration
server for further configuration.

thanks
prasadv


On Wed, Jan 15, 2014 at 7:53 PM, Steven Dake sd...@redhat.com wrote:

 On 01/14/2014 09:27 PM, Clint Byrum wrote:

 Excerpts from Prasad Vellanki's message of 2014-01-14 18:41:46 -0800:

 Steve

 I did not mean to have custom solution at all. In fact that would be
 terrible.  I think Heat model of software config and deployment is really
 good. That allows configurators such as Chef, Puppet, Salt or Ansible to
 be
 plugged into it and all users need to write are modules for those.

 What I was  thinking is if there is a way to use software
 config/deployment
   to do initial configuration of the appliance by using agentless system
 such  as Ansible or Salt, thus requiring no cfminit. I am not sure this
 will work either, since it might require ssh keys to be installed for
 getting ssh to work without password prompting. But I do see that ansible
 and salt support username/password option.
 If this would not work, I agree that the best option is to make them
 support cfminit...

 Ansible is not agent-less. It just makes use of an extremely flexible
 agent: sshd. :) AFAIK, salt does use an agent though maybe they've added
 SSH support.

 Anyway, the point is, Heat's engine should not be reaching into your
 machines. It talks to API's, but that is about it.

 What you really want is just a VM that spins up and does the work for
 you and then goes away once it is done.

 Good thinking.  This model might work well without introducing the groan
 another daemon problems pointed out elsewhere in this thread that were
 snipped.  Then the modules could simply be heat templates available to
 the Heat engine to do the custom config setup.

 The custom config setup might still be a problem with the original
 constraints (not modifying images to inject SSH keys).

 That model wfm.

 Regards
 -steve


  ___
 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

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


Re: [openstack-dev] [heat] Sofware Config progress

2014-01-14 Thread Prasad Vellanki
Steve

I did not mean to have custom solution at all. In fact that would be
terrible.  I think Heat model of software config and deployment is really
good. That allows configurators such as Chef, Puppet, Salt or Ansible to be
plugged into it and all users need to write are modules for those.

What I was  thinking is if there is a way to use software config/deployment
 to do initial configuration of the appliance by using agentless system
such  as Ansible or Salt, thus requiring no cfminit. I am not sure this
will work either, since it might require ssh keys to be installed for
getting ssh to work without password prompting. But I do see that ansible
and salt support username/password option.
If this would not work, I agree that the best option is to make them
support cfminit...

thanks
prasadv


On Mon, Jan 13, 2014 at 11:23 PM, Prasad Vellanki 
prasad.vella...@oneconvergence.com wrote:


 On Thu, Jan 9, 2014 at 6:14 AM, Steven Dake sd...@redhat.com wrote:

 that


 Steve
 Thanks for detailed email. Apologize for the delayed response but we have
 been thinking about how does software config fit into configuring network
 and service function devices. I agree with you that in general it is best
 to get appliance vendors to put cloudinit into their images and thus get on
 board with what every cloud is doing. I thought I would get some feedback
 on the direction of Heat for configuring network devices and appliances.

 I am thinking there are few things to consider for configuring Network and
 Network Service devices/Virtual Appliances.

 Neutron APIs along with the service APIs provide a way to configure
 network devices by abstracting the APIs and have a plugin model for
 individual devices. These APIs include Neutron core apis, Service API such
 as LBaaS, FWaaS, VPNaaS. Though these are currently for physical devices,
 there is a movement towards configuring Virtual Appliances too. These APIs
 will be addressed via Heat Neutron resources.

 While *aaS do address configuring the supported service, they do not
 address the bootstrapping of the device. Generally for most devices
 bootstrapping is done via rest API and/or SSH. And for unsupported
  services that do not have these APIs one needs to use custom way to
 configure where Heat can really help.  Bootstrapping includes installing
 licences, configuring admin password, upgrade software  and some with more
 than that. For this our thought is it would be great to have  Heat software
 config/deployment do bootstrapping, upgrade etc.

  While I agree long term is to have vendors to implement cloudinit
 framework, we were wondering if there is an intermediate solution that will
 allow configuration without requiring agent and cloudinit, If there is
 enough critical mass behind such a requirement we can have further
 discussions on the design and implementation options.

 BTW puppet seems to use similar proxy way to network device configuration.
 See link below
 https://puppetlabs.com/blog/managing-f5-big-ip-network-devices-with-puppet

 thanks
 prasadv


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


Re: [openstack-dev] [heat] Sofware Config progress

2014-01-13 Thread Prasad Vellanki
On Thu, Jan 9, 2014 at 6:14 AM, Steven Dake sd...@redhat.com wrote:

 that


Steve
Thanks for detailed email. Apologize for the delayed response but we have
been thinking about how does software config fit into configuring network
and service function devices. I agree with you that in general it is best
to get appliance vendors to put cloudinit into their images and thus get on
board with what every cloud is doing. I thought I would get some feedback
on the direction of Heat for configuring network devices and appliances.

I am thinking there are few things to consider for configuring Network and
Network Service devices/Virtual Appliances.

Neutron APIs along with the service APIs provide a way to configure network
devices by abstracting the APIs and have a plugin model for individual
devices. These APIs include Neutron core apis, Service API such as LBaaS,
FWaaS, VPNaaS. Though these are currently for physical devices, there is a
movement towards configuring Virtual Appliances too. These APIs will be
addressed via Heat Neutron resources.

While *aaS do address configuring the supported service, they do not
address the bootstrapping of the device. Generally for most devices
bootstrapping is done via rest API and/or SSH. And for unsupported
 services that do not have these APIs one needs to use custom way to
configure where Heat can really help.  Bootstrapping includes installing
licences, configuring admin password, upgrade software  and some with more
than that. For this our thought is it would be great to have  Heat software
config/deployment do bootstrapping, upgrade etc.

 While I agree long term is to have vendors to implement cloudinit
framework, we were wondering if there is an intermediate solution that will
allow configuration without requiring agent and cloudinit, If there is
enough critical mass behind such a requirement we can have further
discussions on the design and implementation options.

BTW puppet seems to use similar proxy way to network device configuration.
See link below
https://puppetlabs.com/blog/managing-f5-big-ip-network-devices-with-puppet

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


Re: [openstack-dev] [heat] Sofware Config progress

2014-01-08 Thread Prasad Vellanki
Clint  Steve
One scenario we are trying to see is whether and how Heat software-config
enables  deployment of  images available from third party as virtual
appliances,  providing network, security or acceleration capabilities. The
vendor in some cases might not allow rebuilding and/or  may not have the
cloud init capability.Sometimes changes to the image could run into issues
with licensing. Bootstrapping in such situations is generally done via rest
api or ssh once the appliance boots up where one can bootstrap it further.

We are looking at how to automate deployment of such service functions
using new configuration and deployment  model in Heat which we really like.

One option is that software-config can provide an option in Heat to trigger
bootstrapping that can be done from outside rather than inside,  as done by
 cloud-init, and does bootstrapping of appliances using ssh and/or rest.

Another option is there could be an agent outside that recognizes this kind
of service coming up and then inform Heat  to go to next state to configure
the deployed resource. This is more like a proxy model.

thanks
prasadv



On Tue, Jan 7, 2014 at 11:40 AM, Clint Byrum cl...@fewbar.com wrote:

 I'd say it isn't so much cloud-init that you need, but some kind
 of bootstrapper. The point of hot-software-config is to help with
 in-instance orchestration. That's not going to happen without some way
 to push the desired configuration into the instance.

 Excerpts from Susaant Kondapaneni's message of 2014-01-07 11:16:16 -0800:
  We work with images provided by vendors over which we do not always have
  control. So we are considering the cases where vendor image does not come
  installed with cloud-init. Is there a way to support heat software config
  in such scenarios?
 
  Thanks
  Susaant
 
  On Mon, Jan 6, 2014 at 4:47 PM, Steve Baker sba...@redhat.com wrote:
 
On 07/01/14 06:25, Susaant Kondapaneni wrote:
  
Hi Steve,
  
I am trying to understand the software config implementation. Can you
   clarify the following:
  
i. To use Software config and deploy in a template, instance resource
   MUST always be accompanied by user_data. User_data should specify how
 to
   bootstrap CM tool and signal it. Is that correct?
  
 Yes, currently the user_data contains cfn-init formatted metadata
 which
   tells os-collect-config how to poll for config changes. What happens
 when
   new config is fetched depends on the os-apply-config templates and
   os-refresh-config scripts which are already on that image (or set up
 with
   cloud-init).
  
ii. Supposing we were to use images which do not have cloud-init
   packaged in them, (and a custom CM tool that won't require
 bootstrapping on
   the instance itself), can we still use software config and deploy
 resources
   to deploy software on such instances?
  
 Currently os-collect-config is more of a requirement than cloud-init,
   but as Clint said cloud-init does a good job of boot config so you'll
 need
   to elaborate on why you don't want to use it.
  
iii. If ii. were possible who would signal the deployment resource to
   indicate that the instance is ready for the deployment?
  
   os-collect-config polls for the deployment data, and triggers the
   resulting deployment/config changes. One day this may be performed by a
   different agent like the unified agent that has been discussed.
 Currently
   os-collect-collect polls via a heat-api-cfn metadata call. This too
 may be
   done in any number of ways in the future such as messaging or
 long-polling.
  
   So you *could* consume the supplied user_data to know what to poll for
   subsequent config changes without cloud-init or os-collect-config, but
 you
   would have to describe what you're doing in detail for us to know if
 that
   sounds like a good idea.
  
  
  
Thanks
   Susaant
  
  
   On Fri, Dec 13, 2013 at 3:46 PM, Steve Baker sba...@redhat.com
 wrote:
  
I've been working on a POC in heat for resources which perform
 software
   configuration, with the aim of implementing this spec
  
 https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-spec
  
   The code to date is here:
   https://review.openstack.org/#/q/topic:bp/hot-software-config,n,z
  
   What would be helpful now is reviews which give the architectural
   approach enough of a blessing to justify fleshing this POC out into a
 ready
   to merge changeset.
  
   Currently it is possible to:
   - create templates containing OS::Heat::SoftwareConfig and
   OS::Heat::SoftwareDeployment resources
   - deploy configs to OS::Nova::Server, where the deployment resource
   remains in an IN_PROGRESS state until it is signalled with the output
 values
   - write configs which execute shell scripts and report back with
 output
   values that other resources can have access to.
  
   What follows is an overview of the architecture and implementation to
   help with your reviews.
  
   REST API
   
   Like 

Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

2013-12-19 Thread Prasad Vellanki
On Dec 17, 2013 3:22 PM, Tim Hinrichs thinri...@vmware.com wrote:



 - Original Message -
 | From: Prasad Vellanki prasad.vella...@oneconvergence.com
 | To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
 | Sent: Monday, December 16, 2013 2:11:37 PM
 | Subject: Re: [openstack-dev] [neutron][policy] Policy-Rules discussions
based on Dec.12 network policy meeting
 |
 |
 |
 | Hi
 | Please see inline 
 |
 |
 |
 | On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong  s3w...@midokura.com 
 | wrote:
 |
 |
 | Hi,
 |
 | During Thursday's group-policy meeting[1], there are several
 | policy-rules related issues which we agreed should be posted on the
 | mailing list to gather community comments / consensus. They are:
 |
 | (1) Conflict resolution between policy-rules
 | --- a priority field was added to the policy-rules attributes
 | list[2]. Is this enough to resolve conflict across policy-rules (or
 | even across policies)? Please state cases where a cross policy-rules
 | conflict can occur.
 | --- conflict resolution was a major discussion point during
 | Thursday's meeting - and there was even suggestion on setting
 | priority
 | on endpoint groups; but I would like to have this email thread
 | focused
 | on conflict resolution across policy-rules in a single policy first.
 |

 There was interest in having a single policy that could include different
actions so that a single flow might be both redirected and QOSed
simultaneously.  For me this rules out a total ordering on the policy
statements.  Here's a proposal that relies on the fact that we're fixing
the meaning of actions within the language: the language specifies a
partial order on the *actions*.  For example, DENY takes precedence over
ALLOW, so if we both ALLOW and DENY, then the conflict resolution dictates
DENY wins. But {DENY, ALLOW} and QOS and REDIRECT are all unrelated, so
there is no problem with a policy that both DENYs and QOSes and REDIRECTs.

 | (2) Default policy-rule actions
 | --- there seems to be consensus from the community that we need to
 | establish some basic set of policy-rule actions upon which all
 | plugins/drivers would have to support
 | --- just to get the discussion going, I am proposing:
 |
 |
 |
 | Or should this be a query the plugin for supported actions and thus
 | the user knows what functionality the plugin can support. Hence
 | there is no default supported list.
 |

 I think the important part is that the language defines what the actions
mean.  Whether each plugin supports them all is a different issue.  If the
language doesn't define the meaning of the actions, there's no way for
anyone to use the language.  We might be able to write down policies, but
we don't know what those policies actually mean because 2 plugins might
assign very different meanings to the same action name.


I agree that it is very important to define what actions mean.


As for supported action, it is probably best to simplify this for POC by
restricting it to a small set of actions. One can always add this call. My
point was UI becomes cleaner and clear for the user if you have the call.


 |
 |
 | a.) action_type: 'security' action: 'allow' | 'drop'
 | b.) action_type: 'qos' action: {'qos_class': {'critical' |
 | 'low-priority' | 'high-priority' |
 |
 | 'low-immediate' | 'high-immediate' |
 |
 | 'expedite-forwarding'}
 | (a subset of DSCP values - hopefully in language that can
 | be well understood by those performing application deployments)
 | c.) action_type:'redirect' action: {UUID, [UUID]...}
 | (a list of Neutron objects to redirect to, and the list
 | should contain at least one element)
 |
 |
 |
 |
 | I am not sure making the UUIDs a list of neutron objects or endpoints
 | will work well. It seems that it should more higher level such as
 | list of services that form a chain. Lets say one forms a chain of
 | services, firewall, IPS, LB. It would be tough to expect user to
 | derive the neutron ports create a chain of them. It could be a VM
 | UUID.
 |
 |

 Perhaps we could use our usual group mechanism here and say that the
redirect action operates on 3 groups: source, destination, and the group to
which we want to redirect.


 |
 | Please discuss. In the document, there is also 'rate-limit' and
 | 'policing' for 'qos' type, but those can be optional instead of
 | required for now
 |

 It would be nice if we had some rationale for deciding which actions to
include and which to leave out.  Maybe if we found a
standard/spec/collection-of-use-cases and included exactly the same
actions.  Or if we go with the action-based conflict resolution scheme from
(1), we might want to think about whether we have at least complementary
actions (e.g. ALLOW and DENY, WAYPOINT -- route traffic through a group of
middleboxes-- and FORBID -- prohibit traffic from passing through
middleboxes).

 | (3) Prasad asked for clarification on 'redirect' action, I propose to
 | add the following text

Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

2013-12-19 Thread Prasad Vellanki
On Tue, Dec 17, 2013 at 7:34 PM, Stephen Wong s3w...@midokura.com wrote:

 Hi Prasad,

 Thanks for the comments, please see responses inline.

 On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
 prasad.vella...@oneconvergence.com wrote:
  Hi
  Please see inline 
 
 
  On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong s3w...@midokura.com
 wrote:
 
  Hi,
 
  During Thursday's  group-policy meeting[1], there are several
  policy-rules related issues which we agreed should be posted on the
  mailing list to gather community comments / consensus. They are:
 
  (1) Conflict resolution between policy-rules
  --- a priority field was added to the policy-rules attributes
  list[2]. Is this enough to resolve conflict across policy-rules (or
  even across policies)? Please state cases where a cross policy-rules
  conflict can occur.
  --- conflict resolution was a major discussion point during
  Thursday's meeting - and there was even suggestion on setting priority
  on endpoint groups; but I would like to have this email thread focused
  on conflict resolution across policy-rules in a single policy first.
 
  (2) Default policy-rule actions
  --- there seems to be consensus from the community that we need to
  establish some basic set of policy-rule actions upon which all
  plugins/drivers would have to support
  --- just to get the discussion going, I am proposing:
 
 
  Or should this be a query the plugin for supported actions and thus the
 user
  knows what functionality the plugin can support.  Hence there is no
 default
  supported list.

 I think what we want is a set of must-have actions which
 application can utilize by default while using the group-policy APIs.
 Without this, application would need to perform many run time checks
 and have unpredictable behavior across different deployments.

 As for querying for a capability list - I am not against having
 such API, but what is the common use case? Having a script querying
 for the supported action list and generate policies based on that?
 Should we expect policy definition to be so dynamic?


I agree that we should simplify this for POC.

The use case is in the UI the user should know what actions are valid. The
user should not wait for error to figure out whether a action is valid. But
if we put well defined set that is mandatory this is not an issue.



 
  a.) action_type: 'security'action: 'allow' | 'drop'
  b.) action_type: 'qos'action: {'qos_class': {'critical' |
  'low-priority' | 'high-priority' |
 
 'low-immediate' | 'high-immediate' |
 
 'expedite-forwarding'}
   (a subset of DSCP values - hopefully in language that can
  be well understood by those performing application deployments)
  c.) action_type:'redirect'   action: {UUID, [UUID]...}
   (a list of Neutron objects to redirect to, and the list
  should contain at least one element)
 
 
  I am not sure making the UUIDs a list of neutron objects or endpoints
 will
  work well. It seems that it should more higher level such as list of
  services that form a chain. Lets say one forms a chain of services,
  firewall, IPS, LB. It would be tough to expect user to derive the neutron
  ports create a chain of them. It could be a VM UUID.

 Service chain is a Neutron object with UUID:


 https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#

 so this is not defined by the group-policy subgroup, but from a
 different project. We expect operator / tenant to define a service
 chain for the users, and users simply pick that as one of the
 redirect action object to send traffic to.


 
  Please discuss. In the document, there is also 'rate-limit' and
  'policing' for 'qos' type, but those can be optional instead of
  required for now
 
  (3) Prasad asked for clarification on 'redirect' action, I propose to
  add the following text to document regarding 'redirect' action:
 
  'redirect' action is used to mirror traffic to other destinations
  - destination can be another endpoint group, a service chain, a port,
  or a network. Note that 'redirect' action type can be used with other
  forwarding related action type such as 'security'; therefore, it is
  entirely possible that one can specify {'security':'deny'} and still
  do {'redirect':{'uuid-1', 'uuid-2'...}. Note that the destination
  specified on the list CANNOT be the endpoint-group who provides this
  policy. Also, in case of destination being another endpoint-group, the
  policy of this new destination endpoint-group will still be applied
 
 
  As I said above one needs clarity on what these UUIDs mean. Also do we
 need
  a call to manage the ordered list around adding, deleting.listing the
  elements in the list.
  One other issue that comes up whether the classifier holds up along the
  chain. The classifier that goes into the chain might not be the same on
 the
  reverse path