deltacloud-devel December 2009

deltacloud-devel@lists.fedorahosted.org

11 participants
9 discussions

request for enhancement - injection of files on instance creation
by Michael Neale 18 Feb '11

18 Feb '11

Hi All. Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)? (this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout). -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com

12 33

[PATCH] OpenNebula driver
by Daniel Molina Aranda 19 Jan '10

19 Jan '10

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

2 1

HW profiles vs. portal
by David Lutterkort 23 Dec '09

23 Dec '09

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.ht… [2] to make things easier for users, we should probably express that in the API as 'optional base HWP + modifications to it'

2 2

OpenNebula driver
by Daniel Molina Aranda 16 Dec '09

16 Dec '09

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

3 3

Repository merging complete
by Bob McWhirter 16 Dec '09

16 Dec '09

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

2 1

Website + RimuHosting
by Ivan Meredith 08 Dec '09

08 Dec '09

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

3 2

testing kits?
by Michael Neale 01 Dec '09

01 Dec '09

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

1 0

Repository Merging
by Bob McWhirter 01 Dec '09

01 Dec '09

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

2 2

Driver instance states
by Bob McWhirter 01 Dec '09

01 Dec '09

Howdy-- It's a non-functional change, unless you're a driver author, but I've created a more literate way to specify the states and transitions an instance might go through. http://github.com/bobmcwhirter/deltacloud-merge/blob/master/server/lib/delt… Looks like: pending.to( :running ) .automatically pending.to( :stopped ) .on( :stop ) The .xml representation is unchanged, as is the client that consumes it. This purely makes writing drivers a tad easier. Also, I've wired up GraphViz for generating pretty pictures from the state information: http://skitch.com/bobmcwhirter/njtta/deltacloud-foundation Does Fedora include the dot executable normally? -Bob

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

deltacloud-devel December 2009