[JBoss JIRA] (JBIDE-25504) Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25504?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25504:
------------------------------------------
[~rhuss] ok, thx for getting back. I'll reach out about this then.
> Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25504
> URL: https://issues.jboss.org/browse/JBIDE-25504
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.2.AM2
> Reporter: Jeff MAURY
> Assignee: Andre Dietisheim
> Labels: openshift, openshift_v3, server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: springboot-dependencies.zip
>
>
> When a SpringBoot application is being deployed on OpenShift with the server adapter, we should support the following use case:
> * the SpringBoot app has a dependency which is avalailable in the workspace
> * when a modifiction is done on the dependency code, it should be synced to OpenShift by the server adapter
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25903) OpenShift: Deploy Image to OpenShift - pointless Help button
by Josef Kopriva (JIRA)
Josef Kopriva created JBIDE-25903:
-------------------------------------
Summary: OpenShift: Deploy Image to OpenShift - pointless Help button
Key: JBIDE-25903
URL: https://issues.jboss.org/browse/JBIDE-25903
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: docker, openshift
Affects Versions: 4.5.3.Final
Environment: F28
Reporter: Josef Kopriva
Assignee: Andre Dietisheim
Priority: Minor
Attachments: image-2018-04-05-08-19-09-880.png
!image-2018-04-05-08-19-09-880.png|thumbnail!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25901) MINISHIFT_HOME is not propagated to new detected cdk binary properly
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25901?page=com.atlassian.jira.plugi... ]
Martin Malina edited comment on JBIDE-25901 at 4/5/18 2:18 AM:
---------------------------------------------------------------
[~rob.stryker] the main problem here is that you never told anybody about those choices that you made. I may admit that it makes sense, but I cannot guess how you made things work - I was operating under the assumption that we honor $MINISHIFT_HOME at all times. So when I see it not being the case what do I do? I report a bug!
So this is not about me feeling it should work one way or the other. This is about me inferring the correct behavior based on the information you gave me previously.
OK, now about minishift home. You're right that the situation is not ideal. Especially for the use case of avoiding the CLI altogether (i.e. when downloading using runtime detection) it seems to make sense to make up a unique minishift home directory for each new binary/adapter. But in another case it may be desirable. Consider this scenario: You're all set in CLI - you have your custom $MINISHIFT_HOME and a cdk binary somewhere. You start devstudio and search your cdk dir or start creating a cdk server adapter manually - in both cases it would be preferable to use the $MINISHIFT_HOME variable. So now which one is more common - to have multiple cdk adapters where we don't want to use one minishift home path for all of them OR users having $MINISHIFT_HOME setup and dealing with just one cdk binary. I'm afraid I cannot answer this one with high level of confidence, but I would guess that multiple cdk binaries/adapters is not a common setup for our end users.
One more question: Can you please sum up the use cases where having $MINISHIFT_HOME will make a difference? I just did a quick test to see what happens if I have that and install devstudio and then run it. The result was that runtime detection had both paths - ~/.minishift and $MINISHIFT_HOME. Is that intended? What are the other use cases for $MINISHIFT_HOME? Thanks!
was (Author: mmalina):
[~rob.stryker] the main problem here is that you never told anybody about those choices that you made. I may admit that it makes sense, but I cannot guess how you made things work - I was operating under the assumption that we honor $MINISHIFT_HOME at all times. So when I see it not being the case what do I do? I report a bug!
So this is not about me feeling it should work one way or the other. This is about me inferring the correct behavior based on the information you gave me previously.
OK, now about minishift home. You're right that the situation is not ideal. Especially for the use case of avoiding the CLI altogether (i.e. when downloading using runtime detection) it seems to make sense to make up a unique minishift home directory for each new binary/adapter. But in another case it may be desirable. Consider this scenario: You're all set in CLI - you have your custom $MINISHIFT_HOME and a cdk binary somewhere. You start devstudio and search your cdk dir or start creating a cdk server adapter manually - in both cases it would be preferable to use the $MINISHIFT_HOME variable. So now which one is more common - to have multiple cdk adapters where we don't want to use one minishift home path for all of them OR users having $MINISHIFT_HOME setup and dealing with just one cdk binary. I'm afraid I cannot answer this one with high level of confidence, but I would guess that multiple cdk binaries/adapters is not a common setup for our end users.
One more question: Can you please some up the use cases where having $MINISHIFT_HOME will make a difference? I just did a quick test to see what happens if I have that and install devstudio and then run it. The result was that runtime detection had both paths - ~/.minishift and $MINISHIFT_HOME. Is that intended? What are the other use cases for $MINISHIFT_HOME? Thanks!
> MINISHIFT_HOME is not propagated to new detected cdk binary properly
> --------------------------------------------------------------------
>
> Key: JBIDE-25901
> URL: https://issues.jboss.org/browse/JBIDE-25901
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, runtime-detection
> Affects Versions: 4.5.3.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> Following some of the changes to how cdk and runtime detection works (most notably that path to cdk binary can now be used for searching), I wanted to try and see if $MINISHIFT_HOME is still respected and works properly. And it seems to fail.
> I started devstudio with MINISHIFT_HOME=/Users/rasp/minishift_home, then ran runtime detection against /Users/rasp/tmp where a cdk binary was found. But the newly created adapter had this set up as minishift home: /Users/rasp/tmp/MINISHIFT_HOME
> That seems totally wrong.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-24436) Deploy wizard: dialog expands to full available vertical space
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24436?page=com.atlassian.jira.plugi... ]
Josef Kopriva closed JBIDE-24436.
---------------------------------
Assignee: Josef Kopriva
Resolution: Out of Date
[~adietish] Closing, I was not able to reproduce it.
> Deploy wizard: dialog expands to full available vertical space
> --------------------------------------------------------------
>
> Key: JBIDE-24436
> URL: https://issues.jboss.org/browse/JBIDE-24436
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.4.Final
> Reporter: Andre Dietisheim
> Assignee: Josef Kopriva
> Priority: Minor
> Labels: deploy_docker_wizard, openshift_v3
> Fix For: 4.5.3.Final
>
> Attachments: deploy-image-wizard-too-tall.png
>
>
> steps:
> # ASSERT: have a docker image available in your local docker daemon
> # ASSERT: have docker tooling installed and a connection to your local docker daemon defined
> # EXEC: open "Docker Explorer" view, unfold "Images" for the conneciton to your local docker daemon
> # EXEC: select your docker image and pick "Deploy to OpenShift..."
> Result:
> Docker Image deploy wizard pops up, taking all the available vertical space
> !deploy-image-wizard-too-tall.png!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-24436) Deploy wizard: dialog expands to full available vertical space
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24436?page=com.atlassian.jira.plugi... ]
Josef Kopriva updated JBIDE-24436:
----------------------------------
Fix Version/s: 4.5.3.Final
(was: 4.5.x)
> Deploy wizard: dialog expands to full available vertical space
> --------------------------------------------------------------
>
> Key: JBIDE-24436
> URL: https://issues.jboss.org/browse/JBIDE-24436
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.4.Final
> Reporter: Andre Dietisheim
> Priority: Minor
> Labels: deploy_docker_wizard, openshift_v3
> Fix For: 4.5.3.Final
>
> Attachments: deploy-image-wizard-too-tall.png
>
>
> steps:
> # ASSERT: have a docker image available in your local docker daemon
> # ASSERT: have docker tooling installed and a connection to your local docker daemon defined
> # EXEC: open "Docker Explorer" view, unfold "Images" for the conneciton to your local docker daemon
> # EXEC: select your docker image and pick "Deploy to OpenShift..."
> Result:
> Docker Image deploy wizard pops up, taking all the available vertical space
> !deploy-image-wizard-too-tall.png!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-23512) Properties: Header hidden by another header is not retrievable
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23512?page=com.atlassian.jira.plugi... ]
Josef Kopriva commented on JBIDE-23512:
---------------------------------------
[~adietish] yes, I am able to reproduce it on F28.
> Properties: Header hidden by another header is not retrievable
> --------------------------------------------------------------
>
> Key: JBIDE-23512
> URL: https://issues.jboss.org/browse/JBIDE-23512
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.2.Final
> Reporter: Marián Labuda
> Priority: Minor
> Labels: openshift_v3, properties
> Fix For: 4.5.x
>
> Attachments: out-1.ogv, properties.ogv
>
>
> Table header in Properties for OpenShift 3 resources can be moved/resized. If I resize a header to beginning of another header, the another header is hidden and I cant resize is back or retrieve the second header with its column. See video for more details
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25504) Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
by Roland Huß (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25504?page=com.atlassian.jira.plugi... ]
Roland Huß commented on JBIDE-25504:
------------------------------------
[~adietish] sorry, I have no idea really. And I'm probably also not the right person to ask for as I'm not that deep into Spring (as it really looks like an intrinsis Spring Boot problem). But maybe the RHOAR guys can help here ?
> Support hot deploy for workspace dependencies for SpringBoot applications on OpenShift
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25504
> URL: https://issues.jboss.org/browse/JBIDE-25504
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.2.AM2
> Reporter: Jeff MAURY
> Assignee: Andre Dietisheim
> Labels: openshift, openshift_v3, server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: springboot-dependencies.zip
>
>
> When a SpringBoot application is being deployed on OpenShift with the server adapter, we should support the following use case:
> * the SpringBoot app has a dependency which is avalailable in the workspace
> * when a modifiction is done on the dependency code, it should be synced to OpenShift by the server adapter
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBDS-3846) Create container oriented perspective
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3846?page=com.atlassian.jira.plugin.... ]
Denis Golovin edited comment on JBDS-3846 at 4/4/18 11:33 PM:
--------------------------------------------------------------
[~jeffmaury]OpenShift deserves to have a dedicated Perspective, would be good to have a perspective where all related/used in relation to OpenShift Views are present. Would be good starting point for OpenShift related cheatsheets "Open OpenShift Perspective". I can help to make that happened in next release.
was (Author: dgolovin):
[~jeffmaury]IOpenShift deserves to have a dedicated Perspective, would be good to have a perspective where all related/used in relation to OpenShift Views are present. Would be good starting point for OpenShift related cheatsheets "Open OpenShift Perspective". I can help to make that happened in next release.
> Create container oriented perspective
> -------------------------------------
>
> Key: JBDS-3846
> URL: https://issues.jboss.org/browse/JBDS-3846
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: cdk, docker, openshift
> Affects Versions: 10.0.0.Alpha1
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Priority: Critical
> Fix For: 11.x
>
>
> At the moment we have only JBoss perspective. We should create a new, more container oriented perspective, where Docker Explorer view would be opened by default and other views should be added and aligned to satisfy user needs. Layout of perspective should be more focused on container development.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBDS-3846) Create container oriented perspective
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3846?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3846:
-------------------------------------
[~jeffmaury]IOpenShift deserves to have a dedicated Perspective, would be good to have a perspective where all related/used in relation to OpenShift Views are present. Would be good starting point for OpenShift related cheatsheets "Open OpenShift Perspective". I can help to make that happened in next release.
> Create container oriented perspective
> -------------------------------------
>
> Key: JBDS-3846
> URL: https://issues.jboss.org/browse/JBDS-3846
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: cdk, docker, openshift
> Affects Versions: 10.0.0.Alpha1
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Priority: Critical
> Fix For: 11.x
>
>
> At the moment we have only JBoss perspective. We should create a new, more container oriented perspective, where Docker Explorer view would be opened by default and other views should be added and aligned to satisfy user needs. Layout of perspective should be more focused on container development.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25902) OpenShift Delete Resources is not deleting all selected resources
by Denis Golovin (JIRA)
Denis Golovin created JBIDE-25902:
-------------------------------------
Summary: OpenShift Delete Resources is not deleting all selected resources
Key: JBIDE-25902
URL: https://issues.jboss.org/browse/JBIDE-25902
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.5.3.AM3
Environment: Windows 10 Pro
Reporter: Denis Golovin
Attachments: delete-resources.gif
Delete Resources dialog would not delete all selected resources at once. For example for jenkins service created from Jenkins docker image that would require to run dialog three times to get all jenkins service related resources deleted. It looks like it does matter in waht order resources are deleted.
!delete-resources.gif!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months