On Thu, Sep 6, 2018 at 4:11 AM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > > On Wed, Sep 5, 2018 at 1:59 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: > > On Wed, Sep 5, 2018 at 2:28 AM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > >> > >> On Tue, Sep 4, 2018 at 8:29 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: > >> > On Tue, Sep 4, 2018 at 10:20 PM Alfredo Deza <adeza@xxxxxxxxxx> wrote: > >> >> > >> >> On Tue, Sep 4, 2018 at 10:15 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: > >> >> > hi guys, > >> >> > > >> >> > we build boost every time when building ceph. i don't think it's > >> >> > efficient, hence http://tracker.ceph.com/issues/25186 is filed to > >> >> > track this issue. > >> >> > > >> >> > to cache the built libboost for xenial and bionic, we can setup a PPA > >> >> > repo or host the repo by ourselves. if this approach works fine, we > >> >> > can also build libboost for centos. and expand the coverage to other > >> >> > dependencies, like dpdk, rocksdb and seastar. > >> >> > > >> >> > what do you think? > >> >> > >> >> I worry about the maintenance burden. Repositories are somewhat easy > >> >> with our infrastructure. If we are able to HTTP POST the binary to > >> >> chacra.ceph.com > >> >> > >> >> Who will be maintaining this package? > >> > > >> > i will. in the short-term, i will > >> > > >> > 1. setup repo(s) hosting the "debian/" directory. so the downstream > >> > changes can be tracked. > >> > 2. build the deb packages manually. > >> > 3. upload the source/binary packages to chacra > >> > > >> > in long-term, i think i will try to setup a jenkins job to build and > >> > upload the deb files for different branches when they gets updated. > >> > for instance, we will have xenial, bionic branches for libboost 1.67, > >> > once the xenial branch is updated, we should built the new recipe and > >> > push the built packages to chacra. > >> > > >> > my concern is, we might want to host different versions of dependency > >> > packages, for instance, rocksdb x.y.z adds a new API, and we picks it > >> > up and uses it in master. apparently, we also bump up the version # of > >> > it in install-deps.sh in master, where we will install the pre-built > >> > packages. but the Ceph versions which use rocksdb version x.y.$(z-1) > >> > should still build after this change in master. and their > >> > install-deps.sh still point to rocksdb x.y.$(z-1). so if we cannot > >> > support multiple versions in one repo. it's a no-go. > >> > >> Sounds like this will work nicely for our Jenkins jobs, but it won't > >> do much for development builds as I think we're mostly on Fedora or > >> other Ubuntus. :( > >> Is that expected? > > > > i don't follow. what do you mean by "development builds"? are they the > > builds of pull requests? all of our building jobs are performed by > > jenkins. if jenkins slaves are able to pull from chacra repo, we are > > good, i think. > > > > as long as different debian derivatives are able to pull from > > different repos, and they should, the problem is solved. BTW, reprepro > > now supports multiple versions support. but the change > > (https://github.com/profitbricks/reprepro) has not been accepted > > upstream. > > > > really? are we building on fedora also on the jenkins builders? i > > think we only build Ceph on centos, ubuntu and debian. but i don't > > think it's a show-stopper, as we can always setup a rpm repo for > > fedora anyway. it just adds more maintenance load. > > Oh sorry, I meant builds on developer machines > (laptops/desktop/"personal" servers). in addition to the pre-built lib*-dev packages for the supported distros (centos, xenial, bionic), i think developers can also benefit from the build scripts and packaging recipes. taking debian sid + GCC-8 as an example, if a developer is developing with this combination, he/she will need to pull https://github.com/tchaikov/boost, and prepare the download, extract source tarball, then copy the debian directory into it. export DEB_BUILD_OPTIONS="parallel=8 nodoc" dpkg-buildpackage -b # install the built packages # pass the appropriate parameters to cmake yes, we need some more tooling to facilitate the process, for instance, - to match the upstream libboost version used by given tag/branch of ceph, and to . - to match the debian/ packaging recipe for building given tag/branch of ceph but the task to create a repeatable process to prepare the building dependencies is the same for both jenkins build and local build. > Don't take this to mean avoiding the extra builds for our automated > systems is a bad idea, or should be blocked on making my local build > faster! It just wasn't what I was expecting when I read the subject > line. So I wanted to make sure we were all taking about the same > thing. basically they are the same, as they share quite a few problems we need to address. > -Greg -- Regards Kefu Chai
