Skip to content
This repository has been archived by the owner on Aug 29, 2018. It is now read-only.

[WIP] Inform user of the need to scale up when enabling HA on a scaled application #721

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tiwillia
Copy link
Member

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]

@tiwillia
Copy link
Member Author

@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
Copy link
Member

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.

@tiwillia
Copy link
Member Author

@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.

@tiwillia tiwillia changed the title Inform user of the need to scale up when enabling HA on a scaled application [WIP] Inform user of the need to scale up when enabling HA on a scaled application Oct 30, 2015
@tiwillia
Copy link
Member Author

We are holding off on this fix until we determine whether rhc app-show --gears can be fixed to clearly show whether haproxy is located on a gear or not.

scaleup_needed = false
gear_groups = rest_app.gear_groups
gear_groups.each do |gg|
scaleup_needed = true if gg.attributes["scales_from"] > 1
Copy link
Contributor

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.

Copy link
Member Author

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.
@openshift-bot
Copy link

Evaluated for online test up to f74c46d

@openshift-bot
Copy link

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants