[occi-wg] Query uniqueness

[Gary Mazz]

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 <http://andy.edmonds.be>
>
>
> On Mon, Apr 11, 2011 at 17:30, Gary Mazz <garymazzaferro at gmail.com 
> <mailto:garymazzaferro at 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 at merzky.net <mailto:andre at 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 at ogf.org <mailto:occi-wg at ogf.org>
>     http://www.ogf.org/mailman/listinfo/occi-wg
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20110411/a94033cf/attachment-0001.html