-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NFS shared directories #9
Comments
Documenting issues that @tylerflint explained to me today: The ZoneGate is currently enabled just after zones are created, which is just after the global zone becomes available: vagrant-smartos-zones/lib/vagrant/smartos/zones/hooks.rb Lines 10 to 19 in 85f866f
Yet in order for NFS to work, a private ip must be provisioned in the global zone. By the time |
This just happened two weeks ago: It looks as if Docker suffers from a similar problem. I can't quite wrap my head around that commit at the moment, but it will likely change the understanding we gained today about code execution ordering. |
NFS with VirtualBox requires that a public or private network is used. Because of how the Network middleware is written, the only way to run code after it is to register middleware *before* it, but call through to later middleware before executing code. This change requires a bit switch in the order of our middleware, and will likely cause problems with attempts to integrate with guest additions. The guest additions code executes before networks are configured, so before we can reasonably expect a local zone to exist. [refs #9]
@tylerflint try pulling the latest code from github when you get a chance. At the very least, vm public and private networks should now get installed in the global zone before the zone is created. |
That actually did work! I’m not sure what issues we might run into by deferring the zone configuration until the end of the stack, but at the very least it seems to have worked for the current set of functionality. The only thing that didn’t seem to run was the actual ifs mount. For some reason vagrant didn’t even try to setup nfs. I’m wondering if they’ve recently changed the dsl and I’m simply using it wrong. Either way, this is good progress! On Nov 9, 2014, at 11:35 AM, Eric Saxby [email protected] wrote:
|
@sax Actually, I was just being silly. When I configure the Vagrantfile correctly, nfs works perfectly. As soon as I can I'll update the README with an example of how to enable nfs and then we can consider this complete. Pretty cool! FYI there is no proprietary config here at all, just added this to the Vagrantfile: config.vm.network "private_network", ip: "33.33.33.10"
config.vm.synced_folder ".", "/vagrant", type: 'nfs' |
@sax as a side note, it might be worth discussing any issues that we may be causing down the road by deferring the action stack. I actually can't think of any right off, since we'll likely be installing guest plugins with a custom action within this plugin. As I think about it, I'm really not sure that we'll have any issues with this at all. Still, worth thinking about in advance. fwiw I'm really glad you looked at it from a different angle. I couldn't think about how we were going to get around this issue and the approach I was about to take probably would have worked eventually, but would have been a lot of work and likely a race condition. |
Ditto! I think this has been a really good collaboration. Thank you for spending so much time deconstructing the NFS middleware. It was really spinning around in my head until you pointed out the Network middleware. |
Oh, awesome! I thought there was going to need to be changes in the zone provisioning. This is fantastic!= |
This probably works, I think it just needs thorough testing and some documentation in the README.
The text was updated successfully, but these errors were encountered: