Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On 04/16/2013 03:58 AM, Joerg Jaspert wrote:
> On 13182 March 1977, Thomas Goirand wrote:
>
>> Note that the upstream changelog issue was quickly solved (and I agreed
>> with the FTP masters view on it), though remains the "problem" of having
>> too many binaries, according to the FTP masters.
>
> Ay. I go into the reasons for that somewhere down below.
>
>> I decided to leave up to before the OpenStack summit to the FTP masters,
>> so that they could approve Nova. With no reply from them, which made me
>> miss my dead line, I am left with no other option but to escalate the
>> issue.
>
> Whyever do you set yourself such a deadline, depending on other stuff
> you can't control?
>
> Also, if your goal would be to get the packages accessible for others -
> reprepo, dpkg-scan* and co are all not hard to use.
I do that already since last autumn. Here's the latest build:
deb ftp://archive.gplhost.com/debian grizzly main
deb ftp://archive.gplhost.com/debian grizzly-backports main
This things uses Jenkins CI: on every git push, packages gets rebuilt
and pushed (on a more private URL which I don't advertize about, it only
show on the IRC channel). Once I'm satisfied with the packages (after
installation tests of all of them), I start a script to publish all
packages on the above repositories. This workflow is also very
convenient for testing things, and helped me to avoid uploading crap to
Debian.
So yes, I'm doing that already. Yet I would still prefer to have things
in the Debian repositories.
> Now, lets go on.
>
>> Now, I'm seeing that, as this mail went public when it should never have
>> been, it's making the situation worse... :(
>
> Nope.
>
>> I hope that the original issue can be solved never the less, and that
>> the communication with the FTP masters can be restored in a sane way.
>
> We are always happy with sanity. We don't see it often enough.
Thanks.
> Now, as we have it here anyways: I stay by what I said. The amount of
> splitting you did is nothing that the Debian archive should get. It's
> all nice that upstream may like it, but we are talking about Debian, not
> Upstream.
Not just upstream. Integrators and users as well. They are my priority,
just like for everyone in Debian.
> And we do consider a bit more here. Each and every package
> takes extra space in the various metadata places, like Packages (times
> number of architectures), our database, our various handling scripts of
> archive/testing/pts/bugs/whatnot. So we have to decide between an
> excessive split and something that makes sense.
>
> The nova packages consist[1] mostly of one file in /usr/bin with the size
> between 1500 and 3000 bytes, or worse - one file in /etc between 45 and
> 222 bytes - or even nothing (nova-volume).
I am on the side of Russ Allbery here. Ideally, as a developer, I
shouldn't have to worry about this, too much, and here is IMHO too much.
The infrastructure problems which Debian runs into shouldn't clash with
the convenience users either, to the point where Debian would be a very
special case with packaging different from other distro, and breaking
existing puppet scripts others are already maintaining (for Debian
and/or Ubuntu).
> Lets pick one set out here. nova-compute-*. Those seem to ship config
> files for compute nodes of different types. lxc, kvm, qemu, whatever.
> We question two things here: That it is neccessary to split them into
> one <100byte file per package ones, and that they all have to conflict
> with each other.
As you know, a package isn't only made with what files it holds. It also
contains precious dependencies. By asking to switch to a single package,
you are removing the possibility to have dependencies that make sense.
Package: nova-compute-kvm
Depends: python-libvirt, libvirt-bin, kvm
I don't want to just document this, OpenStack is complicated enough
already, adding installation of dependencies as a manual thing matching
configuration files or debconf values would be annoying.
> The second part is something for a important bugreport
> - why do you presume to tell me I might not want qemu and uml, or
> qemu/kvm or whatever on one machine? I may not be able to run it at same
> time, but why may I not install them?
For testing, I would understand. But for going on production, it doesn't
make sense to install things for more than one hypervisor in a single
system.
> Now, lets have one technical point too. Why are you doing a chmod +x
> unconditionally in postinst on all the plugin files you just shipped
> with the nova-xcp package? And similar in the -network?
Because otherwise it doesn't work (if I remember well, it took me a full
month last year to find this out). Or are you pointing out that I could
ship these files already with the +x bit? Though, if that is your view,
how much would you rate this seriousness? IMO, not more than wishlist.
> [2] why does the xen one put its config into /usr/share/nova-compute-xen
> while all the others use /etc/nova for it?
If I remember well (it's been more than a year now...), this is a
problem upstream code, which searches from this location. XCP in Debian
was made as an adaptation from XCP in CentOS, and there are still lots
of things that needs to be fixed upstream. As you may (or not) have seen
on the BTS, I spent the whole year either working on fixing lots of such
issues myself, or trying to push upstream to do so (when it is located
in the Ocaml code which I don't understand). I believe I pointed that
one out to upstream, but it hasn't been addressed yet. I will file a bug
on the BTS to remember it. This kind of things is rather low on both my
priority (see the remaining issues on the BTS), and the one of upstream,
unfortunately. It isn't a policy violation, and AFAIK (correct me if I'm
wrong), it is just not very standard, and annoys me a but with
dh_python2 calls in debian/rules. So I agree shall be fixed at some
point (upstream), though I think it's not that important / urgent.
Thomas
Reply to: