Default values for environment variables in RockOn definition

[Flox]

Hi @Hooverdan,

Before I try to answer your questions and share my thoughts, please accept my apologies for not getting back with you earlier than that; I wanted to take the the proper time to answer you correctly but this has turned out to be rather difficult.

Note, also, that I will try to give more general answers (which seemed to be your focus) rather than specifics to watchtower; these may be better suited for a dedicated thread, for instance.

@Hooverdan

I am looking at possibly updating the Watchtower Rockon (which helps managing auto-updates of docker containers - even multi-container setups, so a manual stop/start action is not necessary in the RockOn dashboard to get the latest version of an underlying container).
The first commit was done about 2 years ago. I am interested in switching it to the official container ( containrrr / watchtower )

That sounds like an excellent idea, indeed! I didn’t notice it was outdated and switching to using the official docker image seems like a no-brainer in this case.

@Hooverdan

Not sure all of them make sense in the context of “simplicity”.

I think you said it perfectly there as getting the right balance between simplicity and possibilities may be the most “difficult” part of a rock-on. On one hand, you’re tempted to surface as many options as possible to the user during the installation, but then you run the risk of unnecessarily complicating the install for most users with options they won’t use. I’ve personally never found a one-size fits all solution to this, so I’m always trying to ask myself:

1. what will benefit all users, and not just a portion of them?
2. would the added feature brought by this specific parameter outweigh the “complexity” brought by asking the user to set it up.

Of course, improving the rock-ons framework to make this kind of choice a lot less difficult is an important solution to the problem and this is also part of what I’ve been trying to work on–on this topic, I’m excited to see you found a great use for the ability to set docker labels from the web-UI. There is a lot more left to do and improve, of course, and that includes the three points you listed:

@Hooverdan

• My assumption is that if I define an environment variable, I will have to provide a value for it and if I don’t, then the environment variable will be still be passed, albeit with an empty value. Is that correct, or if the value is blank, the environment variable doesn’t become part of the docker run command? The latter would work as well, since then the default value of a given variable will just be used by the container. Of course all this default value information on settings can be linked back to the developers’ documentation or embedded in the description/label texts, so a user would know what to put into the field, even if they didn’t want to use a particular option.

Currently, all environment variables defined in the rock-on json as “environment objects” are required to be filled and the rock-on install wizard will not let the user proceed to the next step if their corresponding field is left blank. This gives a lot of room for improvement, and your idea of setting a default value for each environment variable is a great one, and was already brought up by @magicalyak in the issue linked below:

add env default option for rockons

You’re also bringing an interesting point, however, to give the possibility to set an environment variable as optional. I can image a simple key:value setting in the json under the specific environment object to set an "optional": true/false flag. If true, the given environment variable can be left blank during the rock-on install wizard. Feel free to create an issue on the rockstor-core repo if you’d like.

@Hooverdan

Like for the port definition, is there the ability to define a default value (most of the environment variables in the WatchTower setup have default values, aka, if they are not passed during startup the options/environment variables behave according to the default value). since the above example has quite a few options that can be considered/configured, but the majority of users might need only one or two options for most use cases.

Not yet (see above), but definitively needs to be implemented. I do see one potential drawback from this, however, in that it may open the gates to rock-ons with a myriad of options surfaced to the user during the rock-on install wizard. This would go against the “simplicity” principle of rock-ons and would thus still represent another example of the difficult choices to make between “simplicity” and “possibilities” I mentioned earlier in my message. I’d like to take the opportunity to point to an idea written up by @phillxnet a little while ago regarding creating a very simple “one click / auto-install” button. There are a lot steps before we can get to this, however–and the points you raised are one of them–but this would greatly help with keeping a sane balance.

Next phase of Rock-on framework improvements

I currently like how the existing system works as it leads users into separating each of their docker install’s config and data. But yes this is a little over the top for many and a little ping pong on the user interface. I suggest that we leave the existing rock-ons-root config as it is as that is only a one off anyway. Only obvious addition is an auto option / button, ie:- Currently we have the explanation header and the selection of the “Root Share”. In the circumstance where there is only…

@Hooverdan

• Can I pass a container label as part of the json definition to the RockOn? Or is that only possible after it has been set up using the standard functionality in the RockOn screens?

Currently in Rockstor, a label can be applied only after the rock-on install, as part of the post-install customization. The only way to do so in the json would be to use the "options" object, but you would of course not be able to let the user choose the value of the label. I actually wondered whether I should do that when I implemented the feature, but given docker labels are typically used as customization to a container and communication between containers that can happen on any container, it made more sense to me to set it as a post-install customization rather than a JSON setting. I also couldn’t really find a scenario in which a container label needed to be set at install for all users, which heavily factored in my decision. I would be happy to be proven wrong, of course, in which case we can implement a JSON approach as well.

As mentioned at the beginning of my post, I purposely tried to remain general rather than more specific to watchtower as I believe the points you raised an important to the rock-ons framework in general. Let us know if you’d like a more watchtower-centric discussion, however, especially if you already have a JSON that is working well for you. I believe watchtower is a rather popular project so discussing this will the community may help decide what are the options needed and used by most. I may be totally wrong here as I’m not a user, but I hope it’ll help.

Thanks again for all your contributions, and I hope I was able to answer your questions.