[01:04] thanks, wallyworld. Given that we want 1.25.0 asap, do you think it could reasonably be done soon? or should we aim for it in 1.25.1? [01:05] cherylj: it can go in 1.25.1 - it's been broken for a while AFAIK. so let's not hold up 1.25 for it, but i'd like to think 1.25.1 will appear not too long after [01:05] wallyworld: sounds good, thanks! [01:09] :O [01:09] update-status hook isn't a myth! [01:15] lazyPower: it better not [01:15] we should settle for one of the englishes in the code [01:16] perrito666, i heard about it in seattle, but called schenanigans [01:16] i'm on a build of 1.25-beta2 and its in here [01:16] grep -ri authorized | wc -l [01:16] 997 [01:16] grep -ri authorised | wc -l [01:16] 200 [01:16] lazyPower: it better be, I put it there [01:55] perrito666: english vs american [01:56] thumper: they both sound foreign to me :p [01:56] :) [01:58] pretty sure America invented English [01:59] My brain reads juju comments and code with the BBC narrator voice so I presume it is uk version :p [01:59] lol [02:06] ok brain coredumped, see some of you tomorrow [02:39] dpb1: don't suppose you still have the env for https://bugs.launchpad.net/juju-core/+bug/1491688? and can I get access? I haven't had any luck reproducing it, and the logs aren't very illuminating [02:39] Bug #1491688: all-machine logging stopped, x509: certificate signed by unknown authority

[02:53] axw: I have that locally with 1.24.6 [02:54] thumper: orly? did you have to do something special? [02:54] start two local providers [02:54] it fucks up all the logs [02:54] it used to work [02:54] interesting [02:54] I'll try that [02:55] the lxd provider will fix this... [02:55] * thumper can't wait [02:55] we should just warn people about the problems of running more than zero local providers [02:55] thumper: pretty sure LS is using MAAS though... [02:55] yeah... [02:55] and yes, the lxd provider is amazing [02:55] I'm guessing that this isn't necessarily the same problem [02:55] I want it nowwwww [02:55] a little slow, though [02:55] natefinch: plz make tools work properly with local streams [02:56] slow [02:56] ? [02:56] natefinch: the OpenStack on LXD demo wayne did was pretty sweet [02:56] agreed [02:56] bootstrapping takes like twice as long as the local provider [02:56] axw: yeah, that demo was pretty killer [02:57] honestly, just bootstrapping without it asking for a sudo password kind of rocks my world... not to mention the fact it doesn't crap all over my local machine [02:57] natefinch: hah... [02:57] well that isn't really surprising [02:57] local bootstrap isn't starting a machine [02:57] right [02:57] it is just shitting on our local machine [02:58] what amazed me the most was how easy it was to write the provider. They really did well with lxd [03:07] axw: I don't, and it wasn't seen with doing anything funky (like two local providers). But, if you all can't repro, I totally understand (I certainly can't at will). I've seen it a total of twice. [03:08] dpb1: ok, no worries. I'll keep looking anyway [03:22] what's the right way to convert from a unit ID to a unit tag? I'm getting unit ids back from a strings watcher and I've been told I have to pass Tags through the API. [03:23] names.NewUnitTag looks likely, but it panics if I pass it an invalid id (which is gobsmackingly horrible, btw) [03:24] * thumper looks [03:24] natefinch: what do you have? [03:24] service/3 ? [03:24] yeah [03:25] names.NewUnitTag should work [03:25] * thumper looks at the tests [03:25] but it panics... which means I have to check the ids before I pass it into the function, and then that function itself rechecks the ids, which is dumb [03:25] natefinch: c.Assert(names.NewUnitTag("wordpress/2").String(), gc.Equals, "unit-wordpress-2") [03:25] yes, you have to check [03:26] names.IsValidUnit [03:26] all the New*Tag methods panic on invalid input [03:26] that's horrible [03:26] because they are generally used where checking errors is a PITA [03:26] no... it is a valid pattern [03:26] most places, you know you are dealing with valid names [03:27] sometimes, like user input, you need to validate [03:28] it's a house of cards waiting for someone to feed the wrong string into the wrong function at some point and the whole thing blows up in production because someone didn't want to check an error. [03:28] I disagree [03:28] but I can see your point of view [03:28] ditto :) [03:28] so... [03:29] given that you have a valid unit name, why is it failing? [03:29] perhaps you don't have what you think you have [03:29] I'mwriting an api client. It takes a list of strings it hopes are ids. It shouldn't assume someone's not going to do the wrong thing [03:29] * thumper looks at unit id [03:30] agreed, the client (and the server) need to validate [03:30] for example, my test passed in an invalid id, and the code panicked. Sure, I could not do that, but that seems silly [03:31] right, so validate [03:31] right [03:32] IIRC the general use case for creating tags using the New*Tag methods was tests [03:32] at the time they were written [03:32] and panicing in tests is fine [03:32] perhaps we should create a new class of functions [03:32] that validate and return (tag, error) [03:33] however, the line count will be approx the same as currently [03:33] it just irks me to call IsValidUnit twice [03:33] it is my expectation that if I'm calling a function that doesn't return an error, I should check theinput [03:33] you don't [03:33] do you? [03:34] I assume a function that doesn't return an error can't fail [03:34] well... [03:34] or it panics [03:34] because Go [03:34] well... except that in general you never panic unless THE WORLD HAS COME TO AN END. Not because johhnny passed in "foo" [03:35] so, I don't call IsValidUnit twice, but I call it once and then NewUnitTag calls it once [03:35] / NewUnitTag returns the tag for the unit with the given name. [03:35] / It will panic if the given unit name is not valid. [03:36] trivia - the panic was added on the day I joined canonical (though not by me) [03:36] :) [03:36] magic [03:37] And yes, I am glad that the comment states it panics. That's at least better than blindsiding someone. [03:38] boo yeah - have a panic [03:38] not as nice as a picnic [03:38] but close enough [03:39] ha [03:46] wallyworld: I really don't know what's up with the rsyslog bug. I can't reproduce it, and injecting errors into the rsyslog worker shows that it does recover from errors writing certs to state [03:47] wallyworld: rsyslog looks unhealthy in the env, because it's repeating machine-0's logs in all-machines.log [03:47] axw: hmmm. mark as incomplete and ask for steps to repro? or access to an env with the problem so it can be investigated [03:47] wallyworld: ok [03:47] ty for looking [03:49] menn0: what ever happened to the logging-in-state feature branch? is that still happening? [03:52] axw: it's been merged for a long time [03:53] axw: but it's still behind a feature flag [03:53] menn0: ah [03:53] menn0: any particular reason why it's not enabled by default? [03:53] axw: it also gets activated if the "jes" feature flag is turned on [03:53] I see [03:53] menn0: so it will be soon then I guess? [03:53] axw: to be honest, I don't know when [03:53] (on by default) [03:54] mk [03:54] axw: some people had concerns about logging to mongodb [03:54] axw: performance related mainly [03:54] axw: let me bring it up on the list [03:58] menn0: I don't think it is in 1.24 is it? [03:58] axw: small corner case fix please http://reviews.vapour.ws/r/2955/ [04:01] * menn0 checks [04:04] thumper, axw: it's in 1.25 but not 1.24 [04:05] there's bits of it there in 1.24 but it wasn't complete nor wired in at that stage [04:05] menn0: ok. was mainly just curious what the plan was for enabling it [04:05] thanks [04:06] axw: I'll email the list about getting it turned on by default for 1.26 [04:09] menn0: do we need the EnvUUID field in new mongo docs? William said in a review that he thought we didn't, but to check with you. [04:10] natefinch: no they're not necessary any more [04:10] the multi-env DB layer will automatically add them [04:11] I have a personal tech debt item to go and remove them from all our structs (and all the place they're set) [04:11] even if a document struct has an EnvUUID field you can just leave out setting it in the code that creates them [04:11] it'll still get added [04:11] /populated [04:21] menn0: thanks [04:24] natefinch: np [04:24] natefinch: let me know if you find that any aspect of this doesn't work how I've just described [04:25] menn0: will do [04:37] axw: with the test it would be either a big cut and paste or a bit of refactoring all for a corner case where the method being used is tested extensively elsewhere. i can do it if you insist :-) [04:48] axw: another small one sorry http://reviews.vapour.ws/r/2956/ [06:57] dimitern, running 10 mins late... [07:03] frobware, that's ok, I'm finishing my HW list here, will join ~5m === urulama is now known as urulama|afk === urulama|afk is now known as urulama [09:02] dimitern: hangout? [09:02] omw [09:34] dimitern: frobware: I see that AWS "space discovery" is still listed as a deliverable, even after our conversation with William last week when we said it shouldn't be done [09:44] voidspace, that depends on "shared spaces by default" or not [09:45] dimitern: yes, and the agreement in discussion with fwreade was that we should *not* do shared spaces by default [09:45] dimitern: because of the unnecessary pain that it brings [09:45] voidspace, I know, but that's not approved yet by jam or rick [09:46] voidspace, I'd like it if we don't share by default, but mark seemed keen on the idea [09:47] dimitern: listing it as a deliverable seems like a bad idea (very) [09:47] you're boxing us into a corner [09:49] voidspace, even if we go with "not shared by default", there is still value in having discover + filters [09:49] dimitern: how is discover different from list then? [09:50] voidspace, discover lists spaces which are pre-existing on the cloud, but not yet known to (or usable by) juju [09:51] dimitern: but if you don't have shared spaces then there won't be pre-existing spaces [09:51] voidspace, i.e. you can import these (idempotently) [09:51] because as soon as you can share spaces (import them) then the can of worms is open [09:51] and you can't delete / rename them or move subnets [09:51] voidspace, well, "not sharing by default" does not exclude "being able to share spaces at all" [09:52] which is why we agreed not to do it [09:56] voidspace, how about openstack, azure? [09:56] voidspace, for maas "shared by default" and "no creation" is clear [09:57] dimitern: I'm talking about AWSD [09:57] *AWS [09:57] Bug #1508392 opened: Clearer error message when servicename instead of unitname [09:57] you have listed space discovery as a 16.04 deliverable for AWS, despite discussion with fwreade saying we shouldn't do it [10:01] voidspace, we have to do auto-discovery at bootstrap to figure out where to put the apiserver, and to allow bootstrapping into a space [10:02] dimitern: not if we don't have shared spaces [10:02] dimitern: because there won't be a pre-existing space, so we'll create the necessary infrastructure at bootstrap [10:05] dimitern: it *does* mean we don't have feature parity between AWS / MAAS for spaces [10:05] voidspace, that's one of the options [10:05] voidspace, let's have a call with jam about this, ideally also with rick [10:05] frobware, ^^ ? [10:05] we need to clarify this ASAP [10:06] heh [10:12] dimitern: voidspace: if the user has to set up the spaces in order for anything to work at all (which they do today), then it seems to make sense to discover them without having to have a bunch of steps. I don't think it is a prereq for January, though. [10:13] jam, not for jan, we're discussing later, until 16.04 [10:14] jam: they set them up through juju [10:15] jam: so they don't have to set them up in EC2 as a pre-requisite [10:15] jam: they only configure them through juju [10:17] jam: having spaces discoverable (i.e. potentially shareable between environments) means that you can't safely delete or rename a space (can't fix typos) and you can't delete subnets or move them between spaces (so you have to assign a subnet to a space at subnet creation) [10:17] jam: all of which is a horrible UX [10:17] jam: not to mention that if you have different teams sharing a substrate (amazon account) with different environments they will see each others spaces [10:18] voidspace: if you have different teams sharing an amazon account you see everyone's stuff anyway [10:18] hence the *shared account* [10:18] jam: and old spaces/subnets from old environments will hang around for ever [10:18] jam: not with juju - you just see your environment [10:19] jam: a much better model, both for implementation and for UX, is private (to the environment) spaces by default, with explicitly global spaces for sharing [10:19] jam: with the added benefit that "explicitly global" doesn't need to be done initially (yay scope reduction) and can be added later [10:29] voidspace: so I wouldn't focus too much on things beyond January at this point, but I'd also note that if we aren't handling routing between subnets, etc, then the user still has to go to the console to do anything. [10:29] I do agree with some of your points about shared-on-request [10:30] jam: dimitern: the strongest argument for not promising it is that if we don't do it we can always add it - but as soon as we add it we have to support it for ever [10:30] jam: dimitern: so really, let's not promise it or do it until we're clear about the implications [10:31] jam: (it's currently listed as a 16.04 deliverable in the draft doc - which is why I'm bringing it up now) [10:40] frobware, voidspace, jam, I agree to drop it, but it should be replaced with an entry about modeling the shared (global/local) aspect of spaces/subnet and how does it affect the CLI commands [10:40] (i.e. make sure we can do it later properly) [10:41] well yes we should document what we do... [13:39] dimitern: backported latest doc changes to 1.25, mind a quick look at http://reviews.vapour.ws/r/2961/ ? thx [13:40] TheMue, sure, will do shortly [13:40] dimitern: great [15:01] Bug #1508498 opened: JUJU bootstrap fails first time every time [15:04] Bug #1508498 changed: JUJU bootstrap fails first time every time [15:06] TheMue, reviewed [15:06] sorry it took so long [15:06] dimitern: thx [15:13] Bug #1508498 opened: JUJU bootstrap fails first time every time [15:34] wwitzel3, can you refresh my memory on what is happening the first week of feb w/ the eco team [15:34] I see your travel request [15:34] alexisb: fosdem charmers summit party time! [15:34] alexisb: the 1st rule of charmers summit is you talk about charmers summit ALL THE TIME. [15:35] ALL THE TIME EVERYWHERE [15:35] lol [15:35] woo woo [15:35] fosdem fosdem [15:35] hypetrain [15:35] do I even need to say anything at this point? [15:35] :) [15:35] fosdem, cfgmgmtcamp, and http://summit.juju.solutions [15:35] wwitzel3: jsut 'pretty please'? :P [15:36] rick_h_: :) [15:37] wwitzel3, seems I am a good spot to ask for bribes ;) [15:40] alexisb: haha [16:14] frobware: so I've done a 1.22 -> 1.24 upgrade with ignore-machine-addresses=true and failed to reproduce that issue [16:14] frobware: trying some other configurations [17:05] ericsnow: natefinch: wwitzel3: http://reviews.vapour.ws/r/2963/ [17:12] katco: are those first two tests going to compile? [17:12] natefinch: tests run [17:12] katco: workload.Info doesn't ahve a Workload field anymore, does it? [17:13] katco: looking [17:13] natefinch: hm. no it does not [17:13] natefinch: doh... didn't run those tests [17:14] katco: oh good, I was hoping this wasn't some wacky like embedding thing where it works both ways [17:34] cherylj: bug 1465317 just came up in #ubuntu-devel. Ubuntu just learned about series X and the dep8 tests failed. They have fixed a test to avoid the panic, but they are nontheless concerned about Juju's insistence on knowing every version of every OS. [17:34] Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series

[17:35] sinzui: I was just looking at that bug. I see that it's in progress, but I'm not convinced that dave is actually working it. [17:36] I asked for an update, but I'll also talk with him directly in the onyx standup today [17:36] ericsnow: natefinch: wwitzel3: updatedf [17:38] cherylj: I saw. I think we really need the issue to be fixed in 1.26. I think 1.25.1 is nice to have, I think all the next OS upgrades will involve 1.26 being the new stable [17:39] sinzui: sounds reasonable. [17:46] Bug #1508498 changed: JUJU bootstrap fails first time every time

[17:48] yeeeeesssss: https://github.com/rmuslimov/jenkins.el [17:49] Bug #1508498 opened: JUJU bootstrap fails first time every time

[17:52] Bug #1508498 changed: JUJU bootstrap fails first time every time

[17:58] Bug #1508498 opened: JUJU bootstrap fails first time every time

[18:01] Bug #1508498 changed: JUJU bootstrap fails first time every time

[18:02] mup: calm down [18:02] marcoceppi: Excuse moi, parlez vous anglais? [18:02] okay who made mup sassy [18:53] katco: lol .. isn't there a bootloader for emacs? just switch already [18:54] wwitzel3: lol i think there is [18:55] there are instructions for making it pid 1 [18:55] good enough [19:22] wwitzel3: i know you can make it your wm [19:28] the day fun died and emacs won [19:28] katco: heh, for an editor no one uses there sure are a lot of plugins and extensions for it [19:29] sinzui: I was just about to ask you if that juju-local packaging bug should be sent to lxc. You're too quick! [19:29] wwitzel3: maybe more people use it than people think :) [19:29] :) [19:29] wwitzel3: semi-complete list: https://melpa.org/#/ [19:30] cherylj: :) I was helping the user in another channel [19:30] ah! [19:30] all those packages just for katco [19:30] haha [19:31] wwitzel3: 70k+ downloads... you should try it out (whistles) https://melpa.org/#/evil [19:33] katco: http://reviews.vapour.ws/r/2814/ all tests passing [19:33] natefinch: tal [19:38] wwitzel3: Kind of random, but I think I just realized I actually know you based on your handle, hah [19:39] kind of crazy [19:42] cherylj: I just reported bug 1508585 which is the cause the failure of the current test of 1.25 [19:42] Bug #1508585: TestUploadedToolsMetadata fails on windows and centos

[19:47] Bug #1508585 opened: TestUploadedToolsMetadata fails on windows and centos

[19:47] thanks for the heads up, sinzui [19:50] Bug #1508585 changed: TestUploadedToolsMetadata fails on windows and centos

[19:53] Bug #1508585 opened: TestUploadedToolsMetadata fails on windows and centos

[19:53] jamesmillerio: yeah? [19:54] wwitzel3: yeah, you're Laura Tripletts friend and Jessa's husband, right? [19:54] jamesmillerio: ahh, yeah, I know you and your wife :) [19:55] Niceeee, yep. I saw your wedding pictures go over my FB feed a few days ago so your name was fresh in my head. Saw you in here and there are only so many witzel's out there, haha. [20:05] i am fairly certain that wwitzel3 is actually a golden retriever who has no idea what he's doing. [20:06] like 20% sure. [20:06] 20% seems low [20:07] well. i'm also unsure of what i'm doing. [20:07] I'm 100% sure that I'm unsure [20:07] ;) [20:08] i... uh... i... yeah. [20:08] maybe. [20:17] Bug #1508595 opened: revisit use of networks in AddService code

[20:30] katco: so.... now what? [20:31] katco: what can I do to help with our demos, now that we've finally reached a more or less stopping point for this bug? [20:31] natefinch: wwitzel3: ping, you need help with lxd? [20:34] can I add any surity? [20:34] but I know I don't know what you are doing [20:35] thumper: surity? [20:35] sureity? [20:35] sureitude [20:35] damn english [20:35] thumper: lol [20:36] sureness [20:36] thumper: no i don't think so, just trying to find the next best thing for nate to work on [20:37]