Migrate from CAPO Internal OpenStackServer Controller to External ORC Controller

[lentzi90]

The Cluster API Provider OpenStack (CAPO) project has its own internal OpenStackServer CRD and controller for legacy reasons. The project has started transitioning to use the external OpenStack Resource Controller (ORC) instead.

The initial step of this migration was completed in PR #2346: 🌱 Remove ORC from CAPO. In that PR, the internal ORC integration and related code were removed so that CAPO would rely on an external, out-of-tree ORC deployment. However, the transition was not fully completed, and the largest remaining task is to get rid of the internal OpenStackServer implementation.

We need to be extra careful about the upgrade and transition from the internal OpenStackServer to the ORC implementation. We will need at least one minor release where both are supported and where CAPO actively migrates resources. Some kind of test for this is also needed.

Why do we need to do this? We risk diverging from ORC, we have to maintain our own controller. It would simply be preferable to adopt ORC and have one less thing to worry about.

[mandre]

I can take this one. I'll first need to check if there's a feature gap between what CAPO exposes for the server creation and what ORC provides.
/assign

[mandre]

OK, we're not there yet 😅. Here's a gap analysis between what CAPO offers and what ORC currently supports.

CAPO's OpenStackMachineSpec	ORC	Note
Flavor	✔️ (FlavorRef)
Image	✔️ (ImageRef)	They're effectly the same as CAPO leverages ORC for it
SSHKeyName	❌	KeyPair controller is WIP
Ports	❌	See details below
Port Network	✔️
Port Description	✔️
Port FixedIPs	✔️ (Port's Addresses)
Port SecurityGroups	✔️ (Port's SecurityGroupRefs)
Port Tags	✔️ (Port's Tags)
Port Trunk	❌	Need to extend the Port controller
Port AdminStateUp	❌	Need to extend the Port controller
Port MACAddress	❌	Need to extend the Port controller
Port AllowedAddressPairs	✔️ (Port's AllowedAddressPairs)
Port HostID	❌	Need a Host controller
Port VNICType	✔️ (Port's VNICType)
Port Profile	❌	Need to extend the Port controller
Port DisablePortSecurity	✔️ (Port's PortSecurity)
Port PropagateUplinkStatus	❌	Need to extend the Port controller
Port ValueSpecs	❌	Need to extend the Port controller
SecurityGroups	✔️ (Port's SecurityGroupRefs)	Managed individually, per port
Trunk	❌	Missing a Trunk controller
Tags	✔️ (Tags)
ServerMetadata	❌	Need to extend Server controller
ConfigDrive	❌	Need to extend Server controller
RootVolume	❌	Need to extend Server and Volume controllers
AdditionalBlockDevices	⚠️ (VolumeRefs)	Need to extend Volume controller to support AZ
ServerGroup	✔️ (ServerGroupRef)
IdentityRef	⚠️ (CloudCredentialsRef)	Might need to adapt
FloatingIPPoolRef	⚠️	ORC has a FloatingIP controller, might be able to leverage it
SchedulerHintAdditionalProperties	❌	Need to extend Server controller

[lentzi90]

Thank you for this valuable analysis!

@bnallapeta @huxcrux @bilbobrovall you three have been involved in the CloudCredentialsRef and FloatingIPPoolRef features. Would it be possible for you to take a look at implementing these in ORC? Or at least look into how we might adopt the ORC Server controller and keep these features.

[mandre]

However, this isn't as bad as it looks because:

• we have open PRs for KeyPair and Trunk controllers (the bulk of the work)
• it's relatively straightforward to add missing fields to existing controllers like I did for AZ support in the volume controller