----- Original Message -----
On 07/06/2012, at 4:42 AM, Matt Wagner wrote:
<snip>
> I think aeolus-configure is really slick and makes things 100 times
> easier than it used to be, but "edit this yaml file based on what
> this
> wiki page suggests" is _still_ not very intuitive for RHEV and
> vSphere
> configs. I'm not sure just yet on how we can solve that, but it's
> definitely something deserving some attention.
Other ways we could get info from the user:
+ Command line argument style
* aeolus-configure --rhev-nfs example.org:/export/ovirtexport
Long command lines aside, this would be beneficial for scripting.
This is fairly reasonable though might get VERY long.
Another option is to consider shipping an example file and allowing the file to be passed
into configure rather than looking on /etc/
+ Interactive command line style
* What's the name of your oVirt/RHEV NFS server? [
example.org]
* What is the mount point for its export domain?
[/export/ovirtexport]
<etc>
Good for newbies?
My big concern here is that there are LOTS of things that ought to be able to be
specified, and it would quickly become at least marginally overwhelming even if we built
some curses based UI around this.
+ Web interface (not aeolus-configure based)
(UX experts for this one :>)
I think I like this one the best really, but I'd an explicit -- make each configurable
thing doable via a RESTful endpoint and provider some useful example scripts/cli to
interact with the endpoints. And then go further and make aeolus-configure as minimal as
possible, there is still some pain to be had here thinking about how to handle
multiple-machine installations.
From the Aeolus installer's (SysAdmin) perspective, the command line
style is good for scripting. Whereas having everything configurable
from
the web interface is more in line with our stated (UX friendly) end
vision.
No idea how important fixing this stuff is though, in comparison to
other
things.
+ Justin
--
Aeolus Community Manager
http://www.aeolusproject.org
I think it is really quite important and something that we should be pushing on pretty
actively.
The other part probably worth calling out, we should clarify the intended audience here.
For quite some time we have been trying to serve two distinct communities here:
(1) people that want to get a reasonable development environment setup without having to
understand how to weave all the components together, and
(2) people that are trying install & run in a (potentially) more complex production
environment
It seems that in trying to hit both targets we've compromised on both. There has been
some amount of talk about splitting out development setup. This is becoming much closer
to possible now with some of the bundler changes Jay has been moving along. Perhaps we
can draw some inspiration from devstack[1].
Thanks,
Mike
[1]
http://devstack.org/