On 08/04/2011 08:00 AM, Mark McLoughlin wrote:
Hi Scott,
For reference, here was my previous attempt to dig through this:
https://fedorahosted.org/pipermail/aeolus-devel/2011-June/002120.html Ahh, yes I
remember that thread now. You're tackling a much larger scope
with that document, though, and I'm not sure we'd want to handle all of
that in this one iteration. In particular, some of the proposals around
the more fundamental rethinking of providers and provider accounts still
need a fair amount more thinking/design/etc which shouldn't necessarily
hold back the changes I'm proposing here, which can probably be more
readily put in place. In this larger context, the separate chunks of
work would break out roughly like this:
1) Multi-provider core refactoring (proposed below; relatively few
remaining issues to work out; ready to start implementation this week)
2) All imagefactory provider config comes via conductor api along with
credentials (proposed below; need to coordinate design/api/changes with
aeolus-image and factory team)
3) Hash out requirements/design for the more fundamental changes Mark
proposed in the linked message (can be done in parallel w/ impl for 1-2)
4) Implement desired changes to Provider/Account/etc models.
On Thu, 2011-08-04 at 01:06 -0400, Scott Seago wrote:
> 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.
Yes!
> 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"
I'd call these "anti-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)
In the case of RHEV, this is a URL - we should provide people with as
much help as possible when filling out this field.
OK, so I see a two phase approach here -- first we get the field out
there so it's functional, then we need some sort of UI helper component
that's driver-specific. For ec2 it's a picklist, for RHEV perhaps some
boilerplate URL text "https://[RHEV-HOST]/what-we-expect-here", for
eucalyptus we'd start with "|ec2=[EC2-IP]:8773;s3=[S3-IP]:8773" in the
textfield, etc.
|
> 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
Before I get to your open question below, what I don't like about this
is that the deltacloudd URL is duplicated between all providers and
something that users need to fill in.
Entering the deltacloudd URL is not the common case. Conductor should be
configured with a deltacloudd URL in the same way it would be configured
with the address of IWHD, Image Factory or Condor.
So how about this compromise:
1) we add a conf value for default deltacloud-core URL -- possibly to
the metadata_objects table so it can be edited via admin UI, or as you
say we could do it in the same way we do IWHD/condor/etc
2) for 'new provider', the normal workflow just shows this as plain text
in HTML (with a hidden form element actually specifying the value for
the object) -- we provide the user with a button to override default
provider -- if the click that, the plain text is replaced with an
editable textfield with the default deltacloud URL pre-filled.
I'd say that, for 2), for the first iteration we just use a regular
textfield but we pre-fill the data with the default value so in most
cases. We then enhance it with hiding the formfield by default after we
get some UI design on this. In particular, I'd say that the "hide the
formfield until the user clicks the 'override' button should be js-only.
The plain HTML fallback just provides the textfield with default filled-in.
So the main thing here is that we're providing the multi-provider core
for convenience -- users shouldn't have to worry about where
deltacloud-core is when adding providers. However, there may be cases
where the user wants to use a different core. For example, what if the
user has aeolus admin privileges on the web UI but not shell access to
mess with deltacloud-core config/packages and wants to test out a new
driver that's not loaded on the default core instance? If he can
override the core URL, he can set up a separate core instance and point
there.
> 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.
I'd see this as a special case where we allow users to add a "deltacloud
provider" - i.e. you just give it a deltacloud URL, rather than a
X-Deltacloud-Provider value to pass to our embedded deltacloudd.
Well even when you give a deltacloud URL (as suggested above) this
"custom" deltacloud-core instance may still be set up for multiple
providers, so we don't want to preclude them choosing the
X-Deltacloud-Provider field as well. Perhaps we say that
X-Deltacloud-Provider is required _unless_ the user overrides the
default deltacloud-core URL, in which case it's optional?
> 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
Right, exactly. We already pass the credentials XML to image factory, so
perhaps the providers details could just be included there?
Finally, to repeat a point I made before - with this new setup, having
separate UIs for configuring providers and provider accounts doesn't
really make much sense to me. It makes most sense to me for the user to
point Conductor at a provider and supply the credentials for it at the
same time.
Yeah I think some of that's on Ken's roadmap for the admin UI. At a
minimum we need to connect the Provider and ProviderAccount UIs. At the
moment we're even limiting to one account per provider, so it's even
easier to consolidate these two. However, long-term I don't think we can
continue with this restriction as-is.
Right now, the design seems to be optimized for the case where
you're
entering many accounts for the one provider. IMHO, that's not the
important case and we could tackle that with some "this is another
account for a provider I added earlier" UI trickery
Right -- and, see above, you can't even add multiple accounts with the
present UI.
Cheers,
Mark.