[openstack-dev] [Fuel] Packaging CI for Fuel

Monty Taylor mordred at inaugust.com
Sat Mar 19 10:10:18 UTC 2016

On 03/17/2016 03:11 PM, Thomas Goirand wrote:
> On 03/16/2016 06:22 PM, Emilien Macchi wrote:
>> Are they any effort on OpenStack packaging?
>> http://governance.openstack.org/reference/projects/packaging-deb.html
>> http://governance.openstack.org/reference/projects/packaging-rpm.html
>> I would like to see packaging built & tested by OpenStack Infra, so
>> downstream CI (Fuel, Puppet OpenStack, TripleO, Kolla, etc) could use
>> it as a single place and efforts would converge.
> Hi Emilien,
> As you know, things were a bit stuck, with the Debian image patch not
> being approved. But it has changed, and we do have a debian-jessie image
> in infra now. Therefore, I've move to the next step, which is actually
> building packages. Here's the CR:
> https://review.openstack.org/#/c/294022/


The patch looks good, but it conflicts with the 
move-nova-jobs-to-db-macro and the "add debian jessie support for bindep 
fallback" change. Rather than fighting the rebase fight, let's put a 
brief hold on this (sorry, I know) and land it as soon as those land.

> I've been able to test the pkgdeb-install-sbuild.sh script that I'm
> proposing to setup sbuild on a copy of the Debian image (thanks a lot to
> Pabelanger and Fungi copy the image, and give it to me for download),
> and sbuild was setup properly. The pkgdeb-build-pkg.sh also worked,
> though I'm not 100% sure yet about the content of
> /home/jenkins/workspace/${JOB_NAME}, if it will have the correct branch
> or what, but everything else should be working to build packages.

We'll need to work to make sure that we're using zuul-cloner to get the 
right things checked out - this will be important for making sure that 
Depends-On works (that way someone can propose a nova change, and you 
can propose a packaging change that Depends-On that change and we can 
make sure we have a packaging change to handle it before it even lands)

> Once packages are built, then we will want to publish them somewhere.
> That's the part where there's lots of unknown. This has so far never
> been done on OpenStack infra. Hopefully, our new PTL will probably help
> here (or someone else from infra)! :) Also, managing a Debian repository
> isn't really hard to do: one can generate the necessary artifacts with a
> small shell script which uses apt-ftparchive (you can look how its done
> at src/pkgos-scan-repo in openstack-pkg-tools).

Luckily, we've got and apt-repository infrastructure already set up and 
ready in infra thanks to the mirror work we did this last cycle. It's 
using reprepro fwiw.

I believe we should add jessie to the list of things we mirror in it, 
and then also add a volume to hold things we publish ourselves.

We'll also need to move from having an unsigned reprepro to a signed 
reprepro if we're going to publish our own packages. We've not been 
signing the repo so far because we've sort of wanted to discourage use 
of our mirror outside of the gate - but it turns  out our mirror is 
AMAZING - so I think it's time we change that.

> Finally, we'll need a way to build backports from Sid and also publish them.

Hrm. We might want to mirror sid then too. I'd like to talk about the 
backport building process - hopefully a process that does not need to 
require us making a repo in gerrit for each package we want to backport 
and include in our repo.

It would also be good to tie off with the security team about this. One 
of the reasons we stopped publishing debs years ago is that it made us a 
de-facto derivative distro. People were using our packages in 
production, including backports we'd built in support of those packages, 
but our backports were not receiving security/CVE attention, so we were 
concerned that we were causing people to be exposed to issues. Of 
course. "we" was thierry, soren, jeblair and I, which is clearly not 
enough people. Now we have a whole security team and people who DO track 
CVEs - so if they're willing to at least keep an eye on things we 
publish in a repo, then I think we're in good shape to publish a repo 
with backports in it.

We'll also want to make sure we're building packages for trusty and xenial.

> That's where we are now. Let's go back to the first step, which is the
> CR linked above. Help and comments welcome.

Yay for movement!

More information about the OpenStack-dev mailing list