« back to all changes in this revision
Viewing changes to state/api/params/internal.go
- Committer: Tarmac
- Date: 2013-08-29 12:41:06 UTC
- mfrom: (1730.1.6 upgrader-split-api-1218256)
- Revision ID: tarmac-20130829124106-xg228w85o2qohbor
[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/
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/
added
removed
state/api/params/internal.go
