Open dave62 opened 5 years ago
Hi Dave,
I agree that the error logging probably need improving
You'll probably find that the error in the browser console (F12 on windows) is more informative - or at least may be useful for me. If you have a moment to recreate the issue then a copy of the browser console log would be really useful.
Any idea what it didn't like migrating?
Thanks for being the guinea pig and taking time to file an issue
Following up from an email with the logs...
TypeError: n.body is undefined\n[188]/p</e.prototype.getBinaryBlob
The migration tool can't get the binary for the application because the cockpit application (being built in) does not store its binary on cumulocity.
This shouldn't be a problem because the cockpit application is installed on all tenants and doesn't need to be migrated.
The logging however is a valid concern
Debugged the actual code - turns out in this case it was a custom cockpit and the binary was available this was a bug and is captured in a separate issue: #2
Changes to be made to logging:
As first "guinean pig" tester of this great solution to accelerate C8y assets/objects management across tenants, I encountered few hiccups during my first objects migration from an existing pilot tenant to my own PoC/internal tenant. Unfortunately the error message was very evasive as shown in the attached screenshot and no logging available to further debug the issue and trace down problematic object/migration step, forcing me to do a painful "try and error" migration approach almost object by object:![migration_tool_issue](https://user-images.githubusercontent.com/53825241/62544179-96a04300-b85f-11e9-89f1-20e33f5f0a55.png)
For more complex migrations involving multiple objects and dependencies it would greatly help to have some logging functionality wrapped around the web app itself, or maybe as part of a contained microservice app to subscribe in the tenant with status and log options (vs just a web app and like what we have for fieldbus etc for instance).