[occi-wg] Query uniqueness

[Andy Edmonds]

>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 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>
>  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
> 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/fb084e24/attachment.html