Add initial roadmap #176
Add initial roadmap #176
Conversation
| - [S] Evaluate container registries for moving container images out of DockerHub | ||
| - [M] Support autoscaling on custom metrics for applications | ||
| - [M] Support managing PodDisruptionBudgets for applications | ||
| - [L] Look into replacing fiaas/k8s with kubernetes-clients/python |
There was a problem hiding this comment.
I'd like to hear a bit of background for this item?
Last time I checked, the official client was really cumbersome to work with, especially when dealing with CRDs.
If it was up to me, I would probably prefer to put my time into improving fiaas/k8s in the places where it falls short rather than trying to work with the official client. The only thing I really would like to get from the official client is the config-loading mechanisms.
There was a problem hiding this comment.
The background is partially captured by the list of PRs closed in the k8s repository, for example this one: fiaas/k8s#101
We shouldn't be spending time maintaining our own client, because each time an API changes, we have to reflect that. This increases our workload when having to make the FIAAS ecosystem compatible with a new Kubernetes version, and as you know, these come regularly.
There was a problem hiding this comment.
Most of those would have been handled with little to no effort if we had taken the time to implement fiaas/k8s#97 (a first attempt of which was in fiaas/k8s#55).
But fair enough. I don't do enough with the fiaas codebase these days to have a strong opinion either way.
There was a problem hiding this comment.
We shouldn't be spending time maintaining our own client, because each time an API changes, we have to reflect that. This increases our workload when having to make the FIAAS ecosystem compatible with a new Kubernetes version, and as you know, these come regularly.
I think this is a good summary of the background/motivation for this.
Also I see this as initially an exploratory task, to determine if using the official client could be a good fit, before either committing to switching or not.
This is a suggestion for a roadmap consisting of some items we've discussed internally. Consider this not written in stone; I'm adding it here for transparency's sake, and as a tool for further discussion.