Overcloud nodes deployed by OSP-Director are using DHCP; can they be statically assigned instead? I understand that at this time provisioning must happen via DHCP, although you are exploring the possibility of first assigning overcloud addresses via DHCP, then converting to static IP addresses. This is an RFE to track this. Additionally, would it be possible for a user to assign the desired IP address in one of the yaml files before, so that the desired IP could be associated with the MAC address early on?
If you are deploying with network isolation, the only interfaces that are DHCPd are the ones Neutron DHCP configures on the control plane. We have discussed setting those addresses statically once the machines are provisioned to remove the DHCP dependency -- it seems like a good idea. I would imagine this could be done manually with the current code, but I'd need to check with Dan Prince to be sure.
Dan, Can we set those interface manually after deployment? John
(In reply to John Fulton from comment #0) > Overcloud nodes deployed by OSP-Director are using DHCP; can they be > statically assigned instead? We would like to move towards being able to support this upstream. We actually have access to the assigned IP address in Heat so we should be able to switch over to a static configuration. The complexity is around making sure the default route and special 169.254.169.254/32 routes get set appropriately for the static network configurations. > > I understand that at this time provisioning must happen via DHCP, although > you are exploring the possibility of first assigning overcloud addresses via > DHCP, then converting to static IP addresses. This is an RFE to track this. > > Additionally, would it be possible for a user to assign the desired IP > address in one of the yaml files before, so that the desired IP could be > associated with the MAC address early on? All of the IP addresses for the provisioning network are assigned via the Neutron 'ctplane' network. We would likely use Neutron for IPAM regardless of whether static or DHCP is used on the nodes. Using Neutron we have the capability to restrict the range of IPs requested on a subnet... but this isn't for just a single machine, it is for the whole set. Say your overcloud has 15 machines you would need to assign 15 ctlplane network IPs. I'm slightly confused by the request for IP pre-assignment here. Is this for a specific machine perhaps? Or for all machines on the network? Also, this sort of sounds to me like a separate requirement and might best be handled in a unique ticket. I don't think it is related to the previous issue of configuring IP addresses statically.
Dan, can we make this static assignment manually post-deployment with the code we have right now or we'll need extra patches? If we can do it right now, can you either post instructions or point to them elsewhere?
(In reply to Rafael Rosa from comment #8) > Dan, can we make this static assignment manually post-deployment with the > code we have right now or we'll need extra patches? Hi Rafael, An ad-hoc script to do this post deployment would work so long as the interfaces aren't being managed by os-net-config templates already. I think the best option would be to integrate this directly into the Heat network config templates. We've got an upstream patch up for review now: https://review.openstack.org/#/c/206022/ Still a few details being worked out but it is close. > > If we can do it right now, can you either post instructions or point to them > elsewhere?
[stack@bldr16cc09 ~]$ nova list +--------------------------------------+------------------------+--------+------------+-------------+---------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+------------------------+--------+------------+-------------+---------------------+ | edfe32ca-51ca-486e-bfc9-7c38b30410e9 | overcloud-compute-0 | ACTIVE | - | Running | ctlplane=10.3.58.14 | | d482fc52-c63f-4dd4-aea9-93bc050910c6 | overcloud-controller-0 | ACTIVE | - | Running | ctlplane=10.3.58.13 | +--------------------------------------+------------------------+--------+------------+-------------+---------------------+ [stack@bldr16cc09 ~]$ ssh heat-admin.58.13 'sudo grep -B1 10.3.58.13 /etc/sysconfig/network-scripts/ifcfg*' /etc/sysconfig/network-scripts/ifcfg-br-ex-BOOTPROTO=static /etc/sysconfig/network-scripts/ifcfg-br-ex:IPADDR=10.3.58.13 [stack@bldr16cc09 ~]$ ssh heat-admin.58.14 'sudo grep -B1 10.3.58.14 /etc/sysconfig/network-scripts/ifcfg*' /etc/sysconfig/network-scripts/ifcfg-br-ex-BOOTPROTO=static /etc/sysconfig/network-scripts/ifcfg-br-ex:IPADDR=10.3.58.14
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/RHSA-2015:1862