Re: Testing Leader Election reconfiguration

On Tue, Mar 15, 2016 at 4:36 PM, Tom Barber wrote: > If I want to wait for a message is it something from the right side of > status_set for example: > https://github.com/OSBI/layer-pdi/blob/master/reactive/pdi.py#L83 > 'Configuration > has changed, restarting Carte.'?

Re: Testing Leader Election reconfiguration

Hey Cory Not even I'm that crazy! :) I have recycled the bootstrapped test environment but the only nodes running are those used in this test suite. I tried to use wait_for_messages initially and was a little confused as to what a "message" equated to (and again in those tests I got a timeout as

Re: Juju2 - MAAS Provider - Multiple Subnets per Space

John, Thanks for the swift reply. That makes total sense! Thanks! ~James On Tue, Mar 15, 2016 at 11:48 AM, John Meinel wrote: > If the subnets have logical differences, then they should be in different > spaces. > > Examples for and against: > 1) 2 network switches,

Re: Juju2 - MAAS Provider - Multiple Subnets per Space

If the subnets have logical differences, then they should be in different spaces. Examples for and against: 1) 2 network switches, one is 1GB for admin traffic, other is 10GB for storage traffic, these should be different spaces 2) 2 racks, each configured identically. each rack has 2 switches as

Juju2 - MAAS Provider - Multiple Subnets per Space

Hello Everyone, Thought I would take 2.0 for a test drive, I seem to of hit a wall trying to bind service interfaces to subnet in a space. I see spaces can be assigned like so --> juju deploy mysql --bind "server=database cluster=internal" Does this indicate that I should have an affinity

Re: Testing Leader Election reconfiguration

Tom, It's also important to note that sentry.wait() waits for *all* units in the deployment to settle for at least 30 seconds, so it might be possible that another unit that wasn't included in the status gist you provided is churning and causing it to time out. That's particularly possible if

Re: Testing Leader Election reconfiguration

On Tue, Mar 15, 2016 at 12:30 PM, Tom Barber wrote: > Hi Tim, > > Why would I need to increase the timeout when the status says all the unit > are operational? > The default wait time is 300s, with an "idle threshold" of 30s. Which means, it waits for everything to be

Re: Testing Leader Election reconfiguration

Hi Tim, Why would I need to increase the timeout when the status says all the unit are operational? The status dump came out of bundletester which said that it failed on the first wait(), I assume the status dump arrived at the same time? Bugs are allowed, the test was hacked up from a previous

Re: Testing Leader Election reconfiguration

Hey Tom, 1. You can increase the wait time until it doesn't time out: self.d.sentry.wait(timeout=1200) 2. At what point in this sequence of commands was the status dump captured? 3. There is a bug here. You take a reference to the pdi/0 info dict on line 1. It's the same object you use to get

Re: Testing Leader Election reconfiguration

Okay back here again, so my nice leader election function looks like: def test_leader_election_failover(self): unit = self.d.sentry['pdi'][0].info message = unit['workload-status'].get('message') ip = message.split(':', 1)[-1] self.d.add_unit('pdi', 2)

Re: Reactive roadmap

On Mon, Mar 14, 2016 at 2:28 PM, Cory Johns wrote: > On Tue, Mar 8, 2016 at 9:19 AM, Simon Davy wrote: >> >> 1) Is there a roadmap for reactive? A target for a stable 1.0 release, >> or similar? We'd ideally like a stable base to build from