Can't delete target from web console

[gibello]

No error on the javascript console, but exception in the karaf.log:

2017-01-03 15:15:46,846 | DEBUG | qtp217867603-358 | TargetResource                   | 32 - net.roboconf.roboconf-dm-rest-services - 0.8.0.SNAPSHOT | Request: get details about target occi-CA.
2017-01-03 15:15:46,873 | DEBUG | qtp217867603-359 | PreferencesResource              | 32 - net.roboconf.roboconf-dm-rest-services - 0.8.0.SNAPSHOT | Request: get the preferences for key = web.extensions.
2017-01-03 15:15:46,891 | DEBUG | qtp217867603-356 | TargetResource                   | 32 - net.roboconf.roboconf-dm-rest-services - 0.8.0.SNAPSHOT | Request: list usage statistics for target occi-CA.
2017-01-03 15:15:49,783 | DEBUG | qtp217867603-357 | TargetResource                   | 32 - net.roboconf.roboconf-dm-rest-services - 0.8.0.SNAPSHOT | Request: delete target occi-CA.
2017-01-03 15:15:49,785 | ERROR | qtp217867603-357 | TargetResource                   | 32 - net.roboconf.roboconf-dm-rest-services - 0.8.0.SNAPSHOT | Deletion is not permitted.
2017-01-03 15:15:49,788 | TRACE | qtp217867603-357 | TargetResource                   | 23 - net.roboconf.core - 0.8.0.SNAPSHOT | net.roboconf.dm.management.exceptions.UnauthorizedActionException: Deletion is not permitted.
    at net.roboconf.dm.internal.api.impl.TargetsMngrImpl.deleteTarget(TargetsMngrImpl.java:245)
    at net.roboconf.dm.rest.services.internal.resources.impl.TargetResource.deleteTarget(TargetResource.java:202)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
    at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
    at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
    at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
    at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
    at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
    at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
    at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
    at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
    at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
    at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
    at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
    at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
    at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:558)
    at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:733)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
    at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
    at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:276)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
    at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
    at org.eclipse.jetty.server.Server.handle(Server.java:499)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
    at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
    at java.lang.Thread.run(Thread.java:745)

[vincent-zurczak]

The application and its template had all been deleted. Another target definition can successfully be deleted. And still the exception indicates the target is used. :confused:

I'll see whether I can reproduce this issue.

[vincent-zurczak]

I could not reproduce the problem. I have hypothetisis about what could happen, but it does not go beyond.

If it is possible...

• Stop your DM. Clear your logs.
• Start your DM and reproduce the problem.
• Then, send me...
  • ... the data/log/karaf.log file
  • ... the data/roboconf directory

Thanks. :+1:

[vincent-zurczak]

After verifications, here is what happens.

• A scoped instance is associated with a target (let's call it CA).
• The VM is successfully created by the target handler.
• An entry is created in the usage.properties file of the target.

Then, at undeployment...

• The user clicks to undeploy the scoped instance.
• An exception is thrown by the target handler when undeploying.
• The entry in the association file is therefore not removed.

To by-pass the lack of secured undeployment, the DM was restarted and statuses were updated by hand. The application and the template can be deleted. The target is not associated with any instance or application. BUT, the usage.properties file still contains items.

So, there are 2 problems in fact:

• First, the web administration should verify both the associations and both the usage items when searching whether a target can be deleted or not.
• Second, there can be an inconsistency between the associations.properties and the usage.properties files. When the DM restarts, scoped instances that are not deployed (after restoration) should be removed from the usage.properties file.

[vincent-zurczak]

We should also release all locks related to an application when we delete it.

[vincent-zurczak]

There is no error in the web admin. We really checked the usage statistics. But we could not reference an application that had been deleted. So, basically, releasing the lock when we delete an application, and checking the locks when we restore applications, is enough.