Looked at power shift documentation, it meant for local cluster management ( like up and down and switch etc)
Does it work enterprise multi cluster switching without up and down? -- Srinivas Kotaru From: Jonathan Yu <[email protected]> Date: Wednesday, December 21, 2016 at 11:24 AM To: Srinivas Naga Kotaru <[email protected]> Cc: "[email protected]" <[email protected]>, dev <[email protected]>, Jorge Morales Pou <[email protected]>, Graham Dumpleton <[email protected]> Subject: Re: OC client - Multi cluster I think PowerShift may be useful for this scenario... Jorge and Graham would know more, but I think powershift enables easy switching between cluster "profiles" and manages persistence of configuration state. Tutorial: https://stefanopicozzi.blog/2016/12/18/getting-started-with-oc-cluster-updown/ GitHub: https://github.com/getwarped/powershift-cluster On Wed, Dec 21, 2016 at 11:21 AM, Srinivas Naga Kotaru (skotaru) <[email protected]<mailto:[email protected]>> wrote: Yep, both –config and KUBECONFIG working as expected. I agree with you, for automation and scripts, use –config and humans with multiple terminals and tabs, use KUBECONFIG. -- Srinivas Kotaru From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Wednesday, December 21, 2016 at 11:16 AM To: Srinivas Naga Kotaru <[email protected]<mailto:[email protected]>> Cc: dev <[email protected]<mailto:[email protected]>> Subject: Re: OC client - Multi cluster I would recommend keeping login and use of the config file separate - for CI, using a pre-built kubeconfig that you control separately from the thing using it. In general, for scripting I recommend --config and for users with multiple shells I recommend KUBECONFIG. Since a single kubeconfig file isn't thread safe you don't really want multiple shells reusing the same kubeconfig if you are going to ever run "oc project" or "oc login" On Dec 21, 2016, at 2:21 AM, Srinivas Naga Kotaru (skotaru) <[email protected]<mailto:[email protected]>> wrote: It seems below approach working. Not sure that is right approach to deal with this issue. oc get pods -o wide --config ~/.kube/cluster1 oc get pods -o wide --config ~/.kube/cluster2 -- Srinivas Kotaru From: Srinivas Naga Kotaru <[email protected]<mailto:[email protected]>> Date: Tuesday, December 20, 2016 at 11:08 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: dev <[email protected]<mailto:[email protected]>> Subject: Re: OC client - Multi cluster U mean using separate .kube/config per tab? KUBECONFIG=/path/to/.kube/config env variable How this approach works in CI/CD environment where it has to deploy to multiple clusters? One login should not overwrite another deployment where it might be deploying to altogether different cluster? Does OC support --kubeconfig=/path/to/.kube/config so CI/CD systems use oc login –user <> -password <> --kubeconfig = --kubeconfig=/path/to/.kube/config?? -- Srinivas Kotaru From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday, December 20, 2016 at 10:49 PM To: Srinivas Naga Kotaru <[email protected]<mailto:[email protected]>> Cc: dev <[email protected]<mailto:[email protected]>> Subject: Re: OC client - Multi cluster You can use different KUBECONFIG environment variables per tab. It has been suggested to add more environment variables but that can complicate scripting. On Dec 21, 2016, at 1:43 AM, Srinivas Naga Kotaru (skotaru) <[email protected]<mailto:[email protected]>> wrote: Is it normal behavior to switch to each cluster and login separately while working on clusters? One terminal with 3 tabs, can’t we work each cluster separately? What happening, whatever last login, being affective same cluster on all the tabs. To overcome I tried to play around with set-context and use-context but still no use. Commands always issued against last login or current-context(which is always the last logged cluster) -- Srinivas Kotaru _______________________________________________ dev mailing list [email protected]<mailto:[email protected]> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev _______________________________________________ dev mailing list [email protected]<mailto:[email protected]> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev -- Jonathan Yu / Software Engineer, OpenShift by Red Hat / Follow me on Twitter @jawnsy<https://twitter.com/jawnsy> “Restlessness is discontent — and discontent is the first necessity of progress. Show me a thoroughly satisfied man — and I will show you a failure.” — Thomas Edison
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
