[openstack-dev] [nova] Exposing provider networks in network_data.json
mgagne at iweb.com
Thu Jul 16 20:23:29 UTC 2015
I stubble on this review  which proposes adding info about provider
networks in network_data.json.
Concerns were raised by Kevin Benton about how those information
shouldn't be exposed to virtual instances for various reasons you can
read in the review and I totally agree with those concerns.
Monty Taylor mentioned a valid use case with Ironic where the node needs
the provider networks info to properly configure itself.
While I totally agree this is clearly a valid use case, I do not believe
the proposed implementation is the right answer.
(copying and rewording my comment found in the review)
For one, it breaks the virtual instance use case as I do not understand
how cloud-init or any similar tools will now be able to consume that
If you boot a virtual instance where the traffic is already decapsulated
by the hypervisor, how is cloud-init supposed to know that it doesn't
have to configure vlan network interfaces?
This important distinction between virtual and metal is not addressed in
the proposed implementation. In fact, it breaks the virtual use case and
I strongly believe it should be reverted now.
I do understand that the baremetal use case is valid but do not
understand how inexorably exposing this information to virtual instances
will not introduce confusion and errors.
So it looks like there is a missing part in this feature. There should
be a way to "hide" this information if the instance does not require to
configure vlan interfaces to make network functional.
Furthermore, John Garbutt mentioned "Part of me worries a little about
leaking this information, but I know some guests need this info. [...]
But even in those cases its security by obscurity reasons only, and I
want to ignore those.".
To that, I answer that as an public provider operator, I do not wish to
expose such information to my users. It's not up to Nova to decide for
me that exposing provider networks info is "ok" and those concerns be
"ignored". Please do not make such decisions lightly and without asking
a second opinion from operators which are the ones who will consume your
More information about the OpenStack-dev