[Xen-devel] Re: Re: [Xen-tools] [RFC] xm interface proposed changes

[Sean Dague <sean@xxxxxxxxx>]

On Fri, Jul 29, 2005 at 04:28:56PM +0100, harry wrote:
> On Fri, 2005-07-29 at 10:44 -0400, Sean Dague wrote:
> > On Fri, Jul 29, 2005 at 03:25:04PM +0100, harry wrote:
> >> <big snip>
> > I actually think this is exactly the opposite from what we want, and is
> > actually what is in there now and makes it such a mess.
> 
> No, it's not remotely what's in there now.  Right now, the configuration
> tools contain a lot of explicit knowledge about the system.  In fact,
> every single aspect of the system has part of its function in the python
> tools.  This is why the tools are a mess.
> 
> I'm saying relocate all of that back to the individual components which
> are to be configured such that each individual configurable aspect has
> both the implementation of the function and the configuration interface
> in once place rather than split into two with half in python.
> 
> This would leave the configuration tools as a combination of a discovery
> mechanism and a simple pipe from the command line to the component to be
> configured.
> 
> > 
> > Let's look at xm help, for instance.  In order to run xm help, which you
> > think would be simple, you have to import about 10 objects for every feature
> > that xm could possibly support, if any of these fail you die.  Then you need
> > to instantiate classes for every sub command, if any of these fail, you 
> > die. 
> > Then you run through each object, figure out what group it is in, pull help
> > from each object, and stick that together.  If anything fails here, you die.
> 
> That's just crap implementation.  The basic idea is vaguely correct.
> There's no good reason for any of this to fail so failure simply
> shouldn't be an option.

First rule of software, things always fail.  There are plenty of reasons for
things to fail.  A daemon died somewhere along the way, you ran out of
resources to run in, you didn't have enough permissions, etc.

If the software can't detect a failure in a useful way, and regroup then I
certainly wouldn't run it on my network, and I definitely wouldn't trust it
to run my virtual machines.

> > The real rub is that those 10 imported objects, all import their own
> > objects, etc.  If any of those fail, you die.  A really good instance is
> > "why can't I run xm help as none root?".  Because xm needs write access to
> > the xend log files (buried about 5 object imports down).  You can't seperate
> > that out in any reasonable way to check permissions upfront.  You can't move
> > the imports into main() to trap there, because all the 20 classes for each
> > command expect those objects to be global in main.py to operate on them.
> > 
> > So lets say you end up with a model where you *can* catch each object
> > failure, what do you do?  Do you quietly turn off/on options based on what
> > is there?  That means the interface of xm would change day to day.  I'd hate
> > to have to answer support questions on that. :)
> 
> In the previous note, I proposed that the xm interface reflect the
> components which were explicitly active.  A compromise would be for the
> xm interface to reflect the installed components rather than those that
> were explicitly active. With this compromise, a new component would have
> two parts: a configuration plug-in and an active implementation of the
> component.  Xm would discover the installed configuration plug-ins. This
> would still be relatively easy to extend and maintain compared to the
> current monolithic system.
> 
> > 
> > While quite interesting from an engineering elegance point of view, it is
> > quite problematic from a user point of view.  xm help should provide the
> > same set of options this morning and this afternoon, unless I very
> > intentionally upgraded the program.  Additionally the future architecture is
> > really centered on xenstore as the management interface.  I don't think
> > integrating every possible usage of xenstore into xm/xend is the right
> > approach.
> 
> I would say that xm help should reflect what I could currently do with
> the system, not what would be possible if I downloaded and installed
> every single possible 3rd party extension.
> 
> I don't understand what you mean by "integrating every possible usage of
> xenstore into xm/xend".  I wouldn't want anything in xm/xend apart from
> the generic pipe and discovery mechanism mentioned above.
> 
> > 
> > I think this needs to take a much more user centric, Model-View-Controler
> > approach.  Forcing the User Interface to be a direct reflection of how we
> > happen to have objects underneath usually just causes no end of usability
> > (and maintenance) pain.
> 
> With either extensible proposal, the user interface doesn't need to be a
> reflection of the low-level underlying objects.  Each installable
> component gets to design whatever user interface is appropriate to best
> configure its functionality.  If components are independent then
> reflection of underlying objects in the interface is natural at the
> component level and if they are not independent there's no reason why
> they can't have a common configuration component which provides a
> spanning configuration model.
> 
> Also, we are talking about the lowest level configuration interface here
> which in practise will be an internal interface between the system
> components and a higher level user GUI. So, I think there is a slightly
> different trade-off desired here than ultimate ease-of-use.

Calling a python program the lowest level interface means we clearly have
different definitions of lowest. ;)  libxenstore is the low level interface,
xm & xend is a user interface.
 
> In particular, it is required that the system support 3rd party
> extensions and I think it will prove essential that integrating
> configuration and help support for those extensions should avoid a
> dependency on changes to the low-level tools and serialisation through a
> single maintainer.
> 
> Harry

        -Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________

Attachment: pgpT9OxsJfWdI.pgp
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel