[JBoss JIRA] (JBDS-3615) virtual box cannot be installed reliably on windows
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3615?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3615:
-------------------------------------
Failed again on demo havoc demo today. This time no reboot request and overal VirtualBox installation is reported as Successful, but vagrant up reported that VM is in unexpected state. Solution is to remove/install virtual box.
After inspecting attached log I found the only problem reported in log:
{code}DIFXAPP: RETURN: InstallDriverPackages() 0 (0x0)
CreateHostOnlyInterface: Creating host-only interface
CreateHostOnlyInterface: NetAdpDir property = C:\DeveloperPlatform\virtualbox\drivers\network\netadp6\
CreateHostOnlyInterface: Resulting INF path = C:\DeveloperPlatform\virtualbox\drivers\network\netadp6\VBoxNetAdp6.inf
CreateHostOnlyInterface: Calling VBoxDrvCfgInfInstall(C:\DeveloperPlatform\virtualbox\drivers\network\netadp6\VBoxNetAdp6.inf)
CreateHostOnlyInterface: VBoxDrvCfgInfInstall returns 0x0
UpdateHostOnlyInterfaces: VBoxNetCfgWinUpdateHostOnlyNetworkInterface failed, hr = 0xe000020b
CreateHostOnlyInterface: calling VBoxNetCfgWinCreateHostOnlyNetworkInterface
Querying NetCfgInstanceId failed (0x00000000)
CreateHostOnlyInterface: VBoxNetCfgWinCreateHostOnlyNetworkInterface returns 0x80004005
CreateHostOnlyInterface: VBoxNetCfgWinCreateHostOnlyNetworkInterface failed, error = 0x80004005
CreateHostOnlyInterface: Almost done...
CreateHostOnlyInterface: Returns success (ignoring all failures){code}
VirtualBox issue https://www.virtualbox.org/ticket/14545
> virtual box cannot be installed reliably on windows
> ---------------------------------------------------
>
> Key: JBDS-3615
> URL: https://issues.jboss.org/browse/JBDS-3615
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Blocker
> Labels: havoc
> Fix For: 9.1.0.CR1
>
>
> look at docker-toolbox what they do that is different.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21836) Preferences: openshift 3 oc location resets to a different/old value on restart
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21836?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-21836 at 3/9/16 10:18 AM:
-------------------------------------------------------------------
[~fbricon] [~maxandersen] very good chances, I tried reproducing but failed and then thought maybe I could if I was missing oc in PATH, but even then, I couldnt.
was (Author: adietish):
[~fbricon] [~maxandersen] very good chances, I tried reproducing but failed and then though maybe I could if I was missing oc in PATH, but even then, I couldnt.
> Preferences: openshift 3 oc location resets to a different/old value on restart
> -------------------------------------------------------------------------------
>
> Key: JBIDE-21836
> URL: https://issues.jboss.org/browse/JBIDE-21836
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Max Rydahl Andersen
> Priority: Blocker
> Labels: oc_binary, openshift_v3, preferences
> Fix For: 4.3.1.CR1
>
>
> on start of eclipse new workspace the value is for reason unknown to me set to:
> {code}
> /Users/max/Downloads/openshift-origin-v1.0.3-1695461-darwin-amd64/oc
> {code}
> which does exist, but is old version and publish fails.
> Then I set it to
> {code}
> /usr/local/bin/oc
> {code}
> now publish works.
> Restart eclipse - old value returns and publish starts failing again.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21836) Preferences: openshift 3 oc location resets to a different/old value on restart
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21836?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-21836:
------------------------------------------
[~fbricon] [~maxandersen] very good chances, I tried reproducing but failed and then though maybe I could if I was missing oc in PATH, but even then, I couldnt.
> Preferences: openshift 3 oc location resets to a different/old value on restart
> -------------------------------------------------------------------------------
>
> Key: JBIDE-21836
> URL: https://issues.jboss.org/browse/JBIDE-21836
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Max Rydahl Andersen
> Priority: Blocker
> Labels: oc_binary, openshift_v3, preferences
> Fix For: 4.3.1.CR1
>
>
> on start of eclipse new workspace the value is for reason unknown to me set to:
> {code}
> /Users/max/Downloads/openshift-origin-v1.0.3-1695461-darwin-amd64/oc
> {code}
> which does exist, but is old version and publish fails.
> Then I set it to
> {code}
> /usr/local/bin/oc
> {code}
> now publish works.
> Restart eclipse - old value returns and publish starts failing again.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21836) openshift 3 oc locaiton resets to a different/old value on restart
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21836?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21836:
-------------------------------------
Fix Version/s: 4.3.1.CR1
> openshift 3 oc locaiton resets to a different/old value on restart
> ------------------------------------------------------------------
>
> Key: JBIDE-21836
> URL: https://issues.jboss.org/browse/JBIDE-21836
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Max Rydahl Andersen
> Priority: Blocker
> Labels: oc_binary, openshift_v3, preferences
> Fix For: 4.3.1.CR1
>
>
> on start of eclipse new workspace the value is for reason unknown to me set to:
> {code}
> /Users/max/Downloads/openshift-origin-v1.0.3-1695461-darwin-amd64/oc
> {code}
> which does exist, but is old version and publish fails.
> Then I set it to
> {code}
> /usr/local/bin/oc
> {code}
> now publish works.
> Restart eclipse - old value returns and publish starts failing again.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21836) Preferences: openshift 3 oc location resets to a different/old value on restart
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21836?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21836:
-------------------------------------
Summary: Preferences: openshift 3 oc location resets to a different/old value on restart (was: openshift 3 oc locaiton resets to a different/old value on restart)
> Preferences: openshift 3 oc location resets to a different/old value on restart
> -------------------------------------------------------------------------------
>
> Key: JBIDE-21836
> URL: https://issues.jboss.org/browse/JBIDE-21836
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Max Rydahl Andersen
> Priority: Blocker
> Labels: oc_binary, openshift_v3, preferences
> Fix For: 4.3.1.CR1
>
>
> on start of eclipse new workspace the value is for reason unknown to me set to:
> {code}
> /Users/max/Downloads/openshift-origin-v1.0.3-1695461-darwin-amd64/oc
> {code}
> which does exist, but is old version and publish fails.
> Then I set it to
> {code}
> /usr/local/bin/oc
> {code}
> now publish works.
> Restart eclipse - old value returns and publish starts failing again.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21836) Preferences: openshift 3 oc location resets to a different/old value on restart
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21836?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21836:
-------------------------------------
Labels: oc_binary openshift_v3 preferences (was: )
> Preferences: openshift 3 oc location resets to a different/old value on restart
> -------------------------------------------------------------------------------
>
> Key: JBIDE-21836
> URL: https://issues.jboss.org/browse/JBIDE-21836
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Max Rydahl Andersen
> Priority: Blocker
> Labels: oc_binary, openshift_v3, preferences
> Fix For: 4.3.1.CR1
>
>
> on start of eclipse new workspace the value is for reason unknown to me set to:
> {code}
> /Users/max/Downloads/openshift-origin-v1.0.3-1695461-darwin-amd64/oc
> {code}
> which does exist, but is old version and publish fails.
> Then I set it to
> {code}
> /usr/local/bin/oc
> {code}
> now publish works.
> Restart eclipse - old value returns and publish starts failing again.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21843) CDK Poller always fails on OSX
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21843?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-21843:
--------------------------------
Description:
Starting the CDK on OSX always fails. Whether it was already started from CLI or not.
The vagrant up command is properly executed, you can see the output in the console, but it ends up with a message "Server CDK Server Adapter at localhost failed to start."
I traced the problem back to:
{noformat}
VagrantPoller.parseOutput(String[]) line: 220
VagrantPoller.onePing(IServer, String) line: 160
VagrantPoller.onePing(IServer) line: 138
VagrantPoller.getCurrentStateSynchronous(IServer) line: 114
CDKLaunchController$2.run() line: 222
{noformat}
In parseOutput, the value of lines is :
[1457536005,,error-exit,Vagrant::Errors::ProviderNotUsable,The provider 'virtualbox' that was requested to back the machine\n'cdk' is reporting that it isn't usable on this system. The\nreason is shown below:\n\nVagrant could not detect VirtualBox! Make sure VirtualBox is properly installed.\nVagrant uses the `VBoxManage` binary that ships with VirtualBox%!(VAGRANT_COMMA) and requires\nthis to be available on the PATH. If VirtualBox is installed%!(VAGRANT_COMMA) please find the\n`VBoxManage` binary and add it to the PATH environmental variable.]
this is not properly parsed as it later goes into this block
{code}
Collection<VagrantStatus> stats = status.values();
if( stats.size() == 0 ) {
return IStatus.ERROR;
}
{code}
And the message in the lines is lost completely
was:
Starting the CDK on OSX always fails. Whether it was already started from CLI or not.
The vagrant up command is properly executed, you can see the output in the console, but it ends up with a message "Server CDK Server Adapter at localhost failed to start."
{noformat}
VagrantPoller.parseOutput(String[]) line: 220
VagrantPoller.onePing(IServer, String) line: 160
VagrantPoller.onePing(IServer) line: 138
VagrantPoller.getCurrentStateSynchronous(IServer) line: 114
CDKLaunchController$2.run() line: 222
{noformat}
In parseOutput, the value of lines is :
[1457536005,,error-exit,Vagrant::Errors::ProviderNotUsable,The provider 'virtualbox' that was requested to back the machine\n'cdk' is reporting that it isn't usable on this system. The\nreason is shown below:\n\nVagrant could not detect VirtualBox! Make sure VirtualBox is properly installed.\nVagrant uses the `VBoxManage` binary that ships with VirtualBox%!(VAGRANT_COMMA) and requires\nthis to be available on the PATH. If VirtualBox is installed%!(VAGRANT_COMMA) please find the\n`VBoxManage` binary and add it to the PATH environmental variable.]
this is not properly parsed as it later goes into this block
{code}
Collection<VagrantStatus> stats = status.values();
if( stats.size() == 0 ) {
return IStatus.ERROR;
}
{code}
And the message in the lines is lost completely
> CDK Poller always fails on OSX
> ------------------------------
>
> Key: JBIDE-21843
> URL: https://issues.jboss.org/browse/JBIDE-21843
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.CR1
> Environment: OSX
> Reporter: Fred Bricon
> Assignee: Rob Stryker
> Priority: Critical
>
> Starting the CDK on OSX always fails. Whether it was already started from CLI or not.
> The vagrant up command is properly executed, you can see the output in the console, but it ends up with a message "Server CDK Server Adapter at localhost failed to start."
> I traced the problem back to:
> {noformat}
> VagrantPoller.parseOutput(String[]) line: 220
> VagrantPoller.onePing(IServer, String) line: 160
> VagrantPoller.onePing(IServer) line: 138
> VagrantPoller.getCurrentStateSynchronous(IServer) line: 114
> CDKLaunchController$2.run() line: 222
> {noformat}
> In parseOutput, the value of lines is :
> [1457536005,,error-exit,Vagrant::Errors::ProviderNotUsable,The provider 'virtualbox' that was requested to back the machine\n'cdk' is reporting that it isn't usable on this system. The\nreason is shown below:\n\nVagrant could not detect VirtualBox! Make sure VirtualBox is properly installed.\nVagrant uses the `VBoxManage` binary that ships with VirtualBox%!(VAGRANT_COMMA) and requires\nthis to be available on the PATH. If VirtualBox is installed%!(VAGRANT_COMMA) please find the\n`VBoxManage` binary and add it to the PATH environmental variable.]
> this is not properly parsed as it later goes into this block
> {code}
> Collection<VagrantStatus> stats = status.values();
> if( stats.size() == 0 ) {
> return IStatus.ERROR;
> }
> {code}
> And the message in the lines is lost completely
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21828) OpenShift Explorer view flickers when refreshing a service
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21828?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-21828:
-----------------------------------------------
The first point (new substracture is created internally in a silent manner) is critical for performance in large models. Suppose, an object is added which has thousands of objects in its sub-tree. This object was not in model, adding just it one already loaded and firing only one event for it is good enough for all clients, both UI and core. If it is first added while not loaded, fired to make clients aware of it, and then is loaded firing thousands of events, then it puts high load to performance.
This can be easily reconciled with observable framework by this trick: do not add new object and do not bind it to listeners until it is loaded. Then, what if the object should be lazy to load, what then is the difference? That is where merge is important. Model knows its loaded nodes, when merging into the existing structure, the merge process will prompt new structure to 'expand' to needed level. And it is important that it will not be prompted by UI which would bounce loading between UI thread and non-UI thread, entangling them and making both performance and UI-refresh problems.
And to follow this approach, separating model from content provider is inevitable. The content provider is prompted by UI every time it gets an event, we then are at the hard choice sync/async. If model is separate, the choice is easy, it is one - just get from the model what it has at the moment and watch for next events, and process it with refresh() - whatever the order of events, that will give ui the most recent state of model. Model, when requested for children of an object which is not fully loaded yet, will start a loading job, and due to merge, clients will be notified only of exact incremental changes in known to them objects. Compare it to the approach of removing all children then adding new children and letting ui prompt them to load thus causing a lot of events and ui forgetfulness of the expanded state that should be solved on ui side.
> OpenShift Explorer view flickers when refreshing a service
> ----------------------------------------------------------
>
> Key: JBIDE-21828
> URL: https://issues.jboss.org/browse/JBIDE-21828
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Xavier Coulon
> Attachments: Screenshot 2016-03-08 10.32.39.png
>
>
> When calling the "Refresh" command on a service, the tree view flickers because of too many refresh calls.
> Adding some traces revealed 25 calls to {{BaseExplorerContentProvider#refreshViewer(Object)}}, which seems way too much for a service with a single pod.
> Attachement: screenshot of the OpenShift Server view, showing 2 projects, one of which has 3 services.
> Custom/added logs in the console:
> {code}
> Refreshing viewer from org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectUIModel@431dafbc
> Refreshing viewer from org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectUIModel@431dafbc
> Refreshing viewer from org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectUIModel@431dafbc
> Refreshing viewer from org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectUIModel@431dafbc
> Refreshing viewer from org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectUIModel@431dafbc
> Refreshing viewer from org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectUIModel@431dafbc
> Refreshing viewer from sample/jee-sample
> Refreshing viewer from sample/jee-sample
> Refreshing viewer from sample/jee-sample
> Refreshing viewer from sample/jee-sample
> Refreshing viewer from sample/mongodb
> Refreshing viewer from sample/mongodb
> Refreshing viewer from sample/mongodb
> Refreshing viewer from sample/nodejs-mongodb-example
> Refreshing viewer from sample/nodejs-mongodb-example
> Refreshing viewer from sample/nodejs-mongodb-example
> Refreshing viewer from sample/nodejs-mongodb-example
> Refreshing viewer from sample/jee-sample
> Refreshing viewer from sample/jee-sample
> Refreshing viewer from sample/jee-sample
> Refreshing viewer from sample/jee-sample
> Refreshing viewer from sample/nodejs-mongodb-example
> Refreshing viewer from sample/nodejs-mongodb-example
> Refreshing viewer from org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectUIModel@431dafbc
> Refreshing viewer from org.jboss.tools.openshift.internal.ui.models.OpenShiftProjectUIModel@431dafbc
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21843) CDK Poller always fails on OSX
by Fred Bricon (JIRA)
Fred Bricon created JBIDE-21843:
-----------------------------------
Summary: CDK Poller always fails on OSX
Key: JBIDE-21843
URL: https://issues.jboss.org/browse/JBIDE-21843
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: cdk
Affects Versions: 4.3.1.CR1
Environment: OSX
Reporter: Fred Bricon
Priority: Critical
Starting the CDK on OSX always fails. Whether it was already started from CLI or not.
The vagrant up command is properly executed, you can see the output in the console, but it ends up with a message "Server CDK Server Adapter at localhost failed to start."
{noformat}
VagrantPoller.parseOutput(String[]) line: 220
VagrantPoller.onePing(IServer, String) line: 160
VagrantPoller.onePing(IServer) line: 138
VagrantPoller.getCurrentStateSynchronous(IServer) line: 114
CDKLaunchController$2.run() line: 222
{noformat}
In parseOutput, the value of lines is :
[1457536005,,error-exit,Vagrant::Errors::ProviderNotUsable,The provider 'virtualbox' that was requested to back the machine\n'cdk' is reporting that it isn't usable on this system. The\nreason is shown below:\n\nVagrant could not detect VirtualBox! Make sure VirtualBox is properly installed.\nVagrant uses the `VBoxManage` binary that ships with VirtualBox%!(VAGRANT_COMMA) and requires\nthis to be available on the PATH. If VirtualBox is installed%!(VAGRANT_COMMA) please find the\n`VBoxManage` binary and add it to the PATH environmental variable.]
this is not properly parsed as it later goes into this block
{code}
Collection<VagrantStatus> stats = status.values();
if( stats.size() == 0 ) {
return IStatus.ERROR;
}
{code}
And the message in the lines is lost completely
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21843) CDK Poller always fails on OSX
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21843?page=com.atlassian.jira.plugi... ]
Fred Bricon reassigned JBIDE-21843:
-----------------------------------
Assignee: Rob Stryker
> CDK Poller always fails on OSX
> ------------------------------
>
> Key: JBIDE-21843
> URL: https://issues.jboss.org/browse/JBIDE-21843
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk
> Affects Versions: 4.3.1.CR1
> Environment: OSX
> Reporter: Fred Bricon
> Assignee: Rob Stryker
> Priority: Critical
>
> Starting the CDK on OSX always fails. Whether it was already started from CLI or not.
> The vagrant up command is properly executed, you can see the output in the console, but it ends up with a message "Server CDK Server Adapter at localhost failed to start."
> {noformat}
> VagrantPoller.parseOutput(String[]) line: 220
> VagrantPoller.onePing(IServer, String) line: 160
> VagrantPoller.onePing(IServer) line: 138
> VagrantPoller.getCurrentStateSynchronous(IServer) line: 114
> CDKLaunchController$2.run() line: 222
> {noformat}
> In parseOutput, the value of lines is :
> [1457536005,,error-exit,Vagrant::Errors::ProviderNotUsable,The provider 'virtualbox' that was requested to back the machine\n'cdk' is reporting that it isn't usable on this system. The\nreason is shown below:\n\nVagrant could not detect VirtualBox! Make sure VirtualBox is properly installed.\nVagrant uses the `VBoxManage` binary that ships with VirtualBox%!(VAGRANT_COMMA) and requires\nthis to be available on the PATH. If VirtualBox is installed%!(VAGRANT_COMMA) please find the\n`VBoxManage` binary and add it to the PATH environmental variable.]
> this is not properly parsed as it later goes into this block
> {code}
> Collection<VagrantStatus> stats = status.values();
> if( stats.size() == 0 ) {
> return IStatus.ERROR;
> }
> {code}
> And the message in the lines is lost completely
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month