[openstack-dev] [Neutron] Group Based Policy and the way forward
Kevin Benton
blak111 at gmail.com
Tue Aug 5 22:13:20 UTC 2014
That makes sense. It's not quite a fair analogy though to compare to
reintroducing projects or tenants because Keystone endpoints aren't
'user-facing' so to speak. i.e. a regular user (application deployer,
instance operator, etc) should never have to see or understand the purpose
of a Keystone endpoint.
On Aug 5, 2014 3:53 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
> On 08/05/2014 05:22 PM, Kevin Benton wrote:
>
>> >Is anyone listening to what I'm saying? The term "endpoint" is obtuse
>> and completely disregards the existing denotation of the word "endpoint"
>> in use in OpenStack today.
>>
>> Sorry, I didn't understand the confusion because you didn't provide a
>> reference to how "endpoint" is used in OpenStack now. I hadn't heard the
>> term until this GBP work other than keystone endpoints, which have no
>> overlap with this. Can you provide the definition you are familiar with
>> so someone can explain the difference?
>>
>
> Yes, a Keystone endpoint, which exists in the service catalog that every
> single token sent to and from any OpenStack service.
>
> You are correct that there is no overlap with the GBP concept of endpoint.
> But, I guess I'm surprised nobody brought this up when discussing the
> proposed GBP API extensions to Neutron... since the endpoint has been a
> part of the Keystone service catalog API for years.
>
> It would be like if the GBP API came up with a new resource called
> "project" or "tenant" and expected everyone to just understand that this
> new "project" resource had nothing to do with the project concept that is
> used throughout the other APIs...
>
> Anyway, sorry if I'm just blowing off some steam here... it's my fault for
> not paying more attention to this earlier on. But this point goes directly
> to the discussion that Mark McClain and Bob were having about whether to
> let an major API extension like this bake somewhere outside of Neutron vs.
> baking inside Neutron ala VPNaaS, LBaaS, etc.
>
> OK, steam has been blown off, sorry for the partially tangential thread.
>
> -jay
>
>
> On Tue, Aug 5, 2014 at 2:41 PM, Jay Pipes <jaypipes at gmail.com
>> <mailto:jaypipes at gmail.com>> wrote:
>>
>> On 08/05/2014 04:26 PM, Stephen Wong wrote:
>>
>> Agreed with Kevin and Sumit here. As a subgroup we talked about
>> Nova
>> integration, and the preliminary idea, as Bob alluded to, is to
>> add
>> "endpoint" as an option in place of Neutron port. But if we can
>> make
>> Nova EPG-aware, it would be great.
>>
>>
>> Is anyone listening to what I'm saying? The term "endpoint" is
>> obtuse and completely disregards the existing denotation of the word
>> "endpoint" in use in OpenStack today.
>>
>> So, we've gone ahead and replaced the term "port" in the caller
>> interface -- which, besides being too entirely too low-level,
>> actually did describe what the object was -- to using a term
>> "endpoint" that doesn't describe even remotely what the thing is (a
>> template for a collection of networking-related policies and
>> objects) and that already has a well-known definition in the
>> OpenStack ecosystem.
>>
>> That is my point. That is why I brought up the comment on the
>> original patch in the series that some docstrings would be helpful
>> for those not entirely subscribed to the Tenets of National
>> Dvorkinism.
>>
>> These interfaces should speak plain old concepts, not networking
>> guru arcanum.
>>
>> Best,
>> -jay
>>
>> On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
>> <sumitnaiksatam at gmail.com <mailto:sumitnaiksatam at gmail.com>
>> <mailto:sumitnaiksatam at gmail.__com
>> <mailto:sumitnaiksatam at gmail.com>>> wrote:
>>
>> That's right Kevin, EPG (and its association to the
>> L2/3_Policy)
>> capture the attributes which would represent the
>> "network-template"
>> being referenced here.
>>
>> Jay, what Bob mentioned here was an option to use the
>> "endpoint" as a
>> one-to-one replacement for the option of using a Neutron
>> port. This is
>> more so in the context of providing an evolutionary path
>> (from the way
>> Nova currently does it using a pre-defined port). However,
>> if it makes
>> sense to make Nova aware of the EPG right at the outset,
>> then that is
>> even better.
>>
>> I have also noted your suggestion on clarifying the
>> "endpoint"
>> terminology. This was already done in one of the patches
>> you had
>> reviewed earlier, and will do that in the first patch as
>> well (where
>> you pointed it out now).
>>
>> Thanks,
>> ~Sumit.
>>
>> On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton
>> <blak111 at gmail.com <mailto:blak111 at gmail.com>
>> <mailto:blak111 at gmail.com <mailto:blak111 at gmail.com>>>
>> wrote:
>> > Specifying an endpoint group would achieve the
>> --networking-template effects
>> > you described. The endpoint group would have all of the
>> security
>> policies,
>> > IP allocation policies, connectivity policies, etc.
>> already setup.
>> >
>> >
>> > On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes
>> <jaypipes at gmail.com <mailto:jaypipes at gmail.com>
>> <mailto:jaypipes at gmail.com <mailto:jaypipes at gmail.com>>>
>> wrote:
>> >>
>> >> On 08/05/2014 01:13 PM, Robert Kukura wrote:
>> >>>
>> >>>
>> >>> On 8/5/14, 11:04 AM, Gary Kotton wrote:
>> >>>>
>> >>>> Hi,
>> >>>> Is there any description of how this will be consumed
>> by Nova. My
>> >>>> concern is this code landing there.
>> >>>
>> >>> Hi Gary,
>> >>>
>> >>> Initially, an endpoint's port_id is passed to Nova
>> using "nova
>> boot ...
>> >>> --nic port-id=<port-uuid> ...", requiring no changes
>> to Nova.
>> Later,
>> >>> slight enhancements to Nova would allow using commands
>> such as
>> "nova
>> >>> boot ... --nic ep-id=<endpoint-uuid> ..." or "nova
>> boot ... --nic
>> >>> epg-id=<endpoint-group-uuid> ...".
>> >>
>> >>
>> >> Hi Bob,
>> >>
>> >> How exactly is the above a friendlier API for the main
>> user of
>> Neutron,
>> >> which is Nova? I thought one of the main ideas behind
>> the GBP
>> stuff was to
>> >> create a more declarative and intuitive API for users
>> of Neutron
>> -- i.e.
>> >> Nova -- to use in constructing needed networking
>> objects. The
>> above just
>> >> seems to me to be exchanging one low-level object
>> (port) with
>> another
>> >> low-level object (endpoint or endpoint group)?
>> >>
>> >> Perhaps the disconnect is due to the term "endpoint"
>> being used,
>> which,
>> >> everywhere else in the OpenStack universe, means
>> something entirely
>> >> different from GBP.
>> >>
>> >> I guess, based on my understanding of the *intent* of
>> the GBP
>> API, I would
>> >> have expected an API more like:
>> >>
>> >> nova boot ... --networking-template <UUID>
>> >>
>> >> where --networking-template would refer to a network,
>> subnet
>> topology, IP
>> >> assignment policy, collection of security groups and
>> firewall
>> policies that
>> >> the tenant had established prior to booting an
>> instance...
>> thereby making
>> >> the API more intuitive and less cluttered.
>> >>
>> >> Or is it that I just don't understand this new "endpoint"
>> terminology?
>> >>
>> >> Best,
>> >> -jay
>> >>
>> >>
>> >> _________________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.__org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> <mailto:OpenStack-dev at lists.__openstack.org
>> <mailto:OpenStack-dev at 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 at lists.openstack.__org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> <mailto:OpenStack-dev at lists.__openstack.org
>> <mailto:OpenStack-dev at 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 at lists.openstack.__org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> <mailto:OpenStack-dev at lists.__openstack.org
>> <mailto:OpenStack-dev at 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 at lists.openstack.__org
>> <mailto:OpenStack-dev at 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 at lists.openstack.__org
>> <mailto:OpenStack-dev at 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 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/20140805/0e5c62c8/attachment.html>
More information about the OpenStack-dev
mailing list