-
Notifications
You must be signed in to change notification settings - Fork 382
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
🌱 tmc e2e : Split SyncerFixture #2730
🌱 tmc e2e : Split SyncerFixture #2730
Conversation
a8933e9
to
d597bdf
Compare
d597bdf
to
f7a8a44
Compare
f7a8a44
to
8a9580d
Compare
test/e2e/framework/syncer.go
Outdated
kcpSyncTargetInformerFactory.Start(ctx.Done()) | ||
kcpSyncTargetInformerFactory.WaitForCacheSync(ctx.Done()) | ||
|
||
go apiImporter.Start(klog.NewContext(ctx, klog.FromContext(ctx).WithValues("resources", resources)), 5*time.Second) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is the api importer needed in this fixture?
Could we make it optional in another StartAPIImporter
method?
I.e. something like syncerFxture.StartHeartBeat(...).StartAPIImport(...)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rule of thumb: smaller fixtures
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And a fixture without the need of a downstream cluster would be probably a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the SyncTarget to be ready to use, we would expected, in most tests, that the API compatibility check has been run and that the Accepted
(or Imcompatible
in some cases) state would be set to every resource of the synctarget.Status.SyncedResources
array.
There are very few e2e tests that don't even require this information in the SyncTarget, even maybe none.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have separated the 2 functions as you proposed:
syncerFixture.CreateAndStartHeartBeat(t).StartAPIImporter(t)
And a fixture without the need of a downstream cluster would be probably a good idea.
I'd rather keep that for later, since I don't see the need of this right now, and this would involve more coding / refactoring. Do you agree ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went a step further and allowed stopping the heatbeat and starting it again. This would be useful for some tests @jmprusi is currently writing.
So the way to create a syncer with APIImports and heatbeats is now:
syncerFixture..Create(t).StartAPIImporter(t).StartHeartBeat(t)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! worked perfectly for my PR! being able to start/stop the heartbeat allows us to test some "complex" scheduling scenarios!
e2d15f4
to
ac998d9
Compare
@jmprusi Is the new ability to call |
test/e2e/framework/syncer.go
Outdated
// and then starts a new syncer against the given upstream kcp workspace. | ||
// Whether the syncer runs in-process or deployed on a pcluster will depend | ||
// whether --pcluster-kubeconfig and --syncer-image are supplied to the test invocation. | ||
func (sf *syncerFixture) CreateAndStart(t *testing.T) *StartedSyncerFixture { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
am confused. How is a SyncTarget applied to the physical cluster?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks a whole lot like Create(t).StartSyncer(t)
, i.e. it overlaps with Create
, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, bad wording. The SyncTarget is not what is applied. But the Syncer-related resources are applied in the physical cluster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in commit 13a4a06
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks a whole lot like Create(t).StartSyncer(t), i.e. it overlaps with Create, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to have either:
syncerFixture.Create(t).StartSyncer(t)
or
syncerFixture.Create(t).StartAPIImporter(t).StartHeartBeat(t)
kcpSyncTargetInformerFactory.Start(ctx.Done()) | ||
kcpSyncTargetInformerFactory.WaitForCacheSync(ctx.Done()) | ||
|
||
go apiImporter.Start(klog.NewContext(ctx, klog.FromContext(ctx).WithValues("resources", resources)), 5*time.Second) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I asked before, maybe the comment/answer got lost: why do we have to run a full api importer, why not just set some conditions to fake the outcome?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Afair you asked about replacing the the whole logic of checking authorization for synced resources in the downstream cluster, which drives the "Authorized" condition. This logic I effectively removed, since the Authorized condition is not checked by any KCP controller.
It seems to me that the API importer is something else: It doesn't drive a direct condition, but allows the compatibility check controller, which runs on the KCP side, to set the Accepted
status on every resource of the syncTarget.syncedResources
array.
If we try to set this status manually on the SyncTarget in the test fixture, the KCP controller will very probably reset the values to incompatible until it has the downstream schemas imported.
See my previous comment: #2730 (comment)
/lgtm |
... to provide a way to only maintain heartbeat and import apis without effectively syncing. And change all the candidate tests to use the new function. Signed-off-by: David Festal <[email protected]>
Signed-off-by: David Festal <[email protected]>
... into 2 functions: `Create()` (already exists) and `StartSyncer()`. Signed-off-by: David Festal <[email protected]>
13a4a06
to
8f125fe
Compare
Signed-off-by: David Festal <[email protected]>
Signed-off-by: David Festal <[email protected]>
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sttts 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 |
/lgtm |
Signed-off-by: David Festal <[email protected]>
/lgtm |
Summary
Split the
SyncerFixture
start method to provide a way to only maintain Synctarget heartbeat and import apis, withouteffectively syncing upstream resources.
Related issue(s)
No related issue, but this is required in order to avoid conflicting with the e2e tests of the Upsyncer virtual workspace with the implementation of the Upsyncer controller (on the Syncer side) is merged.
This will also allow lighter e2e tests for all the tests that don't need effective syncing of resources to the downstream cluster.