Bug 1538015 - Include docker.yaml and docker-ha.yaml environment files by default
Summary: Include docker.yaml and docker-ha.yaml environment files by default
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 13.0 (Queens)
Hardware: All
OS: All
high
urgent
Target Milestone: beta
: 13.0 (Queens)
Assignee: Emilien Macchi
QA Contact: Artem Hrechanychenko
URL:
Whiteboard:
Depends On: 1466744
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-24 10:10 UTC by Marius Cornea
Modified: 2018-08-03 18:35 UTC (History)
19 users (show)

Fixed In Version: openstack-tripleo-heat-templates-8.0.0-0.20180122224017.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1466744
Environment:
Last Closed: 2018-06-27 13:42:33 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1745154 None None None 2018-01-24 15:27:28 UTC
Red Hat Product Errata RHEA-2018:2086 None None None 2018-06-27 13:43:13 UTC

Comment 2 Red Hat Bugzilla Rules Engine 2018-01-24 10:11:22 UTC
This bugzilla has been removed from the release since it has not been triaged, and needs to be reviewed for targeting another release.

Comment 3 Marius Cornea 2018-01-24 10:13:26 UTC
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?

Comment 5 Dan Prince 2018-01-24 13:49:14 UTC
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.

Comment 6 Julie Pichon 2018-01-24 14:16:20 UTC
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/

Comment 7 Dan Prince 2018-01-24 15:20:28 UTC
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.

Comment 8 Jon Schlueter 2018-01-25 11:33:18 UTC
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

Comment 9 Dan Prince 2018-01-26 01:38:06 UTC
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.

Comment 10 Dan Prince 2018-01-26 01:40:20 UTC
(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.

Comment 15 Omri Hochman 2018-02-09 13:48:09 UTC
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

Comment 19 errata-xmlrpc 2018-06-27 13:42:33 UTC
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


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