This would be useful in OSP8 and earlier. In OSP9 it's hopefully not needed thanks to this new feature in Heat that allows stack updates that modify a subset of the environment files without passing all of the environment files used during the stack create to Heat again:

http://specs.openstack.org/openstack/heat-specs/specs/mitaka/multi-environments.html

However, there may be changes in the TripleO client required to take advantage of this feature. AFAIK this has never been tested.

Bulk update to reflect scope of Red Hat OpenStack Platform 9 and Red Hat OpenStack Platform does not include this issue (No pm_ack+).

I set bug priority to high to avoid use case [1] which we forgot some parameters.

It is very likely to happen to customers, for sure when upgrading from one version to another after a year.

I think we need to same history of all commands relate to deploy/update/upgrade   



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1358374

(In reply to Ofer Blaut from comment #4)
> I set bug priority to high to avoid use case [1] which we forgot some
> parameters.
> 
> It is very likely to happen to customers, for sure when upgrading from one
> version to another after a year.
> 
> I think we need to same history of all commands relate to
> deploy/update/upgrade   
> 
> 
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1358374

+ scale/debugging.

We are post M2, Suggesting to include in 12 (Pike)

It is not the original Deployment Command needed, but the last deployment command used, i.e. adding nodes.

I agree with Zane (comment #2), and I'll enhance on that. Here is how I see it: it's not the commands that we need to refer to, but the environment that was configured. Some of this data is currently available when you run "openstack workflow env show overcloud", and we need to enhance on that:

1) All the environment yamls that were used need to be listed. Currently it lists something very partial like the following (I used a lot more environments than what it lists):

"environments": [                    
    {                                                     
        "path": "overcloud-resource-registry-puppet.yaml" 
    },                                                    
    {                                                     
        "path": "user-environment.yaml"                   
    }                                                     
],                                                        

2) All the default_parameters that were collected from all the yamls should be listed in the environment. Again, this partially works today already and needs to be tested (it would be wonderful to backport it also).

3) The entire set of templates can be found in swift. This already exists today, but the external environment files that were used are not stored in swift. We should store them in addition to listing them as item (1) describes.

The exact command syntax that was used for the deployment can then be deduced from the data stored in the environment, and it's not so important to record the bash command. This should work equally well when using the GUI and using the CLI.

This is a very important enhancement that I need in my automation!

Something similar to the initial request has been implemented in Pike upstream, adding a few links.

Udi, the work you mentioned on improving environment management is slowly on-going upstream (unfortunately unlikely to be backportable). The external environments you mention should already be stored in swift too as part of the user-environmnent.yaml mega-environment at the moment.

Thank you Julie, should we put the status on "POST", since the review has been merged ?

In my opinion it's close enough to the bug description to do this, yes. I'll confirm with the UA what to do with release targets as even if it will be available as part of OSP12 now, I don't know that we have the QE resources available to do the verification. Thanks!

(Fixing assignment to the actual patch author)

Re-opening as it's not clear where the stored deployment command looks like and how to retrieve it.