-
Notifications
You must be signed in to change notification settings - Fork 60
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
Azure deployment refresh enhancement #21
Conversation
/cc @blomquisg @djberg96 @bronaghs |
This pull request is not mergeable. Please rebase and repush. |
@@ -1,3 +1,5 @@ | |||
require 'azure-armrest' | |||
|
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've learned the hard way that we shouldn't do this. It causes a load ordering problem that results in the Rails cache getting cleared because of the cache_method gem:
You should be able to just use the cassettes and specs that are already there. |
Fall back to existing logic if API cannot retrieve the content
565dab2
to
4b76727
Compare
@miq-bot assign @blomquisg |
With the new API support we are now able to get templates for many stacks that we used cannot due to the lacking of uri. For this reason we see the number of total orchestration templates in the testing provider increases from 4 to 18. |
Checked commits bzwei/manageiq-providers-azure@515c9a5~...16f45d7 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
@djberg96 can you give me a 👍 on this one? |
👍 |
Use the recently added Azure API to directly get deployment template. With old API we can only retrieve deployment template if the URI is known, or if the deployment is provisioned from MangeIQ. As a result many deployments cannot recover their templates. With the newest API we now can directly get the templates without downloading from an URI or loading from ManageIQ DB. But the API does not work with old deployments, so we have to keep existing logic as the fallback method.
Simplify how to identify resources created by a deployment. We now understand the key to identify them is provisioning_operation == 'Create'. This allows us to delete quite some code and simply the logic.
It seems above improvements should be separate PRs; but they all require regenerating the VCR for refresh spec test. In addition, our recent upgrade
azure-armrest
gem version to0.5.0
also requires regenerating the VCR. The work to regenerate VCR is non-trivial, so that I would like to put them together with one commit.This PR has a dependency on ManageIQ/manageiq-gems-pending#30