Open Stack

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?

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