[occi-wg] New revision of the spec

Gary Mazz garymazzaferro at gmail.com
Fri Aug 6 11:46:36 CDT 2010 

Hi,

Sorry for not replying.. I was taking a few days holiday.. I'll respond 
later today :)

gary

Thijs Metsch wrote:
> Again - see inline :-)
>
> On Thu, 2010-08-05 at 09:26 +0000, Csom Gyula wrote:
>   
>> Hi, 
>> thanks for your feedback! Comments for the open items only:)
>>
>>
>> [5] Id assignment: URI or id? Any:) I've got used to ids but URI might better fit the ws client 
>> space. Also the id is usually reflected within the URI.
>>
>> The general idea is that the identifier (either the internal id or the URI) is determined before 
>> the creation request is issued. So the sequence would be the following:
>>
>> 1. The client asks a new id/URI (for a resource type) and the server gives back the next free 
>>     one.
>> 2. The client assembles the id/URI into the request and issues it (if using URIs the assembling
>>     migth be nothing but using the URI to post the request to). The server checks whether 
>>     the id is free-and-unique or not, if yes it creates the new resource.
>>
>> In this scenario the worst thing that could happen is that an id/URI is requested but never
>> used - which is not an issue compared to the other case when the client creates the 
>> resource but cannot retrieve the id due to some problem (connection lost or kinda). 
>>
>> Similar could be applied when using (unique) names. Though in this case it is the client 
>> responsibility to determine the unique name, and the server has only 2 roles: validate the 
>> unicity and respond to resource reuqests given by name.
>>
>> A real life example: OpenNebula when deploying machines to the virtualization layer generates 
>> a so called deployment id (one-[VMID]) then assigns it to the Libvirt domain as the domain's 
>> name. The domain id itself is generated by Libvirt internally. We'll apply the same technique
>> to keep in synch our internal registry with the ONE's db.
>>     
>
> Well right now doing a POST on / will create /<some id> and a POST
> on /foo/ will create a /foo/<some id> if 'foo' exists. If you do a PUT
> on an non existing resource it will try to create it - otherwise update
> it. So a PUT on /foo/bar will create the resource /foo/bar...
>
> Maybe this helps?!
>
>   
>> [7] Graphics: I agree with Gary, console is a must:) His spec is definitve... here let me add just
>> some notes:
>> * We are using KVM/QEMU as the hypervisor so I can confirm that KVM/QEMU provides graphical 
>>   terminal support, namely VNC:)
>> * Security is an issue at least in two ways. First the terminal gives access to the running 
>>   compute resource hence it needs password protection or such. Second the terminal
>>   access operates on the host level not on the vm level. That is the terminal address would
>>   be the IP of the physical host the vm is running on. Generally it is not a secure thing
>>   to give direct access to interna hostl infrastructure. For instance in our solution (currently in 
>>   development) we use a VNC proxy that hides the internal locations.
>> * Isn't occi.console.status the same as (or projection of) the socci.compute.status? It could
>>    be a useful information though. I guess it should be dinamically queried from the corresponding
>>    compute resource.
>> * Either the console should be the part of the compute resource or it should link to the compute 
>>   resource it belongs to, that is:
>>   * either console should be moved under the compute namespace (ie. occi.compute.console.xxx)
>>   * or there must be a bidirectional link between the two (occi.console.compute_link -> compute
>>     and occi.compute.console_link -> console or such)
>>     
>
> Some good notes @Gary can you respond?
> How do you feel about the subject if those attributes are mandatory or
> optional?
>
>   
>> [8] Compute transitional states: Regarding long running jobs... I've got the point:) Just one
>> more question. Can someone query active jobs related to a particalur resource? Ie. is job linkage 
>> supported from the resources? Again its about robustness... w/o the query feature or kinda if the 
>> connection is lost during the transaction the client might miss a running job...
>>     
>
> That is not described yet...
>
>   
>> [9] Compute end state: yep, I can paint images:) Which UML tool do you use/prefer?:)
>>     
>
> I dunno - @Andy can you tell?
>
>
>   
>> [10, 11] Network related stuff: yep I can pick it up:)
>>     
>
> Perfect Thanks!
>
>   
>> [13] Golden images: Ok I see the point:) just let me add one note. Support through linkage means 
>> that you support 'clone before' operations only. In theory there could be (at least) 2 scenarios for 
>> golden image usage:
>>
>> 1. Clone before: Clone the golden image, retrieve its id then use it in the (new or updated)
>>    compute resource. That is cloning and compute creation/update happens in 2 transactions.
>> 2. Clone just-in-time: Give the golden image link, mark it with "clone=yes" and issue your 
>>     compute create or update request. That is cloning and compute creation/update happens 
>>     in 1 transaction.
>>
>> Strictly speaking the 2nd feature is not mandatory though it might increase usability (ie. 
>> "one click deployment"). 
>>     
>
> Anybody else got some thoughts on this?
>
> Cheers,
>
> -Thijs
>
>   
>> Cheers,
>> Gyula
>> ________________________________________
>> Feladó: Thijs Metsch [tmetsch at platform.com]
>> Küldve: 2010. augusztus 5. 10:16
>> Címzett: Csom Gyula
>> Másolatot kap: occi-wg at ogf.org
>> Tárgy: RE: [occi-wg] New revision of the spec
>>
>> Hi,
>>
>> Thank you for your replies - I'll try to comment inline :-) If you see
>> any changes needed - do not hesitate to edit them in the Wiki as well!
>>
>>     
>>> Core:
>>>
>>> [1] Action - Http mapping: Which Http method does actions map to? POST?
>>>       
>> yes
>>
>>     
>>> [2] Return values: Return values could be specified both for CRUD and resource-specific
>>> actions. For instance when creating new resources the generated id should be returned as
>>> a minimum (see also id assignment below)
>>>       
>> Currently it should either return a 200 OK with Location or a 202 with
>> Location to another intermediate resource for a long running job.
>>
>>     
>>> [3] Creating subresources: it could be clarified whether subresources can be created
>>> along with the parent resource or not? What is right creation seuqence:
>>>
>>> 1. Create a compute w/o network and storage then add network and storage
>>> 2. Create a compute with network and storage in 1 transaction then maybe adding more
>>>     resources later...
>>>
>>> Which scenario is valid? Which should be supported by an OCCI-complient solution?
>>>       
>> Probably something we need to be more clear on in the Infrastructure
>> part.
>>
>>     
>>> [4] Adding subresources: Do you plan to support adding subresources? For instance
>>> attaching an existing storage to a compute? If yes where does it fit within the spec? Is it a
>>> resource UPDATE procedure by providing a link to an existing resource?
>>>       
>> It would be a PUT with an Link on an existing resource...needs to be
>> more clear I guess :-)
>>
>>     
>>> [5] Id assignment: Generally speaking server assigned ids doesn't provide a robust solution.
>>> What if the client lost the connection? It can lead to zombie resources... Think of system
>>> integration and cloud management automation... Either unique names or sequences (like
>>> in RDBMS) could be supported.
>>>       
>> What is an id in this question? An internal ID used by the Backend
>> system or a URI?
>>
>>     
>>> [6] 'Attributes in creation': the specification deals with attribute mutability however it doesn't
>>> clarify attribute 'creatibility'. That is what attributes can be filled by the client and what can be
>>> filled by the server when creating resources? What can be null? What is always assigned
>>> either dynamically or manually? Generally it would be nice to document how attributes behaves
>>> when creating a new resource: can be null | must be manually filled | dynamically assigned |
>>> manual or dynamic etc.
>>>       
>> Might be an idea - for now mutability means: can be set by the user -
>> all described attributes are mandatory (if not stated otherwise)
>>
>>     
>>> Infrastructure:
>>>
>>> [7] Graphics: It is a basic service within clouds to provide OS-independent monitor that is terminal
>>> access to vms independent from the OS running in the virtual machine. VNC is a typical solution.
>>> It would be nice to support this within compute (eg. graphics type, ip, port, password, and keymap).
>>>       
>> What do you think of the solution Gary proposed on the list?
>>
>>     
>>> [8] Compute transitional states: It might be useful to introduce substates for transitions. For instance
>>> virtual machine deployment typically takes some time while the resource is either pending (not yet
>>> scheduled) or being deployed. Typically a user or agent would be interested in such transitions...
>>>       
>> See long running jobs...
>>
>>     
>>> [9] Compute end state: Also an end state (like deleted) should be introduced that is for systems that
>>> support logical deletes (destroys the vm but maintains the record for audit purposes or kinda).
>>>       
>> Already an todo in the Wiki - can you paint new images? :-)
>>
>>     
>>> [10] Virtual network: vnets are basic services within cloud/virtualization solutions. That is the
>>> admin or user create a virtual network and the user assigns the compute's NIC to the selected
>>> virtual network.
>>>
>>> This is related to the following question: "Semantics of provisioning a compute in relation to
>>> networking is undecided". In my limited practise I've seen 2 types of provisioning:
>>>   * when the client request an explicit address
>>>   * when a client request a virtual network and it is the server who assigns the address
>>>
>>> That is in the first case IP address is filled by the client, however in the second case it is filled
>>> by the server (see also [6] above).
>>>       
>> This is a area we need to work on - can you pick this one up?
>>
>>     
>>> [11] Private vs. public IP: Also there's a difference between public and private IPs. Public IP
>>> allocation is definitely a cloud role, related to the administration domain too. However managing
>>> private IPs at the cloud level might not make sense: since vlans are separated anytime any
>>> private IP could be configured at the VM level, it is the user responsibility. So for private IPs
>>> it is usually the MAC address that must be managed by the cloud (that is unique MAC address
>>> is a generally a must).
>>>       
>> see above :-)
>>
>>     
>>> [12] Cooked storage: Do you plan to support cooked storage, that is creating a storage with
>>> a file system on it? If yes a disk type attribute might be introduced...
>>>       
>> Probably more in scope of CDMI if I understand you correctly...but not
>> sure...
>>
>>     
>>> [13] Golden images: It is a basic service within clouds to create a storage by cloning
>>> an existing image. If this is to be supported then a source attribute (link) might be introduced to
>>> the storage resource.
>>>       
>> This is generally support through links - the spec might need to be more
>> clear here...
>>
>>
>> Thanks again,
>>
>> -Thijs
>>
>>     
>>> Cheers,
>>> Gyula
>>>
>>> ________________________________________
>>> Feladó: occi-wg-bounces at ogf.org [occi-wg-bounces at ogf.org] ; meghatalmaz&#243;: Thijs Metsch [tmetsch at platform.com]
>>> Küldve: 2010. augusztus 3. 9:26
>>> Címzett: occi-wg at ogf.org
>>> Tárgy: [occi-wg] New revision of the spec
>>>
>>> Hi,
>>>
>>> I would like to point you to the newest version of the spec:
>>>
>>> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModels
>>>
>>> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/HTTPHeaderRendering
>>>
>>> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Infrastructure
>>>
>>> Some changes have happened including:
>>>
>>> * renaming Kind to Resource
>>> * Cleanup of namespace for schemes in the category and links
>>> * added some diagrams etc.
>>>
>>> This version includes a lot of rewording and should be more clear on
>>> many issues!
>>>
>>> Please review it and give us a first shot of feedback!
>>>
>>> Cheers,
>>>
>>> -Thijs
>>>
>>> --
>>> Thijs Metsch
>>> Senior Software Engineer Grid and Cloud Technology
>>> Platform Computing GmbH
>>> Europaring 60
>>> D-40878 Ratingen
>>> http://www.platform.com
>>>
>>> http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>       
>> --
>> Thijs Metsch
>> Senior Software Engineer Grid and Cloud Technology
>> Platform Computing GmbH
>> Europaring 60
>> D-40878 Ratingen
>> http://www.platform.com
>>
>> http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax
>>
>>     
>
>

More information about the occi-wg mailing list