I’m in the process of adding a new Rockon to the registry.
While I have managed to install it locally, a peculiar thing happend while installing…
Even though the ports are clearly stated in the JSON file what they should be set to by default, Rockstor decided to change two ports to some other port numbers!
I have checked with ss and my default ports were not in use!
The last two ports were changed from their default values “8088” and “8843”, respectively.
@aremiaskfa Thanks for the feedback.
Yes this is a little irritating and it would be nice to have it resolved. @Flox feedback on this would be good as they are more up on this mechanism than myself. We seem to hand on to prior used, but no longer used, ports and suggest ones on from them in error. Pretty sure this is at least a usability bug. And if we can pin it down further (the exact mechanism in code) we can likely sort it relatively easily.
Forgive my short and undocumented or verified reply for now; I’m on my phone but still wanted to briefly answer.
This actually seems to be one of Rockstor’s convenience features at play (@phillxnet, forgive me if I misunderstand here). If you look at the Rock-On framework wiki post that was linked above, you will see that Rockstor actually checks that the ports instructed to be used are available and not already used on the system. Indeed, if we go with already used ports, we’ll end up with conflicts (or Docker may actually even refuse to run the container). If a port number is found to be already defined in another Rock-On, it’ll bump it up by 1 and so on until it finds one available (not already defined in another Rock-On).
The two ports you mention are relatively common ones used in docker containers, so that’s probably why theybwere changed (if you search for these port numbers in the Rock-On registry repository, you should find at least another JSON with these numbers).
Now, for the weaknesses of that approach. While this worked very well in the early days of Rock-Ons where we had a relatively low number of Rock-Ons, we now have many Rock-Ons and thus forcing new ones to new numbers because of eventual conflicts with another Rock-On that the user would probably never use. That is of course unnecessarily burdensome to the user. We have had a similar discussion not too long ago and it was proposed to improve that port number bumping logic to only consider the Rock-Ons currently installed on the system. I’ll try to find that discussion again and link to it here.
Please forgive me if I’m misunderstanding the initial issue here, but I hope I could help nonetheless.
Agreed that we need a more comprehensive rework, and thank you for linking to your other thread as that is highly relevant. I’ll try to develop there as soon as possible .
… to improve that port number bumping logic to only consider the Rock-Ons currently installed on the system.
This makes sense from my end. I would only add one minor UI/UX thing: that when Rockstor decides to bump a port number, make it more visible to the user that such an automated change had happened.
If there are a lot of ports, one might not notice it was changed and expect the default ports.
.