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

Upgrade tests for KafkaSource #67

Closed
aliok opened this issue Sep 30, 2020 · 7 comments · Fixed by #524 or #563
Closed

Upgrade tests for KafkaSource #67

aliok opened this issue Sep 30, 2020 · 7 comments · Fixed by #524 or #563
Assignees

Comments

@aliok
Copy link
Member

aliok commented Sep 30, 2020

We need to implement upgrade tests for KafkaSource and KafkaBinding so that in the future we can change the storage version to v1beta1 from v1alpha1.

Best idea is to keep eventing at latest release and only changing the eventing-kafka version. We can in the future run the tests again with eventing head too.

Part of umbrella issue, #65

@aliok aliok changed the title Upgrade tests for KafkaSource v1alpha1 to v1beta1 and tooling for it Upgrade tests for KafkaSource Dec 1, 2020
@cardil
Copy link
Contributor

cardil commented Jan 28, 2021

I think this should be modeled similar to eventing and serving upgrade tests. That means upgrading to the latest version from stable and going back.

If we implement migration of API at any point it should do that in that migration period and tests should survive that.

My approach would be to adopt a new upgrade test framework for compose-ability and write some standard pre- post- assertions and continual tests.

To be able to write continual tests, I'm thinking to extend Wathola testing utility from eventing, so it will be possible to replace its sender transport from HTTP request to a Kafka client.

That would enable us to send events directly to Kafka topic, so we can configure KafkaSource or/and KafkaBinding and feed cloud events to broker (in future this broker could be backed by KafkaChannel #72), and then to the receiver for validation.

/assign

@matzew
Copy link
Contributor

matzew commented Jan 29, 2021

@cardil I agree that using the schema/model from serving/eventing is right

What do you mean with:

adopt a new upgrade

Also, extending the utils from eventing to have usage on downstream seems good 👍

@cardil
Copy link
Contributor

cardil commented Jan 29, 2021

I could also skip extending testing tools and use KafkaSink. But, KafkaSink isn't in this repo, right?

@cardil
Copy link
Contributor

cardil commented Jan 29, 2021

/area test-and-release

@knative-prow-robot
Copy link
Contributor

@cardil: The label(s) area/test-and-release cannot be applied, because the repository doesn't have them

In response to this:

/area test-and-release

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@cardil
Copy link
Contributor

cardil commented Apr 9, 2021

/reopen

@knative-prow-robot
Copy link
Contributor

@cardil: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants