[
https://issues.jboss.org/browse/JBIDE-23352?page=com.atlassian.jira.plugi...
]
Andre Dietisheim edited comment on JBIDE-23352 at 11/4/16 10:01 AM:
--------------------------------------------------------------------
We maybe also should get rid of the add/remove/edit ports capability. See the discussion
here:
https://issues.jboss.org/browse/JBIDE-23368?focusedCommentId=13317423&...
{quote}
This was originally added because even though an image metadata does not indicate an image
will be listening on a port, it still could be. For example, a debug port is open but I
did not explicitly declare it in the dockerfile. Adding still allows you to configure a
service that will expose the port. However, Andre Dietisheim and I had a long discussion
about this issue and I believe we agreed on doing one of the following:
* Remove the functionality all together to be consistent with the web ui
* Modify button desc, add text to explain the ramifications, update the table to make it
obvious these ports are not exposed
I'm not certain what the right direction is other then we should probably follow the
web and console as examples. You could always make the argument that a user can manually
edit a service if an image does not explicitly expose ports. This seems reasonable to me.
{quote}
was (Author: adietish):
We maybe also should get rid of the add/remove/edit ports capability. See the discussion
here:
https://issues.jboss.org/browse/JBIDE-23368?focusedCommentId=13317423&...
{quote}
This was originally added because even though an image metadata does not indicate an image
will be listening on a port, it still could be. For example, a debug port is open but I
did not explicitly declare it in the dockerfile. Adding still allows you to configure a
service that will expose the port. However, Andre Dietisheim and I had a long discussion
about this issue and I believe we agreed on doing one of the following:
* Remove the functionality all together to be consistent with the web ui
* Modify button desc, add text to explain the ramifications, update the table to make it
obvious these ports are not exposed
I'm not certain what the right direction is other then we should probably follow the
web and console as examples. You could always make the argument that a user can manually
edit a service if an image does not explicitly expose ports. This seems reasonable to me.
{quote}
Deploy Docker Wizard: Default routing port selection need more info
for users
-----------------------------------------------------------------------------
Key: JBIDE-23352
URL:
https://issues.jboss.org/browse/JBIDE-23352
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.1.AM2
Reporter: Marián Labuda
Labels: deploy_docker_wizard, openshift_v3
Fix For: 4.4.2.AM3
Attachments: no_route_selected.png, refdoc-services-1.png, refdoc-services-2.png,
webui-deploy-docker-image.png
In the wizard on wizard page Services & Routing Settings, there is a table with
mapped ports. No port is selected by default , but OpenShift knows what to open.
If there is only one port mapping, we could check it by default. If there are more port
mappings, we could show a label/info/description what is gonna be done under the hood, so
users will know what is happening.
steps to reproduce:
# EXEC: In Docker Explroer: pick an image and choose "Deploy to OpenShift..."
in the context menu
# EXEC: get to the "Services & Routing Settings" page
!no_route_selected.png!
It's not obvious to the user what the wizard will create: A service that
"exposes" pod ports and a route that points to this service. Furthermore
it's not obvious that without a "checked" (used by route) port, the route
will round-robin through the available ports. Additionally we should show the user what
ports are exposed by the pod, and which ones are ports that the user added while no
explicit exposure is defined in the pod (so he's on his own, if there's nothing
listening on them he'll have users face non-functional or no reposonses at all).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)