[
https://issues.apache.org/jira/browse/AURORA-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Chu-Carroll updated AURORA-76:
-----------------------------------
Description:
To eventually start supporting deployment of clientv2, and to help users
gradually migrate to v2, we need to have a mechanism in the command-line
processing to take commands that aren't recognized by the v2 client, and pass
them to the v1 client for processing.
So running "aurora list_jobs example" will run the client v1 "list_jobs"
command; running "aurora status a/b/c/d" will run the v1 "status" command, and
running "aurora job status a/b/c/d" will run the v2 status command.
The current noun/verb framework that we've built for processing commands in
clientv2 is monolithic, in the sense that it believes it's the only thing that
needs to be able to process command-line arguments.
This issue should add tooling to the framework so that you can create multiple
distinct command-processing components, and have the framework dispatch a
command to the appropriate one.
In addition to the general clientv2/v1 bridging issues, this should also make
it easier to build multiple versions of the aurora client for different
environments - just add new noun/verb groupings to a new command line
processor, and then patch it in via this bridge.
was:
To eventually start supporting deployment of clientv2, and to help users
gradually migrate to v2, we need to have a mechanism in the command-line
processing to take commands that aren't recognized by the v2 client, and pass
them to the v1 client for processing.
So running "aurora list_jobs example" will run the client v1 "list_jobs"
command; running "aurora status a/b/c/d" will run the v1 "status" command, and
running "aurora job status a/b/c/d" will run the v2 status command.
> Implement bridging for clientv2 command line framework.
> -------------------------------------------------------
>
> Key: AURORA-76
> URL: https://issues.apache.org/jira/browse/AURORA-76
> Project: Aurora
> Issue Type: Task
> Components: Client
> Reporter: Mark Chu-Carroll
> Assignee: Mark Chu-Carroll
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> To eventually start supporting deployment of clientv2, and to help users
> gradually migrate to v2, we need to have a mechanism in the command-line
> processing to take commands that aren't recognized by the v2 client, and pass
> them to the v1 client for processing.
> So running "aurora list_jobs example" will run the client v1 "list_jobs"
> command; running "aurora status a/b/c/d" will run the v1 "status" command,
> and running "aurora job status a/b/c/d" will run the v2 status command.
> The current noun/verb framework that we've built for processing commands in
> clientv2 is monolithic, in the sense that it believes it's the only thing
> that needs to be able to process command-line arguments.
> This issue should add tooling to the framework so that you can create
> multiple distinct command-processing components, and have the framework
> dispatch a command to the appropriate one.
> In addition to the general clientv2/v1 bridging issues, this should also make
> it easier to build multiple versions of the aurora client for different
> environments - just add new noun/verb groupings to a new command line
> processor, and then patch it in via this bridge.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
