Re: [sop] SOP Requirements

Jamal Hadi Salim <> Wed, 29 February 2012 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CEE021F8608 for <>; Wed, 29 Feb 2012 09:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.513
X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8NvaYrLblrVp for <>; Wed, 29 Feb 2012 09:09:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9CC1621F855D for <>; Wed, 29 Feb 2012 09:09:38 -0800 (PST)
Received: by ggmi1 with SMTP id i1so301284ggm.31 for <>; Wed, 29 Feb 2012 09:09:38 -0800 (PST)
Received-SPF: pass ( domain of designates as permitted sender) client-ip=;
Authentication-Results:; spf=pass ( domain of designates as permitted sender)
Received: from ([]) by with SMTP id q6mr473298oeh.56.1330535378253 (num_hops = 1); Wed, 29 Feb 2012 09:09:38 -0800 (PST)
Received: by with SMTP id q6mr403072oeh.56.1330535378135; Wed, 29 Feb 2012 09:09:38 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 29 Feb 2012 09:09:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Jamal Hadi Salim <>
Date: Wed, 29 Feb 2012 12:09:17 -0500
Message-ID: <>
To: "Ashish Dalela (adalela)" <>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQl/M2dtAK94AgP1wQzMdLZ0GJTJP/IHzzyulYZ9ILHAG92EImuw/t6aUkmgaxLoDW0hocOK
Cc: Vishwas Manral <>,, Michael Hammer <>
Subject: Re: [sop] SOP Requirements
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Service Orchestration and Desciption for Cloud Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Feb 2012 17:09:39 -0000

Hi Ashish,

On Wed, Feb 29, 2012 at 11:44 AM, Ashish Dalela (adalela)
<> wrote:

> I understand the ForCES background - the idea is aligned with ATCA and
> the notion that any node can be given any "personality". That may not be
> true in general where certain types of devices are "capable" of doing
> certain things. E.g. you can't trivially make a switch a firewall or a
> load-balancer. You certainly can't make a network device a storage
> device or a server trivially. It is true for x86 servers maybe, but as
> you get a wide variety of hardware capabilities or move up the software
> stack into a middleware or a specific type of application, the
> generalized view disappears. Until we get to a point where a common type
> of hardware can enact any type of functionality that view is limited.

I dont need to know a node's "personality" - if it exists, it tells me.
The creation or booting of the node is considered a setup process.
[Once create/booted - the node becomes part of my resource pool.
I may not use it at all if i choose not to.]
In your case, you may consider the creation aspect part of the

> The reality with virtualized services is that the instance doesn't
> *exist* when you ask for it. E.g. when I request a VM, the VM that I
> will be allocated doesn't exist. It will be created on-demand. So, there
> is no way I can request the specific "instance". I have to only request
> a "type". The type has to be mapped to a capability source, and then
> converted into an instance. Once you have an instance, sure, you refer
> to it both by type and instance.

Then no conflict there.
I presume theres an operation to say "create abc.vm" which
returns me some ID. And going forward i can refer to that
abc.vm.someID and be able to reference attribute, no?

> Sure, that can be clarified. I thought the definition was clear in the
> drafts, but if not, that can be clarified.

I will read the drafts closely and comment. Is the requirements one the best
one to focus one (that is the one i have looked at).