[Pkg-xen-devel] Current status

[Guido Trotter]

On Sun, Feb 19, 2006 at 01:14:08AM -0800, Jeremy T. Bouse wrote:

Hi,

>     I have to agree that we've gotten a lot done and think what we have
> setup is a great start.
> 

Yeah, I agree... So let's start finishing our efforts! ;)

>     Yes, documentation is lacking and we should put something together
> either in NEWS.Debian or a README.Debian to include in the package
> describing the caveats that are still requiring steps be taken outside
> of the packaging. I would have to setup a machine with Adam's 2.0.6
> packages as I found them severly lacking and went with Yvette's 2.0.7
> packages for now. I can test the upgrade path from that if we think it
> is necessary. I'll just be playing around with either my primary or
> secondary MX & NS domUs to do so, but I want them running 3.0.x anyway.
> 

I think we should use NEWS.Debian for actual *changes* in the packaging we want
to esplicitely tell the user about... As they can probably figure out about the
splitting themselves the only thing I can think of now is advice them about the
fact that before having a working xen 3 system, if starting with xen 2 they need
new kernels, which they might not notice.

Then there is README.Debian: there we can document kernel and networking
policies or at least point to other external documents talking about those
issues, and so on! I can write something, tomorrow, but of course I'd appreciate
some review from a native speaker!

>     I think for now this is prolly the best course of action since we
> can't provide any default kernels for dom0 or domU currently. I do think
> for a complete solution to be able to be done out-of-the-box install we
> will need atleast a basic dom0 in the archive eventually but that will
> most likely mean dealing through -devel to get consensus and approval first.
> 

Ok

>     I think debianizing might be the best way to go. I think it will be
> easier to manage for someone new but understands the standard
> configuration usage within debian. That said I think it should be
> attempted to maintain backwards compatibility if possible should we go
> that route. As you said the current way interferes with the network
> configuration and that isn't an ideal situation. As well there isn't
> much documentation I could find for handling multiple NICs where only
> one is used for domUs and the other is for dom0 only or even setting up
> multiple NICs to be used.
> 

Ok, so still some more work to do... ;)

>     I had already thought about this myself, though I'd put it off till
> we had packaging we were ready to upload. I have sent emails to Adam on
> multiple occassions as well as through the BTS and have yet to receive
> anything one way or the other. I know I'm not the only one that has
> attempted to contact him as well. I'm certainly not the only one
> frustrated with the lack of response.
> 
>     I was planning on one more attempt to contact Adam plus Cc'ing to
> -devel expressing the intention to take over maintainership and give a
> delay before it is uploaded. In fact I was going to suggest doing the
> upload myself, so as to take any flak that might result from what would
> essentially seem to appear like a hostile takeover to some possibly. I
> would make use of the delayed upload [2] to automate the delay so we
> wouldn't need to take further action once I upload the file it would be
> released after the given number of days delay. I was figuring something
> between 7-15 days delay to give Adam ample time to respond.
> 

Well, a mail to -devel now could be nice, and maybe also attract other
contributors... Even if I think we tried to involve everybody who said he was
interested... Also an announcement made through alioth could be useful: we want
to have a consensus as large as possible...

As for the upload you can of course do it, but you're not going to take the
blame alone, if there will be any! We're all working on this, so both good and
bad reactions should be considered by all of us!


>     Well without doing anything to /lib/tls Xen itself should spit out a
> warning message to the console, should the user bother to notice it. The
> notice does describe the technic to move it out of the way and disable
> it. We again should put this in a NEWS.Debian or README.Debian anyway if
> we decide to go this route.
> 

I think it should go in README.Debian, as it's nothing new! ;)

>     Another route might be to modify the init.d script to determine if
> we are running under Xen and move the directory out of the way on
> boot-up and move it back on shutdown. Not sure if we want to go this
> route or not, but it would only affect the system while running under
> Xen and leave it alone when running a standard kernel.
> 

Problems: what if there is both tls and tls.disabled from an older version of
Xen? Anyway before doing this we must get permission from debian-policy and
debian-devel!

> 	Other than that I can't think of anything else at this time. I believe the 'installer' issue will be left as a wishlist item for the time being as I think that it won't be practical until we can put the dom0/domU kernels in the archive with atleast a base default configuration. The idea of the 'installer', as I understand it from Yvette, is to be able to do a Xen install from scratch. Just like how the new d-i just finally started allowing MD and LVM on install I think this will take time once things stablize and default kernels can be included. As well it would entail making udeb's which could be added to d-i process. A bit more work than we want right now until we get everything already on our plate dealt with.
> 

Oh, so it was actually "integration with d-i"... Yeah, we definitely need to
postpone it until kernel and tls are sorted out, at least!

Guido

PS going to be mostly away for today! Have a good weekend!