We have a few references in the manual to administratively allowing HA apps, and one obscure reference in the REST API guide for how to actually enable them.
We have the PEP (http://openshift.github.io/documentation/openshift-pep-005-available-web.html) which was partially implemented.
We have the blog article (https://www.openshift.com/blogs/announcing-openshift-origin-3).
Nothing pulls it all together and describes all the workings and options in one place.
1. How does a user make their app HA? (REST API only currently)
2. When are secondary LB gears created? What controls this?
3. How does auto-scaling work?
4. How "HA" is the app? What happens if the first gear goes away?
(no auto-scaling, can't git push; also DB gears of course aren't HA yet)
5. How do requests get directed to secondary LB gears?
(via the HA alias and their router setup)
Thanks for the extra info on this BZ. I've done up a first draft, but before I show it, can I ask a few questions:
1. How "partially implemented" was the PEP from above? ie, if I use the info from that, am I going to be putting in some incorrect information?
2. Do you know if this ties into this BZ:
I can't seem to find any info on this one, but they sound _kinda_ similar.
(In reply to brice from comment #2)
> 1. How "partially implemented" was the PEP from above? ie, if I use the info
> from that, am I going to be putting in some incorrect information?
The entire routing layer is currently an implementation detail left to the administrator. There is no router component.
The PEP proposes a couple methods of making scaling decisions - the implementation leaves it to one head gear.
The PEP indicates that LB gears could route to a subset of service gears - in the implementation, all route to all.
Just a few details I noticed quickly - a lot more need to be filled in.
> 2. Do you know if this ties into this BZ:
Well, not really - that was about improvements to the scaling algorithm, but it could be a good place to talk about that too.
Some source material:
So I'm sure you're aware that this isn't a small task. And you're definitely right in that the info is currently all over the place. Unfortunately, this is because each guide is aimed at a different audience. So for this BZ specifically, I've put a small "this is what high-availability is" section in the User Guide which links the reader to already-existing sections of the Admin Guide and the Deploy Guide, then later on put in a section on making apps highly-available (which ties into another BZ from Eric ).
I know this probably is nowhere near complete, but I thought I'd let you in on the plan so far, and also what I have so far.
Please let me know if I've got any information incorrect or if you disagree with anything. I'm all ears!
I've also added a note to the bottom of the section in the Admin Guide that says "Now go to the User Guide for a procedure on how to make apps HA".
Also, I went to add a similar note to the section of the Deployment Guide where we set up a load-balancer, but it ends on the same topic in the Admin Guide (topic sharing!).
Changed some stuff in the User Guide to more reflect Luke's question on how auto-scaling works.
Luke, thanks again for the detailed review. I've rewritten the three topics you mentioned above. I think this new edit more closely aligns with the layout you are trying to suggest above.
I'm not going to go through each edit I made cos obviously I made a lot. But here's a few notes:
1. I removed a lot of the information about outages. I do think this is more for the Admin, and might even be a little to simple for an admin.
2. I kept the topic about manually scaling an app, but instead provided a link to the topic in the User Guide rather than doubling up on the into (I realized I had done that a bit here).
3. I tried to take in all your rearranging suggestions. I hope I followed them correctly.
4. Also removed the zones info. If you that info needs to be in the docs somewhere, this may be a story for another BZ.
5. I hope I clarified the curl/Rest API stuff correctly.
I think that's all. Please let me know what you think and if it requires any more edits.
Luke, if you didn't pick at things then the docs would be in a much worse state than what they currently are :)
I've taken in your suggestions. I've made a few sentence level edits, but nothing that changes the meanings (I think). I won't put this onto QA just yet, but it'd be great if you can give one final ack that this is all good.
User guide looks fine. For admin guide, I'm still not seeing the distinction between routing layer and LB layer. For reference, see Terms under http://openshift.github.io/documentation/openshift-pep-005-available-web.html
Anywhere you have "external load balancer" should really be "external routing layer" or just "routing layer". I really think it's too confusing if you refer to both as load balancing. Gears inside OSE load balance. Something external routes.
Also, step 2 should come after step 3, and probably just be combined with step 4. Setting ROUTER_HOSTNAME is only relevant if MANAGE_HA_DNS="true", and neither one makes sense until after the discussion of why a DNS entry is needed for the HA app.
Luke, you're right. I've gone through the Admin Guide and the Deployment Guide and made the distinction more clear. I'd say it's in a better state now. can I ask for a final ack?
Ah, yes. I had changed the title, but there was something fiddley going on preventing it from showing up. Fixed now.
Bullet point added. But is that all you meant? I think if you want me to add anything extra from your new blog post then a separate BZ might have to be raised titles something about "Implementing a Routing Layer". More than happy to work on that with you again, though. I don't doubt there's some good points in there we can throw in :)
Done. Well, change to:
"In order to create DNS entries for high-availability applications that point to the routing layer, OpenShift Enterprise adds either a prefix or suffix, or both, to the regular application name:"
Mainly cos CCS rules against and/or
Deleted that last bit too. I thought you had suggested that to be added. My mistake :)
Anything more suggestions?
(In reply to brice from comment #21)
> Bullet point added. But is that all you meant?
For now yes :) The info from my blog post may be germane for a future request.
> Deleted that last bit too. I thought you had suggested that to be added. My
> mistake :)
I wanted to "mention at the end that OSE still only creates the DNS record if MANAGE_HA_DNS=true." Not sure the sequence of events but the existing wording on now-step-3 seems to make that clear enough.
Thanks, +1 now!
Ok! Thanks, Luke. I'll put this onto QA
- Added info section on HA apps
- Edited existing info on Scalable apps
- Added section on making apps HA
- Edited section on Enabling Support for HA apps
- Edit of the routing layer sections to tie in with this
- Tried to make the difference between routing layer and load balancer more obvious
- updated same section from admin guide that's being shared here
*** Bug 1133631 has been marked as a duplicate of this bug. ***