You forgot these potential steps: - download/install docker - download apache-nifi docker image
These steps are basically analogous to: - download JDK - download apache-nifi tar.gz So the docker solution is only saving the configuration of nifi.properties step; something which should always be modified by the user anyway. Adding docker into the mix, especially if it's included as a regular output from the build, means yet-another-deployment-artifact to manage and maintain. If the community can consistently support it, and the issue of defaulting all nifi properties is resolved, then I'd say go for it. You're basically suggesting to trade a Docker installation/configuration for the JDK installation/configuration. Docker is the hotness and all, so maybe it's worth it for the gee-whiz perspective. But again, it doesn't add very much real value (for demo purposes). The Docker image would have to add value beyond a simple bootstrap demo, to be truly valuable. Two cents. Adam On Wed, May 13, 2015 at 10:28 AM, Aldrin Piri <[email protected]> wrote: > Not sure I agree with your assessment. The demand is there for Docker > containers, even for Java apps, as evidenced by the Registry that grows > larger every day. > > NiFi is easy to set up, but it's certainly easier to do: > > docker run -P apache-nifi > http://localhost:8080/nifi > > Through a container, or equivalent, we control the totality of the user > experience for running. If they want to get into internals, they have the > option to, but certainly do not need to nor do they have to worry about > modifying their current system to support it. > > On Wed, May 13, 2015 at 10:21 AM, Adam Taft <[email protected]> wrote: > > > It is a Java app. So it's not like having virtualized container adds a > > whole lot of value. To quickly try out NiFi, currently you would: > > > > - install java (if not already) > > - download latest tar.gz > > - unzip to some user directory > > - modify nifi.properties > > - bin/nifi.sh start > > - http://localhost:8080/nifi > > > > With a virtualized container, you're possibly saving the step of > > downloading java and modifying the nifi.properties (to some default > > "unsecure" configuration). The rest of the steps would still be > performed, > > substituting download of the image and running it. > > > > So maybe this is simply a function of a "quick start" documentation, with > > screenshots? I'm not seeing a lot of value for using a container, simply > > for demo purposes. > > > > A live hosted demo might be interesting to consider. You would have to > > deal with the problem of someone using a GetFile that is looking at /etc, > > for example. > > > > Adam > > > > > > > > On Wed, May 13, 2015 at 10:01 AM, Joe Witt <[email protected]> wrote: > > > > > All, > > > > > > Yesterday I had a chance to talk to a really cool startup with awesome > > > developers who gave some great feedback on nifi. One of the things > > > they mentioned was how much they loved the UI. In fact they said if > > > they hadn't seen the reference to the UI they would have said > > > 'interesting' and moved on but not really followed up. > > > > > > The point they made is we should make it as easy as possible to get > > > from landing on the apache nifi webpage to having an up and running > > > instance of NiFi for them to get to start playing with the UI. > > > > > > I'd like to put this out there to get a sense of how people see this > > > being most effectively done. > > > > > > They mentioned Vagrant. We've also had some folks mention and > > > contribute references to docker images. Other ideas might be > > > providing a live/running site where people could just immediately > > > start gaining familiarity with nifi. > > > > > > Each of these have different pros/cons and it is unclear how to do > > > these in apache effective ways. > > > > > > Look forward to ideas you all may have or thoughts on what other > > > effective approaches projects have taken. > > > > > > Thanks > > > Joe > > > > > >
