[CentOS-devel] ostree as a delivery model

Thu Apr 10 14:39:03 UTC 2014

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 at 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 at verbum.org> wrote:
>
>> Hi George,
>>
>> On Tue, Apr 8, 2014 at 6:20 AM, George Dunlap <dunlapg at 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 at centos.org
>> http://lists.centos.org/mailman/listinfo/centos-devel
>>
>
>
>
> --
>
> *Mike SCHMIDT *
>
> *CTO Intello Technologies Inc.**mike.schmidt at intello.com
> <mike.schmidt at intello.com>*
>
>
>
> *Canada: 1-888-404-6261 x320 <1-888-404-6261%20x320> USA: 1-888-404-6268
> x320 <1-888-404-6268%20x320> Mobile: 514-409-6898 <514-409-6898>
> www.intello.com <http://www.intello.com/>*
>
>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel
>
>

-- 
Jaime Melis
Project Engineer
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org | jmelis at opennebula.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140410/89d459a7/attachment.html>