[openstack-dev] [Neutron] Blueprint -- Floating IP Auto Association
Steven Weston
steven-weston at live.com
Sun Nov 17 00:08:14 UTC 2013
Hi Salvatore!
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?
Good Stuff!!
Steven
On 11/15/2013 7:39 AM, Salvatore Orlando wrote:
>
>
>
> On 14 November 2013 23:03, Steven Weston <steven-weston at live.com
> <mailto:steven-weston at live.com>> wrote:
>
> Hi Salvatore,
>
> 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.
>
> I have now assigned the blueprint to you.
Great, thank you!
>
> Is there any reason why the two alternatives you listed should be
> considered mutually exclusive?
>
> 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.
> Unless I am not understanding what you suggest.
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.
> So far I understand the goal is to pass a 'autoassociate_fip' flag (or
> something similar) to POST /v2/port
> the operation will create two resource: a floating IP and a port, with
> only the port being returned (hence the side-effect).
>
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?
>
> 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.
>
> 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?
I think that depends on how we want it to work ... see my comments below.
>
> 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.
>
>
> 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!
>
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.
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!
> To conclude I think it might be actually not bad at all to allow for
> specifying a floating_ip_id when creating a port.
> 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.
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.
>
> Thoughts? Ideas? Criticisms? Complements? J
>
> Steven
>
>
> -------- Original message --------
> From: Salvatore Orlando <sorlando at nicira.com
> <mailto:sorlando at nicira.com>>
> Date: 11/14/2013 4:23 AM (GMT-07:00)
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [Neutron] Blueprint -- Floating IP
> Auto Association
>
> **
>
> Hi Steven,
>
> I see three Steven Weston on Launchpad. If you give me your LP ID,
> I will assign the blueprint to you.
>
> This is a nova parity item and i'd like to raise the priority to High.
>
> It would be also good to hear from you about the implementation
> approach.
>
> 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.
>
> 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.
>
> The latter option has the cons of requiring two neutron API calls.
>
> The input of the whole community on this topic will be very
> appreciated.
>
> Salvatore
>
> On 14 November 2013 05:47, Steven Weston <steven-weston at live.com
> <mailto:steven-weston at live.com>> wrote:
>
> 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.
>
> 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.
>
> Steven
>
> *From:*Jaume Devesa [mailto:devvesa at gmail.com
> <mailto:devvesa at gmail.com>]
> *Sent:* Wednesday, November 13, 2013 10:32 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] Blueprint -- Floating
> IP Auto Association
>
> Hi all,
>
> 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?
>
> Steven: if you still interested in it, please tell us. You
> asked for it first and it will be yours.
>
> Regards
>
> On 5 November 2013 07:21, Salvatore Orlando
> <sorlando at nicira.com <mailto:sorlando at nicira.com>> wrote:
>
> I don't think there has been any development in the past 6
> months.
>
> A few people have shown interest in it in the past, but
> the blueprint has currently no assignee.
>
> So If you want to work on it, feel free to assign to yourself.
>
> To quickly sum up the discussion around this blueprint, it
> could be implemented in two ways:
>
> - providing automation in the neutron API (creating the
> floating IP together with the port)
>
> - automating the operation on the orchestration side
> (nova-api in this case).
>
> 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.
>
> Regards,
>
> Salvatore
>
> On 30 October 2013 08:46, Steven Weston
> <steven-weston at live.com <mailto:steven-weston at live.com>>
> wrote:
>
> Does anybody know what the status of this Blueprint
> is?
> https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip
>
> 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.
>
> Anybody?
>
> Thanks!
>
> Steven Weston
>
> _______________________________________________
> 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
> <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131116/23c17689/attachment.html>
More information about the OpenStack-dev
mailing list