[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 commented on JBIDE-25901:
---------------------------------------
[~adietish] we're discussing this issue with Rob ATM and we ended up agreeing that probably not that much needs to change. Once we're done we will sum up the current functionality and add it to https://issues.jboss.org/browse/RHDEVDOCS-724 to be documented.
As to what $MINISHIFT_HOME is for: In CLI, by default, ~/.minishift is used for storing of all the data, but you can change this by defining your MINISHIFT_HOME env var and pointing it to another directory. That way minishift/cdk will use that directory instead.
There was a feature request a while back to support this variable in devstudio, i.e. use the custom directory instead of the default (if $MINISHIFT_HOME is set for the Eclipse process). But it turns out that this is quite a pain to do right - you don't always want to use this, especially if you download a new CDK binary directly in Eclipse.
> 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)
8 years
[JBoss JIRA] (JBIDE-25901) MINISHIFT_HOME is not propagated to new detected cdk binary properly
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25901?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25901:
------------------------------------------
[~mmalina] I'm a bit of a noob in this area, what is the purpose of $MINISHIFT_HOME? How is your setup affected if this variable isnt set properly?
> 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)
8 years
[JBoss JIRA] (JBIDE-25871) Server adapter: spring-boot-camel-xml adapter cannot rsync: no rsync nor tar available
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25871?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25871:
------------------------------------------
I currently experience odd behaviours with OSO east2, the camel/springboot demo app template is not fully executing, it won't create the service. When then trying to remove the partial resources nothing happens, in Eclipse and in Web UI.
> Server adapter: spring-boot-camel-xml adapter cannot rsync: no rsync nor tar available
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-25871
> URL: https://issues.jboss.org/browse/JBIDE-25871
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.5.2.AM3
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: rsync, server_adapter, springboot
> Fix For: 4.5.3.Final
>
> Attachments: fuse-on-openshift.zip, pod-running.png, rsync-fails.png
>
>
> # ASSERT: have project *camel-ose-springboot-xml* imported to your workspace (from attached archive fuse-on-openshift)
> # ASSERT: have a connection to https://console.starter-us-east-2.openshift.com with a project *<username>-stage*
> # EXEC: deploy project *camel-ose-springboot-xml* project via fabric-8 maven plugin:
> {code}
> mvn clean install fabric8:deploy \
> -Dkubernetes.master=https://console.starter-us-east-2.openshift.com \
> -Dkubernetes.namespace=adietish-stage \
> -Dkubernetes.auth.basic.username=<username> \
> -Dkubernetes.auth.basic.password=<password> \
> -Dfabric8.mode=openshift \
> -Dkubernetes.trust.certificates=true \
> -Dfabric8.build.strategy=s2i \
> -Dkubernetes.auth.tryServiceAccount=false \
> -Dfabric8.generator.from=fabric8/s2i-java \
> -Dfabric8.generator.fromMode=docker \
> -Dkubernetes.auth.tryKubeConfig=false
> {code}
> # ASSERT: you have a pod running for a service *camel-ose-springboot-xml*
> !pod-running.png!
> # EXEC: create a server adapter for your service *camel-ose-springboot-xml*
> # ASSERT: adapter starts automatically and starts to sync local project to OpenShift
> Result:
> RSync fails, you're told that the container has no strategy for syncing, neither rsync nor tar are available.
> !rsync-fails.png!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBIDE-25672) Server adapter: spring-boot-camel-xml adapter throws "null" error when starting (open.paas.redhat.com)
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25672?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25672:
------------------------------------------
[~dbocharov] please rievew https://github.com/jbosstools/jbosstools-openshift/pull/1717. Thx!
> Server adapter: spring-boot-camel-xml adapter throws "null" error when starting (open.paas.redhat.com)
> ------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-25672
> URL: https://issues.jboss.org/browse/JBIDE-25672
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.5.2.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: image-2018-01-29-15-48-29-101.png
>
>
> # ASSERT: have a connection to open.paas.redhat.com
> # EXEC: create a new app based on the "s2i-spring-boot-camel-xml" template. Have the project imported to your workspace and the server adapter created
> # ASSERT: a server adapter "s2i-spring-boot-camel-xml" is created
> # EXEC: wait for the adapter to get "[started]"
> Result:
> After some waiting time the adapter throws the following error:
> !image-2018-01-29-15-48-29-101.png!
> In the Eclipse log you find the following:
> {code}
> !MESSAGE Could not launch server s2i-spring-boot-camel-xml (DeploymentConfig) at OpenShift 3 (open.paas.redhat.com)
> !STACK 0
> org.eclipse.core.runtime.AssertionFailedException: null argument:
> at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
> at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73)
> at org.jboss.tools.openshift.internal.core.server.debug.DebugContext.<init>(DebugContext.java:64)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftLaunchController.createDebugContext(OpenShiftLaunchController.java:199)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftLaunchController.launch(OpenShiftLaunchController.java:93)
> at org.jboss.ide.eclipse.as.wtp.core.server.launch.ControllableServerLaunchConfiguration.launch(ControllableServerLaunchConfiguration.java:52)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3566)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3502)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:377)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JBIDE-25672) Server adapter: spring-boot-camel-xml adapter throws "null" error when starting (open.paas.redhat.com)
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25672?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25672:
------------------------------------------
I cannot reproduce this any longer. So I went for improving the error message which should by itself improve the user experience: https://github.com/jbosstools/jbosstools-openshift/pull/1717
> Server adapter: spring-boot-camel-xml adapter throws "null" error when starting (open.paas.redhat.com)
> ------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-25672
> URL: https://issues.jboss.org/browse/JBIDE-25672
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.5.2.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: server_adapter
> Fix For: 4.5.3.Final
>
> Attachments: image-2018-01-29-15-48-29-101.png
>
>
> # ASSERT: have a connection to open.paas.redhat.com
> # EXEC: create a new app based on the "s2i-spring-boot-camel-xml" template. Have the project imported to your workspace and the server adapter created
> # ASSERT: a server adapter "s2i-spring-boot-camel-xml" is created
> # EXEC: wait for the adapter to get "[started]"
> Result:
> After some waiting time the adapter throws the following error:
> !image-2018-01-29-15-48-29-101.png!
> In the Eclipse log you find the following:
> {code}
> !MESSAGE Could not launch server s2i-spring-boot-camel-xml (DeploymentConfig) at OpenShift 3 (open.paas.redhat.com)
> !STACK 0
> org.eclipse.core.runtime.AssertionFailedException: null argument:
> at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
> at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73)
> at org.jboss.tools.openshift.internal.core.server.debug.DebugContext.<init>(DebugContext.java:64)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftLaunchController.createDebugContext(OpenShiftLaunchController.java:199)
> at org.jboss.tools.openshift.core.server.behavior.OpenShiftLaunchController.launch(OpenShiftLaunchController.java:93)
> at org.jboss.ide.eclipse.as.wtp.core.server.launch.ControllableServerLaunchConfiguration.launch(ControllableServerLaunchConfiguration.java:52)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3566)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3502)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:377)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[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)
8 years
[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)
8 years
[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)
8 years
[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)
8 years