Open Stack

On Mon, 2020-04-06 at 20:22 +0200, Radosław Piliszek wrote:
> 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. ;-)

im not sure i agree.
from a downstream perspecivit i think that will make packaging more difficult and
from an upstrem perspeictive my two favorite installer are devstack and kolla
but while i have tried to use kolla for dev in the past i still prefer devstack
and im not sure i would vote for a move that may make that impossibel unless
kollas dev mode has advanced signifcatly form wehn i last used it.
> 
> Dropping py2 deserves dropping old mindset. :-)
it deserves revaluting them sure but dropping for the sake fo it without
considering the costs and beinfits no.
> 
> -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
> > > 
> 
>