fabric8io / fabric8 Goto Github PK

Needed to create a fabric from hawtio.

I'm trying to build fabric but am getting:

[ERROR] Failed to execute goal on project fabric-camel-c24io: Could not resolve dependencies for project org.fusesource.fabric:fabric-camel-c24io:jar:1.1-SNAPSHOT: Could not find artifact biz.c24.io:c24-io-api:jar:4.0.1 in Nexus
(http://XXXXXXX/nexus/content/groups/public) -> [Help 1]

Could you add the repo to the pom or just reply stating a public repo I can add as proxy to our nexus (or tell me there's something standard missing from our nexus setup).

thanks.

I tried to make openshift cardrige work with openshift with hudson-enabled.
First, we've to update the deploy file to point on the new fabric snapshot: fuse-fabric-99-master-20130411.214420-284.tar.gz

In a second time, this lead to exceptions due to some access restrictions on the build:

Started by user Jenkins System Builder
Building remotely on osgobldr in workspace diy-0.1/ci/jenkins/workspace/osgo-build
Checkout:osgo-build / diy-0.1/ci/jenkins/workspace/osgo-build - hudson.remoting.Channel@1624d4d:osgobldr
Using strategy: Default
Last Built Revision: Revision 71cb8f1c96e33bd6338f252f63b5f2422bc26213 (origin/HEAD, origin/master)
Checkout:osgo-build / diy-0.1/ci/jenkins/workspace/osgo-build - hudson.remoting.LocalChannel@1c94782
Fetching changes from 1 remote Git repository
Fetching upstream changes from ssh://[email protected]/~/git/osgo.git/
Seen branch in repository origin/HEAD
Seen branch in repository origin/master
Commencing build of Revision 2bf64d0c922b62300200491518bf1fcf7e47f0d9 (origin/HEAD, origin/master)
Checking out Revision 2bf64d0c922b62300200491518bf1fcf7e47f0d9 (origin/HEAD, origin/master)
Warning : There are multiple branch changesets here
[osgo-build] $ /bin/sh -xe /tmp/hudson3360923740378159305.sh

• alias 'rsync=rsync --delete-after -az -e '''/usr/libexec/openshift/cartridges/jenkins-1.4/info/bin/git_ssh_wrapper.sh''''

• . ci_build.sh
  ++ set +x
  Running .openshift/action_hooks/pre_build
  Running .openshift/action_hooks/build

• /usr/libexec/openshift/cartridges/jenkins-1.4/info/bin/git_ssh_wrapper.sh [email protected] 'ctl_all stop'

  You are accessing a service that is for use only by authorized users.
  If you do not have authorization, discontinue use at once.
  Any use of the services is subject to the applicable terms of the
  agreement which can be found at:
  https://openshift.redhat.com/app/legal

  Welcome to OpenShift shell

  This shell will assist you in managing OpenShift applications.

  !!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!
  Shell access is quite powerful and it is possible for you to
  accidentally damage your application. Proceed with care!
  If worse comes to worst, destroy your application with 'rhc app delete'
  and recreate it
  !!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!

  Type "help" for more info.

Stopping services
WARNING: This ssh terminal was started without a tty.
It is highly recommended to login with: ssh -t

• export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64
• JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64
• export PATH=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64/bin:/usr/libexec/openshift/cartridges/diy-0.1/info/bin/:/usr/libexec/openshift/cartridges/abstract-httpd/info/bin/:/usr/libexec/openshift/cartridges/abstract/info/bin/:/bin:/usr/bin:/sbin:/usr/sbin:/usr/libexec/openshift/cartridges/embedded/jenkins-client-1.4/info/bin/
• PATH=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64/bin:/usr/libexec/openshift/cartridges/diy-0.1/info/bin/:/usr/libexec/openshift/cartridges/abstract-httpd/info/bin/:/usr/libexec/openshift/cartridges/abstract/info/bin/:/bin:/usr/bin:/sbin:/usr/sbin:/usr/libexec/openshift/cartridges/embedded/jenkins-client-1.4/info/bin/
• cd /fabric
  /var/lib/openshift/51742da1e0b8cd9323000003/app-root/runtime/repo//.openshift/action_hooks/stop: line 6: cd: /fabric: No such file or directory
• bin/stop
  /var/lib/openshift/51742da1e0b8cd9323000003/app-root/runtime/repo//.openshift/action_hooks/stop: line 7: bin/stop: No such file or directory
• exit 0
  Done
• rsync --delete-after -az -e /usr/libexec/openshift/cartridges/jenkins-1.4/info/bin/git_ssh_wrapper.sh /var/lib/openshift/5174485a500446e738000281//diy-0.1/ci/jenkins/workspace/osgo-build/ '[email protected]:~/app-root/runtime/repo'
• /usr/libexec/openshift/cartridges/jenkins-1.4/info/bin/git_ssh_wrapper.sh [email protected] deploy.sh
  Running .openshift/action_hooks/deploy
• FUSEFABRIC=fuse-fabric-SNAPSHOT
• FUSEFABRIC_TARGET=fuse-fabric-99-master-SNAPSHOT
• TARBALL=fuse-fabric-SNAPSHOT.tar.gz
• TMPAREA=/upload
• '[' '!' -f /upload/fuse-fabric-SNAPSHOT.tar.gz ']'
  Create upload directory and download Fuse Fabric.
• echo 'Create upload directory and download Fuse Fabric.'
• mkdir /upload
  mkdir: cannot create directory `/upload': Permission denied
• wget -O /upload/fuse-fabric-SNAPSHOT.tar.gz http://repo.fusesource.com/nexus/content/repositories/snapshots/org/fusesource/fabric/fuse-fabric/99-master-SNAPSHOT/fuse-fabric-99-master-20130411.214420-284.tar.gz
  /upload/fuse-fabric-SNAPSHOT.tar.gz: No such file or directory
• cd /upload
  /var/lib/openshift/51742da1e0b8cd9323000003/app-root/runtime/repo/.openshift/action_hooks/deploy: line 18: cd: /upload: No such file or directory
• tar zxf fuse-fabric-SNAPSHOT.tar.gz
  tar (child): fuse-fabric-SNAPSHOT.tar.gz: Cannot open: No such file or directory
  tar (child): Error is not recoverable: exiting now
  tar: Child returned status 2
  tar: Error is not recoverable: exiting now
• mv fuse-fabric-99-master-SNAPSHOT fabric
  mv: cannot stat `fuse-fabric-99-master-SNAPSHOT': No such file or directory
• '[' '!' -d /fabric ']'
• mkdir /fabric
  mkdir: cannot create directory `/fabric': Permission denied
  Copy Fuse Fabric distro to the OPENSHIT RUNTIME DIR
• echo 'Copy Fuse Fabric distro to the OPENSHIT RUNTIME DIR'
• cp -rf /upload/fabric
  cp: missing destination file operand after /upload/fabric' Trycp --help' for more information.
• cp -rf /var/lib/openshift/51742da1e0b8cd9323000003/app-root/runtime/repo//diy/fabric
  cp: missing destination file operand after /var/lib/openshift/51742da1e0b8cd9323000003/app-root/runtime/repo//diy/fabric' Trycp --help' for more information.
  Clean log files.
• echo 'Clean log files.'
• cd /fabric
  /var/lib/openshift/51742da1e0b8cd9323000003/app-root/runtime/repo/.openshift/action_hooks/deploy: line 33: cd: /fabric: No such file or directory
• rm -rf logs
• ln -s logs
  ln: creating symbolic link `./logs': Permission denied
  Build step 'Execute shell' marked build as failure
  Archiving artifacts
  Finished: FAILURE

Can you update the doc, I don't know how to correct this issue (I will try to see how openshift work, but it may take some times...).

Regards,

Was seeing a bit of this earlier but wanted to do a bit of work on FMC and am finding it's taking about 2 minutes to list the profiles on the profile list page. This used to take less than a second.

2013-07-22 09:54:23,418 | ERROR | agent-1-thread-1 | DeploymentAgent | e.fabric.agent.DeploymentAgent$1 212 | 116 - org.fusesource.fabric.fabric-agent - 7.3.0.redhat-020 | Unable to update agent
org.osgi.service.resolver.ResolutionException: Unable to resolve dummy/0.0.0: missing requirement [dummy/0.0.0] osgi.identity; osgi.identity=fabric-maven-proxy; type=karaf.feature; version=0 [caused by: Unable to resolve fabric-maven-proxy/7.3.0.redhat-020: missing requirement [fabric-maven-proxy/7.3.0.redhat-020] karaf.feature; karaf.feature=http; version=2.3.0 [caused by: Unable to resolve http/2.3.0.redhat-610020: missing requirement [http/2.3.0.redhat-610020] karaf.feature; karaf.feature=pax-http; version=3.0.0 [caused by: Unable to resolve pax-http/3.0.1: missing requirement [pax-http/3.0.1] osgi.identity; osgi.identity=org.ops4j.pax.web.pax-web-jetty; type=osgi.bundle; version="[3.0.1,3.0.1]" [caused by: Unable to resolve org.ops4j.pax.web.pax-web-jetty/3.0.1: missing requirement [org.ops4j.pax.web.pax-web-jetty/3.0.1] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.ops4j.pax.swissbox.core)(version>=1.6.0)(!(version>=2.0.0)))" [caused by: Unable to resolve org.ops4j.pax.swissbox.core/1.6.0: missing requirement [org.ops4j.pax.swissbox.core/1.6.0] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2147483647.2147483647.2147483647)))"]]]]]
at org.apache.felix.resolver.Candidates.populateResource(Candidates.java:285)[116:org.fusesource.fabric.fabric-agent:7.3.0.redhat-020]
at org.apache.felix.resolver.Candidates.populate(Candidates.java:153)[116:org.fusesource.fabric.fabric-agent:7.3.0.redhat-020]
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:148)[116:org.fusesource.fabric.fabric-agent:7.3.0.redhat-020]
at org.fusesource.fabric.agent.DeploymentBuilder.resolve(DeploymentBuilder.java:199)[116:org.fusesource.fabric.fabric-agent:7.3.0.redhat-020]
at org.fusesource.fabric.agent.DeploymentAgent.doUpdate(DeploymentAgent.java:356)[116:org.fusesource.fabric.fabric-agent:7.3.0.redhat-020]
at org.fusesource.fabric.agent.DeploymentAgent$1.run(DeploymentAgent.java:209)[116:org.fusesource.fabric.fabric-agent:7.3.0.redhat-020]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_17]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]

It'd be awesome to support the concept of clustered Receipe's; e.g. "message bridge" is a simple example of a Receipe. Where its a simple camel route with a few parameters (e.g. in and out endpoint URI).

Then we have a JSON file for each 'receipe' instance with the various values required.

e.g. imagine if a profile's git repo looked like this...

profiles/
foo/
  receipes/
        1.json
        2.json
        ...
        N.json

where 1.json might look like

{ "inUri": 'activemq:foo.bar", "outUri": "mq:cheese" }

Now assuming we have some java code capable of dealing with each of the JSON files a profile container instance is given which is defined in the profile as usual in Fabric (e.g. a profile has a blueprint service for that or something).

What we need is a way to get Fabric to partition the N files across M instances of the profile given a replica factor of X (which defaults to 1).

e.g. if there are 10 files and 2 instances of a profile, then each profile is given 5 files each.

I'm wondering if this could work a little bit like the profile:uri type thing; so that there's a simple way to access a profiles 'files' (but each instance only sees the files its meant to use).

So I guess since there are multiple files, its maybe not a URL handler. (Though wackily for JSON or XML it could be a URL handler, as it could just return 1 document for all the matching files! :)

Under the covers we need a work sharing/stealing algorithm using ZK; kinda like the Ordasity stuff (though hopefully built on Curator for simplicity)
https://github.com/boundary/ordasity#building-stateful-clustered-services-on-the-jvm

We probably need some kind of API for folks consuming the files that looks something like...

public interface ReceipeAgent {
    void startRecipe(URL configFile);
    void stopRecipe(URL configFile);
}

Then for each JSON file a particular Profile instance should own, the fabric code would call startReceipe(...) for each file separately. Then as work is partitioned / rebalanced, the controller would call start/stop as required.

If an individual file is editted, then the controller would call stop then start so that the particular receipe gets restarted.

Hi

I have built the last HEAD version of fuse and created a fabric using the jboss-fuse-full distro.

When I try to create a child instance with profile mq the proces hangs while createing the instance. I create the instance using

fabric:container-create-child --profile mq root mq

I have 39690 mb free space on my drive. After I looked into logs I can see following entries

2013-04-08 21:39:48,177 | WARN | eMQ Broker: root | BrokerService | ? ? | 114 - org.apache.activemq.activemq-osgi - 5.8.0.redhat-60022 | Store limit is 102400 mb, whilst the data directory: /home/kso/Projects/apache/karaf/fuse/esb/jboss-fuse-full/target/jboss-fuse-99-master-SNAPSHOT/data/root/kahadb only has 39690 mb of usable space
2013-04-08 21:39:48,177 | ERROR | eMQ Broker: root | BrokerService | ? ? | 114 - org.apache.activemq.activemq-osgi - 5.8.0.redhat-60022 | Temporary Store limit is 51200 mb, whilst the temporary data directory: /home/kso/Projects/apache/karaf/fuse/esb/jboss-fuse-full/target/jboss-fuse-99-master-SNAPSHOT/data/root/root/tmp_storage only has 39690 mb of usable space

While the first entry is only a warning the second one is an exception. I think it causes the later problem with creating of the mq instance. I think, the second entry should be a warning too.

When I move the whole distro on a partition with more capacity I can create the mq instance.

The problem is known in ActiveMQ (http://activemq.2283324.n4.nabble.com/Error-on-ActiveMQ-Startup-td4661998.html). I create this issue to track the problem.

e.g. these directories get turned into files...

https://github.com/jboss-fuse/fuse/tree/master/fabric/fuse-fabric/src/main/resources/distro/fabric/import/fabric/configs/versions/1.0/profiles/example-dozer/schemas
https://github.com/jboss-fuse/fuse/tree/master/fabric/fuse-fabric/src/main/resources/distro/fabric/import/fabric/configs/versions/1.0/profiles/controller-jboss/jboss

the first one is the big show stopper mind you ;)

2013-06-06 08:12:32,413 | ERROR | NAPSHOT-thread-1 | tServiceReferenceRecipe$Listener | tServiceReferenceRecipe$Listener 546 | 9 - org.apache.aries.blueprint.core - 1.0.1.redhat-610001 | Error calling listener method public synchronized void org.fusesource.fabric.partition.TaskManagerFactory.unbindPolicy(org.osgi.framework.ServiceReference)
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_12-ea]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_12-ea]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_12-ea]
at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_12-ea]
at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.invokeMethods(AbstractServiceReferenceRecipe.java:543)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.unbind(AbstractServiceReferenceRecipe.java:537)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.unbind(AbstractServiceReferenceRecipe.java:440)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.updateListeners(AbstractServiceReferenceRecipe.java:420)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.ReferenceListRecipe.internalCreate(ReferenceListRecipe.java:75)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_12-ea]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_12-ea]
at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:667)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_12-ea]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_12-ea]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_12-ea]
at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610001]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)[:1.7.0_12-ea]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)[:1.7.0_12-ea]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_12-ea]
Caused by: java.lang.NullPointerException
at org.fusesource.fabric.partition.TaskManagerFactory.unbindPolicy(TaskManagerFactory.java:183)[121:org.fusesource.fabric.fabric-partition:99.0.0.master-SNAPSHOT]
... 26 more

We shouldn't have classes that are bound to specific fabric modules in the api:

i) We need to keep changes in the api as minimal as possible.
ii) Adding new ContainerProviders shouldn't require modifying the api.
iii) User should be able to implement own ContainerProviders.

The main challenge here is that those classes are serialized/deserialized to/from json and bytes and that is causing ClassLoading issues.

A possible solution would be to have each ContainerProvider advertise the supported otpions and metadata classes, so that they can be used for serialization/deserialization.

Be good if it was possible to update things like the stored username/password or JVM options that are in a container's metadata object via JMX so that it can be done from consoles.

Using -Dmaven.test.skip=true:

[INFO] Not compiling test sources
[INFO]
[INFO] >>> exec-maven-plugin:1.2.1:java (default) @ process-manager >>>
[INFO]
[INFO] <<< exec-maven-plugin:1.2.1:java (default) @ process-manager <<<
[INFO]
[INFO] --- exec-maven-plugin:1.2.1:java (default) @ process-manager ---
[WARNING]
java.lang.ClassNotFoundException: org.fusesource.process.manager.GenerateControllerKinds
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:285)
at java.lang.Thread.run(Thread.java:722)

I don't think this scala object is used anywhere in fabric-core, it only seems to be used in fabric-monitor. Would it make sense to just move this scala file into fabric-monitor? I think this would then let us remove the scala dependency from fabric-core.

it'd be great for other sibling projects (e.g. hawtio, FuseByExample and - more importantly - customer projects) if they could just include a single Fuse BOM for a fuse release and get all the versions of everything set as maven build properties that folks can then use in their builds - without having to inherit from the parent fuse-parent pom.xml

It'd be good if we could create a pure API module and move org.fusesource.fabric.api interfaces to there. For the IDE we'd like to decouple it's usage of fabric (think it directly creates a ZK client, connects it to the registry and creates an instance of FabricServiceImpl) and use jolokia/JMX to control fabrics.

2013-06-17 08:51:33,860 | INFO | agent-1-thread-1 | DeploymentAgent | rce.fabric.agent.DeploymentAgent 750 | 100 - org.fusesource.fabric.fabric-agent - 99.0.0.master-SNAPSHOT | org.springframework.context.support / 3.1.3.RELEASE
2013-06-17 08:51:33,861 | INFO | agent-1-thread-1 | DeploymentAgent | rce.fabric.agent.DeploymentAgent 762 | 100 - org.fusesource.fabric.fabric-agent - 99.0.0.master-SNAPSHOT | Done.
2013-06-17 08:51:33,896 | INFO | .fabric.server]) | ActiveMQServiceFactory | q.fabric.ActiveMQServiceFactory$ 56 | 116 - org.jboss.amq.mq-fabric - 99.0.0.master-SNAPSHOT | Broker broker1 is waiting to become the master
2013-06-17 08:51:33,903 | ERROR | .fabric.server]) | configadmin | ? ? | 5 - org.apache.felix.configadmin - 1.4.0.redhat-610003 | [org.osgi.service.cm.ManagedServiceFactory, id=495, bundle=116/mvn:org.jboss.amq/mq-fabric/99-master-SNAPSHOT]: Updating configuration org.fusesource.mq.fabric.server.3e17a2b0-5066-4761-8f68-9db12849aa1f caused a problem: Unable to parse ActiveMQ configuration: null
org.osgi.service.cm.ConfigurationException: null : Unable to parse ActiveMQ configuration: null
at org.fusesource.mq.fabric.ActiveMQServiceFactory.liftedTree1$1(ActiveMQServiceFactory.scala:437)[116:org.jboss.amq.mq-fabric:99.0.0.master-SNAPSHOT]
at org.fusesource.mq.fabric.ActiveMQServiceFactory.updated(ActiveMQServiceFactory.scala:433)[116:org.jboss.amq.mq-fabric:99.0.0.master-SNAPSHOT]
at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:88)[5:org.apache.felix.configadmin:1.4.0.redhat-610003]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1650)[5:org.apache.felix.configadmin:1.4.0.redhat-610003]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1593)[5:org.apache.felix.configadmin:1.4.0.redhat-610003]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[5:org.apache.felix.configadmin:1.4.0.redhat-610003]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]
Caused by: java.lang.NullPointerException
at org.fusesource.mq.fabric.ActiveMQServiceFactory$ClusteredConfiguration.(ActiveMQServiceFactory.scala:241)[116:org.jboss.amq.mq-fabric:99.0.0.master-SNAPSHOT]
at org.fusesource.mq.fabric.ActiveMQServiceFactory.liftedTree1$1(ActiveMQServiceFactory.scala:435)[116:org.jboss.amq.mq-fabric:99.0.0.master-SNAPSHOT]
... 6 more
2013-06-17 08:51:36,032 | INFO | hChildrenCache-0 | FabricConfigAdminBridge | figadmin.FabricConfigAdminBridge 106 | 98 - org.fusesource.fabric.fabric-configadmin - 99.0.0.master-SNAPSHOT | Updating configuration org.fusesource.fabric.agent

So ClusterServiceManager can be for just managing an existing cluster, and ClusterBootstrapManager would be used for initially creating a fabric, hopefully moving this to a separate class will avoid any odd lockups.

Have put in a patching UI in place in hawtio and just giving it a bit of a test, but am running into this exception from the patch service:

Caused by: org.fusesource.fabric.api.FabricException: Profile 'patch-jboss-fuse-6.0.0.redhat-024-p1' does not exist in version '1.1'.
        at org.fusesource.fabric.internal.VersionImpl.getProfile(VersionImpl.java:104)
        at org.fusesource.fabric.service.PatchServiceImpl.applyFinePatch(PatchServiceImpl.java:485)
        ... 58 more

The applyPatches JMX method basically works similar to FMC, it'll create a new version based on some version the user provides and patch it. But from the log it seems like the createVersion() call returns before the version is ready to be used, for example after getting the above exception in applyPatches I delete the newly created version because of the error. In the log I see a number of errors after this like:

013-06-27 16:32:52,487 | ERROR | hChildrenCache-0 | TreeCache                        | ramework.recipes.cache.TreeCache  585 | 51 - org.fusesource.fabric.fabric-zookeeper - 99.0.0.master-SNAPSHOT | 
org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /fabric/configs/versions/1.1/profiles/insight
        at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)[53:org.fusesource.fabric.fabric-linkedin-zookeeper:99.0.0.master-SNAPSHOT]
        at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)[53:org.fusesource.fabric.fabric-linkedin-zookeeper:99.0.0.master-SNAPSHOT]
        at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1566)[53:org.fusesource.fabric.fabric-linkedin-zookeeper:99.0.0.master-SNAPSHOT]

and another one:

2013-06-27 16:32:54,062 | INFO  | pool-89-thread-1 | Bridge                           | rce.fabric.git.zkbridge.Bridge$1  180 | 119 - org.fusesource.fabric.fabric-git-zkbridge - 99.0.0.master-SNAPSHOT | Unable to sync git / zookeeper: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /fabric/configs/versions/1.1/profiles/example-camel/org.fusesource.fabric.agent.properties

it's easy to reproduce, just build hawtio, fire up a fabric container and apply the hawtio profile, go to Fabric and then Patching and apply some patch to either the current version or a new version.

https://github.com/fusesource/fuse/raw/master/fabric/openshift/cartridge
is no longer a valid URL.
Where do I pull the content?
Thanks,

We currently have working cartridge for fabric registry and fabric client.
It would be awesome if we had a container provider that could be used to manage containers running inside openshift from shell & hawtio.

if you are trying to join a container to an existing fabric (fabric:join) and your container has a name already uses in the existing fabric ... you completly freezed your existing fabric.

Note : the default caontainer name is "root"

git clone https://github.com/jboss-fuse/fuse.git
mvn -e -Dmaven.test.skip clean install
...
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:java (default) on project process-manager: An exception occured while executing the Java class. org.fusesource.process.manager.GenerateControllerKinds -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:java (default) on project process-manager: An exception occured while executing the Java class. org.fusesource.process.manager.GenerateControllerKinds
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: An exception occured while executing the Java class. org.fusesource.process.manager.GenerateControllerKinds
at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:352)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.ClassNotFoundException: org.fusesource.process.manager.GenerateControllerKinds
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:285)

at java.lang.Thread.run(Thread.java:680)

since the git-zk bridge doesn't deal well with recursive directories; lets try a pure git implementation of the Profile configuration; which should work nicer when in disconnected/offline systems

run:

version-create

then profile-delete --version 1.1 a-mq

then do profile-list --version 1.1 and you get:

Error executing command: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /fabric/configs/versions/1.1/profiles/a-mq

also the profile appears to still show up in the JMX API.

This is related to commit 5c6d3ac, while you can use --user/--password to update the stored credentials in a container's metadata object it'd be better if we instead prompted for credentials if the command fails with an authentication failure.

It'd be great if we had a development mode for Karaf where the system directory in the distro is completely ignored & all jars are loaded directly from the local maven repo.

Then if you're working on, say, the fabric bootstrap stuff; you can just stop/start the fabric process whenever you rebuild, say, fabric-core. No need to rebuild the fuse-fabric distro each time

slightly wacky idea - but we've loads of useful profiles; and a profile is kinda a simple compose-able combination of bundles / features / config files / config admin values.

It'd be nice to be able to add/remove profiles - and change profile versions - and edit profiles - all from in a single stand alone container thats not using fabric.

Really we should encourage folks to just use fabric really ;) or remove barriers to possible adoption. e.g. why are not all stand alone containers a 'single node fabric'? e.g. could we have a stand alone - single node - flavour of the fabric agent; which has no ZK or joining - or commands for creating containers or whatnot - but allowed profiles to be used for everyone in all circumstances?

e.g. maybe we could make a FabricAgent implementation which basically didn't need ZK - had an in memory registry implementation in the root container - but still used a git repo to store history and configuration?

This object is really short-lived (only used in when performing a jaas:update) so it makes no point in caching stuff.

Moreover, caching is causing synchronization issues, so its better removed.

Some weeks ago you have updated the fabric-camel-cluster (34da681) to deploy it on FuseESB 7. Could you tag a version of the project which was deployable on vanilla Karaf or ServiceMix (before the changes were applied)?

Seeing this a lot in the log today after a fresh build:

2013-08-05 11:15:21,714 | ERROR | Timer-0 | GitFacade | io.hawt.git.GitFacade 859 | 120 - org.fusesource.fabric.fabric-git-hawtio - 99.0.0.master-SNAPSHOT | Failed to pull from the remote git repo with credentials org.eclipse.jgit.transport.UsernamePasswordCredentialsProvider@424a6ea6. Reason: org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during execution of fetch command
org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during execution of fetch command
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:143)[123:org.fusesource.fabric.fabric-git:99.0.0.master-SNAPSHOT]
at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:245)[123:org.fusesource.fabric.fabric-git:99.0.0.master-SNAPSHOT]
at io.hawt.git.GitFacade.doPull(GitFacade.java:854)[120:org.fusesource.fabric.fabric-git-hawtio:99.0.0.master-SNAPSHOT]
at io.hawt.git.GitFacade.gitOperation(GitFacade.java:911)[120:org.fusesource.fabric.fabric-git-hawtio:99.0.0.master-SNAPSHOT]
at io.hawt.git.GitFacade$2.run(GitFacade.java:111)[120:org.fusesource.fabric.fabric-git-hawtio:99.0.0.master-SNAPSHOT]
at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_25]
at java.util.TimerThread.run(Timer.java:505)[:1.7.0_25]
Caused by: org.eclipse.jgit.errors.NotSupportedException: URI not supported: http:///http://192.168.1.126:8181/git/fabric/
at org.eclipse.jgit.transport.Transport.open(Transport.java:556)[123:org.fusesource.fabric.fabric-git:99.0.0.master-SNAPSHOT]
at org.eclipse.jgit.transport.Transport.open(Transport.java:430)[123:org.fusesource.fabric.fabric-git:99.0.0.master-SNAPSHOT]
at org.eclipse.jgit.transport.Transport.open(Transport.java:314)[123:org.fusesource.fabric.fabric-git:99.0.0.master-SNAPSHOT]
at org.eclipse.jgit.transport.Transport.open(Transport.java:284)[123:org.fusesource.fabric.fabric-git:99.0.0.master-SNAPSHOT]
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:118)[123:org.fusesource.fabric.fabric-git:99.0.0.master-SNAPSHOT]
... 6 more

There's an extra slash in the http:// URI...

so then we'd be able to connect into the child tomcat/jetty/jboss process from the hawtio console for example :)

Just an FYI if you do:

version-create
version-delete 1.1

and then invoke the 'versions()' JMX operation you'll get a zookeeper exception that the 1.1 node doesn't exist, however if you do a version-list you'll see that 1.1 is still there...

e.g. something like

fabric:create --git http://github.com/acme/myrepo --newuser cheese

We've a boatload of stuff under fabric that kinda makes building the entire project take longer than it should. I think we should make the following changes:

Move fabric--facade to the "tooling" module
Move fmc- and fabric-rest to a separate "fmc" module

I think we can also take FMC out of the base fabric distro and just add it to the jboss-fuse distros, that's shave probably about 20MB off of the size of the distro.

I think the "openshift" module can go, isn't it superceded by jboss-fuse/openshift repo? Also fabric-security can go elsewhere that's just a POC integration with some SSO provider. Any other modules under fabric that can go away or be moved?

Could be a special case for this profile, but do:

profile-copy example-camel-fabric foobar

and then:

profile-display foobar

and there's no camel.xml or ReadME.md in the copied profile.

it'd be great if we could create child containers in a polymorphic way; where the profile maybe defines the container type (e.g. we detect the child container is really tomcat / jetty / jboss / whatever child process), but it appears from the CLI, web tooling and APIs like its a container - its just under the covers not using karaf but its a child process, not instance.

e.g. in hawtio it'd be great to create a child container, then pick a profile which is a tomcat based set of wars/shared libraries - and it just works; while under the covers the root container is adding a new controller of child processes etc.

Creating a Fabric container fails in -025 and -024 with the following exception:

2013-07-31 14:00:34,968 | WARN | admin-1-thread-1 | FabricConfigAdminBridge | figadmin.FabricConfigAdminBridge 156 | 107 - org.fusesource.fabric.fabric-configadmin - 7.3.0.redhat-025 | Exception when tracking configurations. This exception will be ignored.
org.fusesource.fabric.api.FabricException: org.fusesource.fabric.api.FabricException: org.fusesource.fabric.api.FabricException: java.lang.IllegalArgumentException: Path must not end with / character

Installation is empty, just unzip the ea-release and do:

fabric:create -r manualip -m localhost --new-user admin --new-user-password admin

[smx@biseinvp02 bin]$ uname -a
Linux biseinvp02 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
[smx@biseinvp02 bin]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
[smx@biseinvp02 bin]$ java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
[smx@biseinvp02 bin]$

Same happens with OpenJDK 1.7.0_25 in that machine.

Full karaf.log: https://gist.github.com/burmanm/6121159

added a new mbean that exposes the ZooKeeperClusterService, works great, however I cannot seem to get the fabric agent to start when using JMX to create a fabric.

You can reproduce this from either hawtio or jconsole, just go to the org.fusesource.fabric domain, look at the ClusterServiceManager operations and execute createCluster(java.util.List, java.util.Map), specify null for the first argument and {"username":"admin", "password":"admin", "role":"admin"} for the second argument.

Created a child container, had to stop/restart it to get it to deploy. In the log for the child container I'm seeing a lot of this message at INFO level:

Unable to sync git / zookeeper: java.lang.NullPointerException: null

e.g. all the core JDK helper functions from files should probably go into common-util?

Currently we assume that the port we bind to is the same with the port we advertise for each service.

In most cases this is correct, but in environments like Open shift, this is not true. We need to have a way to tackle this problem.