feat: create tiertemplaterevision for each tiertemplate #1103
Conversation
mfrancisc
requested review from
MatousJobanek,
xcoulon,
alexeykazakov,
rajivnathan and
ranakan19
as code owners
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
Co-authored-by: Matous Jobanek <mjobanek@redhat.com>
There was a problem hiding this comment.
Looks great 👍 Thanks a lot for the extra changes
just consider dropping the check for the conflict as mentioned in my last comment #1103 (comment)
I see that you just did that :-)
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fbm3307, MatousJobanek, mfrancisc The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
from the TTR resource: it doesn't look like the delete would be actually called for this |
@MatousJobanek thanks for pointing this out. I'm looking at it, seems like the cleanup is buggy ? But most of the time works 🤔 |
It's strange because that is actually the custom NSTemplateTier I create here with cleanup https://github.com/codeready-toolchain/toolchain-e2e/pull/1061/files#diff-d1f261f3430b9095a3c1639d087ee7fdb0c4a33756c21552ed0a53095c7d9326R412 and the deletion should be triggered here https://github.com/codeready-toolchain/toolchain-e2e/pull/1061/files#diff-9f3717e8440a5df617b514735733d446cd593f05131365e355488105d9f0aa91R115 |
|
this one looks more like infra/rgsvc glitch : /retest |
| tierTemplatesRefs := []string{ | ||
| "base1ns-admin-123456new", "base1ns-clusterresources-123456new", "base1ns-code-123456new", "base1ns-dev-123456new", "base1ns-edit-123456new", "base1ns-stage-123456new", "base1ns-viewer-123456new", | ||
| } | ||
| tiertest.AssertThatNSTemplateTier(t, "base1ns", cl). |
There was a problem hiding this comment.
This assertion is repeated in every subtest here. Is that necessary? If that's part of a setup that is common to all the subtests then it should probably be separated out into its own function.
There was a problem hiding this comment.
This assertion is repeated in every subtest here. Is that necessary?
Yes, the whole point of the "revisions management" management is to that that the NSTemplateTier.Status.Revisons field is populated as expected, and this is the assertion that does that. After each reconcile it verifies that the field contains the expected values.
If that's part of a setup that is common to all the subtests then it should probably be separated out into its own function.
It is not a setup, it's part of the //then of each test. But maybe I'm not understanding exactly what do you mean with: it should probably be separated out into its own function.
There was a problem hiding this comment.
My point here is that the the setup, i.e. tierTemplates := initTierTemplates(t, nil, base1nsTier.Name) is very similar in many tests, as is the prepareReconcile call, the actual call to Reconcile and the subsequent "sanity checks" up until this assertion.
So I wonder if there is an opportuntity to a) test all of that just once (maybe the slight changes in the "circumstances" in the different test cases don't warrant that) and/or b) to put all that code into a function that would be called from the testcases to make them shorter and hopefully more readable.
|
/retest infra |
# Conflicts: # go.mod # go.sum
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1103 +/- ##
==========================================
+ Coverage 79.16% 79.70% +0.54%
==========================================
Files 78 79 +1
Lines 7814 8027 +213
==========================================
+ Hits 6186 6398 +212
+ Misses 1449 1445 -4
- Partials 179 184 +5
|
This PR introduces creation of TierTemplateRevision CRs for each TierTemplate, as soon as this is merged we should not see any TTR, we will start seeing those in host namespace only when we populate TierTemplate.Spec.TemplateObjects field.
With the current logic the TTRs are created only when there is a new TierTemplate ( thus one per TierTemplate ) with the TierTemplate.Spec.TemplateObjects field populated. The TTRs are not used yet, thus they will not guide the creation/update/deletion of user namespace content.
In follow up PRs we will introduce comparison between TierTemplate and TierTemplateRevision and usage of TierTemplateRevisions for driving space provisioning.
Jira: https://issues.redhat.com/browse/KUBESAW-146
Paired with: codeready-toolchain/toolchain-e2e#1061