rhel-osp-director: Try to deploy overcloud 7.2 with network isolation, from undercloud 8.0, fails right away with: [stack@undercloud72 ~]$ openstack overcloud deploy --templates --control-scale 3 --compute-scale 2 --ceph-storage-scale 1 --ntp-server 10.5.26.10 --timeout 90 -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /home/stack/network-environment.yaml Deploying templates in the directory /usr/share/openstack-tripleo-heat-templates Stack failed with status: Resource CREATE failed: resources.Networks: Property error: resources.StorageMgmtNetwork.properties.StorageMgmtNetValueSpecs: Value must be a string Heat Stack create failed. Environment: openstack-tripleo-0.0.7-1.el7ost.noarch openstack-tripleo-common-0.0.2-4.el7ost.noarch openstack-tripleo-puppet-elements-0.0.2-1.el7ost.noarch openstack-tripleo-image-elements-0.9.7-1.el7ost.noarch instack-undercloud-2.2.0-1.el7ost.noarch openstack-tripleo-heat-templates-0.8.6-94.el7ost.noarch Steps to reproduce: 1. Deploy undercloud 8.0. 2. Get/Load images for 7.2 (Note: BZ #1295912) 3. Downgrade the openstack-tripleo-heat-templates package to 7.2 version. 4. Run a deployment with network isolation: openstack overcloud deploy --templates --control-scale 3 --compute-scale 2 --ntp-server x.x.x.x --timeout 90 -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /home/stack/network-environment.yaml Result: Deploying templates in the directory /usr/share/openstack-tripleo-heat-templates Stack failed with status: Resource CREATE failed: resources.Networks: Property error: resources.StorageMgmtNetwork.properties.StorageMgmtNetValueSpecs: Value must be a string Heat Stack create failed. Expected result: No error.
This is questionable for being a blocker -- backwards compatibility for deployment is defined for the latest 7.y (will be 7.3). So this will need to be replicated with 7.3. Though, no work started on this feature in general, yet. At the moment this is not a bug, so I am closing it and let's start testing once we have this available from eng.
Moving back to ON_QA - we need to track this issue and verify it doesn't reproduces when attempting to deploy OSP 7.3 with director 8.0. -I'm not sure if it consider a blocker for 8.0?
This is hitting CI as well with the last poodle and puddle at 16 Feb 2016
Here is the command that I'm issuing source /home/stack/stackrc; openstack overcloud deploy --debug --log-file overcloud_deployment_38.log --templates --libvirt-type=qemu --ntp-server 10.5.26.10 --control-scale 1 --compute-scale 1 --ceph-storage-scale 1 --block-storage-scale 0 --swift-storage-scale 0 --control-flavor baremetal --compute-flavor baremetal --ceph-storage-flavor baremetal --block-storage-flavor baremetal --swift-storage-flavor baremetal --neutron-network-type vxlan --neutron-tunnel-types vxlan --timeout=90 -e /usr/share/openstack-tripleo-heat-templates/kilo/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/kilo/environments/net-single-nic-with-vlans.yaml -e ~/network-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/kilo/environments/storage-environment.yaml -e ~/default-overcloud-settings.yaml $ cat default-overcloud-settings.yaml parameters: CinderLVMLoopDeviceSize: 10000 $ cat network-environment.yaml # note the EC2MetadataIp: value should match the value in /home/stack/undercloud.conf for key local_ip # EC2MetadataIp: "local_ip" #ControlPlaneSubnetCidr: key name must match the keyname found in #/usr/share/openstack-tripleo-heat-templates/network/config/$type/node.yaml parameter_defaults: InternalApiNetCidr: 172.16.20.0/24 StorageNetCidr: 172.16.21.0/24 TenantNetCidr: 172.16.22.0/24 ExternalNetCidr: 172.16.23.0/24 StorageMgmtNetCidr: 172.16.19.0/24 InternalApiAllocationPools: [{'start': '172.16.20.10', 'end': '172.16.20.100'}] StorageAllocationPools: [{'start': '172.16.21.10', 'end': '172.16.21.100'}] StorageMgmtAllocationPools: [{'start': '172.16.19.10', 'end': '172.16.19.100'}] TenantAllocationPools: [{'start': '172.16.22.10', 'end': '172.16.22.100'}] ExternalAllocationPools: [{'start': '172.16.23.110', 'end': '172.16.23.150'}] ExternalInterfaceDefaultRoute: 172.16.23.251 NeutronExternalNetworkBridge: "''" ControlPlaneSubnetCidr: "24" ControlPlaneDefaultRoute: 192.0.2.1 EC2MetadataIp: 192.0.2.1
https://review.openstack.org/#/c/221452/ needs to be backported to OSP7 for this to work.
No need to downgrade the openstack-tripleo-heat-templates package to 7.2 version. There are 2 rpms now: openstack-tripleo-heat-templates-0.8.7-12.el7ost.noarch openstack-tripleo-heat-templates-kilo-0.8.7-12.el7ost.noarch
Environment: openstack-tripleo-heat-templates-0.8.7-12.el7ost.noarch openstack-tripleo-heat-templates-kilo-0.8.7-12.el7ost.noarch [stack@instack ~]$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates/kilo --control-scale 3 --compute-scale 2 --ntp-server clock.redhat.com --timeout 90 -e /usr/share/openstack-tripleo-heat-templates/kilo/environments/network-isolation.yaml -e /home/stack/network-environment.yaml Deploying templates in the directory /usr/share/openstack-tripleo-heat-templates/kilo 2016-02-23 22:58:53 [overcloud]: CREATE_IN_PROGRESS Stack CREATE started 2016-02-23 22:58:53 [Networks]: CREATE_IN_PROGRESS state changed 2016-02-23 22:58:53 [Networks]: CREATE_FAILED resources.Networks: Property error: resources.StorageMgmtNetwork.properties.StorageMgmtNetValueSpecs: Value must be a string 2016-02-23 22:58:53 [overcloud]: CREATE_FAILED Resource CREATE failed: resources.Networks: Property error: resources.StorageMgmtNetwork.properties.StorageMgmtNetValueSpecs: Value must be a string Stack overcloud CREATE_IN_PROGRESS Stack overcloud CREATE_FAILED Heat Stack create failed.
Verified: Environment: openstack-tripleo-heat-templates-0.8.10-2.el7ost.noarch The issue doesn't reproduce. Able to complete the deployment successfully.
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://rhn.redhat.com/errata/RHEA-2016-0604.html