In case you didn't hear, Tesla revealed their upcoming model X yesterday, looks pretty nice: http://www.teslamotors.com/modelx -j _______________________________________________ deltacloud-devel mailing list deltacloud-devel <at> lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
Gents Unfortunately you've been away today. I've some issues with the aforementioned JIRA. The commit sent to me by fvollero: https://git-wip-us.apache.org/repos/asf?p=deltacloud.git;a=commit;h=2fbc147f9e3041b19f2c89e4d222ba2185486405 does not solve the JIRA. It only addresses the issue in EC2 Driver. This would suffice for the conductor BZ but this really should be fixed across the board. Another fundamental issue is that the Deltacloud Client (ruby) does not properly support HTTP Errors. We at least need the valid_credentials method to properly handle any HTTP Errors returned by the server. But I think its worth noting though that properly handling errors really needs to implemented across the client as a whole. I've created a patch for conductor addressing the original BZ: https://bugzilla.redhat.com/show_bug.cgi?id=753880 this will fix the BZ once the changes are in the client. I've added some comments to the JIRA explaining the issue with the commit and a suggestion on how to handle http errors. Could you guys let me know how this goes.(Continue reading)
Gentlemen. After speaking to Michal and Justin. It sounds like Deltacloud might be interested in importing the Android App I build for DC into the DC project. You guys are free to take it. It's here: https://github.com/mtaylor/MobileCloudController Just give me a few days to author the code before you pull it. Regards Martyn _______________________________________________ deltacloud-devel mailing list deltacloud-devel <at> lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
Hi people, I wrote a native Deltacloud Android App a while back but didn't get round to sending it out, I thought now is as good of a time as any to get it out there. You can download the app from here: http://martyntaylor.fedorapeople.org/dcdroid.apk Please check it out, there are one or two minor issues atm. But all in all it does the job. Please drop me aline if people have suggestions/bugs etc... I will get round to setting up a Redmine/BZ project soon. One Note: The app uses the older style "one DC Instance per provider" format (Since I wrote the Android client way before the newer format was introduced). Also, I've only tested this on a handful of displays though I written it to be compatible with most (though it might not look so great). Have fun Martyn _______________________________________________ deltacloud-devel mailing list deltacloud-devel <at> lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
Hello all! I have confusion about deltacloudd deployment. I have three cloud deployments. Can I access all of them via single installation of deltacloudd? For example: I have OpenNebula cloud controller in server A, OpenStack cloud controller in server B and Eucalyptus in server C. Can I install deltacloud server in server D and install & run deltacloudc client from server E. If yes, should I install deltacloudd server in each cloud controller server (A, B, C) or is it possible to install single deltacloudd server and run it for all three clouds (with different drivers)? Kind regards, Nodir. _______________________________________________ deltacloud-devel mailing list deltacloud-devel <at> lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
https://bugzilla.redhat.com/show_bug.cgi?id=751113 _______________________________________________ deltacloud-devel mailing list deltacloud-devel <at> lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
In order to lock down components, it has been proposed that we offer an API on top of conductor that exposes
image management functionality (pretty much what is currently offered by aeolus-image command line).
This would mean that any client wanting to manipulate objects would talk directly with conductor and go
through conductor authentication etc... This gives a central point of contact for image related tasks
via the conductor API and also hides the bits and pieces going on in the background, i.e. iwhd and
imagefactory, that really a user is not concerned about.
To recap the state of aeolus-image:
At the moment the rubygem aeolus-image that is used by conductor serves 2 purposes: firstly, it acts as a
client lib to iwhd (which conductor uses in the new catalogue functionality); secondly it holds all the
logic for the CLI.
So as it stands, we need to:
1) Rip out the object model (iwhd client part) of aeolus-image and place it in a new rubygem; this will serve
solely as a client lib rubygem for iwhd and imagefactory called "aeolus-image-resource" (or another
better name)
2) Add imagefactory interaction to the iwhd/imagefactory client lib rubygem - aeolus-image-resource.
This will interface with the new ImageFactory REST API, and will be used to create builds and push images
etc... using the same object model that is currently in place inside aeolus-image, which is used for
interfacing with iwhd. This will also replace code that talks to the imagefactorys qmf interface which is
in the aeolus-image CLI code.
3) Add to the current REST API in conductor, to add in the extra resources we need:
images
builds
target_images
provider_images
This probably just consists of wrapping the aeolus-image-resource calls in the relevant controllers.
(Continue reading)
Howdy Folks, So Michal and I have been working on a Condor based cloud using deltacloud as the front end API. The code base can be found here: http://git.fedorahosted.org/git/?p=condor-cloud.git There are still some cleanups and testing to be done but I would like to get this into Fedora 16 as a feature. I am hoping you guys can take a look and let me know if this is acceptable and what needs to be fixed to make it so. There are actually two parts to this project, one is the deltacloud driver, which can be found under the deltacloud-condor-driver directory. The rest deals with condor configuration and scripts. I'm thinking I may name this project 'falcondor' as it seems unused and more interesting :). Thanks! Ian
Providing a formal deffinition of the XML for an API, makes using the API, in particular creating and maintaining client applications that utilise the API much simpler, and far clearer for a developer. There are an array of tools that provide class generation, and automatic marshalling and unmarshalling of objects, generated straight from a formally defined XML Document, for ruby, this project looks to offer these functions: https://github.com/rubyjedi/soap4r . In my experience writing Java and Android clients, I have found that the time spent creating an XSD or other formal XML definition, repays 10 fold in development time, and also makes keeping clients up to date alot simpler. For DC Client I ended up writing my own: https://github.com/mtaylor/deltacloud-tools/blob/master/DeltaCloudClient/docs/deltacloud.xsd But, I think it would be better as a whole to adopt this approach from the start. It would not only benefit the creation of the CLI but also anyone else who needs to utilise these APIs Martyn
Chris, I have confirmed that entering an Instance name of > 50 characters does indeed cause a: 500 Internal Server Error. So I am going to assume this is the issue. This needs to be addressed both in Condor and in the RHEVM Driver. The Driver should do any validation checks before sending the API request to the BackEnd provider, and thus return an Error message with a more helpful message. Cheers Martyn ----- Original Message ----- From: "Chris Lalancette" <clalance@...> To: "Martyn Taylor" <mtaylor@...> Cc: "Chris Lalancette" <clalance@...>, "Michael Orazi" <morazi@...> Sent: Monday, 23 May, 2011 1:17:04 PM Subject: Re: e2e failing w/rhevm 2.2 On 05/23/11 - 07:38:12AM, Martyn Taylor wrote: > Hi Chris, > > I've been trying this morning to get full e2e working with rhevm 2.2. > > However, I'm still getting: Create_Instance_Failure: 500 Internal Server Error > > You mentioned on Fridays call that there still might be some issues with Condor. Is this now fixed? Could this issue I'm seeing here? >(Continue reading)
Gentlemen, I've noticed a lot of chat around not being able to start instances. For any of you who are not aware, you now *MUST create a HWP post installation (that matches some back end provider HWP) in order to start an instance. Documentation for this is found here: http://www.aeolusproject.org/conductor-use.html
 |
|
|
|
|
|
|
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
RSS Feed3 | |
|---|---|
4 | |
1 | |
5 | |
1 | |
1 | |
2 | |
2 | |
138 | |
269 | |
176 | |
568 | |
553 | |
127 | |
166 | |
318 | |
314 | |
200 | |
339 | |
130 | |
76 | |
31 | |
70 | |
79 | |
30 | |
86 | |
49 |