[ https://issues.jboss.org/browse/JBIDE-19178?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-19178 at 10/14/15 8:33 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) 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). {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) 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). {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)