[jbosstools-issues] [JBoss JIRA] (JBIDE-20764) Create Server Adapter for OpenShift 3 applications

[Andre Dietisheim (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-20764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117420#comment-13117420 ] 

Andre Dietisheim edited comment on JBIDE-20764 at 10/12/15 3:34 PM:
--------------------------------------------------------------------

in a mail by [~rcernich] on the 10th of August "JBoss OpenShift Dev/Debug Requirements"

{quote}
I'm guessing the ideal flow is for users to simply right-click a project and "Run/Debug As => OpenShift Application."  The following details would then need to be specified (or inferred from the project):
 * OpenShift instance
 * OpenShift project
 * "Application" name (default to project name)
 * Server type (e.g. EAP, JWS, etc.; default based on project type, e.g. war=eap)
 * Base image (e.g. eap64-openshift, webserver30-tomcat7-openshift, etc.; default based on app-type)
 * Deployment directory (discover from image)
 * Debug port (discover from image) (via DEBUG docker env var)

Given that, we would create an application on OS containing a dc, a service and a route.  The dc comes up, the deployment is sync'd.  You'd have to decide whether you'd want to remove the objects when the application is stopped.

The next use case might be to attach to an already running instance, which should be a lot less complicated.  The only detail I see missing here is possibly having to configure debug on the pod (so the debug port on the server becomes available).

Extracting some requirements based on the above, I think we end up needing the following:
 * label specifying deployment directory (already exists: org.jboss.deployments-dir)
 * label specifying debug port
 * flag enabling debug (to expose the debug port on the server/jvm)
 * flag enabling "hot deploy" 
{quote}
via possibility to mount /deployments -> upstream k8s issue where containers can be modified, committed and pushed to registry)
{quote}
 * label specifying server type (currently env variables: JBOSS_PRODUCT, JBOSS_EAP_VERSION)
{quote}
There's no consensus yet whether docker labels or openshift annotation shall be used, while it seems annotations are what is preferred for tools. Then uncertain is whether docker labels are propagated (while they apparently should) to openshift annotations.
{quote}
Complications:
 * Networking - How do you connect to the debug port?  Is that a service?  Do we go through a route using SNI?
 * Creating the image - Do we create a dummy image, then rsync the contents?  Do we create an image locally and push it to the OS registry?
 * Permissions - Are there any special permissions that users would need to have to enable debugging, opening ports, etc.?
 * Committing the image - How do we want to handle changes that a user might make to an image: drop them, commit them?

More fun stuff:
 * Could we enable existing "servers view" content off of pod nodes (e.g. EAP view, but rooted at a pod instead of server)?
 * What about source types beyond git (e.g. curl, blob, rsync, empty)?
{quote}


was (Author: adietish):
in a mail by [~rcernich] on the 10th of August "JBoss OpenShift Dev/Debug Requirements"

{quote}
I'm guessing the ideal flow is for users to simply right-click a project and "Run/Debug As => OpenShift Application."  The following details would then need to be specified (or inferred from the project):
 * OpenShift instance
 * OpenShift project
 * "Application" name (default to project name)
 * Server type (e.g. EAP, JWS, etc.; default based on project type, e.g. war=eap)
 * Base image (e.g. eap64-openshift, webserver30-tomcat7-openshift, etc.; default based on app-type)
 * Deployment directory (discover from image)
 * Debug port (discover from image) (via DEBUG docker env var)

Given that, we would create an application on OS containing a dc, a service and a route.  The dc comes up, the deployment is sync'd.  You'd have to decide whether you'd want to remove the objects when the application is stopped.

The next use case might be to attach to an already running instance, which should be a lot less complicated.  The only detail I see missing here is possibly having to configure debug on the pod (so the debug port on the server becomes available).

Extracting some requirements based on the above, I think we end up needing the following:
 * label specifying deployment directory (already exists: org.jboss.deployments-dir)
 * label specifying debug port
 * flag enabling debug (to expose the debug port on the server/jvm)
 * flag enabling "hot deploy" (via possibility to mount /deployments -> upstream k8s issue where containers can be modified, committed and pushed to registry)
 * label specifying server type (currently env variables: JBOSS_PRODUCT, JBOSS_EAP_VERSION)

Complications:
 * Networking - How do you connect to the debug port?  Is that a service?  Do we go through a route using SNI?
 * Creating the image - Do we create a dummy image, then rsync the contents?  Do we create an image locally and push it to the OS registry?
 * Permissions - Are there any special permissions that users would need to have to enable debugging, opening ports, etc.?
 * Committing the image - How do we want to handle changes that a user might make to an image: drop them, commit them?

More fun stuff:
 * Could we enable existing "servers view" content off of pod nodes (e.g. EAP view, but rooted at a pod instead of server)?
 * What about source types beyond git (e.g. curl, blob, rsync, empty)?
{quote}

> Create Server Adapter for OpenShift 3 applications
> --------------------------------------------------
>
>                 Key: JBIDE-20764
>                 URL: https://issues.jboss.org/browse/JBIDE-20764
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: openshift
>    Affects Versions: 4.3.0.CR1
>            Reporter: Fred Bricon
>            Assignee: Andre Dietisheim
>            Priority: Critical
>              Labels: new_and_noteworthy, openshift_v3
>             Fix For: 4.3.1.Final
>
>
> get the actions available on OpenShift 3 resources in openshift explorer so you don't necessarily have to jump between the various views to work with openshift apps. This matches an existing feature in OpenShift 2. Upon project creation, a "Create server adapter" checkbox should be displayed.
> Server status= matching deployment pod status
> Possible menus:
> - Start/Stop
> - Show Web Console
> - Port Forwarding
> - Stream logs
> [~maxandersen] can you think of anything else?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)