Open Stack

On Tue, Aug 5, 2014 at 1:41 PM, Jay Pipes <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.
>

Yes, listening, absolutely. I acknowledged your point in this thread
as well as on the review. Your suggestion on the thread seemed to be
to document this better and clarify. Is that sufficient for moving
forward, or are you thinking something else?

> 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.
>

Couple of things -

The "endpoint", as is being used in this context, does not refer to
the "template" that you are referring to (if I understand you
correctly). The template in some ways is analogous to the "endpoint
group" (or EPG), and is defined as a collection of endpoints. Kevin,
Stephen, and I, have been alluding to that in this thread earlier.

Why "endpoint"? The thinking, among the people discussing this, was
that it needs to be something more abstract than the very specific
network "port" terminology, and something with which can associate
policies and labels/tags. I am not advocating that this is the perfect
naming convention, and I do appreciate the concern that there is
overlap with an endpoint being used in a different context elsewhere
in OpenStack. This overlap however escaped everybody's attention until
it manifested in the code and your review (after having gone through
review in two design summit sessions and being in discussion over
several months).

> 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>> 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>> 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>> 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>
>>
>>      >> 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>
>>
>>      > 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
>>
>>
>>
>>
>> _______________________________________________
>> 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