nuclio: Can't specify custom labels or versions in Function resource...

Hi,

I am trying out Nuclio and I must say it a great contribution! There are however a few of use cases that are throwing me for a loop…

UseCase #1:

• Need to ability to specify custom labels on my functions.
• I am using the manifest approach to creating my function using the following manifest:

apiVersion: nuclio.io/v1
kind:       Function
metadata:
  name:      fred
  labels:
    fn:             fred
    revision:   v1

Per the doc, my read was that you should be able to set custom labels on this resource, but some will be overridden by the controller. That seems acceptable but it looks like my custom labels are completely wiped clean. So in this case looking at the function pod my cust labels fn and revision never make it. Describing my function pod shows:

name=fred
pod-template-hash=519971098
serverless=nuclio
version=latest 

UseCase #2

• Need to ability to run fred v1 and fred v2 concurrently. I want the ability to try out a couple version of my function in the cluster so I can test out which performs better. So I thought I can deploy using the nuctl CLI since I can’t seem to be able to set a version in the manifest. However specifying --version v1 or --version v2 has absolutely no effect as the version is set to latest no matter what?? It is totally possible that I am missing something here, but having the ability to deploy multiple revs of a given function seems like a reasonable use case?

UseCase #3

Deploying a custom service docker image. I could not find this in the docs, but I would also like to build a full service docker image and use this as the function image ie completely bypassing the controller, publish the image to my registry and use that image in the manifest. The function may then support multiple routes/options. I am sure this is possible but I am not sure how to best approach it. So suggestions and comments would be most appreciated!

Versions

• Nuclio Version: 0.2.6
• K8s: 1.9.0

Now I realize this might be off the original intent. So I am totally ok with not in scope replies.

Thank you for your comment and suggestions and for contributing this very clever framework to the community!!