gmane.comp.lib.deltacloud.devel

Model X

Jason Guiditta — 2012-02-10T20:00:01

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

JIRA DTACLOUD-127 - Valid Credentials Errors

Martyn Taylor — 2012-02-06T17:54:19

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 handl

Deltacloud Android App

Martyn Taylor — 2012-02-02T14:46:18

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

Android Deltacloud App

Martyn Taylor — 2011-11-30T13:01:53

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

Can I run deltacloudd server in a differentphysical machine?

Nodir Kodirov — 2011-11-07T02:42:04

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

Re: aeolus-configure -p rhevm is not working in latest rpms from testing

Mike Orazi — 2011-11-03T15:35:01

Richard,

I've assigned the BZ to you for triage.  It looks like it might be a 
yaml issue, but ???

Thanks for the heads up,
Mike
_______________________________________________
deltacloud-devel mailing list
deltacloud-devel< at >lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/deltacloud-devel

aeolus-configure -p rhevm is not working inlatest rpms from testing

wes hayutin — 2011-11-03T15:00:01

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

Conductor Image Management API

Martyn Taylor — 2011-09-14T17:10:43

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 a

Re: Condor Cloud Driver

Ian Main — 2011-07-13T17:03:14

[ CC'd incubator list - DOH! ]

On Mon, Jul 11, 2011 at 03:41:06PM -0700, David Lutterkort wrote:

OK, I will start on these today.  Thanks!

    Ian

Re: Condor Cloud Driver

David Lutterkort — 2011-07-11T22:41:06

Very cool.

I completely agree that this should be merged into deltacloud proper.
Some notes from looking at the code:

      * Remove 'Copyright ...' from all source files (have a look at the
        other drives for proper headers)
      * There's some trailing whitespace trouble
      * condor_driver.rb:58: Don't set CONDOR_MAPPER_DIR to something
        that's relative to File::dirname(__FILE__) - instead write
        to /var/tmp (we really ought to claim /var/lib/deltacloud for
        things like this)
      * condor_driver.rb (create_instance): I find encoding
        config_server IP and uuid very ugly. Could the config_server IP
        become part of the config of condor-cloud ? Could we use the
        API_PROVIDER for this ? The uuid could be passed in as the
        user_name of the instance. The comment explaining what's
        happening with user_data also doesn't match the code
      * condor_driver.rb (valid_credentials?): something a little less
        hardcoded would be nice ;)

Re: Condor Cloud Driver

Ian Main — 2011-07-11T20:17:18

Well one thing at a time I think.  I think getting this into deltacloud
is the next logical step since it is very tightly coupled to deltacloud.
Getting it into the codebase will allow it to be more easily installed.

Once that happens I'll see about spreading the word a bit more.

    Ian

Re: Condor Cloud Driver

Lans Carstensen — 2011-07-10T01:37:52

Thank you for your work on this, this looks interesting.  The Condor 
grid community will likely find this interesting as a way to enable 
private cloud services on existing compute grids - but you should let 
them know by sending something to condor-users and/or condor-devel.

What's the status on committing the aeolus-condor patches upstream?  I 
think you'd need to provide pointers in DEVELOPERS.txt on how to pull 
from Condor's upstream instead of pulling from aeolus's yum repo before 
you send that community an announcement.

Along the same vein, this seems like it might be a good candidate for a 
contributed module to Condor:

https://condor-wiki.cs.wisc.edu/index.cgi/wiki?p=ContribModules

Has that been considered?  Doing so would increase exposure within the 
Condor community, who would presumeably be the primary user of this project.

Condor Cloud Driver

Ian Main — 2011-07-08T20:06:44

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

CLI - Formal XML Definition

Martyn Taylor — 2011-06-07T10:24:44

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

Mart

Re: e2e failing w/rhevm 2.2

Martyn Taylor — 2011-05-23T13:35:56

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-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
To: "Martyn Taylor" <mtaylor-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Cc: "Chris Lalancette" <clalance-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>, "Michael Orazi" <morazi-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
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:

It is hard to say if this is the exact problem.

The problem I still know about is that condor generates instance names like:

Condor_localhost.localdomain_job#12.0 (or s

Re: Post Installation: New HWP Model

wes hayutin — 2011-03-14T17:00:29

That is a good sign that the form we use to start an instance may not be
as user friendly as we would like it to be. Any chance we can add some
javascript validation on that form.

Post Installation: New HWP Model

Martyn Taylor — 2011-03-14T16:16:17

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

Re: request for enhancement - injection of fileson instance creation

Thomas von Steiger — 2011-02-17T23:51:54


What can i do with new vm's in a cloud without discover them and get more configuration to the vm.
If we install a new system from a template we need to do always some steps like install something else to bring up services or put puppet there to bring up services later.
With one injection like firstboot or postcommand, everything is possible then.
Put, for example "firstboot" has always a dependencies to a guest operating system, in which style firstboot is running.
On the other hand, the most cloud providers have the "same/a" range of supported operating systems.

Thomas

Timeout support in deltacloud-client

Matt Wagner — 2011-02-17T19:32:49

Hi all,

I want to propose adding timeout capabilities to deltacloud-client. I'm 
seeing problems in Aeolus Conductor where a non-responding provider will 
hang indefinitely until Apache closes the connection. I think the fix is 
to allow deltacloud-client to raise an exception on timeouts instead of 
trying to do so each place Conductor calls out to a provider. (A good 
demonstration of this problem is to attempt to add a provider like 
'http://1.1.1.1:1234/api'.)

rest-client has support for two types of timeout: an 'open_timeout' when 
opening a connection, and a normal 'timeout' for an active connection: 
http://rdoc.info/github/adamwiggins/rest-client/master/RestClient/Resource

I will send a quick patch that adds these two timeouts to the 'request' 
method. I don't know the deltacloud-client code that well, so I'd 
appreciate it if someone could let me know if there is a better way of 
accomplishing this.

Best,
Matt

Re: Task #197 - Remove any logic forcing one provider only

Chris Lalancette — 2011-01-27T15:50:51

Please send new patches to aeolus-devel-TuqUDEhatI4ANWPb/1PvSmm0pvjS0E/A< at >public.gmane.org

Thanks,

[PATCH aeolus 5/6] Cucumber tests for Provideraccounts

2011-01-27T15:37:53

From: Jozef Zigmund <jzigmund-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>

I fixed all Rspecs and Cucumbers for provider_account model. Also I fixed some forgotten renamings.
It was needed change some attributes in migrations.
---
 .../admin/provider_accounts_controller.rb          |   53 ++++++------
 .../controllers/provider_accounts_controller.rb    |   62 +++++++-------
 src/app/models/image.rb                            |    2 +-
 src/app/models/provider.rb                         |   11 ++-
 src/app/models/provider_account.rb                 |    8 +-
 src/app/views/admin/provider_accounts/_mock.haml   |   16 ++++
 .../provider_accounts/_provider_selection.haml     |    2 +-
 src/app/views/admin/provider_accounts/new.haml     |    3 +-
 src/app/views/admin/providers/_form.haml           |    2 +-
 src/app/views/builds/new.haml                      |    6 +-
 src/db/development_structure.sql                   |   89 ++++++++++++++++++++
 ...824_rename_cloud_account_to_provider_account.rb |    3 +-
 ...737_