You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Peter Wilcsinszky <pe...@gmail.com> on 2018/08/08 12:29:11 UTC

Re: Version-Agnostic Paths in Docker?

https://github.com/apache/nifi/pull/2940

This is what I came up with, however not sure I covered your use case
Aldrin. I tried to have a symlink with the name /opt/nifi/nifi-current to
point to the original installation path, but the WORKDIR instruction
resolves the link and we end up running NiFi in /opt/nifi/nifi-<VERSION>
while the environment variables point to /opt/nifi/nifi-current which I
would avoid.
We can change the WORKDIR to be /opt/nifi and cd into nifi-current from the
script, but that would be a breaking change I beleive for anyone using
custom scripts and depending on the original working directory.

What do you think?

Cheers,
Peter

On Tue, Jul 31, 2018 at 5:22 PM Aldrin Piri <al...@gmail.com> wrote:

> 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 <
> peterwilcsinszky@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 <jm...@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
> > >
> >
>

Re: Version-Agnostic Paths in Docker?

Posted by Aldrin Piri <al...@gmail.com>.
I'll scope it out. Thanks for taking an initial effort on it!

On Wed, Aug 8, 2018 at 8:29 AM Peter Wilcsinszky <pe...@gmail.com>
wrote:

> https://github.com/apache/nifi/pull/2940
>
> This is what I came up with, however not sure I covered your use case
> Aldrin. I tried to have a symlink with the name /opt/nifi/nifi-current to
> point to the original installation path, but the WORKDIR instruction
> resolves the link and we end up running NiFi in /opt/nifi/nifi-<VERSION>
> while the environment variables point to /opt/nifi/nifi-current which I
> would avoid.
> We can change the WORKDIR to be /opt/nifi and cd into nifi-current from the
> script, but that would be a breaking change I beleive for anyone using
> custom scripts and depending on the original working directory.
>
> What do you think?
>
> Cheers,
> Peter
>
> On Tue, Jul 31, 2018 at 5:22 PM Aldrin Piri <al...@gmail.com> wrote:
>
> > 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 <
> > peterwilcsinszky@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 <jm...@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
> > > >
> > >
> >
>