Description of problem: We don't have flexibility to set the predicate IPs for the provisioning network. Cu wants to have the control over provisioning network IPs. Version-Release number of selected component (if applicable): RHEL OSP 8 How reproducible: Everytime. Steps to Reproduce: - We can set the predictable IPs for all networks except provisioning network. - We have introduced management network in RHEL OSP 8 which can also have predictable IPs. Actual results: No option to have predictable IPs for provisioning network. Expected results: Cu wants to have predictable provisioning networks. Additional info: -- I suggested Cu to use management network with which they can have predictable IPs. Cu response on suggestion : ~~~ Having predictable IP addresses inside the provisioning network can be an alternative to the management network introduced in OSP 8. In my specific case I already have a number of separated networks: - nic1 : provisioning connected to an access port on the switch - nic2: internal, storage, storage mgmt, tenant, external connected to a trunk port on the switch. This is configured in a way that the native VLAN of that port is used for floating IPs while all other VLANs are tagged. Adding yet another network just to have access via predictable IPs wouldn't add any benefit other then having predictable IPs. On the other hand it would add unnecessary implications like: - added administrative effort on the switches - moving management traffic from nic1 to nic2 (yes, this could be avoided with correct templates but then again I can't just use an access port on the switch for nic1) ~~~
Networking for Hardware Provisioning team.
*** Bug 1261638 has been marked as a duplicate of this bug. ***
This feature has been implemented upstream in this patch: https://review.openstack.org/#/c/568505/ It will be included in OSP 14.
Verified: Environment: openstack-tripleo-heat-templates-9.0.0-0.20180919080941.0rc1.0rc1.el7ost.noarch This is achievable with adding a yaml to overcloud deployment with something like: parameter_defaults: <controller rolename>IPs: # Each controller will get an IP from the lists below, first controller, first IP ctlplane: - 10.37.168.81 - 10.37.168.82 - 10.37.168.83 <compute rolename>IPs: # Each compute will get an IP from the lists below, first compute, first IP ctlplane: - 10.37.168.151 - 10.37.168.152 <CephStorage role>IPs: # Each ceph node will get an IP from the lists below, first node, first IP ctlplane: - 10.37.168.161 - 10.37.168.162
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-2019:0045