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 *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> 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 > https://lists.sourceforge.net/lists/listinfo/xcat-user >
_______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
