Open Stack

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 at redhat.com> napisał(a):
>
> 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
> >
>