-
Notifications
You must be signed in to change notification settings - Fork 36
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
Adding support for ruby 3.1.x #320
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously we introduced Luan's customized neovim configuration, which had a mixed reception. This commit removes the customized configuration. I speculate that the long neovim start-up time while it downloaded plugins was the main source of disappointment. The vanilla neovim configuration does not download plugins, and is ready to go right away. Drive-bys: I removed the git submodule for `ruby-install`, used solely when creating the `bosh/vsphere-vcpi` Docker image. An earlier commit deprecated the use of the submodule, whose sole purpose appears to have been to pin `ruby-install` to a known working version. We now build the latest version of `ruby-install`, which appears to work fine.
There's a race condition: when the NSX-T Policy API Migration Mode is enabled, and a VM is added to a server pool via the Policy API and then subsequently added to server pools via the Management API, then an error, "There are more than one pool member which have the same IP address" may occur. This commit resolves the race condition by re-ordering the operations so that the VM is added to the pool via the Management API first, the Policy API, second. The error is apt to occur when there's a delay between adding the VM to the pool via the Policy API and the Management API, for example, when running the tests from a workstation with slow connection or when debugging a failed run using `pry-byebug`. When we manually inserted a 60 second sleep between the operations, the failure occurred 10/10 times. When we removed the sleep, it succeeded 4/4 times. Fixes: ``` NSXT::ApiCallError: [{"httpStatus"=>"BAD_REQUEST", "error_code"=>23613, "module_name"=>"LOAD-BALANCER", "error_message"=>"There are more than one pool member which have the same IP address 169.254.178.190 and port 80."}] ``` Signed-off-by: Brian Cunnie <bcunnie@vmware.com>
We pull the `ns_groups` list off of the VM type in order to add them to the appropriate management / policy API group list. In some places, we were adding additional groups we looked up via server pool name to that list. However, this caused mutation of the original array on the vm_type object, causing a very hard-to-diagnose test failure and potentially subtle production bugs. In this case, the mutation made the ordering of add_to_policy_groups_and_server_pools and add_to_management_groups_and_server_pools significant even though it should add the same groups regardless of order. > Failure/Error: groups = > @nsxt_policy_provider.retrieve_groups_by_name(ns_groups) unless > ns_groups.empty? > #<InstanceDouble(VSphereCloud::NSXTPolicyProvider) > (anonymous)> received unexpected message :retrieve_groups_by_name with > (["fake nsgroup 1"]) Signed-off-by: Brian Cunnie <bcunnie@vmware.com>
Signed-off-by: Brian Upton <bupton@vmware.com>
deploy-director.sh could fail but keeps executing commands. We set -e so the scripts exits instead of continuing. Signed-off-by: Daniel Felipe Ochoa <danielfelipo@vmware.com>
When trying to upgrade to newer versions of Ubuntu (which include newer versions of OpenSSL), we were encountering a failure where the private key of the certificate used with the HTTP server in tests was too short. > [2022-04-13 19:09:23] ERROR OpenSSL::SSL::SSLError: SSL_CTX_use_certificate: ee key too small > /usr/local/lib/ruby/2.6.0/webrick/server.rb:259:in `initialize' Rather than hardcode new values, we wrote a somewhat-short method to generate certificates on the fly. Now, we have just a signing CA which signs the leaf cert, and an unrelated CA which is not part of the signing chain. This makes the certificate(:failure) case more clear in that it doesn't include the signing CA needed to trust the leaf cert. [#181892208] vSphere CPI should use more secure certificates in testing (so we can upgrade Docker image's Ubuntu) Signed-off-by: Brian Upton <bupton@vmware.com>
[#181892208] vSphere CPI should use more secure certificates in testing (so we can upgrade Docker image's Ubuntu)
im currently getting a warning
this could be disabled by adding |
ramonskie
reviewed
May 2, 2022
ramonskie
approved these changes
May 2, 2022
cunnie
approved these changes
May 2, 2022
Thanks @lnguyen |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.