The storage API could really use comprehensive set of drush commands that allow for creating/removing/modifying containers, and placing them in the appropriate classes, as well as doing the syncing process in full, or in part.
For this purpose I've done up a patch to add at least some of these commands to the storage API.
The commands that it adds are:
- storage-cron
- storage-sync-files
- storage-sync-migration
- storage-list-containers
- storage-list-classes
- storage-list-container-classes
- storage-create-container
- storage-modify-container
- storage-destroy-container
- storage-container-class
Using the help command for storage-create-container or storage-modify-container lists all the expected values for each of the defined storage services.
These are primarily the commands we use, and as such are missing the appropriate create class, destroy class, etc.
Comment | File | Size | Author |
---|---|---|---|
#5 | storage_api-full_set_of_drush_commands-2348597-5.patch | 948 bytes | Perignon |
storage-drush-commands.patch | 16.23 KB | rhys | |
Comments
Comment #1
Perignon CreditAttribution: Perignon commentedComment #3
Perignon CreditAttribution: Perignon commentedCommitted to Dev
Comment #4
scottrigby@rhys & @Perignon
The
storage-modify-container
drush command has an incorrect callback. It also needs to pass the$container
object. I'd re-roll the patch, but the earlier one was already committed (even though this issue status is Needs Review).I also can't submit it properly for some reason, because of this warning (I see #2002236: Add S3 container: "The difference between the request time and the current time is too large" but the recommendation didn't fix it):
Here's a quick diff. Can someone take a stab at this who has a matching server time in their dev environment? I don't want to cross issues, but just can't test this to be sure everything works properly.
Comment #5
Perignon CreditAttribution: Perignon commentedIn regards to the server time, make sure you are using NTP and that should fix it.
Attached is a patch file for use. I don't have a dev environment setup with a bucket that I can use at the moment so I cannot test this.
Comment #6
jonhattanPatch in #5 is fine.
I've found that `storage-create-container` command rely on the array returned by serviceSettingsDefault() to obtain the accepted options, but not all configuration settings have a default value, so they're missing in drush.
For example, in the case of S3, there's no way to configure `secret_access_key`.
How do you want to proceed? Add a key to serviceSettingsDefault() for each option or decouple drush from serviceSettingsDefault() and replicate all options within drush? I may write a patch in either direction you prefer.
Comment #7
Perignon CreditAttribution: Perignon commentedI honestly don't have much of a preference myself. I have not written any drush integrations to date so I am not really one to say one way or the other honestly.
Comment #8
scottrigby@jonhattan & @Perignon: I have written a command that allows this, and lets me get on with what I need to do. Also this is simplified, and bypasses some of the existing container validation (because, even though my values were correct, that validation was not passing).
Here's what I added in case it's helpful. Let's decide on a direction first, then I'm happy to roll a patch as needed:
Comment #9
Perignon CreditAttribution: Perignon commented