Xena: Rocky 8 AIO scenario #155
Conversation
This configures the hosts to use the mirrors in the local pulp. Prior to this change kayobe would attempt to configure CentOS stream mirrors on a Rocky host.
This improves support out of the box. You still need to make sure that you install a compatible version of ansible in the kayobe virtualenv: ``` git clone https://github.com/stackhpc/stackhpc-kayobe-config -b stackhpc/wallaby cd stackhpc-kayobe-config pip install -U ansible-base@git+https://github.com/stackhpc/ansible@stackhpc/2.10/rocky -e . ``` The above example installs a fork of ansible with support for Rocky 8.
This is the equivalent change of: https://review.opendev.org/c/openstack/ansible-collection-kolla/+/831642 I missed that this is defined again in the ci environment. Note we can remove this duplicate definition in Xena as the kolla globals merging feature landed: https://review.opendev.org/c/openstack/kayobe/+/804068 But this change is cherry-pickable to wallaby.
Should probably test with the defaults.
| - repo: "https://github.com/stackhpc/stackhpc-image-elements" | ||
| local: "{{ source_checkout_path }}/stackhpc-image-elememts" | ||
| version: "v1.4.0" | ||
| # FIXME: merge and tag a new release |
There was a problem hiding this comment.
Not technically need for AIO, so could this split this out. I was just testing with the image produced by DIB. Should we switch to using the LVM based DIB images at some point?
| uuid = data.openstack_images_image_v2.image.id | ||
| source_type = "image" | ||
| volume_size = 100 | ||
| volume_size = 200 |
There was a problem hiding this comment.
This was for the stackhpc LVM layout with the DIB image
|
Is it best to land this change on wallaby? Seems easier to merge up than down? I assumed I should target the latest release, but maybe this was a mistake? |
It is possible to merge up, but not down. You can cherry pick down if necessary though. It might be safer to start with Xena since it's not in use yet. Will we have all the necessary dependencies in Wallaby? |
| @@ -0,0 +1,3 @@ | |||
| --- | |||
| # SASL password when using libvirt on the host | |||
| secrets_libvirt_sasl_password: "{{ secrets_libvirt_sasl_password | default(lookup('password', '/dev/null'), true) }}" | |||
There was a problem hiding this comment.
Could you not use the password lookup plugin, and write the result to a file?
There was a problem hiding this comment.
Could work. Are you imagining to just use that for the AIO? Or would we write it some location in kayobe config? Something like {{ kayobe_config_env_path }}/secrets/libvirt_sasl_password?
| # compute_qemu_conf_extra. | ||
| #compute_qemu_conf: | ||
|
|
||
| # Whether to enable libvirt SASL authentication. Default is true. |
There was a problem hiding this comment.
Do we need a config sync somewhere?
There was a problem hiding this comment.
Think so, will check when these keys landed upstream.
There was a problem hiding this comment.
Trying to fix upstream here: https://review.opendev.org/c/openstack/kayobe/+/856454. Will also need syncing to kayobe-config.
etc/kayobe/compute.yml
Outdated
| # NOTE: You can use: | ||
| # kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/generate-stackhpc-secrets.yml | ||
| # to generate secrets_libvirt_sasl_password. | ||
| compute_libvirt_sasl_password: "{{ secrets_libvirt_sasl_password }}" |
There was a problem hiding this comment.
Probably needs to be in the ci-aio environment?
There was a problem hiding this comment.
Can we keep it in the base config? It isn't used unless you set kolla_enable_nova_libvirt_container to false.
etc/kayobe/kolla.yml
Outdated
| #kolla_enable_kibana: | ||
| #kolla_enable_kuryr: | ||
| #kolla_enable_loadbalancer: | ||
| kolla_enable_nova_libvirt_container: "{{ not os_distribution in ['rocky'] }}" |
| - 'echo "10.205.3.187 pulp-server pulp-server.internal.sms-cloud" >> /etc/hosts' | ||
| # Configure SSH keys here, to avoid creating an ephemeral keypair. | ||
| # This means only the instance needs to be cleaned up if the destroy fails. | ||
| ssh_authorized_keys: |
There was a problem hiding this comment.
IIRC this didn't work for me in the Ubuntu job, unsure which user got the key.
There was a problem hiding this comment.
Cheers, I didn't check this as I only saw the ubuntu PR late and thought I'd adopt the method from there.
This is so we can inject the public key within the userdata. Previously we were using the file function which does not do any templating. This meant that we had the literal string "file(var.ssh_public_key)" in our userdata and consequently could not login.
Internal pulp URLs include minor version
|
Closing in favour of #235. |
I'll rebase this when this when the test is passing. It builds on a few other open PRs.