Add ADR for Function Revisions #133
Conversation
| testcluster --> stop | ||
| test --> |No| prod[Set revision policy to manual] | ||
| prod --> maint[Maintenance Cronjob triggers] | ||
| maint --> first{Is first maintenance for instance?} |
There was a problem hiding this comment.
What kidn of maintenance it is? instance maintenance? the one that is specified in the claim, right?
There was a problem hiding this comment.
Yes the instance maintenance.
| prod --> maint[Maintenance Cronjob triggers] | ||
| maint --> first{Is first maintenance for instance?} | ||
| first --> |Yes| autpolicy[Set revision policy to auto] | ||
| first --> |No| selector[Set revision selector to most current revision] |
There was a problem hiding this comment.
I don't understand this logic when it's NO, it has to go back to policy manual and remain on the older version until its maintenance is triggered and then it can go to the happy path yes and set to auto no?
There was a problem hiding this comment.
No, if it's not the first maintenance, then it's already set to automatic, so we can skip setting the policy. We only have to change from manual to automatic on the first maintenance, when we set the selector for the revision. Once the selector is set, we have to use automatic, or the revision will never be updated.
Just for the record, here's the rendered chart:
| changes --> stop | ||
| .... | ||
|
|
||
| For production clusters the default revision policy will be set to manual. This will ensure that newly created instances will just have the most current revision. Test cluster will get the default policy automatic, so they get changes immediately. This will help detect issues. |
There was a problem hiding this comment.
This will ensure that newly created instances will just have the most current revision
Isn't it the opposite? It will make functions(revisions) available, though the instances will not be set to the latest right away, only during the maintenance.
There was a problem hiding this comment.
If we create a claim or composite with the manual policy, it will point to the most current revision at the time of creation. If there are new revisions after that point it won't switch to other revisions as long as manual is set.
From the linked Crossplane docs:
The below XR uses the Manual policy. When this policy is used the XR will select the latest CompositionRevision when it’s first created, but must manually be updated when you wish it to use another CompositionRevision.
|
|
||
| For production clusters the default revision policy will be set to manual. This will ensure that newly created instances will just have the most current revision. Test cluster will get the default policy automatic, so they get changes immediately. This will help detect issues. | ||
|
|
||
| During the very first maintenance for any given instance, the maintenance job will switch the revision policy over to automatic. It will then also set the revision to the must current using a `selector`. The policy has to be set back to automatic in order for the selector to actually apply otherwise it will still keep using the old revision. |
There was a problem hiding this comment.
| During the very first maintenance for any given instance, the maintenance job will switch the revision policy over to automatic. It will then also set the revision to the must current using a `selector`. The policy has to be set back to automatic in order for the selector to actually apply otherwise it will still keep using the old revision. | |
| During the very first maintenance for any given instance, the maintenance job will switch the revision policy over to automatic. It will then also set the revision to the most current using a `selector`. The policy has to be set back to automatic in order for the selector to actually apply otherwise it will still keep using the old revision. |
There was a problem hiding this comment.
It will then also set the revision to the most current using a
selector
Who or better what will set the selector to the necessary revision? Can you please add that here
There was a problem hiding this comment.
It references the maintenance job mentioned in the previous sentence. It's also in the flowchart. How should I write it, that it's clearer?
There was a problem hiding this comment.
I guess I just need some hands on experience :)
| === Hotfixes | ||
| It might be necessary that a hotfix has to be applied immediately to all instances. | ||
|
|
||
| To handle this an additional job will be specified in the component. This job will have a parameter which contains the explicit version that should be applied to all claims or components. |
There was a problem hiding this comment.
Can you add more about how this job is to be added? maybe in the CD GitHub pipeline where during creating a tag the pipeline understands it's a hotfix and generates the necessary job?
There was a problem hiding this comment.
This should not be automatically determined.
I'll add more how it should work.
There was a problem hiding this comment.
I've added more details how exactly this should work.
Kidswiss
force-pushed
the
adr/functionrevisions
branch
from
c143a79 to
aa4c08a
Compare
|
We should also add some more use-cases to this ADR. As from our first tech talk in the team: We should enhance it with the ability to not only to keep separate functions and revisions for the tags, but also for a list of configurable branches. So multiple branches and their functions could be rolled out at the same time on the same cluster. This will at least solve some of the bottlenecks we have with the lab. |
Summary
Checklist
change,decision,requirement/quality,requirement/functional,dependencyas they show up in the changelog