Closed mkinney closed 4 years ago
I like this idea but I'm not a fan of the interface. If you're going to persist changes to the vmx it shouldn't happen silently and it probably shouldn't be done on the up command.
Why not create a new interface to update the vmx?
Can you elaborate? I don't understand.
mech up is a command for bringing up the VMX as it stands up.
But if you are going to add these switches to the up command you make the up command persist state which to me is an unexpected behavior.
If anything, commands that can modify the VMX should be seperate and also confirm that VMX changes will be taking places.
Yes, when I run "mech up" I may want to override the value that is hard coded into the .box file. That is why I enabled the override in the initial up() command.
I think a better approach is to expose the VMX configuration under a separate command. Up should be very simple and just do the one thing it's asked of.
The "up" is configured to auto-add the network card on the first spin up the the vm. I didn't create a new pattern per se, just followed the existing pattern.
Often times, I will want to spin up a slightly different configuration on-the-fly. So, I think this approach is better for my use cases.
So, are you proposing a new operation like 'mech change_vmx' that would allow you to override these values? Or, could you elaborate on how you'd like to see it implemented?
if this were to be revisited, it would be better to have the mem/vcpu settings in the mechfile like the vagrantfile... mech up should be simple and the persistent settings done in the Mechfile so you can do mech destroy/mech up cycles without remembering your settings for the up command every time.
Resoves #68