[jbosstools-issues] [JBoss JIRA] (JBIDE-19178) Explorer, Servers view: Add logical view to OpenShift v3 explorer

[Andre Dietisheim (JIRA)]

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

Andre Dietisheim edited comment on JBIDE-19178 at 10/12/15 10:58 AM:
---------------------------------------------------------------------

In a mail from [~rcernich] on the 10th of September "JBoss Tools OpenShift Server Integration"

{quote}
The server framework in Eclipse has two main features:
 * Deployment - running a project on a server
 * Servers View - visualizing details about a server and facilitating management of the server

OpenShift is an intersting type of "server" since it's more of a platform for running servers (a server server?).  That said, it can be configured to support running specific types of user applications (projects?) through the use of builder images and templates.  Given that, I think there is an opportunity to use the capabilities feature within the servers framework to support the "Run on Server" functionality for OpenShift.  For example, if an OpenShift instance has the EAP, JWS and Ruby builder images installed, that OS instance can be marked as supporting EAP, JWS and Ruby project types.  (EAP and JWS are a bit peculiar since they support JEE project types, but you get the gist.)  This can then be used to integrate other aspects of the servers framework for OS.

At this point, I don't think we should get lost in the details regarding pods, containers, etc., but should keep it simple, similar to the basic new-app functionality: an app is a project and has a single service, a single dc with a single pod template (for those that need concrete, implementation details).  The user doesn't really need to know or care about what an application is, or that it's composed of these various objects within OS.  (We need to know this, but they don't.)  I won't get into this any further, as that was the purpose of my other email (what is required to support "run on server" for OS).  This pretty much covers the "deployment" case.

The servers view is more interesting because there are a few different approaches you can take to visualizing an OS instance:
 * object views (pods, dcs, etc.)
 * application views (don't shoot!)
 * node views (really just a container for object or application views)

>From an application developer's perspective, I don't think they should care about pods, services, dcs, etc.  They care about building an application.  The ops guys care about how/where it ends up running.  Because of this, I think forcing concepts like pods, etc. onto the application developer is not the best way to go as it's confusing and is pretty much orthogonal to their job responsibilities.  Given that, I'm a proponent of an application view, however application isnt' a clearly defined term within OS (a separate discussion).  Putting the general view concepts aside, we can focus on container objects running xpaas images (e.g. eap, jws, etc.).  If a container is running one of these images, we should be able to provide the same view below that container node that we provide for an eap, jws, etc. server in the servers view.  These views would be specific to each container running the image (in the event replicas > 1).

Diving into an "application view," in lieu of a concrete definition of application in openshift, I will propose a few definitions, for the purpose of advancing the tools:
 * All objects with the same value for an "application" label, e.g. application=foo == the foo application.  More generically, an application view could simply be a filtered view based on label key/value pairs, e.g. show all objects with label application=foo || deploymentConfig=bar.
 * A dc or rc, along with all objects referencing the dc, or objects within it.  For example, a dc, (dc-a) includes a pod template (pt-b) referencing an image (ist-c) built by a bc (bc-d), which is referenced by a service (s-e) through a label and is exposed via a route (r-f).  In this example, you'd assume the application is: dc dc-a, all deployments created from dc-a, all pods created from pt-b, image stream is-c, build config bc-d, all builds from bc-d, service s-e and route r-f.  Note, given the relationship between services and pods that it's possible a single service could be a part of many "applications."  Any objects not associated with a dc could be displayed in a "misc" or "raw" view (the latter could contain all objects, even if they're part of an "application").  What that might look like in a view:

A dc based application view.
* Applications
** Foo (the application root node; properties view might contain services and routes with actions like, open in browser)
*** instance-1 (an instance of the application, i.e. the container running the application)
*** instance-2
*** OpenShift
*** ...related OpenShift objects, organized as they would be for a generic OpenShift view.

A labels filter based approach:
* root
** Deployments
*** Deployment-a
**** pod-a
***** instance 1
****** container 1 (properties might show the specific build)
***** pod-b
** Services
*** service-a (properties view might expose related routes)
** Builds
*** Config-a
**** build-1

Hopefully, that's enough to give you some idea what I'm thinking.  I don't know how this aligns with others' views on the subject.  I suspect there's some overlap with what's displayed in the OS console too (which might also want to consider alternate views structured for application developers as opposed to operations folks).

Just some ideas.

Feel free to CC other folks or lists.  (I just wanted to keep it contained at first and didn't want this to turn into a spam generator.)

Rob
{quote}


was (Author: adietish):
In a mail from [~rcernich] on the 10th of September "JBoss Tools OpenShift Server Integration"

{quote}
The server framework in Eclipse has two main features:
 * Deployment - running a project on a server
 * Servers View - visualizing details about a server and facilitating management of the server

OpenShift is an intersting type of "server" since it's more of a platform for running servers (a server server?).  That said, it can be configured to support running specific types of user applications (projects?) through the use of builder images and templates.  Given that, I think there is an opportunity to use the capabilities feature within the servers framework to support the "Run on Server" functionality for OpenShift.  For example, if an OpenShift instance has the EAP, JWS and Ruby builder images installed, that OS instance can be marked as supporting EAP, JWS and Ruby project types.  (EAP and JWS are a bit peculiar since they support JEE project types, but you get the gist.)  This can then be used to integrate other aspects of the servers framework for OS.

At this point, I don't think we should get lost in the details regarding pods, containers, etc., but should keep it simple, similar to the basic new-app functionality: an app is a project and has a single service, a single dc with a single pod template (for those that need concrete, implementation details).  The user doesn't really need to know or care about what an application is, or that it's composed of these various objects within OS.  (We need to know this, but they don't.)  I won't get into this any further, as that was the purpose of my other email (what is required to support "run on server" for OS).  This pretty much covers the "deployment" case.

The servers view is more interesting because there are a few different approaches you can take to visualizing an OS instance:
 * object views (pods, dcs, etc.)
 * application views (don't shoot!)
 * node views (really just a container for object or application views)

>From an application developer's perspective, I don't think they should care about pods, services, dcs, etc.  They care about building an application.  The ops guys care about how/where it ends up running.  Because of this, I think forcing concepts like pods, etc. onto the application developer is not the best way to go as it's confusing and is pretty much orthogonal to their job responsibilities.  Given that, I'm a proponent of an application view, however application isnt' a clearly defined term within OS (a separate discussion).  Putting the general view concepts aside, we can focus on container objects running xpaas images (e.g. eap, jws, etc.).  If a container is running one of these images, we should be able to provide the same view below that container node that we provide for an eap, jws, etc. server in the servers view.  These views would be specific to each container running the image (in the event replicas > 1).

Diving into an "application view," in lieu of a concrete definition of application in openshift, I will propose a few definitions, for the purpose of advancing the tools:
 * All objects with the same value for an "application" label, e.g. application=foo == the foo application.  More generically, an application view could simply be a filtered view based on label key/value pairs, e.g. show all objects with label application=foo || deploymentConfig=bar.
 * A dc or rc, along with all objects referencing the dc, or objects within it.  For example, a dc, (dc-a) includes a pod template (pt-b) referencing an image (ist-c) built by a bc (bc-d), which is referenced by a service (s-e) through a label and is exposed via a route (r-f).  In this example, you'd assume the application is: dc dc-a, all deployments created from dc-a, all pods created from pt-b, image stream is-c, build config bc-d, all builds from bc-d, service s-e and route r-f.  Note, given the relationship between services and pods that it's possible a single service could be a part of many "applications."  Any objects not associated with a dc could be displayed in a "misc" or "raw" view (the latter could contain all objects, even if they're part of an "application").  What that might look like in a view:

A dc based application view.
+ Applications
  + Foo (the application root node; properties view might contain services and routes with actions like, open in browser)
    + instance-1 (an instance of the application, i.e. the container running the application)
    + instance-2
    + OpenShift
      + ...related OpenShift objects, organized as they would be for a generic OpenShift view.

A labels filter based approach:
+ root
  + Deployments
    + Deployment-a
      + pod-a
        + instance 1
          + container 1 (properties might show the specific build)
      + pod-b
  + Services
    + service-a (properties view might expose related routes)
  + Builds
    + Config-a
      + build-1

Hopefully, that's enough to give you some idea what I'm thinking.  I don't know how this aligns with others' views on the subject.  I suspect there's some overlap with what's displayed in the OS console too (which might also want to consider alternate views structured for application developers as opposed to operations folks).

Just some ideas.

Feel free to CC other folks or lists.  (I just wanted to keep it contained at first and didn't want this to turn into a spam generator.)

Rob
{quote}

> Explorer, Servers view: Add logical view to OpenShift v3 explorer
> -----------------------------------------------------------------
>
>                 Key: JBIDE-19178
>                 URL: https://issues.jboss.org/browse/JBIDE-19178
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: openshift
>    Affects Versions: 4.3.0.Alpha1
>            Reporter: Jeff Cantrill
>              Labels: explorer, openshift_v3
>             Fix For: 4.3.x
>
>         Attachments: Console of 'App' with the pieces wired.png, Pipeline view mockup.bmml, Pipeline view mockup.png
>
>
> Add an alternate view in the openshift v3 explorer to try to 'link' resources in a similiar fashion to the web console



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