On Wed, Jan 2, 2019 at 4:50 PM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > > On Wed, Jan 2, 2019 at 3:28 PM Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: > > > > On Wed, Jan 2, 2019 at 3:52 PM Sage Weil <sage@xxxxxxxxxxxx> wrote: > > > > > > On Wed, 2 Jan 2019, Ken Dreyer wrote: > > > > Hi folks, > > > > > > > > Our set of packages that we support as "Nautilus on CentOS" is > > > > growing, and I expect it to grow even more. > > > > > > > > In the past, we've been handling each new package as a one-off thing > > > > within Jenkins Job Builder, and this is hard to understand and scale. > > > > I'd like to take a new look at how we do this. > > > > > > > > The CentOS project provides some infrastructure for us to build and > > > > maintain a set of packages on top of the base OS (CentOS 7 at the > > > > moment). CentOS has "SIGs", which are groups of users interested in > > > > packaging things on top of CentOS, and Ceph is in the "Storage SIG" > > > > along with Gluster (and potentially other storage technologies). > > > > > > > > My high-level vision here: Using CentOS's build and release > > > > infrastructure would allow us to come up with a "known good" set of > > > > packages that make up "Nautilus the distribution", which we can QE, > > > > containerize, and distribute in a straightforward way. > > > > > > Is the idea to just put all of the Ceph dependencies in the SIG, or to > > > also include the Ceph releases themselves, or to release the CentOS > > > packages exclusively via the SIG? > > > > My idea is to rely on the CentOS base operating package as much as > > possible, and selectively choose to layer newer packages as it makes > > sense to do it. This is how RDO builds their distribution, for > > example. > > I'm just really unclear what benefit we expect out of this for the > Ceph community (including the build/release people). Are the manual > steps involved in constructing a particular distro's repository > onerous in comparison to doing it for all the distros we care about, > so that if we can drop CentOS from download.ceph.com then we've made > releases materially easier? The work encompasses more than just cutting a new point release of Ceph. We have informal, under-documented processes for each of these: "Signing and shipping a ceph point release" "Adding a new package to our distribution of Ceph" "Removing a package from our distribution of Ceph" "Adding a new base OS distro" "Upgrading to a new version of a compiler" We're doing these things more and more, but the frequency is still low enough that new and interesting things go wrong each time. I have some ideas for making it less painful. This is one of those ideas. > I can see how something like RDO gets big benefits out of this shared > and distro-focused infrastructure. But they pretty much *only* target > CentOS, whereas we are always going to have deb-based Ubuntu and > Debian packages, and may indeed add other RPM distributions like > OpenSUSE in the future. Adding a separate infrastructure sounds like > *more* work to me, since we'll need to try and coordinate builds and > releases across them, update more documentation URLs, etc. SUSE has been doing their own builds in OBS for a while AIUI. This is great, and I think we should do the same for CentOS builds. I would like to see us have a model like OpenStack's "Third Party CI", where we can make it easier for others to build, test and vote on changes without having to host everything in *.ceph.com infrastructure. - Ken
