[occi-wg] Edgy Resource Attributes during Creation now: WS-Agreement and WS-Negotiation

[Gary Mazz]

Hi Alan,

In the example below, the strategy taken with attributes affecting 
"billable" resource characteristics has a direct impact on pricing for 
services...   For example, we can have the "generous provider". If you 
have internet cable service, and your latency expectation is for 100ms 
and they deliver 15ms  because of low utilization, you still only pay 
for the 100ms latency. So the policy would be a minimum or better 
agreement instead of a nominal/minimal rate policy.   Another type of 
policy is the 'greedy consumer'. They take as much as they can get and 
are willing to pay for it.. Under this policy, each time the compute 
instantiation is started, the maximum allocation possible is delivered 
to the consumer.

Both WS-Agreement and WS-Negotiation are very relevant. I would say even 
more relevant for DCIFed than for OCCI. This is where the overall 
taxonomy will become very important, especially across level of 
interoperability. We'll need direct traceability in the taxonomies as we 
transition though layers. I think we'll only get one chance to do this, 
we'll need some careful planning to get as close to correct as possible

-gary


On 4/12/2011 6:54 AM, Alan Sill wrote:
> On Apr 12, 2011, at 7:48 AM, Gary Mazz wrote:
>
>> Now that I think about it...
>>
>> 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
>> 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.
>>
>> Obviously this will impact SLAs, but that another issue
> As regards SLAs, what do you think of a RESTful implementation of WS-Agreement and WS-Negotiation to resolve such issues?
>
> I have spoken with Wolfgang Ziegler about this, and he is interested.
>
> In general, I think it is better to handle SLA-related issues in a framework designed for it, rather than stretch OCCI where it was not designed to go.
>
> - Alan
> .
>
>> Custom Resource attributes will fall into Mixins.
>>
>> What do you think about this approach ?
>>
>> -g
>>
>> 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
>