[JBoss JIRA] (JBIDE-23013) Pull Docker Tooling bits into JBT builds more frequently
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23013?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-23013:
---------------------------------------
{quote}The other option would be to treat docker/vagrant tooling like a first-class component of JBoss Tools, and fetch it into the JBT aggregate site, rather than the target platform.{quote}
Yes, this idea occurred to me when I woke up in the middle of the night last night ;) I think it's definitely worth considering. Fetching from the nightly site would mean actually copying the bits, right? Because simply pointing to docker nightly site would probably not be the best idea.
> Pull Docker Tooling bits into JBT builds more frequently
> --------------------------------------------------------
>
> Key: JBIDE-23013
> URL: https://issues.jboss.org/browse/JBIDE-23013
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build, target-platform
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Nick Boldt
>
> It would be cool if we could update the Docker Tooling bits in our TP more frequently, i.e. weekly or even nightly. I know that currently it is quite a big effort to update TP. So we would need to simplify this somehow.
> So this is a suggestion, but I don't know how we would do it or if it's doable at all.
> Here's a bit of background:
> Today I spotted this blocking bug in docker tooling:
> https://issues.jboss.org/browse/JBIDE-23011
> It was probably brought into JBT TP in the last update of the TP - this JIRA:
> https://issues.jboss.org/browse/JBIDE-22885 - 4 days ago.
> Jeff Maury suggested, that it's a bad idea to update our TP this close to our release (AM3 in this case). But currently we don't have any other option.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBDS-3822) Disable the annoying "This program might not have installed correctly" on cancelation
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3822?page=com.atlassian.jira.plugin.... ]
Denis Golovin edited comment on JBDS-3822 at 8/17/16 3:56 AM:
--------------------------------------------------------------
adding record into installed programs with running powershell uninstall.ps1 script might fix JBDS-3959 as well.
was (Author: dgolovin):
adding record into installed programs with running powershell uninstall.ps1 script might fix JBDS-3822as well.
> Disable the annoying "This program might not have installed correctly" on cancelation
> -------------------------------------------------------------------------------------
>
> Key: JBDS-3822
> URL: https://issues.jboss.org/browse/JBDS-3822
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: platform-installer
> Affects Versions: 9.1.0.CR1
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Labels: havoc
> Fix For: 10.1.0.GA
>
> Attachments: devsuite.manifest
>
>
> Upon closing/cancelling the installer before going through the entire installation process, Windows will open a dialog saying "This program might not have installed correctly" and the user has to somehow confirm it.
> This should be avoided by providing an application manifest that indicates support for certain Windows versions.
> Docs here:
> https://msdn.microsoft.com/en-us/library/dd371711%28VS.85%29.aspx
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23010) landrush plugin prevents CDK server adapter from starting
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23010?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-23010:
---------------------------------------
Using the VagrantLauncher.java test program, I am able to see the problem.
With cdk 2.1 shared_folder setup, I get this end the end (and the process never finishes):
{code}
waitFor returned:0
output thread died
{code}
The error thread never dies.
With cdk 2.2 rc1 including landrush, I get this:
{code}
waitFor returned:0
{code}
As you can see, not even the output thread dies here. Both stay alive after vagrant up is finished.
> landrush plugin prevents CDK server adapter from starting
> ---------------------------------------------------------
>
> Key: JBIDE-23010
> URL: https://issues.jboss.org/browse/JBIDE-23010
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, upstream
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Critical
>
> Today I downloaded cdk 2.2.rc1 [1], installed all the vagrant plugins from scratch. And then I first started this from CLI - it wanted password for sudo to set up landrush. (That's another concern I have: How will this work in devstudio? Probably it won't.)
> Then I stopped it, set up in devstudio and start there. Everything looks fine, but the server adapter is stuck at "Starting...".
> This is the console output:
> {code}
> Bringing machine 'default' up with 'virtualbox' provider...
> ==> default: Clearing any previously set forwarded ports...
> ==> default: Clearing any previously set network interfaces...
> ==> default: [landrush] virtualbox requires an additional private network; adding it
> ==> default: [landrush] starting dns server
> ==> 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: Warning: Remote connection disconnect. Retrying...
> default: Warning: Remote connection disconnect. Retrying...
> ==> default: Machine booted and ready!
> ==> default: Registering box with vagrant-registration...
> ==> 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: Setting hostname...
> ==> default: Configuring and enabling network interfaces...
> [landrush] Using eth1 (172.28.128.3)
> ==> default: [landrush] adding machine entry: cdk.vm => 172.28.128.3
> ==> default: [landrush] adding static DNS entry: cdk => cdk.vm
> [landrush] Using eth1 (172.28.128.3)
> [landrush] Host DNS resolver config looks good.
> ==> default: Copying TLS certificates to /Users/rasp/jbossqa/cdk2.2.rc1/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
> ==> default: Mounting SSHFS shared folder...
> ==> default: Mounting folder via SSHFS: /Users/rasp => /Users/rasp
> ==> default: Checking Mount..
> ==> default: Checking Mount..
> ==> default: Folder Successfully Mounted!
> ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
> ==> default: flag to force provisioning. Provisioners marked to run always will still run.
> ==> default: Running provisioner: shell...
> default: Running: inline script
> ==> default: Running provisioner: shell...
> default: Running: inline script
> ==> default:
> ==> default: Successfully started and provisioned VM with 2 cores and 3072 MB of memory.
> ==> default: To modify the number of cores and/or available memory set the environment variables
> ==> default: VM_CPU respectively VM_MEMORY.
> ==> default:
> ==> default: You can now access the OpenShift console on: https://openshift.cdk:8443/console
> ==> default:
> ==> default: To use OpenShift CLI, run:
> ==> default: $ vagrant ssh
> ==> default: $ oc login
> ==> default:
> ==> default: Configured users are (<username>/<password>):
> ==> default: openshift-dev/devel
> ==> default: admin/admin
> ==> default:
> ==> default: If you have the oc client library on your host, you can also login from your host.
> {code}
> These are my plugins:
> {code}
> $ vagrant plugin list
> landrush (1.1.1)
> - Version Constraint: 1.1.1
> vagrant-registration (1.2.3)
> - Version Constraint: 1.2.3
> vagrant-service-manager (1.3.0)
> - Version Constraint: 1.3.0
> vagrant-share (1.1.5, system)
> vagrant-sshfs (1.2.0)
> - Version Constraint: 1.2.0
> {code}
> [1] http://cdk-builds.usersys.redhat.com/builds/weekly/12-Aug-2016.rc1/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBDS-3812) Target folder input looks weird
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3812?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3812:
--------------------------------
Sprint: devex #119 August 2016
> Target folder input looks weird
> -------------------------------
>
> Key: JBDS-3812
> URL: https://issues.jboss.org/browse/JBDS-3812
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 9.1.0.CR1
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Labels: havoc, ui
> Fix For: 10.1.0.AM3
>
> Attachments: selected.png, unselected.png
>
>
> There are a few visual issues with the target folder input group that make it look really weird:
> - When not focused, there is no real border around the input box, just a little line on the bottom
> - The Browse button is shoved right on top of the input field - when the field is focused, its border is hidden under the button on the right
> - The input field should probably be auto-focused
> - When the validation message shows an error, it has a red icon with black text
> - The path with spaces warning has black text - plus since this path is not allowed, it should show as error, not a warning
> - The message that folder will be created looks exactly like a warning, it should be styled as info (no orange text and icon)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23010) landrush plugin prevents CDK server adapter from starting
by Brian Exelbierd (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23010?page=com.atlassian.jira.plugi... ]
Brian Exelbierd commented on JBIDE-23010:
-----------------------------------------
Based on my conversation with mmalina, yes, this does not block AM3, but is a blocker for CDK2.2
> landrush plugin prevents CDK server adapter from starting
> ---------------------------------------------------------
>
> Key: JBIDE-23010
> URL: https://issues.jboss.org/browse/JBIDE-23010
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, upstream
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Critical
>
> Today I downloaded cdk 2.2.rc1 [1], installed all the vagrant plugins from scratch. And then I first started this from CLI - it wanted password for sudo to set up landrush. (That's another concern I have: How will this work in devstudio? Probably it won't.)
> Then I stopped it, set up in devstudio and start there. Everything looks fine, but the server adapter is stuck at "Starting...".
> This is the console output:
> {code}
> Bringing machine 'default' up with 'virtualbox' provider...
> ==> default: Clearing any previously set forwarded ports...
> ==> default: Clearing any previously set network interfaces...
> ==> default: [landrush] virtualbox requires an additional private network; adding it
> ==> default: [landrush] starting dns server
> ==> 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: Warning: Remote connection disconnect. Retrying...
> default: Warning: Remote connection disconnect. Retrying...
> ==> default: Machine booted and ready!
> ==> default: Registering box with vagrant-registration...
> ==> 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: Setting hostname...
> ==> default: Configuring and enabling network interfaces...
> [landrush] Using eth1 (172.28.128.3)
> ==> default: [landrush] adding machine entry: cdk.vm => 172.28.128.3
> ==> default: [landrush] adding static DNS entry: cdk => cdk.vm
> [landrush] Using eth1 (172.28.128.3)
> [landrush] Host DNS resolver config looks good.
> ==> default: Copying TLS certificates to /Users/rasp/jbossqa/cdk2.2.rc1/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
> ==> default: Mounting SSHFS shared folder...
> ==> default: Mounting folder via SSHFS: /Users/rasp => /Users/rasp
> ==> default: Checking Mount..
> ==> default: Checking Mount..
> ==> default: Folder Successfully Mounted!
> ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
> ==> default: flag to force provisioning. Provisioners marked to run always will still run.
> ==> default: Running provisioner: shell...
> default: Running: inline script
> ==> default: Running provisioner: shell...
> default: Running: inline script
> ==> default:
> ==> default: Successfully started and provisioned VM with 2 cores and 3072 MB of memory.
> ==> default: To modify the number of cores and/or available memory set the environment variables
> ==> default: VM_CPU respectively VM_MEMORY.
> ==> default:
> ==> default: You can now access the OpenShift console on: https://openshift.cdk:8443/console
> ==> default:
> ==> default: To use OpenShift CLI, run:
> ==> default: $ vagrant ssh
> ==> default: $ oc login
> ==> default:
> ==> default: Configured users are (<username>/<password>):
> ==> default: openshift-dev/devel
> ==> default: admin/admin
> ==> default:
> ==> default: If you have the oc client library on your host, you can also login from your host.
> {code}
> These are my plugins:
> {code}
> $ vagrant plugin list
> landrush (1.1.1)
> - Version Constraint: 1.1.1
> vagrant-registration (1.2.3)
> - Version Constraint: 1.2.3
> vagrant-service-manager (1.3.0)
> - Version Constraint: 1.3.0
> vagrant-share (1.1.5, system)
> vagrant-sshfs (1.2.0)
> - Version Constraint: 1.2.0
> {code}
> [1] http://cdk-builds.usersys.redhat.com/builds/weekly/12-Aug-2016.rc1/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23009) Cannot connect to cdk 2.2 docker in Docker Explorer
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23009?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-23009:
---------------------------------------
Thanks [~xcoulon]. Can you explain a bit what is actually wrong? What changed in cdk 2.2 docker that spotify client can't cope with?
> Cannot connect to cdk 2.2 docker in Docker Explorer
> ---------------------------------------------------
>
> Key: JBIDE-23009
> URL: https://issues.jboss.org/browse/JBIDE-23009
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: docker
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Xavier Coulon
> Priority: Critical
>
> When I start CDK 2.2, docker connection is correctly created, but it cannot connect. There is no error message anywhere.
> If I try to create a connection manually, using details from "vagrant service-manager env", the ping fails and it doesn't work either.
> Connection from CLI, on the other hand, to this docker daemon works fine - when I run the export commands:
> {code}
> export DOCKER_HOST=tcp://172.28.128.3:2376
> export DOCKER_CERT_PATH=/Users/rasp/jbossqa/cdk2.2.rc1/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
> export DOCKER_TLS_VERIFY=1
> export DOCKER_API_VERSION=1.22
> {code}
> and then try for example "docker ps" or "docker run hello-world".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months