Ontology Questions

[Pat Wendorf]

This is an excerpt from a conversation Ruv and I were having with Michael, I'll post it here so everyone can benefit:

>>>>> "Pat" == Pat Wendorf <p...@enomaly.com> writes:
   Pat> Beyond viewing the Ontology there's not much you can do.  The
   Pat> document is meant to show what exactly we'll be representing in
   Pat> UCI, like when we make a call to return the state of Amazon EC2
   Pat> or Google App Engine, what kind of data will be returned.  It
   Pat> also doesn't specify what exactly the data will look like in
   Pat> the user interface.  UCI is meant to be a control and
   Pat> representational system, right now we're focusing on the
   Pat> representational part.

   Pat> Where we need help is figuring out if the document fully
   Pat> describes everything that can be done with the current
   Pat> generation of cloud providers.  Filling in these details in the
   Pat> document, in a common language is the key to the success of the
   Pat> project.

 Yeah, so I'm potentially a cloud *provider* in my role at SIMtone.
 I also sold VMs for awhile as cooperix.net, but I am not capitalized
to compete these days... we started in 2004, when nobody was doing it.
   (I'm looking for additional roles to play in other places... I come
    from a consulting background, and aim to return there by the end of the
    year. I come from the IETF space... author rfc4025, 5386..)

 I look at the subclass explorer and I see things.
 I think that an
     "Application_Container" is something like google/azure provide.
     I think that this should be in the comment?

Yes, that was our thinking, Application_Container is used to describe the features of a Platform Cloud like Google App Engine.  The details under this tree are very sparse at this point, as this is not our area of expertise, I was hoping someone could come in and fill this a little better.

     "VM Container" is obviously VMware, XEN, Hyper-V.
     Under physical storage... I think "File Storage" means NFS/CIFS.
     Maybe that should be subclasses?

That's the plan, we have one of our developers merging the details of the base.owl file, which much better represents this level of detail, with cloud.owl (which allows more "stuff" to be represented).
 

 A real, practical thing about moving a Guest Machine from a provider
(say, me!) that is running classic XEN 3.x with a self-patched 2.6.16 or
2.6.18 PV guest kernel to 2.6.26 "native" paravirt, is that the
partitions were "raw" before (i.e. "sda4" <-> /dev/VolGroup00/Guest1Home)
while they mostly insist on putting partition tables in them now.
 Is this the kind of thing that needs to be expressed here?

Assuming the machine is PV, absolutely.  Looking at the doc now, I don't see how we would express this (in classes or properties), so this kind of configuration should be broken into component pieces and represented in the tree.
 

 I also do not see anything about network interfaces under
"VM_Container", nor do I see how I might explain that I need three guest
machines connected with a virtual switch.
 Does this kind of thing fit in?

I think the networking component is one level above the VM_Container, it's possible that the switch a VM connects to could be referenced with a property.  That's a pretty easy one to add in.
 

 Am I right that this ontology is supposed to describe a set of data
(be a kind of "schema") which I will map my real-life data into?

Yes, exactly right.
 

- --

]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSaW5LoCLcPvd0N1lAQIyUQ

gAwkhnoYr2FOJnm4/MyEX6zSxgNpek/NnS
WR8gZroOUdF7YO+80jgywKFqyAnHDZCQwK4laWFkG+ZGI7cjlD8uOYXYOLeuAl34
tXxRY+ydcBUM0fy/3MXnNcm80U2uwob5wDTteE5u6RGXl6c1i3PhFEf4z7FBbpgL
B+sbXqN90XdLo9tI6eGF62RLv6sH9VrdbFkNzipfnHdhoUesxiwR3L8yMQbXHzW2
e8RrUPlPtPTHuPQtwI4VhRnAwNqfnBhuevNsMFY7nd8gtUct/qrPUt6oxjMgTTry
bL/zWU2oVIIzbS1Bj01zqrXbj5//SabaOWnTI4kkNCAVBaZtYzKWAg==
=DScN
-----END PGP SIGNATURE-----