In order to have this discussion in a structured way, we should figure out how we want commands structured in general (i.e. where is the verb). It seems the following policy would be mostly in line with the existing command set. If the command direct object is a xen domain (it does something directly to a domain core) then we use "verb" (i.e. create, destroy, save...). If the command direct object is a part of a domain, like a block device or memory, we use "object-verb", mostly so the object commands cluster in a directly command listing. Examples today would be "vbd-list" for instance. If there is a difference of opinion here, we should hammer that out first, because the rest of the discussion is pretty pointless without at least these ground rules. :) To make this easier, here is the command help today (with attributes added in to each command). ========================================================================---------XM HELP TODAY--------------------------------------------------- call Call xend api functions help Print help. Commands related to consoles: console <DomainId> Open a console to a domain. consoles Get information about domain consoles. Commands on domains: balloon <DomainId> <Mem> Set the domain''s memory footprint using the balloon driver. create <ConfigFile> Create a domain. destroy <DomainId> Terminate a domain immediately. domid <DomainName> Convert a domain name to a domain id. domname <DomainId> Convert a domain id to a domain name. list List information about domains. maxmem <DomainId> <Mem> Set domain memory limit. migrate [options] <DomId> <Host> Migrate a domain to another machine. pause <DomainId> Pause execution of a domain. pincpu <DomId> <VCpu> <CPUS> Set which cpus a VCPU can use. restore <File> Create a domain from a saved state. save <DomId> <File> Save domain state (and config) to file. shutdown [options] <DomId> Shutdown a domain. sysrq <DomId> <letter> Send a sysrq to a domain. unpause <DomId> Unpause a paused domain. vcpu-hotplug <DomId> <VCPU> <0|1> Enable or disable a VCPU in a domain. Commands related to the xen host (node): dmesg [--clear] Read or clear Xen''s message buffer. info Get information about the xen host. log Print the xend log. Comands controlling scheduling: bvt DOM MCUADV WARPBACK WARPVALUE WARPL WARPU Set BVT scheduler parameters. bvt_ctxallow CTX_ALLOW Set the BVT scheduler context switch allowance. sedf DOM PERIOD SLICE LATENCY EXTRATIME WEIGHT Set simple EDF parameters. Commands related to virtual block devices: vbd-create <DomId> <BackDev> <FrontDev> <Mode> [BackDomId] Create a new virtual block device for a domain vbd-destroy <DomId> <DevId> Destroy a domain''s virtual block device vbd-list <DomId> List virtual block devices for a domain. vbd-refresh <DomId> <DevId> Refresh a virtual block device for a domain Commands related to virtual network interfaces: vif-limit <DomId> <Vif> <Credit> <Period> Limit the transmission rate of a virtual network interface. vif-list <DomId> List virtual network interfaces for a domain. Try ''/usr/sbin/xm help CMD'' for help on CMD ------------------------------------------------------------------- The following is a proposed set of changes based on the "obj-verb" paradigm, plus trying to make commands make more sense to a user that may not know things about Xen internals. Commands that have renames are marked with (*), commands that are "new" to create what seems like a complete interface are marked with (+). ==================================================================---------XM Proposed----------------------------------------------- help Print help. Commands related to consoles: console <DomId> Open a console to a domain. * console-list Get information about domain consoles. Commands on domains: domid <DomName> Convert a domain name to a domain id. domname <DomId> Convert a domain id to a domain name. create <ConfigFile> Create a domain. destroy <DomId> Terminate a domain immediately. restore <File> Create a domain from a saved state. save <DomId> <File> Save domain state (and config) to file. * shutdown [-w|-a] <DomId> Shutdown a domain. + reboot [-w|-a] <DomId> Reboot a domain. list List information about domains. * mem-max <DomId> <Mem> Set domain maximum memory limit. * mem-set <DomId> <Mem> Set the domain''s memory dynamically. * cpus-set <DomId> <VCpu> <CPUS> Set which cpus a VCPU can use. + cpus-list <DomId> <VCpu> Get the list of cpus for a VCPU * vcpu-enable <DomId> <VCPU> Disable VCPU in a domain. + vcpu-disable <DomId> <VCPU> Enable VCPU in a domain + vcpu-list <DomId> Get the list of VCPUs for a domain migrate [options] <DomId> <Host> Migrate a domain to another machine. sysrq <DomId> <letter> Send a sysrq to a domain. pause <DomId> Pause execution of a domain. unpause <DomId> Unpause a paused domain. Commands related to the xen host (node): dmesg [--clear] Read or clear Xen''s message buffer. info Get information about the xen host. log Print the xend log. Comands controlling scheduling: bvt DOM MCUADV WARPBACK WARPVALUE WARPL WARPU Set BVT scheduler parameters. bvt_ctxallow CTX_ALLOW Set the BVT scheduler context switch allowance. sedf DOM PERIOD SLICE LATENCY EXTRATIME WEIGHT Set simple EDF parameters. Commands related to virtual block devices: * block-create <DomId> <BackDev> <FrontDev> <Mode> [BackDomId] Create a new virtual block device for a domain * block-destroy <DomId> <DevId> Destroy a domain''s virtual block device * block-list <DomId> List virtual block devices for a domain. * block-refresh <DomId> <DevId> Refresh a virtual block device for a domain Commands related to virtual network interfaces: * network-limit <DomId> <Vif> <Credit> <Period> Limit the transmission rate of a virtual network interface. * network-list <DomId> List virtual network interfaces for a domain. Try ''/usr/sbin/xm help CMD'' for help on CMD ----------------------------------------------------------------- Additionally, if we are to move to a model where command aliasing can easily be done (for backwards compatibility), I actually think we need to majorly restructure main.py from an object based model to a declaritive model, where main() would be a dispatcher to possibly many functions that would be the equiv of the main methods in each object today. I also believe that this is the only way to get ''xm help'' to run as non-root, which I consider a goal. I''d like at least tenative approval for this idea before I code it up, but I am *willing to volunteer* for this conversion of main.py from object based -> declaritive structure. Comments welcome, flame away. -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. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
harry
2005-Jul-29 14:25 UTC
[Xen-devel] Re: [Xen-tools] [RFC] xm interface proposed changes
I think you should move towards a model where the tools dynamically discover the available configuration commands from components which are installed in the system such that the tools eventually contain no command specific code at all. For example, on installation, the balloon driver might register itself as a configurable component which provided a single configuration action called (for the sake of argument) resize. When the balloon driver was installed in a domain, the configuration tools would discover the balloon driver as a new configurable sub-object belonging to the domain and query the registered configuration interface to discover the resize method, the help text, the parameter types and the valid parameter range. Subsequent invocations of xm-help would list the domain-balloon-resize method with an indication of the parameters and help text. A mechanism like this would allow 3rd parties to extend the system without having to modify the low-level configuration tools. Having the entire specification and implementation of the configuration interface in a single location (in the example, the balloon driver code) also makes it easier to avoid incompatibilities between the tools and configurable components since there is less coupling. In fact, the level of coupling has been shifted from the component specific details of the configuration interface to the component-independent aspects of the mechanism for specifying interfaces. I think this would naturally tend towards an object-verb form of expression since this would be consistent with the discovery process. Harry. On Fri, 2005-07-29 at 09:04 -0400, Sean Dague wrote:> In order to have this discussion in a structured way, we should figure out > how we want commands structured in general (i.e. where is the verb). > > It seems the following policy would be mostly in line with the existing > command set. > > If the command direct object is a xen domain (it does something directly to > a domain core) then we use "verb" (i.e. create, destroy, save...). If the > command direct object is a part of a domain, like a block device or memory, > we use "object-verb", mostly so the object commands cluster in a directly > command listing. Examples today would be "vbd-list" for instance. If there > is a difference of opinion here, we should hammer that out first, because > the rest of the discussion is pretty pointless without at least these ground > rules. :) > > To make this easier, here is the command help today (with attributes added > in to each command). > > ========================================================================> ---------XM HELP TODAY--------------------------------------------------- > call Call xend api functions > help Print help. > > Commands related to consoles: > > console <DomainId> Open a console to a domain. > consoles Get information about domain consoles. > > Commands on domains: > > balloon <DomainId> <Mem> Set the domain''s memory footprint using the balloon driver. > create <ConfigFile> Create a domain. > destroy <DomainId> Terminate a domain immediately. > domid <DomainName> Convert a domain name to a domain id. > domname <DomainId> Convert a domain id to a domain name. > list List information about domains. > maxmem <DomainId> <Mem> Set domain memory limit. > migrate [options] <DomId> <Host> Migrate a domain to another machine. > pause <DomainId> Pause execution of a domain. > pincpu <DomId> <VCpu> <CPUS> Set which cpus a VCPU can use. > restore <File> Create a domain from a saved state. > save <DomId> <File> Save domain state (and config) to file. > shutdown [options] <DomId> Shutdown a domain. > sysrq <DomId> <letter> Send a sysrq to a domain. > unpause <DomId> Unpause a paused domain. > vcpu-hotplug <DomId> <VCPU> <0|1> Enable or disable a VCPU in a domain. > > Commands related to the xen host (node): > > dmesg [--clear] Read or clear Xen''s message buffer. > info Get information about the xen host. > log Print the xend log. > > Comands controlling scheduling: > > bvt DOM MCUADV WARPBACK WARPVALUE WARPL WARPU Set BVT scheduler parameters. > bvt_ctxallow CTX_ALLOW Set the BVT scheduler context switch allowance. > sedf DOM PERIOD SLICE LATENCY EXTRATIME WEIGHT Set simple EDF parameters. > > Commands related to virtual block devices: > > vbd-create <DomId> <BackDev> <FrontDev> <Mode> [BackDomId] Create a new virtual block device for a domain > vbd-destroy <DomId> <DevId> Destroy a domain''s virtual block device > vbd-list <DomId> List virtual block devices for a domain. > vbd-refresh <DomId> <DevId> Refresh a virtual block device for a domain > > Commands related to virtual network interfaces: > > vif-limit <DomId> <Vif> <Credit> <Period> Limit the transmission rate of a virtual network interface. > vif-list <DomId> List virtual network interfaces for a domain. > > Try ''/usr/sbin/xm help CMD'' for help on CMD > ------------------------------------------------------------------- > > > > The following is a proposed set of changes based on the "obj-verb" paradigm, > plus trying to make commands make more sense to a user that may not know > things about Xen internals. Commands that have renames are marked with (*), > commands that are "new" to create what seems like a complete interface are > marked with (+). > > ==================================================================> ---------XM Proposed----------------------------------------------- > help Print help. > > Commands related to consoles: > > console <DomId> Open a console to a domain. > * console-list Get information about domain consoles. > > Commands on domains: > > domid <DomName> Convert a domain name to a domain id. > domname <DomId> Convert a domain id to a domain name. > > create <ConfigFile> Create a domain. > destroy <DomId> Terminate a domain immediately. > restore <File> Create a domain from a saved state. > save <DomId> <File> Save domain state (and config) to file. > * shutdown [-w|-a] <DomId> Shutdown a domain. > + reboot [-w|-a] <DomId> Reboot a domain. > > list List information about domains. > > * mem-max <DomId> <Mem> Set domain maximum memory limit. > * mem-set <DomId> <Mem> Set the domain''s memory dynamically. > * cpus-set <DomId> <VCpu> <CPUS> Set which cpus a VCPU can use. > + cpus-list <DomId> <VCpu> Get the list of cpus for a VCPU > * vcpu-enable <DomId> <VCPU> Disable VCPU in a domain. > + vcpu-disable <DomId> <VCPU> Enable VCPU in a domain > + vcpu-list <DomId> Get the list of VCPUs for a domain > > migrate [options] <DomId> <Host> Migrate a domain to another machine. > > sysrq <DomId> <letter> Send a sysrq to a domain. > pause <DomId> Pause execution of a domain. > unpause <DomId> Unpause a paused domain. > > Commands related to the xen host (node): > > dmesg [--clear] Read or clear Xen''s message buffer. > info Get information about the xen host. > log Print the xend log. > > Comands controlling scheduling: > > bvt DOM MCUADV WARPBACK WARPVALUE WARPL WARPU Set BVT scheduler parameters. > bvt_ctxallow CTX_ALLOW Set the BVT scheduler context switch allowance. > sedf DOM PERIOD SLICE LATENCY EXTRATIME WEIGHT Set simple EDF parameters. > > Commands related to virtual block devices: > > * block-create <DomId> <BackDev> <FrontDev> <Mode> [BackDomId] Create a new virtual block device for a domain > * block-destroy <DomId> <DevId> Destroy a domain''s virtual block device > * block-list <DomId> List virtual block devices for a domain. > * block-refresh <DomId> <DevId> Refresh a virtual block device for a domain > > Commands related to virtual network interfaces: > > * network-limit <DomId> <Vif> <Credit> <Period> Limit the transmission rate of a virtual network interface. > * network-list <DomId> List virtual network interfaces for a domain. > > Try ''/usr/sbin/xm help CMD'' for help on CMD > ----------------------------------------------------------------- > > > > Additionally, if we are to move to a model where command aliasing can easily > be done (for backwards compatibility), I actually think we need to majorly > restructure main.py from an object based model to a declaritive model, where > main() would be a dispatcher to possibly many functions that would be the > equiv of the main methods in each object today. I also believe that this is > the only way to get ''xm help'' to run as non-root, which I consider a goal. > I''d like at least tenative approval for this idea before I code it up, but I > am *willing to volunteer* for this conversion of main.py from object based > -> declaritive structure. > > Comments welcome, flame away. > > -Sean > > _______________________________________________ > Xen-tools mailing list > Xen-tools@lists.xensource.com > http://lists.xensource.com/xen-tools_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sean Dague
2005-Jul-29 14:44 UTC
[Xen-devel] Re: [Xen-tools] [RFC] xm interface proposed changes
On Fri, Jul 29, 2005 at 03:25:04PM +0100, harry wrote:> I think you should move towards a model where the tools dynamically > discover the available configuration commands from components which are > installed in the system such that the tools eventually contain no > command specific code at all. > > For example, on installation, the balloon driver might register itself > as a configurable component which provided a single configuration action > called (for the sake of argument) resize. When the balloon driver was > installed in a domain, the configuration tools would discover the > balloon driver as a new configurable sub-object belonging to the domain > and query the registered configuration interface to discover the resize > method, the help text, the parameter types and the valid parameter > range. > > Subsequent invocations of xm-help would list the domain-balloon-resize > method with an indication of the parameters and help text. > > A mechanism like this would allow 3rd parties to extend the system > without having to modify the low-level configuration tools. Having the > entire specification and implementation of the configuration interface > in a single location (in the example, the balloon driver code) also > makes it easier to avoid incompatibilities between the tools and > configurable components since there is less coupling. In fact, the level > of coupling has been shifted from the component specific details of the > configuration interface to the component-independent aspects of the > mechanism for specifying interfaces. > > I think this would naturally tend towards an object-verb form of > expression since this would be consistent with the discovery process. > > Harry.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. 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. 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. :) 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 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. Such is my 2 cents. -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. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ronald G. Minnich
2005-Jul-29 14:54 UTC
Re: [Xen-devel] Re: [Xen-tools] [RFC] xm interface proposed changes
On Fri, 29 Jul 2005, Sean Dague wrote:> On Fri, Jul 29, 2005 at 03:25:04PM +0100, harry wrote: > > ... interesting ideas. > > > > I think this would naturally tend towards an object-verb form of > > expression since this would be consistent with the discovery process. > > > > Harry. > > 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. > > I think this needs to take a much more user centric, Model-View-Controler > approach.I think I''m with sean on this one. ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
harry
2005-Jul-29 15:28 UTC
Re: [Xen-devel] Re: [Xen-tools] [RFC] xm interface proposed changes
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@lists.xensource.com http://lists.xensource.com/xen-devel
harry
2005-Jul-29 16:18 UTC
Re: [Xen-devel] Re: [Xen-tools] [RFC] xm interface proposed changes
On Fri, 2005-07-29 at 08:54 -0600, Ronald G. Minnich wrote:> > I think this needs to take a much more user centric, Model-View-Controler > > approach. > > I think I''m with sean on this one.Well, I don''t think anything I said is incompatible with a model-view-controller approach so I''m probably with Sean on that one too. Harry. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sean Dague
2005-Jul-29 17:35 UTC
[Xen-devel] Re: Re: [Xen-tools] [RFC] xm interface proposed changes
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. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel