One gotcha with using "profile set" as the first statement is the user gets an off-putting message
./minishift profile set istio-demo oc cli context could not changed for 'istio-demo'. Make sure the profile is in running state or restart if the problem persists. the problem with this message is that I have several more commands to run before I run "start", so stop complaining to me that I have not yet ran start. On Sun, Nov 5, 2017 at 7:26 PM, Gerard Braad <[email protected]> wrote: > Hi, > > > On Sun, Nov 5, 2017 at 4:39 PM, Burr Sutter <[email protected]> wrote: > > but one syntax requires no "--" and the other has "--" which I find to > be > > odd since I am using the commands back to back. > > One is a command to set the active profile for subsequent commands, > while the other is a flag to perform a single action/command outside > of the currently chosen or active profile. > > On Sun, Nov 5, 2017 at 11:35 PM, Burr Sutter <[email protected]> wrote: > > I was able to switch profiles live today. > > Good to hear! There is actually not much to it, we do still have some > kinks to iron out. > Feedback like yours will help with, as some can be as easy as better > feedback during start, documentation, etc > > On Mon, Nov 6, 2017 at 6:33 AM, Burr Sutter <[email protected]> wrote: > > But for subsequent restarts, running that same sequence yields lots of > > messages that look bad to the end-user. > > At the moment we provide a verbose feedback about the startup of > Minishift, as we experience many reports related to missing settings > or something related to being on a different distro, or just sometimes > weird behaviour... > > We will try to reduce the output after we are a little bit more > stable, and only report things when we really see a failure. This is > pretty much the same as what happened for the output of `oc cluster > up`, as they also dropped the verbosity after some time. > > > The big win on profiles is the ability to start them and stop them > often, on the fly, in front of a live audience. > > As long as the IP address doesn't chane... as we still have an issue > with how certificates are generated by `oc cluster up`. As long as > there is no way to regenerate the certificates for the new IP address > assigned to the VM, the startup would fail. We can work around this by > forcibly assigning an address on restart, but this will only work with > using the same address when the certificate was generated. > > I hope this can be solved.. > > > Gerard >
_______________________________________________ Devtools mailing list [email protected] https://www.redhat.com/mailman/listinfo/devtools
