Hi, From the current discussions, there has been no mention of events. Will the occi support events ? What will the model look like ? -gary mazzaferro
On Mon, May 18, 2009 at 7:55 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
Hi,
From the current discussions, there has been no mention of events. Will the occi support events ? What will the model look like ?
This is something I had thought about a little but not considered a focus point for us. I did however consider the possibility of OCCI messages being long lived in that they can be queued and passed over transports like XMPP (this was one of a number of potential use cases for signatures). The interest in doing this would be, for example, a client that has rendered a number of resources and wants to know about state changes and the like. They would just need to subscribe to the resource and when the state changes they would be sent the updated entry. Similarly an management system could ask for regular updates of e.g. performance monitor counters. Does this sound adequate for your needs or do you have use case(s) that require more - and if so, why aren't they in the wiki ;) Sam
You've got it... I do like the idea of long life messages and events. I think events will be important just from the perspective of well know programming practices. I personally don't see unix signals going away for a long while. Resources can change states for one reason or another. Networking and storage (another network) are often victims of accidental switch reconfigurations resulting in loss of connectivity to endpoints. Configuration changes to resources outside the scope of the "active state" in the "life cycle model" may need to be logged or corrective action may be engaged. Long life remote service dependencies are another area where events may be appropriate. Normally, I would suggest the applications handle occurrences between parties, but with migration as a normal circumstance, it may be out of control and scope of the parties. Either the infrastructure will handle a "pause for migration" event or the container will tell the app which will tell the other party. Queuing (a bridge) may be a way to avoid the issue as long as the service parameters are not violated. But it may be out of scope for interoperability. Security or privilege revocation is another area. Hard execution breaks due to user or admin control is still another area. Polling may be inappropriate in many cases, driving up CPU loads and network bandwidth consumption. I'll get them on the wiki in the later AM... I'm gmt -7 -gary Sam Johnston wrote:
On Mon, May 18, 2009 at 7:55 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Hi,
From the current discussions, there has been no mention of events. Will the occi support events ? What will the model look like ?
This is something I had thought about a little but not considered a focus point for us. I did however consider the possibility of OCCI messages being long lived in that they can be queued and passed over transports like XMPP (this was one of a number of potential use cases for signatures).
The interest in doing this would be, for example, a client that has rendered a number of resources and wants to know about state changes and the like. They would just need to subscribe to the resource and when the state changes they would be sent the updated entry. Similarly an management system could ask for regular updates of e.g. performance monitor counters.
Does this sound adequate for your needs or do you have use case(s) that require more - and if so, why aren't they in the wiki ;)
Sam
On 19 May 2009, at 12:16, Gary Mazz wrote:
You've got it...
I do like the idea of long life messages and events. I think events will be important just from the perspective of well know programming practices. I personally don't see unix signals going away for a long while.
Resources can change states for one reason or another. Networking and storage (another network) are often victims of accidental switch reconfigurations resulting in loss of connectivity to endpoints.
Configuration changes to resources outside the scope of the "active state" in the "life cycle model" may need to be logged or corrective action may be engaged.
Long life remote service dependencies are another area where events may be appropriate. Normally, I would suggest the applications handle occurrences between parties, but with migration as a normal circumstance, it may be out of control and scope of the parties. Either the infrastructure will handle a "pause for migration" event or the container will tell the app which will tell the other party. Queuing (a bridge) may be a way to avoid the issue as long as the service parameters are not violated. But it may be out of scope for interoperability.
Security or privilege revocation is another area. Hard execution breaks due to user or admin control is still another area.
Polling may be inappropriate in many cases, driving up CPU loads and network bandwidth consumption.
Going down the ATOM route, one does get a feed of events (cf. recent discussions related to holding the lifecycle of a resource as a collection of states in a feed). In addition, there are a number of approaches out there to alert interested parties to an updated feed, stopping relentless polling somewhat. I wonder if that is enough ? regards, Roger
I'll get them on the wiki in the later AM... I'm gmt -7
-gary
Sam Johnston wrote:
On Mon, May 18, 2009 at 7:55 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Hi,
From the current discussions, there has been no mention of events. Will the occi support events ? What will the model look like ?
This is something I had thought about a little but not considered a focus point for us. I did however consider the possibility of OCCI messages being long lived in that they can be queued and passed over transports like XMPP (this was one of a number of potential use cases for signatures).
The interest in doing this would be, for example, a client that has rendered a number of resources and wants to know about state changes and the like. They would just need to subscribe to the resource and when the state changes they would be sent the updated entry. Similarly an management system could ask for regular updates of e.g. performance monitor counters.
Does this sound adequate for your needs or do you have use case(s) that require more - and if so, why aren't they in the wiki ;)
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Roger Menday (PhD) <roger.menday@uk.fujitsu.com> Senior Researcher, Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K. Tel: +44 (0) 208 606 4534 ______________________________________________________________________ Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE Registered No. 4153469 This e-mail and any attachments are for the sole use of addressee(s) and may contain information which is privileged and confidential. Unauthorised use or copying for disclosure is strictly prohibited. The fact that this e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does not guarantee that it has not been intercepted or amended nor that it is virus-free.
Interesting point. Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****. a On Tue, May 19, 2009 at 5:53 PM, Roger Menday <roger.menday@uk.fujitsu.com> wrote:
On 19 May 2009, at 12:16, Gary Mazz wrote:
You've got it...
I do like the idea of long life messages and events. I think events will be important just from the perspective of well know programming practices. I personally don't see unix signals going away for a long while.
Resources can change states for one reason or another. Networking and storage (another network) are often victims of accidental switch reconfigurations resulting in loss of connectivity to endpoints.
Configuration changes to resources outside the scope of the "active state" in the "life cycle model" may need to be logged or corrective action may be engaged.
Long life remote service dependencies are another area where events may be appropriate. Normally, I would suggest the applications handle occurrences between parties, but with migration as a normal circumstance, it may be out of control and scope of the parties. Either the infrastructure will handle a "pause for migration" event or the container will tell the app which will tell the other party. Queuing (a bridge) may be a way to avoid the issue as long as the service parameters are not violated. But it may be out of scope for interoperability.
Security or privilege revocation is another area. Hard execution breaks due to user or admin control is still another area.
Polling may be inappropriate in many cases, driving up CPU loads and network bandwidth consumption.
Going down the ATOM route, one does get a feed of events (cf. recent discussions related to holding the lifecycle of a resource as a collection of states in a feed). In addition, there are a number of approaches out there to alert interested parties to an updated feed, stopping relentless polling somewhat. I wonder if that is enough ?
regards, Roger
I'll get them on the wiki in the later AM... I'm gmt -7
-gary
Sam Johnston wrote:
On Mon, May 18, 2009 at 7:55 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Hi,
From the current discussions, there has been no mention of events. Will the occi support events ? What will the model look like ?
This is something I had thought about a little but not considered a focus point for us. I did however consider the possibility of OCCI messages being long lived in that they can be queued and passed over transports like XMPP (this was one of a number of potential use cases for signatures).
The interest in doing this would be, for example, a client that has rendered a number of resources and wants to know about state changes and the like. They would just need to subscribe to the resource and when the state changes they would be sent the updated entry. Similarly an management system could ask for regular updates of e.g. performance monitor counters.
Does this sound adequate for your needs or do you have use case(s) that require more - and if so, why aren't they in the wiki ;)
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Roger Menday (PhD) <roger.menday@uk.fujitsu.com>
Senior Researcher, Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K. Tel: +44 (0) 208 606 4534
______________________________________________________________________
Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE Registered No. 4153469
This e-mail and any attachments are for the sole use of addressee(s) and may contain information which is privileged and confidential. Unauthorised use or copying for disclosure is strictly prohibited. The fact that this e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does not guarantee that it has not been intercepted or amended nor that it is virus-free. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here. The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc. Sam
Indeed and XMPP and HTTP should not be overlooked either. On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
Well since this is a interoperability interface, I'm assuming there will be gateways to other technologies like fabrics. Events, event delivery and event management are important patterns and are supported by others. I don't believe we'll be able to get away without supporting them for very long. One of the big drawbacks to snmp and cimoms are the lack of event support and an infrastructure to support event message persistence. I'm also not sure where we are drawing the line in terms of interoperability. There was a general consensus that occi should be focusing on integration points in the cloud, but I didn't see a clear definition of an integration point. (I was out of the loop for a while) In the occi model the platform can be considered a container (loosely, a vm) with infrastructure resources provisioned. The container life cycle and resource provisioning are "management" integration points, although there are no verbs published yet. Will portions of occi interface be permitted to permeate the container boundary ? It is still unclear the level of interaction, if any, between the occi and the container contents. Maybe I missed the definition. -gary Alexis Richardson wrote:
Indeed and XMPP and HTTP should not be overlooked either.
On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Gary Have you seen the interface comparison spreadsheet? http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ This is our core focus for interop. To achieve commonality right here right now. No invention just interop. a On Tue, May 19, 2009 at 9:51 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
Well since this is a interoperability interface, I'm assuming there will be gateways to other technologies like fabrics. Events, event delivery and event management are important patterns and are supported by others. I don't believe we'll be able to get away without supporting them for very long. One of the big drawbacks to snmp and cimoms are the lack of event support and an infrastructure to support event message persistence.
I'm also not sure where we are drawing the line in terms of interoperability. There was a general consensus that occi should be focusing on integration points in the cloud, but I didn't see a clear definition of an integration point. (I was out of the loop for a while) In the occi model the platform can be considered a container (loosely, a vm) with infrastructure resources provisioned. The container life cycle and resource provisioning are "management" integration points, although there are no verbs published yet. Will portions of occi interface be permitted to permeate the container boundary ? It is still unclear the level of interaction, if any, between the occi and the container contents. Maybe I missed the definition.
-gary
Alexis Richardson wrote:
Indeed and XMPP and HTTP should not be overlooked either.
On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Yes, thanks.. I'm looking at it and using it as a guide to the other specs. I'll explain why I'm confused and it look like I'm pursuing more than the scope In the occi system model, the IaaS fits between the PaaS and fabric. Looking at the occi UML it shows the compute resource as aggregated dependency of cluster<ag>>domain<ag>>cloud. The example defines "groups" as racks, pools, data center, etc., real physical assets. Based on the example, I think of clusters as organization of physical compute resources. If the intent was to keep domain and cloud logical elements, it may be better to get rid of the cluster as a class and convert it to a property defining a quality of service for the user. Some may disagree, but I don't believe the user cares if there is a cluster configured for round robin, random distribution, active all or primary/spare failover. I'm assuming they'll care about workload capacity and service availability. (and costs). Currently cluster<ag>>domain<ag>>cloud looks more like a fabric than a logical components. Fabrics need a different set of capabilities, like events. -gary Alexis Richardson wrote:
Gary
Have you seen the interface comparison spreadsheet?
http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
This is our core focus for interop. To achieve commonality right here right now. No invention just interop.
a
On Tue, May 19, 2009 at 9:51 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
Well since this is a interoperability interface, I'm assuming there will be gateways to other technologies like fabrics. Events, event delivery and event management are important patterns and are supported by others. I don't believe we'll be able to get away without supporting them for very long. One of the big drawbacks to snmp and cimoms are the lack of event support and an infrastructure to support event message persistence.
I'm also not sure where we are drawing the line in terms of interoperability. There was a general consensus that occi should be focusing on integration points in the cloud, but I didn't see a clear definition of an integration point. (I was out of the loop for a while) In the occi model the platform can be considered a container (loosely, a vm) with infrastructure resources provisioned. The container life cycle and resource provisioning are "management" integration points, although there are no verbs published yet. Will portions of occi interface be permitted to permeate the container boundary ? It is still unclear the level of interaction, if any, between the occi and the container contents. Maybe I missed the definition.
-gary
Alexis Richardson wrote:
Indeed and XMPP and HTTP should not be overlooked either.
On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Gary, The UML doesn't reflect the reality of the AtomPub meta-model, which is in fact far more flexible. I don't care if you call your logical collections "groups", "clusters", "virtual data centers" or "gaggles". The categories have terms ("win2k3"), labels ("Windows 2003 Server") and schemes ("http://purl.org/occi/category#os") and the very first category we would be looking to define is of course the resource types (what Google call "kinds") - that is, "compute", "storage", "network" (and according to NIST's draft definition, in future "application" and "service" - though I'm not sure about that). Hierarchical grouping is something to talk about - do we use something like a '/' separator ala /myvdc/myvrack, have pointers to "parent" objects, or something else. Ok have a flight to catch to London - see [some of] you there. Sam On Wed, May 20, 2009 at 5:38 AM, Gary Mazz <garymazzaferro@gmail.com> wrote:
Yes, thanks.. I'm looking at it and using it as a guide to the other specs.
I'll explain why I'm confused and it look like I'm pursuing more than the scope
In the occi system model, the IaaS fits between the PaaS and fabric. Looking at the occi UML it shows the compute resource as aggregated dependency of cluster<ag>>domain<ag>>cloud. The example defines "groups" as racks, pools, data center, etc., real physical assets. Based on the example, I think of clusters as organization of physical compute resources. If the intent was to keep domain and cloud logical elements, it may be better to get rid of the cluster as a class and convert it to a property defining a quality of service for the user. Some may disagree, but I don't believe the user cares if there is a cluster configured for round robin, random distribution, active all or primary/spare failover. I'm assuming they'll care about workload capacity and service availability. (and costs).
Currently cluster<ag>>domain<ag>>cloud looks more like a fabric than a logical components. Fabrics need a different set of capabilities, like events.
-gary
Alexis Richardson wrote:
Gary
Have you seen the interface comparison spreadsheet?
http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
This is our core focus for interop. To achieve commonality right here right now. No invention just interop.
a
On Tue, May 19, 2009 at 9:51 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
Well since this is a interoperability interface, I'm assuming there will be gateways to other technologies like fabrics. Events, event delivery and event management are important patterns and are supported by others. I don't believe we'll be able to get away without supporting them for very long. One of the big drawbacks to snmp and cimoms are the lack of event support and an infrastructure to support event message persistence.
I'm also not sure where we are drawing the line in terms of interoperability. There was a general consensus that occi should be focusing on integration points in the cloud, but I didn't see a clear definition of an integration point. (I was out of the loop for a while) In the occi model the platform can be considered a container (loosely, a vm) with infrastructure resources provisioned. The container life cycle and resource provisioning are "management" integration points, although there are no verbs published yet. Will portions of occi interface be permitted to permeate the container boundary ? It is still unclear the level of interaction, if any, between the occi and the container contents. Maybe I missed the definition.
-gary
Alexis Richardson wrote:
Indeed and XMPP and HTTP should not be overlooked either.
On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Gary,
The UML doesn't reflect the reality of the AtomPub meta-model, which is in fact far more flexible. I don't care if you call your logical collections "groups", "clusters", "virtual data centers" or "gaggles". I assumed its more flexible, but I wasn't sure of the terminology and
Sam Johnston wrote: division of responsibilities. The DMTF model included virtual metal like network adapters and HBAs. Others define disk drives and disk files. I don't see any managing QOS for virtual metal. The problem with all this vmetal is it exposes the underlying fabric or a vitalized view of the underlying fabric. ie switches, gateways, routers, paths, storage multipathing, disk arrays and luns. It can be a can o' worms. We still need to figure out how to handle an IP address in one cloud provider on one net segment and migrating to another provider on another net segment.
The categories have terms ("win2k3"), labels ("Windows 2003 Server") and schemes ("http://purl.org/occi/category#os") and the very first category we would be looking to define is of course the resource types (what Google call "kinds") - that is, "compute", "storage", "network" (and according to NIST's draft definition, in future "application" and "service" - though I'm not sure about that).
In part, I'm trying to itemize the terms/properties.
Hierarchical grouping is something to talk about - do we use something like a '/' separator ala /myvdc/myvrack, have pointers to "parent" objects, or something else.
Agreed, I personally would like to see different views of the system. The end user should see /Domain/Federation/Cloud/containers/resources . The cloud provider should see /Cloud/Federation/Domain/containers/resources or /Cloud/Domain/Federation/containers/resources. Privacy laws and business practices may restrict one cloud provider from viewing a domain's other cloud providers and their resources. The roles are also different. The Domain would be interested in a view of its multiple cloud providers. The cloud providers would be interested in the Domains and their utilization.
Ok have a flight to catch to London - see [some of] you there.
Safe trip... -gary
Sam
On Wed, May 20, 2009 at 5:38 AM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Yes, thanks.. I'm looking at it and using it as a guide to the other specs.
I'll explain why I'm confused and it look like I'm pursuing more than the scope
In the occi system model, the IaaS fits between the PaaS and fabric. Looking at the occi UML it shows the compute resource as aggregated dependency of cluster<ag>>domain<ag>>cloud. The example defines "groups" as racks, pools, data center, etc., real physical assets. Based on the example, I think of clusters as organization of physical compute resources. If the intent was to keep domain and cloud logical elements, it may be better to get rid of the cluster as a class and convert it to a property defining a quality of service for the user. Some may disagree, but I don't believe the user cares if there is a cluster configured for round robin, random distribution, active all or primary/spare failover. I'm assuming they'll care about workload capacity and service availability. (and costs).
Currently cluster<ag>>domain<ag>>cloud looks more like a fabric than a logical components. Fabrics need a different set of capabilities, like events.
-gary
Alexis Richardson wrote:
Gary
Have you seen the interface comparison spreadsheet?
http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
This is our core focus for interop. To achieve commonality right here right now. No invention just interop.
a
On Tue, May 19, 2009 at 9:51 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Well since this is a interoperability interface, I'm assuming there will be gateways to other technologies like fabrics. Events, event delivery and event management are important patterns and are supported by others. I don't believe we'll be able to get away without supporting them for very long. One of the big drawbacks to snmp and cimoms are the lack of event support and an infrastructure to support event message persistence.
I'm also not sure where we are drawing the line in terms of interoperability. There was a general consensus that occi should be focusing on integration points in the cloud, but I didn't see a clear definition of an integration point. (I was out of the loop for a while) In the occi model the platform can be considered a container (loosely, a vm) with infrastructure resources provisioned. The container life cycle and resource provisioning are "management" integration points, although there are no verbs published yet. Will portions of occi interface be permitted to permeate the container boundary ? It is still unclear the level of interaction, if any, between the occi and the container contents. Maybe I missed the definition.
-gary
Alexis Richardson wrote:
Indeed and XMPP and HTTP should not be overlooked either.
On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net <mailto:samj@samj.net>> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com <mailto:alexis.richardson@gmail.com>> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
Gary,
The UML doesn't reflect the reality of the AtomPub meta-model, which is in fact far more flexible. I don't care if you call your logical collections "groups", "clusters", "virtual data centers" or "gaggles". I assumed its more flexible, but I wasn't sure of the terminology and
I had a related offline comment by Andre - " Minor comment: the hierarchy you added on top of Compute seems arbitrary (to me). Can that be done generically, e.g. a group entity which has 1:n mapping to itself, and Compute resources?" With that I modified things to be more generic/flexible - see attached. Andy -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Gary Mazz Sent: 20 May 2009 09:14 To: Sam Johnston Cc: occi-wg@ogf.org; Roger Menday Subject: Re: [occi-wg] Events ? Sam Johnston wrote: division of responsibilities. The DMTF model included virtual metal like network adapters and HBAs. Others define disk drives and disk files. I don't see any managing QOS for virtual metal. The problem with all this vmetal is it exposes the underlying fabric or a vitalized view of the underlying fabric. ie switches, gateways, routers, paths, storage multipathing, disk arrays and luns. It can be a can o' worms. We still need to figure out how to handle an IP address in one cloud provider on one net segment and migrating to another provider on another net segment.
The categories have terms ("win2k3"), labels ("Windows 2003 Server") and schemes ("http://purl.org/occi/category#os") and the very first category we would be looking to define is of course the resource types (what Google call "kinds") - that is, "compute", "storage", "network" (and according to NIST's draft definition, in future "application" and "service" - though I'm not sure about that).
In part, I'm trying to itemize the terms/properties.
Hierarchical grouping is something to talk about - do we use something like a '/' separator ala /myvdc/myvrack, have pointers to "parent" objects, or something else.
Agreed, I personally would like to see different views of the system. The end user should see /Domain/Federation/Cloud/containers/resources . The cloud provider should see /Cloud/Federation/Domain/containers/resources or /Cloud/Domain/Federation/containers/resources. Privacy laws and business practices may restrict one cloud provider from viewing a domain's other cloud providers and their resources. The roles are also different. The Domain would be interested in a view of its multiple cloud providers. The cloud providers would be interested in the Domains and their utilization.
Ok have a flight to catch to London - see [some of] you there.
Safe trip... -gary
Sam
On Wed, May 20, 2009 at 5:38 AM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Yes, thanks.. I'm looking at it and using it as a guide to the other specs.
I'll explain why I'm confused and it look like I'm pursuing more than the scope
In the occi system model, the IaaS fits between the PaaS and fabric. Looking at the occi UML it shows the compute resource as aggregated dependency of cluster<ag>>domain<ag>>cloud. The example defines "groups" as racks, pools, data center, etc., real physical assets. Based on the example, I think of clusters as organization of physical compute resources. If the intent was to keep domain and cloud logical elements, it may be better to get rid of the cluster as a class and convert it to a property defining a quality of service for the user. Some may disagree, but I don't believe the user cares if there is a cluster configured for round robin, random distribution, active all or primary/spare failover. I'm assuming they'll care about workload capacity and service availability. (and costs).
Currently cluster<ag>>domain<ag>>cloud looks more like a fabric than a logical components. Fabrics need a different set of capabilities, like events.
-gary
Alexis Richardson wrote:
Gary
Have you seen the interface comparison spreadsheet?
http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
This is our core focus for interop. To achieve commonality right here right now. No invention just interop.
a
On Tue, May 19, 2009 at 9:51 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Well since this is a interoperability interface, I'm assuming there will be gateways to other technologies like fabrics. Events, event delivery and event management are important patterns and are supported by others. I don't believe we'll be able to get away without supporting them for very long. One of the big drawbacks to snmp and cimoms are the lack of event support and an infrastructure to support event message persistence.
I'm also not sure where we are drawing the line in terms of interoperability. There was a general consensus that occi should be focusing on integration points in the cloud, but I didn't see a clear definition of an integration point. (I was out of the loop for a while) In the occi model the platform can be considered a container (loosely, a vm) with infrastructure resources provisioned. The container life cycle and resource provisioning are "management" integration points, although there are no verbs published yet. Will portions of occi interface be permitted to permeate the container boundary ? It is still unclear the level of interaction, if any, between the occi and the container contents. Maybe I missed the definition.
-gary
Alexis Richardson wrote:
Indeed and XMPP and HTTP should not be overlooked either.
On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net <mailto:samj@samj.net>> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com <mailto:alexis.richardson@gmail.com>> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto: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 ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hi Andy, I think the hierarchy is important. I took issue (confusion) with the "cluster" term and lack of definition for the execution container (vm) where the resources are attached. The names in the hierarchy are arbitrary, but we are probably better off defining a scheme and some basic/standard logical entities like clouds, federations, domains, worlds, applications and services. How they are organized should be up to the user's management scheme. We just need to define a way create and reconcile the hierarchy. -gary Edmonds, AndrewX wrote:
I had a related offline comment by Andre - " Minor comment: the hierarchy you added on top of Compute seems arbitrary (to me). Can that be done generically, e.g. a group entity which has 1:n mapping to itself, and Compute resources?" With that I modified things to be more generic/flexible - see attached.
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Gary Mazz Sent: 20 May 2009 09:14 To: Sam Johnston Cc: occi-wg@ogf.org; Roger Menday Subject: Re: [occi-wg] Events ?
Sam Johnston wrote:
Gary,
The UML doesn't reflect the reality of the AtomPub meta-model, which is in fact far more flexible. I don't care if you call your logical collections "groups", "clusters", "virtual data centers" or "gaggles".
I assumed its more flexible, but I wasn't sure of the terminology and division of responsibilities. The DMTF model included virtual metal like network adapters and HBAs. Others define disk drives and disk files. I don't see any managing QOS for virtual metal. The problem with all this vmetal is it exposes the underlying fabric or a vitalized view of the underlying fabric. ie switches, gateways, routers, paths, storage multipathing, disk arrays and luns. It can be a can o' worms. We still need to figure out how to handle an IP address in one cloud provider on one net segment and migrating to another provider on another net segment.
The categories have terms ("win2k3"), labels ("Windows 2003 Server") and schemes ("http://purl.org/occi/category#os") and the very first category we would be looking to define is of course the resource types (what Google call "kinds") - that is, "compute", "storage", "network" (and according to NIST's draft definition, in future "application" and "service" - though I'm not sure about that).
In part, I'm trying to itemize the terms/properties.
Hierarchical grouping is something to talk about - do we use something like a '/' separator ala /myvdc/myvrack, have pointers to "parent" objects, or something else.
Agreed, I personally would like to see different views of the system. The end user should see /Domain/Federation/Cloud/containers/resources . The cloud provider should see /Cloud/Federation/Domain/containers/resources or /Cloud/Domain/Federation/containers/resources. Privacy laws and business practices may restrict one cloud provider from viewing a domain's other cloud providers and their resources. The roles are also different. The Domain would be interested in a view of its multiple cloud providers. The cloud providers would be interested in the Domains and their utilization.
Ok have a flight to catch to London - see [some of] you there.
Safe trip...
-gary
Sam
On Wed, May 20, 2009 at 5:38 AM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Yes, thanks.. I'm looking at it and using it as a guide to the other specs.
I'll explain why I'm confused and it look like I'm pursuing more than the scope
In the occi system model, the IaaS fits between the PaaS and fabric. Looking at the occi UML it shows the compute resource as aggregated dependency of cluster<ag>>domain<ag>>cloud. The example defines "groups" as racks, pools, data center, etc., real physical assets. Based on the example, I think of clusters as organization of physical compute resources. If the intent was to keep domain and cloud logical elements, it may be better to get rid of the cluster as a class and convert it to a property defining a quality of service for the user. Some may disagree, but I don't believe the user cares if there is a cluster configured for round robin, random distribution, active all or primary/spare failover. I'm assuming they'll care about workload capacity and service availability. (and costs).
Currently cluster<ag>>domain<ag>>cloud looks more like a fabric than a logical components. Fabrics need a different set of capabilities, like events.
-gary
Alexis Richardson wrote:
Gary
Have you seen the interface comparison spreadsheet?
http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
This is our core focus for interop. To achieve commonality right here right now. No invention just interop.
a
On Tue, May 19, 2009 at 9:51 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Well since this is a interoperability interface, I'm assuming there will be gateways to other technologies like fabrics. Events, event delivery and event management are important patterns and are supported by others. I don't believe we'll be able to get away without supporting them for very long. One of the big drawbacks to snmp and cimoms are the lack of event support and an infrastructure to support event message persistence.
I'm also not sure where we are drawing the line in terms of interoperability. There was a general consensus that occi should be focusing on integration points in the cloud, but I didn't see a clear definition of an integration point. (I was out of the loop for a while) In the occi model the platform can be considered a container (loosely, a vm) with infrastructure resources provisioned. The container life cycle and resource provisioning are "management" integration points, although there are no verbs published yet. Will portions of occi interface be permitted to permeate the container boundary ? It is still unclear the level of interaction, if any, between the occi and the container contents. Maybe I missed the definition.
-gary
Alexis Richardson wrote:
Indeed and XMPP and HTTP should not be overlooked either.
On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net <mailto:samj@samj.net>> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com <mailto:alexis.richardson@gmail.com>> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto: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 ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
------------------------------------------------------------------------
That a good point, Gary (can also see how Cluster could be interpreted differently). Might be useful if we list grouping entities on the registry wiki page. Andy -----Original Message----- From: Gary Mazz [mailto:garymazzaferro@gmail.com] Sent: 20 May 2009 10:06 To: Edmonds, AndrewX Cc: Sam Johnston; occi-wg@ogf.org; Roger Menday; Andre Merzky Subject: Re: [occi-wg] Events ? Hi Andy, I think the hierarchy is important. I took issue (confusion) with the "cluster" term and lack of definition for the execution container (vm) where the resources are attached. The names in the hierarchy are arbitrary, but we are probably better off defining a scheme and some basic/standard logical entities like clouds, federations, domains, worlds, applications and services. How they are organized should be up to the user's management scheme. We just need to define a way create and reconcile the hierarchy. -gary Edmonds, AndrewX wrote:
I had a related offline comment by Andre - " Minor comment: the hierarchy you added on top of Compute seems arbitrary (to me). Can that be done generically, e.g. a group entity which has 1:n mapping to itself, and Compute resources?" With that I modified things to be more generic/flexible - see attached.
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Gary Mazz Sent: 20 May 2009 09:14 To: Sam Johnston Cc: occi-wg@ogf.org; Roger Menday Subject: Re: [occi-wg] Events ?
Sam Johnston wrote:
Gary,
The UML doesn't reflect the reality of the AtomPub meta-model, which is in fact far more flexible. I don't care if you call your logical collections "groups", "clusters", "virtual data centers" or "gaggles".
I assumed its more flexible, but I wasn't sure of the terminology and division of responsibilities. The DMTF model included virtual metal like network adapters and HBAs. Others define disk drives and disk files. I don't see any managing QOS for virtual metal. The problem with all this vmetal is it exposes the underlying fabric or a vitalized view of the underlying fabric. ie switches, gateways, routers, paths, storage multipathing, disk arrays and luns. It can be a can o' worms. We still need to figure out how to handle an IP address in one cloud provider on one net segment and migrating to another provider on another net segment.
The categories have terms ("win2k3"), labels ("Windows 2003 Server") and schemes ("http://purl.org/occi/category#os") and the very first category we would be looking to define is of course the resource types (what Google call "kinds") - that is, "compute", "storage", "network" (and according to NIST's draft definition, in future "application" and "service" - though I'm not sure about that).
In part, I'm trying to itemize the terms/properties.
Hierarchical grouping is something to talk about - do we use something like a '/' separator ala /myvdc/myvrack, have pointers to "parent" objects, or something else.
Agreed, I personally would like to see different views of the system. The end user should see /Domain/Federation/Cloud/containers/resources . The cloud provider should see /Cloud/Federation/Domain/containers/resources or /Cloud/Domain/Federation/containers/resources. Privacy laws and business practices may restrict one cloud provider from viewing a domain's other cloud providers and their resources. The roles are also different. The Domain would be interested in a view of its multiple cloud providers. The cloud providers would be interested in the Domains and their utilization.
Ok have a flight to catch to London - see [some of] you there.
Safe trip...
-gary
Sam
On Wed, May 20, 2009 at 5:38 AM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Yes, thanks.. I'm looking at it and using it as a guide to the other specs.
I'll explain why I'm confused and it look like I'm pursuing more than the scope
In the occi system model, the IaaS fits between the PaaS and fabric. Looking at the occi UML it shows the compute resource as aggregated dependency of cluster<ag>>domain<ag>>cloud. The example defines "groups" as racks, pools, data center, etc., real physical assets. Based on the example, I think of clusters as organization of physical compute resources. If the intent was to keep domain and cloud logical elements, it may be better to get rid of the cluster as a class and convert it to a property defining a quality of service for the user. Some may disagree, but I don't believe the user cares if there is a cluster configured for round robin, random distribution, active all or primary/spare failover. I'm assuming they'll care about workload capacity and service availability. (and costs).
Currently cluster<ag>>domain<ag>>cloud looks more like a fabric than a logical components. Fabrics need a different set of capabilities, like events.
-gary
Alexis Richardson wrote:
Gary
Have you seen the interface comparison spreadsheet?
http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
This is our core focus for interop. To achieve commonality right here right now. No invention just interop.
a
On Tue, May 19, 2009 at 9:51 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Well since this is a interoperability interface, I'm assuming there will be gateways to other technologies like fabrics. Events, event delivery and event management are important patterns and are supported by others. I don't believe we'll be able to get away without supporting them for very long. One of the big drawbacks to snmp and cimoms are the lack of event support and an infrastructure to support event message persistence.
I'm also not sure where we are drawing the line in terms of interoperability. There was a general consensus that occi should be focusing on integration points in the cloud, but I didn't see a clear definition of an integration point. (I was out of the loop for a while) In the occi model the platform can be considered a container (loosely, a vm) with infrastructure resources provisioned. The container life cycle and resource provisioning are "management" integration points, although there are no verbs published yet. Will portions of occi interface be permitted to permeate the container boundary ? It is still unclear the level of interaction, if any, between the occi and the container contents. Maybe I missed the definition.
-gary
Alexis Richardson wrote:
Indeed and XMPP and HTTP should not be overlooked either.
On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net <mailto:samj@samj.net>> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com <mailto:alexis.richardson@gmail.com>> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto: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 ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
------------------------------------------------------------------------
------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Actually I'm with Gary on this one... what he said (and what I've said before) is "*How they are organized should be up to the user's management scheme. We just need to define a way create and reconcile the hierarchy.*". For me cloud->domain->cluster makes sense... for a hosting provider/enterprise something like datacenter->cage->rack makes more sense but this falls well into the realm of user preferences... no amount of defining each of the terms will give users the flexibility they need/want and many of them will have existing schemes that they will want to keep. Note that the proposed category scheme caters well for this in that you can have multiple vocabularies (schemes). The first and most obvious one is resource types (what Google call "kinds") including compute, storage and network. Others that we might want to define include things like operating systems (which could also be an enum attribute) and of course customers would be free to define their own. A category looks like this: <category scheme="http://purl.org/occi/cat#os" term="win2k3" label="Windows
2003 Server" />
I had also catered for a user tag space ala: <category scheme="http://example.com/~/" term="myboxen" />
I need to read up on/think about hierarchical category schemes but am also tempted by a rel="parent" linking system. Sam 2009/5/20 Edmonds, AndrewX <andrewx.edmonds@intel.com>
That a good point, Gary (can also see how Cluster could be interpreted differently). Might be useful if we list grouping entities on the registry wiki page.
Andy
-----Original Message----- From: Gary Mazz [mailto:garymazzaferro@gmail.com] Sent: 20 May 2009 10:06 To: Edmonds, AndrewX Cc: Sam Johnston; occi-wg@ogf.org; Roger Menday; Andre Merzky Subject: Re: [occi-wg] Events ?
Hi Andy,
I think the hierarchy is important. I took issue (confusion) with the "cluster" term and lack of definition for the execution container (vm) where the resources are attached. The names in the hierarchy are arbitrary, but we are probably better off defining a scheme and some basic/standard logical entities like clouds, federations, domains, worlds, applications and services. How they are organized should be up to the user's management scheme. We just need to define a way create and reconcile the hierarchy.
-gary
Edmonds, AndrewX wrote:
I had a related offline comment by Andre - " Minor comment: the hierarchy you added on top of Compute seems arbitrary (to me). Can that be done generically, e.g. a group entity which has 1:n mapping to itself, and Compute resources?" With that I modified things to be more generic/flexible - see attached.
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Gary Mazz Sent: 20 May 2009 09:14 To: Sam Johnston Cc: occi-wg@ogf.org; Roger Menday Subject: Re: [occi-wg] Events ?
Sam Johnston wrote:
Gary,
The UML doesn't reflect the reality of the AtomPub meta-model, which is in fact far more flexible. I don't care if you call your logical collections "groups", "clusters", "virtual data centers" or "gaggles".
I assumed its more flexible, but I wasn't sure of the terminology and division of responsibilities. The DMTF model included virtual metal like network adapters and HBAs. Others define disk drives and disk files. I don't see any managing QOS for virtual metal. The problem with all this vmetal is it exposes the underlying fabric or a vitalized view of the underlying fabric. ie switches, gateways, routers, paths, storage multipathing, disk arrays and luns. It can be a can o' worms. We still need to figure out how to handle an IP address in one cloud provider on one net segment and migrating to another provider on another net segment.
The categories have terms ("win2k3"), labels ("Windows 2003 Server") and schemes ("http://purl.org/occi/category#os") and the very first category we would be looking to define is of course the resource types (what Google call "kinds") - that is, "compute", "storage", "network" (and according to NIST's draft definition, in future "application" and "service" - though I'm not sure about that).
In part, I'm trying to itemize the terms/properties.
Hierarchical grouping is something to talk about - do we use something like a '/' separator ala /myvdc/myvrack, have pointers to "parent" objects, or something else.
Agreed, I personally would like to see different views of the system. The end user should see /Domain/Federation/Cloud/containers/resources . The cloud provider should see /Cloud/Federation/Domain/containers/resources or /Cloud/Domain/Federation/containers/resources. Privacy laws and business practices may restrict one cloud provider from viewing a domain's other cloud providers and their resources. The roles are also different. The Domain would be interested in a view of its multiple cloud providers. The cloud providers would be interested in the Domains and their utilization.
Ok have a flight to catch to London - see [some of] you there.
Safe trip...
-gary
Sam
On Wed, May 20, 2009 at 5:38 AM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Yes, thanks.. I'm looking at it and using it as a guide to the other specs.
I'll explain why I'm confused and it look like I'm pursuing more than the scope
In the occi system model, the IaaS fits between the PaaS and fabric. Looking at the occi UML it shows the compute resource as aggregated dependency of cluster<ag>>domain<ag>>cloud. The example defines "groups" as racks, pools, data center, etc., real physical assets. Based on the example, I think of clusters as organization of physical compute resources. If the intent was to keep domain and cloud logical elements, it may be better to get rid of the cluster as a class and convert it to a property defining a quality of service for the user. Some may disagree, but I don't believe the user cares if there is a cluster configured for round robin, random distribution, active all or primary/spare failover. I'm assuming they'll care about workload capacity and service availability. (and costs).
Currently cluster<ag>>domain<ag>>cloud looks more like a fabric than a logical components. Fabrics need a different set of capabilities, like events.
-gary
Alexis Richardson wrote:
Gary
Have you seen the interface comparison spreadsheet?
http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
This is our core focus for interop. To achieve commonality right here right now. No invention just interop.
a
On Tue, May 19, 2009 at 9:51 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Well since this is a interoperability interface, I'm assuming there will be gateways to other technologies like fabrics. Events, event delivery and event management are important patterns and are supported by others. I don't believe we'll be able to get away without supporting them for very long. One of the big drawbacks to snmp and cimoms are the lack of event support and an infrastructure to support event message persistence.
I'm also not sure where we are drawing the line in terms of interoperability. There was a general consensus that occi should be focusing on integration points in the cloud, but I didn't see a clear definition of an integration point. (I was out of the loop for a while) In the occi model the platform can be considered a container (loosely, a vm) with infrastructure resources provisioned. The container life cycle and resource provisioning are "management" integration points, although there are no verbs published yet. Will portions of occi interface be permitted to permeate the container boundary ? It is still unclear the level of interaction, if any, between the occi and the container contents. Maybe I missed the definition.
-gary
Alexis Richardson wrote:
Indeed and XMPP and HTTP should not be overlooked either.
On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj@samj.net <mailto:samj@samj.net>> wrote:
On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson <alexis.richardson@gmail.com <mailto:alexis.richardson@gmail.com>> wrote:
Interesting point.
Speaking as someone who is professionally involved in messaging and events my STRONG advice would be to completely leave them for now. Implementation of the planned draft will naturally bring up use cases suited to the various eventing technologies and protocols, none of which are fully baked by the way. This will be good fodder for future work but currently is **** not in scope ****.
Agreed, and I don't know AMQP well enough to say how it could fit here.
The use case we need to take away from it is that OCCI messages aren't necessarily going to be ephemeral - they may well be long lived, queued, serialised, saved to file, etc.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto: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 ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
------------------------------------------------------------------------
------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
+1 -g Sam Johnston wrote:
Actually I'm with Gary on this one... what he said (and what I've said before) is "/How they are organized should be up to the user's management scheme. We just need to define a way create and reconcile the hierarchy./". For me cloud->domain->cluster makes sense... for a hosting provider/enterprise something like datacenter->cage->rack makes more sense but this falls well into the realm of user preferences... no amount of defining each of the terms will give users the flexibility they need/want and many of them will have existing schemes that they will want to keep.
Note that the proposed category scheme caters well for this in that you can have multiple vocabularies (schemes). The first and most obvious one is resource types (what Google call "kinds") including compute, storage and network. Others that we might want to define include things like operating systems (which could also be an enum attribute) and of course customers would be free to define their own. A category looks like this:
<category scheme="http://purl.org/occi/cat#os" term="win2k3" label="Windows 2003 Server" />
I had also catered for a user tag space ala:
<category scheme="http://example.com/~/ <http://example.com/%7E/>" term="myboxen" />
I need to read up on/think about hierarchical category schemes but am also tempted by a rel="parent" linking system.
Sam
2009/5/20 Edmonds, AndrewX <andrewx.edmonds@intel.com <mailto:andrewx.edmonds@intel.com>>
That a good point, Gary (can also see how Cluster could be interpreted differently). Might be useful if we list grouping entities on the registry wiki page.
Andy
-----Original Message----- From: Gary Mazz [mailto:garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>] Sent: 20 May 2009 10:06 To: Edmonds, AndrewX Cc: Sam Johnston; occi-wg@ogf.org <mailto:occi-wg@ogf.org>; Roger Menday; Andre Merzky Subject: Re: [occi-wg] Events ?
Hi Andy,
I think the hierarchy is important. I took issue (confusion) with the "cluster" term and lack of definition for the execution container (vm) where the resources are attached. The names in the hierarchy are arbitrary, but we are probably better off defining a scheme and some basic/standard logical entities like clouds, federations, domains, worlds, applications and services. How they are organized should be up to the user's management scheme. We just need to define a way create and reconcile the hierarchy.
-gary
Edmonds, AndrewX wrote: > I had a related offline comment by Andre - " Minor comment: the hierarchy you added on top of Compute seems arbitrary (to me). Can that be done generically, e.g. a group entity which has 1:n mapping to itself, and Compute resources?" > With that I modified things to be more generic/flexible - see attached. > > Andy > > -----Original Message----- > From: occi-wg-bounces@ogf.org <mailto:occi-wg-bounces@ogf.org> [mailto:occi-wg-bounces@ogf.org <mailto:occi-wg-bounces@ogf.org>] On Behalf Of Gary Mazz > Sent: 20 May 2009 09:14 > To: Sam Johnston > Cc: occi-wg@ogf.org <mailto:occi-wg@ogf.org>; Roger Menday > Subject: Re: [occi-wg] Events ? > > > Sam Johnston wrote: > >> Gary, >> >> The UML doesn't reflect the reality of the AtomPub meta-model, which >> is in fact far more flexible. I don't care if you call your logical >> collections "groups", "clusters", "virtual data centers" or "gaggles". >> > I assumed its more flexible, but I wasn't sure of the terminology and > division of responsibilities. The DMTF model included virtual metal like > network adapters and HBAs. Others define disk drives and disk files. I > don't see any managing QOS for virtual metal. The problem with all this > vmetal is it exposes the underlying fabric or a vitalized view of the > underlying fabric. ie switches, gateways, routers, paths, storage > multipathing, disk arrays and luns. It can be a can o' worms. We still > need to figure out how to handle an IP address in one cloud provider on > one net segment and migrating to another provider on another net segment. > >> The categories have terms ("win2k3"), labels ("Windows 2003 Server") >> and schemes ("http://purl.org/occi/category#os") and the very first >> category we would be looking to define is of course the resource types >> (what Google call "kinds") - that is, "compute", "storage", "network" >> (and according to NIST's draft definition, in future "application" and >> "service" - though I'm not sure about that). >> > In part, I'm trying to itemize the terms/properties. > >> Hierarchical grouping is something to talk about - do we use something >> like a '/' separator ala /myvdc/myvrack, have pointers to "parent" >> objects, or something else. >> > Agreed, I personally would like to see different views of the system. > The end user should see /Domain/Federation/Cloud/containers/resources . > The cloud provider should see > /Cloud/Federation/Domain/containers/resources or > /Cloud/Domain/Federation/containers/resources. Privacy laws and business > practices may restrict one cloud provider from viewing a domain's other > cloud providers and their resources. The roles are also different. The > Domain would be interested in a view of its multiple cloud providers. > The cloud providers would be interested in the Domains and their > utilization. > >> Ok have a flight to catch to London - see [some of] you there. >> > Safe trip... > > -gary > >> Sam >> >> On Wed, May 20, 2009 at 5:38 AM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com> >> <mailto:garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>>> wrote: >> >> Yes, thanks.. I'm looking at it and using it as a guide to the >> other specs. >> >> I'll explain why I'm confused and it look like I'm pursuing more >> than the scope >> >> In the occi system model, the IaaS fits between the PaaS and >> fabric. Looking at the occi UML it shows the compute resource as >> aggregated dependency of cluster<ag>>domain<ag>>cloud. The >> example defines "groups" as racks, pools, data center, etc., real >> physical assets. Based on the example, I think of clusters as >> organization of physical compute resources. If the intent was to >> keep domain and cloud logical elements, it may be better to get >> rid of the cluster as a class and convert it to a property >> defining a quality of service for the user. Some may disagree, but >> I don't believe the user cares if there is a cluster configured >> for round robin, random distribution, active all or primary/spare >> failover. I'm assuming they'll care about workload capacity and >> service availability. (and costs). >> >> Currently cluster<ag>>domain<ag>>cloud looks more like a fabric >> than a logical components. Fabrics need a different set of >> capabilities, like events. >> >> -gary >> >> >> Alexis Richardson wrote: >> >> Gary >> >> Have you seen the interface comparison spreadsheet? >> >> http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ >> >> This is our core focus for interop. To achieve commonality >> right here >> right now. No invention just interop. >> >> a >> >> >> On Tue, May 19, 2009 at 9:51 PM, Gary Mazz >> <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com> <mailto:garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>>> >> wrote: >> >> >> Well since this is a interoperability interface, I'm >> assuming there will be >> gateways to other technologies like fabrics. Events, event >> delivery and >> event management are important patterns and are supported >> by others. I >> don't believe we'll be able to get away without supporting >> them for very >> long. One of the big drawbacks to snmp and cimoms are the >> lack of event >> support and an infrastructure to support event message >> persistence. >> >> I'm also not sure where we are drawing the line in terms of >> interoperability. There was a general consensus that occi >> should be focusing >> on integration points in the cloud, but I didn't see a >> clear definition of >> an integration point. (I was out of the loop for a while) >> In the occi model >> the platform can be considered a container (loosely, a vm) >> with >> infrastructure resources provisioned. The container life >> cycle and resource >> provisioning are "management" integration points, although >> there are no >> verbs published yet. >> Will portions of occi interface be permitted to permeate >> the container >> boundary ? It is still unclear the level of interaction, >> if any, between >> the occi and the container contents. Maybe I missed the >> definition. >> >> -gary >> >> >> >> >> >> Alexis Richardson wrote: >> >> >> Indeed and XMPP and HTTP should not be overlooked either. >> >> >> On Tue, May 19, 2009 at 7:49 PM, Sam Johnston >> <samj@samj.net <mailto:samj@samj.net> <mailto:samj@samj.net <mailto:samj@samj.net>>> wrote: >> >> >> >> On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson >> <alexis.richardson@gmail.com <mailto:alexis.richardson@gmail.com> >> <mailto:alexis.richardson@gmail.com <mailto:alexis.richardson@gmail.com>>> wrote: >> >> >> >> Interesting point. >> >> Speaking as someone who is professionally >> involved in messaging and >> events my STRONG advice would be to completely >> leave them for now. >> Implementation of the planned draft will >> naturally bring up use cases >> suited to the various eventing technologies >> and protocols, none of >> which are fully baked by the way. This will >> be good fodder for future >> work but currently is **** not in scope ****. >> >> >> >> Agreed, and I don't know AMQP well enough to say >> how it could fit here. >> >> The use case we need to take away from it is that >> OCCI messages aren't >> necessarily going to be ephemeral - they may well >> be long lived, queued, >> serialised, saved to file, etc. >> >> Sam >> >> >> >> >> >> _______________________________________________ >> occi-wg mailing list >> occi-wg@ogf.org <mailto:occi-wg@ogf.org> <mailto:occi-wg@ogf.org <mailto:occi-wg@ogf.org>> >> http://www.ogf.org/mailman/listinfo/occi-wg >> >> >> >> >> >> >> >> >> >> >> >> > > _______________________________________________ > occi-wg mailing list > occi-wg@ogf.org <mailto:occi-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/occi-wg > ------------------------------------------------------------- > Intel Ireland Limited (Branch) > Collinstown Industrial Park, Leixlip, County Kildare, Ireland > Registered Number: E902934 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > ------------------------------------------------------------------------ >
------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
participants (5)
-
Alexis Richardson -
Edmonds, AndrewX -
Gary Mazz -
Roger Menday -
Sam Johnston