August 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-22241) OpenShift Explorer: Cascade resource deletion

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22241?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22241: ------------------------------------- Fix Version/s: 4.4.1.Final (was: 4.4.1.AM3) > OpenShift Explorer: Cascade resource deletion > --------------------------------------------- > > Key: JBIDE-22241 > URL: https://issues.jboss.org/browse/JBIDE-22241 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.0.Alpha1 > Reporter: Marián Labuda > Assignee: Jeff MAURY > Labels: explorer, openshift_v3, ux > Fix For: 4.4.x > > > It would be nice to have a possibility to allow cascading deletion, deletion of related resource/resource managed by the resource which is about to be deleted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22241) OpenShift Explorer: Cascade resource deletion

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22241?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22241: ------------------------------------- Fix Version/s: 4.4.x (was: 4.4.1.Final) > OpenShift Explorer: Cascade resource deletion > --------------------------------------------- > > Key: JBIDE-22241 > URL: https://issues.jboss.org/browse/JBIDE-22241 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.0.Alpha1 > Reporter: Marián Labuda > Assignee: Jeff MAURY > Labels: explorer, openshift_v3, ux > Fix For: 4.4.x > > > It would be nice to have a possibility to allow cascading deletion, deletion of related resource/resource managed by the resource which is about to be deleted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22580) Deploy Docker Image wizard: Cannot push already tagged image to docker registry

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22580?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22580: ------------------------------------- Fix Version/s: 4.4.1.Final (was: 4.4.1.AM3) > 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.1.Final > > > 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22580) Deploy Docker Image wizard: Cannot push already tagged image to docker registry

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22580?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22580: ------------------------------------- Sprint: (was: devex #118 July 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.1.Final > > > 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22239) Allow a user to choose to permanently update their desired replicas for their deployment

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22239?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22239: ------------------------------------- Sprint: devex #119 August 2016 (was: devex #118 July 2016) > Allow a user to choose to permanently update their desired replicas for their deployment > ----------------------------------------------------------------------------------------- > > Key: JBIDE-22239 > URL: https://issues.jboss.org/browse/JBIDE-22239 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.0.Alpha1 > Reporter: Jeff Cantrill > Assignee: Viacheslav Kabanovich > Labels: openshift_v3 > Fix For: 4.4.1.Final > > > When scaling, we should provide an option to a user who is scaling their deployment to update the deploymentconfig desired replias setting. Currently, if you scale the deployment in the explorer view or the replicationcontroller in the tabs view, image or config change triggers from a DC will set the replica count to whats defined their. Suggest: > * Adding a custom dialog in the "..to.." option > * Update to use a spinner > * Add a checkbox to 'make the change perminent' > * If checkbox=true, you should only need to update the dc if it has a configchange trigger. > * Optionally show checkbox if unable to determine the dc associated with the deployment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22239) Allow a user to choose to permanently update their desired replicas for their deployment

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22239?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22239: ------------------------------------- Fix Version/s: 4.4.1.Final (was: 4.4.1.AM3) > Allow a user to choose to permanently update their desired replicas for their deployment > ----------------------------------------------------------------------------------------- > > Key: JBIDE-22239 > URL: https://issues.jboss.org/browse/JBIDE-22239 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.0.Alpha1 > Reporter: Jeff Cantrill > Assignee: Viacheslav Kabanovich > Labels: openshift_v3 > Fix For: 4.4.1.Final > > > When scaling, we should provide an option to a user who is scaling their deployment to update the deploymentconfig desired replias setting. Currently, if you scale the deployment in the explorer view or the replicationcontroller in the tabs view, image or config change triggers from a DC will set the replica count to whats defined their. Suggest: > * Adding a custom dialog in the "..to.." option > * Update to use a spinner > * Add a checkbox to 'make the change perminent' > * If checkbox=true, you should only need to update the dc if it has a configchange trigger. > * Optionally show checkbox if unable to determine the dc associated with the deployment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22362) Server Adapter: Static changes done to nodejs application are not visible

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22362?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22362: ------------------------------------- Fix Version/s: 4.4.1.Final (was: 4.4.1.AM3) > Server Adapter: Static changes done to nodejs application are not visible > ------------------------------------------------------------------------- > > Key: JBIDE-22362 > URL: https://issues.jboss.org/browse/JBIDE-22362 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Alpha2 > Reporter: Marián Labuda > Assignee: Ilya Buziuk > Priority: Critical > Labels: openshift_v3, server_adapter > Fix For: 4.4.1.Final > > > I am having an OpenShift application based either on nodejs-example or nodejs-mongodb-example template. Once application is up and running I create a new server adapter and perform changes in index.html. These changes are static and should be (?) immediately visible on OpenShift server, but they are not. I have checked whether changes were published, but rsync in console shows expected output also changes done manually on the server side to index.html are not visible in browser (even when cache overwritten is triggered - so there is no caching problem in browser). This seems to be upstream issues, but requires investigating. > So far I have tried it on CDK OpenShift. It would be nice to test it on other OpenShift instances, also on templates using different base docker image. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22362) Server Adapter: Static changes done to nodejs application are not visible

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22362?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22362: ------------------------------------- Sprint: devex #119 August 2016 > Server Adapter: Static changes done to nodejs application are not visible > ------------------------------------------------------------------------- > > Key: JBIDE-22362 > URL: https://issues.jboss.org/browse/JBIDE-22362 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Alpha2 > Reporter: Marián Labuda > Assignee: Ilya Buziuk > Priority: Critical > Labels: openshift_v3, server_adapter > Fix For: 4.4.1.Final > > > I am having an OpenShift application based either on nodejs-example or nodejs-mongodb-example template. Once application is up and running I create a new server adapter and perform changes in index.html. These changes are static and should be (?) immediately visible on OpenShift server, but they are not. I have checked whether changes were published, but rsync in console shows expected output also changes done manually on the server side to index.html are not visible in browser (even when cache overwritten is triggered - so there is no caching problem in browser). This seems to be upstream issues, but requires investigating. > So far I have tried it on CDK OpenShift. It would be nice to test it on other OpenShift instances, also on templates using different base docker image. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22362) Server Adapter: Static changes done to nodejs application are not visible

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22362?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22362: ------------------------------------- Sprint: (was: devex #118 July 2016) > Server Adapter: Static changes done to nodejs application are not visible > ------------------------------------------------------------------------- > > Key: JBIDE-22362 > URL: https://issues.jboss.org/browse/JBIDE-22362 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Alpha2 > Reporter: Marián Labuda > Assignee: Ilya Buziuk > Priority: Critical > Labels: openshift_v3, server_adapter > Fix For: 4.4.1.Final > > > I am having an OpenShift application based either on nodejs-example or nodejs-mongodb-example template. Once application is up and running I create a new server adapter and perform changes in index.html. These changes are static and should be (?) immediately visible on OpenShift server, but they are not. I have checked whether changes were published, but rsync in console shows expected output also changes done manually on the server side to index.html are not visible in browser (even when cache overwritten is triggered - so there is no caching problem in browser). This seems to be upstream issues, but requires investigating. > So far I have tried it on CDK OpenShift. It would be nice to test it on other OpenShift instances, also on templates using different base docker image. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22066) Server adapter: Stopping debugging of OpenShift application should get application back to normal state.

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22066?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22066: ------------------------------------- Fix Version/s: 4.4.1.Final (was: 4.4.1.AM3) > Server adapter: Stopping debugging of OpenShift application should get application back to normal state. > -------------------------------------------------------------------------------------------------------- > > Key: JBIDE-22066 > URL: https://issues.jboss.org/browse/JBIDE-22066 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.CR1 > Reporter: Marián Labuda > Assignee: Viacheslav Kabanovich > Labels: openshift_v3, server_adapter > Fix For: 4.4.1.Final > > > When user stop or delete Server Adapter where debugging has been enabled, application should be able to get back to normal state - remove environment variable for debugging and remove ports for debugging from deployment config. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

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 August 2016