[occi-wg] New revision of the spec

[Thijs Metsch]

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ó: 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