[CentOS-devel] ostree as a delivery model

Sun Apr 6 18:35:40 UTC 2014
Les Mikesell <lesmikesell at gmail.com>

On Sun, Apr 6, 2014 at 12:40 PM, Colin Walters <walters at verbum.org> wrote:
> But OSTree is much more flexible than traditional block replication
> because:

Is if flexible enough to scale 'down'?  That is, is it something you
would likely use to install your 2nd system if you only had 2 and had
never used it before?   Or your first system as a copy of something
someone else already has running?

>  > But how
>  > do you deal with the necessary differences in that case? There is
>  > always some ugly overlap in software/system/local configuration that
>  > is hard to abstract away.
> This is another key point - in OSTree you have a writable /etc and
> /var.  In particular the fact that a 3 way merge is applied to /etc
> helps make the system "feel like" Unix, in contrast to more basic
> block-level systems which are unaware of the semantics of /etc.

Does something mange the necessary differences during an install?  And
can it tell a hardware or local difference that doesn't change in an
update from a software configuration item that would be
software-version specific?  Or do these still leave lots of odd
special cases, especially if you aren't using VMs?

>> And yet none of them give you the ability to build/test one system,
>> then let someone else duplicate it easily and track its tested
>> updates.  Which is what pretty much everyone needs to do if they have
>> multiple machines, and it would give people with no administration
>> experience the ability to have machines with software managed by
>> experts, almost for free.
> The more I think about your suggestion the more it feels like the
> "staging" model, which is clearly widely used inside individual
> organizations.

Yes, everyone with more than a few machines needs that - and large
organizations need it so badly they build their own in spite of the
cost and difficulty.   Which is why I think it is so odd that the
stock tools aren't designed to do repeatable updates in the first
place.  Why is it so difficult to tell yum to just ignore anything
added to the repositories after the staging system update was done and
reproduce that same update to a production system after your tests are

> Anyways, there's clearly a lot of ways to build, deploy, and manage
> systems =)  I think the rpm-ostree model is a unique middle ground
> between traditional packages on the client and image-based updates -
> not for everyone, but some here might be interested, and I'm happy to
> hear any other feedback!

It is very unlike the unix philosophy to need a lot of ways to do
something.  Why isn't there one tool that does it right in the first
place - and can work appropriately for 2 systems the same as 2,000?
And more annoyingly, why does every variation of the simple idea of
installing and tracking versioned updates need different and complex
infrastructure for the package repository and invent a new
configuration and command language that is incompatible with anything
used before or the source management systems that do essentially the
same things?

    Les Mikesell
      lesmikesell at gmail.com