<div dir="ltr">As Gavin mentioned there are options to configure for Ansible et al.<div><br></div><div>With any configuration management tool de jour you can configure your DHCP, TFTP, and HTTP for PXE and then enforce a desired state on the nodes. I am a developer on several configuration management tools and from the mailing list the speed issues come from people doing things the hard way.</div><div><br></div><div>If you need an API, try Open Stack Ironic</div><div><br></div><div>Saltstack has a GUI if you need warm and fuzzy</div><div><br></div><div>Python Fabric + expect can do anything at speed but will require some thinking.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 12, 2017 at 11:07 AM, Gavin W. Burris <span dir="ltr"><<a href="mailto:bug@wharton.upenn.edu" target="_blank">bug@wharton.upenn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, All.<br>
<br>
We use a minimal pxe kickstart for hardware nodes, then Ansible after that.  It is a thing of beauty to have the entire cluster defined in one git repo.  This also lends itself to configuring cloud node images with the exact same code.  Reusable roles and conditionals, FTW!<br>
<br>
With regards to scaling, Ansible will by default fork only 8 parallel processes.  This can be scaled way up, maybe hundreds at a time.  If there are thousands of states / idempotent plays to run on a single host, those are going to take some time regardless of the configuration language, correct?  A solution would be to tag up the plays and only run required tags during an update, versus a full run on fresh installs.  The fact caching feature may help here.  SSH accelerated mode or pipelining are newer feature, too, which will reduce the number of new connections required, a big time saver.<br>
<br>
Cheers.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue 09/05/17 02:57AM EDT, Carsten Aulbert wrote:<br>
> Hi<br>
><br>
> On 09/05/17 08:43, Stu Midgley wrote:<br>
> > Interesting.  Ansible has come up a few times.<br>
> ><br>
> > Our largest cluster is 2000 KNL nodes and we are looking towards 10k...<br>
> > so it needs to scale well :)<br>
> ><br>
> We went with ansible at the end of 2015 until we hit a road block with<br>
> it not using a client daemon a fat ferew months. When having a few 1000<br>
> states to perform on each client, the lag for initiating the next state<br>
> centrally from the server was quite noticeable - in the end a single run<br>
> took more than half an hour without any changes (for a single host!).<br>
><br>
> After that we re-evaluated with salt stack being the outcome scaling<br>
> well enough for our O(2500) clients.<br>
><br>
> Note, I ave not tracked if and how ansible progressed over the past<br>
> ~2yrs which may or may not exhibit the same problems today.<br>
><br>
> Cheers<br>
><br>
> Carsten<br>
><br>
> --<br>
> Dr. Carsten Aulbert, Max Planck Institute for Gravitational Physics,<br>
> Callinstraße 38, 30167 Hannover, Germany<br>
> Phone: +49 511 762 17185<br>
> ______________________________<wbr>_________________<br>
> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
> To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/<wbr>mailman/listinfo/beowulf</a><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Gavin W. Burris<br>
Senior Project Leader for Research Computing<br>
The Wharton School<br>
University of Pennsylvania<br>
Search our documentation: <a href="http://research-it.wharton.upenn.edu/about/" rel="noreferrer" target="_blank">http://research-it.wharton.<wbr>upenn.edu/about/</a><br>
Subscribe to the Newsletter: <a href="http://whr.tn/ResearchNewsletterSubscribe" rel="noreferrer" target="_blank">http://whr.tn/<wbr>ResearchNewsletterSubscribe</a><br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/<wbr>mailman/listinfo/beowulf</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">- Andrew "lathama" Latham <a href="mailto:lathama@gmail.com" target="_blank">lathama@gmail.com</a> <a href="http://lathama.org" target="_blank">http://lathama.com</a> -</div></div></div></div>
</div>