<div dir="ltr">Hi guys,<div><br></div><div>Forgive me for skipping the philosophical debate ;-)</div><div><br></div><div>If I understand correctly ostree, it would help us in OpenNebula (and mainly the OpenNebula users) with a couple of challenges that arise somewhat frequently. The main advantage I see this solves, or at least helps greatly with, is certification of both physical and virtual platforms.</div>
<div><br></div><div>First of all, by using ostree we can certify a specific CentOS OpenNebula deployment, and it also delivers a very flexible way of upgrading the frontend/worker nodes.</div><div><br></div><div>The other issue is that we've seen a growing number of people using not only single VMs but multi-tiered services composed of multiple VMs. Handling upgrades and certifying applications to work with those VMs is a bit challenging, since all the images can be installed differently or can have different versions of the rpm packages. However with ostree I can imagine how it would be a very useful tool for service developers when developing/deploying/upgrading these environments.</div>
<div><br></div><div>cheers,<br>Jaime</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 4:07 PM, Mike Schmidt <span dir="ltr"><<a href="mailto:mike.schmidt@intello.com" target="_blank">mike.schmidt@intello.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>I'm not going to get into the philosophical debate here, here's my totally pragmatic viewpoint:</div>
<div><br></div>Coming from an environment where we install hundreds of I'd guess you could call them appliances, running centos5, I'd say at first glance os-tree would provide a stable way to handle updates in the field (when we switch to centos7 later this year), where we update both the os and our own code, as well as all the supporting cast (bind, apache, etc) without too much risk. And anyway, it fedora is anything to go by, centos7 will boot much faster than centos5, which we are using currently. <div>
<br></div><div>At the moment, we still use yum update, but it's not always safe, and we end up with a variety of versions in the field.</div><div><br></div><div>Oh, and, while I sympathize with many other sysadmins, what's one more tool, if I don't have to write it myself and it does what I don' t have today? I have at least three people full-time involved in keeping our sites up to date; if I could just move one of them to other tasks, I win. </div>
<div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 9:10 AM, Colin Walters <span dir="ltr"><<a href="mailto:walters@verbum.org" target="_blank">walters@verbum.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi George,<br>
<div><br>
On Tue, Apr 8, 2014 at 6:20 AM, George Dunlap <<a href="mailto:dunlapg@umich.edu" target="_blank">dunlapg@umich.edu</a>> wrote:<br>
><br>
</div><div>> But coming back down from the ivory tower,<br>
<br>
</div>Thanks for steering us back on track =)<br>
<div><br>
> So the question is whether these are worth the cost of having Yet<br>
> Another Tool.<br>
<br>
</div>Right, that is a good way to put it. There's no question that<br>
rpm-ostree is another tool. However I do want to strongly emphasize<br>
something that's implicit in the "rpm-ostree" name: I see the ostree<br>
technology as joining an ecosystem, not as entirely replacing things.<br>
<br>
Concretely, on every rpm-ostree generated tree, "rpm -qa" works. Which<br>
if you think about it is a Big Deal - there's an incredible amount of<br>
tooling built up around RPM in this way. A simple example is: How do<br>
you report a bug? Well, Bugzilla only knows about RPMs.<br>
<br>
And more strongly than that, the rpm-ostree server side compose tooling<br>
*enforces* that you only put RPM-based content in there.<br>
<br>
(The OSTree side is just dumb filesystem replication, you could easily<br>
ship<br>
trees generated with a hybrid of RPM + say pip or bundler. I'd rather<br>
fix<br>
the RPM side to be capable of what people want from pip myself)<br>
<div><br>
> #1 may not be a killer feature for sysadmins in particular; they are<br>
> likely to figure out one setup and use it on their production systems.<br>
> It would probably be very much a feature for people who *develop*<br>
> these "images" however; and anything which makes it so that<br>
> development<br>
<br>
</div>Right. "ostree admin switch" is not that interesting - yet. It does<br>
demonstrate that client systems *can* have choice of software, unlike<br>
many image based upgrade systems out there. But it will be far, far<br>
more interesting when rpm-ostree supports package installation on top,<br>
then it'll act like a rebase operation.<br>
<div><br>
> #2 is probably somewhat of an advantage; particularly if it means that<br>
> you can also atomically switch back to the previous version if it<br>
> turns out you've screwed something up.<br>
<br>
</div>Exactly! You can, you always have two complete "trees" (kernel +<br>
/usr), that manifest as two bootloader entries. There is even now<br>
"rpm-ostree rollback":<br>
<a href="https://github.com/cgwalters/rpm-ostree/commit/441313f9ef4dca7f6e1c683dccc35043ea9c29ad" target="_blank">https://github.com/cgwalters/rpm-ostree/commit/441313f9ef4dca7f6e1c683dccc35043ea9c29ad</a><br>
<div>> Whether these outweigh the disadvantage of having Yet Another Tool, I<br>
> can't really tell; but the ostree idea certainly seems to have merit,<br>
> and is at least worth considering.<br>
<br>
</div>Thanks for the feedback!<br>
<br>
If anyone has a chance to try composing trees with rpm-ostree and runs<br>
into trouble, please don't hesitate to file github issues, or you can<br>
follow up here, or mail me directly if you prefer.<br>
<div><div><br>
<br>
<br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org" target="_blank">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><font color="#cc3300"><font face="Tahoma"><font><b>Mike SCHMIDT<br>
</b></font></font></font><font color="#808080"><font face="Tahoma"><font><b>CTO <br>Intello Technologies Inc.<br></b></font></font></font></span><span style="font-family:Tahoma;border-collapse:collapse;color:rgb(128,128,128)"><b><font color="#888888"><a href="mailto:mike.schmidt@intello.com" style="color:rgb(42,93,176)" target="_blank">mike.schmidt@intello.com</a></font></b></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><font color="#808080"><font face="Tahoma"><font><b><font color="#888888">Canada: <a href="tel:1-888-404-6261%20x320" value="+18884046261" target="_blank">1-888-404-6261 x320</a><br>
USA: <a href="tel:1-888-404-6268%20x320" value="+18884046268" target="_blank">1-888-404-6268 x320</a><br>
Mobile: <a href="tel:514-409-6898" value="+15144096898" target="_blank">514-409-6898</a><br>
<a href="http://www.intello.com/" style="color:rgb(42,93,176)" target="_blank">www.intello.com</a></font></b></font></font></font></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><font color="#808080"><font face="Tahoma"><font><b><br>
</b></font></font></font></span></div>
</font></span></div>
<br>_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Jaime Melis<br>Project Engineer<br>OpenNebula - Flexible Enterprise Cloud Made Simple<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a></div>
</div>
</div>