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

🌱 tmc e2e : Split SyncerFixture #2730

Merged
merged 6 commits into from
Feb 7, 2023

Conversation

davidfestal
Copy link
Member

Summary

Split the SyncerFixture start method to provide a way to only maintain Synctarget heartbeat and import apis, without
effectively 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.

@davidfestal davidfestal force-pushed the split-SyncerFixture branch 2 times, most recently from a8933e9 to d597bdf Compare February 2, 2023 20:17
@davidfestal davidfestal changed the title 🌱 [WIP] tmc e2e : Split SyncerFixture 🌱 tmc e2e : Split SyncerFixture Feb 2, 2023
test/e2e/framework/syncer.go Outdated Show resolved Hide resolved
test/e2e/framework/syncer.go Outdated Show resolved Hide resolved
test/e2e/framework/syncer.go Outdated Show resolved Hide resolved
kcpSyncTargetInformerFactory.Start(ctx.Done())
kcpSyncTargetInformerFactory.WaitForCacheSync(ctx.Done())

go apiImporter.Start(klog.NewContext(ctx, klog.FromContext(ctx).WithValues("resources", resources)), 5*time.Second)
Copy link
Member

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(...)?

Copy link
Member

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

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

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 ?

Copy link
Member Author

@davidfestal davidfestal Feb 6, 2023

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)

Copy link
Member

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!

@davidfestal davidfestal force-pushed the split-SyncerFixture branch 4 times, most recently from e2d15f4 to ac998d9 Compare February 6, 2023 18:44
@davidfestal
Copy link
Member Author

@jmprusi Is the new ability to call StopHeartBeat() and call the StartHeartBeat() again later working for your new e2e test case ?

pkg/syncer/syncer.go Outdated Show resolved Hide resolved
test/e2e/framework/syncer.go Outdated Show resolved Hide resolved
test/e2e/framework/syncer.go Outdated Show resolved Hide resolved
// 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 {
Copy link
Member

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?

Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in commit 13a4a06

Copy link
Member

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?

Copy link
Member Author

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)
Copy link
Member

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?

Copy link
Member Author

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)

@jmprusi
Copy link
Member

jmprusi commented Feb 7, 2023

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 7, 2023
test/e2e/framework/syncer.go Outdated Show resolved Hide resolved
... 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]>
@jmprusi
Copy link
Member

jmprusi commented Feb 7, 2023

@jmprusi Is the new ability to call StopHeartBeat() and call the StartHeartBeat() again later working for your new e2e test case ?

Yes, I'm using it for testing the resource scheduler interaction with upsynced resources (#2533), and being able to stop the syncer and restart is required.

... into 2 functions: `Create()` (already exists) and
`StartSyncer()`.

Signed-off-by: David Festal <[email protected]>
@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Feb 7, 2023
test/e2e/framework/syncer.go Outdated Show resolved Hide resolved
Signed-off-by: David Festal <[email protected]>
@sttts
Copy link
Member

sttts commented Feb 7, 2023

/approve

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 7, 2023

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 7, 2023
@jmprusi
Copy link
Member

jmprusi commented Feb 7, 2023

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 7, 2023
test/e2e/framework/syncer.go Outdated Show resolved Hide resolved
Signed-off-by: David Festal <[email protected]>
@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Feb 7, 2023
@jmprusi
Copy link
Member

jmprusi commented Feb 7, 2023

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 7, 2023
@openshift-merge-robot openshift-merge-robot merged commit 74e06bb into kcp-dev:main Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants