Is there a higher-level overview somewhere of what packaging-deb does?
Should it be useful to me as the packager of a Neutron driver project
(networking-calico)? (Currently I've rolled my own processes for
generating Debian packages for Ubuntu Trusty and Xenial.)
Thanks,
Neil
On Wed, Jun 22, 2016 at 10:10 AM Thomas Goirand <z...@debian.org> wrote:
> I've been asked to tell everyone the status of the project. So here is a
> report.
>
> What's been already done:
> - Debian Jessie image is up and running on all Infra nodes.
>
> - openstack-pkg-tools package can be built on each request, and is
> gating on the fact that it builds or not. This includes installing and
> setting-up the build environment using sbuild and git-buildpackage,
> which will be reused everywhere.
>
> - openstack-pkg-tools resulting packages are pushed to
> tarballs.openstack.org after a merge of a patch proposal. Though it
> seems there's still some issues to fix so that it pushes to the correct
> location (ie: /packaging-deb/openstack-pkg-tools/<SHA256-of-last-commit>).
>
> What we need to do:
>
> 1/ Push openstack-pkg-tools to a Debian repo
> Once pushing the built openstack-pkg-tools to tarballs.openstack.org is
> done on the correct location, we should build another job that will pick
> the resulting artefacts (ie: source package and binary package), and add
> it to a (new) Debian repository.
>
> 2/ Once we have a repository with openstack-pkg-tools, we can (finish)
> the infra job to build all other packages. This will be *very* easy to
> do, since all the work is already done to build openstack-pkg-tools
> itself. The only difference is that it will use the build scripts from
> the openstack-pkg-tools *package* instead of openstack-pkg-tools reusing
> its own scripts from the git clone (copied in /usr/bin). There's such a
> difference to avoid a bad commit within openstack-pkg-tools blocking
> everything, including a fix to openstack-pkg-tools itself.
>
> 3/ Another Debian repository should be created to handle "one time"
> backports of packages not currently maintained within the PKG OpenStack
> group in Debian. Design has already been discussed on how to do it.
> However, since it may take a large amount of time to get this finished
> and working as we expect, what we can do as a temporary solution, is
> simply doing a sync from Mirantis Debian repository (reprepro does it
> very well).
>
> 4/ Add all OpenStack packaging Git repository, and enjoy doing the work
> in OpenStack gerrit.
>
> What's taking so much time currently, is simply step 1/. The infra team
> has its own requirements on how to do it, because of security reasons,
> global distribution of the workload (ie: the Debian repository must be
> available everywhere we build packages, so it must be stored on the
> AFS). This is a non-trivial thing to implement. I don't have enough
> knowledge of OpenStack infra myself to do it alone, and the infra team
> has been very busy over the last months doing many things (upgrade to
> Xenial for many nodes, switching to the new version of Zuul, getting rid
> of Jenkins, etc.).
>
> I've been asked if it was possible to move everything we do within the
> current mixture of git.debian.org + Jenkins build servers hosted at both
> Linaro and Mirantis. It seems, from what I've heard, that it would be
> possible to use Gerrit, while continuing to use the current build system
> with Jenkins. However, I am really not convince that we should put some
> efforts into this, as the infra team is already super busy and has a
> hard time finding time to help us implementing the above. And it doesn't
> seem reasonable to move all the packaging to Gerrit if we don't have the
> same level of functionality and QA that we currently have (ie: build on
> each git push, full packaged based Tempest CI, etc.).
>
> I hope the above is what everyone expected me to write, and that there's
> enough details. I'd happily give more details if one asks. Monty, please
> feel free to reply and add text to this thread if you need to.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __________________________________________________________________________
> 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
>
__________________________________________________________________________
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
