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" <jaypi...@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 <jaypi...@gmail.com >> <mailto:jaypi...@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 >> <sumitnaiksa...@gmail.com <mailto:sumitnaiksa...@gmail.com> >> <mailto:sumitnaiksatam@gmail.__com >> <mailto:sumitnaiksa...@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 >> <blak...@gmail.com <mailto:blak...@gmail.com> >> <mailto:blak...@gmail.com <mailto:blak...@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 >> <jaypi...@gmail.com <mailto:jaypi...@gmail.com> >> <mailto:jaypi...@gmail.com <mailto:jaypi...@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@lists.openstack.__org >> <mailto:OpenStack-dev@lists.openstack.org> >> <mailto:OpenStack-dev@lists.__openstack.org >> <mailto: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 >> <mailto:OpenStack-dev@lists.openstack.org> >> <mailto:OpenStack-dev@lists.__openstack.org >> <mailto: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 >> <mailto:OpenStack-dev@lists.openstack.org> >> <mailto:OpenStack-dev@lists.__openstack.org >> <mailto: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 >> <mailto: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 >> <mailto: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://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
