[JBoss JIRA] (JBIDE-22580) Deploy Docker Image wizard: Cannot push already tagged image to docker registry
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22580?page=com.atlassian.jira.plugi... ]
Xavier Coulon updated JBIDE-22580:
----------------------------------
Sprint: devex #120 September 2016
> Deploy Docker Image wizard: Cannot push already tagged image to docker registry
> -------------------------------------------------------------------------------
>
> Key: JBIDE-22580
> URL: https://issues.jboss.org/browse/JBIDE-22580
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: docker, openshift
> Affects Versions: 4.4.0.Final
> Reporter: Marián Labuda
> Assignee: Xavier Coulon
> Labels: deploy_docker_wizard, docker, openshift_v3
> Fix For: 4.4.2.AM1
>
>
> There is a CDK docker registry located at hub.openshift.rhel-cdk.10.1.2.2.xip.io. From command line user has to tag image at first before pushing it to remote registry to match registry URL, e.g. to push image msa/helloworld from local repository to CDK docker registry I have to tag image as follows hub.openshift.rhel-cdk.10.1.2.2.xip.io/msa/helloworld and then I can just push it "docker push hub.openshift.rhel-cdk.10.1.2.2.xip.io/msa/helloworld". Users used to command line tooling and not aware of "auto-tag" feature of OpenShift tooling can bump into issues. When I am trying to push already tagged image (as I would be expecting from command line) I get an error with following stack trace
> {code}Failed to push the selected Docker image into OpenShift registry
> org.eclipse.linuxtools.docker.core.DockerException: Conflict: Tag latest is already set to image 2e0ddd37ace80cf13a9d3c664445430972fb3440661eb5d8efb7cc994f11bbdb, if you want to replace it, please use -f option
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.tagImage(DockerConnection.java:1083)
> at org.jboss.tools.openshift.internal.ui.dockerutils.PushImageToRegistryJob.doRun(PushImageToRegistryJob.java:65)
> at org.jboss.tools.openshift.internal.common.core.job.AbstractDelegatingMonitorJob.run(AbstractDelegatingMonitorJob.java:37)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
> I think it would be better at first try to check, whether an image does not already have specific tag and if it does, then we should involve confirmation dialog to use force push. If there is no such tagged image, push would behave as it is. Alternatively after checking of image existence we could just simply ignore it, because it is being tagged on same tag.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22580) Deploy Docker Image wizard: Cannot push already tagged image to docker registry
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22580?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-22580:
---------------------------------------
[~mlabuda] since the uptream issue has been fixed, can you give it another try and let me know if anything is missing here ?
> Deploy Docker Image wizard: Cannot push already tagged image to docker registry
> -------------------------------------------------------------------------------
>
> Key: JBIDE-22580
> URL: https://issues.jboss.org/browse/JBIDE-22580
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: docker, openshift
> Affects Versions: 4.4.0.Final
> Reporter: Marián Labuda
> Assignee: Xavier Coulon
> Labels: deploy_docker_wizard, docker, openshift_v3
> Fix For: 4.4.2.AM1
>
>
> There is a CDK docker registry located at hub.openshift.rhel-cdk.10.1.2.2.xip.io. From command line user has to tag image at first before pushing it to remote registry to match registry URL, e.g. to push image msa/helloworld from local repository to CDK docker registry I have to tag image as follows hub.openshift.rhel-cdk.10.1.2.2.xip.io/msa/helloworld and then I can just push it "docker push hub.openshift.rhel-cdk.10.1.2.2.xip.io/msa/helloworld". Users used to command line tooling and not aware of "auto-tag" feature of OpenShift tooling can bump into issues. When I am trying to push already tagged image (as I would be expecting from command line) I get an error with following stack trace
> {code}Failed to push the selected Docker image into OpenShift registry
> org.eclipse.linuxtools.docker.core.DockerException: Conflict: Tag latest is already set to image 2e0ddd37ace80cf13a9d3c664445430972fb3440661eb5d8efb7cc994f11bbdb, if you want to replace it, please use -f option
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.tagImage(DockerConnection.java:1083)
> at org.jboss.tools.openshift.internal.ui.dockerutils.PushImageToRegistryJob.doRun(PushImageToRegistryJob.java:65)
> at org.jboss.tools.openshift.internal.common.core.job.AbstractDelegatingMonitorJob.run(AbstractDelegatingMonitorJob.java:37)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
> I think it would be better at first try to check, whether an image does not already have specific tag and if it does, then we should involve confirmation dialog to use force push. If there is no such tagged image, push would behave as it is. Alternatively after checking of image existence we could just simply ignore it, because it is being tagged on same tag.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-21065) Server host name address should not be defaulted during server adapter creation
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21065?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-21065:
--------------------------------
Sprint: devex #120 September 2016
> Server host name address should not be defaulted during server adapter creation
> -------------------------------------------------------------------------------
>
> Key: JBIDE-21065
> URL: https://issues.jboss.org/browse/JBIDE-21065
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server, upstream
> Affects Versions: 4.3.0.Final
> Reporter: Xavier Coulon
> Assignee: Rob Stryker
> Fix For: 4.4.x
>
>
> I've noticed that when I create a server adapter and I give it an IP address as the hostname, the hostname remains the default value, ie, {{localhost}}.
> This is annoying in the case where I want to connect to a VM running on my own host (eg, a VM running Docker). In this particular case, I set the hostname at something like {{192.168.99.100}} but it is reverted as {{localhost}} which gives {{127.0.0.1}} as the primary IP address. As a consequence, the server adapter fails to connect to the server since it uses the wrong IP address.
> Note that the host name can be changed for good in the Server Configuration Editor _after_ its creation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22626) Updating deployed docker image on OpenShift does not work
by Dmitrii Bocharov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22626?page=com.atlassian.jira.plugi... ]
Dmitrii Bocharov updated JBIDE-22626:
-------------------------------------
Sprint: devex #120 September 2016 (was: devex #119 August 2016)
> Updating deployed docker image on OpenShift does not work
> ---------------------------------------------------------
>
> Key: JBIDE-22626
> URL: https://issues.jboss.org/browse/JBIDE-22626
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Marián Labuda
> Assignee: Dmitrii Bocharov
> Priority: Critical
> Labels: docker, openshift_v3
> Fix For: 4.4.1.Final
>
>
> In JBIDE-22515 was fixed use case when user have an image with specific tag. That works now ok.
> But if user deploys image with tag e.g. :0.8 to OpenShift, resources are created for this specific tag. When I am trying to Deploy to OS image with tag :0.9 afterwards, everything finish without an error. No new resources are created, but no existing resources are modified to contain this new image. Deployment config still contains tag :0.8 and thus new deployment is not done.
> Basically we need to modify deployment config in such cases to contains newer tag and let OpenShift do all magic and redeploy it.
> In order to add this version tag after semicolon, right-click on the image -> Add tag -> Re-type namespace/imagename + add ":0.8" e.g.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22818) vagrant service-manager call experiences timeout after output
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22818?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22818:
--------------------------------
Sprint: devex #120 September 2016
> vagrant service-manager call experiences timeout after output
> --------------------------------------------------------------
>
> Key: JBIDE-22818
> URL: https://issues.jboss.org/browse/JBIDE-22818
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.1.AM2
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.1.Final
>
>
> {noformat}
> !ENTRY org.jboss.tools.openshift.cdk.server 4 0 2016-07-21 09:48:26.869
> !MESSAGE Unable to successfully complete a call to vagrant service-manager.
> !STACK 0
> java.util.concurrent.TimeoutException: Process output:
> ^[[0m # docker env:^[[0m # Set the following environment variables to enable access to the # docker daemon running inside of the vagrant virtual machine: export DOCKER_HOST=tcp://10.1.2.2:2376 export DOCKER_CERT_PATH='C:\Pedro\Software\Openshift_RHCDK_suite10\cdk\components\rhel\rhel-ose\.vagrant\machines\default\virtualbox\docker\' export DOCKER_TLS_VERIFY=1 export DOCKER_API_VERSION=1.21 ^[[0m^[[0m ^[[0m # openshift env:^[[0m ^[[0m# You can access the OpenShift console on: https://10.1.2.2:8443/console # To use OpenShift CLI, run: oc login https://10.1.2.2:8443 export OPENSHIFT_URL=https://10.1.2.2:8443 export OPENSHIFT_WEB_CONSOLE=https://10.1.2.2:8443/console export DOCKER_REGISTRY=hub.openshift.rhel-cdk.10.1.2.2.xip.io^[[0m ^[[0m # run following command to configure your shell: # eval "$(VAGRANT_NO_COLOR=1 vagrant service-manager env | tr -d '\r')"^[[0m
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:186)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:153)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:108)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:85)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:67)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:59)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.checkOpenShiftHealth(VagrantPoller.java:185)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePing(VagrantPoller.java:174)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePingSafe(VagrantPoller.java:154)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.getCurrentStateSynchronous(VagrantPoller.java:133)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.handleProcessTerminated(CDKLaunchController.java:250)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.access$2(CDKLaunchController.java:242)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController$2.run(CDKLaunchController.java:235)
> !ENTRY org.jboss.tools.openshift.cdk.server 4 0 2016-07-21 09:49:07.139
> !MESSAGE Unable to successfully complete a call to vagrant service-manager.
> !STACK 0
> java.util.concurrent.TimeoutException: Process output:
> ^[[0m # docker env:^[[0m # Set the following environment variables to enable access to the # docker daemon running inside of the vagrant virtual machine: export DOCKER_HOST=tcp://10.1.2.2:2376 export DOCKER_CERT_PATH='C:\Pedro\Software\Openshift_RHCDK_suite10\cdk\components\rhel\rhel-ose\.vagrant\machines\default\virtualbox\docker\' export DOCKER_TLS_VERIFY=1 export DOCKER_API_VERSION=1.21 ^[[0m^[[0m ^[[0m # openshift env:^[[0m ^[[0m# You can access the OpenShift console on: https://10.1.2.2:8443/console # To use OpenShift CLI, run: oc login https://10.1.2.2:8443 export OPENSHIFT_URL=https://10.1.2.2:8443 export OPENSHIFT_WEB_CONSOLE=https://10.1.2.2:8443/console export DOCKER_REGISTRY=hub.openshift.rhel-cdk.10.1.2.2.xip.io^[[0m ^[[0m # run following command to configure your shell: # eval "$(VAGRANT_NO_COLOR=1 vagrant service-manager env | tr -d '\r')"^[[0m
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:186)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:153)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:108)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:85)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:67)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:59)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ConfigureDependentFrameworksListener.configureFrameworks(ConfigureDependentFrameworksListener.java:53)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ConfigureDependentFrameworksListener$1.run(ConfigureDependentFrameworksListener.java:43)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23050) Exception in Tools.findFirstValidVMInstall
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23050?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-23050:
--------------------------------
Fix Version/s: 4.4.2.AM1
> Exception in Tools.findFirstValidVMInstall
> ------------------------------------------
>
> Key: JBIDE-23050
> URL: https://issues.jboss.org/browse/JBIDE-23050
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.4.0.Alpha1
> Reporter: Automated Error Reporting Bot
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM1
>
>
> The following problem was reported via the automated error reporting:
> Message: <no message>
> {noformat}
> java.lang.Exception: null
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findFirstValidVMInstall(Tools.java:267)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findSecondaryVMInstall(Tools.java:424)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findHomeDirectoryToAddToClasspath(Tools.java:409)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getToolsJar(Tools.java:125)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getToolsLoader(Tools.java:100)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.reset(Tools.java:93)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.<init>(Tools.java:80)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getInstance(Tools.java:71)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.propertyChange(RemoteDebugActivator.java:248)
> at org.eclipse.core.runtime.Preferences$1.run(Preferences.java:510)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.runtime.Preferences.firePropertyChangeEvent(Preferences.java:513)
> at org.eclipse.core.internal.preferences.legacy.PreferenceForwarder.preferenceChange(PreferenceForwarder.java:116)
> at org.eclipse.core.internal.preferences.EclipsePreferences$2.run(EclipsePreferences.java:848)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.preferences.EclipsePreferences.firePreferenceEvent(EclipsePreferences.java:851)
> at org.eclipse.core.internal.preferences.EclipsePreferences.put(EclipsePreferences.java:863)
> at org.eclipse.jdt.launching.JavaRuntime.initializeVMs(JavaRuntime.java:2769)
> at org.eclipse.jdt.launching.JavaRuntime.getVMInstallTypes(JavaRuntime.java:539)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getAllVMInstalls(Tools.java:183)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getAllCompatibleInstalls(Tools.java:214)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findFirstValidVMInstall(Tools.java:257)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findSecondaryVMInstall(Tools.java:424)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findHomeDirectoryToAddToClasspath(Tools.java:409)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getToolsJar(Tools.java:125)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getToolsLoader(Tools.java:100)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.reset(Tools.java:93)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.<init>(Tools.java:80)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getInstance(Tools.java:71)
> at org.jboss.tools.common.jdt.debug.tools.ToolsCore.getActiveProcessIds(ToolsCore.java:179)
> at org.jboss.tools.jmx.jvmmonitor.internal.tools.JvmAttachHandler.updatesActiveJvms(JvmAttachHandler.java:100)
> at org.jboss.tools.jmx.jvmmonitor.internal.tools.JvmAttachHandler$1.run(JvmAttachHandler.java:78)
> at java.util.TimerThread.mainLoop(null:-1)
> at java.util.TimerThread.run(null:-1)
> {noformat}
> Bundles:
> | org.eclipse.core.jobs | 3.7.0.v20150330-2103 | 3.8.0.v20160509-0411 |
> | org.eclipse.core.resources | 3.11.0.v20160503-1608 | 3.11.0.v20160503-1608 |
> | org.eclipse.core.runtime | 3.11.0.v20150405-1723 | 3.12.0.v20160606-1342 |
> | org.eclipse.debug.ui | 3.11.101.v20160203-1230 | 3.11.101.v20160203-1230 |
> | org.eclipse.jdt.core | 3.12.0.v20160516-2131 | 3.12.0.v20160516-2131 |
> | org.eclipse.jdt.debug.ui | 3.7.101.v20160203-1236 | 3.7.200.v20160423-1519 |
> | org.eclipse.jdt.launching | 3.8.0.v20150527-0946 | 3.8.100.v20160505-0636 |
> | org.eclipse.jdt.ui | 3.12.0.v20160525-1829 | 3.12.0.v20160525-1829 |
> | org.eclipse.jface | 3.11.0.v20150602-1400 | 3.12.0.v20160518-1929 |
> | org.eclipse.m2e.core | 1.7.0.20160603-1933 | 1.7.0.20160603-1933 |
> | org.eclipse.m2e.core.ui | 1.7.0.20160603-1933 | 1.7.0.20160603-1933 |
> | org.eclipse.m2e.jdt | 1.7.0.20160603-1933 | 1.7.0.20160603-1933 |
> | org.eclipse.pde.core | 3.11.0.v20160510-1223 | 3.11.0.v20160510-1223 |
> | org.eclipse.pde.ui | 3.9.0.v20160525-1830 | 3.9.0.v20160525-1830 |
> | org.eclipse.swt | 3.104.0.v20150528-0211 | 3.105.0.v20160603-0902 |
> | org.eclipse.ui | 3.107.0.v20150507-1945 | 3.108.0.v20160518-1929 |
> | org.jboss.tools.common.jdt.debug | 3.7.0.CR1-v20150915-2036-B30 | 3.8.0.Final-v20160610-1533-B7 |
> | org.jboss.tools.common.jdt.debug.ui | 3.7.0.CR1-v20150915-2036-B30 | 3.8.0.Final-v20160610-1533-B7 |
> | org.jboss.tools.jmx.jvmmonitor.tools | 1.7.1.Final-v20160409-0826-B118 | 1.8.0.Final-v20160614-2020-B9 |
> Operating Systems:
> | Linux | 2.6.32.22 | 4.6.4.fc24 |
> | MacOSX | 10.11.5 | 10.11.5 |
> | Windows | 6.1.0 | 10.0.0 |
> The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/57001066e4b08ccb7b...] for the latest data.
> Thank you for your assistance.
> Your friendly error-reports-inbox.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23125) CDK server adapter: NPE when trying to find cdk connection
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23125?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-23125:
--------------------------------
Sprint: devex #120 September 2016
> CDK server adapter: NPE when trying to find cdk connection
> ----------------------------------------------------------
>
> Key: JBIDE-23125
> URL: https://issues.jboss.org/browse/JBIDE-23125
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Andre Dietisheim
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM1
>
>
> This was automatically reproted in aeri https://redhat.ctrlflow.com/reviewers#!/problems/57c68f6be4b0fd7621ccda10
> {code}
> Bundle: org.eclipse.jface 3.12.0.v20160518-1929
> Message: Problems occurred when invoking code from plug-in: "org.eclipse.jface".
> Exception:
> java.lang.NullPointerException: null
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.CDKDockerUtility.findDockerConnection(CDKDockerUtility.java:39)
> at org.jboss.tools.openshift.cdk.server.ui.internal.view.CDKActionProvider$ShowInDockerViewAfterStartupAction.adaptToViewItem(CDKActionProvider.java:104)
> at org.jboss.tools.openshift.cdk.server.ui.internal.view.CDKActionProvider$ShowInViewAfterStartupAction.accept(CDKActionProvider.java:182)
> at org.eclipse.wst.server.ui.internal.view.servers.AbstractServerAction.selectionChanged(AbstractServerAction.java:85)
> at org.jboss.tools.openshift.cdk.server.ui.internal.view.CDKActionProvider$ShowInViewAfterStartupAction.selectionChanged(CDKActionProvider.java:198)
> at org.eclipse.ui.actions.SelectionProviderAction.selectionChanged(SelectionProviderAction.java:144)
> at org.eclipse.jface.viewers.Viewer$1.run(Viewer.java:158)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:173)
> at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:155)
> at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:2191)
> at org.eclipse.jface.viewers.StructuredViewer.handleSelect(StructuredViewer.java:1229)
> at org.eclipse.ui.navigator.CommonViewer.handleSelect(CommonViewer.java:463)
> at org.eclipse.jface.viewers.StructuredViewer$4.widgetSelected(StructuredViewer.java:1258)
> at org.eclipse.jface.util.OpenStrategy.fireSelectionEvent(OpenStrategy.java:242)
> at org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy.java:236)
> at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:405)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23050) Exception in Tools.findFirstValidVMInstall
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23050?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-23050:
--------------------------------
Sprint: devex #120 September 2016
> Exception in Tools.findFirstValidVMInstall
> ------------------------------------------
>
> Key: JBIDE-23050
> URL: https://issues.jboss.org/browse/JBIDE-23050
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.4.0.Alpha1
> Reporter: Automated Error Reporting Bot
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM1
>
>
> The following problem was reported via the automated error reporting:
> Message: <no message>
> {noformat}
> java.lang.Exception: null
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findFirstValidVMInstall(Tools.java:267)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findSecondaryVMInstall(Tools.java:424)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findHomeDirectoryToAddToClasspath(Tools.java:409)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getToolsJar(Tools.java:125)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getToolsLoader(Tools.java:100)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.reset(Tools.java:93)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.<init>(Tools.java:80)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getInstance(Tools.java:71)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.propertyChange(RemoteDebugActivator.java:248)
> at org.eclipse.core.runtime.Preferences$1.run(Preferences.java:510)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.runtime.Preferences.firePropertyChangeEvent(Preferences.java:513)
> at org.eclipse.core.internal.preferences.legacy.PreferenceForwarder.preferenceChange(PreferenceForwarder.java:116)
> at org.eclipse.core.internal.preferences.EclipsePreferences$2.run(EclipsePreferences.java:848)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.preferences.EclipsePreferences.firePreferenceEvent(EclipsePreferences.java:851)
> at org.eclipse.core.internal.preferences.EclipsePreferences.put(EclipsePreferences.java:863)
> at org.eclipse.jdt.launching.JavaRuntime.initializeVMs(JavaRuntime.java:2769)
> at org.eclipse.jdt.launching.JavaRuntime.getVMInstallTypes(JavaRuntime.java:539)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getAllVMInstalls(Tools.java:183)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getAllCompatibleInstalls(Tools.java:214)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findFirstValidVMInstall(Tools.java:257)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findSecondaryVMInstall(Tools.java:424)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.findHomeDirectoryToAddToClasspath(Tools.java:409)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getToolsJar(Tools.java:125)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getToolsLoader(Tools.java:100)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.reset(Tools.java:93)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.<init>(Tools.java:80)
> at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getInstance(Tools.java:71)
> at org.jboss.tools.common.jdt.debug.tools.ToolsCore.getActiveProcessIds(ToolsCore.java:179)
> at org.jboss.tools.jmx.jvmmonitor.internal.tools.JvmAttachHandler.updatesActiveJvms(JvmAttachHandler.java:100)
> at org.jboss.tools.jmx.jvmmonitor.internal.tools.JvmAttachHandler$1.run(JvmAttachHandler.java:78)
> at java.util.TimerThread.mainLoop(null:-1)
> at java.util.TimerThread.run(null:-1)
> {noformat}
> Bundles:
> | org.eclipse.core.jobs | 3.7.0.v20150330-2103 | 3.8.0.v20160509-0411 |
> | org.eclipse.core.resources | 3.11.0.v20160503-1608 | 3.11.0.v20160503-1608 |
> | org.eclipse.core.runtime | 3.11.0.v20150405-1723 | 3.12.0.v20160606-1342 |
> | org.eclipse.debug.ui | 3.11.101.v20160203-1230 | 3.11.101.v20160203-1230 |
> | org.eclipse.jdt.core | 3.12.0.v20160516-2131 | 3.12.0.v20160516-2131 |
> | org.eclipse.jdt.debug.ui | 3.7.101.v20160203-1236 | 3.7.200.v20160423-1519 |
> | org.eclipse.jdt.launching | 3.8.0.v20150527-0946 | 3.8.100.v20160505-0636 |
> | org.eclipse.jdt.ui | 3.12.0.v20160525-1829 | 3.12.0.v20160525-1829 |
> | org.eclipse.jface | 3.11.0.v20150602-1400 | 3.12.0.v20160518-1929 |
> | org.eclipse.m2e.core | 1.7.0.20160603-1933 | 1.7.0.20160603-1933 |
> | org.eclipse.m2e.core.ui | 1.7.0.20160603-1933 | 1.7.0.20160603-1933 |
> | org.eclipse.m2e.jdt | 1.7.0.20160603-1933 | 1.7.0.20160603-1933 |
> | org.eclipse.pde.core | 3.11.0.v20160510-1223 | 3.11.0.v20160510-1223 |
> | org.eclipse.pde.ui | 3.9.0.v20160525-1830 | 3.9.0.v20160525-1830 |
> | org.eclipse.swt | 3.104.0.v20150528-0211 | 3.105.0.v20160603-0902 |
> | org.eclipse.ui | 3.107.0.v20150507-1945 | 3.108.0.v20160518-1929 |
> | org.jboss.tools.common.jdt.debug | 3.7.0.CR1-v20150915-2036-B30 | 3.8.0.Final-v20160610-1533-B7 |
> | org.jboss.tools.common.jdt.debug.ui | 3.7.0.CR1-v20150915-2036-B30 | 3.8.0.Final-v20160610-1533-B7 |
> | org.jboss.tools.jmx.jvmmonitor.tools | 1.7.1.Final-v20160409-0826-B118 | 1.8.0.Final-v20160614-2020-B9 |
> Operating Systems:
> | Linux | 2.6.32.22 | 4.6.4.fc24 |
> | MacOSX | 10.11.5 | 10.11.5 |
> | Windows | 6.1.0 | 10.0.0 |
> The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/57001066e4b08ccb7b...] for the latest data.
> Thank you for your assistance.
> Your friendly error-reports-inbox.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23125) CDK server adapter: NPE when trying to find cdk connection
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23125?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-23125:
--------------------------------
Fix Version/s: 4.4.2.AM1
> CDK server adapter: NPE when trying to find cdk connection
> ----------------------------------------------------------
>
> Key: JBIDE-23125
> URL: https://issues.jboss.org/browse/JBIDE-23125
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Andre Dietisheim
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM1
>
>
> This was automatically reproted in aeri https://redhat.ctrlflow.com/reviewers#!/problems/57c68f6be4b0fd7621ccda10
> {code}
> Bundle: org.eclipse.jface 3.12.0.v20160518-1929
> Message: Problems occurred when invoking code from plug-in: "org.eclipse.jface".
> Exception:
> java.lang.NullPointerException: null
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.CDKDockerUtility.findDockerConnection(CDKDockerUtility.java:39)
> at org.jboss.tools.openshift.cdk.server.ui.internal.view.CDKActionProvider$ShowInDockerViewAfterStartupAction.adaptToViewItem(CDKActionProvider.java:104)
> at org.jboss.tools.openshift.cdk.server.ui.internal.view.CDKActionProvider$ShowInViewAfterStartupAction.accept(CDKActionProvider.java:182)
> at org.eclipse.wst.server.ui.internal.view.servers.AbstractServerAction.selectionChanged(AbstractServerAction.java:85)
> at org.jboss.tools.openshift.cdk.server.ui.internal.view.CDKActionProvider$ShowInViewAfterStartupAction.selectionChanged(CDKActionProvider.java:198)
> at org.eclipse.ui.actions.SelectionProviderAction.selectionChanged(SelectionProviderAction.java:144)
> at org.eclipse.jface.viewers.Viewer$1.run(Viewer.java:158)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:173)
> at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:155)
> at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:2191)
> at org.eclipse.jface.viewers.StructuredViewer.handleSelect(StructuredViewer.java:1229)
> at org.eclipse.ui.navigator.CommonViewer.handleSelect(CommonViewer.java:463)
> at org.eclipse.jface.viewers.StructuredViewer$4.widgetSelected(StructuredViewer.java:1258)
> at org.eclipse.jface.util.OpenStrategy.fireSelectionEvent(OpenStrategy.java:242)
> at org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy.java:236)
> at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:405)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22916) Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata if image is not pulled to a docker connection
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22916?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-22916:
----------------------------------
Summary: Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata if image is not pulled to a docker connection (was: Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata)
> Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata if image is not pulled to a docker connection
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-22916
> URL: https://issues.jboss.org/browse/JBIDE-22916
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Labels: deploy_docker_wizard, openshift_v3
> Fix For: 4.4.1.Final
>
> Attachments: 2016-09-06 at 14-19-31.mp4
>
>
> When I am trying to deploy a docker image from context menu of a project in OpenShift explorer view and I paste image name (e.g. docker.io/openshift/hello-openshift), image metadata are not fetched/processed and thus there are no environment variables in the wizard and routing (routing wizard page is empty and cannot finish dialog - requires manual entry). This force user to enter the details manually, otherwise he would get deployed not working pod. This is happening only in case when user provide an image without any tag and thus there is/supposed to be assumed tag "latest".
> You can observe that it works when using tag v1.2.1. Difference between images with tag v1.2.1 and latest is that v1.2.1 contains exposed ports also in container config, not just in general config of the image.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months