Hi Alfredo, On Mon, 2019-08-05 at 09:02 -0400, Alfredo Deza wrote: I think we are deviating a bit on the discussion:1) We are not in the capacity of adding any other new distro to ourbuild toolchain, for development or releases. What would be the steps in order to extend the capacity for adding a new distro? What is required from the community? Money, like extend OVH computing resources, dedicated engineer who can support the distro and play role as maintainer? 2) We can own the effort of adding the mechanisms needed in shaman(shaman.ceph.com) so that community-built Ceph packages/repos canreport there. This will entailadding authentication so that updates can verify the source. Do I understand correctly that there is no mechanism at the moment. For #2 specifically, the shaman dashboard allows updating the statusof a build (started, building, failed, succeeded) as well as the repo.Tools like teuthology query shaman for the state and locationof repos. The API is detailed here:https://github.com/ceph/shaman I only see that API can support one login/password pair, am I wrong? Who can provide existing credential to us, so we can integrate our builds without taking Ceph Infrastructure team engineering resources? On Mon, Aug 5, 2019 at 4:21 AM Marcin Juszkiewicz<marcin.juszkiewicz@xxxxxxxxxx> wrote:W dniu 02.08.2019 o 19:55, Alfredo Deza pisze:On Fri, Aug 2, 2019 at 12:20 PM Lars Marowsky-Bree <lmb@xxxxxxxx>wrote:Kyrlyo wanted to add openSUSE to the set of distributions that getbuild for and used by teuthology, for example:However, seems officially there are "no plans" to add otherplatforms but Ubuntu and CentOS, so Alfredo closed the PRs.At Linaro we would like to help with adding Debian to the list ofdistributions Ceph is built for. We can provide aarch64 (arm64) machinesfor it.Hey Lars. Adding a distro for builds is a very involved problem tosolve. We don't keep a detailed list of everything that is neededbut I will try to go over some of the well-known items:2) A new distribution added *must* exist in the cloud provider (OVHin this case) that can spin up a VM for builds (as of this writing,there is only an opensuse42 image available from 2016)https://www.ovh.co.uk/dedicated_servers/distributions/lists Debian 10as available. Not that this page is up-to-date as it does not even listUbuntu 18.043) *All* the building scripts must be revised to ensure that the newdistribution is accounted for. I did some of this work when addingUbuntu Bionic and it was non-trivial, error prone, and it took abouttwo weeks to really get it right with the help of other people.I can probably work on it.4) The services that ensure that images come up and are prepared tobuild Ceph have to be udpated as well to ensure that the minimumrequirements are installed so that the machine is operational5) If the new distro is Python3 only we will need to update alltooling that interacts with a jenkins node - we are not there yet asall our tooling is Python2 exclusive.Debian 10 'buster' has both Python 2.7 and Python 3.7 so should not bea problem - we can start with py2 and then update to py3 once Ceph move.At Cephalocon, Ken Dreyer and me did a presentation on what exactlyentails building Ceph for both development and releases, theproblems we've faced and where we would like to head next. It mightbe useful to go through if you haven't already:https://www.youtube.com/watch?v=seHyiQT8YJMWill watch it later.A few of the things we brought up is that we (the Cephinfrastructure team and our services) aren't prepared to accommodatemultiple other distributions and that we are trying to get away fromtaking on the load of maintenance in our systems and looking to otherbuild/repo solutions. One of these solutions is the CentOSstorage-sig which we are trying to coordinate to build and host reposfor us there.In addition to that, we mentioned that we would like to see a widercommunity effort go into building and hosting Ceph in separatesystems, maybe with a special signing key (our release signingprocess is pretty inflexible!) so that others who are buildingdevelopment repositories can ensure their authenticity, while givingus the ability to revoke keys as needed.In the past, we've gotten asked to re-enable the Debian builds,which puts us into a similar problem (maintenance burden, scriptupdates, and other items already mentioned), and we've had to turnthat down. As Ken mentions in the presentation, we really want to behelpful and accommodating to the wider community, but we can't do iton our own and with our infrastructure as it is today - we are maxedout.Distributing community signing keys, or allowing other builders tosubmit status updates into shaman.ceph.com for testing scheduling isyet-to-be-done work, but I am open to have those conversations sothat we can move forwards with more distros and better testing.At Linaro we can arrange machines for building and testing. Space forhosting Debian/arm64 repos too. We are fine on using those machines alsoto build packages for other arm64 distributions._______________________________________________Dev mailing list --dev@xxxxxxxTo unsubscribe send an email todev-leave@xxxxxxx_______________________________________________Dev mailing list --dev@xxxxxxxTo unsubscribe send an email todev-leave@xxxxxxx |
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
