Container names were built using the service name. We didn't checked the
name and leave underscores inside.
This commit does:
- fix all service and rename containers (`container_name`)
- use `ContainerName` everywhere we need to get the container by name
See #106
This labels allow to use some environment variables from another service
and use the configMap / secret instead of the original value. This is
useful to avoid duplication of values for several variables.
This volumes are "emptyDir" and can have init command. For example, in a
"same-pod", it allow the user to copy data from image to a directory
that is mounted on others pods.
2 fixes:
- the first problem to resolve is that some volume names can have "-" in
the name. We now replace them by "_"
- the second problem is that k8s.io library truncates the lines and so
we cannot split the files by lines. We now "unwrap" the result.
TODO: globalize the `yaml.Marshal()` code to our own specific function
Underscores are forbidden by Kubernetes (should be a valid URL string),
we replace "_" by "-" in names, and we leave the values file using the
original name. So a volume named "foo_bar" in compose file, is
registered as "foo_bar" in the values file, but "foo-bar" is used as
volume name in deployments, volume claims, ...
- reduce complexity
- use better tools to format the code
- add more tests
- and too many things to list here
We are rewriting for V3, so these commits are sometimes big and not
fully detailed. Of course, further work will be more documented.
We were using `yaml.Unmarshal` on basic types or inline structs. This
was not efficient and not clear to defined what we expect in labels.
We now use types to unmarshal the labels.
Only the `values` label is, at this time, parsed by GetValuesFromLabel
because this `utils` function is clearly a special case.
- changed variables that was uppercased, that's not OK for linters
- cleanup some documentation
- remove the "/" in label prefix, a function is now used to get the
complete label (`labelName()`)
- some cleanup in tpl files, and so on...
It is possible there are many things like this to fix. I made too much
complexity on searching services in deployment while the map key is
enough to get the righ deployment for a compose service.
Need to check the "same-pod" possibilities later.
If "depends_on" is set, we need to ensure that the target service has
got declared ports. It's necessary, at this time, to ensure the target
is started (with an initContainer)
As soon as Kubernetes proposes a better check, we will be able to fix
this requirement.
