Alex - the first step should be as you indicated - remove the invalid template files network_data.yaml and network-environment.yaml. Do you have the templates that were used in the original deploy? Those should be reused. Next step is you may need to restore the heat DB, but its not clear if that is necessary. When switching between network-isolation and non-network-isolation and redeploying you will often get "Physical network XXX is in use" errors, for example [1]. I don't think you will have that problem when using the "openstack overcloud update prepare" but its worth checking the neutron log files for similar type errors from the previous deployment. If so, and you did not save the heat DB, the heat DB will have to be restored using a method similar to [1], the heat team can help with this. Next is to determine why the "openstack overcloud update prepare" command is failing, you should look for errors in heat/mistral logs. Sorry to farm this out but as I mentioned earlier the Upgrades DFG would probably be the most helpful for this update command along with doing a minor update in general. Its good that this is a staging environment, are they using this to test for a production update? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1483246
Thanks Ilyas, yes I suggest that they redeploy this test environment instead of attempting to recover the DB.
Hi Bob! Huge thanks for your follow-ups. We will try to re-run "openstack overcloud update prepare ..." command without network isolation and understand what is the issue there. At the same time, I would like to ask you to help me to understand the current options for networking setup of pre-provisioned nodes in RHOSP 13. Let me explain the point. We know that old behavior was changed [1] somewhere around Z5 minor release and now network-isolation works differently. So I am wondering, if we still can configure overclouds templates for pre-provisioned nodes in a way that will allow us to 1. Use assigned IP addresses for CTLPLANE network [2] 2. Have isolated storage network (and this network ONLY) [2] If there is a way to configure this setup, what should be the templates? Kind Regards, Alex S. [1] https://access.redhat.com/solutions/4300061 https://bugzilla.redhat.com/show_bug.cgi?id=1643423 [2] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/director_installation_and_usage/index#sect-Configuring_Network_Interfaces_for_the_Control_Plane
Alex, you can assign the IPs for both the Control Plane and Storage networks. See openstack-tripleo-heat-templates/environmants/ips-from-pool-all.yaml, but create a custom version where you remove all references to networks other than ctlplane and storage. Each node will have to be specified with ctlplane and storage fixed IPs in the custom ips-from-pool-all.yaml. In order to deploy with only those two networks, you will need a custom network_data.yaml where the Storage network is defined with the proper IP subnet, and all other networks are marked with "enabled: false". For instance, your ips-from-pool-all.yaml will look something like this if you had 3 controllers and 5 computes (add other roles if applicable): resource_registry: OS::TripleO::Controller::Ports::StoragePort: ../network/ports/storage_from_pool.yaml OS::TripleO::Compute::Ports::StoragePort: ../network/ports/storage_from_pool.yaml parameter_defaults: ControllerIPs: # Each controller will get an IP from the lists below, first controller, first IP ctlplane: - 192.168.24.249 - 192.168.24.250 - 192.168.24.251 storage: - 172.16.1.249 - 172.16.1.250 - 172.16.1.251 ComputeIPs: # Each compute will get an IP from the lists below, first compute, first IP ctlplane: - 192.168.24.10 - 192.168.24.11 - 192.168.24.12 - 192.168.24.13 - 192.168.24.14 storage: - 172.16.1.10 - 172.16.1.11 - 172.16.1.12 - 172.16.1.13 - 172.16.1.14 Your custom network-isolation.yaml will look like this (you don't need port definitions for the roles, since that is covered in ips-from-pool-all.yaml): resource_registry: # networks as defined in network_data.yaml OS::TripleO::Network::Storage: ../network/storage.yaml # Port assignments for the VIPs OS::TripleO::Network::Ports::StorageVipPort: ../network/ports/storage.yaml You will need a custom deployed-server-roles-data.yaml file that will include references to only the Storage network in all applicable roles: - name: ControllerDeployedServer CountDefault: 1 disable_constraints: True tags: - primary - controller networks: - Storage [...] - name: ComputeDeployedServer CountDefault: 1 HostnameFormatDefault: '%stackname%-novacompute-%index%' disable_constraints: True disable_upgrade_deployment: True networks: - Storage When you deploy, you need to point to the custom network_data.yaml, deployed-server-roles-data.yaml, and network-isolation.yaml: openstack overcloud update prepare -v \ --log-file $LOGFILE \ --disable-validations \ --templates /usr/share/openstack-tripleo-heat-templates \ --stack overcloud \ -r /home/stack/templates/deployed-server-roles-data.yaml \ -n /home/stack/templates/network_data.yaml \ -e /home/stack/templates/network-isolation.yaml \ [...]
Alex - closing this for now as Dan has provided the recommended network. Please reopen if you need more info.
Verified according to steps described above
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-2020:0760
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days