Aeolus Papercuts

Andrew Fitzsimon afitzsim at redhat.com
Mon Jun 11 23:27:55 UTC 2012


Totally agree.  Especially for the provider input. I always assumed it was a finite thing. An option select or even a chosen JS input would go miles beyond what we are rocking right now


On 12/06/2012, at 4:51 AM, Matt Wagner <matt.wagner at redhat.com> 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.
> 
> 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