Notes from Scale testing

[William Reade]

On Wed, Oct 30, 2013 at 8:15 AM, John Arbash Meinel
<john at arbash-meinel.com>wrote:

> >> Just to be clear for other readers (wasn't clear to me without
> >> checking the src)  this isn't the agent resolving the api server
> >> address from provider-state which would mean provider credentials
> >> available to each agent, but each agent periodically requesting
> >> via the api the address of the api servers. So the cache here is
> >> on the api server.
>
> The cache does need to be either in the DB or on the API server. The
> trigger is that running a hook includes the API Addresses in the hook
> context. So every hook triggers a call to API Addresses (not sure if
> hooks fired in sequence cache the state between calls).
>

The unit doesn't cache that information, indeed; and it's information that
*does* exist in the db, now, but watching it reliably is not currently
possible. If we had a DB cache of state servers -- or even just a direct
cache of their addresses -- it would be pretty simple to fix; and we'll
need *that* for the HA work, so we should prefer that approach over hacking
in something unreliable at the API level.

And that triggers the API server to make a request from EC2.
>

We should be a little bit wary of not caching simplestreams requests, too.
The impact should be much lower than in the previous scheme, but I think it
could still be a problem for both upgrader and provisioner in certain
environments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20131031/696e8766/attachment.html>