Hi,

This started as a discussion on the application of the location attribute for resources categories and mixins.. And, which policies should be implemented where. How the location named spaces are applied is somewhat unclear to a casual reader. Which leads to poor location naming practices.  There is an addition issue of which naming practices should be restricted at the provider by  enforcement technology. Obviously, this impacts the provider's occi implementations.

The issue of a registry was brought up by Andre, I was assuming he was considering a centralized registry for mixins to prevent location named space aliasing.. But reconciliation can easily be handled at the provider. Providers simply rejecting named space collision and foreign mixins do little for interoperability and is currently out of scope. However, it does not mean we cannot suggest best practices to address issues not in scope of the specification.   

BTW, did you get to see what kind of bird that was ? a magpie?

-g

On 4/11/2011 11:06 AM, Andy Edmonds wrote:
From my POV, there shouldn't be any doubts about what must, should or could be implemented. The specs respect RFC2119.

In regards to interoperability, it is for this aspect why we have the query interface. Here's an example that might highlight it's use.

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.

.2c

Andy
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