Edgy Resource Attributes during Creation
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
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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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. 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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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 :-/
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?
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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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
Inline... On 4/12/2011 9:51 AM, alexander.papaspyrou@tu-dortmund.de wrote: 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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Inline... Am 12.04.2011 um 11:09 schrieb Gary Mazz:
Inline...
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 occ.'s scope.
I guess we had a different notion of "uninitialized" in mind. From an SLA perspective, all values are "temporary" until the agreement is electronically signed. From the protocol perspective, the value is not "uninitialized" anymore from the very first moment it is set by either the client or the server.
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...
Agreed. The question is to what extent (and, more importantly, by which way) this should be specified. I would say that this is another thing to go into the "book"... -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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi, I did a little snipping... AP:I guess we had a different notion of "uninitialized" in mind. From an SLA perspective, all values are "temporary" until the agreement is electronically signed. From the protocol perspective, the value is not "uninitialized" anymore from the very first moment it is set by either the client or the server. The type and range of the value is dependent on policy influenced by a signed agreement. There can be many type of policies for determining service capabilities during deployments. During a deployment, the values reported in Resource attributes is the current instance.. and in fact may be different each time read.. Resource attributes defined in the provisioning phase is handled according to policy. Without: X-OCCI-Attribute: occi.compute.cores we have no way to request a default value. On 4/12/2011 10:28 AM, alexander.papaspyrou@tu-dortmund.de wrote:
Inline...
Am 12.04.2011 um 11:09 schrieb Gary Mazz:
Inline...
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 occ.'s scope. I guess we had a different notion of "uninitialized" in mind. From an SLA perspective, all values are "temporary" until the agreement is electronically signed. From the protocol perspective, the value is not "uninitialized" anymore from the very first moment it is set by either the client or the server.
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... Agreed. The question is to what extent (and, more importantly, by which way) this should be specified. I would say that this is another thing to go into the "book"...
-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@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@ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg
occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (4)
-
Alan Sill -
alexander.papaspyrou＠tu-dortmund.de -
Gary Mazz -
Ralf Nyren