RFC Feature: Add New Provider Types

Scott Seago sseago at redhat.com
Mon Apr 2 15:25:08 UTC 2012


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_New_Provider_types
>>
>> ==  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



More information about the aeolus-devel mailing list