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
implement.
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
rhevm.json
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
config files.
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/
javascript checking
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
this content
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.
Scott