search

vmware-archive / cfops

This is simply an automation that is based on the supported way to back up Pivotal Cloud Foundry
http://www.cfops.io
Apache License 2.0
35 stars 24 forks source link

cfops restore succeeds but tile state does not change #104

Open cah-aaron-anderson opened 8 years ago

cah-aaron-anderson commented 8 years ago

When attempting to run cfops restore on the Elastic Runtime tile, the command completes successfully ("Tile action completed successfully"), but there is no state change in the elastic runtime tile.

cfops version v2.2.29 elastic runtime: 1.8.5-build.4

Output:

+ LOG_LEVEL=debug
+ cfops restore --adminuser <hidden> --adminpass <hidden> --opsmanageruser ubuntu --tile elastic-runtime --opsmanagerhost opsmanager.my.domain --destination .
2016/11/01 17:26:40 D1101 17:26:40.611057 10 init.go:38] not loading plugins:  open ./plugins: no such file or directory []
2016/11/01 17:26:40 D1101 17:26:40.611405 10 createCliCommand.go:80] checking registry for 'elastic-runtime' tile
2016/11/01 17:26:40 D1101 17:26:40.611454 10 createCliCommand.go:83] found tile in registry
2016/11/01 17:26:40 D1101 17:26:40.611517 10 createCliCommand.go:86] we have all required flags and a proper builder
2016/11/01 17:26:40 D1101 17:26:40.611663 10 remote_execute.go:26] using password for authn
2016/11/01 17:26:40 D1101 17:26:40.611718 10 opsmanager.go:76] Exporting url 'https://opsmanager.my.domain/api/installation_settings'
2016/11/01 17:26:40 D1101 17:26:40.61176 10 opsmanager.go:130] attempting to auth against https://opsmanager.my.domain/api/installation_settings
2016/11/01 17:26:40 D1101 17:26:40.611836 10 opsmanager.go:171] aquiring your token from:  https://opsmanager.my.domain/api/installation_settings https://opsmanager.my.domain/api/installation_settings
2016/11/01 17:26:40 D1101 17:26:40.830849 10 opsmanager.go:174] your token <token> https://opsmanager.my.domain/uaa
2016/11/01 17:26:41 D1101 17:26:41.736789 10 createCliCommand.go:69] Running restore for tile: {Tile:0xc820082ea0 Closer:0xc8200240e0}
2016/11/01 17:26:41 D1101 17:26:41.76017 10 elasticruntime.go:47] Retrieving All CC VMs
2016/11/01 17:26:41 D1101 17:26:41.768816 10 elasticruntime.go:77] Entering getAllCloudControllerVMs() function
2016/11/01 17:26:41 D1101 17:26:41.768903 10 elasticruntime.go:80] getAllCloudControllerVMs() function map[connectionURL:https://<hidden>:25555/deployments/cf-0a3fedce3213c5d66173/vms directorInfo:0xc820161080]
2016/11/01 17:26:41 D1101 17:26:41.768958 10 elasticruntime.go:85] Retrieving CC vms
2016/11/01 17:26:41 D1101 17:26:41.775135 10 elasticruntime.go:94] Unmarshalling CC vms
2016/11/01 17:26:41 D1101 17:26:41.775262 10 elasticruntime.go:55] Setting up CC jobs
2016/11/01 17:26:41 D1101 17:26:41.775312 10 elasticruntime.go:59] Running db action
2016/11/01 17:26:41 D1101 17:26:41.775374 10 elasticruntime.go:108] RunDbAction info: &{SystemInfo:{GetSet:{} systemInfo:map[] Product:cf Component:mysql Identifier:mysql_admin_credentials Ip:<hidden> User:<hidden> Pass:<hidden> VcapUser:<hidden> VcapPass:<hidden> SSHPrivateKey:<hidden> RemoteArchivePath:/var/vcap/store/mysql/archive.backup} Database:mysql}
2016/11/01 17:26:41 D1101 17:26:41.775935 10 mysqldump.go:26] setting up a new remote MyslDump object
2016/11/01 17:26:41 D1101 17:26:41.77598 10 remote_execute.go:32] using sslkey for authn
2016/11/01 17:26:41 D1101 17:26:41.777752 10 elasticruntime.go:130] Restoring %s mysql
2016/11/01 17:26:41 D1101 17:26:41.964021 10 remote_execute.go:32] using sslkey for authn
2016/11/01 17:26:42 D1101 17:26:42.507951 10 execute_list.go:12] /var/vcap/packages/mariadb/bin/mysql -u <hidden> -h localhost --password=<hidden> < /var/vcap/store/mysql/archive.backup
2016/11/01 17:26:46 D1101 17:26:46.932757 10 mysqldump.go:77] mysqldump restore called:  [/var/vcap/packages/mariadb/bin/mysql -u <hidden> -h localhost --password=<hidden> < /var/vcap/store/mysql/archive.backup] <nil>
2016/11/01 17:26:46 D1101 17:26:46.932815 10 mysqldump.go:53] mysqldump Import called:  <nil>
2016/11/01 17:26:46 D1101 17:26:46.932831 10 remote_execute.go:32] using sslkey for authn
2016/11/01 17:26:46 D1101 17:26:46.963898 10 file.go:25] Preparing to remove %s /var/vcap/store/mysql/archive.backup
2016/11/01 17:26:46 D1101 17:26:46.965146 10 file.go:27] Removing %s /var/vcap/store/mysql/archive.backup
2016/11/01 17:26:46 D1101 17:26:46.967469 10 mysqldump.go:61] mysqldump remove remote file called:  <nil>
2016/11/01 17:26:46 D1101 17:26:46.967565 10 elasticruntime.go:135] Done restoring %s mysql
2016/11/01 17:26:46 D1101 17:26:46.975449 10 createCliCommand.go:56] Tile action completed successfully
2016/11/01 17:26:46 D1101 17:26:46.975536 10 tempfilecloser.go:20] removing tmpfile:  /tmp/installation.json562593121

<nil> showing up in the logs leads me to believe it isn't using the mysql.backup I'm pointing to, but using any --destination other than where it's located (or attempting to retrieve from s3) errors out earlier, so I'm a little lost. I've tried both using both local and remote (s3) artifacts, but couldn't get restore working in any capacity. Both ways causes no state change in the Elastic Runtime tile, and I can't see anywhere in any logs that it did anything. Using the same credentials, cfops backup works like a charm.

I've verified cfops backup can push the artifacts to S3 (using S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY, S3_BUCKET_NAME, and setting S3_ACTIVE to true), but I couldn't confirm whether or not cfops restore supports pulling the artifacts from S3. It looks like it does, so long as the artifacts exist in the root of the S3 bucket, but wasn't able to verify. Does it?