How stable is this upgrade path? I’d like to keep on top of new releases, but 1.1.x to 1.2.0 was pretty badly broken when I tried it and I don’t really want to risk that again.
1.2.1 is mostly fixes for 1.1.x->1.2.0 issues. There is a significant issue which can make the API (and therefore UI) unresponsive when the server is busy (e.g. while upgrading several services) so you’ll want to upgrade.
1.2 was a uniquely large release and complicated upgrade because of all the work to make networking, storage, balancing and other services pluggable and the dependencies between them. We do not expect to do anything similar again.
Ah, I think what I hit was similar to William Flanagan with a combo of t2 instances, pull timeouts, and things cascading from there.
What is the safest way to upgrade? External RDS DB, obviously snapshot that first. Then kill and launch the new version, do I need to upgrade the agents as well?
Thanks.
Yes, stop server, snapshot DB, start new server. Agents are updated automatically.
1 Like
Thanks, it worked very well. Gave me a little bit of grief getting the network service upgraded from 0.0.1 to 0.0.6, but it did get settled down and upgraded (saw a few go panics in the logs of containers that were failing, but didn’t have a chance to capture them). Everything’s stable now. Spent a bit of time cleaning up the LB config and it seems to be working fine. Started adding healthchecks and once I realized how they needed to be done (and why they worked on one app but not another… check timeout of 2s was too low) it went pretty smooth.