1740
|
|
|
Antonio Rosales |
10 years ago
|
|
|
1739
|
|
|
Antonio Rosales |
10 years ago
|
|
|
1738
|
|
|
Antonio Rosales |
10 years ago
|
|
|
1737
|
|
|
Roger Peppe |
10 years ago
|
|
|
1736
|
|
|
Roger Peppe |
10 years ago
|
|
|
1735
|
|
|
William Reade |
10 years ago
|
|
|
1734
|
|
|
Tim Penhey |
10 years ago
|
|
|
1733
|
|
|
Tim Penhey |
10 years ago
|
|
|
1732
|
|
|
Andrew Wilkins |
10 years ago
|
|
|
1731
|
|
[r=jameinel],[bug=1218256] upgrader: add Upgrader.DesiredVersion
The initial implementation of the API version of the Upgrader had a single API endpoint Tools() that it used to find both the desired agent version to run, and the URL to download tools matching that version. This was simple, but caused bug #1218256. Specifically, it means that the API Server needs to have provider (eg ec2) credentials in order to answer the Tools request. (So it can search the storage and see what the URL for downloading the tools is.)
As such after bootstrap (before the first connect), the Upgrader would keep bouncing as it got an error trying to determine what agent version it should run as.
This adds one more api: Upgrader.DesiredVersion(). This only returns the agent version string. Which can be served directly from the DB after bootstrap, without having to look at the provider at all.
And even beyond the first bootstrap, the current implementation of WatchAPIVersion is very naive and will trigger a probe on any change to EnvironConfig. At present that means it also triggers a listing of all Storage buckets to find the tools that will match for that agent. With the new implementation, it only provokes a DesiredVersion() call which is relatively small and doesn't talk to a 3rd party data source.
This isn't strictly backwards compatible. If we upgrade a machine-1 agent before upgrading the machine-0 agent, machine-1 will keep bouncing until machine-0 has finished upgrading and has the new API available. That was already true of upgrading from 1.12 to 1.13.x, so we haven't made the upgrade-to-1.14 story any worse. (Agents will still notice they have to upgrade, and start trying to upgrade, they will just keep bouncing after the upgrade until machine-0 finishes its upgrade.)
We *could* do something where if DesiredVersion can't be called, we fall back to Tools and if that fails we fall back to direct DB access. But I don't think it is worth spending the time on that code path right now.
https://codereview.appspot.com/13380043/
|
John Arbash Meinel |
10 years ago
|
|
|
1730
|
|
|
Gavin Panella |
10 years ago
|
|
|
1729
|
|
|
Roger Peppe |
10 years ago
|
|
|
1728
|
|
|
Dave Cheney |
10 years ago
|
|
|
1727
|
|
|
Roger Peppe |
10 years ago
|
|
|
1726
|
|
|
Roger Peppe |
10 years ago
|
|
|
1725
|
|
|
Frank Mueller |
10 years ago
|
|
|
1724
|
|
|
Roger Peppe |
10 years ago
|
|
|
1723
|
|
|
John Arbash Meinel |
10 years ago
|
|
|
1722
|
|
|
John Arbash Meinel |
10 years ago
|
|
|
1721
|
|
|
John Arbash Meinel |
10 years ago
|
|
|