Hi Burr, And this is why there is an option `m ip --set-static` as it sets the same IP forced onto the network interface. but the smart solution is also not to rely on a bridged network option here, as you can never predict what the IP range of the 'new wifi' is.
Or avoid all of this and set up your own VM using a static address, maybe using vagrant or using the Hypervisor management interface, tweak the settings from the console to use the network rc scripts, etc. and then provision OpenShift using the Remote/Exisitng VM feature of minishift (the generic driver) => https://docs.openshift.org/latest/minishift/using/run-against-an-existing-machine.html Our hands are tied when it comes to IP assignment, as these are controlled by the hypervisor. The way the docker machine library interacts with these hypervisors prevents us from doing very fancy stuff. It is a known limitation, for which we already have a better solution than minikube ATM. What are you missing? regards, Gerard On Thu, Jul 26, 2018 at 4:35 AM Burr Sutter <[email protected]> wrote: > > > > On Wed, Jul 25, 2018 at 11:44 AM Lalatendu Mohanty <[email protected]> > wrote: >> >> >> >> On Wed, Jul 25, 2018 at 9:37 PM, Burr Sutter <[email protected]> wrote: >>> >>> >>> >>> On Tue, Jul 24, 2018 at 12:59 PM Lalatendu Mohanty <[email protected]> >>> wrote: >>>> >>>> On Tue, Jul 24, 2018 at 8:03 PM, Gerard Braad <[email protected]> wrote: >>>>> >>>>> Only after the first/initial start After this the address is fixed and >>>>> will be applied to the VM on start. >>>>> It writes a configuration file into the persistent storage of the VM >>>>> and this is read on start every time. >>>>> >>>> >>>> Hi Burr, >>>> >>>> I have a question for you. When we implemented "--set-static" feature we >>>> had the question around whether --set-static should be part of "minishift >>>> start" or "minishift ip". There were arguments for both the sides. This >>>> was one of the reason we kept this feature as experimental. When a feature >>>> is experimental we look for user feedback and then we can make changes >>>> without keeping backward compatibility. >>>> >>>> As Gerard mentioned we need existing Minishift instance to run minishift >>>> ip --set-static and you just need to run it once during the first start. >>>> >>>> If you run it without the instance then you will get below error >>>> >>>> $ minishift ip --set-static >>>> Error getting IP: Docker machine "minishift" does not exist. Use >>>> "docker-machine ls" to list machines. Use "docker-machine create" to add a >>>> new one. >>>> >>>> We have an issue [1] to improve the error message, but it is clear that it >>>> needs a running instance. >>>> >>>> Now my question is, what you think would be a better user experience >>>> "minishift start --set-static" or "minishift ip --set-static" or something >>>> else. >>> >>> >>> >>> I like the proposal of using the config “setstaticip” that gets applied >>> after start. >>> >>> Also, one big gotcha is that subsequent minishift starts on NEW VMs will go >>> able to .100, which might “overlay” a previously created VM. This gives >>> you an error in the new Vm and the old one. This just happened to me as I >>> am scrambling to get the demo up for customers today. >> >> >> >> The IP allocation part is handled by the hypervisor software. Minishift can >> not do much about it. When a VM starts it asks the hypervisor to give a >> free IP. If you have VM in shutdown/stop state for long hypervisor considers >> the the previous allocated IP is free after certain time, hence the issue. >> > > We need some smarts in minishift to at least realize it is being allocated an > IP again. It seems to be a very common occurrence, in short time intervals > (minutes) if you are changing wifi access points > > minishift stop > close laptop > move > open laptop > connect to a new wifi > minishift start > > >>> >>> >>>> >>>> >>>> Also upstream Minishift has a mailing list [2]. I would request you to use >>>> that as we do not consider [email protected] as our upstream mailing >>>> list. >>>> >>>> [1] https://github.com/minishift/minishift/issues/2163 >>>> >>>> [2] https://lists.minishift.io/admin/lists/minishift.lists.minishift.io/ >>>> >>>> Thanks, >>>> Lala >> >> _______________________________________________ Devtools mailing list [email protected] https://www.redhat.com/mailman/listinfo/devtools
