![]() ![]() If the webUI port (if applicable) is unpublished, the webUI button displayed in the Rock-ons summary page would not work anymore. Should we offer the possibility to edit the container port as well (or leave this for a future and separate issue/PR)?ģ. let user choose to not expose the port (if desired) via checkbox (such checkbox would be checked by default)Ģ. If one chooses to unpublish a port, I can see three possibilities: In the future, we may work on adding the possibility to create the network from here, as an enhancement.ġ. On the next step (or below this one), one may attach the Rock-on's container(s) to one or more pre-existing docker networks. This could be implemented on the Rock-on customization dialog next to the other customization options currently existing (see below).Ĭlicking on the "Ports" button would lead to a dialog to edit all ports: > I would actually like to see an option to export or not the ports in the GUI, _then_ we would have a use for network creation and joining.Īs a result, we can offer an advanced post-install customization option to advanced users to un-publish predefined ports and then join docker networks of interest. Indeed, as described by in the issue referenced above (), joining a docker network would be useful/required only if predefined ports are not published: In order to make custom docker networks (described in #2009) useful, we need to create an interface to edit the ports described in a Rock-on JSON file. It is meant as tracking and discussion material for a work currently **in progress**. ![]() This issue relates to step 3 of Rock-ons networking work described in #1982, and … follows steps 1 (#2003) and 2 (#2009). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |