Longevity of the .NET Core runtime....

[natiki]

Hi,

As @allantargino is kindly hosting this off his hub account how is Kubeless securing the longevity of this runtime?

I understand it is a 3rd party contributor, but wouldn't it be "better" if kubeless at least maintained this within its own hub account? As I understand things if this image was ever deleted then basically there is no recourse to the project.

Cheers,

[andresmgot]

Hi,

The default configuration points to @allantargino repository to make it easier for him to update/modify the runtime as OWNER. The source code for the runtime is here:

https://github.com/kubeless/runtimes/tree/master/stable/dotnetcore

So actually anyone can build/mirror this image if necessary.

[natiki]

Hi,

So why does Kubeless not do the mirror? My concern here is that one day I will go to deploy a function and it won't work. I then have to scramble to rebuild this.

[andresmgot]

I understand, yes, we could mirror those images and in case there is an outage we could swap those image. The problem is that it will require changes in the Kubeless configmap so in case that happens, admins would need to do some manual work anyways.

We could also build and push images in the runtimes CI but some of them are quite slow to build and it would add a lot of overhead for every build.

There is room for improvement there but we never have the resources to work on that, we are open to contributions!

[natiki]

@andresmgot Contributions..... yes, this project is on my list.... :-)

We are seriously considering Kubeless for our serverless production requirements with .NET Core as it meets a number of needs and requirements others don't..... If we do commit to it then I will be able to use some of my "day job" developer resources to improve things and give back to OSS.

I do however have a steep learning curve here to produce and extend the rumtimes already provided for .NET Core ;-)

[allantargino]

I agree with @andresmgot that adding this step to the build would make it slower.. @natiki, how about you mirror all images in your own registry and use it with kubeless?

[allantargino]

Sorry the delay to get into the discussions, I was in vacations :))

[natiki]

@allantargino no apologies needed ;-) Too few vacations these days. grin

Apologies if this is a noob question but:

build would make it slower..

I assumed the docker publish is decoupled from the main kubeless build? And that CI for this push is only done off a trigger for https://github.com/kubeless/runtimes/tree/master/stable/dotnetcore once it is released?

how about you mirror all images in your own registry and use it with kubeless

For our production requirements yes.... However I am "pushing" to get the .net runtime (managed by 3rd parties) on the same footing as the ones developed "in house" by kubeless.

[andresmgot]

I assumed the docker publish is decoupled from the main kubeless build? And that CI for this push is only done off a trigger for https://github.com/kubeless/runtimes/tree/master/stable/dotnetcore once it is released?

Yes, the build procedure for the core of Kubeless is decoupled from the runtimes (it is a different repository and CI). Pushing the image is not the problem though, building those take several minutes depending on the runtime. We would need also to code a mechanism to substitute images built in the CI in the manifests.