[JBoss JIRA] (JBIDE-22695) Environment Variables of application deployment should have different workflow
by Marián Labuda (JIRA)
Marián Labuda created JBIDE-22695:
-------------------------------------
Summary: Environment Variables of application deployment should have different workflow
Key: JBIDE-22695
URL: https://issues.jboss.org/browse/JBIDE-22695
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.4.1.AM1
Reporter: Marián Labuda
Priority: Critical
Reset All button in Environment Var wizard dialog should get application to default state. At the moment it reset environment variables in the table just to the values at the point of opening the wizard. If I would delete some environment variables and confirm changes, but I would find out I broke something and I would like to rollback it to original state, I would try to reset it with Reset All button. But it won't work for me. This is causing the more serious issue:
Because we edit same deployment configuration and start deployments from it and in the same time we set number of replicas in other deployment configs to zero. So we don't have the original deployment config and thus we cannot rollback easily (well there is a way but nasty one - edit replication controller, copy and paste environment variables to the deployment config, save it and deploy latest).
There are 2 options:
a) Create a new deployment configuration for a new (modified) set of environment variables and create a new replication controller (deployment) from this deployment configuration. There is one con - it can lead to many deployment configurations and replication controllers (for each deployment configuration there would be one replication controller).
b) Just edit current replication controller (deployment) of an application or create a new one from an existing but with modified env. vars and with correct amount of replicas and set replicas in the previous to 0. One of those approaches (create/edit RC) would be, I think, more satisfying.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22686) Can't push image to docker registry
by Dmitry Bocharov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22686?page=com.atlassian.jira.plugi... ]
Dmitry Bocharov commented on JBIDE-22686:
-----------------------------------------
Hardy, yes. I can reproduce it
{code:bash}
[dbocharov@dhcp-10-40-4-134 openshift]$ ./oc login 10.1.2.2:8443 -u openshift-dev -p devel
Unable to connect to the server: dial tcp 10.1.2.2:8443: getsockopt: no route to host
{code}
> Can't push image to docker registry
> -----------------------------------
>
> Key: JBIDE-22686
> URL: https://issues.jboss.org/browse/JBIDE-22686
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: docker, openshift
> Affects Versions: 4.4.0.Final
> Environment: Fedora 23
> Reporter: Dmitry Bocharov
> Assignee: Dmitry Bocharov
> Attachments: DeployDockerImageToOS.webm
>
>
> The screencast of the last steps is attached.
> Properties and settings of the cdk haven't been changed. Everything is dowloaded and installed in a usual way.
> Possibly something is with the dns - maybe it wasn't configured correctly while cdk installation. Because we to push to the valid url, while OS connection only an IP in its settings.
> _exception:_
> org.eclipse.linuxtools.docker.core.DockerException: com.spotify.docker.client.DockerException: org.eclipse.linuxtools.docker.core.DockerImagePushFailedException: Image push failed: hub.openshift.rhel-cdk.10.1.2.2.xip.io/sample-project/aloha: unable to ping registry endpoint https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v0/
> v2 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v2/: dial tcp 10.1.2.2:443: connection refused
> v1 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v1/_ping: dial tcp 10.1.2.2:443: connection refused
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.pushImage(DockerConnection.java:1047)
> at org.jboss.tools.openshift.internal.ui.dockerutils.PushImageToRegistryJob.doRun(PushImageToRegistryJob.java:67)
> 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)
> Caused by: com.spotify.docker.client.DockerException: org.eclipse.linuxtools.docker.core.DockerImagePushFailedException: Image push failed: hub.openshift.rhel-cdk.10.1.2.2.xip.io/sample-project/aloha: unable to ping registry endpoint https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v0/
> v2 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v2/: dial tcp 10.1.2.2:443: connection refused
> v1 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v1/_ping: dial tcp 10.1.2.2:443: connection refused
> at org.eclipse.linuxtools.internal.docker.core.DockerProgressHandler.progress(DockerProgressHandler.java:42)
> at com.spotify.docker.client.ProgressStream.tail(ProgressStream.java:74)
> at com.spotify.docker.client.DefaultDockerClient.push(DefaultDockerClient.java:821)
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.pushImage(DockerConnection.java:1043)
> ... 3 more
> Caused by: org.eclipse.linuxtools.docker.core.DockerImagePushFailedException: Image push failed: hub.openshift.rhel-cdk.10.1.2.2.xip.io/sample-project/aloha: unable to ping registry endpoint https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v0/
> v2 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v2/: dial tcp 10.1.2.2:443: connection refused
> v1 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v1/_ping: dial tcp 10.1.2.2:443: connection refused
> at org.eclipse.linuxtools.internal.docker.ui.views.ImagePushProgressHandler.processMessage(ImagePushProgressHandler.java:49)
> at org.eclipse.linuxtools.internal.docker.core.DockerProgressHandler.progress(DockerProgressHandler.java:40)
> ... 6 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22695) Environment Variables of application deployment should have different workflow
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22695?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-22695:
----------------------------------
Description:
Reset All button in Environment Var wizard dialog should get application to default state. At the moment it reset environment variables in the table just to the values at the point of opening the wizard. If I would delete some environment variables and confirm changes, but I would find out I broke something and I would like to rollback it to original state, I would try to reset it with Reset All button. But it won't work for me. This is causing the more serious issue:
Because we edit same deployment configuration and start deployments from it and in the same time we set number of replicas in other deployment configs to zero. So we don't have the original deployment config and thus we cannot rollback easily (well there is a way but nasty one - edit replication controller, copy and paste environment variables to the deployment config, save it and deploy latest).
There are 2 options:
a) Create a new deployment configuration for a new (modified) set of environment variables and create a new replication controller (deployment) from this deployment configuration. There is one con - it can lead to many deployment configurations and replication controllers (for each deployment configuration there would be one replication controller).
b) Just edit current replication controller (deployment) of an application or create a new one from an existing but with modified env. vars and with correct amount of replicas and set replicas in the previous to 0. And then let respin pods with correct setup. One of those approaches (create/edit RC) would be, I think, more satisfying.
was:
Reset All button in Environment Var wizard dialog should get application to default state. At the moment it reset environment variables in the table just to the values at the point of opening the wizard. If I would delete some environment variables and confirm changes, but I would find out I broke something and I would like to rollback it to original state, I would try to reset it with Reset All button. But it won't work for me. This is causing the more serious issue:
Because we edit same deployment configuration and start deployments from it and in the same time we set number of replicas in other deployment configs to zero. So we don't have the original deployment config and thus we cannot rollback easily (well there is a way but nasty one - edit replication controller, copy and paste environment variables to the deployment config, save it and deploy latest).
There are 2 options:
a) Create a new deployment configuration for a new (modified) set of environment variables and create a new replication controller (deployment) from this deployment configuration. There is one con - it can lead to many deployment configurations and replication controllers (for each deployment configuration there would be one replication controller).
b) Just edit current replication controller (deployment) of an application or create a new one from an existing but with modified env. vars and with correct amount of replicas and set replicas in the previous to 0. One of those approaches (create/edit RC) would be, I think, more satisfying.
> Environment Variables of application deployment should have different workflow
> ------------------------------------------------------------------------------
>
> Key: JBIDE-22695
> URL: https://issues.jboss.org/browse/JBIDE-22695
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM1
> Reporter: Marián Labuda
> Priority: Critical
> Labels: openshift_v3
>
> Reset All button in Environment Var wizard dialog should get application to default state. At the moment it reset environment variables in the table just to the values at the point of opening the wizard. If I would delete some environment variables and confirm changes, but I would find out I broke something and I would like to rollback it to original state, I would try to reset it with Reset All button. But it won't work for me. This is causing the more serious issue:
> Because we edit same deployment configuration and start deployments from it and in the same time we set number of replicas in other deployment configs to zero. So we don't have the original deployment config and thus we cannot rollback easily (well there is a way but nasty one - edit replication controller, copy and paste environment variables to the deployment config, save it and deploy latest).
> There are 2 options:
> a) Create a new deployment configuration for a new (modified) set of environment variables and create a new replication controller (deployment) from this deployment configuration. There is one con - it can lead to many deployment configurations and replication controllers (for each deployment configuration there would be one replication controller).
> b) Just edit current replication controller (deployment) of an application or create a new one from an existing but with modified env. vars and with correct amount of replicas and set replicas in the previous to 0. And then let respin pods with correct setup. One of those approaches (create/edit RC) would be, I think, more satisfying.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ERT-335) Implement more keyboard shortcuts in Docker View [EBZ#497474]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-335:
---------------------------------------
Summary: Implement more keyboard shortcuts in Docker View [EBZ#497474]
Key: ERT-335
URL: https://issues.jboss.org/browse/ERT-335
Project: Eclipse Release Train
Issue Type: Task
Components: Linux Tools
Reporter: Friendly Jira Robot
Priority: Trivial
Shortcut for Refresh (F5) is implemented, but other shortcuts are not, for example Delete for removing images/containers etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22677) rsync stuck on OSX
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22677?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-22677:
-------------------------------------
I opened https://github.com/openshift/origin/issues/9726 upstream.
The same problem can be reproduced from CLI, when using the same command
> rsync stuck on OSX
> ------------------
>
> Key: JBIDE-22677
> URL: https://issues.jboss.org/browse/JBIDE-22677
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Fred Bricon
> Assignee: Dmitry Bocharov
> Priority: Blocker
>
> I deployed an eap app from the eap64-basic-s2i template, then created an openshift 3 server.
> On server startup, publishing fails to complete after 5 minutes and a thread dump shows rsync is still blocking in the background.
> {noformat}
> "pool-40-thread-1" #231 prio=5 os_prio=31 tid=0x00007f9a55dd0000 nid=0xeb9f runnable [0x000000013199a000]
> java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:255)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x00000007b3d45cb8> (a java.lang.UNIXProcess$ProcessPipeInputStream)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> - locked <0x00000007b3d49d50> (a java.io.InputStreamReader)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> - locked <0x00000007b3d49d50> (a java.io.InputStreamReader)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> at org.jboss.tools.openshift.core.server.RSync.lambda$0(RSync.java:152)
> at org.jboss.tools.openshift.core.server.RSync$$Lambda$181/1635081930.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> I'm deploying on CDK 2.1RC5
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22694) Environment Var Wizard: Improve deletion of environment variables
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22694?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-22694:
----------------------------------
Labels: env_var_wizard openshift_v3 (was: )
> Environment Var Wizard: Improve deletion of environment variables
> -----------------------------------------------------------------
>
> Key: JBIDE-22694
> URL: https://issues.jboss.org/browse/JBIDE-22694
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.1.AM1
> Reporter: Marián Labuda
> Labels: env_var_wizard, openshift_v3
>
> Deletion of environment variable does not match user expectation. If I delete an environment variable which has been added in earlier opened and closed Env. Var wizard, this variable has prefix [deleted]. I don't think this is good practice, we should be consistent across all wizards and dialog, so once user select an env var in table and push Delete button, value should be removed from the table. No labelling should be done here, the table should reflect real current state of environment variable (what it is gonna look like once I hit Finish button).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22694) Environment Var Wizard: Improve deletion of environment variables
by Marián Labuda (JIRA)
Marián Labuda created JBIDE-22694:
-------------------------------------
Summary: Environment Var Wizard: Improve deletion of environment variables
Key: JBIDE-22694
URL: https://issues.jboss.org/browse/JBIDE-22694
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.1.AM1
Reporter: Marián Labuda
Deletion of environment variable does not match user expectation. If I delete an environment variable which has been added in earlier opened and closed Env. Var wizard, this variable has prefix [deleted]. I don't think this is good practice, we should be consistent across all wizards and dialog, so once user select an env var in table and push Delete button, value should be removed from the table. No labelling should be done here, the table should reflect real current state of environment variable (what it is gonna look like once I hit Finish button).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months