[00:14] <wallyworld_> ericsnow: given we have stuff that needs to be landed for 1.23, would it be worth reverting the commit that is blocking landings
[00:14] <ericsnow> wallyworld_: it (systemd support) needs to be in 1.23 too, but otherwise yeah
[00:15] <wallyworld_> ok
[00:15] <ericsnow> wallyworld_: I'm hopeful I can find the problem in the next bit
[00:15] <wallyworld_> rightio
[00:15] <ericsnow> wallyworld_: it's a matter of trying to decipher the CI logs
[00:15] <wallyworld_> fun
[00:25] <davecheney> thumper: sinzu I have a replacement gccgo-go package that fixes the test problems with 1.23
[00:25] <davecheney> how/when do you want it ?
[00:41] <davecheney> a/win10
[00:42] <thumper> davecheney: alexisb has passed on the power patch to wes and they are dealing with the foundations (or whatever team) to get it landed
[00:43] <davecheney> right o
[00:43] <davecheney> just to repeat
[00:44] <davecheney> i have a replacement deb that we can install on the ci machines to get the tests passing
[01:16] <jw4> ericsnow: I think there is another presentation of the map-ordering bug in systemd service_test.go : http://paste.ubuntu.com/10508907/
[01:17] <jw4> ericsnow: I'll file an LP bug for it, but thought you'd like to know
[01:17] <ericsnow> jw4: is that different from https://bugs.launchpad.net/juju-core/+bug/1427149
[01:17] <mup> Bug #1427149: Tests require predictable map ordering <ci> <regression> <test-failure> <juju-core:In Progress by dooferlad> <https://launchpad.net/bugs/1427149>
[01:17] <ericsnow> jw4: ?
[01:17] <jw4> ericsnow: it's different presentation
[01:17] <jw4> ericsnow: not sure if it's different root cause
[01:18] <ericsnow> jw4: pretty sure it's the same cause
[01:18] <jw4> ericsnow: I think it is different because the other one seems to be related to listing services and this seems to be related to order of an emitted config file
[01:19] <ericsnow> jw4: k
[01:19] <jw4> ericsnow: but yeah, same issue with map ordering being unpredictable in newer versions of go
[01:20] <mup> Bug #1427454 was filed: systemd tests depend on map-ordering <juju-core:New> <https://launchpad.net/bugs/1427454>
[01:20] <jw4> nice new feature mup... who taught you that trick?  I started noticing it this past weekend
[01:27] <ericsnow> could I get a review on http://reviews.vapour.ws/r/1053/?
[01:28] <ericsnow> it is for unblocking CI
[01:35] <jw4> ericsnow: ungraduated, but LGTM
[01:39] <ericsnow> jw4: thanks
[01:40] <ericsnow> wallyworld_: could you take a quick look?
[01:40]  * wallyworld_ looks up
[01:41] <thumper> ericsnow: done
[01:42] <ericsnow> thumper: thanks
[01:43] <wallyworld_> ericsnow: i asked for a todo for better test coverage
[01:43] <ericsnow> wallyworld_: k
[01:44] <wallyworld_> there's a few corner cases and logic in there that would be good to test
[01:44] <wallyworld_> transient, desc == "" etc
[01:44] <ericsnow> wallyworld_: good point
[01:46] <waigani> perrito666: you're oncall reviewer right? Could you take a look please: http://reviews.vapour.ws/r/1054/
[01:46] <wallyworld_> waigani: perrito666 is or should be asleep
[01:46] <waigani> wallyworld_: well that's no excuse!
[01:47] <wallyworld_> indeed
[01:52] <ericsnow> I'll be AFK for a bit, but the merge job is running and if it lands the local-deploy-vivid-amd64 job should kick off (with hopefully successful results)
[01:54] <perrito666> waigani: thanks to the magic of timezones I am not OCR for a couple of hours more
[01:54] <waigani> perrito666: you're awake! but you shouldn't be
[01:54] <perrito666> waigani: but, I am a nice enough person and Ill review it, although you will have to explain to my wife why I am reviewing code in bed
[01:54] <waigani> perrito666: no don't seriously it's okay
[01:56] <davecheney> open question
[01:57] <davecheney> there is a page, i think somewhere on cdimages.u.c that gives you links to amazon to try any cloud image
[01:57] <davecheney> does anyone know what I am talking about
[01:57] <davecheney> does anyone remember the page
[01:58] <davecheney> https://cloud-images.ubuntu.com/vivid/current/
[01:58] <davecheney> it's this one
[02:03] <perrito666> waigani: reviewed
[02:04] <perrito666> davecheney: btw, I reviewed waigani's :p
[02:04] <waigani> perrito666: thank you, now sleep
[02:05] <perrito666> waigani: I need to wait that the soap opera my wife is watching ends (I want to know the ending now that I saw the beginning)
[02:09] <davecheney> Get:24 http://ap-southeast-2.ec2.archive.ubuntu.com/ubuntu/ vivid/main gcc-4.9 amd64 4.9.2-10ubuntu7 [5,656 kB]
[02:10] <davecheney> 35% [24 gcc-4.9 5,647 kB/5,656 kB 100%]                                                                                                                                                98.3 kB/s 8min 7s
[02:10] <davecheney> go cloud images
[02:10] <davecheney> go ... slow
[02:11] <davecheney> i've let mr howard know
[02:25]  * thumper disconnects to focus on finishing this branch by the EOD
[02:27] <ericsnow> the CI test is queued up that will verify the blocker bug is resolved
[03:02] <axw> wallyworld_: just noticed something weird in validateVolumeParams: it's setting params.Pool to the default internally. why is it doing that? that value won't surface, since the params are by-value
[03:03] <axw> the Pool should be != "" by the time validation occurs
[03:03] <wallyworld_> let me look
[03:08] <wallyworld_> axw: yeah, that looks like a mistake
[03:09] <axw> wallyworld_: nps, I'll need to make updates in this area in my branch \
[03:09] <axw> so I can fix it
[03:09] <wallyworld_> ty
[04:18] <mup> Bug #1427501 was filed: api/networker: test failure due to map ordering <juju-core:New> <https://launchpad.net/bugs/1427501>
[04:27] <mup> Bug #1427505 was filed: apiserver/networker: test failure due to map ordering <juju-core:New> <https://launchpad.net/bugs/1427505>
[04:34] <wallyworld_> axw: that maas doc, we need to provide feedback on the storage API result data at the bottom of the doc
[04:34] <axw> wallyworld_: ok
[04:34] <wallyworld_> we can take a day or so to do it
[04:35] <wallyworld_> i'll look tomorrow
[04:40] <mup> Bug #1427508 was filed: cmd/jujud/agent: test failure <juju-core:New> <https://launchpad.net/bugs/1427508>
[04:48] <mup> Bug #1346597 was filed: cannot get replset config: not authorized for query on local.system.replset <cloud-installer> <landscape> <oil> <juju-core:New> <https://launchpad.net/bugs/1346597>
[04:56] <mup> Bug #1427510 was filed: version: tests do not parse on a fresh machine <juju-core:New> <https://launchpad.net/bugs/1427510>
[05:25] <wallyworld_> axw: i've put up a charm.v4 pull request https://github.com/juju/charm/pull/88
[05:25] <axw> looking
[05:26] <axw> wallyworld_: I just proposed a rather larger change: https://github.com/juju/juju/pull/1725
[05:27] <wallyworld_> ok, np, i have to go to soccer soonish, but will look either now or when i get back
[05:31] <beisner> o/ hi, good evening!
[05:32] <beisner> fyi bug 1420049 updated
[05:32] <mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Fix Committed by dooferlad> <juju-core 1.22:Fix Released by axwalk> <https://launchpad.net/bugs/1420049>
[05:38] <wallyworld_> axw: i kinda think we should have storage properties - the spec does seem to discuss expected behaviour - perhaps jam has a view? easy to ignore if we don't need them
[05:38] <wallyworld_> s/ignore/omit
[05:39] <axw> wallyworld_: it "kinda" does, but it's not very clear. see my unanswered question in the doc
[05:40] <axw> wallyworld_: the main problem is that once they're in there, we can't easily change it
[05:40] <axw> wallyworld_: is it possible to just have the attribute ignored but not error if it's supplied ?
[05:41] <wallyworld_> yeah, i know the question. i think it's a more of a charm author hint - "i don't care if this data disappears as it's just a cache".
[05:42] <wallyworld_> sure, i=we can set the attribute but the stroage provider doesn't need to act on it if that's what yu mean
[05:42] <axw> wallyworld_: I mean, don't even expose it in the output, or define any kind of structure for it
[05:42] <axw> wallyworld_: I really can't see us using it until after phase 1
[05:43] <wallyworld_> ok, let's discuss with jam
[05:43] <jam> wallyworld_: no
[05:44] <axw> no, don't discuss with jam? ;)
[05:44] <wallyworld_> no what?
[05:44] <jam> wallyworld_: I won't discuss it. I came in late to the discussion. what's up ?
[05:45] <jam> sorry, needed a :)
[05:45] <wallyworld_> jam: the concept of torage properties eg transient
[05:45] <axw> jam: we're discussing the merits of "properties" in storage metadata
[05:45] <wallyworld_> the spec isn't 100% clear
[05:45] <wallyworld_> eg are they hints or reuirements
[05:45] <axw> jam: context: https://github.com/juju/charm/pull/88
[05:45] <wallyworld_> we're not sure whether to add support in charm metadata for them
[05:46] <wallyworld_> do we need to support transient storages for phase 1
[05:47] <jam> wallyworld_: I'm pretty sure transient was meant to be a hint, rather than a requirement
[05:47] <jam> "which providers may take to mean"
[05:48] <jam> "may" is pretty clear there
[05:48] <wallyworld_> jam: that's my take on it as well
[05:48] <axw> can the name be changed to reflect this?
[05:49] <axw> e.g. hints
[05:49] <wallyworld_> you mean the name "Properties"?
[05:49] <axw> right
[05:49]  * wallyworld_ has no opinion either way
[05:51] <jam> wallyworld_: axw: so I'd like to avoid revising the charm metadata multiple times. And while 'transient' is just a hint, others may be less of a hint. Do we need to rev the charm metadata format if we allow more entries?
[05:51] <jam> I suppose we don't if we only put hints in there.
[05:51] <jam> I don't like the word "hints" per se
[05:52] <jam> maybe its ok in a storage block
[05:52] <wallyworld_> i'm not sure about the need to revise and the new values or totally optional
[05:52] <wallyworld_> are
[05:52] <wallyworld_> so old metadata will parse just fine
[05:53] <axw> jam: we won't need to rev for additional property/hint names, I just don't think "properties" really reflects that it's optional
[05:53] <axw> and charm authors may be surprised that it doesn't do what they think it does
[05:54] <jam> axw: I believe the discussion was always around hinting, with some other ideas like fast etc. So the provider could know about high-iops storage and map the request over to that storage.
[05:55] <axw> I guess whether or not it's a hint is on the actual value, then
[05:55] <axw> okay
[05:55] <axw> wallyworld_: leave it
[05:55] <axw> I rescind
[05:55] <wallyworld_> ok
[05:56] <jam> axw: so I'm happy to bring up hints vs properties. I don't feel like I have final call, but if you want I can bring it up to Mark.
[05:56] <axw> jam: I think it's fine, as long as we're clear when describing specific properties
[05:57] <wallyworld_> jam: one other thing - trunk is blocked due to a vivid systemd issue. IMHO that's not a regression since we've never supported vivid yet and systemd work is WIP. what's your view on that?
[05:57] <wallyworld_> it will be at least 16 hours before trunk could be unblocked and we got goamz and leader eections work to land
[05:57] <wallyworld_> for 1.23
[05:57] <jam> wallyworld_: It depends. if it is a platform thing (like the gccgo bug) then I hesitate to let it block trunk (not something we can just fix)
[05:57] <jam> wallyworld_: if it is something we did that doesn't work on V then we need to fix it
[05:58] <jam> V is high priority to support
[05:58] <jam> wallyworld_: because until it is in V it won't be backported to T
[05:58] <jam> (standard Ubuntu rule is to be in the latest release and then backport it to the LTS)
[05:58] <wallyworld_> jam: well, upstart always worked on vivid with juju. but we are targetting systemd i believe, and that's what in't uire rught yet
[05:59] <wallyworld_> it seems silly to block on a new juju feature being developed for an unreleased series
[05:59] <wallyworld_> it's just something that needs fixing for sure, but to block everything on that?
[05:59] <jam> wallyworld_: blocking trunk because it is unreleasable helps us prevent adding more bugs into the system. We have a *very* bad track record here
[05:59] <jam> so I'm definitely biased towards blocking
[06:00] <jam> cause we keep breaking shit
[06:00] <jam> and then break something else by the time we fixed the last one
[06:00] <wallyworld_> sure. we block on regressions. IMO this isn't a regression
[06:00] <wallyworld_> it's a new feature that is broken
[06:00] <jam> wallyworld_: we can't release trunk because a key platform we want to support is broken
[06:00] <jam> wallyworld_: then revert it
[06:01] <wallyworld_> we may have to
[06:01] <jam> or we can't because we have to use systemd for vivid
[06:01] <wallyworld_> if we want to change the block policy to a key unreleased platform being broken, that's fine, but we need to make that clear
[06:02] <wallyworld_> since strictly speaking it's not a regression
[06:06] <jam> wallyworld_: I'm pretty sure supporting V is a must for 1.23 since it is targetted to V
[06:07] <wallyworld_> yes, agreed, but thst something is broken is not a regression
[06:07] <wallyworld_> it's a new feature that has a bug
[06:07] <wallyworld_> therefore trunk should not be blocked
[06:07] <jam> wallyworld_: support for a critical platform is enough to be a critical blocker even if it isn't a regression
[06:07] <jam> wallyworld_: if 1.23 was split of trunk already then yes, don't block trunk
[06:08] <jam> I don't think that split has been done yet
[06:08] <wallyworld_> that's a new policy decision then
[06:08] <wallyworld_> no, 1.23 not branched yet
[06:08] <wallyworld_> waiting on leader elections and goamz but these are now queued
[06:08] <jam> wallyworld_: if CI tests can't pass, then we risk breaking it for a new reason if we continue to land code.
[06:09] <jam> wallyworld_: are we *not* waiting on V support
[06:09] <wallyworld_> it's CI on one test only - vivid
[06:09] <jam> that seems like it would fall into that bucket of blocking 1.223
[06:09] <jam> 1.23
[06:10] <wallyworld_> we are waiting on it yes
[06:10] <wallyworld_> but systemd being broken seems unfortunate to block unrelated landings on
[06:10] <jam> wallyworld_: I'm certainly willing to be pragmatic, our track record has just been so bad in this area
[06:10] <wallyworld_> agreed about track record
[06:11] <jam> wallyworld_: all last december we could not release trunk because we would break Y while X was getting fixed
[06:11] <wallyworld_> here it's one CI test (vivid)
[06:11] <wallyworld_> if anything else breaks, stop the line for sure
[06:11] <wallyworld_> but it's a vivid specific (new) feature
[08:15] <TheMue> morning o/
[08:53] <dooferlad> morning o/
[08:55]  * fwereade has an old old laptop whose hdd has started making happy fun clicky noises; going out to get another; might be a little while
[09:21] <axw> :(  hdds should be seen and not heard
[09:46] <perrito666> axw: hdds should be on a hidden place of the house onnected to a storage server :p
[09:46] <perrito666> which is what I did with al the hdd I gradually replaced
[09:47] <axw> perrito666: :)
[09:47]  * axw pats his NAS
[09:48] <perrito666> axw: I actually have a thinkpad with a lot of usb adapters :p I could not get a decent nas here for less money than what a cheap car costs :p
[09:51] <TheMue> hdds shouldn't be needed, large and fast flash as ram replacement instead, non-volatile and networked
[10:39] <perrito666> minihdmi is  really bad idea
[13:54] <perrito666> mm why do we have structs that take pointers to ints?
[13:55] <TheMue> perrito666: if you want to have the possibility that they are nil
[13:55] <TheMue> perrito666: to indicate they are unset
[13:56] <TheMue> perrito666: while 0 or any other value may be valid
[13:56] <perrito666> TheMue: ah that makes sense, perhaps they are values where 0 is meaningful and cannot be used as empty
[13:56] <mgz> yeah, what themue said
[13:56] <TheMue> perrito666: exactly
[13:57] <mgz> sometimes there may actually be a better way of doing the same thing, but there are also compat issues
[13:59] <perrito666> I am seeing a rather creative solution in a review which strikes me as a bit strange but I guess there is no other way
[14:00] <fwereade> perrito666, mgz, TheMue: the general principle is "avoid in-band signalling", it's the same as the motivation for returning `, bool` even when a nil return would theoretically convey the same information
[14:01] <perrito666> fwereade: hey, wb, how was the laptop hunting?
[14:01] <fwereade> perrito666, pretty good, it even had ubuntu preinstalled
[14:01] <perrito666> fwereade: sweeet
[14:01] <TheMue> fwereade: then a struct { myInt int; myIntOK bool } could do the same ;)
[14:01] <perrito666> might I inquire what did you get?
[14:02] <fwereade> perrito666, dell latitude e6540
[14:02]  * TheMue thinks of structs with many of those fields
[14:02] <fwereade> perrito666, yay certified hardware :)
[14:02] <fwereade> TheMue, yeah, that's true, and might even be the way to go sometimes
[14:03] <fwereade> TheMue, it's a bloody hassle constructing test data with points to ints/strings
[14:03] <perrito666> this case has a function that returns an int pointer
[14:04] <TheMue> imho swift has a way to signal if a value is unset
[14:05] <fwereade> perrito666, it is hard to think of a good reason for that
[14:05]  * fwereade wonders if he wrote it himself
[14:05] <mgz> perrito666: you need to link the review now, we've been talking about it for 5 minutes
[14:06] <perrito666> http://reviews.vapour.ws/r/1049/diff/#
[14:06] <perrito666> look for uint64p
[14:07] <mgz> okay, I think that falls under the compat requirements heading
[14:08] <mgz> we could change the constraints struct to seperately record which constraints are actually set, but that's not how it's currently done
[14:11]  * fwereade is obscurely pleased to note that it is indeed all his fault
[14:12] <mgz> :)
[15:24] <ericsnow> could I get a review on http://reviews.vapour.ws/r/1056/
[15:24] <ericsnow> it unblocks CI
[15:24] <perrito666> yes you can
[15:26] <perrito666> ericsnow: may I suggest a different path of action?
[15:26] <ericsnow> perrito666: I'm all ears :)
[15:27] <perrito666> ericsnow: delete the code and before committing make a patch to revet that and save it for quick usage, but dont comment out code
[15:27] <ericsnow> perrito666: I'm fine with that
[15:28] <perrito666> ericsnow: sorry I am a pruit sometimes
[15:30] <natefinch> +1 for not committing commented-out code
[15:30] <natefinch> though if it's a very small amount with a very clear comment as to when it'll be un-commented, that's ok
[15:31] <ericsnow> natefinch: it is :)
[15:31] <ericsnow> natefinch: but that's fine
[15:31] <natefinch> ericsnow: the nice thing about that is that the diffs are easier to read than delete/readd
[15:31] <perrito666> well its not like you cannot revert that commit lateron with git
[15:32] <natefinch> ericsnow: want to do our 1 on 1, or do you want to keep cranking?  I know you've been pushing hard to get this stuff done, and I don't want to break your stride
[15:32] <ericsnow> natefinch: we can meet
[15:35] <mgz> ericsnow: do the unit tests pass with that change? I'd expect commenting out some of the linuxExecutables to fail that test that checks 'em
[15:36] <mgz> ericsnow: I do think a revert at this point to unblock is sensible - if you need help testing before landing an un-revert I'll be happy to help
[15:36] <ericsnow> mgz: the patch includes updating the test that is impacted
[15:36] <mgz> ericsnow: so it does
[15:53] <evilnickveitch> I have a painfully specific question about hook tools. As open-port can now specify a range, what if there is a conflict on _part_ of the range? i.e. I try and open 80-100 but 80 is already open: do I get 81-100 or nothing?
[15:54] <natefinch> evilnickveitch: my guess is that a conflict will mean it does nothing.
[15:54] <natefinch> evilnickveitch: but I can look at the code to know for sure
[15:55] <evilnickveitch> natefinch, if you could, that would help - i do like to be as precise as possible (its for the docs)
[16:06] <natefinch> evilnickveitch: sorry, got disconnected, did you see my last message about any overlap being a conflict?
[16:07] <evilnickveitch> natefinch, I did not, but now I know - thanks so much, it would have taken me far longer to work it out!
[16:26] <mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
[16:26] <mup> Bug #1427454 was filed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
[16:26] <mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
[16:45] <mup> Bug #1427454 was filed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
[16:45] <mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
[16:46] <mup> Bug #1427454 was filed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
[16:46] <mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
[16:46] <mup> Bug #1427454 was filed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
[16:47] <mgz> what are you up to mup...
[16:47] <mgz> naughty bot.
[16:48] <TheMue> mgz: it has a hiccup, or better, a muppup
[16:49] <mup> Bug #1427454 changed: systemd tests depend on map-ordering <intermittent-failure> <tech-debt> <test-failure> <juju-core:Incomplete> <https://launchpad.net/bugs/1427454>
[16:56] <mup> Bug #1427770 was filed: opened-ports doesn't include ports opened by other charms <juju-core:New> <https://launchpad.net/bugs/1427770>
[17:13] <ericsnow> mgz: how do I force local-deploy-vivid-amd64 to re-run?
[17:14] <mgz> on the same revision, rebuild will work
[17:15] <mgz> logged in as admin, select latest build of job, rebuild on the left
[17:15] <ericsnow> mgz: k
[17:17] <mup> Bug #1427770 changed: opened-ports doesn't include ports opened by other charms <juju-core:New> <https://launchpad.net/bugs/1427770>
[17:19] <mup> Bug #1427770 was filed: opened-ports doesn't include ports opened by other charms <juju-core:New> <https://launchpad.net/bugs/1427770>
[18:56] <niedbalski> ericsnow, i am consternated with https://github.com/juju/juju/pull/1727, just a comment
[18:57] <niedbalski> ericsnow, i was under the same impression
[18:58] <ericsnow> niedbalski: yeah, sounds like they are switching over in the next week or so
[19:07] <natefinch> ericsnow: re-stamped
[19:07] <ericsnow> natefinch: thanks
[19:19] <mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:20] <mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:21] <mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:21] <mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:21] <mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:22] <mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:22] <mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:22] <mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:23] <perrito666> sounds like mup could use a burst detection function
[19:23] <mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:23] <mup> Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:23] <mup> Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[19:24] <perrito666> really?
[19:24] <mbruzek> abentley: jog: I noticed that the reporting stuff has changed.
[19:24] <mbruzek> +1
[19:25] <jog> mbruzek, yes, URLs should still be the same.
[19:25] <mbruzek> jog: We got an AWS failure, looks like an infrastructure problem that you fixed last week.
[19:26] <mbruzek> jog: http://reports.vapour.ws/charm-tests/charm-bundle-test-parent-138/charm/charm-testing-aws/10
[19:26] <mbruzek> jog: is that the same error?
[19:27]  * jog looks
[19:31] <jog> mbruzek, looking at the consoleText log deployer appears to have run fine while installing the bundle (I applied a patch for deployer last week). This looks like an error from 'juju terminate-machine'
[19:33] <jog> mbruzek, hmm... maybe not, there's more to this log.
[19:35] <jog> mbruzek, we saw this 'watcher was stopped' Error last week but I think it's different from the issue that was patched.
[19:35] <mbruzek> jog: OK
[19:37] <mbruzek> jog Is there a way to terminate the machines?  (clean up aws) before I try again?
[19:38] <jog> mbruzek, yes I can log into the AWS console and see what's still running.
[19:40] <mbruzek> jog: I kicked off amazon again to see if it works, but then I thought to ask my question.  Feel free to kill that process if you think it will fail.
[19:40] <ericsnow> mgz: so how do I kick off local-deploy-vivid-amd64 against the latest revision?
[19:49] <jog> mbruzek, tvansteenburgh, also once bundle configs start getting uploaded to S3 we should see links in the reports (I just sent you an email on that topic).
[19:52] <tvansteenburgh> mbruzek: the env is destroyed at the start of every test, so you can just rerun - no need to manually cleanup
[19:53] <mbruzek> tvansteenburgh: OK.
[19:53] <mbruzek> tvansteenburgh: http://reports.vapour.ws/charm-tests/charm-bundle-test-parent-138/charm/charm-testing-aws/10
[19:53] <mbruzek> tvansteenburgh: Have you seen this error before
[19:55] <tvansteenburgh> this falls into the "my cloud broke, guess i'll try again" category
[19:55]  * mbruzek *sighs*
[19:55] <mbruzek> Thanks for taking a look.  next test is running, hoping that one passes
[19:55] <tvansteenburgh> it's most likely b/c we are competing for resources with the charm-bundle-test job
[19:56] <tvansteenburgh> your env probably got destroyed out from under you
[19:56] <tvansteenburgh> this will be fixed once we get RevQ using the new jobs
[19:57] <mbruzek> tvansteenburgh: ack.
[19:57] <mbruzek> tvansteenburgh: thank you
[19:57] <tvansteenburgh> planning to sort that out in CO
[20:33] <perrito666> local provider hates me
[20:34] <mup> Bug #1427840 was filed: ec2 provider unaware of c3 types in sa-east-1 <juju-core:New> <https://launchpad.net/bugs/1427840>
[21:28] <wallyworld_> katco: in another meeting, a few minutes late
[21:29] <katco> wallyworld_: k ty
[22:35] <mup> Bug #1427879 was filed: juju cannot deploy when distro-info-data gets a new series <deploy> <series> <juju-core:New> <https://launchpad.net/bugs/1427879>
[23:16] <mup> Bug #1427210 changed: 'relative path in ExecStart not valid' vivid local deploy failure <ci> <local-provider> <lxc> <regression> <juju-core:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1427210>