Aeolus Papercuts

Scott Seago sseago at redhat.com
Tue Jun 12 04:09:21 UTC 2012


On 06/11/2012 02:51 PM, Matt Wagner wrote:
> I hope I'm not opening _too_ big a can of worms here, but I was just
> thinking about a handful of things in Aeolus that really annoy me, yet
> would probably be pretty easy to fix.
>
> Here's what's on my mind. Please feel free to share your own:
>
> 1.) Adding an EC2 account is absurdly complicated if you don't use
> aeolus-configure here. You need to name the provider something magical
> for you to be able to push images. You also need to set the API_PROVIDER
> string to something magical, but seemingly something different. And even
> though there's only a finite set of possible values, you can't choose
> from a dropdown -- you need to manually enter it.
>
> This is maybe not a priority, since most people will probably use
> aeolus-configure. But it seems like we could make this much, much easier
> to do through the web GUI than it is today.
>
Yes, this is a longstanding "backlog" issue. I'm pretty sure jayg and I 
discussed this about a year ago and we'd realized the same thing. The 
provider-type-specific 'new provider' forms were supposed to morph into 
this sort of thing longer-term, but it's always been "that's a good idea 
=> later!"

Basically we need to customize the new provider forms for each type -- 
we're already doing this to a limited extent, but we need more of it. 
For ec2, we need a dropdown for region. The factory/deltacloud 'name' 
discrepancy (which is why the 'name' and 'X-deltacloud-provider' fields 
must be different) is a separate problem which will be handled along 
with the (also a long-term "back-burner" item) task to put all provider 
config in the conductor provider object, so factory will get that stuff 
from us rather than hard-coding it (for ec2) or holding it in config 
files (for RHEV/vSphere). For RHEV we actually need a two-step form -- 
user provides the base URL to the RHEV server (i.e. without datacenter), 
we get a list of providers from deltacloud -- so this will now be a 
dropdown that will provide the X-Deltacloud-Provider field with 
datacenter included. We'll probably want something similar for vSphere.


> 2.) Our messaging is really bad in the case that things fail while
> building images. Because I apparently used the wrong magic string for
> EC2, my attempt to push an image failed. The error I got in the web UI
> reads, "Unable to Upload Provider Image." (Yes, with excessive
> capitalization.) I had to go to imagefactory.log, and by reading the
> stack trace I could piece together what went wrong.
>
> There's actually a whole bunch wrong here. First, the error:
>
> 2012-06-11 14:08:49,751 WARNING imgfac.BuildDispatcher.BuildDispatcher
> pid(26193) Message: No matching provider found for us-east-1, using
> "condorcloud" by default.
> 2012-06-11 14:08:49,751 DEBUG imgfac.ImageWarehouse.ImageWarehouse
> pid(26193) Message: Querying
> (http://localhost:9090/target_images/_query) with expression ($build ==
> "54e87189-b155-4264-982c-4bcffed405fa"&&  $target == "condorcloud")
> 2012-06-11 14:08:49,753 DEBUG imgfac.ImageWarehouse.ImageWarehouse
> pid(26193) Message: Image Warehouse returned status (404) with message:
> 2012-06-11 14:08:49,753 DEBUG imgfac.ImageWarehouse.ImageWarehouse
> pid(26193) Message: Getting metadata (['template']) from
> http://localhost:9090/target_images/None
> 2012-06-11 14:08:49,754 DEBUG imgfac.ImageWarehouse.ImageWarehouse
> pid(26193) Message: Image Warehouse returned status (404) with message:
> 2012-06-11 14:08:49,755 DEBUG imgfac.ImageWarehouse.ImageWarehouse
> pid(26193) Message: Created Image Warehouse instance
> http://localhost:9090 - buckets(target_images, templates, icicles,
> provider_images)
> 2012-06-11 14:08:49,755 ERROR imgfac.rest.imagefactory pid(26193)
> Message: 'template' must be a UUID, URL, XML string or XML document
> path...
>
>
> What this actually means is essentially "You specified an invalid
> provider," but it's not abundantly clear.
>
> Second, this error should come back over the API.
>
> Third, Conductor should collect and display that helpful error, versus
> telling people to work their way through imagefactory.log to figure out
> what went wrong.
>
> It's not like either of these two things are killer features that will
> make a profound difference. But they're both things I think we could put
> in an upcoming sprint to make the user experience, well, less
> frustrating. But I'm pretty sure these aren't the only two. What other
> pet peeves do you think we could pretty trivially address?
>
> -- Matt




More information about the aeolus-devel mailing list