I don't think there is an explicit reason why it was done that way, rather this was the convention established with the way the artifacts were imported into the image and the way the assembly is constructed.
Typically, at least in how I personally use the image, I am making use of volumes and am explicitly setting a version that is used throughout my simple script. This gives me the flexibilities I need in terms of upgrades and the like. Having said all that, certainly in favor of the path suggested, it makes sense and is a nice and easy usability win. I would be sure to keep the versioned approach for those folks who prefer that convention and then additionally add a latest symlink. On Tue, Jul 31, 2018 at 2:10 AM Peter Wilcsinszky < peterwilcsins...@gmail.com> wrote: > Hi, > > I was wondering about this too. We have the option to add a symlink which > you just mentioned and I can do that if there are no argument against. > > Also you can use the env var, when you do things through scripting: > docker run --rm -ti --entrypoint bash apache/nifi:1.7.0 -c "echo > \$NIFI_HOME" > /opt/nifi/nifi-1.7.0 > > I'm not sure about the original reasons it was created this way. We may > change to a version agnostic path with the next release and create a > symlink with the version for backward compatibility. > > Peter > > On Tue, Jul 31, 2018 at 12:01 AM Jon Logan <jmlo...@buffalo.edu> wrote: > > > Hi, > > > > I was looking at utilizing the Docker distribution but was wondering if > any > > thought was given to making the paths version-agnostic? Specifically, the > > conf folder is in /opt/nifi/nifi-1.7.1/conf. This would mean any > > modifications we would make in a container or RPM would be tied to 1.7.1. > > > > I have seen other projects accomplish this with a symlink (ex. > > /opt/nifi/latest -> opt/nifi/nifi-1.7.1), and think that approach might > > work as well here? > > > > Is there a better approach? > > > > > > Thanks! > > Jon > > >
