[JBoss JIRA] (JBIDE-21920) Cannot use features which are using oc binary
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21920?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21920:
-------------------------------------
Steps to Reproduce:
ASSERT: Have an OpenShift 3 connection in OpenShift explorer view.
EXEC: Create a new application on the connection.
ASSERT: Application is running and there is application pod.
EXEC: Set path to oc binary in OpenShift 3 preference page.
EXEC: Try to open application pod logs via context menu of application pod in OpenShift Explorer view.
RESULT: Error message is shown in console and no pod log is displayed.
EXPECTED RESULT: Pod log is shown in console.
> Cannot use features which are using oc binary
> ---------------------------------------------
>
> Key: JBIDE-21920
> URL: https://issues.jboss.org/browse/JBIDE-21920
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Fred Bricon
> Priority: Blocker
> Labels: oc_binary, openshift_v3
> Fix For: 4.3.1.CR1, 4.4.0.Alpha1
>
>
> After latest update of nightly JBT I am not able to get logs from pods(/builds) or use port forwarding . Because there is something wrong with setting oc path. When I set path on OpenShift 3 preference page to be pointing to correct oc binary, following e.g. getting log from pod results in showing following message in console
> {code}
> The OpenShift 'oc' binary location was not specified. Set the property openshift.restclient.oc.location
> {code}
> There is no stack trace available for this error in error log.
> But when using port forwading, there is an error with following stack
> {code}
> com.openshift.restclient.capability.resources.LocationNotFoundException: The OpenShift 'oc' binary location was not specified. Set the property openshift.restclient.oc.location
> at com.openshift.internal.restclient.capability.resources.AbstractOpenShiftBinaryCapability.getOpenShiftBinaryLocation(AbstractOpenShiftBinaryCapability.java:189)
> at com.openshift.internal.restclient.capability.resources.AbstractOpenShiftBinaryCapability.start(AbstractOpenShiftBinaryCapability.java:123)
> at com.openshift.internal.restclient.capability.resources.OpenShiftBinaryPortForwarding.forwardPorts(OpenShiftBinaryPortForwarding.java:66)
> at org.jboss.tools.openshift.internal.core.portforwarding.PortForwardingUtils$1.visit(PortForwardingUtils.java:128)
> at org.jboss.tools.openshift.internal.core.portforwarding.PortForwardingUtils$1.visit(PortForwardingUtils.java:1)
> at com.openshift.internal.restclient.model.KubernetesResource.accept(KubernetesResource.java:91)
> at org.jboss.tools.openshift.internal.core.portforwarding.PortForwardingUtils.startPortForwarding(PortForwardingUtils.java:124)
> at org.jboss.tools.openshift.internal.ui.portforwading.PortForwardingWizardModel.startPortForwarding(PortForwardingWizardModel.java:110)
> at org.jboss.tools.openshift.internal.ui.portforwading.PortForwardingWizardPage$3$1.run(PortForwardingWizardPage.java:157)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21920) Cannot use features which are using oc binary
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21920?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21920:
-------------------------------------
Labels: oc_binary openshift_v3 (was: openshift_v3)
> Cannot use features which are using oc binary
> ---------------------------------------------
>
> Key: JBIDE-21920
> URL: https://issues.jboss.org/browse/JBIDE-21920
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Fred Bricon
> Priority: Blocker
> Labels: oc_binary, openshift_v3
> Fix For: 4.3.1.CR1, 4.4.0.Alpha1
>
>
> After latest update of nightly JBT I am not able to get logs from pods(/builds) or use port forwarding . Because there is something wrong with setting oc path. When I set path on OpenShift 3 preference page to be pointing to correct oc binary, following e.g. getting log from pod results in showing following message in console
> {code}
> The OpenShift 'oc' binary location was not specified. Set the property openshift.restclient.oc.location
> {code}
> There is no stack trace available for this error in error log.
> But when using port forwading, there is an error with following stack
> {code}
> com.openshift.restclient.capability.resources.LocationNotFoundException: The OpenShift 'oc' binary location was not specified. Set the property openshift.restclient.oc.location
> at com.openshift.internal.restclient.capability.resources.AbstractOpenShiftBinaryCapability.getOpenShiftBinaryLocation(AbstractOpenShiftBinaryCapability.java:189)
> at com.openshift.internal.restclient.capability.resources.AbstractOpenShiftBinaryCapability.start(AbstractOpenShiftBinaryCapability.java:123)
> at com.openshift.internal.restclient.capability.resources.OpenShiftBinaryPortForwarding.forwardPorts(OpenShiftBinaryPortForwarding.java:66)
> at org.jboss.tools.openshift.internal.core.portforwarding.PortForwardingUtils$1.visit(PortForwardingUtils.java:128)
> at org.jboss.tools.openshift.internal.core.portforwarding.PortForwardingUtils$1.visit(PortForwardingUtils.java:1)
> at com.openshift.internal.restclient.model.KubernetesResource.accept(KubernetesResource.java:91)
> at org.jboss.tools.openshift.internal.core.portforwarding.PortForwardingUtils.startPortForwarding(PortForwardingUtils.java:124)
> at org.jboss.tools.openshift.internal.ui.portforwading.PortForwardingWizardModel.startPortForwarding(PortForwardingWizardModel.java:110)
> at org.jboss.tools.openshift.internal.ui.portforwading.PortForwardingWizardPage$3$1.run(PortForwardingWizardPage.java:157)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21925) Image metadata not refreshed after name change
by Marián Labuda (JIRA)
Marián Labuda created JBIDE-21925:
-------------------------------------
Summary: Image metadata not refreshed after name change
Key: JBIDE-21925
URL: https://issues.jboss.org/browse/JBIDE-21925
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.3.1.Beta2
Reporter: Xavier Coulon
Assignee: Xavier Coulon
Fix For: 4.3.1.CR1
Steps to reproduce:
- open the *Deploy Docker Image* wizard
- input/search for {{jboss/infinispan-server:8.1.0.Final}}, then click on {{Next}}. The *Deploy Configuration & Scalability* page should show a handful of metadata, including {{INFINISPAN_VERSION = 8.1.0.Final}}
- go back to the previous page, *Deploy an Image* and now input/search for {{jboss/wildfly:10.0.0.Final}} and click back on {{Next}} again.
- ASSERT: the metadata should have been updated
- FAILED: the metadata displayed correspond to the previously selected {{jboss/infinispan-server:8.1.0.Final}} Docker image.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21920) Cannot use features which are using oc binary
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21920?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21920:
-------------------------------------
Fix Version/s: 4.4.0.Alpha1
> Cannot use features which are using oc binary
> ---------------------------------------------
>
> Key: JBIDE-21920
> URL: https://issues.jboss.org/browse/JBIDE-21920
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Fred Bricon
> Priority: Blocker
> Labels: oc_binary, openshift_v3
> Fix For: 4.3.1.CR1, 4.4.0.Alpha1
>
>
> After latest update of nightly JBT I am not able to get logs from pods(/builds) or use port forwarding . Because there is something wrong with setting oc path. When I set path on OpenShift 3 preference page to be pointing to correct oc binary, following e.g. getting log from pod results in showing following message in console
> {code}
> The OpenShift 'oc' binary location was not specified. Set the property openshift.restclient.oc.location
> {code}
> There is no stack trace available for this error in error log.
> But when using port forwading, there is an error with following stack
> {code}
> com.openshift.restclient.capability.resources.LocationNotFoundException: The OpenShift 'oc' binary location was not specified. Set the property openshift.restclient.oc.location
> at com.openshift.internal.restclient.capability.resources.AbstractOpenShiftBinaryCapability.getOpenShiftBinaryLocation(AbstractOpenShiftBinaryCapability.java:189)
> at com.openshift.internal.restclient.capability.resources.AbstractOpenShiftBinaryCapability.start(AbstractOpenShiftBinaryCapability.java:123)
> at com.openshift.internal.restclient.capability.resources.OpenShiftBinaryPortForwarding.forwardPorts(OpenShiftBinaryPortForwarding.java:66)
> at org.jboss.tools.openshift.internal.core.portforwarding.PortForwardingUtils$1.visit(PortForwardingUtils.java:128)
> at org.jboss.tools.openshift.internal.core.portforwarding.PortForwardingUtils$1.visit(PortForwardingUtils.java:1)
> at com.openshift.internal.restclient.model.KubernetesResource.accept(KubernetesResource.java:91)
> at org.jboss.tools.openshift.internal.core.portforwarding.PortForwardingUtils.startPortForwarding(PortForwardingUtils.java:124)
> at org.jboss.tools.openshift.internal.ui.portforwading.PortForwardingWizardModel.startPortForwarding(PortForwardingWizardModel.java:110)
> at org.jboss.tools.openshift.internal.ui.portforwading.PortForwardingWizardPage$3$1.run(PortForwardingWizardPage.java:157)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21815) Image metadata not refreshed after name change
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21815?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-21815.
---------------------------------
Verified on nightly build of JBT with OpenShift plugin build B240.
> Image metadata not refreshed after name change
> ----------------------------------------------
>
> Key: JBIDE-21815
> URL: https://issues.jboss.org/browse/JBIDE-21815
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Fix For: 4.3.1.CR1
>
>
> Steps to reproduce:
> - open the *Deploy Docker Image* wizard
> - input/search for {{jboss/infinispan-server:8.1.0.Final}}, then click on {{Next}}. The *Deploy Configuration & Scalability* page should show a handful of metadata, including {{INFINISPAN_VERSION = 8.1.0.Final}}
> - go back to the previous page, *Deploy an Image* and now input/search for {{jboss/wildfly:10.0.0.Final}} and click back on {{Next}} again.
> - ASSERT: the metadata should have been updated
> - FAILED: the metadata displayed correspond to the previously selected {{jboss/infinispan-server:8.1.0.Final}} Docker image.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21925) Image metadata not refreshed after name change
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21925?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-21925:
----------------------------------
Fix Version/s: 4.4.0.Alpha1
(was: 4.3.1.CR1)
> Image metadata not refreshed after name change
> ----------------------------------------------
>
> Key: JBIDE-21925
> URL: https://issues.jboss.org/browse/JBIDE-21925
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Fix For: 4.4.0.Alpha1
>
>
> Steps to reproduce:
> - open the *Deploy Docker Image* wizard
> - input/search for {{jboss/infinispan-server:8.1.0.Final}}, then click on {{Next}}. The *Deploy Configuration & Scalability* page should show a handful of metadata, including {{INFINISPAN_VERSION = 8.1.0.Final}}
> - go back to the previous page, *Deploy an Image* and now input/search for {{jboss/wildfly:10.0.0.Final}} and click back on {{Next}} again.
> - ASSERT: the metadata should have been updated
> - FAILED: the metadata displayed correspond to the previously selected {{jboss/infinispan-server:8.1.0.Final}} Docker image.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21925) Image metadata not refreshed after name change
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21925?page=com.atlassian.jira.plugi... ]
Marián Labuda resolved JBIDE-21925.
-----------------------------------
Resolution: Done
> Image metadata not refreshed after name change
> ----------------------------------------------
>
> Key: JBIDE-21925
> URL: https://issues.jboss.org/browse/JBIDE-21925
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Fix For: 4.4.0.Alpha1
>
>
> Steps to reproduce:
> - open the *Deploy Docker Image* wizard
> - input/search for {{jboss/infinispan-server:8.1.0.Final}}, then click on {{Next}}. The *Deploy Configuration & Scalability* page should show a handful of metadata, including {{INFINISPAN_VERSION = 8.1.0.Final}}
> - go back to the previous page, *Deploy an Image* and now input/search for {{jboss/wildfly:10.0.0.Final}} and click back on {{Next}} again.
> - ASSERT: the metadata should have been updated
> - FAILED: the metadata displayed correspond to the previously selected {{jboss/infinispan-server:8.1.0.Final}} Docker image.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-14828) Application Wizard: if git clone directory already exist i cannot do anything
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14828?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-14828:
---------------------------------------
In basic scenarios it works nice. But If I am using application with set context dir (e.g. eap 6.4. basic s2i templates use kitchensink context dir, because it is contained in eap quickstarts repo where is plenty of quickstarts) and I delete a project not only from project explorer but also from file system (check the checkbox when prompt to delete project), then only project is deleted from downloaded git repo of quickstarts. In this case, wizard warn me about existing repository and dont allow me to proceed, until I either choose different location or reuse existing repository. After checking the checkbox to reuse repository (of quickstarts, where I earlier deleted the project), wizard is finished successfully but it imports whole eap quickstarts project (parent of all quickstarts) if there is no kitchensink project (which is not there because it was deleted earlier but was not recovered). If I check checkbox "Reuse existing repository" I understand it as overwriting of local content by the remote one. Is this behaviour, as described above, desired?
> Application Wizard: if git clone directory already exist i cannot do anything
> -----------------------------------------------------------------------------
>
> Key: JBIDE-14828
> URL: https://issues.jboss.org/browse/JBIDE-14828
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Beta2
> Reporter: Andre Dietisheim
> Assignee: Rob Stryker
> Labels: application_wizard
> Fix For: 4.3.1.CR1, 4.4.0.Alpha1
>
> Attachments: application-folder-already-exists.png
>
>
> steps to reproduce:
> # EXEC: create and/or import some appliaction from OpenShift to your local workspace using the application/import wizard
> # EXEC: once you have the project imported to your workspace, delete it
> # EXEC: once it is deleted, go and try to re-import the very same application
> Result:
> The 3rd wizard page errors on the git cloning destination. You're told that the destination folder already exists within the clone destination folder. The only way out currently is to choose a different clone destination folder.
> !application-folder-already-exists.png!
> Expected:
> It would help a lot if wizard would allow you to overwrite the existing destination. The wizard could also check if the given folder holds a prior clone and then allow one to "reuse" this folder. The given folder would then simply get imported to Eclipse and we'd fetch instead of cloning.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years