Replies: 2 comments
-
The PXE profile of a node may be determined as follows: j2_ep_groups: "{{ groups | select('match','^'+bb_core_equipment_naming+'_.*') | list | unique | sort }}"
j2_pxe_profile: "
{%- set ep_groups = group_names | select('match', '^'+bb_core_equipment_naming+'_.*') | list | sort %}
{%- set ep_grp_count = ep_groups | length %}
{%- if ep_grp_count > 1 %}
{{ undefined | mandatory('Host ' + inventory_hostname + ' belongs to multiple (' ~ ep_grp_count ~ ') EP groups: ' + ep_groups | join(' + ')) }}
{%- endif %}
{%- set hw_groups = group_names | select('match', '^'+bb_core_hw_naming+'_.*') | list | sort %}
{%- set hw_grp_count = hw_groups | length %}
{%- if hw_grp_count > 1 %}
{{ undefined | mandatory('Host ' + inventory_hostname + ' belongs to multiple (' ~ hw_grp_count ~ ') HW groups: ' + hw_groups | join(' + ')) }}
{%- endif %}
{%- set os_groups = group_names | select('match', '^'+bb_core_os_naming+'_.*') | list | sort %}
{%- set os_grp_count = os_groups | length %}
{%- if os_grp_count > 1 %}
{{ undefined | mandatory('Host '+ inventory_hostname + ' belongs to multiple (' ~ os_grp_count ~ ') OS groups: ' + os_groups | join(' + ')) }}
{%- endif %}
{%- if hw_grp_count == 1 and os_grp_count == 1 and ep_grp_count == 0 %}
{%- set hw_grp = hw_groups | first | regex_replace('^'+bb_core_hw_naming+'_', '') | trim %}
{%- set os_grp = os_groups | first | regex_replace('^'+bb_core_os_naming+'_', '') | trim %}
{{- hw_grp }}-{{ os_grp }}
{%- elif hw_grp_count == 0 and os_grp_count == 0 and ep_grp_count == 1 %}
{%- set ep_grp = ep_groups | first | regex_replace('^'+bb_core_equipment_naming+'_', '') | trim %}
{{- ep_grp }}
{%- else %}
{{- undefined | mandatory('Inconsistent group membership for host ' + inventory_hostname + ': ' + (ep_groups+hw_groups+os_groups) | join(' + ')) }}
{%- endif -%}
" That piece of code not only determines the PXE profile of a node, but also checks whether the user created a consistent inventory:
Of course, that code may be split in its 2 functions:
The j2_pxe_profiles: "
{%- set ns=namespace(profiles={}) %}
{%- for node in hostvars | dict2items | selectattr('value.os_specification', 'defined') | map(attribute='key') %}
{%- set prfl = hostvars[node]['j2_pxe_profile'] %}
{%- set ns.profiles = ns.profiles | combine({ prfl : node }) %}
{%- endfor %}
{{- ns.profiles -}}
" (here, The j2_pxe_profiles:
dgx1-dgxos_5: dgx1
r423_e4i-ubuntu_20_04: node04
r423_e4m_efi-rhel_9_2: node01
r423_e4m_efi-ubuntu_20_04: node02
r424_f3-ubuntu_20_04: master04
x430_a5_sw_raid-ubuntu_20_04: popserver04
x430_e5-ubuntu_20_04: node03
x440_a5_diskless-rhel_9_2: node08 The keys of the dict are:
The values are the name of one of the hosts which belong to that PXE profile (either the EP group, or the combination of the HW & OS groups). This is to hide this trick in the Defining those variables makes the required updates to the 🚨: for performance, avoid using those 2 variables ( ansible.builtin.set_fact:
pxe_profiles: "{{ j2_pxe_profiles }}" (in my test environment with few nodes but many HW & OS groups, the More later... |
Beta Was this translation helpful? Give feedback.
-
The benefit of that distribution-agnostic Here are a few examples illustrating the Simplest partitioning for a UEFI platform
hw_disks:
- drives:
/dev/sda:
partitions:
/:
efi: Simplest partitioning for a BIOS platform
hw_disks:
- drives:
/dev/sda:
partitions:
/:
biosboot: Complete, commented examplehw_disks:
- raid_level: 1 # Software RAID level
drives:
/dev/nvme2n1:
/dev/nvme3n1:
partitions:
/:
efi:
- drives: # No RAID level specified → no software RAID (may be hardware RAID, does not matter here), only one drive allowed in this list
/dev/sda:
path: "/dev/disk/by-path/pci-0000:18:00.0-scsi-0:0:11:0" # Optional - Used by the RedHat installer only
device: "/devices/pci0000:17/0000:17:02.0/0000:18:00.0/host0/target0:0:11/0:0:11:0/block/sda" # Optional - Used by Ubuntu installer only
model: "SAMSUNG_MZ7KH480" # Optional - Used by Ubuntu installer only
partitions:
/tmp:
size: 10240 # Optional - unit = MiB - rest of the storage space if omitted
fstype: ext4 # Optional - XFS if omitted
swap: # fstype is optional - fstype=swap if omitted - only supported value is 'swap'
size: 4096
/home: # No size specified → rest of the available storage space # No fstype specified: XFS by default
- raid_level: 0 # Software RAID level
drives:
/dev/nvme0n1:
model: "KCM6DRUL3T84"
/dev/nvme1n1:
model: "KCM6DRUL3T84"
/dev/nvme4n1:
model: "KCM6DRUL3T84"
/dev/nvme5n1:
model: "KCM6DRUL3T84"
partitions:
/scratch: # Use total storage space # XFS format by default Supported
Limitations:
More later... |
Beta Was this translation helpful? Give feedback.
-
2.X to 3.X major changes
@sla31 came with a very interesting proposal: split current
ep_
groups into 2 entities:hw_
andos_
, as more and more clusters are mixing OS on same hardware.A change like that right now would immediately end 2.X devs and focus on releasing an upgraded 2.X version that would be a 3.X due to this very intrusive change.
Objectives
Groups split
Objective: split current
ep_
groups into 2,hw_
andos_
because it often happen that a cluster have same kind of server with mutliple kind of OS profiles (RHEL 8 and RHEL 9 at the same time, Ubuntu and RHEL, etc).Having 2 layers, aka hardware and OS, would ease usage and swap of servers OS profiles while being able to retain hardware profile. It also helps distribute hardware pre-made profiles.
This is similar to: IaaS (infrastructure = HW), PaaS (platform = OS), SaaS (service = application)
BlueBanquise Infrastructure collection will cover IaaS and PaaS, while other collections whould provide SaaS.
Constraints:
ep_
variables, using precedence piping mechanism (os and hw win againts ep).groups("stuf")[0]
to allow hostvars level usage (due to more and more BMC having dedicated credentials). (Prometheus identified as impacted)Rename mg_ groups
Need a new name as "master groups" is not really clear. "Roles" would be nice but conflicts with Ansible roles.
Purpose ? Function ? Profile ? To be determined. These groups will become more important as they will be used for playbooks in toolings.
Implementation
Groups split
os_partitioning
>ep_partitioning
>hw_disks
hw_disks
being a specific mechanisme that can auto-populate automated install files.os_partitioning
and formerep_partitioning
are raw content.hw_consoles
is a listIn iPXE templates:
"set eq-console {{ ['console='] | product( (['tty0','tty1'] + hw_consoles) | unique ) | map('join') | join(' ') }}"
New
hw_architecture
, to define CPU arch, will be needed in some specific roles.Document possibility to retro compatible with
"ep_hardware.cpu.architecture: {{ hw_architecture }}"
ep_hardware
to be renamedhw_specs
and that contains hardware definition. Be extra precise this time with format, as it will be used by many roles now.ep_host_authentication
to be renamed, likehw_mgmt_authentication
orhw_board_communication
orhw_communication_protocol
or similar. To be defined but have to be clear it is not OS related (not os password).hw_kernel_parameters
should be available alongos_kernel_parameters
as both could be used (some specific parameter linked to hardware, and then another one related to a specific OS).set eq-kernel-parameters {{ nodevars['hw_kernel_parameters'] | default('') }} {{ nodevars['os_kernel_parameters'] | default('') }}
ep_equipment_type
becomehw_equipment_type
, provide a list as standard but allow custom values.pxe_stack_node_main_network_interface
has disapear, blame and investigate why, and fix this.os_extra_install_repos
andos_packages_to_install_with_os_install
or similar to add to pxe_stack role.ep_autoinstall_custom_content
to be renamed os_...All other
ep_
variables have to be sorted betweenos_
andhw_
groups.This needs to add new j2 variables, like but not only:
Also, add a small and quick validation role, that scan hosts to check if they belong to both an os_ group and an hw_ group. Check if it does not conflicts with current BB 2.X since this version allows to simplify cluster using a single all group with roles dedicated variables.
Beta Was this translation helpful? Give feedback.
All reactions