Skip to content
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

Closed
maxstepanov opened this issue Sep 5, 2024 · 5 comments
Closed

Access Workload Kind value in provisioners #29

maxstepanov opened this issue Sep 5, 2024 · 5 comments

Comments

@maxstepanov
Copy link

I'd like my provisioners to make decisions based on Workload Kind being generated.

Looks like it's not present the Input struct

// Input is the set of thins passed to the provisioner implementation. It provides context, previous state, and shared
// state used by all resources.
type Input struct {
// -- aspects from the resource declaration --
// Guid is a random uuid generated the first time this resource is added to the project.
ResourceGuid string `json:"resource_guid"`
ResourceUid string `json:"resource_uid"`
ResourceType string `json:"resource_type"`
ResourceClass string `json:"resource_class"`
ResourceId string `json:"resource_id"`
ResourceParams map[string]interface{} `json:"resource_params"`
ResourceMetadata map[string]interface{} `json:"resource_metadata"`
// -- aspects of the workloads --
// SourceWorkload is the name of the workload that first defined this resource or carries the params definition.
SourceWorkload string `json:"source_workload"`
// WorkloadServices is a map from workload name to the network NetworkService of another workload which defines
// the hostname and the set of ports it exposes.
WorkloadServices map[string]NetworkService `json:"workload_services"`
// -- current state --
ResourceState map[string]interface{} `json:"resource_state"`
SharedState map[string]interface{} `json:"shared_state"`
}

May be it's possible to add WorkloadKind to the Input struct?

@astromechza
Copy link
Member

@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? :)

@maxstepanov
Copy link
Author

maxstepanov commented Sep 6, 2024

@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 score-k8s via resource!
score-k8s doesn't support this pattern! Only for secrets and volumes!

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 score-k8s execution in a script that picks up the patches left by the my CMD provisioners and apply them to manifests.yaml

This is such a common devops pattern I'm really surprised to get so much push back on this.

@astromechza
Copy link
Member

@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 params section, for example:

resources:
  my-thing:
    type: example
    params:
      kind: something

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 class field on a resource may also be used for this purpose.

I'm going to close this issue, and copy your comment above over to the thread on #25.

@maxstepanov
Copy link
Author

maxstepanov commented Sep 8, 2024

@astromechza so resource polymorphism in the context of different kinds is not a desirable?
I'd like to generate different manifests for different workload Kinds but there is no way to do that now.
What wrong with this approach?

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.
It looks weird in the spec.

@astromechza
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants