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.
__________________________________________________________________
pgpd9TnuCUSb3.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home