Version-Agnostic Paths in Docker?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Version-Agnostic Paths in Docker?

Jon Logan
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
Reply | Threaded
Open this post in threaded view
|

Re: Version-Agnostic Paths in Docker?

Peter Wilcsinszky
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Version-Agnostic Paths in Docker?

Aldrin Piri
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 <
[hidden email]> 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 <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Version-Agnostic Paths in Docker?

Peter Wilcsinszky
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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]> 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
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Version-Agnostic Paths in Docker?

Aldrin Piri
I'll scope it out. Thanks for taking an initial effort on it!

On Wed, Aug 8, 2018 at 8:29 AM Peter Wilcsinszky <[hidden email]>
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 <[hidden email]> 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 <
> > [hidden email]> 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 <[hidden email]>
> 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
> > > >
> > >
> >
>