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
> > 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.
Sean Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
Description: PGP signature
Xen-devel mailing list