<div dir="ltr">Hi,<div><br></div><div>this discussion came up recently regarding a nodepool issue.</div><div>The blueprint was recently revived and there is a proposed specification [1]</div><div><br></div><div>I tend to disagree with the way nova implements this feature today.</div>
<div>A configuration-wide flag indeed has the downside that this creates different API behaviour across deployments.</div><div>As an API consumer which wants a public IP for an instance, I would probably have to check if such IP is already available before allocating, which, by the way, it's what nodepool does [2].</div>
<div><br></div><div>The specification [1] tries to make this clearer to user allowing control of this behaviour on a per-subnet basis. This is not bad, but I still think it's not a great idea to introduce side effect in neutron API (in this case port create). Personally I think from the neutron side we can make user's life easier by tying a floating IP lifecycle to the port it is associated with, so that when the port is deleted, the floating IP is not just disassociated but removed too. This won't give the same ease of use which nova achieves today with auto_assign_floating_ips but will still be a better level of automation without adding orchestration on the neutron side.</div>
<div><br></div><div>I've not yet made up my mind on this topic, but if you have any opinion, please share it.</div><div><br></div><div>Salvatore</div><div><br></div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/106487/">https://review.openstack.org/#/c/106487/</a></div>
<div>[2] <a href="http://git.openstack.org/cgit/openstack-infra/nodepool/tree/nodepool/nodepool.py#n398">http://git.openstack.org/cgit/openstack-infra/nodepool/tree/nodepool/nodepool.py#n398</a></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 17 November 2013 01:08, Steven Weston <span dir="ltr"><<a href="mailto:steven-weston@live.com" target="_blank">steven-weston@live.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Salvatore!<br>
<br>
My responses (to your responses) are in-line. I think we could also
use some feedback from the rest of the community on this, as well …
would it be a good idea to discuss the implementation further at the
next IRC meeting?<br>
<br>
Good Stuff!!<br>
<br>
Steven<div class=""><br>
<br>
<div>On 11/15/2013 7:39 AM, Salvatore
Orlando wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 14 November 2013 23:03, Steven
Weston <span dir="ltr"><<a href="mailto:steven-weston@live.com" target="_blank">steven-weston@live.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi
Salvatore,</span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">My
Launchpad ID is steven-weston. I do not know who
those other Steven Westons are … if someone has
created clones of me, I am going to be upset!
Anyway, Here are my thoughts on the implementation
approach.</span></p>
</div>
</div>
</blockquote>
<div>I have now assigned the blueprint to you.</div>
<div> </div>
</div>
</div>
</div>
</blockquote></div>
Great, thank you! <br><div class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">
<span style="color:#1f497d">Is there any reason why
the two alternatives you listed should be
considered mutually exclusive? </span></p>
</div>
</div>
</blockquote>
<div>In line of principle they're not. But if we provide the
facility in Neutron, doing the orchestration from nova for
the association would be, in my opinion, just redundant.</div>
<div>Unless I am not understanding what you suggest.</div>
</div>
</div>
</div>
</blockquote>
<br></div>
I agree, implementing the functionality in nova and neutron would be
redundant, although I was suggesting that the nova api be modified
to allow for the auto association request on vm creation, which
would then be passed to neutron for the port creation. Currently it
looks to only be available as a configuration option in nova.<div class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>So far I understand the goal is to pass a
'autoassociate_fip' flag (or something similar) to POST
/v2/port<br>
</div>
<div>the operation will create two resource: a floating IP
and a port, with only the port being returned (hence the
side-effect).</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
This sounds good, unless we want to modify the api behavior to
return a list of floating ips, as you already suggested below. Or
would it be better to return a mapping of fixed ips to floating ips,
since that would technically be more accurate?<div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">
<span style="color:#1f497d">I think that in
consideration of loosely coupled design, it would
be best to make the attribute addition to the port
in neutron and create the ability for nova to
orchestrate the call as well. I do not see a way
to prevent modification of the REST API, and in
the interest of fulfilling your concern of
atomicity, the fact that an auto association was
requested will need to be stored somewhere, in
addition to the state of the request as well. </span></p>
</div>
</div>
</blockquote>
<div>Storing the autoassociation could be achieved with a
flag on the floating IP data model. But would that also
imply that the association for an auto-associate
floatingIP cannot be altered?</div>
<div> </div>
</div>
</div>
</div>
</blockquote></div>
I think that depends on how we want it to work … see my comments
below.<div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#1f497d">Plus, tracking the attribute
in neutron would allow the ability of other events
to fire that would need to be performed in
response to an auto associate request, such as
split zone dns updates (for example). The primary
use case for this would be for request by nova,
although I can think of other services which could
use it as well -- load balancers, firewalls,
vpn’s, and any component that would require
connectivity to another network. I think the
default behavior of the auto association request
would be to create ip addresses on the associated
networks of the attached routers, unless a
specific network is given.</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Perhaps I need more info on this specific point; I
think the current floating_port_id - port_id might work to
this aim; perhaps the reverse mapping would be needed to,
and we might work to add id - but I don't see why we would
need a 'auto_associate' flag. This is not a criticism.
It's just me being dumb perhaps!</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote></div>
This one is my fault, I should have been more clear as to what I was
thinking ... the purpose of the flag would be to provide some sort
of state that a floating ip was allocated as the result of an
auto-association .. not necessarily for consumption by neutron, but
for other "services" that might want to use the information. I do
see a reason to store it for Neutron's usage as well, but I guess
that would depend on whether the behavior of an auto associated
floating ip address would be different than a normal, independently
associated floating ip address. Which brings up a few good
implementation questions. 1. Should the mapping between the
floating and fixed be immutable? 2. When the port is deleted,
should the floating ip address be removed as well? 3. What about
in the reverse situation, should deletion of the floating ip
address be denied until the port no longer exists? Depending on
what your answers are to these questions, then IMHO I would suggest
possibly adding an "is_auto_associated" flag to the floating ip data
model, as you alluded to above. <br>
<br>
I apologize if these situations are already addressed in Neutron …
if they are, I couldn’t find them … I believe they are currently
handled by nova. If I am incorrect on this, please point me in the
right direction!<div class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>To conclude I think it might be actually not bad at all
to allow for specifying a floating_ip_id when creating a
port.</div>
<div>This way if we add the ability to auto create and
associate a floating ip on port create, this might
partially solve the side effect problem as you'll get the
floating ip ID as well in the response.</div>
</div>
</div>
</div>
</blockquote></div>
Or would it be feasible to add the floating ip information directly
to the port attributes, and then modify the behavior of the REST API
to return the allocations as part of the response, like the fixed
ips are. <br><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#1f497d"></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thoughts?
Ideas? Criticisms? Complements? </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
<span></span></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span><font color="#888888"><span style="color:#1f497d">Steven</span></font></span></p>
<div>
<div><br>
-------- Original message --------<br>
From: Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> <br>
Date: 11/14/2013 4:23 AM (GMT-07:00) <br>
To: "OpenStack Development Mailing List (not for
usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>
<br>
Subject: Re: [openstack-dev] [Neutron] Blueprint
-- Floating IP Auto Association <br>
<br>
<b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span></b></div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi Steven, </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I see three Steven
Weston on Launchpad. If you give me your
LP ID, I will assign the blueprint to you.</p>
</div>
<div>
<p class="MsoNormal">This is a nova parity
item and i'd like to raise the priority to
High.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">It would be also good
to hear from you about the implementation
approach.</p>
</div>
<div>
<p class="MsoNormal">In the past we debated
two alternatives: passing a special
attribute to a port in order to create a
floating IP for it too, or orchestrating
the operation from the nova side.</p>
</div>
<div>
<p class="MsoNormal">The first option has
the cons of adding a side effect to a REST
API call (which is not advisable), and
might be a bit complex when the network
where the port is on is attached to
multiple routers.</p>
</div>
<div>
<p class="MsoNormal">The latter option has
the cons of requiring two neutron API
calls.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">The input of the whole
community on this topic will be very
appreciated.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Salvatore</p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal">
On 14 November 2013 05:47, Steven Weston
<<a href="mailto:steven-weston@live.com" target="_blank">steven-weston@live.com</a>>
wrote:</p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks
for the responses on this. I
definitely still interested in
implementing the functionality
described in this blueprint, but
have been reluctant to start on it
since I did not get a response.</span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Yes,
please assign it to me and I will
get started on it right away! I
do not seem to have the capability
to assign it to myself.</span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Steven</span></p>
<p><a name="1426365a4a889ecd_14258a5e8bcbca57_x_1425527a0e78f4ec__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></a></p>
<p><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
Jaume Devesa [mailto:<a href="mailto:devvesa@gmail.com" target="_blank">devvesa@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, November
13, 2013 10:32 PM<br>
<b>To:</b> OpenStack Development
Mailing List (not for usage
questions)<br>
<b>Subject:</b> Re:
[openstack-dev] [Neutron]
Blueprint -- Floating IP Auto
Association</span></p>
<div>
<div>
<p> </p>
<div>
<div>
<div>
<div>
<p style="margin-bottom:12.0pt">Hi
all,</p>
</div>
<p style="margin-bottom:12.0pt">I
see it has been passed two
weeks since first mail in
this thread and that
blueprint still without
assignee. I also think
this is a good option for
my first blueprint.
However, I can not assign
blueprints to myself, only
bugs. Can anybody assign
to me?</p>
</div>
<p style="margin-bottom:12.0pt">Steven:
if you still interested in
it, please tell us. You
asked for it first and it
will be yours.</p>
</div>
<p>Regards</p>
</div>
<div>
<p style="margin-bottom:12.0pt">
</p>
<div>
<p>On 5 November 2013 07:21,
Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>>
wrote:</p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p>I don't think there has
been any development in
the past 6 months.</p>
<div>
<p>A few people have
shown interest in it
in the past, but the
blueprint has
currently no assignee.</p>
</div>
<div>
<p>So If you want to
work on it, feel free
to assign to yourself.</p>
</div>
<div>
<p> </p>
</div>
<div>
<p>To quickly sum up the
discussion around this
blueprint, it could be
implemented in two
ways:</p>
</div>
<div>
<p>- providing
automation in the
neutron API (creating
the floating IP
together with the
port)</p>
</div>
<div>
<p>- automating the
operation on the
orchestration side
(nova-api in this
case).</p>
</div>
<div>
<p> </p>
</div>
<div>
<p>There are pro and
cons in both
solutions. In my
humble opinion, the
only thing I would
care of is that the
existing operation in
the Neutron API stay
"atomic" as they are.</p>
</div>
<div>
<p> </p>
</div>
<div>
<p>Regards,</p>
</div>
<div>
<p>Salvatore</p>
</div>
</div>
<div>
<p style="margin-bottom:12.0pt"> </p>
<div>
<div>
<div>
<p>On 30 October
2013 08:46, Steven
Weston <<a href="mailto:steven-weston@live.com" target="_blank">steven-weston@live.com</a>>
wrote:</p>
</div>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p>Does
anybody know
what the
status of this
Blueprint is?
<a href="https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip" target="_blank">https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip</a></p>
<p> </p>
<p>I am new to
the neutron
developer
community and
I am looking
for a first
project – this
might be a
good place to
start. But
the last
update was in
March of this
year, so I
don’t know if
the
specifications
have been
locked down
yet. </p>
<p> </p>
<p>Anybody?</p>
<p> </p>
<p>Thanks!</p>
<p><span style="color:#888888">Steven
Weston</span></p>
</div>
</div>
<p> </p>
</div>
</div>
<p style="margin-bottom:12.0pt">
_______________________________________________<br>
OpenStack-dev
mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p>
</blockquote>
</div>
<p> </p>
</div>
<p style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p>
</blockquote>
</div>
<p> </p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>