We recently upgraded from 1.8 to 2.0.20. With version 1.8, the application form would print as, say,
whereas now, with 2.0.20, it is printing as
Is there some configuration option that we failed to copy over to 2.0.20? Is there an option in 2.0.20 that we can set to suppress the version information?
This isn’t really very important, but we’d like to keep the noise we expose users to at a minimum.
Thanks!
Hi Bennet:
On my landing page (WebAuth Login), I have “powered by open OnDemand” at the bottom left of the footer, with “OnDemand version: v2.0.20” at the bottom right of the footer. Is that latter string the one you’re referring too? If so, that’s in
/var/www/ood/apps/sys/dashboard/app/views/layouts/_footer.html.erb. It’s not clear that you can override or suppress that without editing that file.
Ric
Hi, Ric,
What I am referring to is on the form for the Basic Desktop (we modified bc_desktop a little), but it’s on all the applications, at the top of the form. The version is now included after the title attribute from the form.yml.erb is rendered.
Bennet:
That’s interesting:
[ric@ood ~]$ sudo find / -xdev -name form.yml.erb
comes up empty. I have a boatload of form.yml files though. A quick
rpm -ql ondemand-2.0.20-1.el7.x86_64
shows no form.yml.erb files, so I don’t have any idea where those came from at your site. Local git repo maybe?
Ric
If you didn’t add any Ruby variables, it is called form.yml. It’s in the bc_desktop app directory.
here’s my one and only bc_desktop/form.yml
$ ls -ld /var/www/ood/apps/sys/bc_desktop/form.yml
-rw-r–r–. 1 root root 266 Dec 1 13:57 /var/www/ood/apps/sys/bc_desktop/form.yml
I don’t have a form.yml in /etc/ood for bc_desktop, just
$ ls -lR /etc/ood/config/apps/bc_desktop/
/etc/ood/config/apps/bc_desktop/:
total 4
-rw-r–r–. 1 root rt-is-unix 1729 Dec 2 07:52 desktop.yml
drwxrwsr-x. 2 root rt-is-unix 24 Jul 28 2021 submit
/etc/ood/config/apps/bc_desktop/submit:
total 4
-rw-r–r–. 1 root rt-is-unix 1148 Dec 2 07:52 desktop.erb
No version info in any of them.
Yes, and I don’t find version: in any of my files, either. That’s why I was asking here, in the hope that someone on the list would know where in the Ruby code that is defined. 
Grepping for version: in our /opt/ood yielded many, many occurrences, but none looked particularly helpful. I suspect there is a file that gets rendered by the OnDemand application itself because it is occurring for all of our applications, not just one or two, and because it doesn’t seem to be in any file in the application directories.
I also note that under the Clusters menu now, we no longer have the text with the cluster name, instead we have
>_translation missing: en.dashboard.shell_app_title
so I’m expecting there will some file somewhere that got modified from 1.8 to 2.0 that includes the template that now prints the version number.
I think before it may have done that only for developer applications but now seems to be doing it for all.
While making the issue below, I found the commit and it’s been there since 1.7.
That looks like a git hash. We try to get the version from git or a VERSION file. If neither are found, we don’t show the version. You must have started using git with 2.0?
I wonder what the behavior is when you remove the .git/ directory? Kind of defeats the purpose of using git, but automation should handle it. Or start tagging so the version is at least a number.
But I also made this issue for the same, and gathered a lot of information about the code there.
Thanks for tracking that down, @jeff.ohrstrom We’ll take a look
We are installing from .rpm, and I get this list of versions back for ondemand RPMs
ondemand-python-2.0-1.el7.x86_64
ondemand-runtime-2.0-1.el7.x86_64
ondemand-apache-2.0-1.el7.x86_64
ondemand-sqlite-3.26.0-4.el7.x86_64
ondemand-sqlite-libs-3.26.0-4.el7.x86_64
ondemand-ruby-2.0-1.el7.x86_64
ondemand-gems-2.0.18-2.0.18-1.el7.x86_64
ondemand-gems-2.0.20-2.0.20-1.el7.x86_64
ondemand-sqlite-devel-3.26.0-4.el7.x86_64
ondemand-passenger-6.0.7-1.el7.x86_64
ondemand-2.0.20-1.el7.x86_64
ondemand-nodejs-2.0-1.el7.x86_64
ondemand-nginx-1.18.0-2.p6.0.7.el7.x86_64
I find from that an /opt/ood directory, and a /var/www/ood directory. Searching for the file _footer.html.erb in both, I get
# find /opt/ood | grep _footer.html.erb
#
and
# find /var/www/ood | grep _footer.html.erb
/var/www/ood/apps/sys/dashboard/app/views/layouts/_footer.html.erb
However, the contents of that _footer.html.erb don’t look like what is in our file.
That commit seems to point to this URL,
and a file called ondemand/app/views/layouts/_footer.html.erb, but when I look at the file listing at
I don’t see an ondemand/app directory, only one called ondemand/apps.
If I follow the path in the release_2.0 branch to the dashboard layouts, the _footer.html.erb there looks like what we have on our file system.
Sorry to be confused by all this, but I don’t know where in the installed RPM paths nor in the paths for the release_2.0 branch I would find the code comparable to what you cited. Would you mind pointing me to the installed location for that commit?
Thanks, – bennet
@jeff.ohrstrom My eagle-eyed colleague found some text I missed, so I think I know where to look now. Please disregard the prior comment for now.
For those interested, the file
/var/www/ood/apps/sys/dashboard/app/views/batch_connect/session_contexts/new.html.erb
contains the template to print the application name and version number in the block of lines 74-79.
74 <h3>
75 <%= @app.title %>
76 <% if @app.version != 'unknown' %>
77 <small>version: <%= @app.version %></small>
78 <% end %>
79 </h3>
I’ll continue the discussion in the GitHub issue with Jeff so as not to clutter Discourse.
To close the loop in Discourse, if the application has a file called ‘VERSION’ at its root, you can put the word ‘unkown’ on its only line, restart the nginx web server (not httpd), and the version will no longer print as part of the application name. Just in case anyone wants to suppress this and reads this only on Discourse. Thanks, Jeff, and sorry for the extra noise from my confusions.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.