From mboxrd@z Thu Jan 1 00:00:00 1970 From: harry Subject: Re: [Xen-tools] [RFC] xm interface proposed changes Date: Fri, 29 Jul 2005 15:25:04 +0100 Message-ID: <1122647104.28631.25.camel@localhost.localdomain> References: <20050729130420.GC8654@underhill.no-ip.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20050729130420.GC8654@underhill.no-ip.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Sean Dague Cc: xen-tools@lists.xensource.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 Open a console to a domain. > consoles Get information about domain consoles. > > Commands on domains: > > balloon Set the domain's memory footprint using the balloon driver. > create Create a domain. > destroy Terminate a domain immediately. > domid Convert a domain name to a domain id. > domname Convert a domain id to a domain name. > list List information about domains. > maxmem Set domain memory limit. > migrate [options] Migrate a domain to another machine. > pause Pause execution of a domain. > pincpu Set which cpus a VCPU can use. > restore Create a domain from a saved state. > save Save domain state (and config) to file. > shutdown [options] Shutdown a domain. > sysrq Send a sysrq to a domain. > unpause Unpause a paused domain. > vcpu-hotplug <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 [BackDomId] Create a new virtual block device for a domain > vbd-destroy Destroy a domain's virtual block device > vbd-list List virtual block devices for a domain. > vbd-refresh Refresh a virtual block device for a domain > > Commands related to virtual network interfaces: > > vif-limit Limit the transmission rate of a virtual network interface. > vif-list 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 Open a console to a domain. > * console-list Get information about domain consoles. > > Commands on domains: > > domid Convert a domain name to a domain id. > domname Convert a domain id to a domain name. > > create Create a domain. > destroy Terminate a domain immediately. > restore Create a domain from a saved state. > save Save domain state (and config) to file. > * shutdown [-w|-a] Shutdown a domain. > + reboot [-w|-a] Reboot a domain. > > list List information about domains. > > * mem-max Set domain maximum memory limit. > * mem-set Set the domain's memory dynamically. > * cpus-set Set which cpus a VCPU can use. > + cpus-list Get the list of cpus for a VCPU > * vcpu-enable Disable VCPU in a domain. > + vcpu-disable Enable VCPU in a domain > + vcpu-list Get the list of VCPUs for a domain > > migrate [options] Migrate a domain to another machine. > > sysrq Send a sysrq to a domain. > pause Pause execution of a domain. > unpause 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 [BackDomId] Create a new virtual block device for a domain > * block-destroy Destroy a domain's virtual block device > * block-list List virtual block devices for a domain. > * block-refresh Refresh a virtual block device for a domain > > Commands related to virtual network interfaces: > > * network-limit Limit the transmission rate of a virtual network interface. > * network-list 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