Correct steps to create an FMC container now it's a feature in FF 7.1?

[komododave]

Our Fabric must be configured to use Nexus repo proxies to access feature repos.

Because of this we can't create a fabric ensemble node with the 'fmc' profile since it won't be provisioned.

Therefore I used the following steps to first create an ensemble node then create a child container for it with the 'fmc' profile applied:

fabric:create --clean --new-user ouradmin --new-user-role admin --new-user-password ourpass --zookeeper-password ourzkpass

fabric:profile-edit --pid org.fusesource.fabric.agent/patch.repositories=http://maven/nexus/content/groups/ours default

fabric:profile-edit --pid org.fusesource.fabric.agent/org.ops4j.pax.url.mvn.repositories=http://maven/nexus/content/groups/ours default

fabric:profile-edit --pid org.fusesource.fabric.maven/remoteRepositories=http://maven/nexus/content/groups/ours fabric

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

These commands execute successfully, and the child 'fmc-root' is successfully provisioned.

However, FMC is not available on http://ensemble-host:8181

I realise it's possible to add the 'fmc' profile to the root ensemble node after its creation. However, Stan Lewis pointed out in  this post that the 'fmc' profile should be applied at time of container creation to remove the necessity to refresh the PAX MVN bundle.

If someone could answer the following questions, it might clear up what limitations exist now that FMC is a feature:

1. Why doesn't the setup described here work? Is it because the 'fmc' child container must be passed the JMX user and password of the parent container at time of creation? If so where are these defined by default, and how can they be modified?

2. Are there limitations beyond those outlined here when using Maven proxies regarding FMC setup, and if so could you describe what configuration steps certainly will work for FMC?

The sort of response you might give to is "FMC will work with Nexus proxies if you either add the 'fmc' profile to an ensemble container then refresh the PAX MVN bundle, or (ii) add the 'fmc' profile to another root container.

I'm wary of (ii) though since  another post by Stan Lewis highlights that fabric:join is broken in RC 041. However I'm about to try RC 047 which is expected to be the GA release.

[komododave]

I'm pleased to say that the following worked:

• Create a fabric

• Customise maven proxies as above

• Edit this ensemble container to add profile 'fmc'

• Refresh the PAX MVN bundle

• Create custom profiles by extending 'karaf' not 'default'.

The last point was mentioned by Stan Lewis in another thread of mine yesterday.

I'd still be grateful for a response to the above questions.

[stlewis]

Yeah, the FMC wars are actually now embedded into the fuse-fabric distro in 7.1, so it should be possible to install FMC when first creating the fabric without any customization.

This is also the case BTW for the Fuse ESB and Fuse MQ distros with the exception of the Fuse ESB minimal assembly, that last one excludes the FMC wars.  So from any of our distros it's now possible to install FMC, kinda making joining a new FMC container to an existing fabric a little less necessary.

[komododave]

That's good to hear Stan, thank you for this information. I'll modify our command to set profile 'fmc' when trialing the latest RC 047. Very convenient that it's now bundled!

[komododave]

Stan - just to let you know, I tried creating a fabric in RC 047 with the 'fmc' profile applied before our Nexus proxies were configured and it failed, see below.

It looks like this still won't work out of the box without an http connection unless you add 'fabric-commands' and any other missing 'fmc' dependencies into the tarball.

root                          1.0       true    fabric, fabric-ensemble-0000-1, fmc error - java.lang.IllegalArgumentException: Unable to find feature fabric-commands*

[komododave]

Even worse - this error occurs after running `fabric:create` without the `fmc` profile being specified!

I would consider this a bug in RC 047, since anyone requiring a maven proxy to be configured i.e. with no net access on their target host will encounter the issue.

Guess we'll have to go back to RC 041 for now, I know that worked fine.

EDIT: Ok I'm officially confused. Exactly the same issues arises with RC 041 now, yet it worked fine yesterday. (o_O). Must be some problem with changes in how we're deploying fabric, very weird though. I can in fact see that the fabric-commands-VERSION.jar is present under system/ within the fabric installation root. The user and group of the filesystem is the same as yesterday, and we're executing the `fusefabric` script from the same directory. Any ideas what might cause this problem?

[komododave]

Ah, I know why this error arises.

I created some profiles yesterday that reference features not bundled with the tarball.

The fabric:create command we're running now imports these, but of course the dependency features can't be found.

That would make sense!

[stlewis]

I was going to check and see which distro you're using.  If you're running offline initially you might want to use the Fuse ESB full distro, it has fabric in it and more importantly it has all the dependent artifacts for all the features repositories that ship in the ESB.  Or for a slightly smaller download the Fuse ESB medium build has a good hunk of fabric but omits a lot of lesser used features.

Note that no matter what when fabric provisions new remote containers it still uses it's own fuse-fabric distro.

[komododave]

Thanks for this information Stan, it's useful to know.

It seems odd that the error mentioned 'fabric-commands' when that bundle clearly existed on the system.

We're now running RC 047 successfully - removing the profile import parameter from fabric:create did indeed resolve the problem. But I wonder why 'fabric-commands' was listed as absent when in fact that existed and some other feature dependency must have been absent.

[stlewis]

My guess would be the fabric-features.xml wasn't configured correctly in the profile, as I believe that's one of the first features fabric tries to install, i.e. an "unable to find feature" error message tells us that the provisioning agent actually can't find the feature definition.  If there was an issue with how the fabric-commands feature was defined in the XML, i.e. it contained a non-existant bundle or dependent feature then the error message is quite different, usually using the Karaf "MultiException" exception type.

Not sure though, I guess it's a matter of diff'ing what you had changed and try and spot any errors.

[komododave]

I'll shortly post a new thread relating to this issue, describing a scenario which should work yet doesn't creating the same error.