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