Description of problem: Docker.yaml is included by default and should not be added by the user. When using the GUI, deployments might fail if you include docker.yaml because it is not mentioned in capabilities-map.yaml and therefor the GUI considers it a user-supplied environment file and adds it as one of the last environment files (overriding docker-ha.yaml). docker.yaml is hard to find and remove because it is found in the "other" category in the configuration dialog (buried between >100 other unsorted files). It should be unselected by default and the user should never touch it. Version-Release number of selected component (if applicable): openstack-tripleo-ui-9.3.1-0.20180921180345.df30b55.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Open the GUI after a clean install Actual results: The docker.yaml file is one of the environments that are configured in the default "overcloud" plan. Expected results: docker.yaml should not be in the deployment. The default is already a containerized deployment.
Why does specifying docker.yaml break the deployment? It should be a noop. Please provide logs/error messages. It sounds more like an issue with the UI in the way it handles this.
Alex: I just checked and the docker.yaml file on the rhos-14.0-patches branch has data in it for all the docker services. It is not a noop as of yet. I think the issue here is more one of ordering. If I read what has been said above the issue is the docker.yaml is specified manually by the user late in the deployment as a custom environment and that doing this can break the HA defaults that are now wired into the downstream defaults in overcloud-resource-registry-puppet.j2.yaml. Jtomesek: As a solution would it be reasonable to just noop out docker.yaml so that it doesn't do anything. Simply pushing a patch that makes the docker.yaml heat environment an empty file should be doable if all the defaults have in fact been merged into overcloud-resource-registry-puppet.j2.yaml.
It should be a noop if the services are define the same. My question is really around what specifically is broken here as in theory specifying docker.yaml first (which is what we previously had) should essentially be a noop. I guess we need more info as to what specifically the UI is doing around this for the plan.
As Dan says, it is an ordering problem. Since the same configuration is already provided in overcloud-resource-registry-puppet.j2.yaml, enabling docker.yaml should have no effect. This is true under the condition that docker.yaml is applied before any environment file which overrides this configuration which is docker-ha.yaml in this case. GUI does not let the user specify the order of environment files as that requires the user to deeply understand its contents. Instead, it relies on information from capabilities-map.yaml [1]. When the selection of environment files is updated, environment files are reordered using dependency information from capabilities-map.yaml [2]. The files which are not included there (custom environments) are applied after [3]. Since docker.yaml is redundant now, it has been removed from capabilities-map.yaml, it is treated as a custom file and gets applied after docker-ha.yaml. Resulting plan-environment.yaml looks e.g.: ... environments: - path: overcloud-resource-registry-puppet.yaml - path: environments/docker-ha.yaml - path: environments/network-isolation.yaml - path: environments/docker.yaml - path: environments/network-environment.yaml ... Dan: I checked and docker.yaml has been nooped recently in upstream master [4], so it should not be an issue in the future. (Backporting this downstream is a solution but I find the solution below more user-friendly) As described in Comment 1, this problem occurs only in downstream patch which makes docker.yaml enabled by default [5], the simplest solution is IMHO to remove docker.yaml from that patch. Alternatively, we can re-introduce docker.yaml in capabilities-map.yaml to ensure correct ordering. Although I think re-introducing docker.yaml altogether is not user friendly as it introduces 'Containerized deployment' option in GUI which is not relevant and just confuses the user. In short, docker.yaml is no longer relevant, why should we show it as an option or even enable it by default? [1] https://github.com/openstack/tripleo-heat-templates/blob/stable/rocky/capabilities-map.yaml [2] https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/heat_capabilities.py#L156 [3] https://github.com/openstack/tripleo-common/blob/master/tripleo_common/utils/plan.py#L171 [4] https://github.com/openstack/tripleo-heat-templates/blob/master/environments/docker.yaml [5] https://code.engineering.redhat.com/gerrit/gitweb?p=openstack-tripleo-heat-templates.git;a=commit;h=435b62f9e420478e73049c72f092f7ea34182649
Downstream rhos-14.0-patch: https://code.engineering.redhat.com/gerrit/160112 [downstream only] Remove docker.yaml from being enabled by default
docker.yaml is no longer included by default: /rhosp14/openstack-tripleo-ui 2019-06-17.2 openstack-tripleo-ui-9.3.1-0.20190506152409.f3ba58f.el7ost.noarch openstack-tripleo-heat-templates-9.3.1-0.20190513171733.9995be9.el7ost.noarch
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/RHBA-2019:1672