SQL Plugin 1.1.0 fail to load databases on startup

[Kagome]

Hello,

i updates Vcenter Server + orchestrator from 5.5 to 5.51.

Nearly all is working now fine but i have a single bug.

The SQL Plugin 1.1.0 gives me an error in the client when i want to expand the Databases.

If I add new Databases and add the new databases to workflows - it is working until i restart the Orchestrator Server service.

The Error is:

2014-06-05 23:45:52.170+0200 [http-bio-10.77.1.31-8281-exec-1] ERROR {} [VcoDelegatingWebFacade] Server Error...

ch.dunes.model.sdk.SDKFinderException: Unable to execute 'fetchRelation' for type : RootFinder : com.vmware.o11n.plugin.database.DatabaseException: Table content_field_vmhost is not found in database.

    at ch.dunes.vso.sdk.SDKFinder.logAndThrow(SDKFinder.java:858)

    at ch.dunes.vso.sdk.SDKFinder.fetchRelation(SDKFinder.java:342)

    at ch.dunes.vso.sdk.SDKFinder._findRelation(SDKFinder.java:306)

    at ch.dunes.vso.sdk.SDKFinder.findRelation(SDKFinder.java:224)

    at ch.dunes.vso.sdk.ModulesFactory.findRelation(ModulesFactory.java:521)

    at com.vmware.o11n.sdk.EnhancedScriptingSDK.findRelation(EnhancedScriptingSDK.java:99)

    at com.vmware.o11n.service.sdk.SdkModuleServiceImpl.findRelation(SdkModuleServiceImpl.java:57)

    at com.vmware.o11n.service.factory.VcoFactoryFacade.findRelation(VcoFactoryFacade.java:1633)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

    at java.lang.reflect.Method.invoke(Unknown Source)

    at com.vmware.o11n.service.security.AccessRightsInterceptor.invoke(AccessRightsInterceptor.java:92)

    at com.vmware.o11n.service.security.AccessRightsInterceptor.invoke(AccessRightsInterceptor.java:83)

    at com.vmware.o11n.service.webremoting.VcoDelegatingWebFacade.invokeOperation(VcoDelegatingWebFacade.java:106)

    at com.vmware.o11n.integration.initialization.VcoFactoryServiceFacadeProxy.invokeOperation(VcoFactoryServiceFacadeProxy.java:86)

    at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

    at java.lang.reflect.Method.invoke(Unknown Source)

    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319)

    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:196)

    at com.sun.proxy.$Proxy105.invokeOperation(Unknown Source)

    at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

    at java.lang.reflect.Method.invoke(Unknown Source)

    at org.springframework.remoting.support.RemoteInvocation.invoke(RemoteInvocation.java:205)

    at org.springframework.remoting.support.DefaultRemoteInvocationExecutor.invoke(DefaultRemoteInvocationExecutor.java:38)

    at org.springframework.remoting.support.RemoteInvocationBasedExporter.invoke(RemoteInvocationBasedExporter.java:78)

    at org.springframework.remoting.support.RemoteInvocationBasedExporter.invokeAndCreateResult(RemoteInvocationBasedExporter.java:114)

    at org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter.handleRequest(HttpInvokerServiceExporter.java:73)

    at org.springframework.web.context.support.HttpRequestHandlerServlet.service(HttpRequestHandlerServlet.java:67)

    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)

    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)

    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

    at net.sf.ehcache.constructs.web.filter.GzipFilter.doFilter(GzipFilter.java:95)

    at net.sf.ehcache.constructs.web.filter.Filter.doFilter(Filter.java:86)

    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)

    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)

    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)

    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)

    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)

    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)

    at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:680)

    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)

    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)

    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)

    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)

    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)

    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)

    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

    at java.lang.Thread.run(Unknown Source)

Caused by: java.lang.reflect.InvocationTargetException

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

    at java.lang.reflect.Method.invoke(Unknown Source)

    at ch.dunes.vso.sdk.DirectInvoker.invoke(DirectInvoker.java:55)

    at ch.dunes.vso.sdk.SDKDatasourceInvoker.fetchRelation(SDKDatasourceInvoker.java:67)

    at ch.dunes.vso.sdk.SDKFinder.fetchRelation(SDKFinder.java:332)

    ... 51 more

Caused by: com.vmware.o11n.plugin.database.DatabaseException: Table content_field_vmhost is not found in database.

    at com.vmware.o11n.plugin.database.Database.addTables(Database.java:181)

    at com.vmware.o11n.plugin.database.configuration.DataBaseConfigPersister.getDatabaseFrom(DataBaseConfigPersister.java:140)

    at com.vmware.o11n.plugin.database.configuration.DataBaseConfigPersister.getAll(DataBaseConfigPersister.java:82)

    at com.vmware.o11n.plugin.database.configuration.ConfigurationServiceImpl.reload(ConfigurationServiceImpl.java:67)

    at com.vmware.o11n.plugin.database.configuration.ConfigurationServiceImpl.getAll(ConfigurationServiceImpl.java:124)

    at com.vmware.o11n.plugin.database.model.DatabaseManager.getDatabases(DatabaseManager.java:415)

    at com.vmware.o11n.plugin.database.DatabasePluginFactory.findRelation(DatabasePluginFactory.java:150)

    ... 58 more

OK .. as i can read: a table in database seems to be missing.

Questions:

1) how can I reinstall the SQL Plugin 1.1.0 and maybe recreate the database?

2) I don't know why .. but I set the Orchestrator to use the vDB Database in the past while installation instead of a MS SQL Database...so there is no backup.

How can I access the vDB? I have a second, working  Orchestrator Server where I could copy the damaged table structure to the damaged Server.

3) IF i change now from vDB to MS SQL Database .. I'm right that all my Workflows are lost?

Thanks for help in advantage.

[Kagome]

I 'fixed' that issue by the following steps:

- create a package in the orchestrator Client with all Workflows, Actions, resources, ...)

- Export that packages

- document schudle Workflows (paramtertes, time and so on)

- document how you Setup AD-Connection, SQL Connection for the workflows

- Change in Orchestrator webkonfiguration the database (and konfigure it)

- press under 'troublshooting' in the webkonfiguration to reinstall all plugins

- restart orchestrator service

- Import the package in the 'new' orchestrator

- create the SQL Databases for my Workflows again

- add the schedudle Workflows again (Feature request:. a automated way to Export / Import scheduled Workflows)

- finish

What I dislike ....

after checking the new database there was still no Table content_field_vmhost .. and there it made 'click' in my head.

That was one of a old, since months deleted  table of one MySQL Connection i stored in the SQL-Ressources...

Can maybe someone confirm this as a bug:

- create a mysql Database on a serer

- add some tables with content to that database

- add that database to the Orchestrator SQL Ressources

- delete a table in the MySQL database with any Database-Tool ( i used MySQl Query Browser)

- upgrade Orchestrator and vCenter from 5.5 to 5.5.1

- check if there is an error if you try to expand the SQL Ressources in the Orchestrator Client.

[igaydajiev]

>Can maybe someone confirm this as a bug:

>- create a mysql Database on a serer

>- add some tables with content to that database

>- add that database to the Orchestrator SQL Ressources

>- delete a table in the MySQL database with any Database-Tool ( i used MySQl Query Browser)

>- upgrade Orchestrator and vCenter from 5.5 to 5.5.1

>- check if there is an error if you try to expand the SQL Ressources in the Orchestrator Client.

If I understand it correctly after the last step when vCO is restarted SQL plugin for vCenter Orchestrator has a configuration pointing toward database that is deleted and does not exist ant the moment of server restart?

[Kagome]

Hello,

the database is present. only one table (content_field_vmhost) in that database got deleted months ago.

I restarted in the past the vCenter Orchestrator Service 5.5.0 (Windows, build in with vCenter Server) a lots of time before I upgraded to 5.5.1. With Version 5.5.0 was no Problem after restarting, only after the upgrade to 5.5.1 i run into the error.

Sems to be that the database Content is somewhere (outdated) cached.

[igaydajiev]

We were able to reproduce similar behavior and will provide fix in the next plugin release.

Here are the steps we have used to reproduce the issue with plugin version 1.1.0

1. Run workflow "Add database"

2. Remove table from SQL server

3. Restart vCO server and there is error while loading plugin configuration. Inventory also get corupted.

To avoid this error :

1. You can run "Update a database"  workflow after the table has been deleted and prior to restart vCO server.

OR

2. You can run "Remove a table from a database"  workflow to remove table form plugin inventory. And after that delete it physically from the SQL server.

In current state of your environment you can try to temporary create a table with the same name as deleted one.

Restart vCO server.

Rung "Remove a table from database"

Delete table from SQL server.

Hope it helps...

[thakala]

Is there any planned schedule when new SQL plugin might be released?

[SeanKohler]

>> Is there any planned schedule when new SQL plugin might be released?

+1

Also would like to know this answer...

[igaydajiev]

vCO 5.5.2 ships with SQL plugin 1.1.1