[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:
---------------------------------------
Linking a previous issue that was similar, but the culprit was vagrant-sshfs, now it's landrush: JBIDE-22882
> 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: Blocker
>
> 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-23010) landrush plugin prevents CDK server adapter from starting
by Martin Malina (JIRA)
Martin Malina created JBIDE-23010:
-------------------------------------
Summary: 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: Blocker
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-22959) Properties: rename Deployment to Replication Controller
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22959?page=com.atlassian.jira.plugi... ]
Jeff Cantrill commented on JBIDE-22959:
---------------------------------------
[~adietish] To my knowledge I don't know that we surface replica sets at the moment, but this leads to a design question we need to resolve. DeploymentConfigs are moving upstream and are (I think) being rebranded as Deployments. There will be a transitional period between OS dc and Kube deployments where the os kind will be more full featured. Aside from what we call it, we will need to figure out how to make the two co-exist in the ui; the console is or is planning to do that. It will be represented and identified differently (i believe) which means we will need to understand how to degrade functionality most likely
> Properties: rename Deployment to Replication Controller
> -------------------------------------------------------
>
> Key: JBIDE-22959
> URL: https://issues.jboss.org/browse/JBIDE-22959
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Marián Labuda
> Priority: Minor
> Labels: openshift_v3, properties
> Fix For: 4.4.x
>
>
> We should rename Deployment in tabbed properties to Replication Controller. I was complaining about it some times ago, but now I found also good reason to change it - underlying Kubernetes technology has Deployment resources and ReplicaSets (new generation of replication controller). And those resources are something a bit different although it has similar functionality. For users coming from Kubernetes world or those who are familiar with Kubernetes, could this be a bit misleading.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBTIS-182) Publish to ModeShape: Finish Button Disabled
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-182?page=com.atlassian.jira.plugin.... ]
Andrej Podhradsky closed JBTIS-182.
-----------------------------------
Verified with JBDS-IS 9.0.1.GA (Teiid Designer 10.0.1.Final-v20160713-1749-B16)
> Publish to ModeShape: Finish Button Disabled
> --------------------------------------------
>
> Key: JBTIS-182
> URL: https://issues.jboss.org/browse/JBTIS-182
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: modeshape
> Affects Versions: 4.0.0
> Environment: JBDS 7.0.0.GA, JBoss Tools 4.1.3.Beta3, EAP 6.1 (in DV 6.0.0)
> Reporter: Lucie Fabrikova
> Assignee: Dan Florian
> Fix For: 4.1.3.Final
>
> Attachments: modeshape.png
>
>
> If no publish area is created, it cannot be created in dialog "Publish to ModeShape", via rght-click Modeshape->Publish.
> 1. start EAP 6.1 server
> 2. create new Modeshape server (http://localhost:8080/modeshape-rest, admin/admin)
> 3. rght-click a project, Modeshape -> Publish
> 4. dialog "Publish to ModeShape" appears, with warning "A publish area must be selected. If there aren't any to choose from, you can create one here or in the ModeShape View"
> 5. click to add new Publish Area
> 6. button "Finish" is still disabled
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBTIS-59) structureRef being changed when BPMN2 model saved
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-59?page=com.atlassian.jira.plugin.s... ]
Andrej Podhradsky closed JBTIS-59.
----------------------------------
Closing this issue since it was fixed a long time ago.
> structureRef being changed when BPMN2 model saved
> -------------------------------------------------
>
> Key: JBTIS-59
> URL: https://issues.jboss.org/browse/JBTIS-59
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: BPMN2
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 4.0.0
>
> Attachments: QM2.zip
>
>
> The attached project contains a pre and post saved BPMN2 model. It appears that the structureRef on some ItemDefinition elements is being changed from a QName (e.g. ans0:policyQuoteReply) to a relative URI (../schema/policyQuote.xsd#/).
> This problem was previously occurring when the BPMN2 model had default namespace definitions on child elements, but this new 'before' model now has all explicit namespace declarations at the top level.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22677) rsync stuck on OSX
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22677?page=com.atlassian.jira.plugi... ]
Andre Dietisheim resolved JBIDE-22677.
--------------------------------------
Resolution: Duplicate Issue
> rsync stuck on OSX
> ------------------
>
> Key: JBIDE-22677
> URL: https://issues.jboss.org/browse/JBIDE-22677
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift, upstream
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Priority: Blocker
> Fix For: 4.4.1.AM3
>
>
> 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, 7 months
[JBoss JIRA] (JBIDE-22677) rsync stuck on OSX
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22677?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22677:
-------------------------------------
Fix Version/s: 4.4.1.AM3
(was: 4.4.x)
> rsync stuck on OSX
> ------------------
>
> Key: JBIDE-22677
> URL: https://issues.jboss.org/browse/JBIDE-22677
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift, upstream
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Priority: Blocker
> Fix For: 4.4.1.AM3
>
>
> 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, 7 months
[JBoss JIRA] (JBIDE-23005) Server Adapter: Stuck on creating/publishing
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23005?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-23005:
------------------------------------------
[~fbricon] ok, closing JBIDE-22677 as duplicate since we have a more complete strack here.
> Server Adapter: Stuck on creating/publishing
> --------------------------------------------
>
> Key: JBIDE-23005
> URL: https://issues.jboss.org/browse/JBIDE-23005
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Marián Labuda
> Assignee: Andre Dietisheim
> Labels: openshift_v3, server_adapter
> Fix For: 4.4.1.Final
>
> Attachments: stucked_server_adapter
>
>
> When I am trying to create a new OpenShift 3 server adapter, many times creation does not work. Server get stucked at publishing and there is a hanging job Check module status for server eap-app at OpenShift... I am using CDK OpenShift and build an application on eap 6.4 template with kitchensink context_dir. Connection is not established. While this is happening (job is hanging) there is no error in error log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months