Open Stack

On Mon, 2020-04-06 at 19:44 +0200, Radosław Piliszek wrote:
> > >  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
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
>