[00:41] wallyworld: fix: http://reviews.vapour.ws/r/2603/ [00:41] ty, looking [00:42] waigani: we need a test also [00:42] wallyworld: okay, I'll add that now [00:42] in general, any bug fix should be accompanied by a test [00:42] ty [00:56] wallyworld: test added [00:56] looking [00:59] wallyworld: so just so I understand the status history change: previously we didn't store the latest status in history, and now we do? and because of that, returning history would duplicate the latest? [00:59] waigani: lgtm but are there any call sites to update (see comment in review) [01:00] looking [01:00] axw: yes - william did a whole lot of refactoring there and changed how status history was recorded, but the retrieval method wasn't unit tested nor updated to match [01:01] wallyworld: ok [01:01] axw: tested live, works nicely [01:02] waigani: actually, how do we handle the "never logged in" case now in a new 1.26 install? [01:12] wallyworld: so user.LastLogin() will return a time.Time{} but the API server will still return a nil. See checkCreds func in apiserver/admin.go for example. [01:12] wallyworld: there is also a feature test to ensure we display the correct "never connected" message, e.g. TestSystemEnvironmentsCommand [01:14] wallyworld: reviewed [01:15] waigani: without being overly familar with the code, would it be better to return a NeverLoggedInError ? ie is there a record that we just should not write out during the upgrade if last login is nil [01:16] axw: thanks, looking [01:20] axw: with HistoricalUnit, I think I ran into the same issues as in the uniter work recently - too much existing code being called back into. i'll double check though if i can rework it [01:20] wallyworld: thanks [01:21] wallyworld: you're talking about the upgrade step? If user has never logged in, skip creating a lastLoginDoc? Actually, yes that makes more sense. As user.LastLogin() returns neverConnectedErr for a missing lastLoginDoc. [01:21] waigani: exactly [01:21] wallyworld: I'll redo fix [01:21] ta [01:22] i was a bit hastely with my shipit :-) [01:42] https://github.com/juju/juju/pull/3226 [01:42] here is an easy one [01:46] wallyworld: third time lucky: http://reviews.vapour.ws/r/2603/ [01:46] looking [02:48] waigani: your branch failed to merge [02:49] davechen1y: I saw. I can't see how the panics are related to my changes. I'm halfway through running all unit tests locally. [03:08] usual background test failures i'd say [03:34] davechen1y, wallyworld: fix merged. updating bug... [03:34] awesome, ty [03:58] jam: i got a surprise - i looked at juju/charm.v5 and see that there's already a Series metadata attribute which contains a single series. But I can see any charms which use it (I didn't look hard). So I think we could attempt to parse both a scalar and a list maybe and if a scalar, emit a deprecation warning and make it a single value list. What do you think? [03:58] wallyworld: it should be "serieses", clearly :) [03:59] barf [04:00] series is an irregular noun [04:00] like sheep [04:00] yes, I realize that the plural of series is series, it is just fun to be silly. [04:00] hence the smiley [04:00] indeed [04:01] wallyworld: Sounds fine to me to go with a single-or-list sort of parsing, though it probably complicates our internal structure. [04:01] i'll mark the parsing tolerant [04:01] i'll also asl eco who uses it [04:02] wallyworld: I wonder if we actually have it there because we use that spot internally to store what we cached the charm for [04:02] as in, it isn't for the data in charm's metadata file, but instead for what we store in the DB [04:02] Looking at: https://github.com/juju/charm/blob/v5/meta.go that only has "bson" notation, which means its for the DB, right? [04:02] i couldn't see any obvious usages in juju code, but will look harder [04:03] yeah, that could be right actually [04:03] makes sense [04:03] but that sure now complicates it [04:03] might have to go with "os-series" [04:04] that's what mark changed it to in the spec originally [04:05] jam: also, i need to get the resources spec moving again. are you able to schedule some time to have another look before it goes to mark? [04:05] wallyworld: so IIRC it seemed good enough before I left, but if you want me to look at it again, I can. [04:06] jam: i added stuff to the vcs and web source bits, mainly around authentication etc [04:06] i think those are well enough defined for a mvp [04:06] since i added material after you last looked, a once over would be great [04:16] jam: i looked harder at meta.go, and there is a yaml serialisation tag for Series. so seems like it can be defined in metadata.yaml [06:35] * fwereade has just discovered it's a public holiday today [06:51] * fwereade has *also* been being a terrible person and failing to look at reviews he should [06:52] axw, don't suppose you're free to take a very quick look at the uniter interactions in http://reviews.vapour.ws/r/2593/ ? [08:11] fwereade: sorry was out. I'll take a look [08:26] fwereade: seems fine, apart from growing complexity. [08:27] axw, I was mainly thinking about "how does it interact with the maltese-falcon changes" [08:59] fwereade: I see. still looks fine. [09:03] fwereade: aargh, i just made a bunch of replies to http://reviews.vapour.ws/r/2597 and reviewboard seems to have lost them all. doesn't it save replies as drafts? [09:03] rogpeppe, I thought it did [09:04] fwereade: ah, false alarm. for some reason they just weren't showing for me. [11:59] wallyworld: hey, I'm not feeling great. Since rick can't be at the meeting anyway, can we just do it tomorrow, more around 6UTC ? [12:00] jam: sure, works for me [12:00] hope you're feeling btter [12:00] thanks. I started some antibiotics today, so I expect to be doing better [12:01] we can move on resources also [12:03] wallyworld, anyone else: http://reviews.vapour.ws/r/2606/ move to using charm.v6-unstable [12:03] rogpeppe: looking [12:03] wallyworld: thanks [12:04] rogpeppe: says there are conflicts, were you aware? [12:04] wallyworld: i resolved them [12:05] wallyworld: perhaps i should take the conflict messages out of the PR description [12:05] tis ok, i now know, but yeah [12:06] wallyworld: done (well, I edited the PR description in github - i'm hoping that's sufficient) [12:06] np :-) [12:09] rogpeppe: just started looking - are all those dependencies.tsv changes deliberate? [12:09] wallyworld: yes [12:09] wallyworld: i tried to make them as minimal as possible [12:09] np, ty [12:09] wallyworld: new deps are on the latest version [12:10] rogpeppe: and the new deps has charm.v5-unstable? [12:10] wallyworld: ues [12:10] yes [12:10] not v6? [12:10] ah, no [12:10] it *should* have v6-unstable [12:10] let me check [12:11] wallyworld: looks right to me [12:12] wallyworld: uses charm.v6-unstable [12:13] rogpeppe: gopkg.in/juju/charmstore.v5-unstable git a921c6c69d74361c38a99a95d2aceec76533038d 2015-08-27T20:19:40Z [12:13] i copied that from the review board diff [12:13] wallyworld: that's charmstore, not charm [12:13] oh ffs [12:14] sorry, is late here [12:14] wallyworld: np [12:14] sigh [12:14] wallyworld: i've made that mistake several times before :) [12:20] rogpeppe: wow. so much churn. i miss python where you could update *one* file to change a dep. that's what i was refering to before in the email :-) [12:20] it's a hell of a lot to look over for a dep change. imo churn should be avoided :-) [12:21] wallyworld: yeah, i have to say i think there should be a better way. haven't found one yet though. [12:21] wallyworld: all is fun and games until you return an object from the wrong version of a lib :p [12:21] use python :-D [12:23] also maks me wonder if we've done the right thing threading charm store dependency through so many of our files [12:23] wallyworld: charm store dependency != charm dependency [12:23] s/charmstore/charm [12:23] sorry, mistyped [12:24] wallyworld: it's not that surprising - charms are at the heart of what juju does [12:25] true, was musing out loud maybe it could be encapsulated in some helpers [12:25] but probably a crap iea [12:25] just annoyed by the churn and trying to think of how to isolate it :-) [12:26] wallyworld: it would be nice if there was a way to view diffs without showing changes that were just import path changes [12:27] yeah, that would be nice [12:29] wallyworld: at least with the change from v6-unstable to v6, the change will be *entirely* automatic - you won't even need to look through the diff [12:30] true [12:33] rogpeppe: +1 but i dislike the error message changes :-) [12:34] wallyworld: thing is that now those URLs can refer to both charms and bundles [12:34] wallyworld: so "charm URL" is technically wrong [12:34] so "charm or bundle" then ? [12:34] entity has no meaning for an end user [12:36] wallyworld: yeah. i'm not keen on "entity" either [12:36] wallyworld: but "charm or bundle" seems clumsy [12:36] can it be changed? [12:36] accurate and clear [12:36] though [12:36] or even "charm/bundle not found" works [12:37] maybe not with the / as that could be confusing [12:37] but still "entity" kinda sucks [12:37] wallyworld: i'd prefer to change it in another PR if that's OK [12:38] sure, that's why i didn;t mark it a blocker, just a whine :-) [12:38] wallyworld: :) [12:38] right, i better get sleep before i confuse charm and charmstore again [12:41] hmm, if this bug https://bugs.launchpad.net/juju-core/+bug/1493016 is marked as fix-committed, why is master still blocked? http://juju.fail/ [12:41] Bug #1493016: Panic on upgrade from 1.22

[13:04] dimitern, you joining the MAAS HO? [13:12] frobware, yeah, omw [13:12] dimitern, too late. Call just dropped. :) [13:12] frobware, oh :/ too bad [13:12] dimitern, 10 minutes and you're out! [13:12] :) [13:12] frobware, I was fighting until a few minutes ago to fix my config here [13:13] dimitern, want to HO around the SubnetsAvailabilityZoneNames card? [13:13] frobware, I managed to break bash, unity, emacs and dbus with just a few edits in the wrong places :) [13:13] frobware, all fixed now though .. [13:13] dimitern, well the Emacs is obviously bad; the rest? meh... :) === coreycb` is now known as coreycb [13:14] frobware, sure, but as I need to go to the store now, how about to do it in ~30m? [13:14] dimitern, yep np [13:47] frobware, hey, I'm back [13:48] dimitern, want to use the standup HO? [13:48] frobware, joining our 1:1 HO [13:48] frobware, :) [14:01] dimitern: ping [14:13] * perrito666 returns from the mecanic and figures he chose the wrong career [14:31] perrito666: lol that is what I think every time I have to pay someone to do something for me. [14:32] natefinch: well, he had to rebuild the whole engine cooling system, Its not like I can complain [14:42] perrito666: well I'm glad the mechanic could fix you [14:42] would be a shame to have to sell you for scrap [14:45] frobware: ping [14:48] mgz: lol [15:15] voidspace, pong; in a HO with dimitern [15:27] frobware: ok [15:30] Bug #1493016 changed: Panic on upgrade from 1.22

[16:22] Bug #1493444 opened: juju upgrade from 1.24-beta2 to 1.24.5 broken [16:25] Bug #1493444 changed: juju upgrade from 1.24-beta2 to 1.24.5 broken [16:27] Could someone respond to this bug: https://bugs.launchpad.net/juju-core/+bug/1490865 [16:27] Bug #1490865: destroy-environment on an unbootstrapped MAAS environment can release all my nodes

[16:31] Bug #1493444 opened: juju upgrade from 1.24-beta2 to 1.24.5 broken [16:31] who did the status-history stuff? [16:31] what's the new way of connecting directly to mongodb on the state server? [16:31] marcoceppi: perrito666 mostly [16:32] perrito666: you around? I'm trying to figure out the API endpoint for status-history [16:33] For bug #1490865 I am interested in people's opinion [16:33] Bug #1490865: destroy-environment on an unbootstrapped MAAS environment can release all my nodes

[16:35] Is there a list of the API endpoints? or doc on that? [16:36] that bug reportedly has juju destroying nodes it didn't create [16:36] and it is reproducable [16:36] BUT it does require passing --force --yes to destroy environment on an non-existent environment. [16:39] mramm: having been bitten by this, it's a huge problem [16:39] were you bit by this recently? [16:40] I had a similar issue 10 months ago on MAAS [16:40] issue/experience [16:40] that was a separate issue IIRC [16:40] we added behavior to juju to not kill things it doesn't know about in MAAS [16:40] even if they are by the same user [16:40] ack [16:41] BUT in this case, we can't know about anything as there is no juju server to talk to [16:42] I expect that calling "destroy-environment --force --yes maas" on a non-existent environment to be dangerous [16:42] mramm: this would not be an issue were it not for the fact ever tearing down juju properly requires --force --really --super-hard [16:43] destroy-environment without flags just leaves stuff half-torn down too much of the time to do anything else... [16:44] to fix this we would need to know how to reliably differentiate juju deployed maas instances from those that are not juju deployed. [16:45] the current implication does this -- but requires an active juju state server to talk to (since it knows) [16:45] possibly we could just include maas-agent-name in the config even before we bootstrap [16:46] which isn't 100% reliable (unless we use a GUID for the name) [17:10] Bug #1493458 opened: backups restore: fails when machine number differs [17:28] Bug #1489087 changed: certificate verify failed [17:28] Bug #1490552 changed: local hostname not in /etc/hosts [17:28] marcoceppi: back, UnitStatusHistory [17:28] thanks perrito666 [17:35] marcoceppi: sorry for the delay === bdx_ is now known as bdx [18:47] perrito666: could you take a look at http://reviews.vapour.ws/r/2610/? [18:47] perrito666: it relates to one of your recent merges [18:48] ericsnow: did I remove the tests? :| [18:48] no, that seems like my patch :p did you? [18:49] perrito666: I accidentally disabled them in June [18:49] ericsnow: june? some of the things you are adding are from status-available which is fairly recent [18:49] perrito666: your recent patch would not have passed the tests on 1.25 otherwise [18:49] oh [18:49] ok [18:50] ericsnow: can it wait about 1h need to run an errand (bad day for my concentration) [18:50] perrito666: right, when you merged from 1.25 you had conflicts and appear to have removed the changes rather than fixing them [18:50] s/from 1.25/to 1.25/ [18:50] ericsnow: In the meantime, is the removal of the huge block from dimitern to begin with? [18:50] ericsnow: mm damn, ill have to review master too then, thanks for that [18:51] anyway gtg, bbl [18:51] perrito666: don't worry, I'll fix master too [19:07] you know what bugs the hell out of me? [19:07] func (c *Settings) [19:07] c? Really? [19:15] Ce-tings works in Spanish :p [19:15] Ericsnow [19:16] perrito666: yep [19:16] So the only thing troubling me is the big chunk from network being removed [19:16] perrito666: what is removed? [19:16] perrito666: keep in mind that apiserver/params/status.go has everything [19:20] Ok re reviewed the patch [19:21] Ericsnow so this patch looks as if re applying the agentversion work for tests can you expand on what happened? [19:22] And the removed chunk is http://reviews.vapour.ws/r/2610/diff/#4 [19:22] perrito666: your forward-port from 1.24 was missing several changes due to merge conflicts so I added them back in [19:23] Ahhh duh I see it now, sad [19:24] And re http://reviews.vapour.ws/r/2610/diff/#4 [19:26] jog: I will likely miss the meeting today. Are you cool with running that? [19:26] sure [19:27] I'm planning to use this sheet as a discussion point: https://docs.google.com/spreadsheets/d/1CWq1CAIYjJLetnageShXVU0-0etxAE2O0KtRgc3-D_8/edit#gid=0 [19:27] kk [19:27] Example of the various issues we see with the charm tests [19:28] The point I want to make is that there are many charm related failures that need investigation. Most of these look like charm issues (not infrastructure) [19:32] you know your tests aren't isolated enough when you change the signature of a method and find 1 place in production code that calls it, and 30 in test helpers. [19:36] * TheMue is grumpy about his current network status. from fri to sat total breakdown and today every few minutes *hmpf* [20:16] man, I hate that juju deploy can't just take config options on the command line, and that if you pass a file to --config, you have to put the charm name in the file, like mysql: option:value [20:19] ericsnow: ? [20:19] perrito666: yeah [20:19] ericsnow: sorry I was chatting on a phone, now back to the computer: "And the removed chunk is http://reviews.vapour.ws/r/2610/diff/#4" [20:20] perrito666: all that code is superflous; it was moved over to apiserver/params/status.go in June [20:21] perrito666: looks like you accidentally pulled it back in during a merge [20:21] ericsnow: then lgtm [20:21] perrito666: k [20:27] natefinch, katco: could I get a quick review of http://reviews.vapour.ws/r/2610/? [20:28] ericsnow: will review before EOD, trying to get tests passing before release standup [20:28] katco: k [20:28] Bug #1491132 changed: TestNetworkInterfaces fails [20:40] Bug #1491547 changed: [upgrade-juju] Poor user experience

[20:42] state's export_test is 443 lines long [20:43] Bug #1491547 opened: [upgrade-juju] Poor user experience

=== natefinch is now known as natefinch-afk [20:59] Bug #1491547 changed: [upgrade-juju] Poor user experience

[20:59] mm, that last one seems to be duplicated [21:02] Bug #1178312 changed: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority

[21:02] Bug #1325040 changed: juju upgrade-juju is utterly confusing

[21:02] Bug #1492241 changed: juju upgrade-juju cli doesn't provide clear feedback on action being taken

[21:05] Bug #1178312 opened: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority

[21:05] Bug #1325040 opened: juju upgrade-juju is utterly confusing

[21:05] Bug #1492241 opened: juju upgrade-juju cli doesn't provide clear feedback on action being taken

[21:08] Bug #1178312 changed: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority

[21:08] Bug #1325040 changed: juju upgrade-juju is utterly confusing

[21:08] Bug #1492241 changed: juju upgrade-juju cli doesn't provide clear feedback on action being taken

[21:32] sinzui: are you able to join standup? [22:07] wallyworld: holy shit... [22:07] wallyworld: that uniter branch is quite far reaching [22:07] it is [22:08] doc being worked on now [22:20] do all worker facades need to be nouns? [22:20] * perrito666 thinks we are being a bit exagerated with that [22:50] wallyworld got time for a quick chat? [22:51] sure [22:54] thumper: in 1:1