Hi, I stubble on this review [1] 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 information. 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 project. [1] https://review.openstack.org/#/c/152703/5 -- Mathieu __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev