On 04/02/2012 10:59 AM, Matt Wagner wrote:
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.
It's much the same with Role names. We went from English strings in the
db to translation keys in the db, but once we add back the role
management UI (where roles can be created/edited/deleted), we'll need to
allow users to either add translation keys _or_ plain text in their
language of choice. _if_ we add a 'provider type' management UI we may
need the same here.
> 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.
That was my initial thought as well. This came up in response to the
difficulty in adding new provider types that _are_ supported by Factory
and Deltacloud (but not Conductor right now) -- I had a somewhat simpler
thought to get at the same thing, though (see below)
> == 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.
I actually proposed adding enabled/disabled (and an enabled/disable API)
as an alternative to a full CRUD API for Provider Types. The issue is we
ripped out all the other provider types that are supported by Deltacloud
and Factory but were not supported by Conductor as a product. My
suggestion was that we load in all provider types in seeds.rb that are
known to work (even without product support) but that non-supported ones
are disabled by default. The provider types UI could provide
enable/disable functionality to add rackspace, etc. for users that
wanted it.
> ** 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
BTW the whole 'list of values', etc. for X-deltacloud-provider isnt
part
of this RFC -- I mentioned it to Jay as something he'd need to handle in
a Provider Types API since it's already on the roadmap (somewhere?) to
add this enhancement to the 'new provider' UI
Scott