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) as well as surfacing more of the additional options, which can be defined as environment variables (instead of having the options that are not visible to the user - https://containrrr.github.io/watchtower/arguments/). Not sure all of them make sense in the context of “simplicity”.e.g. a “debug” switch cannot easily be used to get verbose log entries without mucking with the json itself and “hard coding” it.
A couple of questions/clarification (I assume, @Flox will have most of the answers for that, but anybody please chime in):
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.
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.
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?
I am currently using my home-brewed RockOn json setup with most of the variables defined explicitly and it’s working well. I am also taking advantage of container labels to decide which RockOns should be updated or not.
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.
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.
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:
what will benefit all users, and not just a portion of them?
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:
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: https://github.com/rockstor/rockstor-core/issues/2012
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.
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.
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.
Thank you very much for your detailed answers. And I used watchtower as the example, as its API offers quite a few options, but at the same time also has them “defaulted” to most values.
I think in terms of the simplicity vs. surfacing available options, I think the ability to have default values for options could still allow for simplicity. If the 90% use case (or whatever that might be) follows specific settings (either via the hidden options in the json file) then even if they are shown but pre-populated with default values, the user can still just continue with the installation, because it will work even without making any changes to the default setup.
Another approach could possibly be, that in the screenflow a minimalist settings screen exists (like today) and then there would be the “advanced” options (but still having the default value functionality), so a user can then choose to hit the button or delve deeper into the advanced settings.
I do agree that there won’t be a one-size fits all while trying to balance a simple RockOn installation process. I do believe though you can get closer to it, once this feature can be realized:
I will create an issue for the optional environment variable setting.
The @phillxnet write-up on the next phase regarding one click install I think is the right direction. This is along the lines that I was thinking: a default, fast install, and a “detailed” configuration path … that might be very ambitious though
On the container label: for me (and the watchtower use case I started with), the post-install assignment works fine.
As always, thank you for your insights and the work you do on this - especially since you do have a “real” job to spend the rest of your waking hours on.
I also cross-referenced the environment object default values issue (see above) in there, as these should probably be considered together, if one is already opening the hood to make changes.
Thanks a lot for your ideas, taking the time to create the issues, and for your feedback! All of these are very helpful and encouraging to pursue the work.
I agree that it is ambitious, but I do see this as entirely feasible if we have all the preparation work done first. The two issues you created are critical parts of this prep work and will make a feature such as the “auto-install button” a lot more easy to implement. I see it as a very good “end” goal that forces you to think about and prepare all the underlying elements correctly, which, in the end, might be the most important part.
Of course, the immediate priority is on the move to openSUSE but I’m hopeful to be able to get back to this part of Rockstor thereafter.
