Open Stack

On 06/29/2015 11:37 AM, John Garbutt wrote:
> On 29 June 2015 at 13:50, Monty Taylor <mordred at inaugust.com> wrote:
>> On 06/29/2015 05:36 AM, John Garbutt wrote:
>>> On 26 June 2015 at 13:17, Monty Taylor <mordred at inaugust.com> wrote:
>>>> On 06/26/2015 08:04 AM, John Garbutt wrote:
>>>>> IMHO, we should focus on getting the external IP address of the VM
>>>>
>>>> Yes. Getting the external IP address of the VM is one of the hardest
>>>> things in OpenStack. It's even worse than image uploads. :)
>>>
>>> +1
> 
> I just wanted to check, Nova does return "accessIPv4" and "accessIPv6".
> 
> I am guessing that didn't work in all the clouds you have tested?

It works in Rackspace and only in Rackspace.

Problem is, from what I can tell, it requires a deployer to specify the
single network that is public. In other clouds, where a routable ip may
come from floating IPs - or where there may be more than one network,
the config-option part breaks down.

What would be neat is if the extension that provides accessIPv4 info,
instead of just having a network config option, did the logic that's here:

http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/meta.py#n73

on behalf of the user without the user having to know any of the 8 ways
that the cloud might have been deployed. Then the config option for the
deployer should be more like "do you get IPs from floating ips? do you
get them from a single network? do you get them from a per-tenant
network that is labeled?" - etc.

So - as great as the entry in the nova metadata is, and as great as I
support the existence of the extension, it actually only winds up being
a 5th standard to solve the problem of 4 competing standards. :(

> Thanks,
> John
> 
> PS
> In the nova v2.1 API, it should start being available everywhere,
> because we are removing the concept of optional API extensions.

I am the world's largest fan of this.