| wallyworld_ | axw_: question, we volumes are listed, i would expect that we'd want to see the unit and storage name to which the volume may be attached, so that we can see this 100GB volume here serves the data-dir storage for mysql/0, right? | 00:00 |
|---|---|---|
| wallyworld_ | at the moment, the PR just shows storage tag | 00:00 |
| redelmann | hi, im having some strange problem after " juju upgrade-juju --version 1.23-beta2" | 00:22 |
| redelmann | all units are loging "unit-mongodb-production-0[25074]: 2015-03-31 00:22:51 ERROR juju.worker runner.go:219 exited "uniter": failed to initialize uniter for "unit-mongodb-production-0": cannot read "/var/lib/juju/agents/unit-mongodb-production-0/state/uniter": invalid operation state: unexpected hook info with Kind Continue" | 00:23 |
| redelmann | ok, now stop working :P | 00:34 |
| axw_ | wallyworld_: volumes are machine-level, hence we see machine attachment. you could argue that since we know the assigned storage instance, we could also show the unit-storage attachments... but we have "juju storage show" if people really want to see that | 00:49 |
| wallyworld_ | axw_: i think that distinction will be lost on the user | 00:49 |
| wallyworld_ | storage will also show fs etc | 00:50 |
| wallyworld_ | if i list volumes, i'd like to see where they're attached (ie what unit) if i were a user | 00:51 |
| wallyworld_ | s/attached/in use | 00:51 |
| axw_ | wallyworld_: I'm not opposed to adding an optional UNIT column | 00:51 |
| wallyworld_ | ok, let's do it | 00:52 |
| wallyworld_ | we could if required (which i'm not sure we will be) add a CLI flag to exclude/include volumes attached to units | 00:52 |
| wallyworld_ | redelmann: i'm not sure what's happened with your upgrade, can you raise a bug and attach as many logs as possible from the affected machine | 00:56 |
| redelmann | wallyworld_: ok | 01:12 |
| wallyworld_ | redelmann: the error is an internal one that indicates that something got out of sync, but we'd need more info | 01:13 |
| redelmann | wallyworld_: im collecting log from machine-0 | 01:14 |
| wallyworld_ | even if you zip the /var/log/juju dir | 01:14 |
| wallyworld_ | but we'd need logs from the machine running the affected unit | 01:15 |
| redelmann | wallyworld_, where i can send logs? | 02:00 |
| wallyworld_ | redelmann: attach them to the bug | 02:00 |
| jw4 | redelmann: that looks like an upgrade issue where the upgrade steps for 1.23 didn't run. Let me know when you've created the bug and attached the logs | 02:24 |
| jw4 | (one of the upgrade steps) | 02:25 |
| redelmann | jw4: ok, first im trying to remove "some way" upgrade from mongo in machine0, need this running for today :P | 02:26 |
| jw4 | thanks redelmann | 02:26 |
| redelmann | jw4, i keep a copy of log for bug | 02:26 |
| jw4 | gracias | 02:26 |
| redelmann | jw4: thank to you | 02:26 |
| axw_ | wallyworld_ thumper: pyfmt - https://plus.google.com/+EliBenderskyGplus/posts/SzKrvzvUuyc | 02:27 |
| * thumper looks | 02:28 | |
| axw_ | I can't see it being as effective as gofmt, since whitespace matters in Python | 02:28 |
| * thumper guesses yet another python fromatter | 02:29 | |
| axw_ | indeed :) | 02:29 |
| thumper | yeah, first paragraph | 02:29 |
| wallyworld_ | can't have too many | 02:29 |
| thumper | axw_: interesting | 02:30 |
| thumper | I want a js version too | 02:30 |
| thumper | resharper does a good job with visual studio | 02:30 |
| thumper | and C# | 02:30 |
| redelmann | axw_, wallyworld_ : https://bugs.launchpad.net/juju-core/+bug/1438489 | 02:44 |
| mup | Bug #1438489: juju stop responding after juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1438489> | 02:44 |
| redelmann | sorry axw_: that no was for you | 02:45 |
| redelmann | jw4: https://bugs.launchpad.net/juju-core/+bug/1438489 | 02:45 |
| jw4 | thanks redelmann :) | 02:45 |
| axw_ | np | 02:45 |
| redelmann | tellm if you need more details, and how to get it. | 02:45 |
| redelmann | now im going to keep trying to remove upgrade from ¿queue? mongo | 02:46 |
| jw4 | redelmann: I don't see that error in that log | 02:47 |
| jw4 | redelmann: do you have other logs? | 02:47 |
| redelmann | jw4, that error is in "juju debug-log" | 02:47 |
| jw4 | redelmann: I see | 02:47 |
| redelmann | cant run debug-log again, it stuck | 02:47 |
| jw4 | seems like that text should be in one of the other log files under ~/.juju/ | 02:48 |
| redelmann | that's why im looking in machine0 logs | 02:48 |
| jw4 | that error would have come from one of the units; what other machine logs do you have under ~/.juju ? | 02:49 |
| redelmann | jw4, i cant see any log in ~/.juju/ | 02:49 |
| redelmann | jw4, all unit say the same | 02:49 |
| redelmann | jw4, actually im deploying to aws | 02:50 |
| jw4 | redelmann: ya, I see that environment | 02:50 |
| redelmann | jw4, juju keep log in ~/.juju if deploying to aws? | 02:50 |
| jw4 | redelmann: I think it'd be on the machine that's having trouble upgrading | 02:51 |
| jw4 | redelmann: how many machines do you have deployed? | 02:58 |
| redelmann | jw4, seven | 02:59 |
| jw4 | redelmann: which machine is unit-pgsql-medium-0 on? | 02:59 |
| jw4 | redelmann: also, machine-0 should have all-machines.log in the /var/log/juju folder | 03:00 |
| redelmann | jw4, you are right | 03:01 |
| redelmann | give me a second | 03:01 |
| jw4 | redelmann: certainly, thanks! | 03:02 |
| redelmann | im scping it | 03:02 |
| mup | Bug #1438489 was opened: juju stop responding after juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1438489> | 03:02 |
| redelmann | jw4, im uploading complete file, this happend today. | 03:04 |
| jw4 | redelmann: thanks; I'll review that. I'm going to be out for 30 minutes or so, but I'll brb | 03:04 |
| redelmann | jw4, ok, i attached it to https://bugs.launchpad.net/juju-core/+bug/1438489 | 03:06 |
| mup | Bug #1438489: juju stop responding after juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1438489> | 03:06 |
| jw4 | thanks | 03:06 |
| davecheney | cherylj: do you need some reviews done ? | 03:10 |
| davecheney | OH MY GOD | 03:16 |
| davecheney | why does juju depend on ajstarks/svgo !?!? | 03:16 |
| davecheney | how is that possibly necessary for the core operation of juju ? | 03:16 |
| wallyworld_ | axw_: only if you feel like it/have time, there's a juju status review which is the first 3 or so branches which would be good to get looked at http://reviews.vapour.ws/r/1334, otherwise i'll bug william when he's net online | 03:23 |
| axw_ | wallyworld_: just started looking, it's quite involved. I'd like to get some of my stuff proposed, hope to take a look later on | 03:24 |
| wallyworld_ | sure np | 03:24 |
| wallyworld_ | i an talk you through anything if needed | 03:24 |
| wallyworld_ | i'll have another proposed straight after, and then a 3rd hopefully later today | 03:25 |
| redelmann | jw4, ok, i "fix" it | 03:27 |
| redelmann | jw4, http://paste.ubuntu.com/10710367/ | 03:30 |
| redelmann | jw4, after that it upgrade fine | 03:30 |
| redelmann | so, it keep saying cannot read "/var/lib/juju/agents/unit-xxx-0/state/uniter": invalid operation state: unexpected hook info with Kind Continue | 04:55 |
| jw4 | redelmann: yeah | 04:55 |
| redelmann | jw4, but now i can juju status ;) | 04:55 |
| jw4 | the basic issue is that in 1.23 the uniter does not expect there to be hook information in the uniter state except when it's actually running a hook | 04:56 |
| redelmann | jw4, any workaround? like deleting /var/lib/juju/agents/unit-xxx-0/state/uniter? | 04:56 |
| jw4 | redelmann: the upgrade steps were supposed to remove the unnecessary hook info from the uniter state file, but apparently it didn't work | 04:56 |
| jw4 | redelmann: if you can find the uniter state file (yaml) and just delete the hook and then restart the uniter, it *might* fix it :) | 04:57 |
| redelmann | jw4, i will try | 04:58 |
| jw4 | redelmann: it should just be called uniter I believe | 05:00 |
| redelmann | mh... | 05:01 |
| redelmann | filter.go:137 cannot retrieve meter status for unit ganglia/0: not found | 05:01 |
| redelmann | maybe writing a working uniter | 05:02 |
| jw4 | redelmann: I'm not sure about that one (possibly upgrade related too, but I'm not familiar with that part) | 05:02 |
| redelmann | jw4, thats happend after deleting uniter file | 05:02 |
| jw4 | redelmann: oh. yeah. I wouldn't delete the uniter file | 05:02 |
| redelmann | jw4, this one: /var/lib/juju/agents/unit-xxx-0/state/uniter | 05:02 |
| redelmann | oh | 05:03 |
| jw4 | redelmann: inside that file there should be a line (in yaml format) signifying the hook | 05:03 |
| jw4 | if you just update the yaml so there is no hook key/value | 05:03 |
| jw4 | that *might* work | 05:03 |
| jw4 | redelmann: unfortunately it's past my bedtime, and my wife has been waiting for me to come to bed for 45 minutes now :( | 05:06 |
| jw4 | redelmann: :) I'll check in again in the morning | 05:06 |
| redelmann | jw4, thank you | 05:06 |
| redelmann | jw4, have a good night | 05:06 |
| jw4 | thanks redelmann you have a great morning/afternoon/night day :) | 05:07 |
| mattyw | morning everyone | 06:23 |
| tasdomas | dimitern, thanks for going through my reviews, much appreciated | 07:44 |
| dimitern | tasdomas, no worries | 07:45 |
| dimitern | tasdomas, aren't you ready to graduate btw ? :) | 07:45 |
| tasdomas | dimitern, well, that's not really up to me to decide ;-] | 07:46 |
| dimitern | tasdomas, I think you are, but I'll have a chat with cmars as well | 07:46 |
| tasdomas | dimitern, but what I find really holding me back in some reviews is lack of knowledge of certain parts of juju | 07:47 |
| dimitern | tasdomas, that will come in time, but when unsure about some part of the code, you should ask questions :) | 07:48 |
| voidspace | morning all | 08:00 |
| dimitern | morning voidspace | 08:00 |
| voidspace | o/ | 08:00 |
| TheMue | morning o/ | 08:00 |
| TheMue | dimitern: the described network problem isn't visible in the clients log. sadly I cannot grab the log of the VM | 08:07 |
| TheMue | dimitern: here you can see that downloads from the maas controller fail | 08:07 |
| TheMue | dimitern: also connections to 169.254.169.254 timeout | 08:09 |
| voidspace | TheMue: o/ | 08:09 |
| TheMue | dimitern: so that's why I think the network setup on the node fails after the changes | 08:09 |
| TheMue | voidspace: o/ | 08:09 |
| dimitern | TheMue, hmm - can you ssh into the node after it failed and check /var/log/cloud-init-output.log? | 08:12 |
| TheMue | dimitern: with the written release we've added the gathering of a primary interface out of the lshw data which is used in newCloudinitConfig() | 08:12 |
| TheMue | dimitern: I'll see if I can | 08:13 |
| dimitern | TheMue, yes, in order to determine which interface to bind into the juju-br0 bridge at cloud-init initial boot | 08:13 |
| TheMue | dimitern: yep, this has been with 1.20.12 | 08:14 |
| TheMue | dimitern: only checked back where it has been changed | 08:14 |
| dimitern | TheMue, yeah, I remember I did this to fix another bug about not using the correct primary interface for the bridge | 08:15 |
| TheMue | ok, while client is still waiting the new node at least gave up | 08:16 |
| dimitern | TheMue, ok, I think this can be faked - if getting the ifaceInfo and the primary interface fails, try using "eth0" as primary interface for newCloudinitConfig() | 08:17 |
| TheMue | now I only have the problem to log in | 08:17 |
| dimitern | TheMue, maybe the ssh keys where not set? | 08:17 |
| TheMue | dimitern: same setting as yesterday | 08:17 |
| TheMue | dimitern: but don't know how far they are distributed to the node | 08:18 |
| dimitern | TheMue, no, I mean if cloud-init failed to complete for some reason, the ssh keys might not be set on the node | 08:18 |
| dimitern | TheMue, cloud-init sets the keys | 08:18 |
| TheMue | dimitern: yep, that could be the reason | 08:19 |
| TheMue | dimitern: my node dislikes me because I corrupted its data :,( | 08:19 |
| TheMue | dimitern: :) | 08:20 |
| TheMue | dimitern: will do the eth0 approach, should be quickly done | 08:20 |
| dimitern | TheMue, it's not the node - that's a case of juju not generating the userdata correctly so the node cannot boot properly :) | 08:21 |
| TheMue | dimitern: damn security, thought we're building OPEN source *rofl* | 08:21 |
| dimitern | TheMue, try that workaround I suggested - destroy and cleanup to start afresh, then use "eth0" as primaryNIC if lshw cannot be parsed | 08:21 |
| * TheMue btw loves his MAAS environment | 08:26 | |
| axw_ | wallyworld_: published some comments on your PR | 08:28 |
| === axw_ is now known as axw | ||
| TheMue | dimitern: no real change, the missing interface information leads to >> 2015-03-31 08:29:49 DEBUG juju.provider.maas environ.go:807 node "/MAAS/api/1.0/nodes/node-4a6120e6-d6ea-11e4-a9b5-000c2975eaae/" network information: []network.Info(nil) | 08:37 |
| TheMue | dimitern: already a bit earlier >> 2015-03-31 08:29:49 DEBUG juju.provider.maas environ.go:760 node "/MAAS/api/1.0/nodes/node-4a6120e6-d6ea-11e4-a9b5-000c2975eaae/" has network interfaces map[] | 08:38 |
| dimitern | TheMue, that could be fine, all it matters is the generated userdata for cloud-init and the node booting ok | 08:39 |
| dimitern | TheMue, did it finish? | 08:39 |
| TheMue | dimitern: looks like before, no action anymore on the node while the client is still "deploying" (repeating this log entry until timeout) | 08:40 |
| dimitern | TheMue, did you use --debug with bootstrap? | 08:40 |
| dimitern | TheMue, it will help if you can paste the output :) | 08:41 |
| TheMue | dimitern: yes, that's where those two lines above are coming from | 08:41 |
| TheMue | dimitern: will create a paste when the timeout is done so that the whole debug log is in | 08:42 |
| dimitern | TheMue, ok | 08:42 |
| TheMue | dimitern: the one I've mailed to you is also debug, see the top line how I'm deploying | 08:43 |
| TheMue | dimitern: fresh-ducks.local is my corrupted node ;) | 08:43 |
| dimitern | TheMue, hmm.. well it seems to me some more debug logging is needed around newCloudinitUserdata to show what's generated | 08:45 |
| TheMue | dimitern: will log it | 08:47 |
| * TheMue just receive a warning by the national weather service, winds will get really strong today :/ | 08:48 | |
| voidspace | TheMue: we've had strong winds all night, continuing now | 08:56 |
| TheMue | voidspace: it will reach its top here between 2 and 6pm, and our neighbor has still two very high trees on her ground which always sway extreme. during the last storm one felt, thankfully not into our direction | 08:57 |
| mattyw | dimitern, ping? | 08:59 |
| dimitern | mattyw, hey | 08:59 |
| dimitern | voidspace, standup? | 09:01 |
| voidspace | dimitern: omw | 09:01 |
| mup | Bug #1438590 was opened: juju version tries to make directories and files in my home <landscape> <juju-core:New> <https://launchpad.net/bugs/1438590> | 09:27 |
| dimitern | dooferlad, so just calling c.SpaceCommandBase.SetFlags(f) in c.SetFlags() works | 09:44 |
| TheMue | dimitern: String method sadly had same troubles with references as values in map[string]interface{}, so had to use the renderer way | 10:24 |
| TheMue | dimitern: here is the according output http://paste.ubuntu.com/10711305/ | 10:24 |
| dimitern | TheMue, ok, this looks fine to me | 10:26 |
| dimitern | TheMue, does it still fail to boot? | 10:26 |
| TheMue | dimitern: yep, still the same failing behavior | 10:26 |
| TheMue | dimitern: while when using a not corrupted node it works | 10:27 |
| dimitern | TheMue, can you try ssh into it? | 10:27 |
| dimitern | TheMue, while the bootstrap goes on? it should be possible after retrying for a while (might not be possible immediately) | 10:27 |
| TheMue | dimitern: yes, currently rejected | 10:28 |
| TheMue | dimitern: still Permission denied (publickey). | 10:30 |
| dimitern | TheMue, try: ssh -i ~/.juju/ssh/id_rsa ubuntu@IP | 10:31 |
| TheMue | dimitern: still the same | 10:32 |
| TheMue | dimitern: at least it's pingable | 10:34 |
| dimitern | TheMue, can you see the console of the VM ? | 10:34 |
| TheMue | dimitern: if the ubuntu user would have a standard password I could login directly on the console | 10:34 |
| dimitern | TheMue, nope, that won't work unfortunately | 10:35 |
| TheMue | dimitern: I know, sadly | 10:36 |
| dimitern | TheMue, maybe the VM is still booting - do you see any messages on the console? | 10:36 |
| TheMue | dimitern: only the login screen | 10:37 |
| dimitern | TheMue, try with your ssh key configured in maas? | 10:38 |
| TheMue | dimitern: the last interesting part have been messages that downloads from controller and this 169... failed | 10:38 |
| TheMue | dimitern: that's what I'm doing, using that key | 10:38 |
| TheMue | dimitern: I'll bootstrap to a valid node and see what the cloudinit looks there | 10:44 |
| dimitern | TheMue, did you try both the juju_id_rsa key *any* your key? | 10:45 |
| dimitern | s/*any*/*and*/ | 10:46 |
| TheMue | dimitern: my key | 10:46 |
| TheMue | dimitern: http://paste.ubuntu.com/10711389/ | 10:47 |
| dimitern | TheMue, well, that's why I wrote this earlier: <dimitern> TheMue, try: ssh -i ~/.juju/ssh/id_rsa ubuntu@IP | 10:47 |
| dimitern | TheMue, that's the juju ssh key | 10:47 |
| TheMue | dimitern: eh, sorry, sure, took it too | 10:48 |
| dimitern | TheMue, so both you couldn't ssh with either key | 10:48 |
| dimitern | s/both/both/ | 10:49 |
| dimitern | aargh | 10:49 |
| dimitern | s/both//\ | 10:49 |
| TheMue | dimitern: hehe, yes | 10:49 |
| TheMue | dimitern: and you're right, the cloudinit looks similar, only the host names | 10:49 |
| TheMue | dimitern: I send you a screenshot of the console. does this help to get in? sadly I cannot cut'n'paste, but enter the key by hand | 11:01 |
| TheMue | wife calls for lunch, bbiab | 11:03 |
| voidspace | Code comments: https://twitter.com/nzkoz/status/538892801941848064/photo/1 | 11:03 |
| dimitern | voidspace, dooferlad, please have a look - juju subnet CLI http://reviews.vapour.ws/r/1339/ | 11:30 |
| dimitern | TheMue, that screenshot is too small to read, unfortunately | 11:37 |
| * fwereade swings by quickly to say: sorry sick yesterday, public holiday today, should be around properly later to catch up a bit | 11:37 | |
| voidspace | dimitern: looking after coffee | 11:45 |
| TheMue | dimitern: hmm, it is sent in full size, strange | 11:57 |
| dimitern | voidspace, I'm in a call with spakiegeek now investingating an issue with maas and juju | 11:59 |
| dimitern | voidspace, it seems we're not out of the rabbit hole yet | 12:00 |
| dimitern | voidspace, I'm getting logs to help debugging the issue | 12:00 |
| dimitern | voidspace, he'll file a bug with details | 12:01 |
| dimitern | voidspace, it's a separate issue than the one you fixed, but also revolves around parsing lshw properly | 12:02 |
| dimitern | TheMue, ah, so it's just that thunderbird is dump - I managed to zoom in using a copy of the screenshot in gimp | 12:04 |
| dimitern | TheMue, that screen is from too early in the boot process | 12:05 |
| dimitern | TheMue, we should do a screensharing session I think to diagnose the issue | 12:06 |
| dimitern | TheMue, it won't work by just describing what you see :) | 12:06 |
| TheMue | dimitern: just doing some preparations | 12:14 |
| TheMue | dimitern: so, sent you an invitation, we'll see how it works | 12:19 |
| dimitern | TheMue, brt | 12:19 |
| voidspace | dimitern: ah, right :-/ | 12:26 |
| voidspace | dimitern: so after #1339 there will be a "subnets" super command, but it will do nothing? | 12:33 |
| voidspace | dimitern: wouldn't it be better to add the functionality first and do the CLI as the last bit - or have I misunderstood? | 12:33 |
| voidspace | "subnet create" anyway | 12:33 |
| dooferlad | voidspace: the idea is to do CLI before API, so we know what the API needs to provide. We know what commands we want already (see Juju Network Model document) | 12:34 |
| voidspace | dooferlad: right, but then we're adding public facing brokenness | 12:35 |
| voidspace | dooferlad: if we know what commands we want, don't we also know what API we need? | 12:35 |
| dooferlad | voidspace: only to a feature branch | 12:35 |
| voidspace | ah yes, of course | 12:35 |
| voidspace | I still prefer to work the other way round | 12:35 |
| voidspace | then we don't *need* a long lived feature branch | 12:35 |
| dooferlad | voidspace: We have a pretty good idea about what the API needs to provide, but this way we don't end up designing endpoints that are a bad fit for the code that is using them. | 12:36 |
| dimitern | voidspace, sorry, in a call again | 12:37 |
| voidspace | dooferlad: ok | 12:37 |
| voidspace | dimitern: np | 12:37 |
| dimitern | voidspace, the CLI returns an error when you try to use it | 12:39 |
| voidspace | dimitern: well exactly :-) | 12:40 |
| voidspace | dimitern: CLI commands that do nothing but error out shouldn't exist... | 12:40 |
| voidspace | dimitern: why do you need the --private option? | 12:40 |
| voidspace | dimitern: if it's the default it does nothing | 12:41 |
| voidspace | dimitern: flag I mean | 12:41 |
| voidspace | specifying it does nothing and it's existence is causing you pain in the code | 12:41 |
| voidspace | dimitern: why not just have --public ? | 12:41 |
| dimitern | voidspace, we always went with the approach "state / api first, cli last" and that bit us on more than one occasion | 12:42 |
| voidspace | dimitern: ok, interesting | 12:42 |
| voidspace | I'm definitely in favour of *designing* the CLI, just not necessarily implementing it first | 12:42 |
| dimitern | voidspace, so starting from the CLI with stub API is the new way I'd like to try now | 12:43 |
| voidspace | but as it's on a feature branch it doesn't matter so much anyway | 12:43 |
| voidspace | dimitern: ok | 12:43 |
| dimitern | voidspace, so by the time we reach state /api we already know what's needed | 12:43 |
| dimitern | voidspace, the --private being the default comes as a requirement from mark | 12:43 |
| voidspace | dimitern: fine. In that case the "--private" flag is superfluous, it does nothing. | 12:44 |
| dimitern | voidspace, it's part of the spec though | 12:44 |
| voidspace | dimitern: just say, "networks are private by default, unless you pass the --public flag" | 12:44 |
| voidspace | dimitern: heh | 12:44 |
| voidspace | it does *nothing* | 12:44 |
| dimitern | voidspace, yeah that's correct | 12:45 |
| dooferlad | voidspace: well, it is an exciting way of starting an IRC conversation :-) | 12:45 |
| voidspace | heh | 12:46 |
| dooferlad | ... just like the name "space" | 12:46 |
| voidspace | dimitern: other than that (and feel free to drop my issue - I meant it as a comment) it all looks good to me | 12:47 |
| voidspace | dimitern: mostly boilerplate except for the parameter checking, which all looks fine | 12:47 |
| dimitern | voidspace, sorry, I'm looking at your review now | 13:02 |
| dimitern | voidspace, yes, having --private seems redundant, but it's part of the spec | 13:03 |
| dimitern | voidspace, I'll add a comment | 13:03 |
| TheMue | A large tree crashed our car, shit. I'm off for some time. | 13:06 |
| dimitern | TheMue, oh that's bad :( | 13:06 |
| jw4 | TheMue: shoot | 13:06 |
| jw4 | TheMue: after all that felling of trees one still got your car!? | 13:07 |
| dimitern | TheMue, I hope the damage is not extensive | 13:11 |
| wallyworld | fwereade: andrew has looked at http://reviews.vapour.ws/r/1334/, it you get time would love it if you could look too | 13:12 |
| TheMue | the rear is totally crashed | 13:12 |
| dimitern | TheMue, oh dear :( | 13:12 |
| dimitern | TheMue, well, the only thing I could do is offer you to take a day off if you need to sort things out :/ | 13:13 |
| dooferlad | TheMue: Yikes! I hope your insurer is efficient :-| | 13:16 |
| mup | Bug #1438683 was opened: Containers stuck allocating, interface not up <cloud-installer> <landscape> <juju-core:New> <https://launchpad.net/bugs/1438683> | 13:22 |
| dimitern | voidspace, dooferlad, I've replied to your review comments; thanks! | 13:32 |
| dooferlad | dimitern: who knew one little flag would cause so much typing :-) | 13:33 |
| dimitern | voidspace, I've also triaged that maas bug ^^ and added a comment capturing what me and sparkiegeek discovered so far, which will possibly help finding the issue | 13:34 |
| voidspace | dimitern: yeah, I've been reading it | 13:34 |
| dimitern | dooferlad, indeed :) | 13:34 |
| voidspace | sounds like a mess... :-/ | 13:34 |
| dimitern | voidspace, yep :( workarounds biting us back, as usual | 13:34 |
| dimitern | if only maas had usable api :) | 13:34 |
| joec1 | Hi folks and esteemed juju devs, apologies for the impertinent question but are there any known issues getting juju to work in Azure (aside from the bug reports)? | 13:40 |
| natefinch | alexisb: sorry, I had hoped the baby wasn't audible over the headset mic.... guess it was | 13:45 |
| alexisb | yes, and sorry I muted you but the baby cry still triggers the mommy instinct and made it hard to concentrate on what I wanted to say :) | 13:46 |
| natefinch | heh I understand | 13:46 |
| dimitern | voidspace, you should really do something to start noticing your PMs :) | 14:03 |
| anastasiamac | dimitern: tyvm for reviewing my PR | 14:25 |
| ericsnow | dimitern: PTAL http://reviews.vapour.ws/r/1234/ | 14:25 |
| anastasiamac | dimitern: i had to add unit info and change sort order for tabular format | 14:25 |
| ericsnow | dimitern: also http://reviews.vapour.ws/r/1332/ and http://reviews.vapour.ws/r/1333/ | 14:25 |
| dimitern | ericsnow, ok, I have a few already, will add them to my queue | 14:26 |
| anastasiamac | dimitern: if u have a chance if u could PTAL it again despite ur prev shipit - would be amazing! | 14:26 |
| ericsnow | dimitern: thanks | 14:26 |
| anastasiamac | dimitern: http://reviews.vapour.ws/r/1323/ | 14:26 |
| dimitern | anastasiamac, np - remind me which one? | 14:26 |
| dimitern | anastasiamac, ok, cheers | 14:26 |
| anastasiamac | dimitern: thnx ;D m EODing now 00:27 on the clock... | 14:27 |
| ericsnow | dimitern: http://reviews.vapour.ws/r/1332/ shouild be easy and is a blocker for the 1.23 release, so perhaps you could "nice" it up :) | 14:27 |
| dimitern | anastasiamac, oh that's late - have a good evening then :) | 14:27 |
| dimitern | ericsnow, ack, will start with it then | 14:27 |
| ericsnow | dimitern: thanks! | 14:27 |
| anastasiamac | dimitern: or early :D ttyl | 14:28 |
| ericsnow | cherylj: it looks like the LICENCE fixes are all done for 1.22 \o/ | 14:28 |
| ericsnow | cherylj: is that right? | 14:28 |
| cherylj | ericsnow: yes, as long as the patch for dependencies.tsv passes CI :) | 14:29 |
| ericsnow | cherylj: awesome! Thanks for tackling all that! | 14:30 |
| cherylj | ericsnow: np! | 14:30 |
| ericsnow | cherylj: be sure to mark the bug as "fix committed" for 1.22 | 14:30 |
| cherylj | thanks for the reminder :) | 14:31 |
| cherylj | hooray! it passed CI | 14:32 |
| mup | Bug #1438721 was opened: sync-tools does not support patch versions <juju-core:New> <https://launchpad.net/bugs/1438721> | 14:34 |
| natefinch | abentley: where can I find the code for the CI tests? | 14:40 |
| aznashwan | dimitern, voidspace: ping | 14:40 |
| dimitern | aznashwan, pong | 14:40 |
| abentley | natefinch: lp:juju-ci-tools | 14:40 |
| voidspace | aznashwan: pong | 14:41 |
| natefinch | abentley: sigh.. launchpad, huh? | 14:41 |
| aznashwan | dimitern: could I bother you guys with what looks like a horrendously huge review but there's actually little to it: http://reviews.vapour.ws/r/1330/ :D | 14:41 |
| dimitern | aznashwan, I'm about 33% done with that monster branch of yours about cloudinit | 14:41 |
| dimitern | :) | 14:41 |
| abentley | natefinch: of course! | 14:41 |
| aznashwan | dimitern: great | 14:41 |
| aznashwan | dimitern: as said there, most of it's relocated code | 14:42 |
| dimitern | aznashwan, why did you decide to rename MachineConfig to InstanceConfig? | 14:42 |
| dimitern | aznashwan, that definitely blew up the diff considerably | 14:42 |
| aznashwan | dimitern: that was bogdanteleaga's doing at the suggestion of one of you guys | 14:43 |
| dimitern | aznashwan, I see | 14:44 |
| dimitern | ok then | 14:44 |
| aznashwan | dimitern: he'd be the better half to ask about this | 14:44 |
| dimitern | aznashwan, ok, thanks | 14:45 |
| bogdanteleaga | dimitern, it was done after some consulting with william; in hindsight it might not have been the best idea exactly because it ended up making the diff humongous, but there's not much to see outside of /cloudconfig | 14:47 |
| dimitern | bogdanteleaga, right, I agree it could've waited, but well .. :) | 14:51 |
| TheMue | dimitern: dooferlad: voidspace: wow, what an organizational stuff with insurance, fire department, neighbor. will post pics later, car seems to be totally crashed | 14:51 |
| dooferlad | TheMue: time for another whisky tasting? | 14:52 |
| TheMue | dooferlad: will these eve definitely need one | 14:52 |
| dimitern | TheMue, :( too bad - hopefully the insurance will cover all | 14:52 |
| TheMue | dimitern: currently all signs are positive, looks like a 100% coverage | 14:53 |
| TheMue | better than many of our unit tests *lol* | 14:54 |
| dimitern | TheMue, good! | 14:54 |
| jw4 | TheMue: I saw that about your car - You've already had one tree fall this year, and your neighbor was felling more trees a couple weeks ago... what gives? | 14:55 |
| * natefinch tries to remember how to use bzr | 14:55 | |
| voidspace | TheMue: ouch :-/ | 14:56 |
| natefinch | abentley: do we have tests trying out HA? | 15:02 |
| natefinch | (in CI) | 15:02 |
| abentley | natefinch: Yes. See http://juju-ci.vapour.ws/job/functional-ha-backup-restore/ and http://juju-ci.vapour.ws/job/functional-ha-recovery/ | 15:03 |
| voidspace | dimitern: port is done, but not run manual tests yet | 15:07 |
| voidspace | dimitern: doing a full normal test run first | 15:07 |
| voidspace | dimitern: then can switch to the other bug | 15:07 |
| dimitern | voidspace, ok, sounds good | 15:07 |
| cherylj | natefinch, ericsnow: I'm updating the dependencies for 1.23, and I see that updating juju/names pulls in this change: https://github.com/juju/names/pull/43 | 15:08 |
| cherylj | natefinch, ericsnow: It brings in a new tag, but doesn't change any functionality. | 15:08 |
| natefinch | space tag sounds so much better than freeze tag | 15:08 |
| cherylj | natefinch, ericsnow: Will that be okay? or do we need a new branch? | 15:08 |
| cherylj | haha | 15:08 |
| natefinch | cherylj: that's expanding the API in a backwards compatible way, so I think it's fine to leave it in the same branch | 15:09 |
| natefinch | cherylj: wait sorry | 15:10 |
| natefinch | cherylj: misunderstood... yes, I think making a new branch there is the right thing to do | 15:10 |
| natefinch | cherylj: it's simple, but doesn't really belong in 1.23, and none of the rest of the code will know what to do with it | 15:10 |
| cherylj | natefinch: okay, glad I asked :) Can you create the branch? | 15:11 |
| natefinch | cherylj: do you have the right commit hash handy? | 15:11 |
| natefinch | (and yes) | 15:11 |
| natefinch | is it just the one before that space tag change? | 15:12 |
| cherylj | natefinch: ce4ecb2967822062fc606e733919c677c584ab7e | 15:12 |
| natefinch | cherylj: thanks | 15:13 |
| cherylj | np! | 15:13 |
| natefinch | cherylj: there you go | 15:15 |
| voidspace | dimitern: hah, a few calls to network.NewAddress to fix first... | 15:18 |
| cherylj | natefinch: thanks! | 15:18 |
| dimitern | voidspace, :) I dread the moment when I have to merge master into net-cli already | 15:20 |
| voidspace | dimitern: heh | 15:21 |
| voidspace | dimitern: it wasn't so many I had to do | 15:21 |
| mup | Bug #1438748 was opened: Use of /tmp/discover_init_system.sh is a security vulnerability. <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1438748> | 15:28 |
| voidspace | dimitern: so, for the "multiple networks with no index" - manually increment the index? | 15:38 |
| voidspace | dimitern: we still risk duplicating an index if there are some with suffix and some without | 15:38 |
| voidspace | dimitern: no idea if that's possible though | 15:38 |
| dimitern | voidspace, I guess that's the only thing to do | 15:38 |
| voidspace | ok | 15:39 |
| dimitern | voidspace, we should add more logging at debug level | 15:39 |
| voidspace | dimitern: ok | 15:39 |
| dimitern | voidspace, cheers | 15:39 |
| voidspace | dimitern: and I'll look through the code seeing if I can work out why we pick the disabled nic | 15:39 |
| voidspace | dimitern: it's almost certainly due to them having the same subnet (network) *or* due to the index issue | 15:40 |
| voidspace | dimitern: but it would be good to know | 15:40 |
| voidspace | dimitern: running a manual test of my 1.23 branch in parallel to doing this | 15:40 |
| natefinch | abentley: I'm trying to write a new CI test to test using ensure availability to turn existing machines in the environment into state servers. Is there documentation on how to write CI tests? It looks fairly straight forward, but docs are always helpful :) | 15:40 |
| dimitern | voidspace, yeah - it was hard to tell what's going on, but the logs should tell | 15:42 |
| abentley | natefinch: Sorry, was on a call. | 15:49 |
| natefinch | abentley: np | 15:49 |
| abentley | natefinch: There isn't documentation. Basically you need to return 0 on success and 1 on failure, and you should allow the runtime environment name to be customized, and jujupy may be helpful. | 15:51 |
| natefinch | abentley: ok, cool. It looks pretty easy, except perhaps how to add the extra jenkins job | 15:52 |
| * natefinch knows jack all about jenkins | 15:52 | |
| abentley | natefinch: when you've got a script that works locally, I can help you with getting it onto Jenkins. | 15:53 |
| abentley | natefinch: When you say "existing machines", do you mean machines that aren't provisioned by juju? | 15:54 |
| alexisb | natefinch, can we land in the HA stuff at this stage? | 15:55 |
| voidspace | dimitern: ok, so manually testing this has revealed a problem with the upgrade step... | 15:57 |
| voidspace | dimitern: and I think trunk is screwed too - I just didn't notice before | 15:57 |
| voidspace | dimitern: http://pastebin.ubuntu.com/10712911/ | 16:00 |
| voidspace | dimitern: the best fix is to have ReleaseAddress not require an instance iD | 16:01 |
| dimitern | voidspace, oh sh*t | 16:01 |
| voidspace | dimitern: I'll repeat the test for trunk, but I bet it has the same issue and I just didn't notice it before :-/ | 16:01 |
| dimitern | voidspace, this is because we need the instance id? | 16:01 |
| voidspace | dimitern: yep | 16:01 |
| dimitern | voidspace, yeah | 16:01 |
| voidspace | dimitern: but I don't think either MaaS or ec2 actually require it | 16:02 |
| dimitern | voidspace, I should've thought of that | 16:02 |
| voidspace | dimitern: so we should just drop it from the provider method signature | 16:02 |
| voidspace | if it's really not used | 16:02 |
| dimitern | voidspace, well, how do you suggest fixing it? | 16:02 |
| voidspace | dimitern: yeah, me too :-) | 16:02 |
| voidspace | dimitern: stop requiring instance ID | 16:02 |
| dimitern | voidspace, don't you need it to get the machine? | 16:02 |
| dimitern | voidspace, or we added it only because we needed it for ReleaseAddress? | 16:03 |
| voidspace | dimitern: I think we just thought we might need it | 16:03 |
| voidspace | dimitern: ah no | 16:04 |
| voidspace | dimitern: ec2 does use it | 16:04 |
| dimitern | voidspace, *whew* ok, then it's easy :) | 16:04 |
| voidspace | nope | 16:04 |
| dimitern | voidspace, oh? | 16:04 |
| voidspace | dimitern: it actually needs a nic id | 16:04 |
| voidspace | dimitern: but we get the nic id from the instance id | 16:04 |
| dimitern | voidspace, yeah | 16:04 |
| dimitern | voidspace, ok, sorry I'm a bit confused | 16:04 |
| cherylj | Can I get a couple license related reviews? http://reviews.vapour.ws/r/1342/ http://reviews.vapour.ws/r/1343/ | 16:05 |
| dimitern | voidspace, you need instance id in order to call ReleaseAddress in the worker | 16:05 |
| voidspace | dimitern: yes | 16:05 |
| voidspace | dimitern: maas doesn't use the instance id | 16:05 |
| dimitern | voidspace, you don't need instance id in the provisioner api | 16:05 |
| voidspace | dimitern: but ec2 does | 16:05 |
| voidspace | dimitern: the issue here is specifically when the upgrade runs and there are dead ip addresses | 16:06 |
| voidspace | dimitern: nothing to do with the provisioner api | 16:06 |
| voidspace | dimitern: the worker notices the dead addresses when it starts and tries to remove them | 16:06 |
| dimitern | voidspace, ok | 16:06 |
| dimitern | voidspace, so we do need to pass instance id, even if it's unused | 16:06 |
| voidspace | dimitern: the addresses have a MachineId() | 16:06 |
| voidspace | dimitern: the worker tries to get the instance id from the machine - but the machine is already gone | 16:07 |
| voidspace | dimitern: Environ.ReleaseAddress takes an instance id | 16:07 |
| voidspace | dimitern: that is not used by maas, but unfortunately *is* used by ec2 | 16:07 |
| natefinch | alexisb, abentley: sorry, left for a minute to make lunch.... | 16:08 |
| dimitern | voidspace, but fortunately, in ec2 it doesn't matter | 16:08 |
| dimitern | voidspace, because if the instance is gone, all its nics and ips are gone with it | 16:08 |
| natefinch | alexisb: I can land it by EOD. I have to do a few trivial code review cleanup things and write a couple trivial unit tests, and then I can start working on the CI tests | 16:09 |
| voidspace | dimitern: ok, so we need a way to release the address for maas | 16:09 |
| dimitern | voidspace, so I guess it only matters for maas - we need to release the addresses, but instance id can be empty | 16:09 |
| dimitern | voidspace, it can be a special value like instance.UnknownId ? | 16:09 |
| voidspace | dimitern: ok, fine | 16:09 |
| voidspace | dimitern: and ec2 will make that a no-op | 16:09 |
| natefinch | abentley: I mean machines that have been added to the juju environment, either through deploy or add-machine. So, like, you could do juju ensure-availability --to 1,2 and convert machines 1 and 2 into state machines | 16:09 |
| voidspace | dimitern: whereas maas will release the address | 16:09 |
| voidspace | dimitern: fine - thanks | 16:10 |
| dimitern | voidspace, exactly - the upgrade step should try a best effort, but not fail if instance id cannot be found | 16:10 |
| abentley | natefinch: Cool. I was thinking this might be something like the manual provider. We have a solution for testing the manual provider, but it's not the cleanest. | 16:11 |
| natefinch | abentley: nope, pretty easy, really... just like the other HA tests./.. just bootstrap, juju add-machine -n 2, wait for them to come up, then juju ensure-availability --to 1,2 and then wait for HA. | 16:12 |
| dimitern | ericsnow, re http://reviews.vapour.ws/r/1332/ - it seems it just drops upstart-specific confs | 16:12 |
| abentley | natefinch: great. | 16:12 |
| ericsnow | dimitern: that is correct | 16:12 |
| dimitern | ericsnow, shouldn't it only drop them when systemd is used? | 16:12 |
| ericsnow | dimitern: we don't need them for upstart either | 16:13 |
| dimitern | ericsnow, i.e. isn't that strictly worse than before? | 16:13 |
| dimitern | ericsnow, ok, if they're not used for upstart fair enough | 16:13 |
| ericsnow | dimitern: they are just clutter since we generate a new upstart conf when we bootstrap | 16:13 |
| dimitern | ericsnow, I'll take your word for it though :) | 16:13 |
| dimitern | ericsnow, ok, that makes sense | 16:14 |
| dimitern | ericsnow, thanks! | 16:14 |
| ericsnow | dimitern: if restore were more than replace-the-old-state server then we would have a different story :) | 16:14 |
| dimitern | ericsnow, LGTM then | 16:14 |
| ericsnow | dimitern: thanks | 16:14 |
| natefinch | I love it when writing documentation for code reveals a bug. | 16:17 |
| dimitern | natefinch, it's worse when it reveals a bug in the spec :) | 16:18 |
| natefinch | dimitern: heh | 16:18 |
| natefinch | dimitern: I actually wasn't being sarcastic. I actually do like it when that happens. Better than not finding the bug until later :) | 16:19 |
| natefinch | dimitern: btw, are watchers fired off serially, or do I need a lock in my Handle() method in case two get fired off in quick succession? | 16:19 |
| dimitern | natefinch, you're using the same handler for 2 watchers? brave! :) | 16:23 |
| natefinch | dimitern: no no... but if there's two changes back to back | 16:23 |
| dimitern | natefinch, the watcher should coalesce events properly | 16:24 |
| natefinch | dimitern: not exactly filling me with confidence ;) | 16:24 |
| dimitern | natefinch, well, it depends if the watcher is working properly :) | 16:25 |
| natefinch | lol | 16:25 |
| natefinch | ok | 16:25 |
| cherylj | natefinch: we also need to branch juju/utils for 1.23 at commit 3efdaa3f15cc47ee83f6c03f640dc14f5915e289 | 16:34 |
| natefinch | cherylj: done | 16:35 |
| * natefinch is getting the hang of this git thing. ;) | 16:36 | |
| cherylj | natefinch: thanks! I'm not sure if we need to branch testing too... It pulls in https://github.com/juju/testing/pull/55 and https://github.com/juju/testing/pull/56 | 16:37 |
| alexisb | natefinch, awesome thank you | 16:37 |
| natefinch | cherylj: to be on the safe side, I think I would | 16:38 |
| cherylj | natefinch: okay, the commit to branch from there is: c07aef9cb4f2ff1db7ddc9d43a0ea88eca39c9ea | 16:38 |
| natefinch | cherylj: done | 16:39 |
| cherylj | natefinch: thanks! | 16:39 |
| natefinch | cherylj: welcome :) | 16:41 |
| === natefinch is now known as natefinch-afk | ||
| mup | Bug #1438798 was opened: juju sync-tools requires default environment <juju-core:New> <https://launchpad.net/bugs/1438798> | 16:58 |
| alexisb | voidspace, you still around? | 17:11 |
| cherylj | natefinch-afk: I think we can get away with not branching juju/charm for 1.23. It just pulls in this: https://github.com/juju/charm/pull/82 | 17:35 |
| cherylj | natefinch-afk: what do you think? | 17:35 |
| === natefinch-afk is now known as natefinch | ||
| natefinch | cherylj: lgtm | 17:37 |
| cherylj | natefinch: thanks1 | 17:37 |
| voidspace | alexisb: yep | 17:39 |
| voidspace | alexisb: just, about to go | 17:39 |
| wwitzel3 | is there an example of putting a provider behind a feature flag? not exactly sure how to approach this | 17:39 |
| cherylj | natefinch: could you review a few more of the license changes? http://reviews.vapour.ws/r/1342/ http://reviews.vapour.ws/r/1343/ http://reviews.vapour.ws/r/1345/ http://reviews.vapour.ws/r/1346/ | 17:39 |
| alexisb | voidspace, looks like you picked up a new bug today for 1.23 | 17:39 |
| voidspace | alexisb: yep | 17:39 |
| alexisb | I was just curious the scope of work | 17:39 |
| voidspace | alexisb: two I think :-/ | 17:40 |
| alexisb | yay! | 17:40 |
| voidspace | alexisb: should be able to land both in the next two days - one per day, maybe quicker | 17:40 |
| voidspace | alexisb: I need to file the second one | 17:40 |
| alexisb | great thank you that is what I needed | 17:40 |
| voidspace | alexisb: the one that is filed is a *little bit* unknown | 17:40 |
| voidspace | alexisb: so it *could* explode :-) | 17:40 |
| voidspace | alexisb: but we don't think so | 17:40 |
| alexisb | voidspace, ok, keep me posted | 17:41 |
| voidspace | alexisb: will do | 17:41 |
| natefinch | cherylj: I'm kinda slammed getting some critical code into 1.23, maybe someone else could do the review, like voidspace or ericsnow or cmars or wwitzel3 | 17:42 |
| cherylj | ah, okay, thanks | 17:42 |
| cmars | cherylj, about to head out for lunch, can take a look in a little bit | 17:43 |
| cherylj | thanks, cmars | 17:44 |
| voidspace | alexisb: actually 3 bugs | 17:46 |
| voidspace | alexisb: for 1.23 | 17:46 |
| cherylj | ah, ericsnow got 'em. Thanks, ericsnow! | 17:46 |
| ericsnow | cherylj: they all LGTM | 17:46 |
| cherylj | thanks!! | 17:46 |
| voidspace | alexisb: bug 1438820 | 17:46 |
| mup | Bug #1438820: IP address life field upgrade step and addresser worker don't play well together <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438820> | 17:46 |
| ericsnow | cherylj: good catch on the blobstore dep :) | 17:46 |
| voidspace | bug 1438683 | 17:46 |
| mup | Bug #1438683: Containers stuck allocating, interface not up <add-machine> <cloud-installer> <landscape> <maas-provider> <network> <juju-core:Triaged by mfoord> <https://launchpad.net/bugs/1438683> | 17:46 |
| voidspace | bug 1438168 | 17:46 |
| mup | Bug #1438168: juju 1.23 doesn't release IP addresses for containers <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438168> | 17:46 |
| alexisb | voidspace, are you thinking a day for each? | 17:47 |
| alexisb | any you think could be deferred to a point release? | 17:47 |
| voidspace | alexisb: one of them is done but blocked on the other two | 17:47 |
| voidspace | alexisb: so still two days for all of them is my thinking | 17:47 |
| voidspace | alexisb: bug 1438168 is complete but in testing it I discovered bug 1438820 that also affects trunk | 17:48 |
| mup | Bug #1438168: juju 1.23 doesn't release IP addresses for containers <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438168> | 17:48 |
| mup | Bug #1438820: IP address life field upgrade step and addresser worker don't play well together <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438820> | 17:48 |
| voidspace | alexisb: but it is 3 bugs / 3 branches | 17:48 |
| alexisb | voidspace, ok, now go enjoy your evening | 17:50 |
| alexisb | thanks for the info | 17:50 |
| cherylj | ericsnow: I'm glad you commented that you couldn't see the review on RB. I saw that I created that pull request against the wrong branch! | 17:52 |
| cherylj | ericsnow: here's the correct branch: http://reviews.vapour.ws/r/1347/ | 17:53 |
| ericsnow | cherylj: LGTM | 17:53 |
| cherylj | ericsnow: thanks again! | 17:53 |
| ericsnow | cherylj: np | 17:53 |
| mup | Bug #1438820 was opened: IP address life field upgrade step and addresser worker don't play well together <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438820> | 17:58 |
| natefinch | thumper: are you actually on? | 17:59 |
| === joec1 is now known as joec1afk | ||
| === joec1afk is now known as joec1 | ||
| natefinch | so, you're supposed to use UnitsWatcher to watch Machines... makes total sense | 18:50 |
| alexisb | natefinch, fwereade would have lots to say about that (this is one of the areas he wants to clean up really badly) | 18:57 |
| natefinch | alexisb: heh... yeah, this is the first time I've delved into watchers and stuff, and there's some interesting choices being made in there... I'm sure they each made sense at the time | 19:00 |
| thumper | natefinch: no, I wasn't | 19:55 |
| thumper | obviously forgot to close IRC last night | 19:55 |
| natefinch | thumper: heh, figured | 19:55 |
| natefinch | thumper: 7am isn't your usual start time :) | 19:55 |
| thumper | nope, it isn't | 19:56 |
| natefinch | thumper: I had some questions about watchers and the API, but I think I figured it out from reading other API facades | 19:56 |
| thumper | awesome | 19:56 |
| ericsnow | davecheney: in case you missed it (re: gccgo in vivid): https://lists.ubuntu.com/archives/ubuntu-devel/2015-March/038740.html | 19:58 |
| natefinch | ericsnow: yeah, I saw that, but uh, joining ubuntu-devel to respond is kinda a high barrier of entry. I think putting gccgo and go as different effective versions is a really bad idea. | 19:59 |
| ericsnow | natefinch: yeah, I was thinking that too :) | 19:59 |
| thumper | ericsnow: dave is off now for a while | 19:59 |
| ericsnow | thumper: k | 20:00 |
| thumper | off until he flies to eurpoe, next week sprinting on arm64 go stuff, then meeting us in Nuremberg | 20:00 |
| ericsnow | thumper: ah | 20:00 |
| natefinch | oh amazon, you're so slow... | 20:57 |
| natefinch | bbl | 21:02 |
| === natefinch is now known as natefinch-dinnne | ||
| === natefinch-dinnne is now known as natefinch-dinner | ||
| mup | Bug #1436655 was opened: gce provider should stop using deprecated zone europe-west1-a <gce-provider> <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1436655> | 21:17 |
| ericsnow | wwitzel3: would you mind assigning the GCE issues you are working on to yourself | 21:24 |
| ericsnow | wwitzel3: there are 2 right? | 21:25 |
| * thumper moves to the coffee shop to see if a change of scenery will help with focus | 21:40 | |
| ericsnow | cherylj: so all 1.23 changes are wrapped up now, right? :) | 22:13 |
| cherylj | ericsnow: yes :) | 22:13 |
| ericsnow | cherylj: lol, too many channels | 22:14 |
| cherylj | hehe :) | 22:14 |
| cherylj | natefinch-dinner: In updating the dependencies for juju master, I see a new repo, juju/jujusvg which is using the LGPL, but doesn't mention the exception found in other repos. Should I add it in? | 22:44 |
| ericsnow | could anyone spare me a review on http://reviews.vapour.ws/r/1349/ and http://reviews.vapour.ws/r/1350/? | 22:44 |
| redelmann_ | Hello, is safe to have two enviroments in same AWS account? | 23:15 |
| redelmann_ | juju destroy-enviroment --force will kill everithing in aws? or just instances of enviroment? | 23:16 |
| thumper | redelmann_: interesting question... | 23:25 |
| thumper | redelmann_: in theory, it should be fine | 23:25 |
| thumper | redelmann_: in practice, I'd test it first | 23:25 |
| thumper | redelmann_: it should be fine, so if it isn't, please make sure you file a bug | 23:26 |
| thumper | could just be my paranoia | 23:26 |
| redelmann_ | thumper, I tried it a while ago and juju terminate all my instances (juju 1.20 i think) | 23:28 |
| redelmann_ | thumper, thats why i asking about this | 23:28 |
| thumper | redelmann_: can you file a bug please? | 23:29 |
| thumper | also though... | 23:29 |
| thumper | you shouldn't need to use --force | 23:30 |
| thumper | that is a very "last resort" mechanism for cleaning up an environment | 23:30 |
| wallyworld_ | axw: after school drop off did we need to catch up about storage since we missed the standup? | 23:38 |
| axw | wallyworld_: I don't have much to talk about. I'm going to propose storageprovisioner changes today, assuming I get enough test coverage done | 23:39 |
| axw | can do if you like tho | 23:39 |
| wallyworld_ | all good, maybe we can touch base this arvo if needed | 23:40 |
| axw | wallyworld_: ok. gotta go help get the kids ready, bbl | 23:40 |
| wallyworld_ | ttyl | 23:40 |
| ericsnow | wallyworld_: if you have a few minutes, could you take a look at http://reviews.vapour.ws/r/1349/ and http://reviews.vapour.ws/r/1350/? | 23:49 |
| ericsnow | wallyworld_: they are both for 1.23 | 23:49 |
| wallyworld_ | ok | 23:50 |
| ericsnow | wallyworld_: thanks | 23:50 |
| redelmann_ | thumper, ok | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!