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

CloudMap Integration tests #343

Merged
merged 2 commits into from
Aug 21, 2020
Merged

Conversation

achevuru
Copy link
Contributor

Issue #, if available:

Description of changes:
Support for CloudMap Integration tests

  • Create and Delete of a CloudMap Namespace
  • Create and Delete of a CloudMap Service
  • Register and Deregister instances. Verify Instance attributes in CloudMap vs Local instances.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Copy link

@fawadkhaliq fawadkhaliq left a comment

Choose a reason for hiding this comment

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

Thanks for adding these. Provides the foundation to add more coverage with CloudMap service discovery scenarios. Would be good to add some update/delete scenarios too

})

//Let Instances sync with CloudMap and Pod Readiness Gate go through
time.Sleep(30*time.Second)

Choose a reason for hiding this comment

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

There's no better way to check by check-wait-retry-timeout instead of just sleep here? : (
This could end up being a flaky test when we enable it in the pipeline

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I mean that is what I initially started with but it was taking at least 15s+ and for that we had to introduce a delay before we reach out to cloudMap again. So, we had to introduce a sleep in some fashion inside the retry loop and the idea was why loop if we are sleeping anyways inside the retry loop and instead go with this.

Choose a reason for hiding this comment

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

The re-try with short intervals will give you a way to move forward earlier than a fixed wait and you can choose to wait longer in the worst case scenario and tune the worst case scenario if that turns out to be a problem causing flakiness. Also allows for better maintainability having retry config in one place instead of having it passed down to every test

test/integration/virtualnode/virtualnode_test.go Outdated Show resolved Hide resolved
test/framework/resource/virtualnode/manager.go Outdated Show resolved Hide resolved
@fawadkhaliq fawadkhaliq merged commit ba896a0 into aws:master Aug 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants