[kayobe][kolla][ironic] kayobe overcloud provision fails because ironic compute hosts use their inspection DHCP pool IPs

Mark Goddard mark at stackhpc.com
Thu Oct 14 09:59:22 UTC 2021


On Wed, 13 Oct 2021 at 18:49, Manuel Holtgrewe <zyklenfrei at gmail.com> wrote:
>
> Dear list,
>
> I am experimenting with kayobe to deploy a test installation of
> OpenStack wallaby. You can find my configuration here:
>
> https://github.com/openstack/kayobe-config/compare/stable/wallaby...holtgrewe:my-wallaby?expand=1
>
> I am following the kayobe documentation and have successfully setup a
> controller and a seed node.
>
> I am at the point where I have the nodes configured and they show up
> in bifrost baremetal node list. I can control them via
> IPMI/iDRAC/RedFish and boot them into the IPA image and the nodes can
> be inspected and actually go into the "manageable" status. kayobe is
> capable of using the inspection results and assigning the root device,
> so far, so good.
>
> I don't know whether my network configuration is good. I want to pin
> the IPs of stack-1 to stack-4 and the names resolve the correct IP
> addresses throughout my network.
>
> Below are some more details. In summary, I have trouble because
> `kayobe overcloud provision` makes my 4 overcloud bare metal host boot
> into IPA with DHCP enabled and they get the same IPs assigned that
> were given to them earlier in inspection. This means that the
> overcloud provision command cannot SSH into the nodes because it knows
> them by the wrong IPs.
>
> I must be really missing something here. What is it?

Hi Manuel. Bifrost will assign IPs from its IP address pool to the
machines during inspection and provisioning. IPA will use these
addresses. Once provisioning is complete, the machines should boot up
into a CentOS image, using the IPs you have allocated. These are
statically configured via a configdrive, which is installed during
provisioning. If the node stays running IPA, then something is going
wrong with provisioning.
Mark

>
> Below are more details.
>
> Here is what kayobe pulled from the bifrost inspection (I believe).
>
> # cat etc/kayobe/inventory/overcloud
> [controllers]
> stack-1 ipmi_address=172.16.66.41 bmc_type=idrac
> stack-2 ipmi_address=172.16.66.42 bmc_type=idrac
> stack-3 ipmi_address=172.16.66.43 bmc_type=idrac
> stack-4 ipmi_address=172.16.66.44 bmc_type=idrac
>
> The IPs are also fixed here
>
> # etc/kayobe/network-allocation.yml
> compute_net_ips:
>   stack-1: 172.16.32.11
>   stack-2: 172.16.32.12
>   stack-3: 172.16.32.13
>   stack-4: 172.16.32.14
>   stack-seed: 172.16.32.6
>
> However, I thought I had to provide allocation ranges for DHCP for
> getting introspection to work.
>
> Thus, I have the following
>
> # etc/kayobe/networks.yml
> compute_net_cidr: 172.16.32.0/19
> compute_net_gateway: 172.16.32.1
> compute_net_vip_address: 172.16.32.2
> compute_net_allocation_pool_start: 172.16.32.101
> compute_net_allocation_pool_end: 172.16.32.200
> compute_net_inspection_allocation_pool_start: 172.16.32.201
> compute_net_inspection_allocation_pool_end: 172.16.32.250
>
> This leads to the following dnsmasq leases in the bifrost host.
>
> # cat /var/lib/dnsmasq/dnsmasq.leases
> 1634187260 REDACTED 172.16.32.215 * REDACTED
> 1634187271 REDACTED 172.16.32.243 * REDACTED
> 1634187257 REDACTED 172.16.32.207 * REDACTED
> 1634187258 REDACTED 172.16.32.218 * REDACTED
>
> What am I missing?
>
> Best wishes,
> Manuel
>



More information about the openstack-discuss mailing list