Can't override extra configs with local.conf

Bug #1249085 reported by Ryan Hsu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
devstack
Fix Released
Medium
Ryan Hsu

Bug Description

With the new local.conf, it is possible to override configuration options for non-extra services (e.g. nova, cinder) but extra services like Tempest cannot take advantage of it's power. The problem is because the "extra" phase is run before any of the extra.d files are run. From the README:

   "runs after services are started and before any files in extra.d are executed"

In the case of Tempest, both the "post-config" and "extra" phases run before Tempest installation and configuration. Putting any configuration options in existing local.conf phases will just get overwritten by options set by configure_tempest(). To fix this, we can create a new phase, "post-extra", that will take place after extras have been installed and configured.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to devstack (master)

Fix proposed to branch: master
Review: https://review.openstack.org/55583

Changed in devstack:
assignee: nobody → Ryan Hsu (rhsu)
status: New → In Progress
Revision history for this message
Dean Troyer (dtroyer) wrote :

Review https://review.openstack.org/#/c/55418/ has the opposite problem regarding the order of local.conf and extras.d handling. Let's see if we can work this out without adding too many new phases.

What it does today:

======
A: local.conf handler for 'local'

[built-in service source]

B: extras.d handler for 'source'

[built-in service install and configure]

C: extras.d handler for 'install'

[built-in service init]

D: extras.d handler for 'post-config'

E: local.conf handler for 'post-config'

[built-in services started]

F: local.conf handler for 'extra'

G: extras.d handler for 'extra'
======

In https://review.openstack.org/#/c/55583/ Ryan wants to add a local.conf handler after G to change the extras services; however they should already be started at that point and there is no mechanism to re-start them.

In https://review.openstack.org/#/c/55418/ Denis has a need to test a value in nova.conf in D that may not be correctly set until E.

I think Ryan's issue could be handled by making the config changes in E rather than F. However, Denis's need is for D and E to change places.

One option would be to have the extras.d scripts make their own call to merge_config_group() local.conf 'some-new-name' as required to enable modifying their own config files from local.conf. Then if we exchange D and E (which I think needs to be done anyway) Ryan could add a merge_config_group() call to tempest after its config file is written to handle user-configurable values using a pahse name like 'tempest-post-config'.

Thoughts?

Changed in devstack:
importance: Undecided → Medium
Revision history for this message
Ryan Hsu (rhsu) wrote :

Dean, thanks for pointing out this issue and for the thoughtful reply.

I forgot to point out that the initial Tempest config is created after [built-in services started] because some of its config options are derived from the running services. This means any swaps that need to be done prior to [built-in services started] won't affect Tempest.

To solve this bug, Tempest just needs the current F to come after G. The 2 solutions that come to mind are:
1. Swap F and G
2. Introduce a phase H for local.conf overrides after extras.d handler for 'extra'

#1 is the simplest solution here, however, if other extras (Savanna?) are already depending on F coming before G, then they'll have to rewrite.

#2 works and doesn't require changes in extras scripts but may add extra complexity/maintenance to devstack.

I'm rooting for #2 because it is a simple change but if either of the above don't work out, I'm okay with having extras.d scripts make their own calls to merge_config_group().

Revision history for this message
Denis Egorenko (degorenko) wrote :

It does not matter for Savanna which of these 2 solutions will be chosen. It is important for us that we read value, which shouldn't will change in the next phases.

Revision history for this message
Ryan Hsu (rhsu) wrote :

Dean, it looks there is no conflict between what Denis and I need. Our options for going forward is as follows:

a) add an extra phase (my current patchset)
b) swap the local.conf 'extra' handler and extras.d 'extra' handler

Please let me know which solution sounds best to you.

Revision history for this message
Ryan Hsu (rhsu) wrote :

Looking to leverage this for the VMware Minesweeper. Can we bump the priority for this?

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to devstack (master)

Reviewed: https://review.openstack.org/55583
Committed: http://github.com/openstack-dev/devstack/commit/feb28837f4db9177835f94b6b9899a90c45a685d
Submitter: Jenkins
Branch: master

commit feb28837f4db9177835f94b6b9899a90c45a685d
Author: Ryan Hsu <email address hidden>
Date: Thu Nov 7 12:12:35 2013 -0800

    Add new stack phase: post-extra

    The current existing phases "post-config" and "extra" are not
    sufficient to allow local.conf overrides to extra type services
    because they run after the services are installed and configured.
    This commit introduces a new phase called "post-extra" that runs
    after these existing phases. With this change, users are able to
    leverage local.conf to provide overridden options to services
    like Tempest.

    Change-Id: I5d758eebfda804dd1d8cbc3d5cc35ef4dcc8c96f
    Closes-Bug: #1249085

Changed in devstack:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.