Prepare images should autoevaluate container parameters for legacy services

[Bogdan Dobrelya]

When we reference a legacy service deployed with puppet on the host, like:

$ cat sahara.yaml
> resource_registry:
> OS::TripleO::Services::SaharaApi: ../../puppet/services/sahara-api.yaml
> OS::TripleO::Services::SaharaEngine: ../../puppet/services/sahara-engine.yaml
$ openstack overcloud container image prepare -e sahara.yaml

it produces an empty list of container_images: []

While it works as expected when resource_registry contains services referenced from 'docker/services' path.

This is new to Queens, and was not the case for Pike. We should fall back to the Pike behavior as users may still want have their legacy services upgradable into containerized services. Therefore,
'openstack overcloud container image prepare' should work the same way for services defined either in the docker/services or puppet/services paths.

[Martin André (mandre)]

I may be missing something, but when specifying legacy BM services I expect not to see container images for it.

Calling "openstack overcloud container image prepare" with no arguments will generate a list of *all* container images, while passing it a role and heat environment files will restrict it to *only* the container images used in the specified services.

With the above example, sahara.yaml does not use containerized services so it's expected to output an empty list.

IMO we should include environments/docker.yaml and probably environments/docker-ha.yaml too by default so that the behavior is maybe a bit less confusing.

[Bogdan Dobrelya (bogdando)]

I was thinking mostly of UX for upgrades paths for legacy services:

* a user installed a service with Pike or Ocata, on the host under systemd control plane.
* now he upgrades to Queens and wants to have that service containerized
* AFAIK, in order to run an upgrade command, the user has to preserve all of the '-e' files he initially deployed with 'as is' plus anything new to go with, if any.

So the question is: shall we allow to refer the services from /puppet/services (the proposed patch) or require them all **changed** to /docker/services (a docs change TBD)? The things are getting complicated for the references like /environments/cinder-backup.yaml. Now the user has to go and change all of the references, from puppet to docker, for all of the services included in /environments/cinder-backup.yaml et al.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Bogdan Dobrelya (<email address hidden>) on branch: master
Review: https://review.openstack.org/544357
Reason: According to the discussion with Martin, this should be a documentation issue and we can not change the tripleo client to work the proposed way, which is automatically detect container images for services referenced **not** from /docker/services paths.