On Mon, Aug 5, 2019 at 12:56 PM Sage Weil <sage@xxxxxxxxxxxx> wrote: > > On Mon, 5 Aug 2019, Alfredo Deza wrote: > > On Mon, Aug 5, 2019 at 10:49 AM Lars Marowsky-Bree <lmb@xxxxxxxx> wrote: > > > > > > On 2019-08-05T13:48:26, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > > > > > Hi Sage, > > > > > > thanks for jumping in. > > > > > > > I think this is misunderstanding who "we" are. What distributions are > > > > tested and built for shaman/chacra and download.ceph.com is a community > > > > decision and depends on who is able to invest the effort. If someone > > > > shows up willing to do the work, whoever was doing the work before doesn't > > > > get to just say no--especially if they don't want to be stuck with that > > > > responsibility for all time. > > > > > > I think the summary here is that SUSE is willing to shoulder part of > > > this work going forward, and if the respective infrastructure is > > > resource constrained, well, the Foundation exists for specifically that > > > purpose. > > > > > > > I see two paths forward: (1) we continue with a monolithic approach to > > > > builds and expand the pool of people who understand and contribute to > > > > maintaining the build infra, or (2) we rearchitect to a federated > > > > approach. > > > > > > I think it'd be a mix. > > > > > > Federating the builds - and pushing maintaining distro-packages to, > > > well, the distributors (Fedora, CentOS, Ubuntu, Debian, openSUSE) - > > > seems most sensible. The distros really know best how to build for their > > > platforms. > > > > > > e.g., for (open)SUSE - I can't talk about any other distro -, we'd be > > > willing to either host the builds on our Open Build Service, or help > > > setup a dedicated OBS instance in the lab somewhere (that'd > > > possibly help with making sure we get them in a timely fashion even when > > > the public infra is overloaded) and helping maintain base images for the > > > OS to run on. > > > > > > And then once builds are done, pulling them back to the shared > > > infrastructure for test runs. > > > > > > This is all sort-of a pre-requisite to eventually also run > > > upstream/cross-distro inter-op testings in a more structured fashion, > > > anyway. > > > > > > > *Both* paths require knowledge transfer to new people, > > > > especially if the old team is too busy with other projects (as I keep > > > > hearing). (FWIW, the first path sounds like a lot less effort, and the > > > > two presumably also aren't mutually exclusive.) > > > > > > Yeah, agreed. > > > > > > So, TL;DR: we're willing to help with extending the distro coverage (for > > > the tests in particular), as long as we know whom to work with to make > > > that happen. > > > > That sounds great Lars. If you are already building/hosting then for > > testing purposes (with Teuthology) it would only need reporting on the > > status(es) of the builds and repos. From what you are saying, I am > > thinking > > that you are looking to have OpenSuse test with teuthology right? > > > > In that case there is no need to push the packages anywhere, shaman > > will happily redirect tools to the right spot and the repo metadata > > will help teuthology find what it needs via the HTTP API. > > The one other piece is getting working images for fog, right? If testing in the lab I think that is one thing yes, not entirely sure what else is there, David should have better details > > s > > > > > > > > > We already have openSUSE on > > > https://docs.ceph.com/docs/master/install/get-packages/ for example. > > > (Probably we want to backport that to the Nautilus and previous releases > > > for openSUSE, though.) > > > > > > But https://github.com/ceph/ceph-qa-suite/tree/master/distros/supported > > > is somewhat more limited. Also, last updated 3 years, really? ;-) > > > (That's at least what the docs point to.) > > > > > > > > > Regards, > > > Lars > > > > > > -- > > > SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) > > > "Architects should open possibilities and not determine everything." (Ueli Zbinden) > > > > _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
