Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On 04/17/2013 02:49 PM, Tollef Fog Heen wrote:
>> 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.
>
> I think it does: I might be interested in running less trusted code in
> KVM, since it provides more isolation, and more trusted code in lxc,
> which provides less isolation, so running both lxc and kvm at the same
> time certainly makes a ton of sense to me.
You guys are writing this as if it was impossible to switch from one
hypervisor to another. Yet this is simply not the case. You can easily
switch from one type of hypervisor to another with the current packages
(by editing /etc/nova/nova-compute.conf manually and installing the
dependencies manually as well). My point is just that multiple packages
make it possible to automate the switch in the config file and
dependencies by simply doing apt-get. I think this is an important
feature and I don't want to see it go.
If we consider that I'm requesting 5 more binary packages, and that we
have 30 000 packages in Debian, we are talking about 0.016% more binary
packages in Debian. I can't believe that only for 0.016% more binaries
is so unbearable for the archive.
>> 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.
>
> You should ship them with the +x bit already. I'd rate it serious or
> important, since you're breaking dpkg-statoverride.
Indeed. I never wrote it shouldn't be fixed. Though in my view it
shouldn't be a blocker for approving nova 2013.1, first because the bug
is already in the older versions of the package, and because nova 2013.1
fixes #700620. I believe it is a lot more annoying than just this
dpkg-statoverride thing, which I will not have time to fix until next
week when I'm back at home anyway.
> (I'd love for Lintian to grow a check for changing permissions of
> shipped files so we could get rid of that completely. I don't think it
> has it yet.)
Agreed. I think I would have spot the remaining hack from last year
when I was trying to have OpenStack + XCP work together.
Thomas
Reply to: