thoughts on priorities

[David Cheney]

> However, the Upgrader change has tentacles. At the moment, every single
> agent requires the environment secrets in order to download fresh tools
> on upgrade, and this is unacceptable. 

<strawman>What if we moved to distributing tools via PPA?</strawman>

> And, finally, the connection/task-running code inside jujud will also
> need some work to deal with those agents that are only allowed API
> connections.
> 
> On the upside, we don't actually need the internal API to cover every
> part of state. Certain tasks are trusted by necessity, either because
> they legitimately use the environment keys (Provisioner, Firewaller) or
> because they require direct state access to do their job (the API
> server, whatever putative task ends up responsible for the state server
> itself).

Watching Openstack videos today there was mention that all openstack
components communicate via an API; there are no back doors. However most
components expose two API endpoints, an admin endpoint, and a user
endpoint -- I think there is something to that wisdom.

> Happily, all these tasks are ones that we only need a few of, and can
> therefore comfortably restrict to only running on machines that are
> running state servers (and are therefore implicitly trusted regardless);
> the ones we need to scale out in a big way are also the ones that we
> want to restrict to API-only access. These are:
> 
>   * Uniter
>   * Machiner
>   * Deployer
>   * Upgrader
>   * (and the jujud code)
> 
> ...and (aside from the aforementioned changes to Uniter/Upgrader) they
> do use a somewhat restricted subset of the current state API, which I
> think will somewhat reduce the implementation burden.
> 
> I'll be going through these today to try to figure out the details a
> little more; once we have those nailed down, we'll need to figure out
> how many people can reasonably swarm on this work without treading on
> each other's toes.
> 
> However, there's another potential tentacle. The switch to API-only
> access will be, uh, challenging to pull off as a perfectly compatible
> upgrade; when we disable state access for agents on untrusted machines,
> we'll need to be certain that they all run code that can handle API-only
> access. So, we also need to be considering major-version upgrades as a
> matter of urgency; and also as a matter of simple prudence, because I
> have a lurking suspicion that sooner or later we'll hit *some* scaling
> problem that can only be resolved by a schema change, and I'd like us to
> be prepared.

I vote for doing a major version update that changes *NOTHING* except
the major version number.

> 
> If anything I've said is wrong or stupid, please let me know; otherwise,
> I would be most grateful if someone were to step up and write a
> reasonably detailed proposal for a major-upgrade model that we can
> implement in a reasonably short time. Anyone?
> 
> Cheers
> William
> 
>