Kevin , this can be one approach but not sure. But certainly won't solve all cases. :)
On Thu, Apr 17, 2014 at 10:33 AM, Kevin Benton <blak...@gmail.com> wrote: > Yeah, I was aware of allowed address pairs, but that doesn't help with the > IP allocation part. > > Is this the tenant workflow for this use case? > > 1. Create an instance. > 2. Wait to see what which subnet it gets an allocation from. > 3. Pick an IP from that subnet that doesn't currently appear to be in use. > 4. Use the neutron-cli or API to update the port object with the extra IP. > 5. Hope that Neutron will never allocate that IP address for something > else. > > > On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen <aaronoro...@gmail.com>wrote: > >> Whoops Akihiro beat me to it :) >> >> >> On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen <aaronoro...@gmail.com>wrote: >> >>> The allowed-address-pair extension that was added here ( >>> https://review.openstack.org/#/c/38230/) allows us to add arbitrary ips >>> to an interface to allow them. This is useful if you want to run something >>> like VRRP between two instances. >>> >>> >>> On Wed, Apr 16, 2014 at 9:39 PM, Kevin Benton <blak...@gmail.com> wrote: >>> >>>> I was under the impression that the security group rules blocked >>>> addresses not assigned by neutron[1]. >>>> >>>> 1. >>>> https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L188 >>>> >>>> >>>> On Wed, Apr 16, 2014 at 9:20 PM, Aaron Rosen <aaronoro...@gmail.com>wrote: >>>> >>>>> You can do it with ip aliasing and use one interface: >>>>> >>>>> ifconfig eth0 10.0.0.22/24 >>>>> ifconfig eth0:1 10.0.0.23/24 >>>>> ifconfig eth0:2 10.0.0.24/24 >>>>> >>>>> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state >>>>> DOWN qlen 1000 >>>>> link/ether 40:6c:8f:1a:a9:31 brd ff:ff:ff:ff:ff:ff >>>>> inet 10.0.0.22/24 brd 10.0.0.255 scope global eth0 >>>>> valid_lft forever preferred_lft forever >>>>> inet 10.0.0.23/24 brd 10.0.0.255 scope global secondary eth0:1 >>>>> valid_lft forever preferred_lft forever >>>>> inet 10.0.0.24/24 brd 10.0.0.255 scope global secondary eth0:2 >>>>> valid_lft forever preferred_lft forever >>>>> >>>>> >>>>> >>>>> On Wed, Apr 16, 2014 at 8:53 PM, Kevin Benton <blak...@gmail.com>wrote: >>>>> >>>>>> Web server running multiple SSL sites that wants to be compatible >>>>>> with clients that don't support the SNI extension. There is no way for a >>>>>> server to get multiple IP addresses on the same interface is there? >>>>>> >>>>>> >>>>>> On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen >>>>>> <aaronoro...@gmail.com>wrote: >>>>>> >>>>>>> This is true. Several people have asked this same question over the >>>>>>> years though I've yet to hear a use case why one really need to do >>>>>>> this. Do >>>>>>> you have one? >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah <ro...@nuagenetworks.net >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi Vikash, >>>>>>>> Currently this is not supported. the NIC not only needs to be in >>>>>>>> different subnet, they have to be in different network as well >>>>>>>> (container >>>>>>>> for the subnet) >>>>>>>> >>>>>>>> Thanks >>>>>>>> Ronak >>>>>>>> >>>>>>>> On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar < >>>>>>>> vikash.ku...@oneconvergence.com> wrote: >>>>>>>> >>>>>>>>> *With 'interfaces' I mean 'nics' of VM*. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar < >>>>>>>>> vikash.ku...@oneconvergence.com> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I want to launch one VM which will have two Ethernet >>>>>>>>>> interfaces with IP of single subnet. Is this supported now in >>>>>>>>>> openstack ? >>>>>>>>>> Any suggestion ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanx >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Kevin Benton >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Kevin Benton >>>> >>>> _______________________________________________ >>>> 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 >> >> > > > -- > Kevin Benton > > _______________________________________________ > 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