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.
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
