serverless-components / knative Goto Github PK

In serverless.yml there are two fields "app:" and "name:" that for the examples are filled with the same values always.

What is the semantic difference and can one of them be omitted?

The mode (i.e. whether deploying on pure Kubernetes or on OpenShift) is auto-detected but it would be nice to pin the mode as on OpenShift both modes can be used when running with admin permission (as an admin is allowed to create privileged containers). This could go into serverless.yml or .env

In the Kubernetes world, it is an established convention that tooling picks up the cluster connection information from "~/.kubec/config". This works for Kubernetes & OpenShift.

I suggest to do the same for this component, so that a user does not have to replicate this information in .env.

... as it is not Express specific anymore (see other examples).

Also, maybe update the splash screen, too ?

While working on this component, the error message when some interaction with the cluster goes wrong is not informative. It just says "HTTP error" but the error itself contains more information in the response body. That should be presented to the user to help in troubleshooting.

Every example requires a package.json in the src/ directory, otherwise, the serverless framework throws an error, even when this package.json is not needed at all.

For non-node projects, package.json should not be required. See the non-node examples' package.json, they are only kind of dummies.

This should be a trivial change but requires changed on the other component dependencies (i.e. kubernetes-configmap would need to get a kubernetes-secret companion).

The deployment for the Kubernetes mode is quite involved with a lot of moving parts (upload pods, persistent volumes, ..).

This can be drastically simplified with a technique described in https://github.com/rhuss/buildah-poc which uses an init-container for receiving the source code. This PoC uses buildah but could equally use Kaniko as well. The benefit of this approach are less things that can go wrong and that need to be cleaned up.

Currently, an existing config map is reused for the Docker credentials used in Kubernetes mode when pushing to the registry. However, this fails when the user changes her configuration in .env after the first run. I recommend to recreate the configmap (or secret, but see #8 ) for every run.

For now, it is assumed that the port is hardcoded to 8080, but it is maybe a good idea to allow this to be configured and then picked up when the Knative service is created.