The CLI needs a better way to handle user environments

Bug #1640861 reported by Dougal Matthews on 2016-11-10
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

At the moment the `openstack overcloud deploy` command accepts the `--environment-file` (short version `-e`) argument. This is for providing additional Heat environment files for the deployment. The problem with these files is that they can reference files in the resource registry anywhere on the local filesystem. To find these files we need to process the templates with python-heatclient (to avoid manually parsing and following them).

The files also have local file paths which don't make sense when the files are uploaded to swift.

We need a better way for this to work. A possible solution would be for the user to put all the files in one directory and tell the deploy command about them with an argument something like `--environment-dir`. Then all files would be uploaded without any processing.

There are some questions.

1. Do we allow users to provide multiple environment directories?
2. How do we merge the environment directory with the tripleo-heat-templates root? Do we just overwrite any files that are the same?
3. Does this have any impact on the GUI?

Dougal Matthews (d0ugal) on 2016-11-10
description: updated
tags: added: tripleoclient
Julie Pichon (jpichon) wrote :

As a somewhat related reference, bug 1642583 was filed against the UI as it cannot display which environments were enabled if the deployment was launched from the CLI. (Currently the UI shows e.g. "Storage Environment, Base resources configuration, TLS, SSL-enabled deployment with IP address as public endpoint, environments/inject-trust-anchor.yaml" on the Deployment Plan page for a deployment started from the UI. It's pretty convenient.)

Changed in tripleo:
milestone: ocata-2 → ocata-3
Changed in tripleo:
status: Confirmed → Triaged
Dougal Matthews (d0ugal) on 2017-01-16
Changed in tripleo:
milestone: ocata-3 → pike-1
Changed in tripleo:
milestone: pike-1 → pike-2
Changed in tripleo:
milestone: pike-2 → pike-3
Changed in tripleo:
milestone: pike-3 → pike-rc1
Ben Nemec (bnemec) wrote :

Is there any chance of this getting fixed for Pike or should we defer it to Queens?

Julie Pichon (jpichon) wrote :

Moving to Queens, though comment #36 on bug 1635409 makes me think perhaps this will be fixed earlier as part of the other bug.

Changed in tripleo:
milestone: pike-rc1 → queens-1
Adriano Petrich (apetrich) wrote :

I'll be adding a blueprint for this.

Changed in tripleo:
milestone: queens-1 → queens-2
Adriano Petrich (apetrich) wrote :

So forget the blueprint. It is mostly executed here as far as I can see the conditions for it to go forward are all merged

Adriano Petrich (apetrich) wrote :

I agree with Julie: Once has fully landed this bug is no longer an issue.

Changed in tripleo:
milestone: queens-2 → queens-3
Changed in tripleo:
milestone: queens-3 → queens-rc1
Changed in tripleo:
milestone: queens-rc1 → rocky-1
Changed in tripleo:
milestone: rocky-1 → rocky-2
Changed in tripleo:
milestone: rocky-2 → rocky-3
Changed in tripleo:
milestone: rocky-3 → rocky-rc1
Changed in tripleo:
milestone: rocky-rc1 → stein-1
Changed in tripleo:
milestone: stein-1 → stein-2

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (FUTURE, PIKE, QUEENS, ROCKY, STEIN).
  Valid example: CONFIRMED FOR: FUTURE

Changed in tripleo:
importance: High → Undecided
status: Triaged → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers