Translating foreign resources
Hi, An issue came up of translating foreign resources between providers.. There are two (3) use cases: 1) we have a provider that has a unique network, defined as a IPNetworkingMixin. Another provider doesn't support that Resource.. 2) We have 2 providers, each provider has a unique network, defined as a IPNetworkingMixin. The operation of the networks is different between providers, their name spaces overlap. 3) We have a provider and they would like to transcribe the IPNetworkingMixin, but the resource class is know to be in an overlapping name space. We have 4 questions: Q1) How do we identify the name space of the originating Mixin A1) The name space is provided by the scheme associated with the resource Q2) There is not enough information in the scheme to translate the resource.. A2) No clear practice Q3) If we translate another providers Mixin, what do we export, the original mixin definition, our translated mapping or both ? A3) No clear practice Q4) If we export both our resource and the original mixin, how do we link them together? A4) No clear pratice Suggestions: Q2: We need some hints? Maybe a pointer to a super class ie derived class "IPNetworkingMixin", super class "Neworking". Looking for some suggestions cheers, gary
Not sure if I understood the issue correctly but I may be able to shed some light on the contract implied by a Mixin. The IPNetworkInterface mixin, defined in the http://schemas.ogf.org/occi/infrastructure/networkinterface# scheme, only guarantees that a resource instance associated with it will support a certain set of attributes. In this case occi.networkinterface.address, occi.networkinterface.gateway and occi.networkinterface.allocation. Infra also says it should be a L3/L4 network but other than that there is not much else in the contract. The only thing OCCI can guarantee when translating resources between providers is the availability of the attributes defined by the associated Kind and Mixins. /Ralf On Thu, 07 Apr 2011 16:51:05 -0600, Gary Mazz <garymazzaferro@gmail.com> wrote:
Hi,
An issue came up of translating foreign resources between providers.. There are two (3) use cases:
1) we have a provider that has a unique network, defined as a IPNetworkingMixin. Another provider doesn't support that Resource..
2) We have 2 providers, each provider has a unique network, defined as a
IPNetworkingMixin. The operation of the networks is different between providers, their name spaces overlap.
3) We have a provider and they would like to transcribe the IPNetworkingMixin, but the resource class is know to be in an overlapping name space.
We have 4 questions:
Q1) How do we identify the name space of the originating Mixin A1) The name space is provided by the scheme associated with the resource
Q2) There is not enough information in the scheme to translate the resource.. A2) No clear practice
Q3) If we translate another providers Mixin, what do we export, the original mixin definition, our translated mapping or both ? A3) No clear practice
Q4) If we export both our resource and the original mixin, how do we link them together? A4) No clear pratice
Suggestions:
Q2: We need some hints? Maybe a pointer to a super class ie derived class "IPNetworkingMixin", super class "Neworking".
Looking for some suggestions
cheers, gary
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi Ralf, Great, this is the first steps in in developing a best practice. Your recommendation also brings up the need to a set of attributes where everyone understands the semantics cheers, gary On 4/8/2011 12:16 PM, Ralf Nyren wrote:
Not sure if I understood the issue correctly but I may be able to shed some light on the contract implied by a Mixin.
The IPNetworkInterface mixin, defined in the http://schemas.ogf.org/occi/infrastructure/networkinterface# scheme, only guarantees that a resource instance associated with it will support a certain set of attributes. In this case occi.networkinterface.address, occi.networkinterface.gateway and occi.networkinterface.allocation. Infra also says it should be a L3/L4 network but other than that there is not much else in the contract.
The only thing OCCI can guarantee when translating resources between providers is the availability of the attributes defined by the associated Kind and Mixins.
/Ralf
On Thu, 07 Apr 2011 16:51:05 -0600, Gary Mazz<garymazzaferro@gmail.com> wrote:
Hi,
An issue came up of translating foreign resources between providers.. There are two (3) use cases:
1) we have a provider that has a unique network, defined as a IPNetworkingMixin. Another provider doesn't support that Resource..
2) We have 2 providers, each provider has a unique network, defined as a IPNetworkingMixin. The operation of the networks is different between providers, their name spaces overlap.
3) We have a provider and they would like to transcribe the IPNetworkingMixin, but the resource class is know to be in an overlapping name space.
We have 4 questions:
Q1) How do we identify the name space of the originating Mixin A1) The name space is provided by the scheme associated with the resource Q2) There is not enough information in the scheme to translate the resource.. A2) No clear practice
Q3) If we translate another providers Mixin, what do we export, the original mixin definition, our translated mapping or both ? A3) No clear practice
Q4) If we export both our resource and the original mixin, how do we link them together? A4) No clear pratice
Suggestions:
Q2: We need some hints? Maybe a pointer to a super class ie derived class "IPNetworkingMixin", super class "Neworking".
Looking for some suggestions
cheers, gary
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (2)
-
Gary Mazz -
Ralf Nyren