In most cases, httpd based service will use 80 as the default port. in rhosp, dashboard used 80 too. so partner need to manually change port, and looks this is not a easy job for some partner. when partner run certification, how to change port confused some partner. Thinking is it possible to let redhat-certification use another port as the default one? Or give partner a assistant command to modify port used by redhat-certification?
It is possible, but just like why the dashboards use port 80, using anything else will require the user to have knowledge about where the service is found since they would have to then specify the port and it wouldn't appear by default. Some questions/points... rhcert webui is not needed on every node, is there a conflict for all nodes on port 80 or just controller nodes? we could optionally also support a path, like ~/rhcert; doing this would keep rhcert on port 80 but when there is some conflict it would then appear on a path. This would train people to use ~/rhcert which in theory would nearly always be available? Getting the rhcert in a container, makes it part of the container to define what port it runs on. This would be an easier way to change the port as this is natural in the start container world. We may also be able to do something like have a param which controls the port # and leave it at 80?
for now, merely openstack cert. per info from puna team, rhosp test doesn't support command line, and have to use web gui. The point is, we need to accept all-in-one setup. I personally prefer to give a param to controll part # first; 2nd, I vote to ~/rhcert; I will not choose container, as this require partner to have knowledge about how to use contrainer, this may bring new issue.
If memory serves, the openstack dashboard makes a mess of any httpd config that is there. Pragmatically, even if we change rhcert's apache config, the openstack dashboard may stomp all over it. I think we need to do some testing to figure this out. Containers to provide a way to map ports, which might be fairly easy to document depending on the role the node has in openstack. I don't really like the path approach, as it's cumbersome and has do be documented everywhere.