Fabric profile: version name not used after version export/import

[alstsever_alain.saint-sever]

Hi,

Another weird thing I just noticed (along with bugs described here https://fusesource.com/forums/thread.jspa?threadID=4591&tstart=0):

From FMC 7.1.0:

1- create a new version, say 1.0-test

2- export 1.0-test version: a file named 1.0-test-export.zip is created containing all the profiles

3- delete version 1.0-test

4- import version from file 1.0-test-export.zip

==> FMC creates version 1.1 while we should expect 1.0-test

The name we gave to the exported version is not used.

Is it the expected behavior (I don't think since we can name a version)?

Thanks

[alstsever_alain.saint-sever]

Hi again,

In fact the situation is worse: when exporting and reimporting a version it appears some files get corrupted or truncated (e.g.: broker.xml in mq-base profile).

Just try exporting/importing again and again the same version and you will notice that (focus on content of broker.xml in mq-base profile to see the issue).

Cannot use the import/export feature for production until all those issues get fixed.

Regards,

[davsclaus]

Hi

I have logged a ticket to have us look into this

http://fusesource.com/issues/browse/FMC-443

Btw what OS are you using?

[alstsever_alain.saint-sever]

Thanks Claus.

My OS is Windows XP SP3. I reproduced the issue using FMC 7.1.0 + Fuse ESB Enterprise 7.1.0 (latest release) on both Google Chrome and Firefox.

Regards,

[stlewis]

The import operation always creates a new version in fabric so as not to overwrite and potentially wreck an existing version, so it's by design, though it does differ from profile import which does let you overwrite an existing version.  Will have to look into the broker XML import though...

[alstsever_alain.saint-sever]

Hi Stan,

Ok but then why do you let the user set a custom name when creating a new version? If I export version xyz I want to have this version named xyz when I import it later (use case: when I reinstall a fabric from scratch. I don't think my customer will recreate by hand a version: he will just import it from an archive we give him. And we want that version to have a given name). If there is a conflict it should be up to the FMC/Fabric to warn the user.

This is very disturbing. If you say that it is by design then I would have prefered that you also force the version name when we create a new version. Other solution: let the user enter a name when he imports a version.

As for the broker XML import: it happens on other files too but it is easier to see the issue on this one. Thanks for looking into this.

Last but not least: when you export a version you'll notice that profiles fabric-ensemble-0000 and fabric-ensemble-0000-1 are exported but their hidden attributes are lost (same issue as with abstract attribute).

Regards,

[stlewis]

Good idea about naming the imported version, think that'd be a good solution to this.

The original idea was that you could import version data without affecting running containers, i.e. you could import a version from another system, tweak profile values as needed and then migrate containers to the newly imported version.

[alstsever_alain.saint-sever]

I understand. My use case is different since we intend to deliver our fabric versions (and updates) as archives and I would like to have the name imported into the Fabric (also it is much easier to dynamically update strings like 'zk\:/fabric/configs/versions/myVersion/profiles/awms-is-parent/mybroker.xml' since you know what the version name 'myVersion' will be! This way we can use some variable in POM and make use of maven filtering capability to generate our fabric version archive).

But if we can name the imported version then it looks fine to me.

[stlewis]

Cool!  I created this issue to track it separately from the data corruption issue, I'll look at it after I sort the missing attributes issue.

[alstsever_alain.saint-sever]

Hi Stan,

I just saw that issue FMC-443 has been fixed. Did you manage to reproduce the file corruption/truncating problem and fix it? If so this is great.

As of today this is really a big showstopper since every time I import my customized fabric version I have to check every files and fix 3 or 4 of them by hand.

[stlewis]

Yup!  Was able to reproduce it without a problem, stinks I didn't catch that when initially implementing it.  So fixed that (tested it a few times even just now to be sure , as well as the issue with attributes and then implemented the extra text field so you can specify a target version name, if the version exists it'll get overlaid with the imported version.

[alstsever_alain.saint-sever]

Ok. Glad to hear that.

And what about the strange fabric-ensemble-XXX profiles? Is this "normal" to get them when you export a version (since they have the 'hidden' attribute this leads me to think that they are some kind of internal profiles we don't have to deal with)?

And I wonder if it could be dangerous to import them on another fabric since they contains some specific configuration data (zookeeper data directory, port...). I fear we could mess up the fabric when migrating a container to the imported version because of these fabric-ensemble-XXX profiles. But maybe I am wrong.