February 2017 - jbosstools-issues

[JBoss JIRA] (JBIDE-23638) Scaling: Sometimes incorrect version of RC leads to error when scaling

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23638?page=com.atlassian.jira.plugi... ] Andre Dietisheim resolved JBIDE-23638. -------------------------------------- Assignee: Andre Dietisheim Resolution: Duplicate Issue This is duplicate to JBIDE-23662. > Scaling: Sometimes incorrect version of RC leads to error when scaling > ---------------------------------------------------------------------- > > Key: JBIDE-23638 > URL: https://issues.jboss.org/browse/JBIDE-23638 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.3.Final > Reporter: Marián Labuda > Assignee: Andre Dietisheim > Labels: openshift_v3 > Fix For: 4.4.3.AM2 > > > Sometimes when scaling an OpenShift 3 application several times, there is an error about failed PUT call. No jobs are running when triggering a scaling. Even though pods are shown correctly (right amount is shown) this error is shown: > {code} > com.openshift.restclient.OpenShiftException: Exception trying to PUT https://10.1.2.2:8443/api/v1/namespaces/test-project/replicationcontrolle... response code: 409 Operation cannot be fulfilled on replicationcontrollers "nodejs-example-1": the object has been modified; please apply your changes to the latest version and try again > at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:114) > at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:65) > at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:190) > at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:163) > at okhttp3.RealCall.execute(RealCall.java:57) > at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:217) > at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:194) > at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:183) > at com.openshift.internal.restclient.DefaultClient.update(DefaultClient.java:275) > at org.jboss.tools.openshift.core.connection.Connection.updateResource(Connection.java:451) > at org.jboss.tools.openshift.internal.ui.handler.ScaleDeploymentHandler$2.run(ScaleDeploymentHandler.java:155) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23626) Preferences: link to download oc may lead me to try to use an incompatible oc binary for my origin/CDK

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23626?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23626: ------------------------------------- Fix Version/s: 4.4.3.Final (was: 4.4.3.AM2) > Preferences: link to download oc may lead me to try to use an incompatible oc binary for my origin/CDK > ------------------------------------------------------------------------------------------------------ > > Key: JBIDE-23626 > URL: https://issues.jboss.org/browse/JBIDE-23626 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.2.AM3 > Reporter: Andre Dietisheim > Labels: oc_binary, preferences > Fix For: 4.4.3.Final > > > oc 1.4, which is available from github is not compatible with the lastest CDK 2.3 (it's only compatible oc 1.3). Futhermore there are specific enterprise oc binaries which follow the OSE versioning scheme 3.2, 3.3 etc. making it hard for the user to know what oc he should use. > Our preferences offer a link to the github releases but there's no info nor logic that makes sure that the user will use compatible combinations (oc 1.4 with CDK 2.3, oc 1.2 with CDK 2.3 etc.) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23625) JMX: jmx tree is not very usable

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23625?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23625: ------------------------------------- Fix Version/s: 4.5.0.AM1 (was: 4.4.3.AM2) > JMX: jmx tree is not very usable > -------------------------------- > > Key: JBIDE-23625 > URL: https://issues.jboss.org/browse/JBIDE-23625 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.2.Final > Reporter: Andre Dietisheim > Fix For: 4.5.0.AM1 > > Attachments: image-2016-12-02-16-47-59-519.png > > > steps to reproduce: > # EXEC: create a new app via eap64-basic-s2i template and import the source to a workspace project > # EXEC: create a server adapter for it > # ASSERT: your server adapter now has a JMX child node > # EXEC: double click it and wait until all MBeans are loaded > # EXEC: now try to see if you can find your deployment > Result: > You get a listing of tons of beans. > !mbeans.png! > Your deployment is a child bean of jboss.as, named by the war that was created: > !mbean-deployment.png! > Rather painfull to find a listing of your deployments in this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23710) Properites: Disable scaling on completed deployments

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23710?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23710: ------------------------------------- Fix Version/s: 4.5.0.AM1 (was: 4.4.3.AM2) > Properites: Disable scaling on completed deployments > ---------------------------------------------------- > > Key: JBIDE-23710 > URL: https://issues.jboss.org/browse/JBIDE-23710 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.3.AM1 > Reporter: Radim Hopp > Labels: openshift_v3, properties > Fix For: 4.5.0.AM1 > > > In web console, scaling completed deployments is disabled. > In devstudio this option is enabled (in Deployments in Properties View) and after scaling up the completed deployment up (from 0 pods), the pods get scaled, but they are immediately scaled down automatically by openshift. > Sometimes I also got this exception (but not allways): > {noformat} > !ENTRY org.jboss.tools.openshift.ui 4 0 2017-01-10 16:32:41.562 > !MESSAGE Unable to scale wildfly-1 > !STACK 0 > com.openshift.restclient.OpenShiftException: Exception trying to PUT https://10.40.4.205:8443/api/v1/namespaces/testproject/replicationcontrol... response code: 409 Operation cannot be fulfilled on replicationcontrollers "wildfly-1": the object has been modified; please apply your changes to the latest version and try again > at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:114) > at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:65) > at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:190) > at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:163) > at okhttp3.RealCall.execute(RealCall.java:57) > at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:217) > at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:194) > at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:183) > at com.openshift.internal.restclient.DefaultClient.update(DefaultClient.java:275) > at org.jboss.tools.openshift.core.connection.Connection.updateResource(Connection.java:451) > at org.jboss.tools.openshift.internal.ui.handler.ScaleDeploymentHandler$2.run(ScaleDeploymentHandler.java:183) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > {noformat} > I think we should do the same as web console -> disable scaling options on completed deployments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23708) Pod Log: unable to get build log if build failed with error

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23708?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23708: ------------------------------------- Fix Version/s: 4.4.3.Final (was: 4.4.3.AM2) > Pod Log: unable to get build log if build failed with error > ----------------------------------------------------------- > > Key: JBIDE-23708 > URL: https://issues.jboss.org/browse/JBIDE-23708 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.3.AM1 > Reporter: Andre Dietisheim > Labels: logs, properties > Fix For: 4.4.3.Final > > Attachments: cannot-get-logs-for-erroring-build.png, webconsole-logs-for-erroring-build.png > > > steps to reproduce: > # ASSERT: make sure that you have a build that failed (ex. launch a nodejs build and shut down your vpn. The build will fail because it cannot connect to the registry) > # EXEC: in Properties view: select "Builds" tab and choose your erroring build. Choose "Build Log..." in it's context menu > Result: > You're told that you cannot get the logs for an erroring build. You therefore cannot have insights on why your build failed: > !cannot-get-logs-for-erroring-build.png! > The webconsole allows you to inspect those logs: > !webconsole-logs-for-erroring-build.png! -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23709) Properties: Scaling To/Up/Down are missing in context menu when project is selected in explorer

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23709?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23709: ------------------------------------- Fix Version/s: 4.5.0.AM1 (was: 4.4.3.AM2) > Properties: Scaling To/Up/Down are missing in context menu when project is selected in explorer > ----------------------------------------------------------------------------------------------- > > Key: JBIDE-23709 > URL: https://issues.jboss.org/browse/JBIDE-23709 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.3.AM1 > Reporter: Andre Dietisheim > Fix For: 4.5.0.AM1 > > Attachments: project-selected-no-scaling.png, service-selected-scaling-possible.png > > > steps to reproduce: > # ASSERT: make sure that you have at least 1 service & pod running in OpenShift > # EXEC: in OpenShift Explorer: select the project that contains the service/pod > # EXEC: in Properties view: select "Pod" tab and then your running pod (not the build pod, but the pod that's running your service). Open up the context menu > Result: > "Scale" with is child entries is missing from the context menu. > !project-selected-no-scaling.png! > While it's present if you have the service selected in the OpenShift Explorer. > !service-selected-scaling-possible.png! -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23704) Application wizard: Application based on builder images do not have prefilled configuration when opened from Central

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23704?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23704: ------------------------------------- Fix Version/s: 4.4.3.Final (was: 4.4.3.AM2) > Application wizard: Application based on builder images do not have prefilled configuration when opened from Central > -------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-23704 > URL: https://issues.jboss.org/browse/JBIDE-23704 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.3.AM1 > Environment: Devstudio 10.3.0.AM1. > Reproducible against internal OS3 instance and agains OS inside CDK 2.3 > Reporter: Radim Hopp > Labels: application_wizard, openshift_v3 > Fix For: 4.4.3.Final > > Attachments: git-repo-missing.png, git-repo-prefilled.png > > > This test started to fail: https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te... and I was able to reproduce it by hand. > It looks very simmilar to JBIDE-22704 except App name is preconfigured, but Git repo URL is not (and thus I cannot continue to next pages of this wizard). > This works when new openshift app wizard is opened via File -> New -> Other... -> OpenShift -> OpenShift Application or by right-clicking on OpenShift connection or OpenShift project in OpenShift explorer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23782) Server adapter: Should keep trying to start (silently) instead of erroring and giving up

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23782?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23782: ------------------------------------- Fix Version/s: 4.4.3.Final (was: 4.4.3.AM2) > Server adapter: Should keep trying to start (silently) instead of erroring and giving up > ---------------------------------------------------------------------------------------- > > Key: JBIDE-23782 > URL: https://issues.jboss.org/browse/JBIDE-23782 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.3.AM1 > Reporter: Andre Dietisheim > Assignee: Rob Stryker > Labels: openshift_v3, server_adapter > Fix For: 4.4.3.Final > > Attachments: starting-server-adapter-failed.png > > > steps to reproduce: > # EXEC: create a new eap64-basic-s2i application in OpenShift and have the jboss-kitchensink project imported to your workspace (dont use a pre-created one) > # EXEC: create a server adapter for it > Result: > The server adapter immediately tries to start and publish once you finish the server adapter wizard. This leads to the following error which is expected since the pods, that the server adapter wants to publish to, dont exist yet. The build has to finish first. Once it's finished, the pod will be ready and available for the adapter to sync to. > !starting-server-adapter-failed.png! > The adapter then turns to [Stopped] and stays stopped. > I then have to keep watching the OpenShift Explorer or the Properties to catch the moment when the build's finished and the service pod is running. > Once this is achieved I can go and start the adapter which will then successfully publish. > It would be much nicer if the adapter would do this waiting for me, it would possibly still inform me that the pod doesnt exist yet but would watch the build and start publishing once it exists. > In order for this wait not to occur endlessly we could inform the user after some timeout, that we were waiting for some pods to appear but this didnt happen in the given timeframe. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23711) Properites: "Edit default route" on Build config does nothing

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23711?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23711: ------------------------------------- Fix Version/s: 4.4.3.Final (was: 4.4.3.AM2) > Properites: "Edit default route" on Build config does nothing > ------------------------------------------------------------- > > Key: JBIDE-23711 > URL: https://issues.jboss.org/browse/JBIDE-23711 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.3.AM1 > Reporter: Radim Hopp > Labels: openshift_v3, properties > Fix For: 4.4.3.Final > > > Context menu of build configs in properties view has entry "Edit default route..." which does nothing. Is it even supposed to be there? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-23780) Import Application: uncheck "Use default clone destination" wont recheck if I removed the folder that it''s complaining about

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23780?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23780: ------------------------------------- Fix Version/s: 4.5.0.AM1 (was: 4.4.3.AM2) > Import Application: uncheck "Use default clone destination" wont recheck if I removed the folder that it''s complaining about > ----------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-23780 > URL: https://issues.jboss.org/browse/JBIDE-23780 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.3.AM1 > Reporter: Andre Dietisheim > Labels: import_wizard, openshift_v3 > Fix For: 4.5.0.AM1 > > Attachments: clone-destination-already-exists.png, error-even-though-clone-destination-doesnt-exist.png > > > steps to reproduce: > # ASSERT: make sure that you have a folder "jboss-eap-quickstarts" in your default Eclipse git clone destination (if you didnt change your preferences, it will point to ~/git/. If you dont have it yet git clone it from https://github.com/jboss-developer/jboss-eap-quickstarts.git) > # EXEC: create a new application using the "eap64-basic-s2i" template > # ASSERT: the OpenShift resources for your application are created, the import wizard pops up with the following error that complains about the directory already existing: > !clone-destination-already-exists.png! > # EXEC: manually remove the directory (ex. in cmd-line) > # EXEC: uncheck "Use default clone destination:" > Result: > The error wont go away, the wizard is still complaining even though the folder isnt in the way any more. > !error-even-though-clone-destination-doesnt-exist.png! > Hitting "Browse" and pointing to the same folder, that doesnt containt the folder anymore, wont help. The error persists. There' > s no way to work around this, you have to cancel the import and start over again. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues February 2017