Support for hybrid KVM / Baremetal deployment

[msherman64]

I wanted to start a thread for discussion of use-cases and caveats when using chi-in-a-box to deploy KVM either by itself, or with baremetal and KVM at a single site/region

[msherman64]

The current caveats I'm aware of are:

1. our fork of horizon needs a patch to bring back the "flavors" tab
2. users may be confused by two different workflows: baremetal using blazar for reservation and selection of nodes, and KVM using just nova flavors + quotas.
3. block storage (cinder), and neutron security groups will work for KVM, but not for baremetal, and may confuse users.

[wehall]

I had to address these two items of the box:

• add post_kvm role to playbooks/post_deploy.yml as in 9dd04d0. Without it, I don't think "enable_kvm: yes" does anything.

• remove the dead CentOS-Stream8 image download from roles/post_kvm/defaults/main.yml

[msherman64]

those make sense to me! Can I ask what your intended deployment looks like?

[wehall]

The players:
Controller – cp1 - a VM with 4 interfaces:
eth0 – VU private net/local subnet - 10.2.218.0/23
eth1 – private net - 10.2.160.0/24,192.168.0.0/24
eth2 – no IP, neutron "raw" interface
eth3 – no IP, neutron "raw" interface

Compute nodes: cnN - Dells with 2 interfaces:
eno1 – 10.2.160.0/24, shared iDRAC in 192.168.0.0/24
eno2 – currently unused

The stage:
cp1:eth1 is connected to switchA via a trunk’ed port
cnN:eno1 is connected to switchA via access port
cp1:eth2 is connected to switchB, with access to public subnet
cp1:eth3 is connected to switchB via trunk'ed port (distinct from cp1:eth2)
cnN:eno2 is connected to switchB via access port

The play:
CiB offering web interfaces in 10.2.218.0
CiB offering api services in 10.2.160.0
cp1:eth2 in cp1:br-ex for public tenant traffic
cp1:eth3 in cp1:br-int for private tenant traffic
cnN:eno1 is used for all traffic
cnN:eno2 unused
(Future:) cnN:eno1 for management traffic, cnN:eno2 for public/tenant traffic

At the moment, all deploys without issue, but instance launch dies with "Binding failed for port" from nova, a "Port not present in bridge br-int" from neutron-openvswitch-agent on the compute nodes. This looks to be an oversight in the ml2 sections of the compute node openvswitch-agent.ini, but I haven't found a solution.