-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rockons: Invalid environment variable (...) #1588
Comments
@daniel-illi Thanks for reporting this and linking to the other report.
and your report here has an equally repeatable var name "POSTGRES_PASSWORD". I wonder if we are looking at some kind of accidental repeating env name / failure to isolate / or update type think here. Could you check to see if any of your locally defined and installed Rock-ons use the same env name. Or this could be some other bug in the container object key storage. Also noting we have a typo in that exception message: "variabled". |
@phillxnet I'm testing the rockon in a fresh vm without any other custom rockons. No rockons are installed yet. |
I get the same error with SELF_URL_PATH in the Tiny-Tiny-RSS image from https://github.com/clue/docker-ttrss Heres my rockon:
|
Another report with the same problem: https://forum.rockstor.com/t/softether-vpn-rockon/2637/3 |
+1 Same exact issue i'm facing with softether that was reported on the forums. |
I have the same issues as mentioned here, but only if i define container_links and a second container, If i remove those the issue disappears. Could this be related to checking the wrong docker image for environmental variables? |
A temporary fix is to duplicate environment json in all containers. It seems like rockstor tries to assign all the environment variables defined in rockon to all of its containers and fails there. |
This is still an issue and really needs to be fixed. The linked PR requires work. |
Noticed that this is still an issue when trying to combine some containers into a single Rockon to improve the user experience of this Rockon. I wrote the following json definition:
Got the following message during the attempt to install:
|
Hi again @KookyKrane, I'm in the same situation as you, and actually it is when I tried to make a rock-on for the same project as you (Nginx Reverse Proxy (jWilder)) and this very issue here that I decided to get myself familiarized with the rock-on system and working on improving them. As described in the other issue you just commented on, I'm currently working on implementing docker networks (which will indirectly help with the current issue), and plan on having a look at the proposed PR (#1688) thereafter. @anatox did a lot of work in this PR to fix this issue and there was a helpful discussion therein with @MFlyer so even though that part of the code changed quite a bit, building upon / adapting @anatox's work should be a very good start (to say the least). |
Thx @FroggyFlox for pointing me to #1688 These patches are certainly motivating me to become more familiar with the system. |
A new forum user has encountered the same issue: In addition to reinforcing the need for this issue to be fixed, let's try to update the forum thread above once this issue is closed. |
Re: @anatox 's #1588 (comment)
Linking for context to @freaktechnik 's now closed-as-later-duplicate issue noted the same work-around #2202 (comment)
|
Title updated to reflect latest testing code behaviour - where we also no-longer have as expressive a trace-back; i.e.:
in the case of the linked draft PR in rockon-registry (rockstor/rockon-registry#379), the most recent reproducer expressing this now long-standing limitation regarding multi-container Rock-on definitions that also involve I have assigned myself to this issue informed by @anatox prior work #1688 in the context of many underlying changes in the interim to our Rock-ons code - represented in current testing branch. |
As-is, in current testing we pass the following from front-end to backend during a rock-on install command request POST (using the reference draft PR as reproducer):
I.e. as per @anatox exposition (many years ago now) we lump all config info, for all containers, together. defeating env name duplication across containers in multi-container Rock-ons: even though it is independently detailed in the source JSON that is the Rock-on definition. This applies to all env categories here also, as per @freaktechnik 's following #2202 (comment) :
Which limits multi-container Rock-ons to per Rock-on unique share/port/cc/env definitions. |
Add container dimension to Rock-on input environment during Rock-on install wizard front-end. Cheery picked from anatox's prior work on GitHub.
Cherry picking front-end changes proposed by @anatox to add container info to the 'environment' input matrix, we get the following input from our Rock-on install front-end:
I.e. we now have a second matrix dimension associated with container id within our DB, preserving per-container env seperation.
|
The addition, in the front-end, of our new environment matrix dimension has the following buggy artifact: I.e. we are summarising the 'new' top level environment matrix dimension. [EDIT]: |
Remaining sub-issues:
|
@phillxnet, |
@FroggyFlox Thanks, that helps. We may have to tackle that separately, in a dedicated PR: still assessing how far to go with this issue that is predominantly related to env per container in multi-container Rock-ons after-all. Confirming share entry as:
With corresponding front-end passing to back-end the following (re shares):
And the resulting share mapping as reported by our 'spanner' on the resulting installed Rock-on:
[EDIT See spin-off issue "Rock-on install wizard obfuscates share container info": #2886 ] |
Add back-end container dimension awareness re environment passed from Rock-on install wizard. Rebase of earlier work cheery picked/re-based from anatox's prior work on GitHub.
@FroggyFlox Currently looking at where/how to address:
[EDIT re the JS for our pre-install summary table:
rockstor-core/src/rockstor/storageadmin/static/storageadmin/js/views/rockons.js Lines 835 to 845 in eab4ed5
rockstor-core/src/rockstor/storageadmin/static/storageadmin/js/templates/rockons/install_summary.jst Lines 1 to 10 in eab4ed5
] |
Thanks a lot for taking care of all that. Maybe we can add the container in parenthesis to the value in the table for this issue (or something along those lines)? |
@FroggyFlox Agreed.
I'm actually working on this approach currently as it goes. We may well have to improve the tables in time thought. |
Existing multi-container Rock-ons in the rockon-registry repo:
Proposed multi-container Rock-on:
|
Rock-on front-end install wizard does not collate container info regarding Rock-on defined environment elements. Affects multi-container Rock-ons only. Results in back-end failure to successfully assign user-input environmental variables. Resolved by adding a container id dimension to the environmental matrix created by the install wizard, and updating the back-end Rock-on instantiator to take advantage of this info. Previously a reverse engineering approach was taken: which cannot work for example, where two containers, within the same Rock-on definition, use the same environmental variable name. Thanks to GitHub user @anatox - the majority of this PR is based on their prior submission to the project - alas unmerged at the time. Also adds - Rock-on install debug log re front-end info received. - Fixes, partly, resulting installer wizard summary feedback bug.
…ent-variable Rockons: Invalid environment variable (...) #1588
@freaktechnik Hello again. Form announcement of 5.0.14-0: https://forum.rockstor.com/t/v5-0-testing-channel-changelog/8898/27 Hope that helps. Not sure if it resolves your issue however. You may be able to share Shares between containers via a hard wired --volumes-from env var. Assuming you instruct the user with a |
While developing the metadata json file for a new rockon, I can into this error with one of my defined environment variables:
I found the line where this error is generated on line 142 of the file
src/rockstor/storageadmin/views/rockon_id.py
:Initially I thought this happens when I define an environment variable that has no corresponding
ENV
set in the Dockerfile, but it didn't help when I defined the same variable in the Dockerfile, the same error was thrown.I ran into the same problem before, as did someone else:
The text was updated successfully, but these errors were encountered: