[occi-wg] Edgy Resource Attributes during Creation

[Gary Mazz]

Inline...

On 4/12/2011 9:51 AM, alexander.papaspyrou at tu-dortmund.de wrote:
> Hey Gary,
>
> Am 12.04.2011 um 07:48 schrieb Gary Mazz:
>
>> Each consumer defined attribute (mandatory, optional or custom) needs 2
>> states, initialized and uninitialized. Undefined mandatory attributes
>> are automatically defined by the occi server for the consumer.  Which
>> means, the occi server always reports back all Resource attributes...
>>
>> Attributes not initialized by the consumer, including the auto-gen'd,
>> should remain uninitialized at the provider until deployment. At
>> deployment, a temporary default value is set. For example, a compute
>> memory attribute may be left uninitialized by the consumer. When the
> Why would that value be "temporary"? IIRC, "deployment" for you is hitting the start button. But then, the value isn't really temporary anymore. The other way around, the value would be server-side set on (protocol-wise) creation (of the OCCI resource), but then it wouldn't be uninitialized anymore...
>
> Sorry for nitpicking :-/
Depending on agreement, every attribute value may be temporary. Leaving 
the values uninitialized in the definition/provisioning allows the occi 
definition to specify "give me the default value on each deployment". 
When running (deployed) a real value can be in there, the value is set 
from systems out of occi's scope.

>> consumer hits the "start" the attribute is set by the provider with a
>> default value. When the compute Resource is "stopped" the attribute
>> value returns to the uninitialized state.
> Not sure whether this should be uninitialized until "start" by definition. Isn't that something that should be left to the provider?
This was just and example to illustrate the use case... Yes, but 
interoperability for one provider is not interoperability...
>> Obviously this will impact SLAs, but that another issue.
> True enough. That's why I was suggesting to leave this to the provider. Then, he would have the ability to set the autogenerated values to something covered by an SLA template he is offering anyway.
>
> Best,
> Alexander
>
>> On 4/12/2011 6:24 AM, Gary Mazz wrote:
>>> Hi Ralf,
>>>
>>> That should be clearly  communicated in the specs as well.
>>>
>>> BTW, Trying to go though these specs pretending there is no intrinsic
>>> knowledge is much harder than it looks.. I how it pays off with more
>>> consistent implementations
>>>
>>> -g
>>>
>>> On 4/12/2011 12:17 AM, Ralf Nyren wrote:
>>>> It depends on the multiplicity of the attributes (see e.g. OCCI
>>>> Infrastructure).
>>>>
>>>> If an attribute is mutable and has a multiplicity greater than zero the
>>>> client is supposed to supply it. If the client doesn't the OCCI server
>>>> should return a Bad Request.
>>>>
>>>> On the other hand if the multiplicity is 0..x it is considered optional
>>>> and it is up to the OCCI server to provide a sensible default.
>>>>
>>>> /Ralf
>>>>
>>>> On Mon, 11 Apr 2011 22:56:53 -0600, Gary Mazz<garymazzaferro at gmail.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> One more edge..
>>>>>
>>>>> During resource creation, resource attributes are included with the
>>>>> request.  OCCI defined resources have defined attributes.
>>>>>
>>>>> The question is what does the occi server do when insufficient
>>>>> attributes are defined in the create request ? Does the create fail ?
>>>>> Does the server populate the Resource with default values ? or does the
>>>>> create complete missing some attributes.
>>>>>
>>>>> cheers
>>>>> gary
>>>>> _______________________________________________
>>>>> occi-wg mailing list
>>>>> occi-wg at ogf.org
>>>>> http://www.ogf.org/mailman/listinfo/occi-wg
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>