Re: [sop] SOP Requirements
Michael Hammer <mphmmr@gmail.com> Thu, 01 March 2012 18:24 UTC
Return-Path: <mphmmr@gmail.com>
X-Original-To: sop@ietfa.amsl.com
Delivered-To: sop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DFA21E813B for <sop@ietfa.amsl.com>; Thu, 1 Mar 2012 10:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.469
X-Spam-Level:
X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ejreUnugLoR for <sop@ietfa.amsl.com>; Thu, 1 Mar 2012 10:24:38 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0C1D21E8156 for <sop@ietf.org>; Thu, 1 Mar 2012 10:24:37 -0800 (PST)
Received: by lagj5 with SMTP id j5so1288465lag.31 for <sop@ietf.org>; Thu, 01 Mar 2012 10:24:36 -0800 (PST)
Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.40.72 as permitted sender) client-ip=10.112.40.72;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.40.72 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com
Received: from mr.google.com ([10.112.40.72]) by 10.112.40.72 with SMTP id v8mr2889220lbk.49.1330626276944 (num_hops = 1); Thu, 01 Mar 2012 10:24:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4lNUUm5QdrIU8mtbyyB55S78EkUGXDBdk5KBiMED+RE=; b=K3WBp8LwqyD8uGdETop1GYPL/rWqXT9L3DgymjO9kqyUzdW2Xcwsl8VM2KOQDs4sih 1XnKzq+MfCd3rIBvLyVFInjX5jkBBAQr2xbBYb5sGQKDoXHk/YN6ceaRufNhCvLtRUyY 2ivmfw9ohZdF0JEuvpDu0jT5XpKMH4UauA+WE=
MIME-Version: 1.0
Received: by 10.112.40.72 with SMTP id v8mr2371930lbk.49.1330626276815; Thu, 01 Mar 2012 10:24:36 -0800 (PST)
Received: by 10.112.104.70 with HTTP; Thu, 1 Mar 2012 10:24:36 -0800 (PST)
In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC6F5@XMB-BGL-416.cisco.com>
References: <CAOyVPHQ-iESaD2osxsWguTw1Ru92JYacSsqbD+1rECPzy1eGfQ@mail.gmail.com> <CAA3wLqV+YeGJH2pFQ80s=PgQC2RsodPMm8qUw3a-VtCzhETkOg@mail.gmail.com> <CAOyVPHTXWPyt5aHL2ehd_upS-DEAcfugVMcUpUm_oO5Ov04rUw@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <CAAFAkD-pheMmSQoUZzup_DHQceyXU=1Aq+oQZWEMXA_5pTNayg@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> <CAAFAkD94ODszZ4D=m0Kyco8CEfE0rs9aLGj36-A7Re2MMQGiZg@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com> <CAAFAkD-yjzhVppSyC058y=TAmOQVoaBmAh6Gr_y0ymrvFr_ydQ@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC382@XMB-BGL-416.cisco.com> <CAAFAkD_8nKOnRf+BhRWiAmxkGByjZDBP6cU2i5ZhnpPA-OGt0Q@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC3B4@XMB-BGL-416.cisco.com> <CAAFAkD8g497EArRo7CWMyAkxRNM4ArMJh_Ru-oYDC4+dqaLRRQ@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC6F5@XMB-BGL-416.cisco.com>
Date: Thu, 01 Mar 2012 13:24:36 -0500
Message-ID: <CAA3wLqW0rNm2pQN=xSaY4G1-0M+t4wW203sjq8takUusR80Ufw@mail.gmail.com>
From: Michael Hammer <mphmmr@gmail.com>
To: "Ashish Dalela (adalela)" <adalela@cisco.com>
Content-Type: multipart/alternative; boundary="e0cb4efe2d588ef52604ba329216"
Cc: Vishwas Manral <vishwas.ietf@gmail.com>, sop@ietf.org, Jamal Hadi Salim <hadi@mojatatu.com>
Subject: Re: [sop] SOP Requirements
X-BeenThere: sop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Service Orchestration and Desciption for Cloud Services <sop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sop>, <mailto:sop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sop>
List-Post: <mailto:sop@ietf.org>
List-Help: <mailto:sop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sop>, <mailto:sop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2012 18:24:39 -0000
We also need to maintain independence between cloud customer and cloud service provider naming conventions. Those can be linked and de-referenced through name server registries operated by the appropriate entities. Mike On Thu, Mar 1, 2012 at 1:08 PM, Ashish Dalela (adalela) <adalela@cisco.com>wrote: > Hi Jamal, > > >> 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 > >> abc.vm.someID.foo, no? > > 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. > > 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: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of > Jamal Hadi Salim > Sent: Wednesday, February 29, 2012 10:39 PM > To: Ashish Dalela (adalela) > Cc: Vishwas Manral; sop@ietf.org; Michael Hammer > Subject: Re: [sop] SOP Requirements > > Hi Ashish, > > On Wed, Feb 29, 2012 at 11:44 AM, Ashish Dalela (adalela) > <adalela@cisco.com> 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 > abc.vm.someID.foo, 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 > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop >
- [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Michael Hammer
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Michael Hammer
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Michael Hammer
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Michael Hammer
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Vishwas Manral