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