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]> 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]" <[email protected]> > *Date: *Wednesday, December 21, 2016 at 11:16 AM > *To: *Srinivas Naga Kotaru <[email protected]> > *Cc: *dev <[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]> 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]> > *Date: *Tuesday, December 20, 2016 at 11:08 PM > *To: *"[email protected]" <[email protected]> > *Cc: *dev <[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]" <[email protected]> > *Date: *Tuesday, December 20, 2016 at 10:49 PM > *To: *Srinivas Naga Kotaru <[email protected]> > *Cc: *dev <[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]> 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] > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > > > _______________________________________________ > dev mailing list > [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
