[PKG-Openstack-devel] Status?

[Thomas Goirand]

On 07/14/2017 12:00 PM, Ondrej Novy wrote:
> Hi,
> 
> 2017-07-14 11:04 GMT+02:00 Thomas Goirand <zigo at debian.org
> <mailto:zigo at debian.org>>:
> 
>     Then I fail to understand why you're talking about source-only upload
>     when I was talking about setting-up a CI. This makes no sense. Could you
>     explain how the 2 are related?
> 
> 
> I think we are completely lost in this discussion.
> 
> It's simple, what I'm saying:
> 
>  1. don't have CI __now__
>  2. don't have tempest __now__
> 
> Have both later.

Ok, then we're on the same page.

> I'm complaining that OS infra is failing and nobody is going to fix it
> and take care of it in future.

At this point, what's lacking in OpenStack infra is a Stretch image. It
is my view that it's useless to do anything without it (or a Sid image
maybe), because Jessie is simply outdated and we don't want to suffer
maintaining a set of backports for it, especially if nobody is going to
run Mitaka or Pike on Jessie. For this to happen, one would need to
solve the issue with the infra team in #openstack-infra. I honestly lack
the energy to do that currently. Also, you wrote that you prefer to use
a receive hook than a proper CI with gerrit patches, so probably it's
not worth the effort.

> I'm fine to have CI with alioth Git, later. Difference is simple: If
> optional CI fails, we can work on packages even without it. If CI fails
> now, development is stopped. And it's broken now (for > 6 weeks now).

Right.

> Jessie was released without tempest check.

Not correct. I've been running tempest checks since Folsom. At the time,
it was done by eNovance: Emillien Macchi and Mehdi Abaakouk, who are now
both working for Red Hat. When I left them, I ported it to a CI running
on my own Xen server (hosted by GPLHost), and then on a "real" hardware
provided by Mirantis (with 16GB of RAM). It's possible that one release
wasn't tempest tested though, I can't remember. Though I am sure that
Icehouse (which is in Jessie) was tempest tested, and even tested twice,
once with a shell script install, and once using puppet.

> I know it's not ideal and not perfect, but it's better than nothing.

Well, in terms of CI, we do have ... nothing right now! :)

> BTW: We don't have tempest now in OS infra.

We never did. I was planning on it only, but I'm not sure 8GB of RAM
would have been enough, and there's a long set of unanswered questions
to be able to do it.

> We have only "build check".
> Same, as anybody must do before upload - build package.

The thing is, you don't for sure build a package after a commit, you may
only do that before the upload. The point of a package build CI is to do
it on each commit, or rather, *before* a commit lands.

> Compare it:
> 
>  1. tempest - we don't have it now, we will don't have it in near future

Hopefully, it can be fixed quickly, if we have support from DSA.

>     Also, I don't think you can compare OpenStack with other packages. It's
>     quite unique in Debian to have such a large amount of packages for a
>     single software solution, and I don't know anything else that interact
>     with so many parts of the system (including, but not limited to: KVM,
>     Qemu, libvirt, rabbitmq-server, Maria/MySQL server, networking bridges,
>     etc.).
> 
> Xorg, kernel, systemd, dbus for example?

These are *very* different. For all of the above, you can check quickly
that they work by simply running them. For OpenStack, you can't just do
dpkg -i, reboot, and see if it works. You have to perform a full
install, and checking that you can spawn an instance, attach storage to
it, and have network connectivity. All of this, expressed in a small
sentence, takes a day or 2 to do by hand. It's not reasonable to do that
often without automation.

Also, OpenStack is a dependency hell, moving on each release, that needs
to be tested, to make sure it is at least (co-)installable. The above
list of software has a quite stable dependency tree if you really want
to compare.

Anyway, let's not discuss this, since you agree a tempest validation
system is useful.

>     If not using an automatic deployment of OpenStack and tempest, how will
>     you make sure that the next release is really working? I see only a
>     single other way: following the install-guide (which may, at the same
>     time, provide you an opportunity to maintain it) and manually install
>     OpenStack, then manually run tempest. This could work, but would need a
>     lot more time than using the automation already in place.
> 
> I want to use/run tempest, but later.

Right, but what's the plan? My proposal: ask for some hardware or a VM
to the DSA, and see if we can run it there. Maybe in the university of
British Columbia data center, where I've heard there's still available
hardware. I've asked for it on IRC on #debian-admin, let's see where
this goes. FYI, the requirements are:

- PXE booted live system with a custom public ssh key to get in [1]
- Reset on demand (through IPMI?)
- Enough RAM (16, maybe 32 GB of RAM)
- A small scratch disk for swift (100 GB should be enough)

[1] I do have the scripts to generate this PXE image, it's somewhere on
Alioth in /git/openstack ...

>     Probably Debconf would be a good place/time to discuss it with DSA.
> 
> yep, I already arranged sprint at DebConf, will you be there?

I hope so.

>     I do not think that there's my way vs your way. I don't think anyone can
>     even remotely contest the advantage of functional testing. The only
>     issue is how, and if there's enough resources to do it.
> 
> As i sad: functional testing is nice, but not must-have.

Let's agree to not agree on the urgency, and just attempt to fix the
current situation! :)

> TBH, my motivation is to have working Git for packages I'm in uploader
> field. Do you have any problem with my suggestions for this group of OS
> packages? 

I do believe it's a shame to just drop the work on OpenStack infra, but
that's your call. So yeah, I do agree, and I'll try to help.

Cheers,

Thomas Goirand (zigo)