Open Stack

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 <blak111 at 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 <aaronorosen at gmail.com>wrote:
>
>> Whoops Akihiro beat me to it :)
>>
>>
>> On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen <aaronorosen at 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 <blak111 at 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 <aaronorosen at 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 <blak111 at 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 <aaronorosen at 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 <ronak at 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.kumar at oneconvergence.com> wrote:
>>>>>>>>
>>>>>>>>> *With 'interfaces' I mean 'nics' of VM*.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar <
>>>>>>>>> vikash.kumar at 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 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Kevin Benton
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Kevin Benton
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> _______________________________________________
> 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/20140417/3db64d63/attachment-0001.html>