Sumo, NIFI-210 [1] has been re-opened to enable support for scripting language processors, and I believe is intended to supersede the others (NIFI-684 (Groovy), NIFI-935 (Jython), and NIFI-1167 (Javascript)).
I’ve been doing some work on this, part of it (like yours) is based on Ricky Saltzer’s POC (in NIFI-684). Are you interested in collaborating on this? My feature branch is at [2], I’ve written two processors: InvokeScriptProcessor: For JSR-223 script engines that are Invocable (Jython, Javascript, Groovy, JRuby, etc.), the user can provide a script that defines an implementation of the Processor interface, and assigns an instance of that to the “processor” variable. The InvokeScriptProcessor will delegate its own Processor methods out to the ones supplied by the script. ExecuteScript: This is much like your ExecuteGroovy processor, but is extended to all registered JSR-223 script engines, which so far includes Jython, Javascript, Groovy, JRuby, Lua, and Scala. I’ve got a template I can provide, and will be making a video demo soon to show the config and execution of these processors. I look forward to your comments and possibly working together! Regards, Matt [1] https://issues.apache.org/jira/browse/NIFI-210 [2] https://github.com/mattyb149/nifi/tree/script-processors On 12/1/15, 12:52 AM, "Sumanth Chinthagunta" <[email protected]> wrote: >Sure Joe. I will create Jira tickets for those processors . I am also working >on to move groovy lib dependency to parent nar level to keep processor nars >sleek. >Sumo > >Sent from my iPhone > >> On Nov 30, 2015, at 7:25 AM, Joe Percivall <[email protected]> >> wrote: >> >> Hey Sumo, >> >> I don't know much about this use-case but just taking a quick look the >> processors in that github repo they seem to be potentially a great addition >> to NiFi! >> >> I think you should consider creating a Jira and working this there. It would >> a lot easier to get feedback and have a record of it on Jira than just on >> the Dev list. >> >> Joe >> - - - - - - >> Joseph Percivall >> linkedin.com/in/Percivall >> e: [email protected] >> >> >> >> >> On Wednesday, November 25, 2015 2:12 PM, Sumanth Chinthagunta >> <[email protected]> wrote: >> I have first-cut implementation of ExecuteRemoteProcess processor at: >> >> https://github.com/xmlking/nifi-scripting/releases >> <https://github.com/xmlking/nifi-scripting/releases> >> >> I tried to provide all capabilities offed by groovy-ssh >> (https://gradle-ssh-plugin.github.io/docs/ >> <https://gradle-ssh-plugin.github.io/docs/>) to ExecuteRemoteProcess user. >> it takes three attributes: >> 1. SSH Config DSL (run once on OnScheduled) >> remotes { >> web01 { >> role 'masterNode' >> host = '192.168.1.5' >> user = 'sumo' >> password = ‘fake' >> knownHosts = allowAnyHosts >> } >> web02 { >> host = '192.168.1.5' >> user = 'sumo' >> knownHosts = allowAnyHosts >> } >> } >> 2. Run DSL ( run on each onTrigger) >> ssh.run { >> session(ssh.remotes.web01) { >> result = execute 'uname -a' >> } >> } >> 3. User supplied Arguments which will be available in Run DSL >> >> anything that is assigned to ‘result’ in RunDSL is passed as flowfile to >> success relationship. >> >> Any suggestions for improvements are welcome. >> >> -Sumo >> >> >>> On Nov 24, 2015, at 8:19 PM, Adam Taft <[email protected]> wrote: >>> >>> Sumo, >>> >>> On Tue, Nov 24, 2015 at 10:27 PM, Sumanth Chinthagunta <[email protected]> >>> wrote: >>> >>>> I think you guys may have configured password less login for SSH (keys?) >>>> >>> >>> Correct. I'm using SSH key exchange for authentication. It's usually >>> done password-less, true, but it doesn't necessarily have to be (if using >>> ssh-agent). >>> >>> >>> >>> >>>> In my case the edge node is managed by different team and they don’t >>>> allow me to add my SSH key. >>>> >>> >>> Yikes. Someone should teach them the benefits of ssh keys! :) >>> >>> >>> >>>> I am thinking we need ExecuteRemoteCommand processor (based on >>>> https://github.com/int128/groovy-ssh) that will take care of key or >>>> password base SSH login. >>>> >>> >>> +1 - this would be a pretty nice contribution. Recommend building the >>> processor and then posting here for review. I'm sure this would be a useful >>> processor for many people. >>> >>> >>> ExecuteRemoteCommand should have configurable attributes and return command >>>> output as flowfile >>>> >>>> host : Hostname or IP address. >>>> port : Port. Defaults to 22. >>>> user : User name. >>>> password: A password for password authentication. >>>> identity : A private key file for public-key authentication. >>>> execute - Execute a command. >>>> executeBackground - Execute a command in background. >>>> executeSudo - Execute a command with sudo support. >>>> shell - Execute a shell. >>>> >>>> >>> As we do for SSL contexts, it might make sense to bury some of these >>> properties in an SSH key controller service. I'm thinking username, >>> password, identity might make sense to have configured externally as a >>> service so they could be reused by multiple processors. Unsure though, >>> there might not be enough re-usability to really get the benefit. >>> >>> Also, I'm thinking that the "background", "sudo" and "shell" options should >>> possibly be a multi-valued option of the processor, not separate >>> properties, and definitely not separate "commands." i.e. I'd probably >>> recommend property configuration similar to ExecuteCommand, with options >>> for specifying the background, sudo, shell preference. >>> >>> Good idea, I hope this works out. >>> >>> Adam
