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
