thoughts on priorities

[roger peppe]

On 30 April 2013 09:49, William Reade <william.reade at canonical.com> wrote:
> 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. We need to be able to watch for
> tools changes, and get their URLs, via the API, and this will involve
> some careful thinking re sane design (I would very much like us to model
> it such that we can cleanly switch to a canary-capable implementation in
> the future...).

I don't think this is too hard. Currently the only thing that an
Upgrader does with respect to an Environ is to list the available
tools. We can quite easily make that capability available across
the API (or store the tools list in the state if we want to
reduce provider calls). Then all the existing logic will work as is.
We might possibly wish to change it in the future, but it seems
like a reasonable way forward to me.

> 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.

That shouldn't be hard. I did design the logic thinking that eventually
only the API server would be connecting directly to mongo, but
it's not a big change to make the state connection optional.
I do think we should eventually move towards making that
true though (universal connection to the API that is), even if for convenience
we might exempt some agents for now. I think there are potentially
quite a few advantages
to having *all* clients and agents access the state through the API.

> 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.

I'm not sure why this necessarily requires a major version upgrade.
ISTM that this can potentially be done incrementally, no?

> 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 agree totally with that though.

> 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?

I have a dusty document lurking around somewhere, I think.
I'll dig it out and give it a bit of an update.