openstack team mailing list archive

[corvus@xxxxxxxxxxxx (James E. Blair)]

"Dan Prince" <dan.prince@xxxxxxxxxxxxx> writes:

> Jim,
>  
> Okay. I'm still a bit fuzzy on the order of operations we'd need to
> make in order to get branch in when a config file changes.
>  
> Take this review for example:
>  
>  https://review.openstack.org/#change,2919
>  
> Based on what I understand devstack needs to support both version of
> the nova config file in order for the branches to land smoothly? That
> seems like something we wouldn't want to do. Am I misunderstanding
> something?

If config file changes can be safely read by multiple versions of (eg,)
nova, then you can:

1) Add new stanzas to config files in devstack.
2) Make the change in nova.
3) Remove old stanzas from devstack.

However, if the changes are in direct conflict, then it seems devstack
would need conditional logic to know which to include.  Whether that
logic should stay in devstack or merely be temporary depends on the
change.  In that case, you would need to:

1) Add conditional logic to devstack that writes out different version
   of the config file.  It should probably test something in the nova
   repo to avoid adding yet another external factor.
2) Make the change in nova.
3) Possibly remove the conditional logic in devstack, depending on the
   nature of the change.

> Also, in order to coordinate these types of changes shouldn't all core
> members on gated projects have core privileges on devstack as well?
> This would allow us to coordinate making these types of changes?

If the changes are strictly ordered like this, I don't think the timing
is super-critical.  Devstack is designed to be accessible so anyone in
the project can submit a patch.


If this kind of config file change is likely to be a common problem,
here is another way we could handle it: change devstack to use the
sample config file from the nova repository instead of the one in
devstack.  Have devstack copy it into place and perform variable
replacement on the specifics (like the admin token).  That makes
devstack a little simpler, and keeps the simple case of a tightly
integrated change of a component and its config file within the same
repo.

-Jim