thoughts on priorities

[William Reade]

On Tue, 2013-04-30 at 11:07 +0100, roger peppe wrote:
> 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.

We need a watcher, and the existing environment config watcher is
unsuitable. The upgrader will have to change to account for that, at
least; and we may as well implement that watcher to do what we
ultimately want, which is deliver the tools we actually need in the
first place.

At the moment, we have a big blind spot wrt upgrades to versions that
aren't available for a particular series/arch, and I feel like a
`Machine.WatchTools()` with `Changes() <-chan *state.Tools` fits neatly
with the (IMO) requirement that we store machine arch in state (so we
can avoid half-upgrades that don't help anyone).

Not sure how this changes the balance of the Environ interface; we may
well see more churn around there, but I'm also having resource map
thoughts that pull in a different direction; maybe we should just leave
potential half-upgrades of cross-arch/cross-series environments as a
known bug that isn't especially high priority?

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

Agreed, this approach is entirely predicated on convenience and is
intended to be a measured step in that direction.

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

A currently-released version will not be able to upgrade to a version
that has already cut off state access, will it? And we won't see
security benefits until we can do that... and, while it's not *strictly*
necessary to see immediate benefits, I don't want to keep an unnecessary
security hole open any longer than necessary.

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

I'd love to see that -- it'll be a useful foundation even if things like
the API weren't fully fleshed out originally.

Cheers
William