RFC: Minor API change proposal for aeolus-cli

Jason Guiditta jguiditt at redhat.com
Mon Dec 12 20:57:54 UTC 2011


Hello all,

I wanted to get thoughts on a change proposal wrt the aeolus-cli
invocation.  If there is general consensus on this being a reasonable
(and timely) change, I will follow this up at some point with a
related structural/architectural change that I think wil improve our
code maintainability and make the cli tooling more expandable and
flexible going forward. That detail I expect to go through a number of
rounds of discussion first, so I am deferring it in favor of what I
think is the most important part of the question as related to an
official 1.0- type release.  This is important because after a
major release, I would like us to be able to reasonably expect to have
backwards compatibility for the cli api.

All that preamble aside, here is my suggestion, followed by my attempt
at a short explanation of why.  I propose that we take the current
command:
aeolus-cli build {other args}

and change it to:
aeolus-cli image build {other args}

This would present a more general construct of:
aeolus-cli {top-level-command} {subcommand} {options}

The reasoning is that while _at this moment_ aeolus-cli is purely an
interface to managing images, over time it should/will grown into a
full suite of commands for managing anything that conductor can do
(calling the conductor api, of course).  Requiring a top level command
gives us a place to put this additional management by making a fairly
small change to the existing cli api.  What do people think?  Is
requiring this command change too jarring so close to a major release?
Does it cause major headache for QA?  Or does it make sense to do it
now and not have to deal with it later (and introduce a post-1.0 api
change).  I think it is clear I think we shoudl do it now, but I
wanted to make sure there were no major objections before pushing
forward with it.

-j



More information about the aeolus-devel mailing list