On Wed, 2011-06-08 at 13:04 -0400, Carl Trieloff wrote:
> On 06/08/2011 12:10 PM, Mark McLoughlin wrote:
>> On Wed, 2011-06-08 at 11:20 -0400, Carl Trieloff wrote:
>>> On 06/08/2011 11:11 AM, Mark McLoughlin wrote:
>>>> Hey,
>>>>
>>>> I started looking at this:
>>>>
>>>>
https://www.aeolusproject.org/redmine/issues/1200
>>>> "Use deltacloud api for provider names"
>>>>
>>>> but decided to think through things from a higher level again.
>>>>
>>>> I've a fairly jumbled set of notes below, but I'd summarize my
>>>> conclusions as:
>>>>
>>>> 1) We should move to using a single instance of deltacloud
>>>>
>>>> 2) We should drop current provider management UI in Conductor
>>> Can you be more specific...
>>>
>>> Where will we put setting up services provided by the 'provider'? As
to
>>> point 4, you may not have bought the same services per region, as long
>>> as that is handled.
>> Can you be more specific about what these per-region services are?
>>
>>
> I speak under correction (attributing this to Scott), but I believe
> Scott had indicated that not all zones get features at the same time.
> I've spent a few minutes googling and then also checked with Matt Hick,
> OpenShift who confirms "zones have different capabilities and also
> function differently"
That sounds fine - i.e. that doesn't suggest that a user should have to
re-enter their EC2 credential for each EC2 region they want to use. It
just means that conductor needs to detect what features a region
supports, which it would have to do today anyway if it relied on
region-specific features.
Put it this way - with EC2, deltacloud knows about all the EC2
providers. So, the concept of "adding a provider" is a bit weird. You're
adding some EC2 account credentials and, possibly, specifying what
regions you want to allow them to be used for.
Even with RHEV-M, you'll be adding some RHEV-M account credentials and,
as part of that process, specifying the RHEV-M instance(s) that the
credentials are valid for.