Bug 1576090 - Use of j2 templates conflicts with use of environment-directory
Summary: Use of j2 templates conflicts with use of environment-directory
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: James Slagle
QA Contact: Arik Chernetsky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-08 19:24 UTC by Steve Reichard
Modified: 2018-09-10 15:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-26 18:51:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Steve Reichard 2018-05-08 19:24:42 UTC
Description of problem:

With OSP12, and the network isolation being generated,  I have to actually use the '-e' to include it so it would be generated.   With previous releases, I would copy (editting paths) any files I needed to an environment-directory with a number so that they were in order.
With OSP12 the isolation file was first, so I could use use the -e for it then my environment-directory.   

I just notice my OSP13 deployment did not work with predictive IPs,  and noticed that the ports are generate from jinja.  Becuase of the ordering of files, this is making me abondon using the environement file - which I had found a very useful feature.





Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 David Peacock 2018-05-08 20:26:22 UTC
Looks related to https://bugs.launchpad.net/tripleo/+bug/1762403

Comment 2 David Peacock 2018-05-08 20:27:25 UTC
And related: https://bugzilla.redhat.com/show_bug.cgi?id=1570938

Comment 3 James Slagle 2018-05-14 20:22:53 UTC
Can you show the deploy command you're using, and the list of environments in the environment dir, and the order you're expecting to have to take effect?

What order is actually taking effect?

Comment 4 Steve Reichard 2018-05-15 13:16:45 UTC
The issue is not that the order in the environment directory is not happening in order, the issue is that I MUST use '-e' for files to be generated from j2, and these files used to be in the middle of the order in the environment file.

For OSP11 this was my deploy command - 

[sreichar@se-users rhosp]$ cat deploy-overcloud.sh 
#!/bin/bash -x

PROJECT=$(basename `dirname $0`)


date


source stackrc

openstack overcloud deploy \
--templates \
--environment-directory /home/stack/mytemplates/env \
--roles-file /home/stack/mytemplates/roles_data.yaml \
--stack ${PROJECT} \
--debug \
--log-file overcloudDeploy.log \

date



----

For OSP12 with the network isolation moving to j2 which would be first or second depending on DVR - this is what my deploy script changed to:


[sreichar@se-users rhosp]$ cat deploy-overcloud.sh 
#!/bin/bash -x

PROJECT=$(basename `dirname $0`)


date


source stackrc

if [[ -e /home/stack/mytemplates/19-dvr.yaml ]]
then
  openstack overcloud deploy \
  --templates \
  --ntp-server 10.5.27.10 \
  -e /home/stack/mytemplates/19-dvr.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  --environment-directory /home/stack/mytemplates/env \
  --roles-file /home/stack/mytemplates/${PROJECT}-roles-data.yaml \
  --networks-file /home/stack/mytemplates/${PROJECT}-network-data.yaml \
  --stack ${PROJECT} \
  --debug \
  --log-file overcloudDeploy.log
else
  openstack overcloud deploy \
  --templates \
  --ntp-server 10.5.27.10 \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  --environment-directory /home/stack/mytemplates/env \
  --roles-file /home/stack/mytemplates/${PROJECT}-roles-data.yaml \
  --networks-file /home/stack/mytemplates/${PROJECT}-network-data.yaml \
  --stack ${PROJECT} \
  --debug \
  --log-file overcloudDeploy.log
fi

date



-------


Now with OSP 13, I see my deterministic IPs didn't work since it seems some of the files it uses are not from j2, and the environment files are not at near the beginning or end, so I couldn't cheat like above anymore

(undercloud) [stack@rhosp-director ~]$ ls mytemplates/env/
25-rhosp-networks.yaml  35-rhosp-IP-pools.yaml  60-sat6-registration.yaml  90-rhosp-rhos13-images.yaml
30-ips-from-pools.yaml  50-rhosp-ext-ceph.yaml  70-rhosp-hostmap.yaml      99-rhosp-misc.yaml
(undercloud) [stack@rhosp-director ~]$

Comment 5 Bob Fournier 2018-05-24 15:53:30 UTC
Please see comments at https://bugzilla.redhat.com/show_bug.cgi?id=1570938#c13. Is this the issue you are hitting?

Comment 6 Dan Sneddon 2018-05-31 20:18:51 UTC
(In reply to Steve Reichard from comment #4)
> The issue is not that the order in the environment directory is not
> happening in order, the issue is that I MUST use '-e' for files to be
> generated from j2, and these files used to be in the middle of the order in
> the environment file.

Steve, the workflow has changed now that we are generating some environment files via Jinja. If you want to use your old workflow, where you just pass a directory with your environment files, you need to generate the needed files and place them in the directory of your choice.

In order to generate the environment files, there is a script in openstack-tripleo-heat-templates/tools/process_templates.py that will do this prior to deployment. Then you can copy the generated files into a directory and use them from there.

The process_templates.py script can be run from the root of the tripleo-heat-templates with no parameters, and it will generate the files inside the tripleo-heat-templates directory structure. You can also pass an output directory to have the files rendered elsewhere. Run process_templates.py --help for more info.

Comment 7 Bob Fournier 2018-06-11 15:47:01 UTC
Steve - are you able to update your workflow using Dan't suggestion to run process_templates.py?

Comment 9 Steve Reichard 2018-09-10 15:18:20 UTC
removing need info since closed.


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