Conversation
claudia-lola
temporarily deployed
to
Leafcloud
GitHub Actions
Inactive
claudia-lola
temporarily deployed
to
Leafcloud
GitHub Actions
Inactive
claudia-lola
temporarily deployed
to
Leafcloud
GitHub Actions
Inactive
claudia-lola
had a problem deploying
to
SMS Lab
GitHub Actions
Failure
claudia-lola
had a problem deploying
to
SMS Lab
GitHub Actions
Failure
claudia-lola
had a problem deploying
to
Leafcloud
GitHub Actions
Failure
claudia-lola
had a problem deploying
to
SMS Lab
GitHub Actions
Failure
claudia-lola
had a problem deploying
to
Leafcloud
GitHub Actions
Failure
claudia-lola
had a problem deploying
to
Leafcloud
GitHub Actions
Failure
etc/kayobe/environments/stackhpc-baremetal/ansible/baremetal-0-enroll-overcloud.yml
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-baremetal/ansible/baremetal-0-enroll-overcloud.yml
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-baremetal/ansible/baremetal-1-check-bmc-up.yml
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-baremetal/ansible/recover-baremetal.yml
Show resolved
Hide resolved
|
|
||
| - name: Undeploy baremetals in 'deploy failed' or 'error' state | ||
| ansible.builtin.command: | ||
| cmd: "{{ venv }}/bin/openstack baremetal node undeploy {{ inventory_hostname }}" |
There was a problem hiding this comment.
JohnG "Maybe lets move this into ./baremetal-4-clean.yml, at least for deploy failed."
etc/kayobe/environments/stackhpc-baremetal/inventory/group_vars/baremetal-redfish/ironic
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/ansible/auto-setup.yml
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/ansible/create-virtual-baremetal.yml
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/ansible/sushy-emulator.yml
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/ansible/vbmc-net.xml.j2
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/ansible/vbmc-pool.xml.j2
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/inventory/group_vars/controllers/lvm.yml
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/inventory/group_vars/sushy-libvirt/ironic
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-baremetal/ansible/baremetal-0-enroll-baremetal.yml
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-baremetal/ansible/baremetal-0-enroll-baremetal.yml
Outdated
Show resolved
Hide resolved
dougszumski
left a comment
dougszumski
left a comment
There was a problem hiding this comment.
I think it would help to split this into smaller PRs, like perhaps:
- General support for configuring Ironic and enrolling baremetal nodes
- Support for deploying baremetal nodes for the control plane
- Sushy support for CI testing
What do you think?
etc/kayobe/environments/stackhpc-sushy-baremetal/inventory/group_vars/sushy-libvirt/ironic
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/ansible/sushyemud.service.j2
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/ansible/sushy-2.yml
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/ansible/auto-setup.yml
Outdated
Show resolved
Hide resolved
| ram: "{{ 42 * 1024 }}" | ||
| vcpus: 42 | ||
| disk: 10 | ||
| ephemeral: 10 |
There was a problem hiding this comment.
We should be able to delete this? It's not relevant for BM
| disk: 10 | ||
| ephemeral: 10 | ||
| extra_specs: "{{ { | ||
| ('resources:CUSTOM_' ~ ironic_resource_class | upper ): 1, |
There was a problem hiding this comment.
We don't want user created BM instances to get scheduled to control plane hardware, so should we make this custom resource class specific to the control plane?
call it ironic_control_plane_resource_class or something?
| # todo: Support mutiple resource classes | ||
| run_once: true | ||
|
|
||
| - name: Create key pair for baremetal |
There was a problem hiding this comment.
Create key pair for baremetal control plane instances?
| ----------------------- | ||
|
|
||
| This environment is intended to be layered on top of a base Kayobe environment | ||
| (e.g. ``ci-aio``), so that baremetal-specific defaults override those provided |
There was a problem hiding this comment.
I guess most people will be trying to layer it on to the default kayobe config for non-CI environments? Like production sites etc? It might be helpful to make the primary use case here?
| Baremetal Environment | ||
| ===================== | ||
|
|
||
| This environment provides playbooks to automate the enrollment, inspection |
There was a problem hiding this comment.
It seems to do a lot more than this - like deploying the control plane HW. I am wondering if that part should be split out into another env?
…fish address var in group_vars/sushy-libvirt/ironic
etc/kayobe/environments/stackhpc-sushy-baremetal/inventory/hosts
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/inventory/group_vars/sushy-libvirt/ironic
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/inventory/group_vars/sushy-libvirt/ironic
Outdated
Show resolved
Hide resolved
etc/kayobe/environments/stackhpc-sushy-baremetal/ansible/sushy-setup.yml
Show resolved
Hide resolved
….conf Co-authored-by: Will Szumski <will@stackhpc.com>
…fish address var in group_vars/sushy-libvirt/ironic
assumptionsandg
left a comment
assumptionsandg
left a comment
There was a problem hiding this comment.
Mainly some nit comments
|
|
||
| * ``kayobe overcloud service deploy`` | ||
|
|
||
| * ``source kayobe-config/etc/kolla/admin-openrc.sh`` |
There was a problem hiding this comment.
nit: Would probably be best to say source $KAYOBE_CONFIG_PATH/../kolla/admin-openrc.sh
| @@ -0,0 +1,2 @@ | |||
| libvirt-python | |||
There was a problem hiding this comment.
Should we be pinning these?
etc/kayobe/environments/stackhpc-sushy-baremetal/inventory/group_vars/controllers/lvm.yml
Show resolved
Hide resolved
|
|
||
| * ``kayobe control host bootstrap`` | ||
|
|
||
| * ``kayobe overcloud host configure`` |
There was a problem hiding this comment.
growroot may be potentially necessary? I could be wrong though.
As in the possible deployment sequence might be:
kayobe overcloud host configure -t kayobe-ansible-user
kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/tools/growroot.yml
kayobe overcloud host configure
|
|
||
| * ``kayobe overcloud post configure`` | ||
|
|
||
| Auto-setup script used to set up Sushy and create virtual baremetal within libvirt using the |
There was a problem hiding this comment.
It might be helpful to explain this runs two different Ansible playbooks... as in this auto-setup script first runs through the Sushy Emulator deployment, and then creates the virtual baremetal which is enrolled in the Sushy Emulator.
|
|
||
| ``kayobe playbook run environments/stackhpc-sushy-baremetal/ansible/auto-setup.yml`` | ||
|
|
||
| Scripts from the baremetal env can be run to enroll, inspect and clean virtual baremetal nodes. |
There was a problem hiding this comment.
We could possibly elaborate here that once the virtual baremetal is created from the previous step and is configured in Sushy, we can begin the same enrollment process we use with other baremetal.
| @@ -0,0 +1,10 @@ | |||
| --- | |||
|
|
|||
| stackhpc_release_pulp_username: "skc-ci-aio" | |||
There was a problem hiding this comment.
nit: maybe this could be set to stackhpc_repo_mirror_username from the ci-aio env?
| ansible.builtin.import_playbook: ./sushy-setup.yml | ||
| - name: Create Libvirt vBMC nodes | ||
| ansible.builtin.import_playbook: ./create-virtual-baremetal.yml | ||
|
|
There was a problem hiding this comment.
Linting isn't happy with this extra line
| - python3-devel | ||
| state: present | ||
|
|
||
| - name: Start and enable the QEMU service |
There was a problem hiding this comment.
We do actually have a role than configures a host for libvirt: https://github.com/stackhpc/ansible-role-libvirt-host. Ideally we'd use that, but is there a reason not to?
There was a problem hiding this comment.
Still think these templates should be factor out in a sushy role:
roles/sushy/templates/sushy.conf.j2
...
|
|
||
| #these vars used to be within ironic_driver_info | ||
| ironic_redfish_system_id: "/redfish/v1/Systems/1" | ||
| ironic_redfish_address: "http://192.168.33.3:34343" |
There was a problem hiding this comment.
Is this is specific to the sushy emulator? Should it in that environment?
| # settings for provision-nova.yml | ||
| ironic_provision_network: "provision-net" | ||
| ironic_provision_flavor: "example_resource_class" | ||
| ironic_provision_image: "overcloud-rocky-9-2025.1-20250930T144255" |
There was a problem hiding this comment.
Should we leave this unset and error if it is missing? Possibly using the mandatory filter?
There was a problem hiding this comment.
I agree for the flavor we should leave unset, the image we can likely just set to this or something:
ironic_provision_image: "{{ stackhpc_overcloud_host_image_version }}"
…hpc-kayobe-config into skc-baremetal-environment
|
Build failed. ❌ openstack-tox-pep8 FAILURE in 2m 10s Warning: |
9 participants
No description provided.