Hi Michal, > We can basically store any attribute or models in DC for those providers > that does not support that attributes or models. We definitely can use this
I just thought of a more complex use-case. Fgcp supports changing the name of an instance, but doesn't supporting changing its description. (Actually, it doesn't have a description attribute at all). So I think the data mapper solution (or any state persistence solution) needs to support cases where not per operation (i.e. machine attribute modification) but per attribute the state can be stored in the DC server if the provider doesn't support it. I'm not sure I described well what I mean. Do you understand what I'm getting at? Regards, Dies Koper > -----Original Message----- > From: Michal Fojtik [mailto:[email protected]] > Sent: Friday, 16 November 2012 12:08 AM > To: [email protected] > Subject: Re: DataMapper support for CIMI attributes > > > On Nov 15, 2012, at 3:02 AM, "Koper, Dies" <[email protected]> wrote: > > > 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? > > I don't think it will be complex. I tried to create a set of helpers > that should make this support clean and not require too much work to be > done in models. Also in future, once cloud providers will support > updating properties like 'description' we can easily get rid of that. > > > And what operations can DC support with this approach? Machine > > templates? Machine attribute modification? > > We can basically store any attribute or models in DC for those providers > that does not support that attributes or models. We definitely can use this > to store attributes like 'description' or 'name' for Machine (and perhaps for > other models as well). I'm not sure how we will proceed for whole models. > We can eventually store them in database OR we can just not support them if > the > backend cloud does not support them. If I understood CIMI correctly you don't > need to support *all* CEP entities. > > Btw. I fixed the patch to get rid of storing credentials, so the stored property > is now identified by entity 'id', driver and provider. > > http://tracker.deltacloud.org/set/130 > > > -- Michal > > > > > > 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 > > > > > > Michal Fojtik > http://deltacloud.org > [email protected] > > >
