[00:53] wallyworld: I'm going to be out for lunch during our normal call time [00:53] wallyworld: catch up with you later in the afternoon? [00:53] sure [00:53] just ping me [00:53] kk [01:09] wallyworld: https://pastebin.canonical.com/133053/ -- I tried to write out the environment.yaml as 'agent-version: $(juju --version)' [01:10] looking [01:12] dpb1: i think the agent version is 1.23.3 [01:12] not the full juju version wich includes the series and arch [01:13] so you'll need to awk or sed it [01:13] wallyworld: you wanted me to ping you when I got back I think? I can't remember why... :) [01:14] wallyworld: no wait, I think you just wanted me to send info to perrito666 [01:14] axw: not that i recall, i think i mentioned some 1:1 topis [01:14] yes [01:14] a couple of metadata examples for filesystem storage on ebs and cinder etc to use in CI tests [01:14] yup [01:15] and some notes on what to test if any apart from the stuff we discussed [01:24] wallyworld: sure, but in that email thread it was mentioned that $(juju --version) was correct. [01:25] dpb1: we will make it correct for bootstrap, i'm not sure if it's currently supported like that. i'll need to review the emails to be sure of what the context was [01:26] ok, I'll reply on thread, just wanted to check if I was way off base. [01:26] dpb1: not offbase, setting the agent-version attribute needs to just be 1.23.4 etc [01:27] k [01:27] dpb1: hopefully next week we'll start the --no-auto-upgrade (or whatever we call it) option for bootstrap [01:27] and/or $(juju version) [01:30] wallyworld: ok, understood [01:36] dpb1: also, with 1.24, bootstrap will not return until it knows there are no upgrades to be done - so in the case of deployer, we will hopefully avoid the situation where deployer gets disconnected because just as it starts its work, the agent restarts from underneath it [01:37] so even if one of those implicit upgrades happens, deployer won't start and then get a disconnect error [01:37] wallyworld: OK, I wasn't aware that made it into 1.24, thanks for letting me know. [01:37] sure, np [01:58] wallyworld: just spilt tea everywhere, will be a bit late [01:59] oh, no [01:59] just ping me === natefinch-afk is now known as natefinch [02:06] wallyworld: I'm in [02:49] Bug #1464470 opened: A subordinate charm hook scheduled to run(but it is waiting for the principal charm hook to release the lock) goes to an error state after the principal charm triggers a reboot. <1.24> <1.25>

[03:42] thumper: http://reviews.vapour.ws/r/1921/ === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [05:33] menn0: still onine? [05:33] wallyworld: yep [05:34] menn0: i forgot to ask you about bug 1464335 [05:34] Bug #1464335: debug-log does not work with local provider

[05:34] this has been reported against 1.24 [05:34] * menn0 is looking [05:34] looks like all-machines log is missing [05:35] maybe i should have asked thumper [05:36] as it is claimed inthe bug he was involved [05:36] wallyworld: i didn't do it [05:36] :( [05:36] wasn't me [05:36] but I recall it [05:37] it not working that is [05:37] it was claimed as a regression of 1202682 [05:37] bug 1202682 [05:37] Bug #1202682: debug-log doesn't work with lxc provider

[05:37] but i haven't dug in [05:37] wallyworld: someone broke it again [05:37] huzaar [05:38] * wallyworld sighs [05:38] that tells me our tests are fooked [05:38] * menn0 spins up an env to have a quick look [05:47] wallyworld: file permission problem [05:47] sudo ! [05:47] wallyworld: menno had the same problem and his ~/.juju was 0700 [05:47] mine is 0755 [05:47] and all is good [05:47] hmmm, ok [05:48] he changed his permissions and an all-machine.log turned up [05:48] huh [05:48] maybe juju init is wrong [05:48] the syslog user couldn't see the config file [05:48] or there was an old .juju [05:48] well, the .pem cert actually [05:49] thanks for looking [05:49] * wallyworld goes back to spec writing [05:49] wallyworld: actually... [05:49] wallyworld: the rsyslog files were in the log dir, and natefinch moved them recently to the datadir [05:49] wallyworld: since the log dir is in /var/log/.... [05:50] the syslog user could access [05:50] also... [05:50] * wallyworld waits with baited breath [05:51] nah, that's it [05:51] I changed my mind [05:51] was thinking of apparmor [05:51] but menno's one started working [05:51] so it wasn't that [05:51] ok [05:51] do you recall if juju init is wrong? [05:51] will need to check [05:51] it was the move of the cert from the logdir to datadir that broke it [05:51] some people like locking down their home dirs [05:51] we can't guarantee this [05:52] ah [05:52] lets just log to the db and fix all this [05:52] :) [05:52] sure, but for 1.24.1 [05:52] so what do you suggest? [05:52] well thumper, interesting that mention it.... [05:52] well, we have two choices [05:53] tell people to change permissions everywhere [05:53] or move the files back out to the log dir [05:53] or [05:53] some other dir [05:53] perhaps make /var/lib/juju- [05:53] /var/lib/juju/local/ for config files [05:53] can't we just create log dir with correct permissions [05:54] it isn't the log dir that is the problem [05:54] the cert that rsyslog uses is in the local provider datadir [05:54] which defaults to $JUJU_HOME// [05:54] sorry, i meant the datadir [05:55] this would mean changing the default datadir for the local provider [05:55] it is effectively requiring moving the datadir out of the home dir [05:55] so... [05:55] to main options [05:55] can't we just change permissions on ~/.juju [05:55] 1) move the rsyslog conf back to the logdir [05:55] no :-( [05:55] that would be bad [05:55] 2) move local provider datadir out of $JUJU_HOME [05:56] rm -rf logs and you break everything [05:56] 3) tell everyone to change the permissions on their home dirs and .juju [05:56] that's about it [05:56] wallyworld: changing their perms on ~/.juju isn't enough... their home dirs have to be open too [05:56] can we just change permissions on .juju [05:56] ah [05:57] option 2 maybe [05:57] i can't see option 1 as any good at all [05:57] can be fixed next week [05:58] can you update bug? maybe someone in US timezone will pick it up, we should maybe even assign to nate [06:00] wallyworld: to be really sure I just confirmed the problem still happens when ~/.juju's perms are open but $HOME is restricted [06:00] yeah, bollocks [06:20] wallyworld: ticket updated [06:20] tyvm [07:03] wallyworld: let me reboot [07:04] ok [07:55] could someone take a look at http://reviews.vapour.ws/r/1888/ ? [09:52] dooferlad: discovered that those tests had a failing assert that was stopping the test but not marking it as a failure [09:52] dooferlad: and that six other tests had the same issue - and some of them fail if you actually run them! [09:53] dooferlad: so we have failing tests on master that aren't being reported... [09:54] voidspace: yikes! [09:54] yeah :-/ [10:02] Voidspace which ones? [10:05] perrito666: lxcBrokerSuite in workker/provisioner/lxc-broker_test.go [10:05] perrito666: the problem is in startInstance [10:05] perrito666: anything that calls that just halts - there's actually an assert failure but the test is marked as a pass [10:15] rogpeppe1, ping? [10:15] mattyw: pong [10:38] Bug #1464600 opened: Juju 1.22.5: pending LXC containers

[10:40] sorry, I seem to keep dcing from freenode [10:40] canonical irc seems fine though [10:45] Bug #1464616 opened: destroy-machine --force no longer forceably destroys machine === kadams54 is now known as kadams54-away [10:54] Bug #1464616 changed: destroy-machine --force no longer forceably destroys machine [11:09] Bug #1464616 opened: destroy-machine --force no longer forceably destroys machine [11:45] Bug #1464633 opened: juju status should show if an upgrade is available

=== mwenning is now known as mwenning-wfh [13:30] Bug #1464665 opened: backupsSuite setup failed

=== anthonyf is now known as Guest45939 [13:37] Hello folks, I was wondering how the lxc template "juju-trusty-lxc-template" is generated ? [13:38] jamespage: Hello ! [13:40] Please correct me if i am wrong, but the way juju spawn containers is that first it will transfer the "juju-trusty-lxc-template" to the target host [13:40] and then juju will use this template to spawn new conatiners from this template. [13:42] I want to change the "juju-trusty-lxc-template" before it is transferred to the target host for the lxc container. Is it possible to do it ? [13:48] Syed_A, the template container is created, when lxc-clone is true (the default) in environments.yaml for the environment, the first time an lxc container is deployed on the machine (of the given series) [13:49] Syed_A, it is possible to change the template container, but why do you need that? juju also changes it in some cases [13:51] Bug #1464671 opened: clientSuite setup fails

[13:51] dimitern: I want the containers to have 3 nics and take ip addresses from three bridges on the hosts. Right now i have to manually edit the template. but if somehow i can edit the template on the juju machine, then whenever a new machine clone this template it has all the values for the 3 bridges. [13:52] Syed_A, it's better to do that by deploying a charm (principal or, better, subordinate) to each container; that charm can contain scripts to add NICs and other things [13:54] dimitern: Right now i have to log inside the machine hosting the container and edit the template manually. I want to edit the template on juju node so that edited template gets transferred whenever i add a new machine to start containers on it. [13:54] Syed_A, how about what I suggested above? [13:55] Syed_A, with a charm that does the custom config, you can write it once and then use it on every machine [13:56] dimitern: that make sense. But i have never written a charm before. [13:57] Syed_A, it can be very simple, e.g. take the ubuntu charm as a base and just add some scripts in the hooks/install [13:58] Syed_A, https://jujucharms.com/ubuntu/trusty/3 - there's a "Download zip" link on the right; then, unzip this in a dir with the following structure: mycharms/trusty/ubuntu [13:59] dimitern: opening it. [13:59] Syed_A, then inside the ubuntu dir, add a "hooks" dir and inside it an "install" script (bash or python, but needs to be executable) [14:00] Syed_A, in that install hook, you can do things like: [14:01] Syed_A, stop a given container, change the lxc.conf it uses to add more networks, restart it [14:02] natefinch: standup [14:02] Syed_A, finally, to test this, use: juju deploy local:trusty/ubuntu --repository --to 1 (or later juju add-unit ubuntu --to X - machine id) [14:02] katco: coming [14:03] Syed_A, there are lots of folks in #juju which can help you with your charm, and there's the online docs about it - https://jujucharms.com/docs/stable/getting-started [14:05] dimitern: This sounds like a great plan but alternatively if i could just edit the template on juju node itself then i will be good to go. [14:06] Syed_A, you can try - it's in /var/lib/lxc/juju-trusty-lxc-template/config (and int the same dir, rootfs/etc/network/interfaces needs to be changed) [14:07] Syed_A, changing the template and then deploying another lxc (the first one you deployed, which triggered the template creation you can destroy) will use the changed template [14:08] dimitern: Yes, this is what i was doing. [14:08] Syed_A, however, beware this is not supported and your mileage may vary [14:08] dimitern: Changing /var/lib/lxc/juju-trusty-lxc-template/config on every host [14:09] dimitern: This file will only be present on a machine if you start a container on it. [14:09] Syed_A, that's the only way manually (still can be automated somewhat by using "juju run" or "juju ssh"/"juju scp"), using a charm allows you to take advantage of juju's automation [14:10] Syed_A, hmm, something occurred to me now [14:10] dimitern: My question is from where does this "/var/lib/lxc/juju-trusty-lxc-template/" comes from ? [14:10] Syed_A, if all your machines are more or less the same, you could potentially do this once on one machine and then just copy the template to /var/lib/lxc and try if it will work [14:12] Syed_A, it's created using lxc-create --debug --userdata --hostid -r trusty [14:12] dimitern: I can do that but then juju might overwrite it ? Probably there could be a semaphore ? [14:12] Syed_A, and then once it boots it's shutdown and cloned [14:12] dimitern: lxc-create -n juju-trusty-lxc-template21 \ [14:12] -t ubuntu-cloud \ [14:12] -f /var/lib/juju/containers/juju-trusty-lxc-template/lxc.conf \ [14:12] -- --debug \ [14:12] --userdata /var/lib/juju/containers/juju-trusty-lxc-template/cloud-init \ [14:12] --hostid juju-trusty-lxc-template \ [14:12] -r trusty [14:12] Syed_A, juju checks if juju-trusty-lxc-template is present and uses it, it won't overwrite it [14:13] dimitern: Sorry about the paste. [14:14] dimitern: If that's the case then it will be a really easy and good solution. [14:15] Syed_A, well, you never know until you try I guess :) [14:16] dimitern: Yep! ;) [14:17] Syed_A, anyway, I hope it works and if you have other questions, here or in #juju someone will be able to help you [14:17] dimitern: Thanks! [14:21] Bug #1464679 opened: juju status oneline format missing info

[15:08] wwitzel3: let me know when you're around.... not a huge fan of the ContextComponent's using of interface{} everywhere [15:10] natefinch: I'm around [15:12] natefinch: by everywhere, you mean in the Get and Set fields? [15:14] natefinch: or are there other places of concern? [15:15] wwitzel3: sory, hyperbole... but just not a fan of not-type-safe code [15:16] wwitzel3: so I'd like to know what this is buying us [15:17] natefinch: it is type safe because we explicitly check that the type conversion works in the component side and error if it doesn't. [15:18] natefinch: but what it buys us is the ability to register components without the hook context needing to know implementation details about the components (and there for, not import that as a package) [15:18] natefinch: so the ContextComponent interface is our intersection between juju internals and the external component [15:47] wwitzel3: do you want to jump in a hangout... I feel like i'm behind on a lot of the decisions made in the spec, so I'd like to understand better about the use cases the spec solves [15:49] sure, katco if you're interested, we are heading in to moonstone [15:50] wwitzel3: yeah be there in a sec === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [16:32] alexisb: you'll be happy to know, there is a ceiling fan in my office now :) [16:33] lol [16:33] nice wwitzel3 [16:41] wwitzel3: i think natefinch needs those tabs for godoc [16:42] katco: ah, ok, I thought it could be spaces too and i was just going for consistency [16:43] spaces or tabs work [16:43] tab is fewer keystrokes [16:44] https://godoc.org/github.com/natefinch/godocgo#hdr-Formatting [16:44] natefinch: ah that's what i was looking for. didn't know you could use spaces as well [16:44] I just hate tabs [16:44] lol [16:45] wwitzel3: tabs in emacs alllll day. come at me! [16:45] I'll sneakily edit your config at gophercon so your tabstop is 32 [16:45] I love tabs. Their whole point is to indent. And you never have to backspace or hit space multiple times to indent. Plus, everyone can set their tabs to be whatever width they want, and no one else has to complain they're too big or small [16:46] wwitzel3: good luck with that. my config is currently 1409 lines long and source controlled ;) [16:47] katco: I wouldn't be able to actually do it anyway, I don't know how to boot emacs [16:48] wwitzel3: quantum computing is coming. i'm hoping those machines will be able to run it [16:51] if you don't already have it, I highly recommend getting the hub tool from github. It wraps git and does a lot of awesome github-specific things from the command line. Like making it super easy to checkout the code for a PR, or make a PR from your command line, etc [16:52] and it's written in Go.... go get github.com/github/hub [16:54] it wraps git, so you can actually replace git with it entirely [17:08] sinzui: about that "SIGABRT uninstalls jujud" bug - why do we have any signal that tells juju to uninstall? why is that a feature? [17:09] natefinch: I think that is the mechanism that Other engineers decided was the right way to clean up. It used to be another more common sig. axw changed it to ABRT last year [17:43] fwereade: I don't suppose you're around? [17:51] does 'juju generate-config' work on linux and windows alike, ito of dir/file being created? [17:52] pmatulis: yes, it works on both. [17:52] pmatulis: not sure what the second half of your question was supposed to be [17:55] natefinch: this command creates ~/.juju/environments.yaml on linux (if not presetn). does it do the same on windows for %LOCALAPPDATA%/Juju ? === kadams54 is now known as kadams54-away [17:56] pmatulis: yes [17:57] pmatulis: the client is totally compatible between linux, windows, and OSX, following all the normal conventions of each OS. [17:58] pmatulis: er, when I say compatible, you still need the OS-specific binary, but it all comes from the same code and they are treated as equally important [18:09] katco: ping? [18:10] natefinch: thank you [18:16] cherylj: pong [18:17] katco: I have a process question / comment for you [18:17] cherylj: sure what [18:17] what's up? [18:17] katco: I know we close bugs that have no activity for 60 days [18:18] but I saw a bug that got closed because of that with a tag of tech debt [18:18] and I'm thinking that maybe tech debt bugs shouldn't be closed because of inactivity [18:19] cherylj: i agree with that... and feature requests [18:19] katco: do you know who owns the bot or whatever that closes these bugs? [18:20] it may also be the case that this has been fixed. The bug I'm looking at was closed last year [18:20] cherylj: almost certainly CI (ping sinzui) [18:20] katco: will do, thanks! [18:22] cherylj: Launchpad doesn’t care about tags. Lp’s 60 day expiration is based on incomplete status witth no one ot other task assigned [18:23] cherylj: incomplete mean there isn’t enough information to accept this issue as work. [18:23] SO tech-debt cannot be incomplete by definition === Syed_A_ is now known as Syed_A [18:27] sinzui: ah, thanks for clarifying. === Syed_A_ is now known as Syed_A [19:40] natefinch, heyhey, have I missed you? [19:40] fwereade: nope [19:41] fwereade: I have a few questions about why we're doing things in the way we are... which I probably already know the answer to, but want to make sure I understand [19:42] natefinch, sure, can you manage a slightly laggy irc conversation about them? [19:43] fwereade: that's fine L( [19:43] fwereade: er :) [19:44] fwereade: what's up with github.com/juju/schema ? It seems like we're reimplementing what the yaml and json parsers already do to take yaml and shove it in a struct. Seems like we could strip out a ton of code that uses schema and just deserialize into a struct [19:47] * fwereade is excavating his mind [19:49] natefinch, well, you *could* do more sophisticated things than we usually do, but I don't think there's a 100% overlap with "just deserialize into a struct" [19:49] * perrito666 imagines fwereade fiddling with a spoon [19:50] natefinch, I would have no objection to replacing schema with something simpler where it's too unwieldy a hammer for the situation [19:51] natefinch, but I'm not convinced it's completely unhelpful across the board [19:51] natefinch, do you have particularly egregious examples off the top of your head? [19:53] fwereade: looking... [19:54] natefinch, I do know that last time I thought I wanted to use the schema package I got tied up in knots trying to make a self-referential one that would turn nested map[interface{}]interface{} into nested map[string]interface{} [19:55] yeah,... it seems like you should never need map[interface{}]interface{} ... map[string]interface{} should always be sufficient. I don't think anything uses non-strings as keys, do they? [20:01] fwereade: anyway, my other question is about the hook context code [20:02] fwereade: there's a bunch of interfaces that seem to only be used for testing... so I wanted to make sure that they had no other function other than to make the code easier to test: https://github.com/juju/juju/blob/master/worker/uniter/runner/jujuc/context.go#L45 [20:03] wwitzel3: btw, when you get back, I think I have a solution to the generics problem with the ContextComponent stuff [20:05] fwereade: looking at git blame, the one big interface recently got refactored into a bunch of smaller ones... but it doesn't change the fact that it seems like there's no one using it outside the tests. [20:10] natefinch, I am entirely comfortable with exposing functionality behind interfaces by default, for all sorts of reasons [20:10] natefinch, ease of testing is certainly one of them [20:11] natefinch, but the Context interface is, I think, an important thing in itself [20:11] natefinch, it's the bottleneck through which all hook communication needs to happen [20:12] natefinch, it keeps the hook tools unaware of more distant layers [20:12] natefinch, and all those things push towards it being an interface === Syed_A_ is now known as Syed_A [20:19] fwereade: have you seen Eric and Wayne's ideas for Components? [20:20] natefinch, not sure I have actually -- hwere were they? [20:20] fwereade: you have. this is the whole intersection of features with layers of architecture discussion [20:21] katco, ah, right [20:23] fwereade: the reason I brought it up is because of what you said about hook tools not needing to know about distant layers. While that's true... it's also true that you're likely to write the action-set hook tool at the same time as the action API call, etc. So it's actually not terrible if the action-set tool knows about the action API... what's actually better is not requiring *everyone else* to know about those things [20:23] ... which I think is what the Component idea is trying to push. [20:23] I don't know what my point was there, though [20:23] natefinch, strongly disagree [20:24] natefinch, it is terrible if the hook tools know about the api [20:24] natefinch, makes it impossible to understand and maintain them in isolation [20:25] natefinch: the idea is that you have an adapter where features and architectural layers intersect, so that neither are strongly coupled to the other [20:25] natefinch, I am all for improving horizontal boundaries, but not at the cost of the vertical ones [20:25] natefinch: these are the "abstraction" cards on our kanban [20:25] yes, sorry, saying it wasn't terrible was hyperbole. Certainly keeping things decoupled is good. [20:26] natefinch, katco: so I frequently articulate this poorly [20:27] natefinch, katco: but I think a good model *is* to cluster feature-specific code into a package or small closely-connected group of packages [20:27] natefinch, katco: those bits define the juju entities and how they act; other model code defines how model entities can/should interact [20:28] fwereade: yep [20:28] natefinch, katco: and then, as much as possible, we use those same model representations wherever we can [20:28] natefinch, katco: so the business logic doesn't need to be rewritten in subtly different ways at every level [20:29] natefinch, katco: the trouble is [20:29] fwereade: yeah, i think we're still on the same page [20:30] natefinch, katco: that many of our business rules are encoded at the storage level and aren't likely to move any time soon [20:30] fwereade: right, we've also identified that as the hardest piece [20:30] natefinch, because it's really damn difficult to extract the business rules without dragging nasty gobbets of persistence concerns with them [20:31] fwereade: we're not planning on doing a whole lot there atm b/c it's such a large effort [20:31] fwereade: but we are going to introduce a few small bits which will hopefully chip away at the problem [20:32] natefinch, katco: so, yeah, I think we're all on the same page. so long as you keep the layers separated as much as you can, I'm happy :) [20:32] fwereade: yes :) we have that in the forefront of our mind for sure :)\ [20:33] yep === lazyPower is now known as lazyPower|eow [20:48] eod. happy weekend all [21:17] bah [21:17] just missing him