Add support for openstack server groups

[lu1as]

Hello,

this PR adds support for specifying a server group in OpenStack node templates, so that it's possible to ensure that for example master nodes were scheduled on different OpenStack compute nodes.

The server group has to be created and configured in OpenStack beforehand. It would be cool if Rancher could manage the server group itself, but I guess that logic is too much for a node driver, so I kept it simple here.

Related issues:

• OpenStack provider: Add support for compute server affinity rancher#16696
• Request: Openstack node driver - add server group option rancher#24696

[lu1as]

Anything wrong with this PR? I tested it with a custom Rancher server image and it seems to work fine.

[iamjla]

This PR's changes look good to me too.
I was motivated to do the same PR until i saw that someone already did the work.
I'll wait until this gets merged as it is a neat feature.

[GillesMocellin]

Hello !
This is really needed to have a real high availability deployment.

[framctr]

This feature would be very helpful for HA.
@rancher/rancher-team-2-hostbusters-dev

[geoffr]

Hiya, is there something holding this back ? We only have Openstack as a provider and this is of real concern.

Thanks very much

[jweiher]

Hi,

I rebased and merged this PR locally and it still works fine. What is the problem with this?

-- Jan

[framctr]

@jweiher

Seems that SUSE does not support OpenStack anymore: https://www.suse.com/support/kb/doc/?id=000020491 .
Maybe, it could be possible to use openstack CAPI with Rancher Turtles in the future.

Anyway, it is always possible to fork the OpenStack node driver in a community project and add all the things it is actually missing.

[pvbouwel]

@jiaqiluo I see you were able to request a review 2 years back. This PR is actually still very relevant for rancher users that use Openstack.

Taking into account the note from framctr I understand Suse does not actively support Openstack issues but I still see it gets some refactor work now and then.

Do you have any insight whether this PR can be moved forward and if so what is needed?

[jiaqiluo]

@pvbouwel, I'll bring this matter to the team for further follow-up.

[jiaqiluo]

It seems that although both fields are exposed, only ServerGroupName is actually used to fetch the ID from the server and then override ServerGroupId. Since this PR has been inactive for years, the existing logic works, and OpenStack is not officially supported in Rancher, I’d consider this acceptable. Any further improvements can be handled by the community.

That being said, the PR LGTM.

(We need one more approval from the team for merging the PR)

[HarrisonWAffel]

LGTM, seems reasonable

[snasovich]

As @framctr noted per https://www.suse.com/support/kb/doc/?id=000020491 OpenStack node driver is not officially supported; however per internal discussions we can accept community contributions provided sufficient testing is done by the community - including confirming no regressions are introduced by the change - and understanding that SUSE's QA has not validated these changes.

The team has already reviewed this PR from "general sanity perspective" but please be aware we're not going to test it against OpenStack environment.

@lu1as / @jweiher / @pvbouwel , could one (or more) of you cover the testing part, specifically provisioning RKE2 clusters with OpenStack in Rancher with AND without newly introduced fields?

Now, the testing w/o merging this PR may be a little involved due to the following:

1. Image used by Rancher to provision VMs for RKE2 provisioning case is determined by machine-provision-image setting (corresponding env var - CATTLE_MACHINE_PROVISION_IMAGE) - so building a custom image with these changes and setting this env var when running Rancher sounds pretty straightforward; however...
2. The code that generates *Config.rke-machine-config.cattle.io CRDs actually uses rancher-machine binary embedded into rancher image itself (in /bin/usr) - and since this PR introduces new fields we do want them to end up on OpenstackConfig CRD to test these changes.

There are multiple options to address above but probably the least involved would be:

1. Build and push custom image from HEAD/https://github.com/rancher/machine/releases/tag/v0.15.0-rancher131 + changes in this PR to Docker Hub (you should be able to leverage existing GHA for this with tweaks like this) - while at it, @lu1as , any chance you could rebase this PR?
2. Build custom Rancher image with updated CATTLE_MACHINE_PROVISION_IMAGE env AND replaced rancher-machine binary, e.g. like this (ensure rancher-machine is the updated binary with the same arch you will be running this Rancher image on.):

FROM rancher/rancher:v2.12.1

COPY rancher-machine /usr/bin/rancher-machine

ENV CATTLE_MACHINE_PROVISION_IMAGE your_rancher_machine_image

Please let me know if one of you could lend a hand in testing this and submitting back test results on this PR? Please also note that RKE1 is EOL and RKE1 provisioning is removed in Rancher v2.12.0+ so this will need to be tested on RKE2.

Thank you in advance!

[lu1as]

@snasovich - PR is rebased, I also updated the commit message to match the new standard.

I haven't used Rancher with RKE for quite a while, but I'll try to update my old Rancher image pipeline and do some testing.

[pvbouwel]

I really appreciate the actions on this.

I'll also need to setup an image pipeline and a dedicated environment for testing this but have some urgent tasks currently. I hope to finish my own testing by end of first week of October.

[lu1as]

I successfully tested the change with Rancher v2.12.1 and RKE v1.33.4+rke2r1 on OpenStack 2024.1 (caracal).

The test cases were:

• RKE2 cluster without defining a server group
• RKE2 cluster with server group name
• RKE2 cluster with server group ID
• RKE2 cluster with server group name that does not exist
  • fails as expected with defined error message during ID lookup
• RKE2 cluster with server group ID that does not exist
  • fails as expected with OpenStack API error message

I also verified that the created OpenStack instances were actually added to the server group. The new fields serverGroupId and serverGroupName correctly appear in the OpenStackConfig CRD and its UI representation, too.

@snasovich - Let me know, if you have more test cases in mind which I should validate.

[snasovich]

@lu1as , sounds good, thank you for testing.
Just curious, which approach did you follow for testing, the one suggested in #151 (comment) or something else?

Also, once we have this PR merged, rancher/machine tagged and bumped in rancher/rancher, would you help testing these scenarios on a rancher/rancher:head image - we'll use those results as validation to close the issues you linked.

[lu1as]

@snasovich - I followed your second approach and replaced the rancher-machine binary in the Rancher image, as this also was the solution I used in the past to build my custom Rancher image.

I can help testing the new Rancher image, of course.