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/
Woot!
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!
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
