On Fri, Mar 30, 2012 at 01:24:43PM -0400, Jason Guiditta wrote:
Copy of wiki page below, actual page here:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Feature_Add_Ne...
== Summary ==
Provide a simpler way for the community/sysadmins to add and test new
provider types.
== Owner ==
TBD, initial write-up by jayg
== Current status ==
* Targeted release: TBD
* Last update: See wiki history
== Screencast Demo ==
None at this time
== Implementation tasks ==
TBD
== Detailed description ==
The first example of this is openstack, which may already be
integrated by the time this feature is done. Deltacloud already has
(theoretical) openstack/rackspace support. Factory can build for
Rackspace, and Openstack will require some tweaks/testing to get it
working correctly (see [[Implementing_OpenStack_support|here]] for
detail). In order for a community member to attempt to contribute
support for Openstack in Aeolus, they currently need to jump through a
number of hoops to even see if deltacloud and factory will 'just work'
for this case. At a minimum, a contributor would need to edit:
* src/app/controllers/providers_controller.rb
* src/config/locales/en.yml
* src/db/seeds.rb
I don't understand the purpose of the code in ProvidersController that
limits the providers we support. Is there any reason we can't just rip
that out?
I wonder how we can make this work with internationalization. Currently
the field names get translated. It seems weird that we'd have some in
en.yml and some in the database. Although that does seem limiting.
In addition, they need to install the proper deltacloud driver and
make any config needed for factory. These latter 2 are not in scope
for this feature, other than as cross-project documentation efforts
I think there's value in being the simplest component here, but this
does make me realize that, even if we make this super-easy, users are
still going to have to pull in updates for the other projects to get
support for new providers, which makes me wonder just how much value we
can really add by adding an API for this.
== High-level implementation details ==
I propose we add an API for adding provider types. This would entail:
* New controller and/or actions to add provider type CRUD support
* Changes to model to support any dynamic fields needed for a user of
* the conductor to be able to properly add a new provider of this type
* (perhaps this already exists as part of the add provider/account api
* feature * changes to UI to allow a new provider to be added based
on any that
* have provider types in the db
** TBD - keep/enhance the current 'enable/disable' concept? If so, we
would need UI at some point to enable any preseeded providers that are
not fully tested/supported. First pass might just allow this to be
done via API.
Right now it's just Providers, not ProviderTypes, that can be
enabled/disabled, right? I'm not sure that we need to allow disabling a
ProviderType, as much as just not adding ones that don't work yet,
especially if we can make it easy to add new ones over an API.
** X-deltacloud-provider field (and we'll want more customization
on
the way -- dropdown for ec2 regions with stuff pulled from deltacloud;
2-step entry for RHEV with "datacenter-free" top level provider URL
provided; then deltacloud ives us a list of provider URLs including
cluster UUID, etc.) -suggested by sseago
Yes! We can make this much easier for users. Right now it kind of
requires that they enter a "magic string" that's not very
well-documented. Where we can retrieve a list of possible values, that
would be fantastic.
-- Matt