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
