On 14 November 2013 23:03, Steven Weston <steven-wes...@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 <sorla...@nicira.com> > Date: 11/14/2013 4:23 AM (GMT-07:00) > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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-wes...@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:devv...@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 <sorla...@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-wes...@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@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 > > > > _______________________________________________ > 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