Open Stack

The only issue with the separate service proxying API calls is that it
can't receive requests between the service and core plugins.

What kind of stability requirements were you concerned about? A response
change would be similar to having a custom policy.json file where things
that violate constraints would result in a 403.
On Aug 8, 2014 1:04 PM, "Maru Newby" <marun at redhat.com> wrote:

> On Aug 8, 2014, at 10:56 AM, Kevin Benton <blak111 at 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.
>
>
> The enforcement requirement might be easier to implement through
> code-based integration, but a separate service could provide the same
> guarantee against constraint violation by proxying v2 API calls for an
> endpoint to which access was restricted.
>
> Apologies if I've missed discussion of this (it's a big thread), but won't
> enforcement by group policy on the v2 API have the potential to violate
> stability requirements?  If new errors related to enforcement can result
> from API calls, that would seem to be a change in behavior.  Do we have a
> precedent for allowing extensions or new services to modify core behavior
> in this way?
>
>
> m.
>
> >
> >
> > On Fri, Aug 8, 2014 at 11:02 AM, Salvatore Orlando <sorlando at nicira.com>
> wrote:
> > It might be because of the wording used, but it seems to me that you're
> making it sound like the group policy effort could have been completely
> orthogonal to neutron as we know it now.
> >
> > What I understood is that the declarative abstraction offered by group
> policy could do without any existing neutron entity leveraging "native"
> drivers, but can actually be used also with existing neutron plugins
> through the mapping driver - which will provide a sort of backward
> compatibility. And still in that case I'm not sure one would be able to use
> "traditional" neutron API (or "legacy" as it has been called), since I
> don't know if the mapping driver is bidirectional.
> >
> > I know this probably stems from my ignorance on the subject - I had
> unfortunately very little time to catch-up with this effort in the past
> months.
> >
> > Salvatore
> >
> >
> > On 8 August 2014 18:49, Ivar Lazzaro <ivarlazzaro at gmail.com> wrote:
> > Hi Jay,
> >
> > You can choose. The whole purpose of this is about flexibility, if you
> want to use GBP API 'only' with a specific driver you just can.
> > Additionally, given the 'ML2 like' architecture, the reference mapping
> driver can ideally run alongside by filling the core Neutron constructs
> without ever 'disturbing' your own driver (I'm not entirely sure about this
> but it seems feasible).
> >
> > I hope this answers your question,
> > Ivar.
> >
> >
> > On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> > On 08/08/2014 08:55 AM, Kevin Benton wrote:
> > The existing constructs will not change.
> >
> > A followup question on the above...
> >
> > If GPB API is merged into Neutron, the next logical steps (from what I
> can tell) will be to add drivers that handle policy-based payloads/requests.
> >
> > Some of these drivers, AFAICT, will *not* be deconstructing these policy
> requests into the low-level port, network, and subnet
> creation/attachment/detachment commands, but instead will be calling out
> as-is to hardware that speaks the higher-level abstraction API [1], not the
> lower-level port/subnet/network APIs. The low-level APIs would essentially
> be consumed entirely within the policy-based driver, which would
> effectively mean that the only way a system would be able to orchestrate
> networking in systems using these drivers would be via the high-level
> policy API.
> >
> > Is that correct? Very sorry if I haven't explained clearly my
> question... this is a tough question to frame eloquently :(
> >
> > Thanks,
> > -jay
> >
> > [1]
> http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html
> >
> > On Aug 8, 2014 9:49 AM, "CARVER, PAUL" <pc2929 at att.com
> > <mailto:pc2929 at att.com>> wrote:
> >
> >     Wuhongning [mailto:wuhongning at huawei.com
> >     <mailto:wuhongning at huawei.com>] wrote:
> >
> >      >Does it make sense to move all advanced extension out of ML2, like
> >     security
> >      >group, qos...? Then we can just talk about advanced service
> >     itself, without
> >      >bothering basic neutron object (network/subnet/port)
> >
> >     A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I
> >     still
> >     think it's too late in the game to be shooting down all the work
> >     that the
> >     GBP team has put in unless there's a really clean and effective way
> of
> >     running AND iterating on GBP in conjunction with Neutron without
> being
> >     part of the Juno release. As far as I can tell they've worked really
> >     hard to follow the process and accommodate input. They shouldn't have
> >     to wait multiple more releases on a hypothetical refactoring of how
> >     L3+ vs
> >     L2 is structured.
> >
> >     But, just so I'm not making a horrible mistake, can someone reassure
> me
> >     that GBP isn't removing the constructs of network/subnet/port from
> >     Neutron?
> >
> >     I'm under the impression that GBP is adding a higher level
> abstraction
> >     but that it's not ripping basic constructs like network/subnet/port
> out
> >     of the existing API. If I'm wrong about that I'll have to change my
> >     opinion. We need those fundamental networking constructs to be
> present
> >     and accessible to users that want/need to deal with them. I'm viewing
> >     GBP as just a higher level abstraction over the top.
> >
> >
> >     _______________________________________________
> >     OpenStack-dev mailing list
> >     OpenStack-dev at lists.openstack.org
> >     <mailto:OpenStack-dev at lists.openstack.org>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Kevin Benton
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140808/2620b6a0/attachment.html>