changeset 1.1403 breaks previous xm behaviour

changeset 1.1403 breaks previous xm behaviour

[Kip Macy]

With the move to unix sockets from http, xm no longer works if you're
not running it as root. This is perfectly reasonable, but I just
wasted 45 minutes trying to figure out why it didn't work. I kept on
assuming it was a versioning with my libraries.

Did I miss an announcement on the list?

    -Kip

Re: changeset 1.1403 breaks previous xm behaviour

[Steven Hand]

>With the move to unix sockets from http, xm no longer works if you're
>not running it as root. This is perfectly reasonable, but I just
>wasted 45 minutes trying to figure out why it didn't work. I kept on
>assuming it was a versioning with my libraries.
>
>Did I miss an announcement on the list?

No, there was no specific announcement about this incompatability; 
however there were a bunch of discussions in the past about the move 
and the increased security features. Cset 1.1403 includes this enhancement
along with a whole bunch more work Mike has been doing over the past while
(which, among other things, removes the dependence on twisted). 

Note that as we move towards 3.0 there are likely to be situations 
in which xen-unstable is just that: it may not compile, it may not 
support previous platforms or maintain precise semantics. We aim to 
minimize these situations but we are trying hard to move to a point
where we support all the functionality slated for 3.0. It is tougher
to keep up with unstable so if it's not required for your particular 
application you may find using 2.0.5 or 2.0-testing easier. 

If you require http access to xend, you can still enable this by 
adding (xend-http-server yes) in /var/xen/xend-config.sxp  


cheers,

S.

Re: changeset 1.1403 breaks previous xm behaviour

[aq]

On 5/15/05, Steven Hand <Steven.Hand@cl.cam.ac.uk> wrote:
> 
> >With the move to unix sockets from http, xm no longer works if you're
> >not running it as root. This is perfectly reasonable, but I just
> >wasted 45 minutes trying to figure out why it didn't work. I kept on
> >assuming it was a versioning with my libraries.
> >
> >Did I miss an announcement on the list?
> 
> No, there was no specific announcement about this incompatability;
> however there were a bunch of discussions in the past about the move
> and the increased security features. Cset 1.1403 includes this enhancement
> along with a whole bunch more work Mike has been doing over the past while
> (which, among other things, removes the dependence on twisted).

Steven, that means we will remove twisted completely in the (near) future?

regards,
aq

Re: changeset 1.1403 breaks previous xm behaviour

[Andrew Thompson]

aq wrote:
>>(which, among other things, removes the dependence on twisted).
> 
> Steven, that means we will remove twisted completely in the (near) future?

Is twisted *evil*?

I thought I read something about wanting to get away from it, but is 
there a particular reason?

/me is curious.

-- 
Andrew Thompson
http://aktzero.com/

Re: changeset 1.1403 breaks previous xm behaviour

[Steven Hand]

> aq wrote:
> >>(which, among other things, removes the dependence on twisted).
> > 
> > Steven, that means we will remove twisted completely in the (near) future?
> 
> Is twisted *evil*?

Well I wouldn't say that twisted is *evil* but it is somewhat
*twisted* :-) 

> I thought I read something about wanting to get away from it, but is 
> there a particular reason?

Just generally trying to: 

  a) minimize dependencies on any non-standard stuff (one the faqs 
     on the list has to do with twisted), and 
  b) simplify the code so that we can understand it - twisted is 
     overkill for the functionality we require. 

cheers,

S.

Re: changeset 1.1403 breaks previous xm behaviour

[Mark Williamson]

> Is twisted *evil*?
>
> I thought I read something about wanting to get away from it, but is
> there a particular reason?

Xend has to deal with *loads* of different kinds of events (admin socket 
connections, console data demux, device control messages...).  Twisted gives 
us an infrastructure for dealing with these in a non-threaded way.  It also 
gives some nifty things like an HTTP server, etc...

The new approach is to use language-level threads instead.  This makes certain 
things easier to follow, since you can have a thread for each logical stream 
of events.

Twisted has some nice features but we won't really need it once we move to the 
threaded model.  It's a shame to lose the HTTP server but the new Xend will 
include a minimal HTTP server in Python, which will be fine for our needs.

Cheers,
Mark