This bugzilla has been removed from the release since it has not been triaged, and needs to be reviewed for targeting another release.
It looks that the same is required for OSP13, when the following environment files aren't passed to the overcloud deploy command Docker service doesn't get started on the overcloud nodes: -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml If these env files are passed then deployment succeeds fine. I was under the impression that we were going to make these the defaults for upstream as well in Queens, has there been any change of plans in regards to this?
Some history. For OSP12 we injected the docker.yaml and docker-ha.yaml files via a Mistral workflow like this: https://code.engineering.redhat.com/gerrit/#/c/116444/ We discussed this at the PTG and agreed that adding a place in our Mistral workflow so that downstream can easily inject custom Heat environments as a default would be the way to go. Additionally there was an upstream patch to propose the OSP12 solution as a temporary upstream mechanism to change the default. https://review.openstack.org/#/c/510115/ That patch was -1'd as the MigratePlanAction was getting removed in: http://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=4212883acbbeccd9ebdeb526a2d5233b9520d185 ---- What I recommend we do: 1) Per discussions at the PTG. Lets create an upstream "placeholder" action that can be used to easily inject downstream product defaults via Heat environments. 2) Re-add the docker.yaml and docker-ha.yaml environments to this file downstream only for OSP13. This is a very small patch and is much more approapriate IMO than patching 10's (if not 100's) of lines of resource registry code in tripleo-heat-templates... (like we do for HA). 3) continue work upstream in Rocky to make docker the default.
I'm not familiar enough with how t-h-t works to understand the alternatives. I know jtomasek suggested updating capabilities-map.yaml with some sort of flag to indicate an environment should always be enabled, and then update plan-environment.yaml accordingly (both UI and CLI will use plan-environment.yaml for the list of environments that must be enabled in a deployment, maybe that's another place to look into? https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml#L7 ). The MigrateAction is gone, but maybe for OSP13 it can be replaced with some kind of DoRandomStuffToPlanAction to enable default environments, like dprince is suggesting. That always felt fragile though, because we can't unit test workflows and it's easy to miss possible execution paths, and Mistral failures can be opaque when things go wrong. Maybe we can add the workaround directly to ProcessTemplatesAction instead, since it seems to run for both create and update plans. We still end up hardcoding template names in Python either way. Also, for the record so it's not forgotten if this is the chosen approach, I understand the initial workaround needed an update to fully work -> https://code.engineering.redhat.com/gerrit/#/c/120807/
I added two upstream patches for this to cleanly implement a mechanism which can be used to inject custom environment files downstream (still needs testing and verification). If we can land those then I think we'll be in better shape for the future in this regard. And have a better mechanism for adjusting our downstream defaults without carrying large t-h-t patches always to munge the environments downstream. ---- NOTE: There is a related patch here that Martin has already proposed downstream with regards to the 'services' environments. There isn't a good way to handle those with this same mechanism so some level of t-h-t patching is still required. https://code.engineering.redhat.com/gerrit/#/c/128066/ This was the same solution we implemented for OSP12.
Does this cover all of the use-cases overcloud container image prepare overcloud tag discover ?? overcloud deploy Also In reading through https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/overcloud.html I do not see the notes about having to pass the same set of -e and -r options to overcloud container image prepare as you do to deploy
Had a nice chat w/ jpichon today on IRC. Turns out we can use plan-environment.yaml in t-h-t to set these default environments directly. Patch is now posted to the RH gerrit.
(In reply to Jon Schlueter from comment #8) > Does this cover all of the use-cases > > overcloud container image prepare > overcloud tag discover ?? > overcloud deploy > > Also In reading through > https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/ > overcloud.html I do not see the notes about having to pass the same set of > -e and -r options to overcloud container image prepare as you do to deploy I think it should work for all of them. Note my fix in comment #9. Very easy to apply that locally if you want to go ahead and test these out now.
OSP13 file exist after deployment: [root@undercloud-0 ~]# cat /usr/share/openstack-tripleo-heat-templates/plan-environment.yaml version: 1.0 name: overcloud description: > Default Deployment plan template: overcloud.yaml environments: - path: overcloud-resource-registry-puppet.yaml - path: environments/docker.yaml - path: environments/docker-ha.yaml [root@undercloud-0 ~]# Verify need to change infrared by default calls : (undercloud) [stack@undercloud-0 ~]$ cat overcloud_deploy.sh #!/bin/bash timeout 100m openstack overcloud deploy \ --templates /usr/share/openstack-tripleo-heat-templates \ --stack overcloud \ --libvirt-type kvm \ --ntp-server clock.redhat.com \ -e /home/stack/virt/internal.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/virt/network/network-environment.yaml \ -e /home/stack/virt/enable-tls.yaml \ -e /home/stack/virt/inject-trust-anchor.yaml \ -e /home/stack/virt/public_vip.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-ip.yaml \ -e /home/stack/virt/hostnames.yml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \ -e /home/stack/virt/debug.yaml \ -e /home/stack/virt/nodes_data.yaml \ -e /home/stack/virt/docker-images.yaml \ --log-file overcloud_deployment_74.log
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2086