Hi Gert,

You could have a look at the management server's log file. With debug enabled, you'll see the storage.Download command if someone registers an ISO:

2013-07-05 13:32:28,337 DEBUG http://agent.transport.Request] (TP-Processor19:null) Seq 26-1412817625: Sending { Cmd , MgmtId: 110514141114, via: 26, Ver: v1, Flags: 100011, {"**storage.DownloadCommand**":{"hvm":true,"description":"CentOS-6.4-x86_64-bin-DVD1","maxDownloadSizeInBytes":53687091200,"id":438,"resourceType":"TEMPLATE","url":"[http://XXXXXXXXXXXXXXXXX/CentOS-6.4-x86_64-bin-DVD1.iso","format":"ISO","accountId":2,"name":"XXXXXXXXXXXXXXXXXXXXXXXX","secUrl":"nfs://XXXXXXXXXXXXXXXXXX","wait":0}} }

Eventually you'll see storage.DownloadAnswer and within that same comment you should see "Download success, starting install".

2013-07-05 13:48:15,816 DEBUG [agent.transport.Request] (AgentManager-Handler-4:null) Seq 26-1412817733: Processing: { Ans: , MgmtId: 110514141114, via: 26, Ver: v1, Flags: 10, [{"*storage.DownloadAnswer*":{"jobId":"9539ecd9-08f7-4ea0-b338-ecbb6ea8c508","downloadPct":100,"errorString":"*Download success, starting install* ","downloadStatus":"DOWNLOAD_IN_PROGRESS","downloadPath":"/mnt/SecStorage/e6cf2aac-a6de-31fa-ae31-9f13ba7b121c/template/tmpl/2/438/dnld6761575145522601161tmp_","installPath":"template/tmpl//2/438//438-2-c91ffcea-d926-3810-9055-808f4a2de71b.iso","templateSize":0,"templatePhySicalSize":0,"checkSum":"0128cfc7c86072b13ee80dd013e0e5d7","result":false,"*details":"Download success, starting install* ","wait":0}}] }

Unfortunately it isn't clear to me what response signifies the successful installation of that ISO. I'm also unclear on how you would track any template operations. The only thing I can think of is for you to initiate those operations through the CloudPlatform GUI and track the related lines in your log file which signifies the start and end of those tasks (for your purpose, all the junk in between means nothing). In the future, just look for those start/end markers and you should be able to quickly determine if anything is going on.

"... when someone registers an ISO and the download starts"

Ok thanks,

Do you know how to clean up, if i stop the service while it is processing an iso or an template or it is
snapshotting ?

Kind regards
Gert

Interesting question. I'm still fairly new to CloudPlatform so I might be missing something but the following should be enough to get you started. The idea is to first try to remove the information from the CP gui, then to verify the cloud DB to see if the ISO/template is correctly marked as destroyed and finally to verify the file was removed from the storage:

First delete the template/ISO from CloudPlatform GUI. After that, you can have a look in your cloud DB at a table called template_host_ref. It'll give you a list of registered ISOs and templates, % complete of the download and some other relevant information. You'll want any ISOs listed in your "Template" Section of the CloudPlatform GUI to show 100 under the "download_pct" column unless you know the download is currently in progress. Check for the name of the ISO you just deleted. I did some tests and an ISO I uploaded earlier and then destroyed was no longer listed in the database although I have to admit I only looked in the DB an hour later. Based on one of the columns being named "destroyed", I strongly suspect the record of the deleted ISO/template will remain in the table for some time with a date under the "destroyed" column until some garbage collection process runs and deletes the record. Perhaps someone more familiar with the internals of CP can address this and clarify.

If you have to manually delete the above record, you'll notice there's a column called "local_path", which is the path where the file resides on your secondary storage. Make sure the file is deleted. Finally, still in the cloud DB in the template_host_ref table, there's a column called template_id. It you're going to manually make changes to the template_host_ref tables, you'll probably want to cross-reference the column name "template_id" against other tables and see if there are other records pointing to the now deleted template, as well as sneak a peak at other tables which start with the word "template" and see what they're about.

The above is mostly based on ISOs, I don't know much specifically about templates other than CloudPlatform's DB uses the same template_host_ref table to track them. HTH!

Erik

Hello Erikgo,

Thank you, I was thinking of another possible way, do you think the below will Work.

We are using a proxy server as described in the installation manual.

If i start by shutting that Down, wait maybe 10min, cloud platform must have some kind of garbage Collection,
so if sombody was doing somthing that did not finished cloud platform should clean it up it self..
?

- I was just thinking, i do not know if cloudplatform has a garbage collection.. ?

Kind regards
Gert

I think what you mean is shutting down the management server perhaps? The process which interacts with the web GUI through which the registration of an ISO or the creation of a template is initiated. I don't know if interrupting the process before completion would be sufficient to get CP to clean the database entries etc. What I do know is the database record for the deleted ISO/template should be deleted instantly. I did another test and checked the database right away and the record was gone. Like I said:

1. Check if the template/ISO is still listed in CloudPlatform gui. If so, attempt to delete.
2. Check the cloud DB, make sure the record isn't there anymore. If it is, make note of local_path and then delete the record
3. Delete the file on secondary storage found at local_path
4. Follow-up with other database cleanup re: template_id column and other tables which start with "template_"

Erik

To address your question more specifically:

"so if sombody was doing something that did not finished could platform should clean it up it self.."

I could be wrong on this but I don't believe the completion of the action is dependent on the end-user's browser staying connected and again, I'm also not sure CP would clean up records of a hard-failed operation (i.e.: if you were to shutdown the management server) automatically.

It's not clear to me if you're currently dealing with the situation or if you're asking for the sake of being prepared in case something happened. If it's the latter, perhaps it would be easier to prevent this non-sense sooner and avoid having to deal with database cleanups. If you know you have to bring your secondary storage down, send an announcement to everyone who has access and let them know not to perform such operations. If you're really desperate and you don't think you'll get cooperation from the end-users, you could setup an iptables ruleset on the management server to first allow "new and established connections" to port 8080 and then eventually when you're getting ready to take down the secondary storage something like 1hr before the maintenance replace "new and established" with "established" and all connected users will eventually timeout/no new connections will be allowed.

Erik

Don't forget to check for scheduled snapshots in CP GUI. Even if an iptables ruleset prevents users from connecting to CP GUI, the tasks will start and keep running until the management server is shutdown (i.e.: you might still interrupt an SSVM operation even though no users have been connected to the GUI for hours).

Hello Erikgo,

It is just to be prepared, but i think the solution with the iptables, is the best way to go.

We are getting ready to let app. 50 customers and some 200 users in to out cloudplatform,
but i still need to be able to do upgrades etc.

So for me the drain of new connections would Work great..

Thank you very much for takeing the time to anserw.

Kind regards
Gert

Quick correction above: I said "they tasks will start and keep running until the management server is shutdown" that came out wrong and isn't what I was thinking. What I meant was, if the scheduled snapshot starts and you shutdown the storage a task will be interrupted. While a request to create a snapshot I believe probably originates from the management server, I don't believe shutting down the management server would interrupt the task, as the actual task is directly handled by the SSVM.

Ok thanks.

I will test the snapshot thing in out testsystem

Kind regards
Gert