True that satellite registration with diskless is very much not consistent with
RedHat view of how OSes live. There may be some opportunity to fix this,
analogous to how confluent uses the TPM2 to manage ssh certificate entitlement
persisting node identity securely across reboot, perhaps the same can be done
for satellite. This may warrant work if people want satellite registered
nodes rather than satellite updated images. Note though that while updates to
running stateless nodes is possible, any rpm update will change content from
being boot server hosted to ram-hosted that can't be evicted, so you'll save
memory by having updated profile and booting to it when possible rather than
in-place updates.
Note that in confluent, the default diskless will leave the image on the server
and to fetch/cache on demand. Basically a multipath https filesystem replaces
downloading it and extracting. Also the read-write is changed to zram instead
of uncompressed. A tethered mode will download upfront but leave it squashfs.
Another diskless difference is on an unpacked image, you can imgutil exec
<path> yum update, and any updates, including kernel and driver updates will
land appropriately in the os profile when packed. No more geninitrd needed, and
imgutil exec uses the right mount namespaces and pid namespaces and bind mounts
and such to have a functional environment to update normally.
Also, we have ansible hooks for deployment. If an os profile has an
ansible/post.d, the plays will target nodes hitting that phase of installation
automatically, ansible/firstboot.d/ for plays to target the nodes hitting
firstboot, and ansible/onboot.d/ for diskless every boot plays.
Ultimately though, people may like doing:
# nodediscover list -t pxe-client -f mac,switch,port -o port
Mac| Switch| Port
------------------|-------|-----------
08:94:ef:3f:e1:32| r4c1| bond0
08:94:ef:4e:13:fa| r4c1| swp35
08:94:ef:4e:15:68| r4c1| swp36
7c:8a:e1:c7:d0:09| r4c1| swp45
7c:8a:e1:c7:ce:17| r4c1| swp46
7c:8a:e1:ce:02:0d| r4c1| swp47
7c:8a:e1:c7:ce:a1| r4c1| swp48
Or using the api or csv to just gather pxe mac addresses based on port, even if
you don't define confluent nodes.
Sorry if I'm going too offtopic by discussing confluent a bit much, but just
wanted to share that we are trying to advance the state of things to hopefully
be easier and useful.
From: Kevin Keane <kke...@sandiego.edu>
Sent: Monday, November 8, 2021 11:07 AM
To: xCAT Users Mailing list <xcat-user@lists.sourceforge.net>
Subject: [External] Re: [xcat-user] RedHat Satellite and xCAT stateful installs
Seems like your use case is very similar to ours - we also have an HPC. But I
abandoned stateless compute nodes, and we don't need discovery. Several reasons:
- Stateless booting wreaks havoc with Satellite registration.
- Applying updates to stateless images is difficult, while it's trivial using
Satellite. Of course, YMMV on this.
- Stateful installation makes (slightly) more memory available on the compute
nodes.
- We rarely add nodes, so discovery isn't important. We simply use an Ansible
list with MAC address, IP address and name. We maintain it manually, but it
could also be scripted from DHCP logs or the like.
My process takes longer than yours, because it involves an Ansible run.
_______________________________________________________________________
Kevin Keane | Systems Architect | University of San Diego ITS |
kke...@sandiego.edu<mailto:kke...@sandiego.edu>
Pronouns: he/him/his
Maher Hall, 162 |5998 Alcalá Park | San Diego, CA 92110-2492 | 619.260.6859 |
Text: 760-721-8339
REMEMBER! No one from IT at USD will ever ask to confirm or supply your
password.
These messages are an attempt to steal your username and password. Please do
not reply to, click the links within, or open the attachments of these
messages. Delete them!
On Mon, Nov 8, 2021 at 5:14 AM THomas HUMMEL
<thomas.hum...@pasteur.fr<mailto:thomas.hum...@pasteur.fr>> wrote:
On 11/3/21 04:11, Kevin Keane wrote:
> I have made the almost exact same migration a few months ago
Hello, thanks for your answer.
> The only difference is that I'm not using xCAT at all any more.
> Satellite can do the same thing as xCAT's stateful installation using
> PXE booting. Instead of post scripts etc., I'm using Ansible. Note that
> PXE booting will work even if your data center only uses static IP
> addresses, as ours does!
I agree that for stateful installs, xCAT is just a kickstart wrapper in
our use case and native RH Satellite install would probably be easier.
However, we're using xCAT for provisionning an HPC cluster which
stateful nodes are just a few admin hosts. Most of nodes are compute
stateless compute servers. There are far more compute nodes than the
other types and batch of new compute nodes are regularily bought by users.
For those stateless servers, key xCAT features for us are:
1) switch-based discovery combined with:
2) regexp/formula to automatically generate predictable and consistent
names and ip addresses
3) BMC remote commands like reventlog, rpower
4) in a very limited way postscripts (we only use confignetwork -s to
"statify" DHCP provided fixed ip addresses and a synclist to fixate
hostkeys on stateless nodes)
This enables us to just nodeadd/makedhcp/makedns and rack a bunch of
servers and have them ready a few minute later to be configured by an
ansible playbook. More important, they can be once unboxed, powered up
all at the same time, not one at a time and still comply to the
naming/numbering scheme and order we want.
We don't use NAT, nodes are accessible under some restrictions.
We've got one vlan for data, one vlan for ipmi
An external DNS is feeded by xCAT on one side, by ansible on the other side.
We find this setup to be the right balance for automation and flexibility.
> In host groups, configure all the stuff you would ordinarily configure
> at the host level. Satellite Server will pick up those values when it
> auto-creates your nodes during the PXE-Boot process.
Again, the issue I'd have is that I'd want a discovery (similar to
switch-based) mechanism to be able to coexist with the stateful
installation process because I want my new stateless nodes to follow, in
order, the naming and numbering schemes I'm using and don't want to
power then up one at a time.
Hence my initial idea to continue using xCAT for the PXE/ks part with
the problems I mentionned in my initial post.
Thanks for your time and answer anyway !
--
Thomas HUMMEL
_______________________________________________
xCAT-user mailing list
xCAT-user@lists.sourceforge.net<mailto:xCAT-user@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/xcat-user<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fxcat-user&data=04%7C01%7Cjjohnson2%40lenovo.com%7Cfa395445185344a6be3c08d9a2d4cb8e%7C5c7d0b28bdf8410caa934df372b16203%7C1%7C0%7C637719857100116824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qegjtYhnPbdRtpi%2BGjlBGreP17WjX6cZG6HLrPxwm2o%3D&reserved=0>
_______________________________________________
xCAT-user mailing list
xCAT-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcat-user
