You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
How to selectively define the fields to reconcile with DependentResources #1474
Defining a DependenResource of type e.g. Job is slightly problematic at a first attempt.
The reason is that the Job.spec.template field is immutable and any update operation slightly changing it result in an error.
I'm not sure what would be the best course of action here, e.g. Labels can still be updated/reconciled, but we should make sure the .spec.template remains untouched.
The problematic bit is that .spec.template contains elements that are filled after the object is created e.g.:
I would like to simply skip the update if .spec.template differ, and, to make sure I never update that subpath (as it will result in an error all the time).
@andreaTP I linked a PR, we can discuss that. Basically now this is possible just more hacky, with that it should be doable much more elegantly. Probably the best would be to add to the same branch an integration test for this use case.
I was updating the API for this use case, see related PR. But realized that getSecondaryResource always can be called. So you can just call that set the spec.template part from there if present. In this case it is not changed.
Not sure if we should still change the API of desired. Will create an example at least.
Activity
csviri commentedon Sep 19, 2022
We don't have a Job specific matcher yet, but this can be probably just fixed if you override the matcher.
What is your exact use case?
Asking because recreating a use case is not supported, what might be an use case some times.
andreaTP commentedon Sep 19, 2022
I would like to simply skip the update if
.spec.templatediffer, and, to make sure I never update that subpath (as it will result in an error all the time).csviri commentedon Sep 19, 2022
Ahh ok, this is defintely should be possible to do even now, just overriding the match and the update function.
However might be easier if the desired would receive the actual resource too if present. cc @metacosm - will prepare a PR for this.
csviri commentedon Sep 19, 2022
@andreaTP I linked a PR, we can discuss that. Basically now this is possible just more hacky, with that it should be doable much more elegantly. Probably the best would be to add to the same branch an integration test for this use case.
github-actions commentedon Nov 19, 2022
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.
github-actions commentedon Dec 4, 2022
This issue was closed because it has been stalled for 14 days with no activity.
csviri commentedon Jan 31, 2023
I was updating the API for this use case, see related PR. But realized that
getSecondaryResourcealways can be called. So you can just call that set thespec.templatepart from there if present. In this case it is not changed.Not sure if we should still change the API of desired. Will create an example at least.
csviri commentedon Jan 31, 2023
See sample here:
#1746
I think this is good enough, no need to explicitly put the resource in to
desrire(...)api. Unless you think otherwise @andreaTP or @metacosm