Re: [Xen-devel] [GIT PULL] remove xend for 4.5 (Was: Re: [PATCH] MAINTAINERS: Exclude xend from toolstack maintainers entry)

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Mar 27, 2014 at 12:12 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Thu, 2014-03-27 at 12:03 +0000, George Dunlap wrote:
>> On Thu, Mar 27, 2014 at 11:18 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
>> wrote:
>> > On Thu, 2014-03-27 at 11:08 +0000, George Dunlap wrote:
>> >> On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
>> >> wrote:
>> >> On my list of dependencies for removing xend, I have the following:
>> >>
>> >> * xend still in tree (x)
>> >>  - xl list -l on a dom0-only system
>> >
>> > Not sure what this was, doesn't sound either hard or critical though.
>>
>> This is from an e-mail from Konrad, msd-id
>> <20130904140414.GA3188@xxxxxxxxxxxxxxxxxxx> .  He said:
>>
>> - No status in xl list -l when only dom0 is present.
>>
>> I'm not sure exactly what that means.  On my system, "xl list -l" on a
>> system with no domUs running produces an empty, but valid, array -- "[
>> ]".  (With some extra whitespace.)
>>
>> Looking further in the thread, it looks like Wei took a look at this,
>> and that at the moment "xl list -l" depends on reading the config file
>> from disk, which is a bigger architectural issue that needs to be
>> resolved.  You posted a PoC patch that you had started, but obviously
>> it hasn't been upstreamed yet.
>>
>> So this should probably actually be "xl list -l contains no
>> information for dom0".
>
> I think Wei was going to work on this again shortly IIRC from our
> discussion last week.
>
>> >>  - xl list -l doesn't contain tty console port
>> >
>> > I think this was fixed, wasn't it (assuming I understand what it
>> > actually means).
>> >
>> >>  - xl Alternate transport support for migration*
>> >
>> > What is this?
>>
>> From another section of my to-do list:
>>
>> * xl migrate transport improvements
>>  owner: None
>>  > See discussion here: http://bugs.xenproject.org/xen/bug/19
>>  - Option to connect over a plain TCP socket rather than ssh
>>  - xl-migrate-recieve suitable for running in inetd
>>  - option for above to redirect log output somewhere useful
>>  - Documentation for setting up alternate transports
>
> http://bugs.xenproject.org/xen/bug/18 might be something of a duplicate
> of this.
>
> It's not clear what this has to do with xend though, it looks like a
> wishlist feature request for xl to me, but one that has no relationship
> with xend.
>
>>
>> OTOH, as a result of that discussion, it became clear that:
>> 1. xl did have the ability to use socat / ssl; the command-line
>> arguments to do that are a bit wonky, however, and the documentation
>> is far from clear
>> 2. The system envisioned was terribly insecure.  Receiving a domain at
>> the moment allows the sender trivial access to all files on the system
>> (including your root disk); receiving domains without authenticating
>> the sender means implicit trust of the entire control network.
>>
>> So perhaps this wouldn't be a blocker.
>
> Indeed, not even close IMHO.
>
>> >>  - xl support for vnc and vnclisten options with PV guests
>> >
>> > Wei fixed this already, in 4.4 even perhaps.
>> >
>> >> - xl PVSCSI support
>> >> - xl PVUSB support
>> >
>> > Meh.
>> >
>> > Any of the above which are still issues can still be considered to
>> > become blockers for 4.5, that doesn't necessarily imply they should
>> > block removal of xend.
>> >
>> > I think at some point we just have to rip the plaster off and I think
>> > that time is now. Doing so will provide additional impetus to actually
>> > fix any remaining issues, as it stands things have stagnated because
>> > people just think "oh, it's ok xend is still available".
>>
>> FWIW, back in September when we had this discussion, Olaf and Jan both
>> said they still had customers using PVSCSI.  I responded:
>>
>>  "...at some point, if it's not important enough for someone to
>> implement, it's not important enough to keep supporting."
>>
>> To which Jan replied, "I accept that this is one way of viewing
>> things, but as someone implementing hypervisor side stuff for people
>> even if neither I nor customers of my employer immediately need it, I
>> think it is not completely off to expect some symmetry here: I think
>> it is reasonable for someone to point out deficiencies in areas (s)he
>> doesn't normally work on, and expect those responsible for these areas
>> to pick this up unless it's completely off."
>>
>> And I think he has a point.
>
> True.
>
> It looks like Olaf has this in hand though.
>
>> So what about the following dependency list?
>>
>> * xend still in tree
>>  [blocker]
>
> NB: I would consider these blockers for 4.5, *not* blockers for removing
> xend.

Blockers for xl for 4.5 if re remove xend.  :-)

If we're OK to accept those two as blockers for 4.5, then this pull has my ack.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel