Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming
It sounds good +1 On Fri, Aug 8, 2014 at 12:44 PM, Sumit Naiksatam wrote: > Thanks Jay for your constructive feedback on this. I personally think > that 'policy-target' is a good option. I am not sure what the rest of > the team thinks, perhaps they can chime in. > > On Fri, Aug 8, 2014 at 8:43 AM, Jay Pipes wrote: > > On 08/07/2014 01:17 PM, Ronak Shah wrote: > >> > >> Hi, > >> Following a very interesting and vocal thread on GBP for last couple of > >> days and the GBP meeting today, GBP sub-team proposes following name > >> changes to the resource. > >> > >> > >> policy-point for endpoint > >> policy-group for endpointgroup (epg) > >> > >> Please reply if you feel that it is not ok with reason and suggestion. > > > > > > Thanks Ronak and Sumit for sharing. I, too, wasn't able to attend the > > meeting (was in other meetings yesterday and today). > > > > I'm very happy with the change from endpoint-group -> policy-group. > > > > policy-point is better than endpoint, for sure. The only other > suggestion I > > might have would be to use "policy-target" instead of "policy-point", > since > > the former clearly delineates what the object is used for (a target for a > > policy). > > > > But... I won't raise a stink about this. Sorry for sparking long and > > tangential discussions on GBP topics earlier this week. And thanks to the > > folks who persevered and didn't take too much offense to my questioning. > > > > Best, > > -jay > > > > > > > > ___ > > 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
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. wrote: > On 8 August 2014 10:56, Kevin Benton 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
On Fri, Aug 8, 2014 at 2:21 PM, Armando M. 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] [neutron][policy] Group-based Policy next steps
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 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] [neutron][policy] Group-based Policy next steps
e Neutron incubator > can be evaluated once it actually becomes something more than a wiki page. > > > 1. > *http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html* > <http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html> > > -- > Kevin Benton > > > On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami <*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* >> 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* > 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* > *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* > *http://
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 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.
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.
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.
Please discuss.
>
> (4) We didn't get a chance to discuss this during last Thursday's
> meeting, but there has been discussion on the document regarding
> adding IP address fields in the classifier of a policy-rule. Email may
> be a better forum to state the use cases. Please discuss here.
>
> I will gather all the feedback by Wednesday and update the
> document before this coming Thursday's meeting.
>
>
We do need to support various use cases mentioned in the document where the
classifier is required to match on various fields in the packet header such
as IP address, MAC address, ports etc. The use cases are L2 firewall,
Monitoring devices where the traffic being sent to them is not dependent on
where they come from, thus can be derived from src and dst groups.
> Thanks,
> - Stephen
>
> [1]
> http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html
> [2]
> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n
>
> ___
> 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][policy] Policy-Rules discussions based on Dec.12 network policy meeting
On Dec 17, 2013 3:22 PM, "Tim Hinrichs" wrote:
>
>
>
> - Original Message -----
> | From: "Prasad Vellanki"
> | 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 d
Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
On Tue, Dec 17, 2013 at 7:34 PM, Stephen Wong wrote:
> Hi Prasad,
>
> Thanks for the comments, please see responses inline.
>
> On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
> wrote:
> > Hi
> > Please see inline
> >
> >
> > On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong
> 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
Re: [openstack-dev] [heat] Sofware Config progress
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 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 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 > 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
Re: [openstack-dev] [heat] Sofware Config progress
On Thu, Jan 9, 2014 at 6:14 AM, Steven Dake 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
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 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
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 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
[openstack-dev] [heat] question on proposed software config
I have a question on agent as part of cfninit that communicates with heat about config done state indication or config tool agent such as chef or puppet communicating with chef server. Since the VM resides on the data network, how does it reach the heat server that is on openstack management network. Is there a translation at network node similar to metadata server for 169 network for heat server access or chef server ? Of course I am assuming that chef server resides on management network too. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
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 wrote: > Zane Bitter 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 [for appliances]
On Thu, Feb 6, 2014 at 1:19 AM, Clint Byrum wrote: > Excerpts from Mike Spreitzer's message of 2014-02-05 22:17:50 -0800: > > > From: Prasad Vellanki > > > To: "OpenStack Development Mailing List (not for usage questions)" > > > , > > > 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 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 actuall
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
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 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 M." ---05/22/2014 11:24:35 PM---On 22 May 2014 13:59, Mandeep Dhami < > dh...@noironetworks.com> wrote: > > > From: "Armando M." > 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 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 thin
Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.
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 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 wrote: > >> 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] Fwd: FW: [Neutron] Group Based Policy and the way forward
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 wrote:
> On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
>
>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton 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
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 wrote: > > On Aug 6, 2014, at 3:56 PM, Armando M. wrote: > > > On 6 August 2014 15:47, Kevin Benton 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
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. 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
