My initial reaction is that it (wskadmin) could become more heavy weight (small changes becomes longer edit, compile iterations) - case in point the wsk cli in Python vs Go... but weighed against the benefits Chetan outlined with potential for a lot of shared code with the backend cannot be discounted.
I’m not familiar with oak-run and will take a look to educate myself. Are you considering the totality if wskadmin or a partitioning and only replacing some of partitions? (I understood the former, just making sure.) -r > On Apr 26, 2018, at 2:05 AM, Chetan Mehrotra <[email protected]> > wrote: > > Hi Team, > > Currently for OpenWhisk admin operation we have tooling implemented in > couple of python scripts like wskadmin, tools/db/* etc. These script > currently talk directly to CouchDB to perform required actions. > > Sometime back I discussed the option to support other databases [1] > and it was suggested to have wskadmin support various db backends. > However looking into other scripts I found some of the tool/db would > also be useful in context of other backends also. > > To simplify this aspect going forward it may be better to implement > the important tooling in Scala itself as a separate sub module in core > repo. This module would produce a 'fat runnable jar' which would be > including all required dependency and can be used as a standalone cli > tool. > > We used similar approach in Apache Jackrabbit Oak [2] where we produce > this single jar which consolidates all the admin tooling. This has > over the years became primary admin tooling for us. > > Such an approach would have following benefits > > 1. Implemented in Scala and thus able to leverage existing > abstractions like ArtifactStore > > 2. For some of the bulk db operations it would be possible to leverage > Akka Streams to implement simpler multi threaded flows. > > 3. Easy to implement tests for the tooling part > > 4. User management operations can be done via existing ArtifactStore > feature set. So one implementation can work against multiple stores > > 5. No other runtime dependency i.e. specific Python version or Python > module need to be deployed. Just have JDK 1.8 and use the jar in > standalone manner. No need to even check out whole OpenWhisk repo > > Key requirement for such a tooling would be to be compatible with > existing CLI argument format. > > If such an approach makes sense I can work on PR to give it a try! > > Chetan Mehrotra > [1] > https://lists.apache.org/thread.html/921a0a6350a7ec3a2dc77564612de59104995622f8417583291f20bc@%3Cdev.openwhisk.apache.org%3E > [2] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run
