On Wed, Mar 12, 2014 at 12:33 PM, James Slagle <jslagle@redhat.com> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">
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". </div></blockquote><div><br></div><div>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.</div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">
Is there any similar equivalent for dpkg, like a dpkg-ostree? </div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">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.</div></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">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.</div></blockquote><br><div>Thanks! =) I appreciate that. </div>