Open Stack

On 14 November 2013 23:03, Steven Weston <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.


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



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


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

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.

> Thoughts?  Ideas?  Criticisms?  Complements?  J
>
> Steven
>
> -------- Original message --------
> From: Salvatore Orlando <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>
> 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> 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]
> *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> 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> 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
> 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
>
>
>
> _______________________________________________
> 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/20131115/93774fb6/attachment.html>