From my POV, there shouldn't be any doubts about what must, should or could be implemented. The specs respect RFC2119.

We have provider A, provider B and C. Customer X has a deployment on provider A but because provider A insulted X's mother, X is leaving that provider! He's scripted a fancy client that does the following to ensure his insult-driven migration can take place:

1. get a list of all known providers [A, B, C]

2. iterate through each provider's query interface comparing available features to required features - only C in this case. We can think of this as ensuring the current "SLA" offered by A.

3. C is found to have all required features (virtual hardware, OSes), including mandatory OCCI features.

4. Given that X's architecture is one based on non-persistent application VMs, X's client can now provision the required resources with C, execute their deployment scripts and then use other facilitates to move redirect data location (e.g. CDMI). Incidentally it is not the reprovisioning of resources that's the challenge but rather the relocation of application data.

5. X is now free to repoint DNS records to the new services and tear down the old services on provider A while simultaneously giving A the bird :p

What OCCI guarantees here is a basic service "quality", where that quality is a set of features and functions (IaaS ones are defined in the IaaS spec). Anything outside of that document is of course vendor specific however the more useful and demand-of such a specificity the more it will become common place, at which time would indicate to this group (us) the warrantying of its standardisation.

The scenario is basic, however this type of scenario will be further investigated not only here within OCCI but also in the forming DCI-Fed/IaaSICP OGF group.

andy.edmonds.be

On Mon, Apr 11, 2011 at 17:30, Gary Mazz <garymazzaferro@gmail.com> wrote:

Ralf,

Leaving architectural components as simply "not implemented" may be
considered 'inoperable' and defeats the purpose of interoperability, at
least in some circles. :)

A provider may implement a protected feature making their occi mixin
unique to their infrastructure enforcing vendor lock-in. Its probably
not desirable to go down that path. We need to address that issue
sometime soon.

cheers
gary

On 4/11/2011 9:59 AM, Ralf Nyren wrote:
> On Mon, 11 Apr 2011 18:51:04 +0300, Andre Merzky<andre@merzky.net> wrote:
>
>>> This means that with user-defined Mixins an OCCI service must refuse to
>>> create a Mixin for which the specified location path already is taken.
>> which basically means that you need a registry of valid mixins?
> You need a registry of all Mixins visible to a particular user, yes. Not
> sure if that is what you meant.
>
> A simple registry could be a hash-map with "location" as the key and the
> Mixin object as value. When a user attempts to add a Mixin check the
> hash-map, if location is already there, return a Bad Request.
>
> Which Mixins are valid or not in terms of scheme + term is up to the
> provider to decide (afaik).
>
> /Ralf
>
>
>

_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg