Added environment as a kubernetes resource definition

[erwinvaneyk]

This fixes #168

[erwinvaneyk]

@xiekeyang could you review this change?

[xiekeyang]

@erwinvaneyk

This provides the workflow environment solution via helm chart installation. However, general customer have no permission to use helm install, which need kube admin privilege (like open shift platform).

So customer might like to use command fission spec apply --specdir <workflow-env-dir>, or kubectl spec apply -f <env.yaml> to create a workflow env.

What is more, customer might want to fill more parameters like resource setting, self-defined environment variables, etc, which is not involved in currant template. If we paste all possible parameters in template, it will be too long-winded.

So, IMO, we can provide:

a) Just address this PR. And we supply some doc, let reader know they can follow this template, and fill their own parameters in it. And suggest customers to create workflow env via fission or kubectl command.

b) Provide a simple workflow-env yaml sample file, with filling the necessary parameters, instead template. Put the yaml file to dir like hack/env/specs/ or example/env/specs... Let customer know they can create it by fission or kubectl. And customer will do this according to their user cases.

I think the above ways are both OK.

[xiekeyang]

charts/fission-workflows/templates/deployment.yaml is an available environment spec, with removing all variables. I feel we need not to use helm command (inhack/codegen-helm.sh) any more, fission spec apply is better?

[erwinvaneyk]

@xiekeyang -- agreed, with the directory change. It might be better to move this to the example dir to indicate that it is just an example of a workflow env definition. The codegen script is just for me/developers to keep the helm templates in sync with the example specification. Users should not need it or helm to use the spec