Open Stack

On 29 June 2015 at 16:48, Monty Taylor <mordred at inaugust.com> wrote:
> 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.

I figured that might be the case.

> 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. :(

Fixing the broken API feels like a possible way forward.

I am hoping we can focus on these things in M, once we have API v2.1
properly sorted.

Thanks,
John