<div dir="ltr"><div>What provisioning tools do you use to manage these servers? Please tell me you aren't doing all of this manually.</div><div>Also what's your environment? All hardware servers? Any virtualisation involved? Cloud servers?</div><div><br></div>Reading your question it feels like you are setting yourself up to fail instead of minimising the failure altogether.<div><br></div><div>What I suggest is that you test your package automatically in a test environment (to me, Vagrant + Rspec/ServerSpec would be first candidates to check) then rollout the package to the repository for the servers to pick it up.</div><div><br></div><div>As for "roll-back" - with comprehensive automatic testing this concept is becoming obsolete, there is no such thing as "roll-back" only "roll-forward", i.e. since the testing and rolling out are small and "cheap", it should be feasible to fix whatever problem was found instead of having to revert the change altogether.</div><div><br></div><div>If you are in a properly supported virtual environment then I'd even go for immutable server images (e.g. Packer building AMI's, or Docker containers), then it's a matter of just firing up an instance of the new image both when testing and in production.</div><div><br></div><div>--Amos</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 August 2016 at 16:55, Elazar Leibovich <span dir="ltr"><<a href="mailto:elazarl@gmail.com" target="_blank">elazarl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">How exactly you connect to the server is not in the scope of the discussion, and I agree that ansible is a sensible solution.<div><br></div><div>But what you're proposing is to manually update the package on a small percent of the machines.</div><div><br></div><div>Manual solution is fine, but I would like to hear experience of people who actually did that on many servers.</div><div><br></div><div>There are many other issues, for example, how to you roll back?</div><div><br></div><div>apt-get remove exposes you to the risk that the uninstallation script would be buggy. There are other solutions, e.g., btrfs snapshots on root partitions, but I'm curious to hear someone experienced with it to expose issues I didn't even thought of.</div><div><br></div><div>Another issue is, how do you select the servers you try it?</div><div><br></div><div>You suggested a static "beta" list, and I think it's better to select the candidates randomly on each update.</div><div><br></div><div>Anyhow, how exactly you connect to the server is not the essence of the issue.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 3, 2016 at 9:30 AM, Evgeniy Ginzburg <span dir="ltr"><<a href="mailto:nad.oby@gmail.com" target="_blank">nad.oby@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello.</div><div>I'm assuming that you have paswordless ssh to the servers in question as root.</div><div>Also I assume that you don't use central management/deployment software (ansible/puppet/chef)</div>In similar cases I usully use parallel-ssh (gnu-parallel is another alternative).<div>First stage install the package manually on one server to see that configuration is OK, daemons restart, etc...</div><div>If this stage is ok second step will be creating list of servers for "complain" list and install package on them trough parallel-ssh.</div><div>Instead of waiting for complains, one can define metrics to check and use some monitoring appliance for verification.</div><div>I case of failure remove package from repository and remove-install again.</div><div>Third will be parallel-ssh install on all the servers.</div><div><br></div><div>P. S. In case of few tens of servers I'd prefer to work with ansible or alternative, it's worh it in most cases/</div><div><br></div><div>Best Regards, Evgeniy.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Aug 2, 2016 at 8:50 PM, Elazar Leibovich <span dir="ltr"><<a href="mailto:elazarl@gmail.com" target="_blank">elazarl@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br></div><div>I'm having a few (say, a few tens) Debian machines, with a local repository defined.</div><div><br></div><div>In the local repository I have some home made packages I'm building and pushing to the local repository.</div><div><br></div><div>When I'm upgrading my package, I want to be sure the update wouldn't cause a problem.</div><div><br></div><div>So I wish to install them on a few percentage of the machines, wait for complaints.</div><div><br></div><div>If complaints arrive - roll back.</div><div>Otherwise keep upgrading the whole machines.</div><div><br></div><div>I'll appreciate your advice and experience of similar situation,</div><div>I'll appreciate if someone who had actual real life experience with this situation would mention it in the comments.</div><div><br></div><div>Thanks,</div></div>
<br></div></div>______________________________<wbr>_________________<br>
Linux-il mailing list<br>
<a href="mailto:Linux-il@cs.huji.ac.il" target="_blank">Linux-il@cs.huji.ac.il</a><br>
<a href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il" rel="noreferrer" target="_blank">http://mailman.cs.huji.ac.il/<wbr>mailman/listinfo/linux-il</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature">So long, and thanks for all the fish.</div>
</font></span></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Linux-il mailing list<br>
<a href="mailto:Linux-il@cs.huji.ac.il">Linux-il@cs.huji.ac.il</a><br>
<a href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il" rel="noreferrer" target="_blank">http://mailman.cs.huji.ac.il/<wbr>mailman/listinfo/linux-il</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><a href="http://au.linkedin.com/in/gliderflyer" target="_blank"><img src="https://static.licdn.com/scds/common/u/img/webpromo/btn_viewmy_160x25.png"></a><br></div></div>
</div>