So this is a point that we've talked about in several meetings, on IRC,
etc but haven't really nailed it down as a specific set of tasks to
Right now, in order to add a new provider to Conductor -- say you've
just spun up another RHEV instance on a new host -- there are 3
different places in the Aeolus infrastructure that you've got to
configure with certain information duplicated:
* First you've got to start up a new deltacloud-core instance with the
RHEV provider URL as the default value for X-Deltacloud-Provider
(There's no need to reply here that "deltacloud has supported
multi-provider core for ages -- why isn't conductor using it? -- as that
is _exactly_ what I'm addressing here)
* You've then got to update the rhevm.json (or whatever it's named)
config file with various information about the new RHEV provider
* Finally, the Conductor admin adds a new provider via the Conductor
Provider UI, making sure to point to the newly-created deltacloud-core
server and using a provider name that matches the configuration added
We need to reduce this to _one_ place -- once a new RHEV server is up
and running the Conductor admin should be able to go to the Conductor
Provider UI and configure the provider here with no need to mess with
deltacloud config files (or new deltacloud-core servers) or with factory
The redmine story for this should read something like:
"As an administrator, when bringing up a new private cloud
instance, I can configure the new provider in a single Aeolus location"
There are 2 main "sub-stories"
1) "As an administrator, when bringing up a new private cloud instance,
it is not necessary to launch a new deltacloud-core instance or
configure any existing deltacloud-core instances with details on this
new provider; the 'new provider' UI in Conductor provides everything
needed for an existing deltacloud-core."
2) "As an administrator, when bringing up a new private cloud instance,
it is not necessary to edit the imagefactory config files with details
on this new provider; the 'new provider' UI in Conductor provides
everything needed by imagefactory."
In more detail, I'll consider them separately:
So the first is relatively straightforward -- I'll be starting to
implement it as part of this sprint. The tasks are as follows:
a) add a deltacloud_driver field to the ProviderType model (no UI for
this model -- it's currently loaded in seeds.rb
b) add a deltacloud_provider field to the Provider model
c) in the UI, make 2 changes to the 'new provider' form:
1) validate the provider type -- i.e. for the chosen provider type,
query the given dc core URL and make sure that this core supports this
provider type, initially as part of form validation, eventually w/
2) add a deltacloud_provider field to the form. This is a free-form
textfield, but we could make a future enhancement where for ec2 the user
gets a picklist of supported regions (internally saved as text like for
other provider types)
d) anywhere in conductor that we make deltacloud calls, update the code
to add in these new fields, either as URL params
(http://localhost:3001/api;driver=ec2;provider=us-east-1) or by setting
request headers for X-Deltacloud-Driver and X-Deltacloud-Provider,
whichever is easier
e) same as d) but for condor too
One open question here is whether we should make deltacloud_provider
optional -- i.e. will we let people defer to the prior behavior of
taking the default provider for a given deltacloud-core instance.
For the second sub-story, there are a lot more open issues. The tasks
are as follows:
a) augment the Provider model and UI with whatever fields are needed to
reproduce the contents of the factory config files (rhevm.json, etc)
b) make sure that the providers.xml (or providers.json) API calls
include these in a format that factory is prepared to deal with --
either just like rhevm.json now, or alter factory to deal with the
conductor API format.
c) aeolus-image should be altered to make this API call and pass the xml
(or json) onto factory
d) imagefactory should be altered to accept the providers.json or
providers.xml content and override its local rhevm.json, etc files with
So there you have it. I expect most of the discussion/disagreement to
occur on the second sub-story, but feel free to respond with
comments/corrections/etc for either.
This patch series just does a bunch of cleanup to the imagefactory, found
by code inspection and through the use of pylint. There should be no
functional change after this series, just cleaner code. With these patches in
place tests still pass and a local upload style build still succeeds. Please
review and ACK.
Extending a general invitation to the high availability communities and
other cloud community contributors to participate in a live demo I am
giving on Friday August 5th 8am PST (GMT-7). Demo portion of session is
15 minutes and will be provided first followed by more details of our
approach to high availability.
I will use elluminate to show the demo on my desktop machine. To make
elluminate work, you will need icedtea-web installed on your system
which is not typically installed by default.
You will also need a conference # and bridge code. Please contact me
offlist with your location and I'll provide you with a hopefully toll
free conference # and bridge code.
Bridge Code: Please contact me off list with your location and I'll
respond back with dial-in information.
For those who don't know, I run a nightly builds repository for Deltacloud API.
It means you can install the latest Deltacloud API through yum using:
$ wget http://devel.mifo.sk/deltacloud/deltacloud-core.repo -O /etc/yum.repos.d/deltacloud-git
$ yum clean all
$ yum install deltacloud-core-DRIVER (or yum install deltacloud-core-all)
I have tested it on F14 and F15 and it works with all dependencies. For RHEL, you should
add the EPEL repository and install some packages manually from Fedora.
Michal Fojtik, mfojtik(a)redhat.com
Deltacloud API: http://deltacloud.org
I'm seeing the following errors when I run my specs:
Validation failed: Email should look like an email address
It looks as though the permission factory (permission.rb:8) is attempting to create an admin user which is failing authlogic's email validation.
From tracing it through, factory girl seems to execute the super type definition BEFORE the sub type therefore before u.login 'admin' can be run, the user is created with no login and thus the email is set to "@example.host". Note the empty user name.
1) DeploymentsController should allow RESTful delete of a single deployment
Failure/Error: @admin_permission = Factory :admin_permission
Validation failed: Email should look like an email address.
One thing that has annoyed me for a while about the imagefactory is that the
binary is called "imgfac.py". I think that it is likely to lead to confusion
among developers and users. Therefore, I proposed to Steve that we rename the
binary to "imagefactory", and deal with the fallout. In order to make this
work, we first have to rename the imagefactory directory to imgfac (to avoid
python naming conflicts), and then deal with the fallout in the codebase. The
patch here does that.
The observant among you will notice that there is no actual patch attached.
That is because it is a large patch (~500K), so I decided it would be best not
to spam the list with it. Instead, I have uploaded the patch to:
Full disclosure: I did not exhaustively test this patch. I got it to the point
where the tests pass, and I was able to do a local EC2 upload style build.
Still, I think this is a good start and other issues (if any) will quickly
Here is the proposal for a API feature planned for this iteration.
The general idea is to create a RESTful API for conductor allowing us to
manage all conductor functionality through this API.
Currently we have some xml and json responses implemented in controllers
For the beginning I suggest to use responder object to directly render
XML responses for collections,
lately when we want to stabilize the API we should use XML templates.
Here I propose features and tasks:
=== As a developer I want to have clean controllers.
* Move more code to before filters
* Move more code to models
=== As a developer I want to have full test suite for the API
* Implement all Rspec tests for the API
=== As a user I want to be able to consume xml API
* Add responder object to actions index and show for all controllers
=== As a user I want to be able to modify data through xml API
* Add responder object to actions update and destroy for all
=== As a user I want to have overview of the API
* Implement entry point for the API
* Implement/configure HTTP authentication
Here is the proposal for a Dashboard feature planned for this iteration.
The general idea is to have a two separate dashboards for each section
(Monitor, Administer), as the Overview (Pools#index pretty view) already
works as Dashboard for Monitor section.
It already contains:
* ribbon with basic statistics of Pools, Deployments, Instances, Alerts,
Updates and global Quota overview
* list of latest alerts
* Overview on Pools their status and status of its Deployments and
Instances with direct access to manage them.
* possibility to get to detailed list view with a single click
Pools Overview section also has links to basic operation as launching or
Managing deployments from within its Pool.
Having a separate Dashboard would mean duplicating of this information
unless Pools Overview section would have been redesigned.
Administer section does not have an Overview section so the idea is to
create similar Overview/Dashboard section as the Monitor section has
which resembles it graphically by using slightly changed UI elements
used in Monitor section as we dont have any wireframes or design
guidelines for it.
The main part of proposed Administer section Overview utilizes the Admin
subsections navigation as a table of boxes for each subsection (similar
to Instances display in Deployment detail pretty view) which contains:
* subsection icon
* title - linking to given subsection
* information about elements count or other relevant info (current
* link to most used function for given subsection (create new user, add
suggested deployable, ...)
Subsections: Users, Roles, Providers, Provider Accounts, Hardware
Profiles, Realms, Pool Families, Suggested Deployables, Settings
Based on the amount of data we want to display the box can have
different size (e.g. Settings subsection box section with current
settings summary can use twice as big box than other)
Navigating back from a subsection to Overview can be done via Breadcrumb
leading to it or by clicking the Administer tab. Current controll panel
select should be put in each subsection to provide navigation among
subsections without returning to Overview.
Other relevant info like last 5 items from user related Action History
(similar to Alerts section in Pools Overview) can be included when its
Administer section Overview simplyfies the navigation for administrator
and speeds up the access to most of the tasks he want to perform in
Administer section. It should be relatively easy to implement as the
current UI elements could be used and it doesnt require changes to
application structure or logic.
Having two separate Dashboards or Overviews simplifies the problem with
having to deal with displaying different amount of information based on
Creating Administer section Overview largely depends on Admin section UX
which is about to be discussed.
Features and Tasks:
As an admin I want to have an Overview in Administer section
* prepare UI design and elements for Subsections boxes
* implement Subsection box navigation with subsection info and links
* remove controll panel select
As an admin I want to navigate around Administer section
* Implement Breadcrumbs to navigate from Admin subsection to Overview
* Add Controll panel select to each subsection to enable navigation
among subsections without returning to Overview
As an admin I want to see last 5 events in Action history (depends on
Action history implementation)
* Implement Action history overview based on Pools pretty view Alerts
section with last 5 events and link to Action history page, placed under
Subsections box navigation.