[occi-wg] New revision of the spec

[Csom Gyula]

Hi!

Some quick notes and questions from the user perspective. I hope it helps in some way:)

Core:

[1] Action - Http mapping: Which Http method does actions map to? POST?

[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)

[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?

[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?

[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.

[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.
 

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).

[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...

[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).

[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).

[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).

[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...

[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.

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