-
Notifications
You must be signed in to change notification settings - Fork 208
[WIP] Inform user of the need to scale up when enabling HA on a scaled application #721
base: master
Are you sure you want to change the base?
Conversation
@abhgupta, could you review real quick? We discussed this yesterday evening. |
# If the application was already scaled, a scale up may be required. | ||
if rest_app.attributes["gear_count"] > 1 | ||
say "You may need to scale up the application to create an additional haproxy instance." | ||
end |
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.
This logic is incorrect. What we need to check is the number of gears in the web_framework group instance. The total application gears could include database gears (separate group instance) and should not be considered here.
@abhgupta made a change as recommended. Now we loop through all group instances and check if a min scaling is set above 1 for the group instance. Databases will always have a min_gears of 1, so they should essentially be ignored. LMK what you think please. |
We are holding off on this fix until we determine whether |
scaleup_needed = false | ||
gear_groups = rest_app.gear_groups | ||
gear_groups.each do |gg| | ||
scaleup_needed = true if gg.attributes["scales_from"] > 1 |
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.
If this is true (we have the ability to identify a pain point), why not just prompt the user and ask them if they would like to scale up (+1) as well?
Or give them an option to scale down (to 1 gear) and continue (enable ha)?
With this code in place to see if you should tell a user what to do, the option exsists to allow the command to scale up or down either before or after the enablement (accordingly), and not make the users do these operations as extra steps.
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.
We don't want to scale a user's application up or down during this command. It will be best to let the user know that they need to scale up, or that they can scale down and back up to get the two haproxy cartridges and remain at their same scale.
I'll modify the PR to include that extra bit of information.
…ication Bug 1256952 https://bugzilla.redhat.com/show_bug.cgi?id=1256952 When an application with more than one gear ha HA enabled, a short message will now be given stating the possible need to scale the application up to actually receive the second haproxy instance. In addition to a adding a new test, the `app_spec.rb` now requires 'net/ssh/multi' to allow the spec to be run on its own outside of the RHC spec test suite. This has been resolved.
Evaluated for online test up to f74c46d |
Online Test Results: FAILURE (https://ci.dev.openshift.redhat.com/jenkins/job/test_pull_requests/9043/) |
Bug 1256952
https://bugzilla.redhat.com/show_bug.cgi?id=1256952
When an application with more than one gear ha HA enabled, a short message will now be given stating the possible need to scale the application up to actually receive the second haproxy instance.
In addition to a adding a new test, the
app_spec.rb
now requires 'net/ssh/multi' to allow the spec to be run on its own outside of the RHC spec test suite. This has been resolved.Please don't let the branch name fool you. This is a fix for bz1256952, even though I mis-named the branch.
[test]