> On 18/12/12 23:09, Ronelle Landy wrote: > >> From: [email protected] > >> To: [email protected] > >> Sent: Tuesday, December 18, 2012 12:26:20 PM > >> Subject: Rev1 CIMI ResourceMetadata capabilities > >> <... snip ....> > > > > np - thanks for the feedback: > > > > - The XML example above shows name, uri and description for each > > capability added. After applying the patches, I see the name and > > uri but no description ... json output is copied below - see > > empty decsription: > > > > {"id":"http://qeblade39.rhq.lab.eng.bos.redhat.com:3001/cimi/resource_metadata","count":1,"resourceMetadata":[{"id":"http://qeblade39.rhq.lab.eng.bos.redhat.com:3001/cimi/resource_metadata/machine","name":"Machine","typeUri":"http://qeblade39.rhq.lab.eng.bos.redhat.com:3001/cimi/machines","capabilities":[{"name":"DefaultInitialState","uri":"http://schemas.dmtf.org/cimi/1/capability/Machine/DefaultInitialState","description":[],"values":[{"value":"STARTED"}]},{"name":"DefaultInitialState","uri":"http://schemas.dmtf.org/cimi/1/capability/Machine/DefaultInitialState","description":[],"values":[{"value":"STARTED"},{"value":"STOPPED"}]}]}],"resourceURI":"http://schemas.dmtf.org/cimi/1/ResourceMetadataCollection"} > > > > > couldn't re-create this one... wonder if it's a sinatra-rabbit > version > issue... what does gem list sinatra-rabbit say (I am running 1.1.3) >
with rev2 (which looks a lot nicer in general the capability description is returned so we're all good on this one: <Collection xmlns="http://schemas.dmtf.org/cimi/1" resourceURI="http://schemas.dmtf.org/cimi/1/ResourceMetadataCollection"> <id>http://qeblade39.rhq.lab.eng.bos.redhat.com:3001/cimi/resource_metadata</id> <count>1</count> <ResourceMetadata> <id>http://qeblade39.rhq.lab.eng.bos.redhat.com:3001/cimi/resource_metadata/machine</id> <name>Machine</name> <typeUri>http://schemas.dmtf.org/cimi/1/Machine</typeUri> <capability name="DefaultInitialState" uri="http://schemas.dmtf.org/cimi/1/capability/Machine/DefaultInitialState" description="Indicates what the default initial state of a new Machine ">STARTED</capability> <capability name="InitialStates" uri="http://schemas.dmtf.org/cimi/1/capability/Machine/InitialStates" description="Indicates the list of allowable initial states">STARTED,STOPPED</capability> </ResourceMetadata> </Collection> > > > > - When creating a new machine, where in the POST command would I > > specify the desired initial state? > > > > There's an 'initialState' attribute for machineTemplate... at a guess > it > would look like (NOTE: our machine create code is not yet setup to > parse > and act on this initial state yet): > > curl -v --user "userassword" -X POST -H "Content-Type: > application/xml" -H "Accept: application/xml" -d ' > <MachineCreate xmlns="http://schemas.dmtf.org/cimi/1"> > <name> myMachine1 </name> > <description> my machine </description> > <machineTemplate> > <initialState> STARTED </initialState> > <machineConfig > href="http://localhost:3001/cimi/machine_configurations/m1.small"> > </machineConfig> > <machineImage > href="http://localhost:3001/cimi/machine_images/ami-48aa4921"> > </machineImage> > </machineTemplate> > </MachineCreate>' http://localhost:3001/cimi/machines I tried a POST machineCreate operation - specifying initialState (for both mock and rhevm). It didn't change the initial state (as noted above: machine create code is not set up to act on it yet) but I didn't get an error and a machine was created for both mock and rhevm - so that's a plus. imho - ACK <... snip ...>
