OCCI specification document
Hi @all, The current version of the OCCI specification can be found here: http://forge.ogf.org/sf/go/doc15731?nav=1 Please have a look with a special look on the attributes defined in the document? Are any missing? Are there to much? What about the naming? We will be working on the document in the next days to push it further to get it done for OGF27. So more details and information to come. For now comments and ideas about the attributes are more then welcome! All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
Hello all, after having read the specification in its most current version, I would like to request a number of clarifications regarding not only the attributes given at the end of the document. Some of these requests for clarifications that follow may not be possible to answer yet (or at least not in time for OGF27). - Page 2 states that it is trivial to translate between wire formats. It then gives an example in the "text" format. Could the translation to e.g. XML (Atom) be shown as well? This would clear up how one would go about posting e.g. a Create request using something else than the HTTP Form encoding, as show on Page 3. - Page 3 states that there are both global and local IDs, and that resources should also have a UUID attribute. Is the local ID the same as the UUID, and the global one simply the URL (which includes the UUID)? Clarifications may be in order here, perhaps with an example. - Page 3 also states that the resource may be moved by an implementation to some other implementation. If so, it is according to the text permissible to not know the new URL for the resource. How will the user find out about this new URL, if she is given a HTTP 410 Gone message by the site she submitted the resource to? - On Page 4, given the presence of "Requests", it is not clear to me what should be considered an "Update" or a "Request". Is there a semantic difference between the two, and if so, what is it? - Page 6, at the "DELETE" operation, there is a note that everything "under" a resource is deleted. What does this mean, specifically? - On Page 6, Collections are mentioned, and that they will be rendered as Atom feeds. Are collections (as Atom feeds) to be accepted as input to some/all operations? Could examples of this be presented in that case? Please note that collections as input, and the related collections as output will require some special handling, since the Atom specification does not consider the Entries in a Feed to be ordered. Thus, the mapping from the output Entries to the input Entries must be made clear in the output. - Page 6 has an overfull hbox (in LaTeX terms, in English "text too long to fit on the paper") in the example, which makes reading the example impossible. Please fix! - On Pages 8 -- 10, it is unclear how most of the attributes will be mapped to Atom (starting with Section 4.4.4 "Status" and onward). What should be elements, and what should be attributes? The information needs to be represented somehow, and mappings to Atom Entry elements is not defined. Thus, they must be defined by the OCCI. - Monitoring is supposed to be supplied as an OCCI extension, but there is a set of attributes for reporting status on Page 8. How does the client get such status reports, and is monitoring intended to work in the same way? - Page 10 mentions the State machine, without presenting it. Perhaps it would be clearer to the reader if the state machine is included, given that the document describes how to alter the state of a (compute) resource? On that note, what are the state machines for the other types of resources? Best regards, -- Lars On Fri, 14 Aug 2009, Thijs Metsch wrote:
Hi @all,
The current version of the OCCI specification can be found here:
http://forge.ogf.org/sf/go/doc15731?nav=1
Please have a look with a special look on the attributes defined in the document? Are any missing? Are there to much? What about the naming?
We will be working on the document in the next days to push it further to get it done for OGF27. So more details and information to come. For now comments and ideas about the attributes are more then welcome!
All the best,
-Thijs
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Fri, Aug 14, 2009 at 10:49 AM, Lars Larsson <larsson@cs.umu.se> wrote:
- Page 2 states that it is trivial to translate between wire formats. It then gives an example in the "text" format. Could the translation to e.g. XML (Atom) be shown as well? This would clear up how one would go about posting e.g. a Create request using something else than the HTTP Form encoding, as show on Page 3.
There are two types of interactions: - retrieving representations (e.g. OVF or our own descriptor format), which use the usual GET/PUT/POST/DELETE semantics - doing stuff (e.g. start, stop, restart) which often requires more than just an empty POST (e.g. for stop/restart is that soft, hard, acpi off, cable pull, etc.) - html forms are best for these types of interactions as we don't need to define a new DSL & all clients have support built in OOTB. - Page 3 states that there are both global and local IDs, and
that resources should also have a UUID attribute. Is the local ID the same as the UUID, and the global one simply the URL (which includes the UUID)? Clarifications may be in order here, perhaps with an example.
Everything, by virtue of having a URL, has a globally unique identifier. However these are not immutable - perhaps the same resource will appear on a node as well as a gateway, or it will move between nodes throughout its lifecycle. Initially we spoke about embedding a uuid into the URL but for legacy purposes this was deemed a bad idea (e.g. most systems already have unique IDs). Simple fix for tracking resources is to allocate them a random (v4) UUID which is immutable... this is the same as what VMware do (and why they ask you if you want to keep the same UUID - eg if the machine was moved - or generate a new one - eg if the machine was copied).
- Page 3 also states that the resource may be moved by an implementation to some other implementation. If so, it is according to the text permissible to not know the new URL for the resource. How will the user find out about this new URL, if she is given a HTTP 410 Gone message by the site she submitted the resource to?
The semantics of moving resources was discussed on this week's call. However we define the API it will be possible for: - one cloud to enumerate and render the resources of another (eg pull) - one cloud to create resources on another (eg push) The use case we haven't yet catered for (but are looking at HTTP COPY and MOVE as defined by WebDAV) is where you have a remote client (eg an iPhone app) that wants to send instructions to migrate without handling the 1's and 0's itself.
- On Page 4, given the presence of "Requests", it is not clear to me what should be considered an "Update" or a "Request". Is there a semantic difference between the two, and if so, what is it?
It makes sense for us to separate out any descriptor format so as to resolve such confusion. Requests are things like state changes (think of them as jobs or tasks if you like) - things that may happen immediately, later, on some schedule, etc.
- Page 6, at the "DELETE" operation, there is a note that everything "under" a resource is deleted. What does this mean, specifically?
Currently each resource has collections of e.g. interfaces/devices, requests, etc. - if you delete the resource then those things that are associated with it no longer make sense.
- On Page 6, Collections are mentioned, and that they will be rendered as Atom feeds. Are collections (as Atom feeds) to be accepted as input to some/all operations? Could examples of this be presented in that case?
That was originally the idea but there was some stiff opposition to Atom and XML in general so it was relegated to collections so as to avoid creating another DSL. Making everything reconcile without the benefit of the atom specification is what is taking most of the time at the moment (e.g. writing the HTTP Category header draft).
Please note that collections as input, and the related collections as output will require some special handling, since the Atom specification does not consider the Entries in a Feed to be ordered. Thus, the mapping from the output Entries to the input Entries must be made clear in the output.
Each entry has at least one unique identifier (the URL) so order is not important, except in terms of dependencies. Again, without the benefit of Atom feeds you then have to look to stateless HTTP for transactions which is a huge PITA (albeit one with potential, if convoluted, solutions).
- Page 6 has an overfull hbox (in LaTeX terms, in English "text too long to fit on the paper") in the example, which makes reading the example impossible. Please fix!
Apologies - we'll certainly fix the formatting as the document matures. There are HTML and DocBook versions if the PDF version is inconvenient. - On Pages 8 -- 10, it is unclear how most of the attributes
will be mapped to Atom (starting with Section 4.4.4 "Status" and onward). What should be elements, and what should be attributes? The information needs to be represented somehow, and mappings to Atom Entry elements is not defined. Thus, they must be defined by the OCCI.
Yes, and GData provide a good example for how to do this. The problem is making it reconcile with the other formats without trying to map Atom to JSON, text and whatever other renderings people want to use (eg protocol buffers).
- Monitoring is supposed to be supplied as an OCCI extension, but there is a set of attributes for reporting status on Page 8. How does the client get such status reports, and is monitoring intended to work in the same way?
This is definitely a work in progress... the idea was to specify a mechanism in core and expose it inline and/or via LINKs where relevant.
- Page 10 mentions the State machine, without presenting it. Perhaps it would be clearer to the reader if the state machine is included, given that the document describes how to alter the state of a (compute) resource?
This was discussed before but state machines tend to be quite religious and if the proposed state machine doesn't match your existing implementation you're in trouble. We obviously need to define some states but the rest will live in a registry.
On that note, what are the state machines for the other types of resources?
The state machine protocol will hopefully be sufficiently generic that it can be used with storage and network resources as well, plus any future work we do (e.g. PaaS, SaaS). I hope that at least partially answers most of your questions. I'm working on the spec actively at the moment (while on holidays in the south of france no less) so I hope some of these gaps will be closed soon enough. Sam
On Fri, 14 Aug 2009, Thijs Metsch wrote:
Hi @all,
The current version of the OCCI specification can be found here:
http://forge.ogf.org/sf/go/doc15731?nav=1
Please have a look with a special look on the attributes defined in the document? Are any missing? Are there to much? What about the naming?
We will be working on the document in the next days to push it further to get it done for OGF27. So more details and information to come. For now comments and ideas about the attributes are more then welcome!
All the best,
-Thijs
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Quoting [Sam Johnston] (Aug 14 2009):
Everything, by virtue of having a URL, has a globally unique identifier.
file://localhost/etc/passwd is a URL, but not globally unique (DNS is not globally unique). Same for file://10.0.0.1/etc/passwd I guess this does not matter to us, but anyway... Andre.
However these are not immutable - perhaps the same resource will appear on a node as well as a gateway, or it will move between nodes throughout its lifecycle. Initially we spoke about embedding a uuid into the URL but for legacy purposes this was deemed a bad idea (e.g. most systems already have unique IDs). Simple fix for tracking resources is to allocate them a random (v4) UUID which is immutable... this is the same as what VMware do (and why they ask you if you want to keep the same UUID - eg if the machine was moved - or generate a new one - eg if the machine was copied).
- Page 3 also states that the resource may be moved by an implementation to some other implementation. If so, it is according to the text permissible to not know the new URL for the resource. How will the user find out about this new URL, if she is given a HTTP 410 Gone message by the site she submitted the resource to?
The semantics of moving resources was discussed on this week's call. However we define the API it will be possible for: * one cloud to enumerate and render the resources of another (eg pull) * one cloud to create resources on another (eg push)
The use case we haven't yet catered for (but are looking at HTTP COPY and MOVE as defined by WebDAV) is where you have a remote client (eg an iPhone app) that wants to send instructions to migrate without handling the 1's and 0's itself.
- On Page 4, given the presence of "Requests", it is not clear to me what should be considered an "Update" or a "Request". Is there a semantic difference between the two, and if so, what is it?
It makes sense for us to separate out any descriptor format so as to resolve such confusion. Requests are things like state changes (think of them as jobs or tasks if you like) - things that may happen immediately, later, on some schedule, etc.
- Page 6, at the "DELETE" operation, there is a note that everything "under" a resource is deleted. What does this mean, specifically?
Currently each resource has collections of e.g. interfaces/devices, requests, etc. - if you delete the resource then those things that are associated with it no longer make sense.
- On Page 6, Collections are mentioned, and that they will be rendered as Atom feeds. Are collections (as Atom feeds) to be accepted as input to some/all operations? Could examples of this be presented in that case?
That was originally the idea but there was some stiff opposition to Atom and XML in general so it was relegated to collections so as to avoid creating another DSL. Making everything reconcile without the benefit of the atom specification is what is taking most of the time at the moment (e.g. writing the HTTP Category header draft).
Please note that collections as input, and the related collections as output will require some special handling, since the Atom specification does not consider the Entries in a Feed to be ordered. Thus, the mapping from the output Entries to the input Entries must be made clear in the output.
Each entry has at least one unique identifier (the URL) so order is not important, except in terms of dependencies. Again, without the benefit of Atom feeds you then have to look to stateless HTTP for transactions which is a huge PITA (albeit one with potential, if convoluted, solutions).
- Page 6 has an overfull hbox (in LaTeX terms, in English "text too long to fit on the paper") in the example, which makes reading the example impossible. Please fix!
Apologies - we'll certainly fix the formatting as the document matures. There are HTML and DocBook versions if the PDF version is inconvenient.
- On Pages 8 -- 10, it is unclear how most of the attributes will be mapped to Atom (starting with Section 4.4.4 "Status" and onward). What should be elements, and what should be attributes? The information needs to be represented somehow, and mappings to Atom Entry elements is not defined. Thus, they must be defined by the OCCI.
Yes, and GData provide a good example for how to do this. The problem is making it reconcile with the other formats without trying to map Atom to JSON, text and whatever other renderings people want to use (eg protocol buffers).
- Monitoring is supposed to be supplied as an OCCI extension, but there is a set of attributes for reporting status on Page 8. How does the client get such status reports, and is monitoring intended to work in the same way?
This is definitely a work in progress... the idea was to specify a mechanism in core and expose it inline and/or via LINKs where relevant.
- Page 10 mentions the State machine, without presenting it. Perhaps it would be clearer to the reader if the state machine is included, given that the document describes how to alter the state of a (compute) resource?
This was discussed before but state machines tend to be quite religious and if the proposed state machine doesn't match your existing implementation you're in trouble. We obviously need to define some states but the rest will live in a registry.
On that note, what are the state machines for the other types of resources?
The state machine protocol will hopefully be sufficiently generic that it can be used with storage and network resources as well, plus any future work we do (e.g. PaaS, SaaS). I hope that at least partially answers most of your questions. I'm working on the spec actively at the moment (while on holidays in the south of france no less) so I hope some of these gaps will be closed soon enough. Sam
On Fri, 14 Aug 2009, Thijs Metsch wrote:
Hi @all,
The current version of the OCCI specification can be found here:
[2]http://forge.ogf.org/sf/go/doc15731?nav=1
Please have a look with a special look on the attributes defined in
the
document? Are any missing? Are there to much? What about the naming?
We will be working on the document in the next days to push it further to get it done for OGF27. So more details and information to come. For now comments and ideas about the attributes are more then welcome!
All the best,
-Thijs
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) [3]http://blogs.sun.com/intheclouds [4]http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:[5]thijs.metsch@sun.com D-93049 Regensburg [6]http://www.sun.com
_______________________________________________ occi-wg mailing list [7]occi-wg@ogf.org [8]http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list [9]occi-wg@ogf.org [10]http://www.ogf.org/mailman/listinfo/occi-wg
References
1. mailto:larsson@cs.umu.se 2. http://forge.ogf.org/sf/go/doc15731?nav=1 3. http://blogs.sun.com/intheclouds 4. http://www.twitter.com/befreax 5. mailto:thijs.metsch@sun.com 6. http://www.sun.com/ 7. mailto:occi-wg@ogf.org 8. http://www.ogf.org/mailman/listinfo/occi-wg 9. mailto:occi-wg@ogf.org 10. http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is ever easy.
On Fri, Aug 14, 2009 at 11:41 AM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Sam Johnston] (Aug 14 2009):
Everything, by virtue of having a URL, has a globally unique identifier.
file://localhost/etc/passwd is a URL, but not globally unique (DNS is not globally unique). Same for file://10.0.0.1/etc/passwd
I guess this does not matter to us, but anyway...
That's an interesting point (and an interesting suggestion that OCCI might be used on file:// URLs/sockets). You're right though in that it doesn't matter for us - so long as it's unique for your system then all's well. Another caveat is that if we allow people to use relative URLs (as is the case for the web today) then those need not be unique at all. Relative URLs are useful for internal references in which case they greatly simplify copies and moves. Sam
Dear Sam, thank you for your replies (especially since you're posting while on vacation!). I hope that some of the clarifications can be written in the spec itself as well. The topic of moving resources interests me greatly. Where can I find information on what was discussed during that telco? I can't find a link in the Concall page[1] at the Wiki (and, by the way, it appears that the last few concalls are missing notes). Best regards, -- Lars [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferenc... On Fri, 14 Aug 2009, Sam Johnston wrote:
On Fri, Aug 14, 2009 at 10:49 AM, Lars Larsson <larsson@cs.umu.se> wrote:
- Page 2 states that it is trivial to translate between wire formats. It then gives an example in the "text" format. Could the translation to e.g. XML (Atom) be shown as well? This would clear up how one would go about posting e.g. a Create request using something else than the HTTP Form encoding, as show on Page 3.
There are two types of interactions:
- retrieving representations (e.g. OVF or our own descriptor format), which use the usual GET/PUT/POST/DELETE semantics - doing stuff (e.g. start, stop, restart) which often requires more than just an empty POST (e.g. for stop/restart is that soft, hard, acpi off, cable pull, etc.) - html forms are best for these types of interactions as we don't need to define a new DSL & all clients have support built in OOTB.
- Page 3 states that there are both global and local IDs, and
that resources should also have a UUID attribute. Is the local ID the same as the UUID, and the global one simply the URL (which includes the UUID)? Clarifications may be in order here, perhaps with an example.
Everything, by virtue of having a URL, has a globally unique identifier. However these are not immutable - perhaps the same resource will appear on a node as well as a gateway, or it will move between nodes throughout its lifecycle. Initially we spoke about embedding a uuid into the URL but for legacy purposes this was deemed a bad idea (e.g. most systems already have unique IDs).
Simple fix for tracking resources is to allocate them a random (v4) UUID which is immutable... this is the same as what VMware do (and why they ask you if you want to keep the same UUID - eg if the machine was moved - or generate a new one - eg if the machine was copied).
- Page 3 also states that the resource may be moved by an implementation to some other implementation. If so, it is according to the text permissible to not know the new URL for the resource. How will the user find out about this new URL, if she is given a HTTP 410 Gone message by the site she submitted the resource to?
The semantics of moving resources was discussed on this week's call. However we define the API it will be possible for:
- one cloud to enumerate and render the resources of another (eg pull) - one cloud to create resources on another (eg push)
The use case we haven't yet catered for (but are looking at HTTP COPY and MOVE as defined by WebDAV) is where you have a remote client (eg an iPhone app) that wants to send instructions to migrate without handling the 1's and 0's itself.
- On Page 4, given the presence of "Requests", it is not clear to me what should be considered an "Update" or a "Request". Is there a semantic difference between the two, and if so, what is it?
It makes sense for us to separate out any descriptor format so as to resolve such confusion. Requests are things like state changes (think of them as jobs or tasks if you like) - things that may happen immediately, later, on some schedule, etc.
- Page 6, at the "DELETE" operation, there is a note that everything "under" a resource is deleted. What does this mean, specifically?
Currently each resource has collections of e.g. interfaces/devices, requests, etc. - if you delete the resource then those things that are associated with it no longer make sense.
- On Page 6, Collections are mentioned, and that they will be rendered as Atom feeds. Are collections (as Atom feeds) to be accepted as input to some/all operations? Could examples of this be presented in that case?
That was originally the idea but there was some stiff opposition to Atom and XML in general so it was relegated to collections so as to avoid creating another DSL. Making everything reconcile without the benefit of the atom specification is what is taking most of the time at the moment (e.g. writing the HTTP Category header draft).
Please note that collections as input, and the related collections as output will require some special handling, since the Atom specification does not consider the Entries in a Feed to be ordered. Thus, the mapping from the output Entries to the input Entries must be made clear in the output.
Each entry has at least one unique identifier (the URL) so order is not important, except in terms of dependencies. Again, without the benefit of Atom feeds you then have to look to stateless HTTP for transactions which is a huge PITA (albeit one with potential, if convoluted, solutions).
- Page 6 has an overfull hbox (in LaTeX terms, in English "text too long to fit on the paper") in the example, which makes reading the example impossible. Please fix!
Apologies - we'll certainly fix the formatting as the document matures. There are HTML and DocBook versions if the PDF version is inconvenient.
- On Pages 8 -- 10, it is unclear how most of the attributes
will be mapped to Atom (starting with Section 4.4.4 "Status" and onward). What should be elements, and what should be attributes? The information needs to be represented somehow, and mappings to Atom Entry elements is not defined. Thus, they must be defined by the OCCI.
Yes, and GData provide a good example for how to do this. The problem is making it reconcile with the other formats without trying to map Atom to JSON, text and whatever other renderings people want to use (eg protocol buffers).
- Monitoring is supposed to be supplied as an OCCI extension, but there is a set of attributes for reporting status on Page 8. How does the client get such status reports, and is monitoring intended to work in the same way?
This is definitely a work in progress... the idea was to specify a mechanism in core and expose it inline and/or via LINKs where relevant.
- Page 10 mentions the State machine, without presenting it. Perhaps it would be clearer to the reader if the state machine is included, given that the document describes how to alter the state of a (compute) resource?
This was discussed before but state machines tend to be quite religious and if the proposed state machine doesn't match your existing implementation you're in trouble. We obviously need to define some states but the rest will live in a registry.
On that note, what are the state machines for the other types of resources?
The state machine protocol will hopefully be sufficiently generic that it can be used with storage and network resources as well, plus any future work we do (e.g. PaaS, SaaS).
I hope that at least partially answers most of your questions. I'm working on the spec actively at the moment (while on holidays in the south of france no less) so I hope some of these gaps will be closed soon enough.
Sam
On Fri, 14 Aug 2009, Thijs Metsch wrote:
Hi @all,
The current version of the OCCI specification can be found here:
http://forge.ogf.org/sf/go/doc15731?nav=1
Please have a look with a special look on the attributes defined in the document? Are any missing? Are there to much? What about the naming?
We will be working on the document in the next days to push it further to get it done for OGF27. So more details and information to come. For now comments and ideas about the attributes are more then welcome!
All the best,
-Thijs
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi Lars, Thanks for your comments as well! On Mon, 2009-08-17 at 09:24 +0200, Lars Larsson wrote:
thank you for your replies (especially since you're posting while on vacation!). I hope that some of the clarifications can be written in the spec itself as well.
Sure they can - if you have any suggestions feel free to post or add the to the source files. Would be great if people help forming this document!
The topic of moving resources interests me greatly. Where can I find information on what was discussed during that telco? I can't find a link in the Concall page[1] at the Wiki (and, by the way, it appears that the last few concalls are missing notes).
Well I'll try to take that into account and add minutes in future... Cheers, -Thijs
Tying the vlan ID to a 12-bit integer like 802.1q is probably a horrible mistake. Strongly recommend you avoid that. At the very least it should be a 32-bit integer, but more likely a 64-bit integer or even (preferably) a string. Very few cloud providers of any reasonable size will have less than 4096 IDs *and* I can guarantee you that there will be non-802.1q workarounds to providing L2 networking domains. --Randy On Aug 13, 2009, at 11:53 PM, Thijs Metsch wrote:
Hi @all,
The current version of the OCCI specification can be found here:
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
On Sat, Aug 15, 2009 at 4:21 AM, Randy Bias <randyb@neotactics.com> wrote:
Tying the vlan ID to a 12-bit integer like 802.1q is probably a horrible mistake. Strongly recommend you avoid that. At the very least it should be a 32-bit integer, but more likely a 64-bit integer or even (preferably) a string. Very few cloud providers of any reasonable size will have less than 4096 IDs *and* I can guarantee you that there will be non-802.1q workarounds to providing L2 networking domains.
Thanks Randy. You're right, and that's why we also have vlan-tag (but really we should probably have schemas so you can specify namespaces like 802.1q, MPLS labels, etc.) network.vlan-idInteger (0..4095)802.1q VLAN ID (e.g. 4095)network.vlan-tag TokenTag based VLANs (e.g. external-dmz) Sam
participants (5)
-
Andre Merzky -
Lars Larsson -
Randy Bias -
Sam Johnston -
Thijs Metsch