[Pkg-xen-devel] Current status

[Jeremy T. Bouse]

Guido Trotter wrote:

>Hi!
>
>Ok, last message for this morning, I promise! ;)
>
>I just wanted to make the point with all of you about the status of our
>packages, what we've done and what we're missing! Since what we've done is
>already in the changelog, let's focus on what we're missing!
>  
>
    I have to agree that we've gotten a lot done and think what we have
setup is a great start.

>1. Upgrade: how is the upgrade path from 2.0.6 in unstable? One probably should,
>after upgrading xen, which should be painless, build new kernels for the domain
>0 and for all the guests... So it's quite a manual process... Can we help it
>somehow? (it seems we cannot, for now...) We should at least document this
>prominently in debian/NEWS.Debian or something, though!
>  
>
    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.

>2. Kernels: ok, we cannot distribute them, at least for now... We should
>probably prepare some piece of documentation to help people creating them as
>simply as possible! Also sample .config files could help: at least for the
>unprivileged domains most people could use our config as is, while for the
>domain 0 I'd advice them to build it customizing it. We can help providing a
>"minimal" Domain 0 config, that could be used adding what one needs (eg,
>drivers, ecc) but with everything that's needed/recommended by xen (eg.
>bridging, etc). Then we can also provide a "comprehensive" .config, copied from
>the debian one, so that if someone is lazy/doesn't really want to compile a
>kernel he can build one without changing anything and by just giving some
>commands... Other ideas to help our users?
>  
>
    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.

>3. Networking: do we want to leave it like it is? Or debianize it somehow? Or at
>least explain people how to debianize it? Maybe disable the default scripts?
>(Probably interfering with a machine's network configuration, like xen by
>default does, by adding a bridge device and heuristically chosing which
>interfaces should be added to it, and which ip address should it have could
>count as a serious policy violation... And people could be really angry if for
>any reason the networking configuration of a machine they administer remotely
>breaks because of this! On the other hand if we make it clear from the beginning
>it's *their* responsibility we play safe and also avoid eventual issues if we
>decide to risk, they file an RC bug against our package, and we have to remove
>the feature, then we'll also have to explain it to the users for which it worked)
>  
>
    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.

>4. Dealing with the maintainership: Adam hasn't opposed our project, but he
>hasn't endorsed it either... What should we do before uploading? At least one
>more mail to Adam and to debian-devel I guess it's due, at least to invite adam
>to join us, or to check our changes, or at least to say "whatever, I don't care,
>go ahead"
>  
>
    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.

>5. /lib/tls so, it seems we decided to leave it alone, for now... Before
>uploading we should at least document this prominently! Then trying to
>coordinate with the glibc guys and maybe asking debian-policy if there is any
>way we can do that without them tracking us down and burning our homes could be
>nice! But I guess we can postpone it, for now...
>  
>
    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.

    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.

>Any comments/suggestions on these? Other things I'm missing and we would
>need/like to address? 
>
>Oh, I'm still a bit unsure about what exactly the "installer" that Yvette
>mentioned in her "Of historical interest only [u]" mail[1] was, so I haven't
>mentioned it... Can someone please illuminate me! Thanks! ;)
>
>Guido
>
>[1] http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-February/000037.html
>  
>
	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.

	Jeremy

[2] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-delayed-incoming