Metadata service does not function when there are overlapping network address spaces

[Thierry Carrez]

Converted to bug from https://blueprints.launchpad.net/quantum/+spec/metadata-overlapping-networks

When an OpenStack instance has multiple networks using the same IP address space the metadata service does not function as expected.

[dan wendlandt (danwent)]

This is likely moving out of Folsom-RC1 unless there's been work on this that is not yet visible. Please update this bug ASAP, otherwise, we'll move it out.

[Russell Bryant (russellb)]

Is there a nova portion to this or is it just a quantum bug?

[Maru Newby (maru)]

russellb: I'm afraid I may have erred in adding a nova potion to this bug in particular, but from what I can tell it's not possible for the metadata service to work when nova is configured to use quantum due to the quantumv2 api in nova not implementing get_fixed_ip_by_address. I'm working on fixing that, but it may need to be targeting a separate bug. I'll discuss tonight with the Quantum team and post an update here.

[dan wendlandt (danwent)]

this is strange, because at one point, the quantum v2 code did support this method (perhaps it was just during review and was never committed though).

I remember this because its a really tricky issue: quantum allows for overlapping IP addresses, so fundamentally there's no clean way to map from an IP to an instance, since that relationship may be many-to-one.

Carl and I had started to brainstorm some options, but the long and short of it seems to be that we need the metadata server to somehow know the source network of the request, and use that info in the request to Quantum, allowing it to differentiate between overlapping IPs. We had talked about also having a model where we would query quantum and if there was only a single result, return that result, but there are tricky issues there, which may be why it was dropped (this is only secure if we know that the admin is the only one allowed to create subnets and can make sure they don't overlap... akin to a more traditional nova network setup).

[Maru Newby (maru)]

The nova issue has been moved to the following bug: bug:https://bugs.launchpad.net/nova/+bug/1052196

[Endre Karlson (endre-karlson)]

How long would it take to get a fix for this? Would it be something that would be possible to get in as a backport or similar?

[dan wendlandt (danwent)]

We will be able to describe how to setup & run the metadata server in a fashion similar to how it is used in Nova with no code changes. However, handling cases where there are overlapping IPs (something nova does not support at all) will be more complicated. I don't expect the diff to be huge, but if one is being strict about limiting backports to only true "bug fixes", they may well turn this down. Ultimately, it will likely be a nova decision.

[Endre Karlson (endre-karlson)]

Can someone from the Nova team be involved here ?

[Thierry Carrez (ttx)]

@Endre: you should attract their attention. IRC (at the project or Nova team meeting), ML otherwise.

[dan wendlandt (danwent)]

I've added markmcclain to this issue, as yesterday he said he would be working on this in Grizzly.

[Mark McClain (markmcclain)]

This is both a Quantum and Nova issue. The fix will require changes to both Nova and Quantum. I'm not sure that backporting to Nova stable will be possible since a new REST url will be added to Nova.

[dan wendlandt (danwent)]

btw, we should probably switch to using the blueprint for this: https://blueprints.launchpad.net/quantum/+spec/metadata-overlapping-networks, as this is a non-trivial change.

[Mark McClain (markmcclain)]

Agreed. I'll write up there and close this bug.

[dan wendlandt (danwent)]

this bug overlaps with a blueprint. closing the bug.