Just to clarify - I'm actually in favor of dropping the plain coinstallability rule. I wrote this before: we have different ways to ensure separation: virtual envs and OCI images. People can and do use them. I don't think this rule brings any benefits nowadays, very diverse projects can be used together even if they decide they need different versions of some internal library - for whatever reason. What counts are well-defined interfaces - this is the only way to ensure cofunctionality, other measures are simply workarounds. ;-) Dropping py2 deserves dropping old mindset. :-) -yoctozepto pon., 6 kwi 2020 o 20:10 Sean Mooney <smooney@redhat.com> napisał(a):
I am thinking something Kolla-esque as LOCI does not seem that alive nowadays (and does not seem to be getting that much level of testing Kolla has from Kolla Ansible and TripleO as both deployment projects consume Kolla images).
Question: Why would we want another competing project? How do you intend to work with Kolla? Do you want to have this image building in the projects, and use another tooling to deploy those images? Did you start collaborating/discussing with non-TripleO projects on this?
(snip, continued)
Maybe I should rephrase. How do you want to make this work with Kolla, Triple-O, and other deployment projects outside those two? Do we distribute and collaborate (each project got a way to build its images), or do we centralize (LOCI/kolla - way)?
Let me answer both the versions. I feel like I put it in bad words, I did not mean to start a completely separate project. What I wanted to say is that I see it best to build possible common containerization solution off Kolla (both as in deliverable and project). The fact is Kolla has some shortcomings that would likely cripple its usage as possible DevStack replacement/booster in gate in its current state. for what its worth i rememebr talking with clark about if using the kolla
On Mon, 2020-04-06 at 19:44 +0200, Radosław Piliszek wrote: pre built image for other project would help speed up the gate in anyway. the conclution we came too at the time was due to the way we prestage git repos ince the vm and we do not expect using kolla image in the gate to have any really speed up and it actully has a dissadvatage
which is we loose any validation that service are co installable on the same host outside of contianers.
e.g. we dont ahve validation that deps of different project dont conflcit sice they are all in different contianers so without adressing that i think it would actully be a regression.
not that i dont like kolla imagess i do but it would not be good to use them in the gate an use kolla ansibel instead of devstack in my view if we consider co installablity to be important. the same goes for any contaienised soltution for that matter.
My idea is to keep this centralized but with more visibility and ask projects to officially support this method of deliverable distribution. The whole undertaking stems from the fact that I perceive modern software distribution as based on containers - you have the recipe, you have the image, you can use it - you have the insight in how it got to be and also are able to reduce repeatability of deployment steps regarding building/installation, all by "official" means. Since TC is about _technical_ _governance_, I'd say this project fits as it deals with the technical part of organizing proper tooling for the job and promothing it in the OpenStack community far and wide.
It would be easy to design deployment scenarios of subsets of OpenStack projects that work together to achieve some cloud-imagined goal other than plain IaaS. Want some baremetal provisioning? Here you go. Need a safe place for credentials? Be my guest! I am not sure what you mean there? Do you want to map OpenStack "sample configs" with gate jobs?
More or less - yes. They seem to need some refresh in the first place (I guess this is where Ironic could shine as well). Currently "sample configs" are vague descriptions of possibilities with listings of projects and links. They should really be captured by deployment scenarios we can offer and have them tested in the gate. This is an interesting matter in its own right. We at Kolla Ansible started some discussion based also on user feedback (which we want to enhance with further with the Kolla Klub) [1]. The goal is to give good coverage of scenarios users are currently interested in while keeping CI resource usage low. You might notice these hardly align with "sample configs". One reason for that is catering for real service coverage, rather than very specific use case. Another is likely different audience than marketing site.
[1] https://etherpad.openstack.org/p/KollaAnsibleScenarios
-yoctozepto