Can you test something for us:
open laptop minishift start *minishift ip --set-static* do a demo minishift stop minishift profile set nextdemo minishift start *minishift ip --set-static* do the nextdemo minishift stop (I dislike keeping the VM running when the laptop sleeps) close the laptop move to next location open laptop repeat Each time you would move back to the previous demo, can you check with *minishift ip* if the IP is still the same? I understand that sleeping is not a good idea; as this also leeds to clock skews for xhyve which affect SSL/TLS. Would really like to know if the Fixed IP option works for you. On Fri, Jul 27, 2018 at 4:30 AM Burr Sutter <[email protected]> wrote: > > > On Wed, Jul 25, 2018 at 9:04 PM Gerard Braad <[email protected]> wrote: > >> 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? >> >> > I do not know right the solution > > my use case is: > open laptop > minishift start > do a demo > minishift stop > minishift profile set nextdemo > minishift start > do the nextdemo > minishift stop (I dislike keeping the VM running when the laptop sleeps) > close the laptop > move to next location > open laptop > repeat > > I basically run 3 main demos/scripts > A: bit.ly/msa-instructions > B: bit.ly/istio-tutorial > C: bit.ly/faas-tutorial > For this week, I ran A & C on my laptop while Christian ran B on his. > > We are working to make OpenShift installable on public cloud VMs, > therefore we would not have to worry about the laptop/minishift having > issues with changing networks - but it does mean you have to have internet > connectivity (and sometimes you do not). > > > > > >> 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
