[occi-wg] New revision of the spec

Csom Gyula csom at interface.hu
Fri Aug 27 11:04:44 CDT 2010 

Thanks for your response!

I reversed the right order: 'what' comes first and 'how' next. The basic
question is whether to support usernames as namespaces:)

To my understanding unique names within the user namespace is only
useful when there's a problem during the creation process and the agent
doesn't receive the new id.

However as a workaround a user or agent might list back its computes
and find the new id from that list. Though not as simple as queriing by
name it could work.

Unique names within the user namespace might increase usability in the
above manner but is probably not critical. Maybe later:) Unique names
within the global namespace... well, that's another story:)

Cheers,
Gyula

________________________________________
Feladó: Ralf Nyren [ralf at nyren.net]
Küldve: 2010. augusztus 27. 17:44
Címzett: Csom Gyula; Thijs Metsch
Másolatot kap: occi-wg at ogf.org
Tárgy: Re: [occi-wg] New revision of the spec

The current spec says resource IDs are URIs and must be unique within the
service provider's namespace.

If we follow this things are kept simple and there is no risk of
collisions. I would use UUIDs in this case so a resource ID would look
like eg:

id=urn:uuid:cd1b56b8-195b-4ee2-a4dd-a4e4198d0468

or

id="http://provider.com/occi/compute/cd1b56b8-195b-4ee2-a4dd-a4e4198d0468"

regards, Ralf

On Fri, 27 Aug 2010 17:02:54 +0200, Csom Gyula <csom at interface.hu> wrote:

> Hi!
>
> Just one more question regarding unique names (see [5] below)...
>
> System ids generated by the cloud seems to slightly differ from unique
> names
> assigned by users. To put it simply... System ids globally identify
> resources... to say
> at the machine level. Meanwhile unique names identify resources for
> their users.
> Hence unqiue names doesn't have to be globally unique just within a user
> domain.
>
> If unqiue names was supported in the above manner, then an OCCI client
> agent
> might augment a name to make it fully qualified. Like:
>
>   PUT /foo/bar at somebody
>
> However there could be an issue with the above approach. That is if such
> convention
> is not enforced by the server then another agent of another user may
> still assign the
> same name a name that doesn't belong to her by convention.
>
> In order to support unique names I guess OCCI servers should either
> enforce some
> naming conventions (through authorization) or augment the names
> themselves (by
> using session information) or maybe use some other technqiue to protect
> against
> name collisions. Anyhow such solution seems to be within the scope of
> the OCCI
> protocol...
>
> What do you think?:)
>
> Cheers,
> Gyula
>
> ________________________________________
> Feladó: Thijs Metsch [tmetsch at platform.com]
> Küldve: 2010. augusztus 6. 11:30
> Címzett: Csom Gyula
> Másolatot kap: occi-wg at ogf.org
> Tárgy: RE: [occi-wg] New revision of the spec
>
> 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
>>
>
> --
> 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

More information about the occi-wg mailing list