Re: [sop] SOP Requirements

Jamal Hadi Salim <> Fri, 02 March 2012 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6459E21F85E7 for <>; Fri, 2 Mar 2012 10:22:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.431, 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 or7Gsyq4wZcV for <>; Fri, 2 Mar 2012 10:22:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9A04821F85B5 for <>; Fri, 2 Mar 2012 10:22:41 -0800 (PST)
Received: by obbeh20 with SMTP id eh20so2779134obb.31 for <>; Fri, 02 Mar 2012 10:22:41 -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 x15mr4221877obh.76.1330712561328 (num_hops = 1); Fri, 02 Mar 2012 10:22:41 -0800 (PST)
Received: by with SMTP id x15mr3649484obh.76.1330712561211; Fri, 02 Mar 2012 10:22:41 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 2 Mar 2012 10:22:21 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Jamal Hadi Salim <>
Date: Fri, 2 Mar 2012 13:22:21 -0500
Message-ID: <>
To: "Ashish Dalela (adalela)" <>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmhCVZe/jOdBpI8xlX8lnSz4f8t7q9a3syL4ba0VHoPS9zsDXyA8uBMGGi8pUOmVEkGpNcu
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: Fri, 02 Mar 2012 18:22:42 -0000

Hi Ashish,

I will read the drafts and provide better comments. I guess
the point i was missing was you put out requirements to
look for a protocol and it turns out you already have a protocol
which suits your needs.


On Thu, Mar 1, 2012 at 1:08 PM, Ashish Dalela (adalela)
<> wrote:

> Please note that the resources we create and the names we assign them
> have to be DNS accessible. That's because from a user standpoint cloud
> and non-cloud services must work just the same. Hence, you don't want to
> give a name like - abc.vm.someID. You want to give a name that will be
> resolved by a DNS server so that the user can reach that server in the
> same way, transparent to the fact that it is cloud created.

Ok - didnt realize that angle.

> To make cloud work incrementally, we need a separate name space for
> "types", and not mix it with existing names in DNS. So, we end up with
> two name spaces - one for types and another for instances. The
> properties of an instance are really properties of a "type" but
> referenced by an instance. The "type" can have a "name" attribute that
> references an instance, without loss of generality. That way, if we
> change the name, we are still consistent.
>>> Is the requirements one the best one to focus one (that is the one i
> have looked at).
> Requirements is certainly the place to start at. Many of the questions
> you have raise also touch upon architecture, and specifics are in the
> protocol draft. Look forward to your comments.
> Thanks, Ashish
> -----Original Message-----
> From: [] On Behalf Of
> Jamal Hadi Salim
> Sent: Wednesday, February 29, 2012 10:39 PM
> To: Ashish Dalela (adalela)
> Cc: Vishwas Manral;; Michael Hammer
> Subject: Re: [sop] SOP Requirements
> 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
> process.
>> 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).
> cheers,
> jamal
> _______________________________________________
> sop mailing list