Description of problem: Set minimum scaling value to 2, then sent make-ha" event using rest api, no new haproxy gear is created, this sclable app does NOT become Highly Available. Version-Release number of selected component (if applicable): devenv_3973 How reproducible: Always Steps to Reproduce: 1. Set ALLOW_HA_APPLICATIONS="true" in broker config file, and enable High Availability capability to the user using oo-admin-ctl-user 2. Create a scalable app 3. Set minimum scaling value to 2, now app will have 2 gears, one is haproxy gear, anther one is web gear. $ rhc cartridge-scale php-5.3 -a scaphp53app --min 2 4. Sent a "make-ha" event using rest api Actual results: No new haproxy gear is created. This app still has 2 gears, one is haproxy gear, another one is web gear. Expected results: A new haproxy gear should be created. Additional info: If skip step 3 in the above steps, "make-ha" event will create a new haproxy gear to make this app to become Highly Available.
It is expected behaviour. What is missing is the right messaging. We do not configure haproxy on existing gears. What we do is set the application up for HA. In this case a scale-up and scale-down will be needed to make haproxy appear on two gears. In the case where min==1 on web component, we just issue a scale-up anyway. It is debatable why the platform itself can't scale-up or down. The reason we did not do it is because in some cases it could be several scale-ups/downs required. e.g. if the multiplier was set to 3 and then it is changed to 4. This would require several scale-down/ups to reach the optimum ratio. The right messaging should be either of the two, depending on what we really did: - 'We have enabled HA on your application, it will need atleast one scale-up for HA to be effective.' or, - 'We have enabled HA on your application, and also performed a scale-up for it to be effective'
(In reply to Rajat Chopra from comment #1) > It is expected behaviour. What is missing is the right messaging. > We do not configure haproxy on existing gears. What we do is set the > application up for HA. In this case a scale-up and scale-down will be needed > to make haproxy appear on two gears. > > In the case where min==1 on web component, we just issue a scale-up anyway. > > It is debatable why the platform itself can't scale-up or down. The reason > we did not do it is because in some cases it could be several > scale-ups/downs required. e.g. if the multiplier was set to 3 and then it is > changed to 4. This would require several scale-down/ups to reach the optimum > ratio. > > The right messaging should be either of the two, depending on what we really > did: > - 'We have enabled HA on your application, it will need atleast one > scale-up for HA to be effective.' or, > - 'We have enabled HA on your application, and also performed a scale-up > for it to be effective' Thanks for your clarification. Indeed when min==2, do scale-up one time, new gear will be created, and it is a haproxy gear, then my application become HA. I have a question about multiplier, I set multiplier to 2 using oo-admin-ctl-app. # oo-admin-ctl-app -c set-multiplier --multiplier 2 -a scaphp53app -l jialiu --cartridge haproxy-1.4 Then scale-up for several times, but my application only has 2 haproxy gears, looks like multiplier does not take any effect. Am I missing some thing?
You are right. And the reason is that haproxy still has the max value==1. After the min is satisfied, the max value constraints it. 'make-ha' should ideally fix the max of the cartridge. Fix put in with https://github.com/openshift/origin-server/pull/4070
The problem discussed in comment 2 and 3 has been verified on devenv_3984. Regarding the messaging discussed in comment 1, will there be any updates(fixes)? The message now is all the same when enabling ha to a scalable app that has 1 or 2 gears
closing the NeedInfo.