[Beaker-devel] More conservative removal of implicit job sharing

Nick Coghlan ncoghlan at redhat.com
Mon Aug 26 05:29:25 UTC 2013


On 08/26/2013 02:41 PM, Raymond Mancy wrote:
>> From: "Nick Coghlan" <ncoghlan at redhat.com>
>>
>> I've been pondering the removal of the old implicit job sharing model
>> from Beaker 0.15, and I'm concerned that it may break existing
>> installations in a way that won't be uncovered until a site upgrades to
>> 0.15 and their users complain about not being able to update jobs any
>> more. At the moment, the only way for installation admins to cope with
>> such complaints is to roll back to 0.14 (a non-trivial exercise).
>>
> 
> That's not quite right. The users can create the correct job permission models.
> That will fix the issue, and they will have to do that eventually anyway.

Except you can't change the permissions on old jobs that were submitted
without an associated group.

>> Yes, it's more work for us, but I really want new Beaker releases to be
>> something that users look forward to, rather than something they fear as
>> "What did they break this time?" :)
> 
> Have we actually had feedback that expresses an inability to cope with changes that
> we make within the space of a single release (or any other time frame for that matter)?
> If we're expecting people to not be able to actually change their scripts/behaviour/settings
> etc within the space of one release, then it makes perfect sense to me to keep the 
> deprecated code around longer.

It's more about ensuring people can schedule breaking changes for a time
that suits them, without necessarily coupling it to the timing of
deploying a new version of Beaker. Any breaking change runs the risk of
people needing to take time to fix things. By decoupling the "deploy new
version" and "make backwards incompatible change" events, it means
people can get the upside of the new version, while having some freedom
to schedule trials for turning off the deprecated behaviour.

> I fear it is still going to be "What did they break this time?", it's just that
> it will be said at N+2 release, rather than N+1, and all this babying inattentive/busy users
> will end up with the same result except more work for the developers, and confusion for users as 
> deprecated code is enabled/disabled halfway through a release.

Sure, breakages will still happen. If we had better data tracking for
this particular behaviour, I'd be happy to define a way to query an
existing installation to see if anyone is relying on the feature, and
when they last used it. However, that's not the case, so it's about
making sure we do it right from our side to ensure the production impact
of breaking changes is minimised, and installation administrators are
given the tools they need to migrate on their timeframe rather than ours.

The idea behind triggering the breakage by changing a setting rather
than deploying a new version is that if users complain, the response can
be to just turn the feature back on and work with the affected users to
ensure they're ready next time it gets turned off.

That is, the flow becomes one of:

- "we're planning to turn this legacy feature off on date X"
- "we turned it off"
- "no complaints, OK, all good!"

or:

- "we're planning to turn this legacy feature off on date X"
- "we turned it off"
- "arrg, the users are upset"
- "OK, we turned it back on, please let us know exactly what broke, and
we'll work with you to explain the replacement features and ensure they
cover your use case before we turn it off for good"

It also means that when we release the version that removes the feature
entirely, hopefully any existing installations will either already have
the feature turned off, or else will be able to try turning it off
*before* they deploy the new version.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane

Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)


More information about the Beaker-devel mailing list