On 11/13/2012 01:10 PM, Koper, Dies wrote:
Hi Michal,
The horrible looking 'uuid' field is SHA1 hash composed from
credentials, driver name and provider string, so different clients
will
not override their properties.
This is something I've been wondering about, should these properties be
stored per user or per resource?
I mean, if I modify an attribute of a machine, which is stored in the
persistence layer as the driver doesn't support this modification
operation, and my colleague who has his own username but sharing my
account lists the machine's attributes, would he see the original
attribute or the modified one?
I would have preferred the latter but having the credentials in the uuid
sounds like you're thinking to do the former?
Good catch! Yes, if you're sharing your resources with colleague that
use different credentials, he will not see the description you stored in
persistence layer (because UUID currently include the creator
username/password) and property will not be matched.
I was thinking if storing attributes per resource will cause problems
for other clouds but it seems not since the resource IDs are mostly unique.
So I'm all for storing attributes per resource. The UUID will still be
there but it will not use account credentials as part of the hash (so it
will be just 'driver:provider'). Or I can drop the hash completely and
just store driver and provider.
What others think? Is this right approach or I miss something? :-)
-- Michal
Regards,
Dies Koper
-----Original Message-----
From: Michal Fojtik [mailto:[email protected]]
Sent: Tuesday, 13 November 2012 10:54 PM
To: [email protected]
Subject: POC: DataMapper support for CIMI attributes
Hi,
I was playing a bit with adding DataMapper to Deltacloud to support
storing certain CIMI attributes that cannot be stored on the provider
side (like 'description', etc.). We were discussing earlier that for
that attributes we will need to create some persistent storage on
Deltacloud side. So I put together a small PoC of how complex (or not
complex) this will be:
So let say you want to create a new Machine. Currently if you specify
'description' in JSON body, we ignore this property because there is
now
way how to store it on the backend side (using the driver method).
So you have this JSON:
~/code/core/server > cat machine.json
{
"resourceURI": "http://schemas.dmtf.org/cimi/1/MachineCreate";,
"name": "myMachine1",
"description": "My very first machine",
"machineTemplate": {
"machineConfig": { "href":
"http://localhost:3001/cimi/machine_configurations/m1-small"; },
"machineImage": { "href":
"http://localhost:3001/cimi/machine_images/img1"; }
}
}
And you create Machine using this curl command:
curl -v --user "mockuser:mockpassword" -X POST \
http://localhost:3001/cimi/machines \
-H "Content-Type: application/json" -d @machine.json
With the patch I attached, you will see something like this in
Deltacloud API log:
<snip>
~ (0.000047) SELECT "id", "name", "uuid", "entity" FROM
"deltacloud_database_entity_properties" WHERE ("uuid" =
'f6d93dfa8eaca129d7412a8d58980a5948361ae8' AND "entity" =
'Instance:inst7' AND "name" = 'description') ORDER BY "id" LIMIT 1
~ (0.017038) INSERT INTO "deltacloud_database_entity_properties"
("name", "uuid", "entity") VALUES ('description',
'f6d93dfa8eaca129d7412a8d58980a5948361ae8', 'Instance:inst7')
~ (0.014218) UPDATE "deltacloud_database_entity_properties" SET
"value" = 'My very first machine' WHERE "id" = 4
~ (0.000104) SELECT "id", "name", "uuid", "entity" FROM
"deltacloud_database_entity_properties" WHERE ("uuid" =
'f6d93dfa8eaca129d7412a8d58980a5948361ae8' AND "entity" =
'Instance:inst7' AND "name" = 'description') ORDER BY "id" LIMIT 1
~ (0.000045) SELECT "id", "value" FROM
"deltacloud_database_entity_properties" WHERE "id" = 4 ORDER BY "id"
127.0.0.1 - - [13/Nov/2012 12:45:03] "POST /cimi/machines HTTP/1.1"
201
862 0.2704
</snip>
As you can see DataMapper will store the 'description' property for
the
'Instance' model with id 'inst7' (the newly created instance).
The horrible looking 'uuid' field is SHA1 hash composed from
credentials, driver name and provider string, so different clients
will
not override their properties.
Once this property is stored, I used the 'get_property_value' method,
that require just instance of the Deltacloud model and property name
to
get the property value.
Let me know what you think and if we want to go this way or we need
something more complex.
The patch is also uploaded in Tracker:
http://tracker.deltacloud.org/set/123
-- Michal
--
Michal Fojtik <[email protected]>
Deltacloud API, CloudForms
--
Michal Fojtik <[email protected]>
Deltacloud API, CloudForms
