You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltacloud.apache.org by lu...@redhat.com on 2012/11/09 05:18:43 UTC
[PATCH 4/8] CIMI: toplevel collections must have a resourceURI attr in XML
From: David Lutterkort <lu...@redhat.com>
---
server/lib/cimi/models/base.rb | 1 +
server/tests/cimi/spec_helper.rb | 5 ++++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/server/lib/cimi/models/base.rb b/server/lib/cimi/models/base.rb
index 63b24ae..6a73cf6 100644
--- a/server/lib/cimi/models/base.rb
+++ b/server/lib/cimi/models/base.rb
@@ -235,6 +235,7 @@ class CIMI::Model::Resource
def self.to_xml(model)
xml = @schema.to_xml(model)
xml["xmlns"] = CMWG_NAMESPACE
+ xml["resourceURI"] = resource_uri
XmlSimple.xml_out(xml, :root_name => xml_tag_name)
end
diff --git a/server/tests/cimi/spec_helper.rb b/server/tests/cimi/spec_helper.rb
index e1f2ee4..e86eaee 100644
--- a/server/tests/cimi/spec_helper.rb
+++ b/server/tests/cimi/spec_helper.rb
@@ -32,6 +32,9 @@ def parse_xml(xml, opts = {})
end
class HashCmp
+
+ IGNORED_KEYS = [ "resourceURI" ]
+
def initialize(exp, act)
@exp = exp
@act = act
@@ -77,7 +80,7 @@ class HashCmp
unless (missing = exp.keys - act.keys).empty?
error "Missing key(s) at /#{path.join("/")}: #{missing.inspect}"
end
- unless (excess = act.keys - exp.keys).empty?
+ unless (excess = act.keys - exp.keys - IGNORED_KEYS).empty?
error "Excess key(s) at /#{path.join("/")}: #{excess.inspect}"
end
(exp.keys - missing - excess).each do |k|
--
1.7.7.6
Re: DC's use of CIMI extensions
Posted by Doug Davis <du...@us.ibm.com>.
The "properties" are really meant to be used by clients as a spot to put
any random data that only it knows how to interpret. So, asking a client
to put a piece of data in there that the server is to then use would go
against that pattern. A better approach would be to define an extension
top-level attribute (sibling to "name", etc...) called "realm_id". The
client can then fill this in knowing that the server will either fault it
if it doesn't understand it, or accept it and take the appropriate action.
> So if I understand this properly, we should not add 'machine_image' and
> 'credential' to the machine properties if client does not set them upon
> machine creation time or machine update.
Its not so much a question of whether the client sets them or not, its more
about whether the server should even look in there for them. CIMI says
that the server should do nothing more than store them and return them back
on a GET. If the server is looking for data from the client that it is
supposed to act upon then they need to be top-level attributes, not part of
"properties".
thanks
-Doug
________________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Michal Fojtik <mf...@redhat.com> wrote on 12/11/2012 05:53:36 AM:
> From: Michal Fojtik <mf...@redhat.com>
> To: dev@deltacloud.apache.org,
> Date: 12/11/2012 05:54 AM
> Subject: Re: DC's use of CIMI extensions
>
> On 12/10, Doug Davis wrote:
> >
> > All,
> > CIMI says: Each resource in the CIMI model has an attribute called
> > "properties." Consumers, when creating or updating a resource, may
store
> > any name/value pair in the "properties" attribute. CIMI Providers shall
> > store and return these values to the Consumer. There is no obligation
for
> > the Provider to understand or take any action based on these values;
they
> > are there for the Consumer's convenience. Providers shall not add
elements
> > to this "properties" attribute.
>
> So if I understand this properly, we should not add 'machine_image' and
> 'credential' to the machine properties if client does not set them upon
> machine creation time or machine update.
>
> I'm currently working on different scenario:
>
> 1. In Deltacloud API we have 'realms' that maps to 'Cluster' in oVirt or
> 'Datastore' in VSphere or the 'Zone' in EC2 (us-west1, etc..).
> When creating Machine using CIMI, I was not able to find any
'matching'
> entity that we can use.
>
> So we plan to use this 'workaround':
>
> 2. Consumer create a new MachineTemplate with:
> <property key='realm_id'>us-west1</property>
>
> 3. Consumer then create new Machine using that MachineTemplate
>
> 4. Provider then parse 'realm_id' property and launch the Machine in
> corrent zone/cluster/datastore.
>
> Is this correct, or there is a better way how to do it?
>
> -- Michal
>
> >
> > DC returns for /machines:
> > <Machine><property key="credential">
> > http://api.deltacloud.org/cimi/credentials</property><property
> > key="machine_image">http://api.deltacloud.org/cimi/machine_images/img3
> > </property><cpu>4</cpu><operation rel="
> > http://schemas.dmtf.org/cimi/1/action/restart" href="
> > http://api.deltacloud.org/cimi/machines/inst19/restart"/><operation
rel="
> > http://schemas.dmtf.org/cimi/1/action/stop" href="
> > http://api.deltacloud.org/cimi/machines/inst19/stop"/><operation rel="
> > http://schemas.dmtf.org/cimi/1/action/capture" href="
> > http://api.deltacloud.org/cimi/machine_images"/><volumes href="
> > http://api.deltacloud.org/cimi/machines/inst19/volumes"/><disks href="
> > http://api.deltacloud.org/cimi/machines/inst19/disks"/>
> > <state>STARTED</state><created>2012-12-07T17:53:19-05:00</created><id>
> > http://api.deltacloud.org/cimi/machines/inst19
> > </id><name>cimi_machine_from_templatejson</name><description> Created
> > machine from
templatejson</description><memory>12582912</memory></Machine>
> >
> > I think these extensions need to be serialized as top-level attributes
on
> > resources instead of using "properties".
> >
> > thanks
> > -Doug
> > ________________________________________________________
> > STSM | Standards Architect | IBM Software Group
> > (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
> > The more I'm around some people, the more I like my dog.
>
> --
> Michal Fojtik <mf...@redhat.com>
> Deltacloud API, CloudForms
>
Re: DC's use of CIMI extensions
Posted by Michal Fojtik <mf...@redhat.com>.
On 12/10, Doug Davis wrote:
>
> All,
> CIMI says: Each resource in the CIMI model has an attribute called
> "properties." Consumers, when creating or updating a resource, may store
> any name/value pair in the "properties" attribute. CIMI Providers shall
> store and return these values to the Consumer. There is no obligation for
> the Provider to understand or take any action based on these values; they
> are there for the Consumer's convenience. Providers shall not add elements
> to this "properties" attribute.
So if I understand this properly, we should not add 'machine_image' and
'credential' to the machine properties if client does not set them upon
machine creation time or machine update.
I'm currently working on different scenario:
1. In Deltacloud API we have 'realms' that maps to 'Cluster' in oVirt or
'Datastore' in VSphere or the 'Zone' in EC2 (us-west1, etc..).
When creating Machine using CIMI, I was not able to find any 'matching'
entity that we can use.
So we plan to use this 'workaround':
2. Consumer create a new MachineTemplate with:
<property key='realm_id'>us-west1</property>
3. Consumer then create new Machine using that MachineTemplate
4. Provider then parse 'realm_id' property and launch the Machine in
corrent zone/cluster/datastore.
Is this correct, or there is a better way how to do it?
-- Michal
>
> DC returns for /machines:
> <Machine><property key="credential">
> http://api.deltacloud.org/cimi/credentials</property><property
> key="machine_image">http://api.deltacloud.org/cimi/machine_images/img3
> </property><cpu>4</cpu><operation rel="
> http://schemas.dmtf.org/cimi/1/action/restart" href="
> http://api.deltacloud.org/cimi/machines/inst19/restart"/><operation rel="
> http://schemas.dmtf.org/cimi/1/action/stop" href="
> http://api.deltacloud.org/cimi/machines/inst19/stop"/><operation rel="
> http://schemas.dmtf.org/cimi/1/action/capture" href="
> http://api.deltacloud.org/cimi/machine_images"/><volumes href="
> http://api.deltacloud.org/cimi/machines/inst19/volumes"/><disks href="
> http://api.deltacloud.org/cimi/machines/inst19/disks"/>
> <state>STARTED</state><created>2012-12-07T17:53:19-05:00</created><id>
> http://api.deltacloud.org/cimi/machines/inst19
> </id><name>cimi_machine_from_templatejson</name><description> Created
> machine from templatejson</description><memory>12582912</memory></Machine>
>
> I think these extensions need to be serialized as top-level attributes on
> resources instead of using "properties".
>
> thanks
> -Doug
> ________________________________________________________
> STSM | Standards Architect | IBM Software Group
> (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
--
Michal Fojtik <mf...@redhat.com>
Deltacloud API, CloudForms
DC's use of CIMI extensions
Posted by Doug Davis <du...@us.ibm.com>.
All,
CIMI says: Each resource in the CIMI model has an attribute called
"properties." Consumers, when creating or updating a resource, may store
any name/value pair in the "properties" attribute. CIMI Providers shall
store and return these values to the Consumer. There is no obligation for
the Provider to understand or take any action based on these values; they
are there for the Consumer's convenience. Providers shall not add elements
to this "properties" attribute.
DC returns for /machines:
<Machine><property key="credential">
http://api.deltacloud.org/cimi/credentials</property><property
key="machine_image">http://api.deltacloud.org/cimi/machine_images/img3
</property><cpu>4</cpu><operation rel="
http://schemas.dmtf.org/cimi/1/action/restart" href="
http://api.deltacloud.org/cimi/machines/inst19/restart"/><operation rel="
http://schemas.dmtf.org/cimi/1/action/stop" href="
http://api.deltacloud.org/cimi/machines/inst19/stop"/><operation rel="
http://schemas.dmtf.org/cimi/1/action/capture" href="
http://api.deltacloud.org/cimi/machine_images"/><volumes href="
http://api.deltacloud.org/cimi/machines/inst19/volumes"/><disks href="
http://api.deltacloud.org/cimi/machines/inst19/disks"/>
<state>STARTED</state><created>2012-12-07T17:53:19-05:00</created><id>
http://api.deltacloud.org/cimi/machines/inst19
</id><name>cimi_machine_from_templatejson</name><description> Created
machine from templatejson</description><memory>12582912</memory></Machine>
I think these extensions need to be serialized as top-level attributes on
resources instead of using "properties".
thanks
-Doug
________________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Re: [PATCH 4/8] CIMI: toplevel collections must have a resourceURI
attr in XML
Posted by David Lutterkort <lu...@redhat.com>.
On Fri, 2012-11-09 at 15:41 -0500, Doug Davis wrote:
> Sure the data is there but its inconsistent from an XML perspective to only
> have one class with a ResourceURI, while all of the others use the root xml
> NS/name for that purpose. But I guess it depends on whether your model has
> one collection class or multiple.
We have multiple (one class for each collection) - and sure, adding a
resourceURI everywhere would help consistency.
David
Re: [PATCH 4/8] CIMI: toplevel collections must have a resourceURI attr in
XML
Posted by Doug Davis <du...@us.ibm.com>.
Sure the data is there but its inconsistent from an XML perspective to only
have one class with a ResourceURI, while all of the others use the root xml
NS/name for that purpose. But I guess it depends on whether your model has
one collection class or multiple.
thanks
-Doug
________________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
From: David Lutterkort <lu...@redhat.com>
To: dev@deltacloud.apache.org,
Cc: "marios@redhat.com" <ma...@redhat.com>, Doug
Davis/Raleigh/IBM@IBMUS
Date: 11/09/2012 02:52 PM
Subject: Re: [PATCH 4/8] CIMI: toplevel collections must have a
resourceURI attr in XML
On Fri, 2012-11-09 at 11:16 -0500, Doug Davis wrote:
> it can't hurt to add that sentence.
I am all for adding that sentence.
> I actually ran into that recently
> and was bugged that we needed a resourceURI at all for XML - I know
that's
> the price we pay for using the same root element for all collections, but
> bleck! :-) Maybe for v2 we can convince folks (Gil) to use a
> collection-specific root element name.
I am actually fine with the way things are now - I was pleasantly
surprised how easy it was to dispatch to the correct model class from
the response only.
David
Re: [PATCH 4/8] CIMI: toplevel collections must have a resourceURI
attr in XML
Posted by David Lutterkort <lu...@redhat.com>.
On Fri, 2012-11-09 at 11:16 -0500, Doug Davis wrote:
> it can't hurt to add that sentence.
I am all for adding that sentence.
> I actually ran into that recently
> and was bugged that we needed a resourceURI at all for XML - I know that's
> the price we pay for using the same root element for all collections, but
> bleck! :-) Maybe for v2 we can convince folks (Gil) to use a
> collection-specific root element name.
I am actually fine with the way things are now - I was pleasantly
surprised how easy it was to dispatch to the correct model class from
the response only.
David
Re: [PATCH 4/8] CIMI: toplevel collections must have a resourceURI attr in
XML
Posted by Doug Davis <du...@us.ibm.com>.
Hi Marios,
it can't hurt to add that sentence. I actually ran into that recently
and was bugged that we needed a resourceURI at all for XML - I know that's
the price we pay for using the same root element for all collections, but
bleck! :-) Maybe for v2 we can convince folks (Gil) to use a
collection-specific root element name.
I'd recommend opening a new issue since it is more than just a typo -
should be a quick 2 minute discussion/vote.
thanks
-Doug
________________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
From: "marios@redhat.com" <ma...@redhat.com>
To: dev@deltacloud.apache.org,
Cc: lutter@redhat.com, Doug Davis/Raleigh/IBM@IBMUS
Date: 11/09/2012 11:11 AM
Subject: Re: [PATCH 4/8] CIMI: toplevel collections must have a
resourceURI attr in XML
cc'ing Doug Davis here - Doug should I open a Mantis for this? (seems
like minor editorial)
IMO, $subject isn't very clear in the spec...
section 4.1.4 Media Types : "In the JSON serialization of CIMI
representations sent by Providers there shall be an additional attribute
on the root object called "resourceURI" that will contain the unique URI
that is associated with the type of
CIMI resource being serialized. "
I think we can add a sentence here saying that the 'root' Collections
must have a resourceURI for the XML serialization too. It *is* defined
in the XML schema @ http://schemas.dmtf.org/cimi/1/dsp8009_1.0.1.xsd and
shown in the example serialization under 5.5.12 Collections but is that
clear enough?
marios
On 09/11/12 06:18, lutter@redhat.com wrote:
> From: David Lutterkort <lu...@redhat.com>
>
> ---
> server/lib/cimi/models/base.rb | 1 +
> server/tests/cimi/spec_helper.rb | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/server/lib/cimi/models/base.rb
b/server/lib/cimi/models/base.rb
> index 63b24ae..6a73cf6 100644
> --- a/server/lib/cimi/models/base.rb
> +++ b/server/lib/cimi/models/base.rb
> @@ -235,6 +235,7 @@ class CIMI::Model::Resource
> def self.to_xml(model)
> xml = @schema.to_xml(model)
> xml["xmlns"] = CMWG_NAMESPACE
> + xml["resourceURI"] = resource_uri
> XmlSimple.xml_out(xml, :root_name => xml_tag_name)
> end
>
> diff --git a/server/tests/cimi/spec_helper.rb
b/server/tests/cimi/spec_helper.rb
> index e1f2ee4..e86eaee 100644
> --- a/server/tests/cimi/spec_helper.rb
> +++ b/server/tests/cimi/spec_helper.rb
> @@ -32,6 +32,9 @@ def parse_xml(xml, opts = {})
> end
>
> class HashCmp
> +
> + IGNORED_KEYS = [ "resourceURI" ]
> +
> def initialize(exp, act)
> @exp = exp
> @act = act
> @@ -77,7 +80,7 @@ class HashCmp
> unless (missing = exp.keys - act.keys).empty?
> error "Missing key(s) at /#{path.join("/")}: #{missing.inspect}"
> end
> - unless (excess = act.keys - exp.keys).empty?
> + unless (excess = act.keys - exp.keys - IGNORED_KEYS).empty?
> error "Excess key(s) at /#{path.join("/")}: #{excess.inspect}"
> end
> (exp.keys - missing - excess).each do |k|
>
Re: [PATCH 4/8] CIMI: toplevel collections must have a resourceURI
attr in XML
Posted by "marios@redhat.com" <ma...@redhat.com>.
cc'ing Doug Davis here - Doug should I open a Mantis for this? (seems
like minor editorial)
IMO, $subject isn't very clear in the spec...
section 4.1.4 Media Types : "In the JSON serialization of CIMI
representations sent by Providers there shall be an additional attribute
on the root object called "resourceURI" that will contain the unique URI
that is associated with the type of
CIMI resource being serialized. "
I think we can add a sentence here saying that the 'root' Collections
must have a resourceURI for the XML serialization too. It *is* defined
in the XML schema @ http://schemas.dmtf.org/cimi/1/dsp8009_1.0.1.xsd and
shown in the example serialization under 5.5.12 Collections but is that
clear enough?
marios
On 09/11/12 06:18, lutter@redhat.com wrote:
> From: David Lutterkort <lu...@redhat.com>
>
> ---
> server/lib/cimi/models/base.rb | 1 +
> server/tests/cimi/spec_helper.rb | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/server/lib/cimi/models/base.rb b/server/lib/cimi/models/base.rb
> index 63b24ae..6a73cf6 100644
> --- a/server/lib/cimi/models/base.rb
> +++ b/server/lib/cimi/models/base.rb
> @@ -235,6 +235,7 @@ class CIMI::Model::Resource
> def self.to_xml(model)
> xml = @schema.to_xml(model)
> xml["xmlns"] = CMWG_NAMESPACE
> + xml["resourceURI"] = resource_uri
> XmlSimple.xml_out(xml, :root_name => xml_tag_name)
> end
>
> diff --git a/server/tests/cimi/spec_helper.rb b/server/tests/cimi/spec_helper.rb
> index e1f2ee4..e86eaee 100644
> --- a/server/tests/cimi/spec_helper.rb
> +++ b/server/tests/cimi/spec_helper.rb
> @@ -32,6 +32,9 @@ def parse_xml(xml, opts = {})
> end
>
> class HashCmp
> +
> + IGNORED_KEYS = [ "resourceURI" ]
> +
> def initialize(exp, act)
> @exp = exp
> @act = act
> @@ -77,7 +80,7 @@ class HashCmp
> unless (missing = exp.keys - act.keys).empty?
> error "Missing key(s) at /#{path.join("/")}: #{missing.inspect}"
> end
> - unless (excess = act.keys - exp.keys).empty?
> + unless (excess = act.keys - exp.keys - IGNORED_KEYS).empty?
> error "Excess key(s) at /#{path.join("/")}: #{excess.inspect}"
> end
> (exp.keys - missing - excess).each do |k|
>