By including the tech-preview images it imposes the extra bandwidth and storage for the extra unused container images.  But this is at the risk of extra complexity and additional parameter if you want to access the tech-preview bits.

From a generated file these should probably be dropped if you don't specify a --tech-preview option for the prepare command.

- imagename: docker-registry.engineering.redhat.com/rhosp12/openstack-neutron-dhcp-agent-docker:20171004.1
- imagename: docker-registry.engineering.redhat.com/rhosp12/openstack-neutron-l3-agent-docker:20171004.1
- imagename: docker-registry.engineering.redhat.com/rhosp12/openstack-neutron-metadata-agent-docker:20171004.1
- imagename: docker-registry.engineering.redhat.com/rhosp12/openstack-neutron-openvswitch-agent-docker:20171004.1
- imagename: docker-registry.engineering.redhat.com/rhosp12/openstack-neutron-server-docker:20171004.1
- imagename: docker-registry.engineering.redhat.com/rhosp12/openstack-neutron-server-opendaylight-docker:20171004.1
- imagename: docker-registry.engineering.redhat.com/rhosp12/openstack-neutron-sriov-agent-docker:20171004.1

This affects deployments with local registry, as this step isn't needed for remote registry scenario.

See my comment [1] in bug #1500528. The images can be filtered out if you pass it your roles_data.yaml and heat environment files to the prepare command.

I'm tempted to mark this bug as a duplicate of #1500528 since the issue will go away once we include the docker.yaml and docker-ha.yaml heat environment files by default in the prepare command.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1500528#c2

This one is a bit different to bug 1500528 and bug 1500531 because the images are built, they're just tech-preview.

Since this is just for optimising storage and transfer time, I don't think this is urgent, but it is worth discussing the possible options.

In this case I think Martin's suggestion is best, there is already a mechanism to filter by only the images which will be used (tech-preview or other). That mechanism is to run prepare with the --service-environment-file and --roles-file arguments.

Another option to hide the existence of tech-preview images is to add a conditional block to overcloud_containers.yaml.j2 so they only get the tech-preview images if they add an argument like this to the prepare call

  --set tech-preview-images=true

I'm setting needinfo for anyone on which approach we should do

I'd be careful about adding more options to the prepare command, it's already quite complex to use as it today.

I think this bug goes away once we add the docker.yaml and docker-ha.yaml files by default to the prepare command, since the downstream files do not include the containerized neutron.

FailedQA.

Environment:
python-tripleoclient-7.3.3-0.20171019055723.153bc4f.el7ost.noarch



Result:

openstack overcloud container image prepare|grep neutron
- imagename: tripleoupstream/centos-binary-neutron-dhcp-agent:latest
- imagename: tripleoupstream/centos-binary-neutron-l3-agent:latest
- imagename: tripleoupstream/centos-binary-neutron-metadata-agent:latest
- imagename: tripleoupstream/centos-binary-neutron-openvswitch-agent:latest
- imagename: tripleoupstream/centos-binary-neutron-sriov-agent:latest
- imagename: tripleoupstream/centos-binary-neutron-server:latest
- imagename: tripleoupstream/centos-binary-neutron-server-ovn:latest




(undercloud) [stack@undercloud-0 dd]$ grep neutron rhos12.yaml 
  DockerNeutronApiImage: 192.168.24.1:8787/openstack-neutron-server-docker:latest
  DockerNeutronConfigImage: 192.168.24.1:8787/openstack-neutron-server-docker:latest
  DockerNeutronDHCPImage: 192.168.24.1:8787/openstack-neutron-dhcp-agent-docker:latest
  DockerNeutronL3AgentImage: 192.168.24.1:8787/openstack-neutron-l3-agent-docker:latest
  DockerNeutronMetadataImage: 192.168.24.1:8787/openstack-neutron-metadata-agent-docker:latest
  DockerNeutronOvnApiImage: 192.168.24.1:8787/openstack-neutron-server-ovn-docker:latest
  DockerNeutronOvnConfigImage: 192.168.24.1:8787/openstack-neutron-server-ovn-docker:latest
  DockerNeutronSriovImage: 192.168.24.1:8787/openstack-neutron-sriov-agent-docker:latest
  DockerOpenvswitchImage: 192.168.24.1:8787/openstack-neutron-openvswitch-agent-docker:latest


  DockerNeutronApiImage: 192.168.24.1:8787/openstack-neutron-server-docker:latest
  DockerNeutronConfigImage: 192.168.24.1:8787/openstack-neutron-server-docker:latest
  DockerNeutronDHCPImage: 192.168.24.1:8787/openstack-neutron-dhcp-agent-docker:latest
  DockerNeutronL3AgentImage: 192.168.24.1:8787/openstack-neutron-l3-agent-docker:latest
  DockerNeutronMetadataImage: 192.168.24.1:8787/openstack-neutron-metadata-agent-docker:latest
  DockerNeutronOvnApiImage: 192.168.24.1:8787/openstack-neutron-server-ovn-docker:latest
  DockerNeutronOvnConfigImage: 192.168.24.1:8787/openstack-neutron-server-ovn-docker:latest
  DockerNeutronSriovImage: 192.168.24.1:8787/openstack-neutron-sriov-agent-docker:latest
  DockerOpenvswitchImage: 192.168.24.1:8787/openstack-neutron-openvswitch-agent-docker:latest

fixes are in latest build

The "fixed in version" should probably be python-tripleoclient-7.3.2-2.el7ost

Note that using python-tripleoclient-7.3.3-0 re-introduces the issue.

upgrades is running into issue with 7.3.3-0.XXXX dlrn build is greater than 7.3.2-2 stable tarball build

Just bumped to 7.3.3 upstream tag which pulls in 2 more patches than we had but looks sane and will be part of next import

Verified:
python-tripleoclient-7.3.3-3.el7ost.noarch
openstack-tripleo-common-7.6.3-3.el7ost.noarch

The output from "openstack overcloud container image prepare" command doesn't include lines with neutron now.

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-2017:3462