Troubleshooting#

The following table contains solutions to commonly encountered symptoms, in the form of “things that you’ll need to remember to do when you change X or do Y”.

When I do this ... ... remember to do that Why?
Make changes to the function build pipeline:
  • function spec changes that only affect build
  • changes to builder logic
  • changes to runtime-specific build logic
 Rebuild whichever thing you're using to deploy the function (nuctl / dashboard) As long as function builds are done locally (note there's a future plan to move function build to a builder service!) - we need the builder we're working with to be aware of any change in logic. If we're deploying with nuctl, it calls platform.BuildFunction
Make changes that will affect the deployed, running function (or Nuclio's processor binary inside the function container), e.g.:
  • health checks
  • changes to trigger-specific logic
  • changes to function spec that affect runtime (like adding support for Docker volumes)
  • changes to a runtime (or a runtime's wrapper)
 Rebuild the appropriate processor image depending on the runtime of the function you're testing with (might need to rebuild processor-py, for instance)

  • If you changed function spec, you also need to rebuild your deployer (nuctl / dashboard)
  • In some cases you might need to rebuild the appropriate runtime's handler-onbuild image
 The processor binary (and in the case of function spec changes, also the deploying tool) both need to be aware of changes to functionconfig structure.

In addition, any change to processor code or runtime-specific code will need to run inside the function container - since function builds will use the existing nuclio/processor image to start from (if there is one built). For it to not be out-of-date, we must rebuild it for the processor binary to include our changes
Make platform-level changes that also affect kubernetes platform logic:
  • extending the platform.Platform interface
  • writing kube-specific logic

(assuming you're also testing with a Kubernetes cluster - which you should be doing!)
  • Rebuild the controller and dashboard images
  • Push them to your minikube's Docker hub (by using the script called push_images.py)
  • Re-apply a development-specific nuclio.yaml onto the minikube cluster

(if you're deploying with nuctl and made changes to kube platform) - rebuild nuctl too		 The controller is the entity that runs inside the Kubernetes cluster and reacts to changes made to Nuclio's CRDs - if new logic was added you need its newest version to run in the cluster.

If the changes affect the deployer too (i.e. new flag which is passed to the kube platform), it also needs to be rebuilt.
Use go test locally Give it a package, not a single test file:
go test -v ./pkg/package/... -p 1
(not: go test -v pkg/package/something_test.go)		 Go test only accepts package names, not individual test files. You may have build errors if you only give it a test file.