[PATCH] OpenNebula driver
by Daniel Molina Aranda
Hi,
We have finished a first version of the DeltaCloud driver for OpenNebula
[1]. If you have any problem with it, just let me know.
This is the information necessary to use the driver:
When using the driver for OpenNebula, the credentials passed in response to
the HTTP 401 authentication challenge should be your OpenNebula user and
password.
The address, in which the OCCI server is listening, needs to be defined in
an environment variable called OCCI_URL.
Regards,
[1] http://www.OpenNebula.org/
--
Daniel Molina, Cloud Technology Engineer/Researcher
DSA Research Group: web http://dsa-research.org and blog
http://blog.dsa-research.org
OpenNebula Open Source Toolkit for Cloud Computing:
http://www.OpenNebula.org
14 years, 3 months
HW profiles vs. portal
by David Lutterkort
Hi,
following the recent discussion[1] about HW profiles, I wanted to
outline what I think needs to happen in the dcloud API, and how portal
needs can be accomodated by all this.
Ultimately, everything we do around hardware profiles (HWP) is there to
serve one call: starting an instance in a cloud. As Bob mentioned in his
email, part of the information you submit to start an instance are
constraints on what you want for your instance[2]: 2 GB of memory, or at
least 2GB of memory; place in a specific realm or don't care what realm
etc. Eventually, we'd like to include constraints that aren't directly
connected to HWP's, like scheduling for a specific time or accomodating
EC2's new spot pricing, though that seems more like a v2 feature.
This all gets more interesting when you think about the dcloud portal,
which aggregates several clouds into one, and exposes them as one
metacloud. That has some important implications for how the dcloud API
models realms and HWP's:
* we still want people to start instances in a specific cloud, in
addition to saying 'put it in any cloud'. That means that the
backend clouds become realms in the metacloud, and that realms
are hierarchical, so that the us-east-1a zone in fred's ec2
account becomes something like the realm fred-ec2/us-east-1a
* different realms can have different HWP's; a realm now has a
list of HWP's associated with it
* we still also produce a per-provider list of HWP's; for portal
that will either be the list of all backend HWP's, or some
reflection of pool quotas, or HWP's that an administrator
entered in the portal admin UI (for API purposes, it doesn't
matter, but it's nice that all these different ways of
generating HWP can be accomodated)
In concrete terms, it seems pretty clear how to describe a HWP: each
dimension in a HWP is either a scalar range, with a unit, min and max
bounds and an optional default value, or an enumeration of opaque
strings, so that a HWP is a dictionary that maps the name of the
dimension to a scalar range or an enumeration.
When we report the HWP of a running instance, it would be nice if we
could either report back a fully resolved HWP (i.e., instance uses 2GB
of mem) or a reference to a HWP (i.e., instance uses HWP 7, which sets
memory to between 2GB and 4GB)
David
[1] https://fedorahosted.org/pipermail/deltacloud-devel/2009-November/000288....
[2] to make things easier for users, we should probably express that in
the API as 'optional base HWP + modifications to it'
14 years, 4 months
OpenNebula driver
by Daniel Molina Aranda
Hi,
This email is to announce that during the last weeks we have been working on
a OpenNebula [1] driver implementation based on the OGF OCCI API [2].
OpenNebula provides the first reference implementation of this new cloud
interface specification. The driver is almost finished, so we will
distribute the source in a few days. We would have wanted to get this driver
into the new core repository, but it came faster than we expected.
We usually release code under Apache license. However, I understand that in
Deltacloud, as we did in libvirt with the OpenNebula driver, code must be
contributed under LGPL?
Regards,
[1] http://www.opennebula.org/
[2] http://www.occi-wg.org
--
Daniel Molina, Cloud Technology Engineer/Researcher
DSA Research Group: web http://dsa-research.org and blog
http://blog.dsa-research.org
OpenNebula Open Source Toolkit for Cloud Computing:
http://www.OpenNebula.org
14 years, 4 months
Repository merging complete
by Bob McWhirter
Howdy everyone--
I've successfully merged the histories of
framework.git
driver-ec2.git
driver-rackspace.git
driver-mock.git
driver-rhevm.git
client-ruby.git
Into a single repository of
core.git
Which can be found here:
http://git.fedorahosted.org/git/?p=deltacloud/core.git;a=summary
I've also pulled the RimuHosting driver (thanks to RimuHosting for the
donation) into the core repository.
Please perform a fresh checkout of this core.git repository, and
discard any workspaces you have for other drivers or frameworks.
Please set up an account through Fedora if you need commit access to
the core.git repository to maintain your driver.
Once folks sanity-check it all, I'll ask Fedora to remove/decommission
the no-longer-needed repositories.
The docs.git and portal.git repositories remain untouched.
Thanks,
-Bob
14 years, 4 months
Website + RimuHosting
by Ivan Meredith
I was wondering if we could please get RimuHosting added to a few
parts on the website.. like..
Support for EC2, RHEV-M, RackSpace; VMWare ESX and more coming soon
=>
Support for EC2, RHEV-M, RackSpace; RimuHosting, VMWare ESX and more coming soon
Also link to the driver repository on github on
http://deltacloud.org/contribute.html (Although I know Bob has merged
the driver with the rest, It doesn't seem 'offical' yet? At least not
on the website).
Thanks, Ivan
http://rimuhosting.com
14 years, 5 months
testing kits?
by Michael Neale
Hey all - was thinking, is there some use in having a
test/compatability suite of tests for:
1) framework - use some mock driver, run some standard functional-like
tests (kind of what we have) - not needed *now*, but if providers
decide to implement the ∂-cloud api themselves in future?
2) Some run through to prove each driver (obviously will need to
create real servers etc) ? Ideally as similar as possible for each
driver implementer?
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
14 years, 5 months
Repository Merging
by Bob McWhirter
It was discussed that perhaps we should simplify our repository
layout, and make a mongo repo for -driver, -framework, and maybe -
client-ruby.
I've done a candidate merge with git-filter-branch, preserving history
across all of the repos into a single merged repo.
I've staged it upon my GitHub account:
http://github.com/bobmcwhirter/deltacloud-merge
You can view merged commit history here:
http://github.com/bobmcwhirter/deltacloud-merge/commits/master
If this looks roughly good, I'll finish tidying up (making a top-level
COPYING and a README), adjust the -framework startup code to look for
drivers in the right place.
Then we'll need to figure out where in FedoraHosted we want it to
live. Do we want to get a fresh repo (just plain "deltacloud" ?) and
push there? What's the process for getting a new repo?
After that, we'll want to destroy the old no-longer-relevant repos.
Thoughts, comments and feedback muchly appreciated.
Thanks,
-Bob
14 years, 5 months
