feat: New ScalingSet CRD to deploy isolated interceptors+scalers #1014
Conversation
JorTurFer
force-pushed
the
isolated-components
branch
2 times, most recently
from
4e793d6
to
6e1700a
Compare
| } | ||
|
|
||
| // HTTPScalingSetStatus defines the observed state of HTTPScalingSet | ||
| type HTTPScalingSetStatus struct{} |
There was a problem hiding this comment.
I am sure this is empty only because the PR is still WIP but for discussion sake mentioning controller may want to capture some conditions here, such as:
- unable to create interceptor/scaler
- kube-api rejects some resource creation
- failure to form the
externalScalerURI
- interceptor/scaler are not running with desired replica count and/or are unhealthy
- possibly getting some basic stats from interceptor admin endpoint?
| } | ||
|
|
||
| // HTTPScalingSetStatus defines the observed state of HTTPScalingSet | ||
| type HTTPScalingSetStatus struct{} |
There was a problem hiding this comment.
We should provide some status about the resource, at least Ready condition
| ctx context.Context, | ||
| logger logr.Logger, | ||
| cl client.Client, | ||
| httpss metav1.Object, |
There was a problem hiding this comment.
We should consider using duck types instead of metav1.Object here, to add some type safety.
There was a problem hiding this comment.
@wozniakjan has also an idea on this.
There was a problem hiding this comment.
WDYM? We do almost the same in KEDA with ScaledObjects and ScaledJobs. Would be enough if I validate the type and return an error if the type isn't correct?
There was a problem hiding this comment.
I mentioned to @zroubalik earlier that maybe we could explore type aliasing or trivial type definitions. In this case, both ScalingSets as well as ClusterScalingSets seem to have exactly matching structure so maybe we could do something along the lines of either
type ClusterScalingSet ScalingSetor
type ClusterScalingSet = ScalingSetI had used the first one with controller-runtime v1 some eons ago successfully and haven't tried it ever since, but could be a good fit for this usecase unless controller-runtime became more strict regarding types.
The implementation went something like this: https://go.dev/play/p/sxZiO_BDw4z
There was a problem hiding this comment.
I didn't know that this works with kubebuilder but I can give a try because yes. both types are exactly the same, just cluster scoped or namespaced
|
I appreciate your feedback, I'll review it, but don't worry about reviewing the PR for the moment as it's still a WIP and there are a couple of pending stuff, like propagating the status info the the CRD, documentation, more test coverage , etc You can review it if you want, but there can be multiple changes until the final version :) |
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
Signed-off-by: Jorge Turrado <jorge.turrado@scrm.lidl>
Signed-off-by: Jorge Turrado <jorge.turrado@scrm.lidl>
|
I'm removing the changes applied to my local branch |
Signed-off-by: Jorge Turrado <jorge.turrado@scrm.lidl>
JorTurFer
force-pushed
the
isolated-components
branch
from
b58f3f4
to
6286ab0
Compare
Signed-off-by: Jorge Turrado <jorge.turrado@scrm.lidl>
Signed-off-by: Jorge Turrado <jorge.turrado@scrm.lidl>
JorTurFer
changed the title
|
I've been talking about this with @zroubalik and to not lock you with the code refactor, we will agreed with merging this PR as it is (it works actually) and I'll open a followup PR in a few days/weeks (before the release for sure) adding the pending stuff to complete this PR (such as but not exclusive):
|
Provide a description of what has been changed
Checklist
README.mddocs/directoryFixes #241