Re: [sop] SOP Requirements

[Jamal Hadi Salim <[e-mail]>]

Hi Ashish,

On Tue, Feb 28, 2012 at 9:08 PM, Ashish Dalela (adalela)
<[e-mail]> wrote:
> Hi Jamal,
>
> We will look at ForCES again since you have mentioned similarities.

If you want to take a shortcut and get quick answers, feel free
to email me or post on the ForCES list.

> Each device advertizes its capabilities - which means advertizes a set
> of "service names". In this case, the "service name" can be
> iaas.compute.virtual.ovf, which can stand for OVF capable servers.
> Another server can advertize a "service name" iaas.compute.virtual.xyz,
> which can stand for XYZ standard for VMs. When a request for VM arrives,
> it carries the "service name" aside from the service parameters. The
> orchestrator maps the target device to the request based on this service
> name, and a whole bunch of other policies (location, bandwidth,
> security, ...).
>
> Ideally, we should not have competing standards for the same service
> name - e.g. virtual machines, but if there are, then this is how you
> would do it.

Yes, makes sense.
[One thing thats not clear is how discovery of this services happens.
In the ForCES
approach, these services would be akin to LFBs. The node that is providing these
LFBs (analogous to an FE if you are trying to do an NE) would connect
to the controller
(aka CE) and tell it what it can support and what capacities of each service
(aka LFB) it can handle etc.]

> The goal is not to translate between OVF and XYZ, because that is so
> buggy and brittle (precisely the problem with mapping APIs). We map OVF
> requests to OVF capable servers and XYZ to XYZ capable servers. SOP
> Proxy acts to do the routing and policy application of requests to
> targets.

When you use the term "proxy" i see "Translation" or at least the orchestrator
being intelligent enough to take  iaas.compute.virtual.ovf.instance1.foo
and understand it to be the same thing as  iaas.compute.virtual.xyz.bar
I think thats not what you want to achieve, correct? You want the request
to be explicit for  iaas.compute.virtual.ovf.instance1.foo for an OVF
knowledgeable app and  iaas.compute.virtual.xyz.bar for XYZ standard
app?

> The "service names" are hierarchical, which means that the child domain
> inherits properties of the parent domain (like objects). That allows you
> to incrementally extend domains by adding new attributes or features. A
> device, may, for example, advertize
> iaas.compute.virtual.ovf.proprietary-extensions, and a user can request
> a VM based on OVF and/or proprietary-extensions.

ok

> This allows, a provider to support a new type of service with "value
> additions", while remaining compatible with standard. No protocol
> changes or changes to infrastructure / software are needed to achieve
> these things.

Yes on the "no protocol changes or infrastructure/software". This is where
OF fails miserably.
While we are trying to standardize, what you are talking about is reality.
Unfortunately, it reduces the standardized interface to be the lowest common
denominator.

> The Proxy may be configured with defaults for this service, or
> configured to reject requests that don't conform to what the provider
> wants to support or with rules on how a proprietary / standard service
> interacts with other services. So, the Proxy becomes an important point
> at which to enforce variety of controls. The Proxy can be at customer
> and provider and service boundaries. So, there are many points where
> different rules can be applied.

Sure.

> Hope I answered you question.

it does with a small caveat above.

cheers,
jamal