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

Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summity



On Thu, Apr 18, 2013 at 04:57:03PM +0800, Thomas Goirand wrote:
> On 04/18/2013 02:52 PM, Tollef Fog Heen wrote:
> > ]] Thomas Goirand 
> > 
> > (Cc-ing you, since I don't know if you're subscribed.  Apologies for the
> > extra copy if you are.)
> 
> I am not subscribed indeed, thanks.
> 
> >> 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.
> > 
> > It sounds wrong to use dependencies where dpkg-reconfigure will do.
> 
> You don't get it (I may have explain badly...).
> 
> If one installs nova-compute-kvm, he will be expecting it to have kvm
> installed, and work out of the box. If there was only dpkg-reconfigure,
> then I would have to actually *remove* the dependencies on kvm, and let
> our users solve the dependencies manually. I don't want to do that. I
> think dependencies are important and help our users. I think that
> integrators who run puppet scripts also don't want things to suddenly
> change and break their scripts, or have the setup very different in
> Debian vs other distro. I think it's worth the added 0.016% binaries.
> 
> Though having dependencies doesn't mean you cannot edit the config file
> and use nova-compute-kvm to run the XCP flavor of Nova if you apt-get
> manually the correct dependencies and edit the configuration files. It's
> weird to do that, I personally wouldn't and I don't see any use case for
> it. But it seems that it's what you want to do, and I'm just saying that
> it is possible, if you like to mess with things.

But what is stopping you from allowing nova-compute-kvm and
nova-compute-lcx to both be installed? The user could then choose via
debconf which of the two to use. The debconf question would only list
those options for which nova-compute-* is installed. Or it might not
even be debconf. Maybe alternatives work better there?
 
> >> 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.
> > 
> > It's pushing the knife ever so slightly deeper into the wound. The
> > problem, as Russ has pointed out isn't your five extra packages or
> > somebody else in particular's packages.  It's the cumulative weight of
> > all of them. Yes, in an ideal world this shouldn't be a problem, but
> > until somebody comes up with a fix, that's what we have to work with.
> 
> You are missing the hole point of why I was unhappy with the FTP masters
> to block my package before the OpenStack summit. Since the very
> beginning, I asked about having my package accepted, then we can discuss
> later. That unless you still think that adding 0.016% more binary
> packages *temporarily* until we have an agreement, is adding too much
> load on the infrastructure in the short term.

Nothing remains as long as a temporary exception. Point in case look
at ia32-libs. Which was added temporarily till multiarch was ready.
Took >12 years to get to the point where we can remove it.
 
> I still think all these binary packages are needed, but if we could not
> agree, at least I think it wasn't too much to ask to solve the problem
> later. Especially when absolutely all the other packages were approved.

At which point ftp-master has to invest more time to clean up. I can
see why they would rather fix the problem before accepting the
packages.

> I'm talking about 48 source packages here, plus many other python module
> which I updated during the last 6 months release cycle of OpenStack.
> 
> It is sad that it is impossible to ask for a bit of teamwork, so that we
> meet some political goals helping Debian adoption.
> 
> Thomas

MfG
	Goswin


Reply to: