feat: Investigate replacement for stackanetes-entrypoint

[alanmeadows]

The stackanetes-entrypoint image consistently leveraged runs into issues with DAEMONSET dependencies, and has trouble with config file dependencies. These should be documented in this issue subsequently but I do not have readily available access to tracebacks at the moment.

We either need to:

1. Investigate whether since its creation there is a now "standard" init container for dependency checking that is being widely used

2. If we continue to use it, ensure we are including it in our CI/CD pipelines we will develop and be creating issues to have the issues we encountered resolved in the upstream repository: https://github.com/stackanetes/kubernetes-entrypoint

[v1k0d3n]

@alanmeadows can you elaborate a little for the general community? @PiotrProkop could make these changes happen since he has done most of this work for stackanetes.

[alanmeadows]

@DTadrzak @PiotrProkop

Currently, when trying to use the daemonset dependency, I get this:

ubuntu@MT01DB04:~$ kubectl run -i --tty entrypoint-test --image=quay.io/stackanetes/kubernetes-entrypoint:v0.1.0 --restart=Never --env=NAMESPACE=default,DEPENDENCY_DAEMONSET=foobar,COMMAND="echo done" -- /kubernetes-entrypoint
Waiting for pod default/entrypoint-test to be running, status is Pending, pod ready: false
Waiting for pod default/entrypoint-test to be running, status is Pending, pod ready: false
Entrypoint Error: 2017/01/05 19:40:40 daemonset.go:25: Cannot initialize daemonset: Env POD_NAME not set
panic: value method daemonset.Daemonset.GetName called using nil *Daemonset pointer

goroutine 9 [running]:
panic(0x127b240, 0xc420427e90)
	/usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/stackanetes/kubernetes-entrypoint/dependencies/daemonset.(*Daemonset).GetName(0x0, 0x147b318, 0xc420427e80)
	<autogenerated>:2 +0xa4
github.com/stackanetes/kubernetes-entrypoint/entrypoint.Entrypoint.Resolve.func1(0xc420427e80, 0x1bd2f00, 0xc4203389c0, 0xc42001202a, 0x7, 0x1bc7b00, 0x0)
	/home/pprokop/gopath/src/github.com/stackanetes/kubernetes-entrypoint/entrypoint/entrypoint.go:61 +0x8b
created by github.com/stackanetes/kubernetes-entrypoint/entrypoint.Entrypoint.Resolve
	/home/pprokop/gopath/src/github.com/stackanetes/kubernetes-entrypoint/entrypoint/entrypoint.go:72 +0x102
ubuntu@MT01DB04:~$ 

Secondly, the config dependency is exactly what I'm looking for to template configmaps with runtime data. Kubernetes has already made it clear they do not want to support this natively, and recommend a templa-tizer init container or sidecar container. This could serve that purpose well however, I need it to do more.

• It should support arbitrary environment interpolation with {{ ENV_FOOBAR }} if I pass in FOOBAR into the environment. It should support options to both error on missing environment variables or null if absent.

• I would like to be able to pass in a path instead of the hard coded /configmaps path.

• I would like to be able to do IP.eth0, IP.bond2.502, and so on (where legacy IP returns IP for interface with the default route); the current implementation only supports a single interface.

• I would like to be able to interpolate command output. Similar to the environment request, if my configmap has {{ ENV_FOOBAR | exec }} as an example it would execute the command in the environment variable foobar and interpolate the results for any {{ ENV_FOOBAR} references. For this reason, the entrypoint image may want to support bash, awk, sed, and a few cores like python, allowing me to pass in simple scripts as mounts that can retrieve the output I need.

[alanmeadows]

Note that I just realized buried in that trace is an error about the POD_NAME not being specified. I will re-run tomorrow with that properly specified in the environment because in my real world scenario I believe that was specified. The nil daemonset pointer error was the same however.

Specifically the goal here is for the new setup with neutron where there are several daemonsets that need to be ordered and we need to be able to depend on other daemonsets being ready:

ovs-db > ovs-vswitchd > neutron-ovs-agent

The finally:

Neutron-ovs-agent > l3 agent
Neutron-ovs-agent > DHCP agent
Neutron-ovs-agent > Compute agent
and so on.

[DTadrzak]

If you have a problem with POD_NAME you need to pass following item as a env:

env:
- name: POD_NAME
  valueFrom:
    fieldRef:
      fieldPath: metadata.name

According to extensions, @PiotrProkop are we able to implement those functionalities?

[DTadrzak]

In future we can use AppController. Mirantis is working on integration with HELM.
https://asciinema.org/a/0pzyc1tuyk9ohabohnzenvpbe
helm/helm#1756

[PiotrProkop]

Daemonset dependency not working in init-container is just a bug which has to be resolved. I will create an issue on github and address it. When it comes to templating, we should prepare a list of missing features and resolve them one by one. If you could create issues with missing features I would appreciate.

[mzylowski]

@alanmeadows
Can you create issues related with gaps from your second post on k8s-entrypoint repo? (https://github.com/stackanetes/kubernetes-entrypoint/issues).

We can start there discussion related with every improvement. I can take responsibility for resolving some issue in entrypoint.

Also I made some research related with daemonset-dependency and for me it works fine but POD_NAME have to be specified.
PTAL: stackanetes/kubernetes-entrypoint#15 (comment)

[v1k0d3n]

@alanmeadows did you get to this. i think you may have explained some of this offline. may be good to have tracked in an issue at stackanetes or here. just trying to keep up with some of our issues.