[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Removal of obsolete OpenStack source packages from bpo



On 07/13/2016 01:51 PM, Rhonda D'Vine wrote:
>> At this point, I went through all of the PKG OpenStack QA page, and
>> checked that everything really is up-to-date in jessie-backports. The
>> only thing I couldn't do just yet, is an actual installation test using
>> exclusively the jessie-backports repository.
> 
>  Well, that's never doable before packages are accepted.  A dpkg -i
> should help you with your prepared packages though to work around that
> and get things tested.  I guess you are very well aware of that and did
> that indeed, but better safe than sorry.
> 
>> However, tempest functional tests are all working using the unofficial
>> jessie-backports of OpenStack Mitaka, and the packages there should be
>> the same (it's just a different rebuild, but the sources are
>> identical).
> 
>  Hmm, that rather sounds like you didn't test with your self built
> packages.  Do you prepare the sources for there too so that the
> confidence in that is justified, do you take the sources from there to
> just upload to backports?  I'm curious on the workflow here, more out of
> interest than anything else.

Ok, let me disclose a bit of what I do. :)
Sorry for the length of my reply.

What I have currently, is that for each and every "git push", my Jenkins
servers are building backports to Jessie amd64 & arm64, and Xenial amd64.

Then every day, a periodic job in the Jessie amd64 Jenkins starts a
check job. It installs most of OpenStack on a single machine: a read
bare metal machine running a Jessie Live which is PXE booted, not a just
a VM, because using Qemu to do nested virtualization is too slow to
enable quick debugging. So what I upload to Sid, I know it also works on
Jessie (and I apply fixes if necessary, but mostly, it's not needed).

For this last upload of OpenStack Mitaka, there's absolutely zero
modification of the source package: they are unmodified from what's in
Sid, they are just rebuilt, as much as I remember.

As I need to ensure that all the build dependencies are there, to do the
upload, I started from a clean Jessie machine. I have a script that
downloads a source package from Sid, backport it, and stores the result
in a temporary local Debian repository, which can be used to build the
next package. I'm not using sbuild here, as it would be too slow to
install each dependency on each build, and it's not really needed as I
started from a clean Jessie anyway.

So, I am 100% sure that all packages can be rebuilt (and that all build
dependency are there), and that they work as the environment shouldn't
be much different from what my Jenkins does (same source, rebuilt in
Jessie as well). What I'm not sure is if there is a missing runtime
dependency missing somewhere in jessie-backports. Normally, it's ok, as
I tested it using my local repository. But I can't be 100% sure until I
get all packages in, especially openstack-meta-packages (that one is
still in the NEW queue). Once that one is in, I can do "apt-get -t
jessie-backports install openstack-proxy-node", then everything should
be ok. This did work on my build VM, so it should be ok, unless I missed
something (that's always possible). That meta package also contains the
"openstack-deploy", which isn't for production: it's for my CI. I may
use that for testing in the official jessie-backports too.

I also intend to manually run the Tempest functional suite with only
stuff from official jessie-backports if time permits. It shouldn't be
different from a run on my CI, but that will be a good thing still,
because I will be able to test if some package that someone else
uploaded there broke something. Chances are limited as things also work
in Sid, but it's better to check.

If you see room for improvement on the above workflow, I'm all for it,
and I would welcome any piece of advice.

Also, all of this manual work is very tedious, and could be automated.
Automation is always a good thing, but I don't think it's possible the
way Debian works currently. Hopefully, we'll get there at some point,
hopefully with Bikesheds in the mix! :)

Cheers,

Thomas Goirand (zigo)


Reply to: