[JBoss JIRA] (ERT-248) Improve UI for Docker reconnection use case [EBZ#495600]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-248:
---------------------------------------
Summary: Improve UI for Docker reconnection use case [EBZ#495600]
Key: ERT-248
URL: https://issues.jboss.org/browse/ERT-248
Project: Eclipse Release Train
Issue Type: Task
Components: Linux Tools
Reporter: Friendly Jira Robot
When a docker connection has been disabled, it's hard to make it work again. You need to click the Enable Connection button. This is not very user friendly.
Until today, I thought the connection was either active or inactive. But today I learnt it can also be disabled. In my opinion it's not practical to have a disabled state at all.
Let me describe the scenario I went through. I was using Container Development Kit which is a server adapter and once you start it, it will create a docker connection and connect to it - docker daemon is running inside CDK. But it would work the same way with a Docker Machine that you start, then stop, then start again.
1. Start CDK (once started, it will create a docker connection)
2. Docker connection is grey, but you can expand it.
3. Expand docker connection in docker explorer - it works - you can see images
4. Stop CDK
5. Now the refresher job will timeout, so the docker connection will be disabled
6. Start CDK again
Now I would expect to be able to work with the docker connection again like after the first start of CDK, but I can't, because now the connection has been disabled. So now I need to know that it's disabled and I need to enable it. I think it can be confusing for a lot of people - why do you need an additional step now?
The above steps could be reproduced with docker-machine. But instead of starting CDK, you would simply do "docker-machine start/stop default" from CLI.
I don't have an exact recipe on how this should be done. But I wonder if we need the disabled state at all. Because once a connection becomes inactive, it is no longer expanded, so it won't produce errors all the time. One issue is that if you had the Docker Images view opened at the same time, that one would probably keep trying to connect (if there was no such thing as a disabled docker connection). So I'm not sure how to solve this.
But the most important thing for me would be to make this use case (the steps above) more user friendly - i.e. make reconnection to a docker daemon a smoother experience.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBIDE-22501) CDK stuck on Starting... after launch
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22501?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-22501:
---------------------------------------
I don't see this happening anymore. But I would still be curious to hear from Rob how this could possibly happen.
> CDK stuck on Starting... after launch
> -------------------------------------
>
> Key: JBIDE-22501
> URL: https://issues.jboss.org/browse/JBIDE-22501
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.0.Alpha2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.4.x
>
>
> This happened to me a few times and I think I mentioned it in a JIRA, but AFAIK there is no separate JIRA for this.
> This is what I did today (verifying JBDS-3739):
> 1. Start my Eclipse Neon RC2
> 2. Updated Eclipse
> 3. Updated Docker Tools to latest nightly
> 4. Installed nightly JBoss Tools Abridged
> 5. Set up cdk server (CDK 2.0 on my disk, already set up and started several times before)
> 6. Start CDK server
> Everything fine here - after some time it's Started, I accepted the OpenShift cert, Docker connection worked.
> 7. Stop CDK server
> 8. Start CDK server
> This time it's stuck on Starting... even though I can see from the console that the vagrant box started:
> {code}
> Bringing machine 'default' up with 'virtualbox' provider...
> ==> default: Clearing any previously set forwarded ports...
> ==> default: Clearing any previously set network interfaces...
> ==> default: Preparing network interfaces based on configuration...
> default: Adapter 1: nat
> default: Adapter 2: hostonly
> ==> default: Forwarding ports...
> default: 22 (guest) => 2222 (host) (adapter 1)
> ==> default: Running 'pre-boot' VM customizations...
> ==> default: Booting VM...
> ==> default: Waiting for machine to boot. This may take a few minutes...
> default: SSH address: 127.0.0.1:2222
> default: SSH username: vagrant
> default: SSH auth method: private key
> default: Warning: Remote connection disconnect. Retrying...
> ==> default: Machine booted and ready!
> ==> default: Checking for guest additions in VM...
> default: No guest additions were detected on the base box for this VM! Guest
> default: additions are required for forwarded ports, shared folders, host only
> default: networking, and more. If SSH fails on this machine, please install
> default: the guest additions and repackage the box to continue.
> default:
> default: This is not an error message; everything may continue to work properly,
> default: in which case you may ignore this message.
> ==> default: Configuring and enabling network interfaces...
> ==> default: Registering box with vagrant-registration...
> ==> default: Copying TLS certificates to /Users/rasp/jbossqa/cdk/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
> ==> default: Rsyncing folder: /Users/rasp/jbossqa/cdk/cdk/components/rhel/rhel-ose/ => /vagrant
> ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
> ==> default: flag to force provisioning. Provisioners marked to run always will still run.
> {code}
> Now it will probably time out and stop the server. And most probably next start will work.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months