thoughts on priorities

[roger peppe]

In 2 May 2013 10:09, William Reade <william.reade at canonical.com> wrote:
> 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.

There's a significant difference there though.

Currently we watch a single thing (the environment config)
for the version change. It seems like you are proposing
that every agent should be able to watch for changes to its own
tools. That seems to imply that we'd need to
set the tools individually for each agent, which means
that we need to do that all in one transaction, or we
need another agent that is responsible for running the tools
selection logic and setting the tools for each agent based
on the global version.

I suggest that the current distributed model works quite well - all
agents watch only the global current version, and then they
each run their own tools selection logic. Then we're using
a model that's basically the same as we're using now
and no agent or unlimited-size transaction is required.

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

I'm not sure how this helps. Surely the way to get around this problem
is to avoid upgrading to a version that we don't have a full set of tools
for? ISTM that that would be better by finding the current set of
machine architectures
and querying the tools to make sure that we have the right version
of the tools for all of them, before upgrading.

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

+1

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

The only way we can cut off state access is by removing the
mongo accounts or changing the passwords on them.
It seems to me that that's a thing that we could provide an API
call for - once everything has been upgraded to use the API,
the user can decide to cut off mongo access. So  I don't think we
*need* a stop-the-world major-version upgrade for this.