Re: Windows and --race tests are now gating
On 2016-07-11 11:57 AM, Mark Shuttleworth wrote: > On 11/07/16 09:26, Aaron Bentley wrote: >> But is this week really any different from any other week? Won't there >> always be something critical that has to land? > > I think it's fine to make it a plan that we will have Windows tests on > for 2.0 GA, but at the moment we're focused on all the breaking changes > to the APIs and those are not Windows-relevant. > >>> With the race tests, we got all of >>> those passing before turning on gating. We need to do the same for the >>> Windows >>> tests. We need to deactivate gating on Windows at this stage. >> But there are some tests that do pass under windows. By disabling all >> tests, we risk further regressions on Windows. Instead, you could >> disable the tests that don't pass (only when running under Windows, of >> course), and then work to fix them. > > Please do that now - leave the passing Windows tests in place and ask > the Windows teams to enable further tests which we then add to the gate. I have talked with Alexis and I'll work with her and the core team to get that done. Aaron signature.asc Description: OpenPGP digital signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Windows and --race tests are now gating
On 11/07/16 09:26, Aaron Bentley wrote: > But is this week really any different from any other week? Won't there > always be something critical that has to land? I think it's fine to make it a plan that we will have Windows tests on for 2.0 GA, but at the moment we're focused on all the breaking changes to the APIs and those are not Windows-relevant. >> With the race tests, we got all of >> those passing before turning on gating. We need to do the same for the >> Windows >> tests. We need to deactivate gating on Windows at this stage. > But there are some tests that do pass under windows. By disabling all > tests, we risk further regressions on Windows. Instead, you could > disable the tests that don't pass (only when running under Windows, of > course), and then work to fix them. Please do that now - leave the passing Windows tests in place and ask the Windows teams to enable further tests which we then add to the gate. Blocking all trunk landings with a chunk of known-failing tests is not good practice. Mark signature.asc Description: OpenPGP digital signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Updating relation info during charm upgrades
If I'm understanding you correctly, the ideal implementation for this would
be something like:
@hook('upgrade-charm')
@when('nrpe.available')
def update_checks(nrpe):
nrpe.remove_check(name='to-be-removed')
nrpe.add_check(...)
However, because of a bug / implementation detail (
https://github.com/juju-solutions/charms.reactive/issues/12), you will
currently have to inline the state lookup instead of using the @when
decorator:
from charms.reactive.relations import RelationBase
@hook('upgrade-charm')
def update_checks():
nrpe = RelationBase.from_state('nrpe.available')
if nrpe:
nrpe.remove_check(name='to-be-removed')
nrpe.add_check(...)
There was some discussion recently where Stuart gave me some insight which
I think will allow a fix for that bug (finally!) but I haven't yet had a
chance to dive in to it.
On Fri, Jul 8, 2016 at 1:11 PM, Casey Marshall wrote:
> I need some help with understanding the best way to manage relation info
> across an application's lifecycle with the reactive framework.
>
> I'll start with the situation that brings me here:
>
> I have a reactive charm that provides some fairly static relation info:
> nagios checks over the nrpe-external-master interface. This charm is
> deployed and related to the nrpe subordinate.
>
> My charm adds the nagios checks it supports when joining the relation, and
> removes them when it departs.
>
> Now, in a new version of my charm, I want to add or remove these nagios
> checks, which means I need to change the relation data. What is the best
> way to do this with the reactive framework? It would be ideal to trigger a
> "conversation" to happen, that would use the same relation state handlers I
> already have in my charm, but I'm not sure how to do this.
>
> I could see a similar situation for other interfaces. http, for example,
> where you have to set extra info in YAML strings for load-balancing with
> apache2 and haproxy. It's easy to imagine needing to change those
> parameters across charm upgrades over time.
>
> I'm trying to avoid the brute-force option, which is to destroy and re-add
> the relation. That works, but seems heavy-handed and wrong.
>
> -Casey
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Windows and --race tests are now gating
On 2016-07-10 08:34 PM, Ian Booth wrote: > Turning on gating for Windows tests before all tests were passing is premature > and is now blocking us from landing critical fixes for beta12 that we need to > release this week for inclusion into xenial. Hey, this is why I pointed out that it would block all landings. And believe me, I double-checked that this was really what Torsten wanted. But is this week really any different from any other week? Won't there always be something critical that has to land? > With the race tests, we got all of > those passing before turning on gating. We need to do the same for the Windows > tests. We need to deactivate gating on Windows at this stage. But there are some tests that do pass under windows. By disabling all tests, we risk further regressions on Windows. Instead, you could disable the tests that don't pass (only when running under Windows, of course), and then work to fix them. That way, we have a passing test suite and a way to work incrementally on fixing the Windows testing instead of requiring a flag-day coordinated change. Aaron signature.asc Description: OpenPGP digital signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
