Hi guys,

Forgive me for skipping the philosophical debate ;-)

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.

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.

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.

cheers,
Jaime


On Tue, Apr 8, 2014 at 4:07 PM, Mike Schmidt <mike.schmidt@intello.com> wrote:
I'm not going to get into the philosophical debate here, here's my totally pragmatic viewpoint:

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. 

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.

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. 



On Tue, Apr 8, 2014 at 9:10 AM, Colin Walters <walters@verbum.org> wrote:
Hi George,

On Tue, Apr 8, 2014 at 6:20 AM, George Dunlap <dunlapg@umich.edu> wrote:
>
> But coming back down from the ivory tower,

Thanks for steering us back on track =)

> So the question is whether these are worth the cost of having Yet
> Another Tool.

Right, that is a good way to put it. There's no question that
rpm-ostree is another tool.  However I do want to strongly emphasize
something that's implicit in the "rpm-ostree" name: I see the ostree
technology as joining an ecosystem, not as entirely replacing things.

Concretely, on every rpm-ostree generated tree, "rpm -qa" works.  Which
if you think about it is a Big Deal - there's an incredible amount of
tooling built up around RPM in this way.  A simple example is: How do
you report a bug?  Well, Bugzilla only knows about RPMs.

And more strongly than that, the rpm-ostree server side compose tooling
*enforces* that you only put RPM-based content in there.

(The OSTree side is just dumb filesystem replication, you could easily
ship
 trees generated with a hybrid of RPM + say pip or bundler.  I'd rather
fix
 the RPM side to be capable of what people want from pip myself)

> #1 may not be a killer feature for sysadmins in particular; they are
> likely to figure out one setup and use it on their production systems.
>  It would probably be very much a feature for people who *develop*
> these "images" however; and anything which makes it so that
> development

Right.  "ostree admin switch" is not that interesting - yet.  It does
demonstrate that client systems *can* have choice of software, unlike
many image based upgrade systems out there.  But it will be far, far
more interesting when rpm-ostree supports package installation on top,
then it'll act like a rebase operation.

> #2 is probably somewhat of an advantage; particularly if it means that
> you can also atomically switch back to the previous version if it
> turns out you've screwed something up.

Exactly!  You can, you always have two complete "trees" (kernel +
/usr), that manifest as two bootloader entries.  There is even now
"rpm-ostree rollback":
https://github.com/cgwalters/rpm-ostree/commit/441313f9ef4dca7f6e1c683dccc35043ea9c29ad
> Whether these outweigh the disadvantage of having Yet Another Tool, I
> can't really tell; but the ostree idea certainly seems to have merit,
> and is at least worth considering.

Thanks for the feedback!

If anyone has a chance to try composing trees with rpm-ostree and runs
into trouble, please don't hesitate to file github issues, or you can
follow up here, or mail me directly if you prefer.



_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel



--
Mike SCHMIDT
CTO 
Intello Technologies Inc.
mike.schmidt@intello.com


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel




--
Jaime Melis
Project Engineer
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org | jmelis@opennebula.org