[Capi-bof] Charter for Open Cloud Computing Interface (OCCI) Working Group

[Sam Johnston]

On Wed, Mar 25, 2009 at 5:03 PM, Michael Richardson <mcr at sandelman.ca>wrote:

>
> is the management of the containers in scope?
> I'm surprised here, or am I mis-understanding?
>

I hope it's the latter... but I can see where the confusion is coming from.
How about s/and/running in/ ala:

"The scope of the specification will be all high level functionality
required for the life-cycle management of workloads (e.g. virtual machines)
running in containers (e.g. hypervisors) supporting service elasticity."

We're not talking about managing hypervisors here, except for basic
primatives like start/stop/restart.

Is it in scope for me to indicate that my collection of virtual machines
> all having an interface named "McrPrivate" should be connected together
> into a LAN, and that interfaces marked "Internet" should be connected to
> the outside?
>

Per my initial suggestion this would be implicit - the special tag
"internet" would have special meaning and other tags would just be strapped
together. Which is not to say it has to work like this - maybe a better
approach will surface from the existing APIs?


> > Reference implementation(s) are specifically excluded, as are details
> > relating to supporting infrastructure (such as storage and network
> hardware
> > configuration).
>
> Does this mean that the API will not permit me to specify what
> "hardware" MAC address should be used on the private network interfaces
> that I configure?
> (I understand that it won't let me specify IP address, and I don't want
> it to)
>

That depends - do you consider that a requirement? Remember that things like
MAC address are typically specified already within the container format
(e.g. OVF) but things like IP are set at runtime... so it's actually the
latter rather than the former that would likely want to be configured via
OCCI.

Is an attribute based system (with defined attributes for common
requirements) enough do you think or do you see us burning this type of
information into function calls?

Sam


> - --
> ]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr at 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.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBScpNpYCLcPvd0N1lAQJCBQf/Rz92gGHkgovkmc5srJH2TQmaZ02rkRf8
> miNcJ/cDJg5O9KLFgNpj+iZY0ERV4wuuQPtPDA/2luxisJ8j6de2GuL7aHL20y3i
> ZxHl9kQ2eQbZKmAl/8nb/3yondAIj/rzpAzJp+VYdwsOT22mq2+ZrLhahMa+9ZIL
> Y1YAJHh1WR1J1kyj54uwNhd25VQLYgxamho5x+mCchMKNWJ23UxdAd4hlTELVZru
> vZWQvXnBK7JkE4r+f3wjmgzNPwODmY/BPOaho4+wDpAi9VXI8PXU3dDE2pRvG+g+
> 0d2bg1l/SlNIxIaNHUyJ4lNlw93iWTpMzlom7mhjcYNiVm+anifXcw==
> =2IxL
> -----END PGP SIGNATURE-----
> _______________________________________________
> Capi-bof mailing list
> Capi-bof at ogf.org
> http://www.ogf.org/mailman/listinfo/capi-bof
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/capi-bof/attachments/20090325/6802d96a/attachment.html