[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OC client - Multi cluster





On Wed, Dec 21, 2016 at 11:32 AM, Srinivas Naga Kotaru (skotaru) <skotaru cisco com> wrote:

Looked at power shift documentation, it meant for local cluster management ( like up and down and switch etc)


Oh... Yes. Clayton's answer is better for production scenarios, sorry about that :)

 

Does it work enterprise multi cluster switching without up and down?


I don't think so, but Jorge/Graham would know more. I think it's a general-purpose tool that could be retrofitted that way if it makes sense to do so (seems to be a nice plugin-based architecture)

 

-- 

Srinivas Kotaru

 

From: Jonathan Yu <jawnsy redhat com>
Date: Wednesday, December 21, 2016 at 11:24 AM
To: Srinivas Naga Kotaru <skotaru cisco com>
Cc: "ccoleman redhat com" <ccoleman redhat com>, dev <dev lists openshift redhat com>, Jorge Morales Pou <jmorales redhat com>, Graham Dumpleton <gdumplet redhat com>


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/

 

On Wed, Dec 21, 2016 at 11:21 AM, Srinivas Naga Kotaru (skotaru) <skotaru cisco com> 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: "ccoleman redhat com" <ccoleman redhat com>
Date: Wednesday, December 21, 2016 at 11:16 AM
To: Srinivas Naga Kotaru <skotaru cisco com>
Cc: dev <dev lists openshift redhat com>
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) <skotaru cisco com> 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 <skotaru cisco com>
Date: Tuesday, December 20, 2016 at 11:08 PM
To: "ccoleman redhat com" <ccoleman redhat com>
Cc: dev <dev lists openshift redhat com>
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: "ccoleman redhat com" <ccoleman redhat com>
Date: Tuesday, December 20, 2016 at 10:49 PM
To: Srinivas Naga Kotaru <skotaru cisco com>
Cc: dev <dev lists openshift redhat com>
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) <skotaru cisco com> 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
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev




--

Jonathan Yu / Software Engineer, OpenShift by Red Hat / Follow me on Twitter @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




--
Jonathan Yu / Software Engineer, OpenShift by Red Hat / Follow me on Twitter @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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]