openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <rod...@gmail.com>
Subject Re: Implement wskadmin in scala
Date Thu, 26 Apr 2018 09:06:40 GMT
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 <chetan.mehrotra@gmail.com> 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

Mime
View raw message