[00:00] * axw goes to do school pickup [00:00] err [00:00] dropoff [00:31] wallyworld: is the juju trunk tagged for each 'beta release', i.e. if I wanted to build a binary for juju-beta11 etc. can I check out a tag? [00:31] yes [00:31] QA does that, i'm not sure what the tags are called exactly [00:31] wallyworld: cheers, I'll figure it out [00:32] wallyworld: just pushing update to list-users [00:32] ok [00:33] wallyworld: http://reviews.vapour.ws/r/5670/diff/# [00:33] wallyworld: `juju list-users some-model` now also shows logged in user with * (and green) [00:34] great [00:34] wallyworld: I also changed the output to better match list-users [00:34] menn0: we don't support arch on azure. did you get the right line number? [00:34] however we don't have date-created returned from the server [00:34] axw: the line number might be different in my checkout [00:34] line 901 is something else entirely [00:34] hang on [00:35] axw: https://github.com/juju/juju/blob/master/provider/azure/environ.go#L834 [00:36] menn0: so if we separated series from kernel, I'd just be checking "is it linux" there [00:36] menn0: could you just change it to GenericLinux please? [00:36] menn0: actually [00:37] menn0: just drop it [00:37] menn0: if we were to support something server side, "generic" wouldn't be helpful [00:37] axw: that's what i'm thinking [00:37] I'll just need to grow the list as we add it [00:37] axw: this is about the instance's series AFAICS [00:37] menn0: yeah it is, but the code there only cares that it's linux - not which distro [00:38] menn0: but "generic linux" isn't going to apply to anythign we actually support server-side [00:38] axw: no it won't [00:38] axw: and Arch won't work either without further support elsewhere [00:38] menn0: indeed [00:39] * axw bbs [00:43] thumper: i asked for the deleted feature test to be added back, and menn0 was naughty for not requesting Qa steps be done [00:54] axw: ping when you're back [00:54] wallyworld: pong [00:56] axw: with credential parsing. the cred name can have "_" in it. so 2 options. one is to use "__" as the separator for the parts. the other is to retain the use of "_" and instead of strings.Replace(s, "__", "/", -1) just look for the first 2 "_" in the string. but the latter might get confusing to read [00:57] the former also allows for __ in the use rname [00:57] bah, _ [00:57] fred_bloggs@local [00:57] for example [00:58] wallyworld: I was thinking that we'd just add escape sequences [00:58] wallyworld: e.g. use URL encoding [00:59] yeah could do, i was going for something human readable easily [00:59] wallyworld: then the user can use whatever characters they want in the cred name [00:59] wallyworld: well, most things will still be unescaped [00:59] but yeah i can escape [01:16] veebers: CI seems unhappy: http://juju-ci.vapour.ws:8080/job/github-merge-juju/9231/console [01:16] merge job anyway [01:17] * veebers looks [01:22] axw: I think I see what was wrong. I've just fired that off now and will watch it [01:36] veebers: thanks [01:39] wallyworld: back [01:39] I didn't show QA, but did do it [01:39] ok [01:39] menn0 reviewed it when it was just removal [01:39] you need to add it to PR :-) [01:40] that's another thing about RB - it has a QA section [01:40] gh doesn't [01:40] did just [01:46] axw: that went through that time [01:46] veebers: thanks for your help [01:49] nw [01:50] wallyworld: how do I add credentials? [01:50] is there a command for it? [01:50] * thumper needs coffee [01:50] juju add-credential [01:50] juju autoload-credentials [01:51] ah... I had a trailing s [01:51] there's 2 commands :-) [01:53] wallyworld: I can have a quick HO to discuss tools selection [01:53] ? [01:53] can I [01:53] brain not functioning [01:53] menn0: sure, give me a couple of minutes [01:53] actually, I might be a while [02:00] axw: here's that credentials change https://github.com/juju/names/pull/73 [02:00] menn0: ping when you are ready [02:07] wallyworld: how do we set model config now? [02:08] set-model-config has gone [02:08] juju config doesn't look like it does it [02:08] * wallyworld considers pointing thumper to the relse notes [02:08] juju model-config foo=bar [02:08] foo=bar [02:08] how about adding model-config to see also of config? [02:09] can do [02:10] oh ffs [02:10] why is my tab completion broken? [02:10] who knows bash bollocks? [02:10] juju control_juju_complete_2_0: command not found [02:13] who wants good news? [02:13] ha in gce seems fine [02:17] thumper: when you kill the master [02:17] .,? [02:17] ? [02:17] wheb i tried it today it didn't work [02:19] rick_h_: see the bug, added output [02:19] it all works [02:20] hang on... [02:20] when you say "kill the master" what do you mean? [02:20] I ssh'ed to the machine and stopped the agent [02:23] wallyworld: reviewed on gh. I'm a little concerned that as we go along, we'll want to grow the allowed characters. I'd rather nip it in the bud and use URL query encoding [02:23] axw: agreed [02:23] bah gh :-( [02:24] ok, can change encoding [02:26] so where's the Fixed button once an issue is fixed on gh? [02:30] rick_h_: it is possible that you hit the edge case of attempting to connect to the agent while it was busy thinking about who the leader is [02:30] it seems that mongo either decides very quickly, or in two minutes [02:36] wallyworld: ok, are you around? [02:36] yep [02:36] wallyworld: stand up hangout? [02:36] standup works [02:40] # github.com/juju/juju/state/backups [02:40] state/backups/restore_test.go:123: not enough arguments in call to setAgentAddressScript [02:40] wallyworld: ^^^ [02:40] that is from the ci failure [02:41] thumper: that's perrito666's work [02:41] i can let him know [02:41] how did it get in? [02:43] nfi i didn't review it [02:43] I mean land at all... [02:43] is it os specific? [02:45] might be os specific [02:45] is this a windows test failure? [02:49] natefinch: don't suppose you're awake and around? [02:54] wallyworld: when I use an older beta (either 11 or 14 in this case) I see this message and a panic, any idea what's going wrong? http://pastebin.ubuntu.com/23180523/ [02:55] wallyworld: no. it isn't [02:56] veebers: haven't seen that message, are you running a snap? [02:56] wallyworld: no, this is a juju binary from a deb that I pulled from a pervious run [02:56] thumper: in that case not sure sorry, i am not across the latest restore code that was just done [02:58] veebers: what are you doing? bootstrap? [03:07] wallyworld: huzzah! I just hacked in the relaxing of the OS comparison and I now have a fedora client bootstrapping a xenial controller on AWS [03:07] awesome [03:08] axw: here now [03:08] natefinch: just wondering if you have a personal Azure account? [03:08] axw: yeah [03:09] natefinch: ok. I don't need anything yet, but will need someone to test out some changes I'm making. I'll poke you when it's ready - probably not till tomorrow [03:09] axw: cool [03:15] natefinch: if you're actually working, I'd appreciate a review on this: https://github.com/juju/juju/pull/6249 [03:17] axw: heh ok [03:29] wallyworld: sorry was distracted by the merge bot stuff; No this is after bootstrap, but I'm doing a couple of odd things as I'm installing stuff on the controller to collect system stats. I'll try get some proper information shortly [03:30] veebers: but this is all from beta15 or whatever right, you are not mixing betas? [03:30] you know that betas are not compatibile with each other [03:31] wallyworld: no, this is all fresh bootstrap et. al from the same binary (and juju version) [03:31] wallyworld: you know you haven't pushed your change? [03:32] let me check [03:32] damn for got -f [03:33] veebers: i haven't seen that message, but a quick grep of the code suggestions something with migrations, but not sure [03:34] wallyworld: ok, I'll have another go at it, possible that I'm doing something screwy (although that would be surprising) [03:35] veebers: probs not your fault, i just haven't seen that message before [03:35] you do need to ensure it's a clean slate though [03:47] axw: are we trying out github reviews? [03:48] natefinch: I've been using it [03:48] natefinch: and I'm happy for you to review my code using it [03:53] wallyworld or thumper: https://github.com/juju/utils/pull/237 [03:53] * thumper looks [03:59] axw_: looks like we have a revoked attribute on cloud.Credential but it's not saved anywhere yet [04:00] menn0: review done [04:00] axw_: reviewed [04:00] wallyworld: yep - didn't you add that? :) [04:00] natefinch: thanks [04:00] axw_: oh, I suppose I should run the QA tests [04:01] axw_: can't recall now. but i'll add it to the mongo doc [04:01] natefinch: if you like. I did run them myself [04:02] thumper: I replied to your comment [04:02] ok to merge? [04:02] ah I see you've already approved [04:02] yep [04:02] axw_: this seems straight forward enough. I'd rather not right now, given how slow azure is and how late it is for me. [04:03] natefinch: yep, I think it's fine - thanks [04:03] thumper: do you know if the bot merges for juju/utils or is it manual? [04:04] * thumper looks [04:04] bot [04:05] menn0: look for the github-merge-juju-* jobs http://juju-ci.vapour.ws:8080/view/Juju%20Ecosystem/ [04:05] thumper: of course. [04:05] it just took a while so I was beginning to wondering [04:05] wonder [04:18] axw_: if you get time later, here's a small pr that adds a watcher for a specific credential tag to state http://reviews.vapour.ws/r/5690/ [04:18] axw_: wallyworld:veebers: i think i know why my PR failed some tests - not on images side (have it too engrained that simplestreams is images and gui) but on tools [04:18] menn0: btw, figured out why hardwarecharacteristics has json tags, at least : the API [04:19] when stream is pulled for tools metadata, I *think* sometimes it causes confusion.. investigating [04:19] natefinch: a bit ick that a struct that lives there is used directly for the API [04:19] natefinch: the yaml tags aren't used though? [04:20] menn0: not that I can tell. I didn't look too deeply into that part, once I realized at least one of the tags was used. We notably do not use that to serialize the values to yaml, since we just serialize the whole struct as that one line string. [04:21] yep [04:22] axw_: wallyworld: actually, no cannot be as tool sections ignores resolve info anyway... [04:37] axw_: thank you, doing the facade bits after lunch [04:37] wallyworld: np [04:37] menn0, wallyworld: I updated http://reviews.vapour.ws/r/5656/ ... I eneded up doing a wholesale find and replace for cpu-cores, since some tests were using the wrong one to check the output, and it was easier to just change everything than try to only fix the exact right ones that were failing. [04:38] natefinch: i'm about to do a kid pickup but I can look afterwards [04:38] menn0: I'm going to bed, no rush :) [04:39] natefinch: haven't looked yet, but using "core" everywhere sounds good to me. [04:39] we just handle the cpu-ocres when doing the deprecation [04:40] yep [05:13] wallyworld: oh, so it seems that panic is releated to trying to deploy a bundle, in this case: cs:~landscape/bundle/landscape-scalable [05:13] that makes more sense [05:13] it seems like it's trying to get a snap or something from the edge channel [05:14] or a charm [05:14] wallyworld: any idea if there is a fix or a work around? :-\ If it's due to a newer bundle/charm can I force a previous version? [05:14] wallyworld: ah that makes sense [05:14] don'tknow off hand, i'd have to look inside the bundle to see what the issu eis [05:15] Interesting. I imagine there is something in place or that there is a branch for 1.25 as I was able to deploy it with 1.25 (although that uses quickstart and a slightly different uri scheme, assuming I've got that right) [05:45] wallyworld: who would be a good person to query re: my charm/panic question? I would love to run it with a previous beta, but don't want to eat your your limited time [05:46] veebers: um, not sure, any juju dev really. you'd need to start by looking inside the bundle. i'd love to help but i have so much to do before tomorrow when i leave [05:46] wallyworld: ack, understood :-) [06:13] axw, anastasiamac_ would you have a moment to help me with this charm? I'm wanting to deploy it with an older juju (i.e. beta14 and beta11) to get some performance details, but it causes a panic === frankban|afk is now known as frankban [06:33] anastasiamac_: this is a pastebin of what I see when I try deploy using beta11 or beta14: https://pastebin.canonical.com/165624/ [06:34] like wallyworld mentioned, it looks like something snap related [06:35] yeah and it's coming from charmrepo.v2-unstable.. i woner who knows much about charmrepo [06:35] axw_: : wallyworld: urulama ^^ [06:35] wonder* [06:36] anastasiamac_: fyi for beta14 the commit for charmrepo in dependancies.trv is 6e6733987fb03100f30e494cc1134351fe4a593b [06:36] old clients can't deal with charms in channels other than stable [06:36] veebers: ans since master tip is 73c1113f7ddee0306f4b3c19773d35a3f153c04a something might have changed... [06:37] urulama: \o/ [06:37] veebers: any particualr reason why u r interested in beta 11/14? [06:37] the way core was written, if they see anything other then development (deprecated) or stable, they'll panic [06:37] ah ok. urulama is there a 'stable' version of cs:~landscape/bundle/landscape-scalable> [06:37] veebers: you need beta 16+ [06:37] anastasiamac_: I'm wanting to compare data of runs (performance comparison) [06:37] veebers: my hero \o/ thank you :D [06:37] veebers: there is, the thing is ... if it's in two channels (one of them edge), client will panic [06:38] urulama: ah right, which is what I'm seeing here [06:38] breaking changes all the way for betas :) [06:38] urulama: thanks for clarifying that :-) [06:38] veebers: np [06:38] urulama: I take it there is no way to deploy that bundle with an older beta? [06:38] veebers: sorry for the great experience :) [06:39] urulama: heh [06:39] veebers: directly from store, no. dl it to disk and deploy as local [06:40] urulama: oh interesting. So I can just grab the .zip from the store and use that? [06:41] veebers: in case of bundles, you can use bundle.yaml only ... however, i suspect landscape charms will be both channels as well and will rewquire same local download, therefore changes to bundle.yaml [06:42] veebers: but yes, you can always grab the zip and do local deploys [06:43] urulama: ah right, you're suggesting that I need to download the charms locally as well and update the bundle.yaml file to reflect that? [06:43] veebers: yeah [06:43] veebers: if possible, upgrading to beta18 could be faster :D [06:43] urulama: cool, thanks :-) [06:43] urulama: hah, I want to get data from previous versions to compare a couple of things [07:12] wallyworld, axw_: Are either of you around and available for some fun debugging? [07:12] huwshimi: depends :-) [07:13] haha [07:13] wallyworld: you know you love our bug reports :) [07:14] wallyworld: one sec while I write out the issue :) [07:14] * wallyworld can't wait [07:15] http://www.reactiongifs.com/r/2013/07/happy-dance-.gif [07:38] Nothing beats waking up after only 4hs sleep to discover your commit broke CI [07:39] perrito666: not your fault, bot was broken [07:43] axw_: ping [07:44] wallyworld: pong [07:44] axw_: how busy are you? [07:44] i have a bug [07:44] bug 1623808 [07:44] Bug #1623808: CreateModel can't find existing creds [07:44] wallyworld: fairly... [07:44] ok, [07:44] * axw_ looks [07:44] i see if i can get to it [07:45] axw_: recall in my PR today i messed with the code to look up a credential; i ran into this same issue [07:45] hrm, ok [07:45] i'll see if i can get to it later tonight [07:45] wallyworld: possibly somewhere along the line we're not using the canonical user name [07:45] e.g. being persisted without the @local [07:45] yeha, that what it seems like [07:46] i'll have dinner, propose ny current pr, and come back to look [07:46] wallyworld, axw_: sorry [07:47] huwshimi: what for? finding a bug in our code? [07:47] beyyer to find it now [07:47] wallyworld: And making you work late [07:47] it's our own fault [07:47] if the bug weren't there, nothing to fix [07:47] wallyworld: And then what would you do with your evening?! [07:47] drink! [07:48] and shit, i have got to fill in the census tonight, been threatened with a fine :-( [07:48] wallyworld: Exciting times [07:48] wallyworld: you should behave in public, don't yell at people or scare they away ... not all of them are programmers! [07:48] indeed. i need to make up some fake details for them [07:49] urulama: who did i yell at? [07:49] wallyworld: just read you've been threatened with a fine :) [07:50] urulama: by the government for not filling in the census [07:50] heh, why so serious? ;) [07:50] i don't want to give them my data [07:50] stress :-) [07:54] Bug #1623811 opened: locally updated credentials not uploaded to controller [07:54] Bug #1623814 opened: Multiple local providers all write to the same all-machines.log [08:06] Bug #1623811 changed: locally updated credentials not uploaded to controller [08:15] Bug #1623811 opened: locally updated credentials not uploaded to controller [08:21] Bug #1623811 changed: locally updated credentials not uploaded to controller [08:45] wallyworld: looking at bug 1584193 - just want to confirm the final state [08:45] Bug #1584193: juju deploy is in a different form than jujucharms.com <2.0> [09:06] Bug #1623814 changed: Multiple local providers all write to the same all-machines.log [09:34] urulama: ping? [09:34] babbageclunk: you rang? [09:34] urulama: Hi - I'm working on bug 1584193 - just want to confirm the final state [09:35] Bug #1584193: juju deploy is in a different form than jujucharms.com <2.0> [09:35] babbageclunk: still using cs:~ format only [09:36] urulama: That's the current required bundle url format? [09:37] babbageclunk: that's about URL format, not bundle format (as in content of .json) [09:37] sorry .yaml :D [09:37] urulama: And we want to accept :user/:name/:series/:revision (no cs:), where everything except name is optional? [09:38] babbageclunk: we'd like to accept /u/:user/:name/:series/:revisions but don't currently [09:39] urulama: I guess what I'm asking is should juju be super-tolerant for all of the historical formats as well as the new ones? [09:40] babbageclunk: yeah, if you break cs:~ format, all the bundles are broken [09:40] babbageclunk: we wouldn't want to do that :) [09:42] urulama: so we want to add the new format for the URL (with and without /u/), as well as all of the others that are currently handled? [09:42] (I mean, as well as keep all of the others...) [09:43] babbageclunk: looking at comment #3 from Rick, looks like it, yes [09:44] urulama: Ok, thanks - I think I get it now. I'm going to start adding test cases. [09:44] babbageclunk: i'd double check, but i don't think /u/ is needed in charms [09:44] babbageclunk: plan to do it for RC? [09:45] urulama: Yeah, dropping /u/ is how I'd interpreted your comment (#5) [09:45] urulama: Hopefully (as long as no surprises today). [09:47] babbageclunk: means you need a list of series to verify if second or third parameter in URL is a revision :-/ [09:47] as in user/mysql/xenial/1 or mysql/xenial/1 vs user/mysql [09:48] urulama: Isn't revision always a number while series never is? [09:48] urulama: Oh, you mean user/name vs name/series? [09:48] babbageclunk: sorry, s/revision/series [09:48] babbageclunk: yeah [09:49] urulama: do we have a list like that anywhere else? [09:49] babbageclunk: i think it's in charmrepo [09:50] urulama: cool, thanks [09:56] babbageclunk: it's not in charmrepo [09:56] babbageclunk: we have it in charm store code, but not sure where it is on juju client side [09:56] urulama: No, I hadn't been able to spot it there. Hmm. [10:01] babbageclunk: what you need is something like this https://github.com/juju/charmstore/blob/v5-unstable/internal/series/series.go#L37 but probably best to put in https://github.com/juju/charm/tree/v6-unstable [10:01] and then we start using it as single source of truth for core and charm store [10:01] urulama: sounds good [10:20] babbageclunk: sorry, missed ping [10:22] axw_: if you get a chance later, here's a fix for that crederntials issue. i'd like a second opinion on the approach. i've validated that it solves the issue i found before when adding the new watcher code (even though i've retained the altered apporach from the watcher pr). i can't test if it fixes the gui issue but it should given the mode of failure i saw with my test code from previously http://reviews.vapour.ws/r/5692/ [10:27] axw_: from what i can see, the root of the issue is that if you have a credential tag made from a user name "fred", and the CloudCredentials call makes a map keyed on tag made from "fred@local", then the map look up can fail even though for both tags, tag.Canonical() is the same [10:30] wallyworld: no worries, urulama's been giving me some background [10:30] rightio [10:31] he can give better info than me on that topic [10:31] i'd have to go look up a bunch of stuff [10:43] urulama, wallyworld - how does the development channel fit into url format? [10:44] babbageclunk: i don't think it does from memory; i think it's a separate search param, but not 100% [10:48] wallyworld: the reason I ask is that there are some examples in the tests in https://github.com/juju/charm/blob/v6-unstable/url_test.go#L302 [10:50] babbageclunk: yeah, you'll need to ask urulama; i've not been involved in that side of it [11:04] urulama: the tests for charm.v6-unstable/url.go include an "exact" url - I guess this is something that gets echoed back to the user at some point? Presumably we want those to be canonicalised into the new format, to fit with docs/examples? [12:30] rick_h_: you about? [12:33] it might be a little early for him still, given the flight back [12:35] mgz: he just approved my travel req [12:35] in which case he is nuts :) [12:49] since I started asking DNS questions on the Azure slack channel.... and now there's a multi-region DNS outgage... :) [12:50] https://azure.microsoft.com/en-gb/status/ [12:51] who needs names anyway? We're just cells in a spreadsheet. :-D === DaveJ__ is now known as DaveJ [13:19] axw_: responded to comment, hope it makes sense what i'm trying to say [13:27] axw_: we would have to make it so that fred@local did not store domain="local", and reserve domain attribute for non-local; that's what you're saying right? [13:28] wallyworld: yes [13:28] +1 to that [13:28] if i land this now, it won't break the api, and we can do the bigger change soon [13:28] wallyworld: np [13:28] but what is stored in the db will need to be handled [13:29] i guess it won't be too hard to throw away @local [13:29] wallyworld: not sure. we may have to accept @local and drop the domain [13:29] right [13:29] would be better to reject it if possible [13:29] we have a few days till rc, i can land this to unblock gui [13:30] and easy then to follow up before tuesday [13:30] hmm, i wonder how big the change would be [13:30] might be nice not to have to mess with the map key types [13:31] probably a can or worms [13:32] axw_: the other thing i did which needs a second optinion is to add the credential watcher to apiserver/provisioner and apiserver/storageprovisioner as those are the bits i think will need it; adding it now gets the apis in place for later [13:33] we can hook up tomorrow about it === benji__ is now known as benji [13:46] wallyworld: I LGTM'd your branch, but just thinking... I don't think storageprovisioner needs it [13:46] or provisioner actually? [13:46] wallyworld: I think only the environ tracker wants to watch it, and restart when it changes [13:46] axw_: yeah, wasn't sure, until we dig in and implement something. [13:47] the provisioners would need it if they were responsible for passing creds to the environ [13:47] depends on how we want to model it. i don't have to land the work [13:48] natefinch: Review this tiny test fix for juju/charm? Knock-on from a change you made to juju/version. https://github.com/juju/charm/pull/219 [13:48] wallyworld: the environ-tracker is solely responsible for maintaining the Environ [13:48] babbageclunk: looking [13:48] natefinch: thx [13:48] wallyworld: the provisioners depend on the environ-tracker to get the Environ [13:48] let's deal with it tomorrow [13:49] yep, sgtm [13:49] changing @local handling will be messy [13:49] babbageclunk: isn't "beta18" the tag? or is "beta" the tag and 18 the patch? [13:49] wallyworld: aren't you happy we filed that bug today? :) [13:50] urulama: oh, i'm positively estatic [13:50] :D [13:50] natefinch: not sure - at the moment it'll be parsed as tag:beta, patch:18. [13:50] urulama: there's a quickie fix landing [13:50] should work but we can't reproduce as the cli passes what's expecyed [13:51] babbageclunk: yeah, that's right, according to the tests on juju/version [13:51] but you guys can tell us if it fixes it [13:51] wallyworld: ok, thanks. will reply on that bug if it's fixed [13:51] not yet [13:51] need to see the landing happen [13:51] wallyworld: just out of curiosity, internal handling of @local is going to be for 2.1? [13:51] natefinch: maybe I should add another case to that charm test to make that a bit more explicit. [13:52] urulama: i would like for 2.0 if possible, but we'll need to look at it. it should be transparent to outside [13:52] kk [13:53] babbageclunk: nah, I think it's ok as is [13:53] natefinch: cool [13:53] babbageclunk: it's just our string output of versions is confusing, since we munge together the tag and the patch [13:54] babbageclunk: man, I love being able to review right on github. [13:55] natefinch: :) [14:19] frobware: sorry, did that while getting ready to crash [14:20] rick_h_: no harm done :) [14:20] frobware: around for a few for the cross team call [14:21] rick_h_: was going to book travel but need to know whether I'm going to the cloud sprint too [14:21] frobware: yes if you're ok with it [14:21] frobware: I got you added to the list [14:21] rick_h_: is there an invite; do I need to use 2 evt codes? [14:42] go build is very effective in its use of every single core on my laptop [14:48] Bug #1587644 opened: jujud and mongo cpu/ram usage spike [15:29] hatch: ping? [15:29] babbageclunk: morning [15:29] niemeyer: had some weird timeout from CI trying to get gopkg.in repos... not sure if this was just a network glitch or what, but figured it might be worth looking to make sure things are running smoothly: http://pastebin.ubuntu.com/23182542/ [15:30] niemeyer: worked fine when I retried, btw [15:30] frobware: ping [15:31] dimitern: pong [15:31] hatch: Hi! I'm working on bug 1584193 [15:31] Bug #1584193: juju deploy is in a different form than jujucharms.com <2.0> [15:32] frobware: let's sync? [15:33] dimitern: give me 10-15. ok? [15:33] hatch: Just wanted to make sure that what I'm proposing (comment at the bottom) sounds right. [15:33] frobware: sure, np [15:33] babbageclunk: alright let me take a look [15:33] hatch: Also, I'm not totally sure how to handle the development channel - should that just be another component of the URL? The existing tests include it. [15:33] hatch: Thanks! [15:33] frobware: I have the provider/maas PR ready, just need to test it some more [15:36] dimitern: ok now [15:36] frobware: omw to standup HO [15:36] morning [15:37] babbageclunk: I think you're on the right track, gimme aminute to bounce this off others [15:37] dimitern: in there now [15:48] babbageclunk: so it looks good, but channels should _not_ be in the url [15:50] hatch: Ok. At the moment the tests include them https://github.com/juju/charm/blob/v6-unstable/url_test.go#L302 [15:50] and the channels are: edge, beta, candidate, stable [15:51] urulama: Ok, I'm just looking back at the code for the deploy command to understand how it handles channel. [15:53] babbageclunk: best person to ask is frankban [15:54] urulama: Does that mean charm.URL should lose .Channel? It seems like it's included in the charmstore.CharmID instead. [15:54] I'll talk to frankban about it. [15:55] babbageclunk: we should remove the channel part of charm.URL, and the corresponding tests [15:55] babbageclunk: that code is obsolete [15:55] frankban: ok great - thanks! [15:55] np [15:56] babbageclunk: and sorry as that's a leftover from us [15:56] shrugs. :) [15:56] Code rots, I guess - easy to delete! [16:03] urulama, frankban: Hmm - is this the kind of change that means we should bump the version of juju/charm? [16:04] babbageclunk: in theory yes, but I don't think there is code relying on that URL field, and btw that's -unstable [16:04] frankban: Ah, of course! Cool cool. [16:27] natefinch: The timeout is generally an ancient version of git in use, typical in some CIs.. (fix was committed upstream ~6 years ago) [16:47] frankban, could you review this? Removing channel from charm.URL. https://github.com/juju/charm/pull/220 [16:48] frankban: There were a couple of (trivial) uses in charmstore, I'm doing a PR for that too. [16:52] Oops, didn't realise what time it was for him. hatch, would you mind reviewing https://github.com/juju/charm/pull/220? [16:53] niemeyer: ahh, interesting. sinzui, mgz, see niemeyer's response to my query about this timeout from CI: http://pastebin.ubuntu.com/23182542/ [16:54] babbageclunk: I'm not really the right person to review a juju core branch :D [16:54] but I can certainly take a look [16:55] hatch: Sorry! I can get frankban to look at it tomorrow instead if you'd prefer. [16:55] sure, it's just that my review won't be a voting one :) [16:56] hatch: :) [16:58] natefinch: not sure that's right, you're looking at a gating merge job? [16:58] mgz: yep [16:58] natefinch: that's on a xenial box, so the git version is pretty current [16:58] $ git version [16:58] git version 2.7.4 [16:58] more likely to be random network blips [16:59] mgz: http://juju-ci.vapour.ws:8080/job/github-merge-juju/9243/console [16:59] mgz: you mean the network isn't reliable? [17:00] mgz: natefinch: yes, we have seen network issues with gopkg and github in the past [17:00] natefinch: http://juju-ci.vapour.ws:8080/job/github-merge-juju/9244/console shows we got the packges [17:03] sinzui: yep, I mentioned it worked when I retried. I hadn't seen that particular error before, so I figured it might be worth a look just in case. . [18:01] balloons: done, thanks a lot [18:03] frankban, I think you mean babbageclunk who seems ot be out fo rthe day :) [18:04] thanks for the review [18:29] alexlist: ah, right, damn you autocomplete! [18:29] oh... again [18:29] alexlist: nm === frankban is now known as frankban|afk [18:42] * redir goes for lunch and to run a couple quick errands bbiab [19:32] sinzui, mgz: my branch won't trigger the bot: https://github.com/juju/juju/pull/6221 [19:35] natefinch: once the bot accepts, you cannot ask it to try again. you need to forge a fail reply or just rerun the jenkins build. I don't see your job was canceled though, [19:36] natefinch: oh, it was this build, the one where we couldn't get a build. that broken the chain [19:36] http://juju-ci.vapour.ws:8080/job/github-merge-juju/9247/console [19:36] * sinzui manually retries the build [19:45] sinzui: dangit, I forgot to save one of the files I edited... that build's going to fail [19:45] natefinch: okay. I can requeue when you shout that the branch has the right files [19:48] sinzui: just did, it's fixed. Sorry about that,. [19:49] natefinch: np [19:49] natefinch: the job is playing http://juju-ci.vapour.ws:8080/job/github-merge-juju/9251/console [19:49] sinzui: thanks [20:07] back [20:23] super easy review anyone? https://github.com/juju/juju/pull/6259 [20:47] natefinch: looking [20:59] thumper, our HO just don't like each other [20:59] heh [20:59] yeah [20:59] thanks for the input [21:23] redir, did you encounter this bug when doing the config naming collapse work?: https://bugs.launchpad.net/juju/+bug/1532130 [21:23] Bug #1532130: Config item 'version' vanishes under 2.0 <2.0-count> [21:24] alexisb: looking [21:27] alexisb: I did not see that bug but also wasn't using postgres, nor specifically trying any charms with a version attribute. [21:27] alexisb: want me to try postgres when I fixup app config to use --reset as a stringvar? [21:28] redir, yes please [21:31] alexisb: added card with bug attached to current iteration [21:32] thumper, can you join the release call today please [21:32] coming === mup_ is now known as mup [22:00] sorry anastasiamac_, thumper lost my browser [22:01] anything happen at teh end of the release call that I need to know about? [22:02] just bashing aussies [22:04] :) [22:04] anastasiamac_, would you have time after standup to go over your test plan and actions for the sprint [22:07] natefinch: gofmt is sad: [22:07] core/description/machine.go [22:07] i wonder how that got though the bot? [22:10] alexisb: before/after/anytime \o/ [22:10] I have meetings before [22:10] alexisb: enjoy :) [22:10] so it will have to be after, but I love your spreadsheet [22:10] \o/ [22:23] \/o\ [22:29] wallyworld and thumper: https://github.com/juju/juju/pull/6261 [22:30] looking in a bit [22:30] wallyworld: I couldn't see any unit test for bootstrapping with local tools so I added them, but I might have missed them somehow [22:31] yeah, they are there somewhere [22:31] maybe spread across cmd/juju/boothstrap and environs/bootstrap [22:31] can't recall exactly [22:42] anastasiamac_: what prompted the latest revert? can you please point me at the offending stream data that broke it? [22:43] axw_: centos iagemetadta was malformed- we used "." instead of ":" to separate tokens in content_id [22:43] anastasiamac_: ah, doh [22:43] axw_: rackspace was using modtly simplestreams data that we generate and our index file and product file do not agree on stream - index says "released", product says "custom" [22:44] :/ [22:44] axw_: in cannonistack, it's even better where image stream used is "ubuntu" [22:44] heh [22:44] axw_: since these files can be hand-crafted there is no guarantee that the 2 sources of stream value are consistent [22:45] axw_: the *right* thing to do, before parsing simplestreams files is to validate them [22:45] anastasiamac_: indeed. we should be less lenient about crap data, otherwise it'll stay that way [22:45] axw_: I think we should also wrk closer with Scott Morser once we get to clean up simplestreams implementation to ensure that we cater for windows special-casing ":" [22:46] axw_: \o/ yes so m pushing simplestream review/re-implement to wishlist :) [22:46] anastasiamac_: ok, thank you [22:46] axw_: what we currently have kind of works but we ned to have a better approach [22:46] axw_: \o/ thank you for asking - love to know that people care :D [22:47] menn0: lgtm, was such a simple change in the end [22:47] axw_: i think tech board has to have a say before we tackle simplestreams and will do a write-up for it based on alexisbgreat suggestions :) [22:47] okey dokey [23:09] wallyworld: thanks for the review. I got interactive auth working last night. just need to hook it up to add-credential now [23:09] awesome [23:09] atm it only works when you add it to credentials.yaml, which is a crappy experience (have to do interactive auth each time you bootstrap) [23:10] progress though [23:14] * thumper sighs and dives further into the rabbit hole [23:56] Bug #1587644 changed: jujud and mongo cpu/ram usage spike [23:59] Bug #1587644 opened: jujud and mongo cpu/ram usage spike