On Wed, Mar 12, 2014 at 12:33 PM, James Slagle <jslagle(a)redhat.com>
wrote:
But, to be clear, someone* saying the TripleO approach is
"incompatible with
packaging" is equivalent to saying Fedora's builtin readonly root
support is
"incompatible with packaging".
You are right, I was assuming that what you were talking about was a
more simplistic "data goes in /mnt/data" type approach. While the
readonly root approach is a little hacky (IMO), I would describe it as
compatible with packaging.
Is there any similar equivalent for dpkg, like a dpkg-ostree?
There is one I know of, but it is not public. I don't think it's
secret sauce, so I may ping the people to ask it be opened up.
My personal opinion is that TripleO, and OpenStack in general, should
offer
differing implementations where it makes sense. Things like the Nova
driver
model, storage backends, etc. I'd like to see TripleO offer such
choices as
well where it makes sense.
I would say that some level of duplication of effort is unavoidable.
TripleO can't depend on OSTree (for example, I'm sure TripleO targets
EL6), and neither can OSTree depend on TripleO (since it needs to
support non-cloud bare metal).
The key is just to make sure that duplication is minimized and that
when both features are available, they work in concert as much as
possible.
I'm certainly very interested in having OSTree work well in the cloud
space. As we discussed before, while in many ways if one does things
"right" in cloud, some of the OSTree features such as preserving the
traditional /etc and /var aren't necessary. On the other hand - I'd
say it's still quite sane to deploy "traditional" servers in a cloud
environment, and OSTree is useful there too.
FWIW, I definitely "see the light" so to speak with what
ostree has
to offer.
I've been hovering aound different package management solutions for
quite a
while. Besides rpm, I spent a few years working closely with Conary,
which you
mention on your RelatedProjects wiki. Even though I have a limited
understanding of the ostree implementation, it appears to hit the
mark of what
I see as a very compelling update model.
Thanks! =) I appreciate that.