Description of problem: We are using RHOSP7 GA bits and notice that in dhcp_agent.ini enable_isolated_metadata and enable_metadata_network two flags are false by default. This is problematic because if a tenant creates a network without attaching to a router, all the instances of that network won't get their metadata. It makes more sense to assign true to these two flags by default. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Assaf, any thoughts on this default change?
Those settings are not applicable to the general case and are relevant to provider networks exclusive architectures or solutions that don't use the L3 agent. Our reference architecture provides metadata via routers which is accomplished by the default values from upstream. Deviating from upstream here for non-standard architectures is dangerous. I'm very much against this.
Giulio, Are these settings parameterized such that they can be altered easily from defaults?
It is OK not to change the default value. However, a nob is needed to let users be able to change the default values for those two flags. There are plenty of uses cases that require to turn on those two flags. Other than manually making configuration changes and restarting neutron-server after installation, what is the recommended installation workflow to turn on these two flags?
You can use any configuration management tool of your liking to change those two values in dhcp_agent.ini on any node you have the DHCP agent running and restart the DHCP agent. It looks like a one time, trivial ordeal to me. What issue am I missing?
That will work. However, is this the general recommendation for any openstack configuration change? RHOSP7 supports 15 controller nodes in maximum, which means a user has to manually log on 15 nodes to make configuration changes and restart services. What if these configurations get inconsistent? What if a user needs to make configuration changes and restart services on all compute nodes? In that case, a user has to have some post installation script. What if that script has bugs and didn't make all necessary changes correctly? Will redhat support help to debug those problems caused by users' post installation script? A much more reasonable way is to allow user to make changes to the default value in the first place and then start the installation.
> RHOSP7 supports 15 controller nodes in maximum, which means a user has to manually log on 15 nodes to make configuration changes and restart services. What if these configurations get inconsistent? What if a user needs to make configuration changes and restart services on all compute nodes? There's a million tools out there (Ansible is my personal favorite) that prevent you from making a change manually to each individual machine. > Will redhat support help to debug those problems caused by users' post installation script? It depends on the change. In this case the answer would be yes, you would be supported. On a general note, Red Hat tests a reference architecture with a given set of configuration values, we cannot test every nob out there and its implication on the rest of the system. That is simply too many permutations. In cases such as these I personally think it's entirely reasonable to expect the user to make a post installation change.
Got it. Thanks! :)
Chris, these are not parametrized no. We might add the parameters; for the moment these can both be manipulated editing hieradata, that means editing: /usr/share/openstack-tripleo-heat-templates/puppet/hieradata/controller.yaml adding there: neutron::agents::dhcp::enable_isolated_metadata: true neutron::agents::dhcp::enable_metadata_network: true and then deploying with the --templates cmdline argument
Based on comments above, I'm turning this into an RFE to add configuration options to the templates. The short term solution is to edit [1] and then deploy. It doesn't require manually editing all the controllers post deploy. [1] /usr/share/openstack-tripleo-heat-templates/puppet/hieradata/controller.yaml
By putting following into an environment file, we can change both enable_isolated_metadata and enable_metadata_network parameters: controllerExtraConfig: neutron::agents::dhcp::enable_isolated_metadata: true neutron::agents::dhcp::enable_metadata_network: true
can we now mark this resolved then I guess?