Pass additional volumes via flag to bpm run

[jamesjoshuahill]

The Platform Recovery team have explored using bpm run in BOSH Backup and Restore (BBR) scripts.

Part of the BBR contract is $BBR_ARTIFACT_DIRECTORY will be set, which is the location of the backup artifact for backup or restore.

This location must be mounted within the BPM container. Because it is only determined at backup or restore time, it is not possible to template it into the BOSH job at deployment time.

Currently the BBR CLI creates $BBR_ARTIFACT_DIRECTORY in the form: /var/vcap/store/bbr-backup/JOB_NAME. We would like to avoid the magic string /var/vcap/store/bbr-backup becoming encoded in bpm.yml config files across the many BOSH releases that support BBR. What do you think?

To avoid extending the BBR contract perhaps it would be possible for BPM to allow us to specify additional volumes as a flag to the bpm run command?

@cloudfoundry-incubator/bosh-backup-and-restore-team

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/159192566

The labels on this github issue will be updated when the story is started.

[jfmyers9]

@jamesjoshuahill This seems like a good suggestion. It also makes us more consistent with some of the other container CLI's.

The only thing I think we need to sort out before making this change is how to express the volume schema through this flag. For your use case, would you want to be able to configure things like allow_executions and writable when specifying volumes on the command line?

[jamesjoshuahill]

Hi @jfmyers9 that's good news.

We would like to be able to configurewritable so that BBR backup scripts can write to $BBR_ARTIFACT_DIRECTORY.

Also, we looked at mount_only and wondered how this would integrate with BBR. Currently, the BBR CLI creates $BBR_ARTIFACT_DIRECTORY as root before invoking BBR scripts. Would bpm run fail if an additional volume directory already exists? Would the command invoked by bpm run have permissions to read the additional volume directory? To avoid any change in the BBR contract we would like bpm run not to fail when the additional volume exists and chown it as required for the bpm run user.

We don't think that allow_executions would be required for $BBR_ARTIFACT_DIRECTORY. This looks like an acceptable resource limitation.

Many thanks
Josh and @aclevername

[xoebus]

What about something like -v path:allow_executions,mount_only?

[xoebus]

In the past we've talked about versioning the configuration so we can make backwards incompatible changes. These would be the first configuration outside configuration file and so we wouldn't be able version these.

[jamesjoshuahill]

The -v flag looks fine to our uneducated eyes; we don't have a strong opinion about the format.

[jfmyers9]

I think the format you proposed looks pretty good. If there are no other concerns, I can whip up a story and hopefully we can get this in a release soon.

[jfmyers9]

https://www.pivotaltracker.com/story/show/159472729

[glestaris]

thanks Jim