Mount propagation support for docker volume plugins running as BPM jobs about bpm-release

[cf-gitbot]

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

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

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

[xoebus]

mount("none", "path", NULL, MS_SHARED, NULL)

[julian-hj]

This is the original moby PR where that rootfsPropagation option was added. The discussion has better documentation than I've seen elsewhere.
moby/moby#15648

It does seem like all 3 options might be good to support. Some containers might just be consumers of new mounts, in which case they'd just need "slave" whereas others (like volume drivers) will be producers of new mounts in which case we need "shared".

[xoebus]

Some of this work has now been done on master (shared mounts but not rootfsPropagation). Does that help unblock any of these use cases or do you need both in order for this to work?

[julian-hj]

IIRC, rootFsPropagation is necessary to get volume mounts out of the bpm container, so I suspect that the current state is kind of like that shiny new bike path they added on the east span of the bay bridge; it would get our volume mount only as far as yerba buena island, but not all the way to work.

[xoebus]

This doesn't match up with some experimenting I just did. From what I could see as long as you create the new mounts inside a shared volume then they will appear in all jobs which have the shared volume.

[julian-hj]

That's entirely possible--it's been nearly a year since I last looked at this so it's quite possible that I am misremembering or that the landscape has shifted or both of those things.

So, you are able to mount a volume inside a shared mount in one BPM container, and see it showing up in another BPM container? If so, then that's more or less the requirement, and you can close this issue.

[xoebus]

Yep, that seems to work. I'm happy to leave this open until we can confirm that you're unblocked. There's still the issue of devices being mounted as `nodev` which may block some of your drivers. I'm hoping to remedy that in the next release.

…

On Fri, May 24, 2019 at 2:29 PM Julian Hjortshoj ***@***.***> wrote: That's entirely possible--it's been nearly a year since I last looked at this so it's quite possible that I am misremembering or that the landscape has shifted or both of those things. So, you are able to mount a volume inside a shared mount in one BPM container, and see it showing up in another BPM container? If so, then that's more or less the requirement, and you can close this issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#73?email_source=notifications&email_token=AAAJPHTDTENOA2B2WY64HFLPXBM2ZA5CNFSM4FKWB2VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGTHUI#issuecomment-495793105>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAJPHVSER5NS2SVLQM3TFTPXBM2ZANCNFSM4FKWB2VA> .

[julian-hj]

I believe that we only need /dev/fuse but I could be mistaken. I will take the blocker off of our BPM story and we will hopefully find some time to try this again sometime soon.

[julian-hj]

Ah, right. NFS is still blocked on #98 but we might be able to give the smbdriver a try. That one doesn't use FUSE.

[bosh-admin-bot]

This issue was marked as Stale because it has been open for 21 days without any activity. If no activity takes place in the coming 7 days it will automatically be close. To prevent this from happening remove the Stale label or comment below.

[julian-hj]

I agree with bosh-admin-bot that this can be closed.