Skip to content
This repository has been archived by the owner on Jan 19, 2018. It is now read-only.

RFE: given a collection of OpenShift templates (or Kubernetes JSON files) apply them all in service order first #18

Open
jstrachan opened this issue Apr 30, 2015 · 5 comments

Comments

@jstrachan
Copy link

Note this might already be fixed - just adding it as a note to be sure its done...

If you have N OpenShift templates and/or Kubernetes JSON files, we'll need to process all the OpenShift templates first (e.g. via osc process command line tool). Then we're left with an ordered list of Kubernetes JSON files.

We need to then iterate through all these JSON files and apply the Services first; to generate the constant service portalIP addresses. Then in the second phase, we do everything but the Services (i.e. Pods and Replication Controllers) which by this time should have all the environment variables setup correctly to point to all the services.

If you don't provision things in a 2 phase approach; its possible to get cycles (Pod A uses service B and Pod B uses service A) and one of the pods doesn't get the IP address of the service.

@goern
Copy link
Contributor

goern commented Jun 17, 2015

@jstrachan pls check if this is correctly implemented...

@aweiteka aweiteka added this to the CDK GA milestone Jul 24, 2015
@ncdc
Copy link

ncdc commented Dec 18, 2015

If the pod's container expects to use the environment variables for the services that Kube/OpenShift automatically inject into the pod/container, then yes, you must create the services first before creating the pods. But it's probably better to have the pod look up the service via DNS. For example, if you have a service called "mysql", the pod can just refer to it via the DNS name "mysql", and it will be resolved to the appropriate service.

@dustymabe
Copy link
Contributor

Another note here.. In the future we are considering making two different passes over the artifacts. One of them deploys services/rcs etc... And the next pass scales the rcs up from 0 to N.

@ncdc would this approach work for that first "non-DNS" case? Since the pods haven't been created yet, because they are scaled down to 0, will they finally have the env vars once they are created after scaling up?

@ncdc
Copy link

ncdc commented Dec 18, 2015

Yes, env vars are injected when pods are created

@dustymabe
Copy link
Contributor

I think this will be taken care of a future restructure we are planning to do where we do a first pass to create services/rcs/dcs and then another pass to scale up the rcs/dcs. In this case the pods won't get created until the rc/dc gets scaled from 0 to N and they will get created with the appropriate environment variables.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants