Hi Michal, > >> Deltacloud side. So I put together a small PoC of how complex (or not > >> complex) this will be:
So, how complex (or not) do you feel it would be? And what operations can DC support with this approach? Machine templates? Machine attribute modification? Regards, Dies Koper > -----Original Message----- > From: Michal Fojtik [mailto:[email protected]] > Sent: Tuesday, 13 November 2012 11:37 PM > To: [email protected] > Subject: Re: DataMapper support for CIMI attributes > > 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
