Hi @aremiaskfa ,
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.