-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Access Workload Kind value in provisioners #29
Comments
@maxstepanov do you mean whether this is a Deployment or StatefulSet? Can you give more context on the kind of provisioner you wanted to write? :) |
@astromechza The same thing we do every day, add objects and patch references. If the reference in the workload like, service accounts, pod disruption budget, topology spread i must be able to patch them. In order to generate the patch i need to know the object Kind to provided the appropriate patch. Our Developers, must be able to specify the service account, topology spread, pod disruption budget etc in I'm trying to avoid forking this, that's why i'm begging to add the value. so i can re-implement templating in CMD provider that also leaves patches out-of-band(score is not aware of them). then i can use wrap and dump pattern. Where i wrap the This is such a common devops pattern I'm really surprised to get so much push back on this. |
@maxstepanov let's keep the patching conversion in #25 please :) This issue is just about passing the "kind" through to to provisioner. If you need to modify the behavior of the provisioner, I recommend you use the
These params are passed to the provisioner and should be used to modify it's output. This would apply just the same to the a provisioner that generates a "patch". The I'm going to close this issue, and copy your comment above over to the thread on #25. |
@astromechza so resource polymorphism in the context of different kinds is not a desirable? I already have the annotation of the Kind in the spec but then i need to re-pass it as a prameter/annotation to resources. |
The reason for this is that resources can be shared between multiple workloads. Since multiple workloads can be different "kinds", the patch/update generated by the provisioner may not work with one of the workloads. So implicit polymorphism is not desired since it can easily fail in these cases. The solution is to make the polymorphism explicit and use the params or class. |
I'd like my provisioners to make decisions based on Workload Kind being generated.
Looks like it's not present the Input struct
score-k8s/internal/provisioners/core.go
Lines 33 to 59 in 26e2211
May be it's possible to add
WorkloadKind
to the Input struct?The text was updated successfully, but these errors were encountered: