openstack team mailing list archive

["Mark Washenberger" <mark.washenberger@xxxxxxxxxxxxx>]

Perhaps I misunderstood. I thought option #3 consisted of adding new http resources to the openstack api to expose the add/allocate/associate/etc floating ip functionality to the api consumer.
 
If that is the case, I believe it would be a break with the cloud servers 1.0 api, where a customer would expect to get a public ip for free when they create an instance.
 
"Jesse Andrews" <anotherjesse@xxxxxxxxx> said:

I like the simple solution (#3) as well.
It gets parity for the APIs while leaving more advanced topics for the NaaS discussions.




-- Sent from my Tandy 1000sx
Jesse Andrews
[mailto:anotherjesse@xxxxxxxxx] anotherjesse@xxxxxxxxx


On Apr 18, 2011, at 11:36 AM, Trey Morris wrote:
Appears my response got lost somehow. I vote for #3 as it's the most configurable (and affects nothing contrariwise). In addition to believing we use flags too often, I don't think having a flag solves the problem very well. A couple of examples show why:
you want a few instances having floating IP(s) while others do not
you want multiple floating IPs for an instance

-tr3buchet


On Mon, Apr 18, 2011 at 6:15 AM, Ilya Alekseyev <[mailto:ilyaalekseyev@xxxxxxx] ilyaalekseyev@xxxxxxx> wrote:

Mark,

approach #1 implementation is here: [https://code.launchpad.net/%7Eopenstack-gd/nova/auto-float-ip] https://code.launchpad.net/~openstack-gd/nova/auto-float-ip. I saw that you interested in approach #3 too. May be you have some ideas of specification of API for approach #3?
 
Erik,
there is implementation of floating ips in Nova. In implementation of approach #1 we just care about auto assigning/deassigning. As I know floating ip implemented like NAT from network nodes.






2011/4/17 Mark Washenberger <[mailto:mark.washenberger@xxxxxxxxxxxxx] mark.washenberger@xxxxxxxxxxxxx>

Eldar,

I'm having some trouble finding the diff for your implementation of approach #1. Any chance you can share it on the list?

Thanks

"Erik Carlin" <[mailto:erik.carlin@xxxxxxxxxxxxx] erik.carlin@xxxxxxxxxxxxx> said:

> Cool.  Got it.  Floating IPs or what Amazon calls Elastic IPs.  How are you
 > solving the cross L2 problem?
> 
> Erik
> 
> Sent from my iPhone
>> On Apr 15, 2011, at 7:28 PM, "Eldar Nugaev" <[mailto:enugaev@xxxxxxxxxxxxxxxx] enugaev@xxxxxxxxxxxxxxxx>


> wrote:
> 
> > Hi Erik
> >
> > Thank you for response!
> > Yes, you are absolutely right OpenStack API already support shared IP
> groups.
 > > Suppose there are some misunderstanding, because I wrote about floating IPs.
> >
> > I want to have API for association IPs from floating IPs pool with
> > particular VM.
> >
 > > At this moment we have #1 implementation as a path in our RPM repo
> > [http://yum.griddynamics.net/] http://yum.griddynamics.net/. And going to make the merge proposal to
 > > trunk.
> >
> > Also we going to create blueprint about #3 and attach branch to it.
> >
> > Eldar
> >
> > On Sat, Apr 16, 2011 at 2:34 AM, Erik Carlin
> <[mailto:erik.carlin@xxxxxxxxxxxxx] erik.carlin@xxxxxxxxxxxxx> wrote:
 > >> Eldar -
> >>
> >> The OpenStack API already supports sharing IPs between instances
> (although
> >> this may be an extension?).  What exact behavior are you after?  More
 > >> important than the way in which we expose via the API is how it's
> >> implemented.  It's important to note that this is extremely network
> >> topology dependent.  Sharing IPs today requires L2 adjacency so other
 > VMs
> >> can GARP for the IP.  L2 doesn't work at scale so you need another
> >> mechanism.  I'm pretty sure the way AWS does it is to have a separate
> pool
> >> of IPs and inject /32 routes higher up that route towards the
 > appropriate
> >> VM IP.  What are your thoughts around how this would be implemented?
> >>
> >> Multiple people are working towards an independent Network as a Service
> >> external to nova so it may make sense to plug this requirement in there.
 > >>
> >> Erik
> >>
> >> On 4/11/11 8:31 AM, "Eldar Nugaev" <[mailto:enugaev@xxxxxxxxxxxxxxxx] enugaev@xxxxxxxxxxxxxxxx>
> wrote:
 > >>
> >>> Hello everyone,
> >>>
> >>> We going to add possibility to assigning floating IP addresses in
> >>> OpenStack API.
> >>> Our goal reproduce AWS behavior when creating instance automatically
 > >>> assigns any free floating IP or add methods to OpenStack API for
> >>> allocation and association API addresses.
> >>>
> >>> At this time we see three way:
 > >>>
> >>> 1. FLAG --auto_assign_floating_ip (default=False)
> >>> 2. Optional parameter "auto_assign_floating_ip" in existing "create"
> >>> method
 > >>> 3. OpenStack API add floating_ip - allocate_floating_ip,
> >>> associate_floating_ip
> >>>
> >>> What way is more suitable at this time?
> >>>
 > >>> --
> >>> Eldar
> >>> Skype: eldar.nugaev
> >>>
> >>> _______________________________________________
> >>> Mailing list: [https://launchpad.net/%7Eopenstack] https://launchpad.net/~openstack
 > >>> Post to     : [mailto:openstack@xxxxxxxxxxxxxxxxxxx] openstack@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : [https://launchpad.net/%7Eopenstack] https://launchpad.net/~openstack
 > >>> More help   : [https://help.launchpad.net/ListHelp] https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >> Confidentiality Notice: This e-mail message (including any attached or
 > >> embedded documents) is intended for the exclusive and confidential use of
> the
> >> individual or entity to which this message is addressed, and unless
> otherwise
> >> expressly indicated, is confidential and privileged information of
 > Rackspace.
> >> Any dissemination, distribution or copying of the enclosed material is
> prohibited.
> >> If you receive this transmission in error, please notify us immediately
> by e-mail
 > >> at [mailto:abuse@xxxxxxxxxxxxx] abuse@xxxxxxxxxxxxx, and delete the original message.
> >> Your cooperation is appreciated.
> >>
> >>
> >
 > >
> >
> > --
> > Eldar
> > Skype: eldar.nugaev
> 
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
 > individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is
 > prohibited.
> If you receive this transmission in error, please notify us immediately by e-mail
> at [mailto:abuse@xxxxxxxxxxxxx] abuse@xxxxxxxxxxxxx, and delete the original message.
 > Your cooperation is appreciated.
> 
> 
> _______________________________________________
> Mailing list: [https://launchpad.net/%7Eopenstack] https://launchpad.net/~openstack
 > Post to     : [mailto:openstack@xxxxxxxxxxxxxxxxxxx] openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : [https://launchpad.net/%7Eopenstack] https://launchpad.net/~openstack
 > More help   : [https://help.launchpad.net/ListHelp] https://help.launchpad.net/ListHelp
>
_______________________________________________
 Mailing list: [https://launchpad.net/%7Eopenstack] https://launchpad.net/~openstack
 Post to     : [mailto:openstack@xxxxxxxxxxxxxxxxxxx] openstack@xxxxxxxxxxxxxxxxxxx
 Unsubscribe : [https://launchpad.net/%7Eopenstack] https://launchpad.net/~openstack
 More help   : [https://help.launchpad.net/ListHelp] https://help.launchpad.net/ListHelp
 

 
_______________________________________________
 Mailing list: [https://launchpad.net/~openstack] https://launchpad.net/~openstack
 Post to     : [mailto:openstack@xxxxxxxxxxxxxxxxxxx] openstack@xxxxxxxxxxxxxxxxxxx
 Unsubscribe : [https://launchpad.net/~openstack] https://launchpad.net/~openstack
 More help   : [https://help.launchpad.net/ListHelp] https://help.launchpad.net/ListHelp
 
_______________________________________________
Mailing list: [https://launchpad.net/~openstack] https://launchpad.net/~openstack
Post to     : [mailto:openstack@xxxxxxxxxxxxxxxxxxx] openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : [https://launchpad.net/~openstack] https://launchpad.net/~openstack
More help   : [https://help.launchpad.net/ListHelp] https://help.launchpad.net/ListHelp