Bug 1254685

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?