Bug 1254685 - RFE: allow configuration of enable_isolated_metadata and enable_metadata_network
RFE: allow configuration of enable_isolated_metadata and enable_metadata_net...
Status: CLOSED WORKSFORME
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: Director
Assigned To: chris alfonso
yeylon@redhat.com
: FutureFeature, ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-18 12:08 EDT by bigswitch
Modified: 2016-04-18 02:51 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-15 19:15:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description bigswitch 2015-08-18 12:08:56 EDT
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:
Comment 3 Mike Burns 2015-08-18 12:21:38 EDT
Assaf,  any thoughts on this default change?
Comment 4 Assaf Muller 2015-08-18 13:18:08 EDT
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.
Comment 5 chris alfonso 2015-08-18 14:36:43 EDT
Giulio, Are these settings parameterized such that they can be altered easily from defaults?
Comment 6 bigswitch 2015-08-18 14:39:25 EDT
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?
Comment 7 Assaf Muller 2015-08-18 15:06:21 EDT
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?
Comment 8 bigswitch 2015-08-18 16:20:41 EDT
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.
Comment 9 Assaf Muller 2015-08-18 16:26:06 EDT
> 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.
Comment 10 bigswitch 2015-08-18 17:32:20 EDT
Got it. Thanks! :)
Comment 11 Giulio Fidente 2015-08-19 03:45:06 EDT
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
Comment 12 Mike Burns 2015-08-19 07:24:21 EDT
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
Comment 14 bigswitch 2015-09-07 11:44:30 EDT
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
Comment 15 Marios Andreou 2015-09-08 09:18:21 EDT
can we now mark this resolved then I guess?

Note You need to log in before you can comment on or make changes to this bug.