| wallyworld | davecheney: hiya, who do we assign the static linking bug to in order to get the packaging fixed? | 02:23 |
|---|---|---|
| davecheney | wallyworld: its weird | 02:26 |
| davecheney | it should already be fixed | 02:26 |
| davecheney | we don't do it for ppc | 02:26 |
| davecheney | i don't see why arm64 is different | 02:26 |
| davecheney | try jamespage or sinzui | 02:26 |
| wallyworld | ok, ta | 02:26 |
| wallyworld | i think that's the only issue for arm in 1.19 which is great | 02:26 |
| mwhudson | what is this issue? | 02:34 |
| davecheney | mwhudson: tools for arm64 are built against a dynamic libgo.so.5 | 02:35 |
| mwhudson | ah | 02:35 |
| davecheney | so don't run if you have got that library installed on the target | 02:35 |
| mwhudson | and this isn't the case for ppc? | 02:36 |
| mwhudson | and both build tools with "go build"? | 02:36 |
| davecheney | mwhudson: i know | 02:42 |
| davecheney | that is what is whack | 02:42 |
| davecheney | lemmie apt-get source | 02:42 |
| mwhudson | it does seem a bit unlikely | 02:43 |
| davecheney | golang_archs:= amd64 i386 armhf | 02:47 |
| davecheney | ifeq (,$(filter $(DEB_HOST_ARCH), $(golang_archs))) | 02:47 |
| davecheney | # NOTE(james-page) statically link libgo for the jujud binary for gccgo | 02:47 |
| davecheney | # this allows the binary to be re-cut for upstream tool distribution and | 02:47 |
| davecheney | # mimics the behaviour of the golang gc compiler. | 02:47 |
| davecheney | JUJUD_FLAGS:= -gccgoflags -static-libgo | 02:47 |
| davecheney | endif | 02:47 |
| davecheney | is this a double negative ? | 02:47 |
| davecheney | honeslyt we can just always pass that flag | 02:47 |
| davecheney | it does no harm if you don't compile with gccgo | 02:47 |
| davecheney | wallyworld: you can assign that issue to me if you like | 02:50 |
| davecheney | i'll figure out where the packaging branch is and propose a fix | 02:50 |
| wallyworld | ok, thanks :-) | 02:50 |
| wallyworld | axw: azure doesn't support a root-disk constraint does it? | 03:01 |
| axw | wallyworld: what's that constraint do again? specifies the size? | 03:02 |
| wallyworld | yeah | 03:02 |
| axw | wallyworld: checking. I think you specify the disk size. | 03:02 |
| === vladk|offline is now known as vladk | ||
| axw | wallyworld: actually it does: http://msdn.microsoft.com/en-us/library/azure/dn197896.aspx | 03:04 |
| wallyworld | ok, cool. thanks | 03:04 |
| axw | wallyworld: although I've just looked, and they're all 127GB | 03:05 |
| axw | wallyworld: could change in the future I guess. | 03:05 |
| wallyworld | yeah, ok. i am looking to allow providers to specify constraints that are unsupported | 03:06 |
| wallyworld | so we can log a warning or perhaps even error if users attempt to use them | 03:06 |
| wallyworld | i'll leave root-disk alone for now for azure | 03:06 |
| * davecheney plays the 'where is the package source branch' game | 03:19 | |
| davecheney | wallyworld: i can't find the packageing branch | 03:22 |
| wallyworld | ok, we can ask james or curtis | 03:22 |
| davecheney | i can make a diff, attach it to the issue | 03:22 |
| wallyworld | ok, feel free to assgn back to me and i can follow up | 03:22 |
| davecheney | done | 03:24 |
| davecheney | no thumper ? | 03:53 |
| waigani | davecheney: thumper is sick | 04:09 |
| jam | morning all | 04:09 |
| axw | morning jam | 04:09 |
| waigani | morning jam | 04:09 |
| davecheney | booh | 04:11 |
| jam | waigani: that's a shame about thumper, especially since he's on vacation next week as well. I hope he gets better. | 04:11 |
| waigani | yeah true, we better make the most of him tomorrow! | 04:11 |
| * davecheney is on vacatoin in just over 24 hours | 04:11 | |
| waigani | Hopefully I'll get my current branch landed before I go | 04:13 |
| === vladk is now known as vladk|offline | ||
| davecheney | axw: do you know offhand if inside juju we set any signal handlers ? | 05:42 |
| axw | davecheney: we do indeed | 05:42 |
| axw | davecheney: why? | 05:42 |
| davecheney | axw: right, that is what is causing juju to explode on ppc | 05:43 |
| jam1 | davecheney: we catch SIGINT during bootstrap, and IIRC SIGABRT to signal we should shut down and clean up after ourselves | 05:43 |
| axw | davecheney: ? :( | 05:43 |
| davecheney | axw: nearly got a working test case | 05:43 |
| davecheney | axw: signal handling on ppc64el 64k kernels appears broke | 05:43 |
| axw | yep, what jam1 said | 05:43 |
| axw | wonderful | 05:43 |
| davecheney | axw: we can fix this | 05:43 |
| axw | ok, cool. | 05:44 |
| davecheney | axw: whereabouts do we setup signal handlers | 05:48 |
| davecheney | so I can crib the exact code | 05:48 |
| axw | davecheney: worker/terminationworker is one | 05:49 |
| axw | davecheney: cmd/cmd.go is another | 05:49 |
| davecheney | right | 05:51 |
| davecheney | thanks | 05:51 |
| jam1 | guys, Trunk is broken for bootstrap | 05:59 |
| jam1 | it isn't installing mongodb on EC2. | 05:59 |
| jam1 | I can see it work at juju-1.19.0, but tip is just broken | 05:59 |
| === vladk|offline is now known as vladk | ||
| vladk | good morning | 06:08 |
| jam1 | morning vladk | 06:28 |
| jam1 | so I worked out the bootstrap stuff. 1.19.1 expects to "apt-get install mongodb-server" during "jujud bootstrap-state" while 1.19.0 expects it to be installed during the "juju bootstrap" and cloud-init portion of the client. | 06:28 |
| jam1 | so juju-1.19.1 trying to bootstrap jujud-1.19.0 is broken | 06:29 |
| vladk | jam1: currently the only way to bring up networks is to use: | 06:30 |
| vladk | juju deploy --networks ... --exclude-networks | 06:30 |
| vladk | I would move these options to --constraints option, | 06:30 |
| vladk | so it will be possible to add networks on 'juju bootstrap' and 'juju add-machine', too. | 06:30 |
| vladk | Also, I would always bring up all networks on MaaS nodes. | 06:30 |
| jam1 | vladk: we explicitly don't want them as constraints, because the act differently. | 06:31 |
| jam1 | with existing constraints, you can change them after deploying one instance | 06:31 |
| jam1 | and it has effects only on new instances | 06:31 |
| jam1 | but for networks | 06:31 |
| jam1 | that doesn't work well | 06:31 |
| jam1 | so we are intentionally modeling them differently. | 06:32 |
| jam1 | we do want to add it to "juju add-machine" | 06:32 |
| jam1 | I believe mgz has a card for doing so. | 06:32 |
| jam1 | I'm not sure about bootstrap, it is certainly something to discuss | 06:32 |
| mattyw | davecheney, ping? | 06:36 |
| vladk | jam1: what is your opinion about always activating all networks on InstanceSetup (not only when --networks specified) | 06:37 |
| davecheney | mattyw: pong | 06:39 |
| jam1 | vladk: so getting the list of what networks should be available on the given machine, and setting them all up, even if we didn't supply --networks listing that network? | 06:40 |
| jam1 | vladk: I'm probably happier if we set up everything rather than only the ones the user supplied | 06:40 |
| jam1 | as then if you want to deploy another service, in say a container, then we know that we do have that network | 06:41 |
| jam1 | now, when we have the NetworkWorker that can do dynamic setup of networks | 06:41 |
| jam1 | it matters less | 06:41 |
| jam1 | because then we can just set up the minimum, and then add ones that we need later. | 06:41 |
| jam1 | I thought we were starting all by default. | 06:41 |
| vladk | jam1: current dimitern's implementation is to setup them all, if --networks was specified, and none otherwise | 06:42 |
| vladk | I suggest to setup them all also on add-machina and bootstrap | 06:43 |
| jam1 | vladk: I think we want to set them up even if you didn't supply --network, because they are (essentially) a property of the machine, not a property of the service we deployed. | 06:43 |
| jam1 | We *do* want to support a bit more SDN, where we can add and remove networks dynamically | 06:43 |
| jam1 | but until we get there, we should be setting them up | 06:43 |
| rogpeppe | mornin' all | 06:56 |
| axw | rogpeppe: good morning, here' a review ;) https://codereview.appspot.com/88350043/ | 07:03 |
| rogpeppe | axw: hiya | 07:03 |
| rogpeppe | axw: looking. (as i try to repro jam1's tip bootstrap failure) | 07:04 |
| jam1 | rogpeppe: I don't know if you saw the whole thread, but just doing "juju bootstrap" without --upload-tools is broken in trunk | 07:05 |
| jam1 | because juju-1.19.1 client expects jujud to install mongo | 07:05 |
| jam1 | but while jujud-1.19.1 will do it, 1.19.0 will not | 07:05 |
| rogpeppe | jam1: ah, without --upload-tools | 07:05 |
| rogpeppe | jam1: i thought we always tried to pick an identical version to bootstrap with | 07:05 |
| axw | nope, there was a thread about it recently on juju-dev | 07:06 |
| rogpeppe | jam1: how much do we need to preserve compatibility between dev versions? | 07:06 |
| jam1 | rogpeppe: well it also means that trunk cannot bootstrap stable (1.18) but I think we've said you always bootstrap matching Major.Minor | 07:08 |
| jam1 | we've talked about, but not implemented, Major.Minor.Patch | 07:08 |
| jam1 | certainly CI would prefer that, and some users have been surprised it wasn't the case. | 07:08 |
| jam1 | rogpeppe: I believe we can break compatibility between dev releases, but we shouldn't do so unless we have strong reason to. | 07:09 |
| rogpeppe | jam1: i think there's a reasonable reason to here | 07:09 |
| rogpeppe | jam1: it cleans up cloudinit a lot to move the mongo stuff out of there | 07:10 |
| rogpeppe | jam1: if you're using tip, you should basically always use upload-tools | 07:10 |
| rogpeppe | axw: looks like you haven't recently merged trunk into that branch | 07:16 |
| axw | rogpeppe: probably not. things moved around a bit, but they're otherwise not that much different are they? | 07:16 |
| rogpeppe | axw: i think that's worth doing, as you will unfortunately encounter a few conflicts, and i'd prefer to review with them resolved | 07:16 |
| rogpeppe | axw: EnsureMongoServer has changed quite a bit | 07:17 |
| axw | rogpeppe: okay no worries | 07:17 |
| rogpeppe | hmm, params.MachineStatus and params.MachineInfo could really do with some reconciliation | 07:44 |
| rogpeppe | each one has info that the other does not | 07:44 |
| wallyworld | jamespage: hi, you around? | 08:30 |
| jamespage | wallyworld, I am | 08:30 |
| wallyworld | jamespage: looks like there's a packaging bug for arm bug 1308263 | 08:30 |
| _mup_ | Bug #1308263: /var/lib/juju/tools/1.19.0.1-trusty-arm64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory <hs-arm64> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1308263> | 08:30 |
| wallyworld | the wrong compiler options are being used | 08:30 |
| wallyworld | are you able to fix the packaging branch> dave cheney looked but couldn't find it | 08:31 |
| jamespage | wallyworld, I disagree | 08:32 |
| jamespage | wallyworld, I'll look now | 08:32 |
| jamespage | wallyworld, https://launchpadlibrarian.net/172662879/buildlog_ubuntu-trusty-arm64.juju-core_1.18.1-0ubuntu1_UPLOADING.txt.gz | 08:32 |
| jamespage | that's the build log for arm64 | 08:32 |
| jamespage | you can quite clearly see that static-libgo is being used | 08:33 |
| wallyworld | ok | 08:33 |
| wallyworld | jamespage: i'll talk to dave tomorrow | 08:34 |
| jamespage | wallyworld, this looks like a problem with whatever branch is used for building PPA packages | 08:34 |
| jamespage | wallyworld, this is not a problem in the distro packages | 08:34 |
| wallyworld | ok | 08:34 |
| wallyworld | thanks for looking | 08:35 |
| jamespage | wallyworld, let me dig a bit | 08:36 |
| wallyworld | ok, i'm about to go out for dinner so much appreciated | 08:36 |
| jamespage | sinzui, where do you keep the packaging you use for the PPA builds? | 08:37 |
| wallyworld | davecheney: hey, you just joined, i asked jamespage about bug 1308263 | 08:37 |
| _mup_ | Bug #1308263: /var/lib/juju/tools/1.19.0.1-trusty-arm64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory <hs-arm64> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1308263> | 08:37 |
| wallyworld | the build logs show the correct options are being used | 08:38 |
| wallyworld | davecheney: https://launchpadlibrarian.net/172662879/buildlog_ubuntu-trusty-arm64.juju-core_1.18.1-0ubuntu1_UPLOADING.txt.gz | 08:38 |
| wallyworld | so more investigation needed | 08:39 |
| wallyworld | but i notice that log is for 1.18 | 08:39 |
| wallyworld | it is 1.19 which has the issue | 08:39 |
| wallyworld | jamespage: could there be a 1.19 build issue? as opposed to 1.18.1? | 08:39 |
| wallyworld | and something else has just occurred to be - the bug says 1.19.0.1 which implies they used upload-tools | 08:40 |
| jamespage | wallyworld, no its the packaging | 08:40 |
| jamespage | wallyworld, it makes no attempt to use static-libgo | 08:41 |
| wallyworld | and upload-tools doesn't use those compile options | 08:41 |
| wallyworld | so i think there is also a juju bug - we need to use the correct compile options for upload-tools on arm | 08:42 |
| davecheney | jamespage: wallyworld oh | 08:43 |
| davecheney | i know what happened | 08:43 |
| davecheney | oh | 08:43 |
| davecheney | no | 08:43 |
| davecheney | hang on | 08:43 |
| davecheney | only jujud is built with a static lib go | 08:43 |
| davecheney | the other cmds aren't | 08:43 |
| davecheney | but their packaging depends on libgo.deb | 08:43 |
| davecheney | as an install dependency | 08:43 |
| davecheney | jamespage: wallyworld one thing, the build recipe is a bit weird, it says only use -gccgoflags -static-libgo for armhf,386 and amd64 | 08:44 |
| davecheney | so, not for ppc/arm64 | 08:44 |
| davecheney | jamespage: will you accept my patch to unconditionally pass that flag ? | 08:45 |
| davecheney | it's harmless if you are using the gc toolchain | 08:45 |
| davecheney | the optoin is just ignored | 08:45 |
| jamespage | davecheney, there is not a bug in the ubuntu packaging in distro - it working exactly as designed | 08:45 |
| jamespage | davecheney, I don't know where the packaging for the ppa's comes from - sinsui would know best | 08:45 |
| * wallyworld has a dinner appointment, sorry gotta run | 08:46 | |
| jamespage | I don't think its done from a recipe any longer | 08:46 |
| davecheney | jamespage: ok | 08:47 |
| davecheney | we'll keep looking | 08:47 |
| davecheney | jam: ubuntu@winton-06:/var/lib/juju$ sudo du -sh * | 08:55 |
| davecheney | 16K agents | 08:55 |
| davecheney | 1.2G db | 08:55 |
| davecheney | juju keeps doing this | 08:55 |
| davecheney | the mongodb goes ape shit and consumes gigs of space | 08:55 |
| perrito666 | morning | 09:18 |
| davecheney | perrito666: you again! | 09:33 |
| davecheney | and now you can't even tell what time it is | 09:33 |
| jam1 | morning perrito666 | 09:43 |
| raywang | hello guys, do you know how to disable the debug info from juju debug-log? it's too much info to sort out useful info | 09:50 |
| perrito666 | davecheney: to be honest its still night :p | 09:57 |
| jam1 | raywang: you can change the default logging with "juju help logging" | 09:58 |
| jam1 | though I thought Debug was disabled by default | 09:58 |
| jam1 | unless you did "juju bootstrap --debug" | 09:58 |
| * jam1 switches machines | 09:59 | |
| raywang | jam1, ok, let me check it, thanks :) | 09:59 |
| raywang | jam1, well, there is no juju help logging.. | 10:00 |
| natefinch | rogpeppe: sorry I didn't email about your branch. I had trouble figuring out what state it was in. It seemed to be out of date with trunk and with a bunch of conflicts, so I don't know what was going on there. | 10:05 |
| rogpeppe | natefinch: ok | 10:06 |
| jam1 | raywang: there is in juju-1.18, that might be new since 1.16 | 10:07 |
| jam1 | yep | 10:07 |
| raywang | jam1, yeah, i'm using 1.16 | 10:07 |
| natefinch | jam1: we should put that in help topics or something, it doesn't show up anywhere under juju help or juju help topics | 10:08 |
| raywang | jam1, just wondering how ot disable the debug mode in juju debug-log output :) | 10:08 |
| rogpeppe | simple review anyone? (code movement only - finally removing state/statecmd): https://codereview.appspot.com/88130047 | 10:16 |
| natefinch | rogpeppe: I can look | 10:19 |
| vladk | mgz: please, take a look: https://codereview.appspot.com/88380044 | 10:28 |
| natefinch | rogpeppe: lgtm'd | 10:29 |
| rogpeppe | natefinch: ta | 10:29 |
| mgz | vladk: sure | 10:32 |
| jam | whose a man got ta threaten to get a trivial review: https://codereview.appspot.com/87570043/ | 10:39 |
| natefinch | jam: looking | 10:40 |
| jam | natefinch: while you're there: https://code.launchpad.net/~jameinel/juju-core/api-endpoints-from-cache-1268470/+merge/216058 | 10:41 |
| jam | that ones a bit less trivial | 10:41 |
| perrito666 | jam: you got a regex matching \n$ is that correct? | 10:43 |
| mgz | it's fine, oddly | 10:43 |
| jam | perrito666: "." doesn't match "\n" | 10:43 |
| jam | so you have to do (.|\n) for multiline | 10:43 |
| perrito666 | ah, didnt have that one, sweet | 10:44 |
| natefinch | jstandup | 10:48 |
| jam | rogpeppe: wallyworld: standup ? | 10:50 |
| jam | rogpeppe: so 1.18.0 *doesn't* return HostPorts, so we do have to maintain compatibility there. | 11:18 |
| rogpeppe | jam: yup - but i think that because we always add the dialled address, that it will work ok even then | 11:18 |
| rogpeppe | pwd | 11:19 |
| jam | pwd to you too :) | 11:20 |
| rogpeppe | :-) | 11:20 |
| rogpeppe | trivial code review anyone? https://codereview.appspot.com/88430044 | 11:30 |
| rogpeppe | natefinch, jam, mgz: ^ | 11:30 |
| natefinch | rogpeppe: looking | 11:30 |
| jam | rogpeppe: LGTM | 11:31 |
| natefinch | rogpeppe: when does it happen that we get a stateport of 0? | 11:31 |
| rogpeppe | natefinch: when the state is created | 11:31 |
| rogpeppe | jam: thanks | 11:31 |
| natefinch | man, I would pay a lot of money to stop being sick. Damn cold has only gotten worse for like 8 days now. | 11:41 |
| rogpeppe | wallyworld: ping | 11:53 |
| * rogpeppe goes for lunch | 12:00 | |
| rogpeppe | natefinch: hangout? | 12:28 |
| wallyworld | rogpeppe: hiya | 12:30 |
| rogpeppe | wallyworld: yo! | 12:30 |
| rogpeppe | wallyworld: i was just looking at jujud.MachineWithCharmsSuite | 12:30 |
| wallyworld | ok | 12:31 |
| rogpeppe | wallyworld: and wondering whether it might be possible to integrate TestManageEnvironRunsCharmRevisionUpdater with MachineSuite | 12:31 |
| wallyworld | could be. i don't recall offhand that test suite | 12:31 |
| wallyworld | let me look | 12:32 |
| rogpeppe | wallyworld: it looks awkward though because of the relationship with charmrevisionupdater/testing/CharmSuite | 12:32 |
| rogpeppe | wallyworld: i *think* that the reason it was separated was that both suites embed JujuConnSuite | 12:32 |
| wallyworld | i must admit i don't recall | 12:33 |
| rogpeppe | wallyworld: ok, fair enough | 12:33 |
| rogpeppe | wallyworld: it all seems a bit twisty and it had your name on it, so thought i may as well ask :-) | 12:34 |
| wallyworld | i'd have to grok the code again | 12:34 |
| wallyworld | i wonder if i added the code from scratch or just refactored | 12:34 |
| wallyworld | but feel free to change whatever needs fixing | 12:35 |
| rogpeppe | wallyworld: ta | 12:35 |
| rogpeppe | wallyworld: looks like it was probably your code from scratch, but i can't be sure | 12:36 |
| wallyworld | could be. i'll have to re-read it to remember what was done | 12:36 |
| wallyworld | but i'm not emotionally attched to it so feel free to fip in and change stuff | 12:36 |
| natefinch | rogpeppe: sorry, busy with the kids for the next 30-45 minutes. | 12:43 |
| rogpeppe | natefinch: ok | 12:43 |
| sinzui | jamespage, The trusty package was made with lp:~juju-qa/juju-core/devel-packaging , The other series were made with lp:~juju-qa/juju-core/devel-mongodb-packaging | 13:03 |
| jamespage | wallyworld, ^^ | 13:05 |
| wallyworld | jamespage: ok, so that might explain that bug? | 13:05 |
| jamespage | wallyworld, those branches don't match the d/rules in trusty no | 13:07 |
| jamespage | wallyworld, but the PPA's currently only build for armhf and x86 anyway | 13:07 |
| wallyworld | not arm64? | 13:07 |
| jamespage | wallyworld, not as far as I am aware of | 13:10 |
| wallyworld | hmmm. that needs to be fixed i guess | 13:10 |
| * wallyworld knows little about packaging | 13:10 | |
| jam | rogpeppe: rotate connection to front: https://codereview.appspot.com/88470043 | 13:13 |
| rogpeppe | jam: thanks, will look in a mo | 13:13 |
| jam | I'm off, but I'm likely to stop by in the evening. | 13:13 |
| natefinch | rogpeppe: back now | 13:31 |
| rogpeppe | natefinch: https://plus.google.com/hangouts/_/canonical.com/juju-core?authuser=1 | 13:31 |
| rogpeppe | mgz, natefinch, jam, wallyworld, axw: trivial review anyone? (just updating dependencies.tsv) https://codereview.appspot.com/88160049 | 13:32 |
| mgz | rogpeppe: looking | 13:33 |
| mgz | wait, what happened to loggo... | 13:33 |
| rogpeppe | mgz: good question - someone never added it, i guess | 13:34 |
| mgz | no, it was there | 13:34 |
| mgz | I bet the 1.18 merge lost it | 13:35 |
| mgz | nope, still there on that... | 13:35 |
| mgz | wait, it's there in trunk | 13:36 |
| mgz | ah, I see | 13:36 |
| mgz | we have it as github.com/juju/loggo | 13:36 |
| mgz | rogpeppe: you added it again as github.com/loggo/loggo | 13:37 |
| mgz | which is actually the right location? | 13:37 |
| rogpeppe | mgz: ah - i guess somewhere in the code is using the old path | 13:37 |
| rogpeppe | mgz: that needs to be fixed | 13:37 |
| mgz | state/apiserver/usermanager/usermanager.go | 13:38 |
| mgz | rogpeppe: can you just fix that in this branch? | 13:38 |
| rogpeppe | mgz: am doing | 13:39 |
| mgz | (I can do a seperate one, but you'll need to remove the extra loggo dep line anmyway) | 13:39 |
| mgz | rogpeppe: star | 13:39 |
| rogpeppe | mgz: review? https://codereview.appspot.com/88490043 | 13:43 |
| rogpeppe | natefinch: https://codereview.appspot.com/88490043 | 13:43 |
| mgz | wow, no pleaselook comment | 13:43 |
| mgz | okay, that CharmSuite change bends my knowledge of go | 13:45 |
| rogpeppe | natefinch: lp:~rogpeppe/juju-core/540-enable-HA/ | 13:45 |
| rogpeppe | mgz: :-) | 13:46 |
| rogpeppe | mgz: what are you having difficulty with? | 13:46 |
| mgz | what implications does a struct having another... what's even the word... inherited, bar the convieninece of having names direct on the object? | 13:46 |
| natefinch | embedded | 13:47 |
| mgz | there's no auto initialise of anything anyway, is there anything else? | 13:47 |
| mgz | embedded, thanks. | 13:47 |
| rogpeppe | mgz: an embedded struct is just a field | 13:47 |
| natefinch | direct access to the methods | 13:47 |
| rogpeppe | mgz: and the type that embeds it gets all its methods | 13:47 |
| mgz | okay, just that. thanks! | 13:47 |
| rogpeppe | mgz: it's just the convenience of having names direct on the object, that's it | 13:48 |
| natefinch | the suites are special because of gocheck doing reflection to look for methods called SetupSuite etc | 13:48 |
| rogpeppe | natefinch: that's true, but it's always possible to define your own SetupSuite and make it call something else, so the embedding thing is still just a convenience | 13:49 |
| natefinch | rogpeppe: right | 13:50 |
| axw | rogpeppe: I just reproposed the HA upgrade branch; ignore it please, I've broken something | 13:54 |
| rogpeppe | axw: sure | 13:54 |
| rogpeppe | mgz: i've updated the dependencies.tsv branch: https://codereview.appspot.com/88160049 | 13:56 |
| mgz | rogpeppe: consider it stamped | 13:57 |
| rogpeppe | mgz: ta | 13:57 |
| natefinch | mgz: how do I branch someone else's branch into a colocated bzr branch on my local machine? | 14:01 |
| rogpeppe | natefinch: | 14:02 |
| rogpeppe | 553-stateservinginfo-validity | 14:03 |
| rogpeppe | 555-jujud-charmsuite-use-commonmachinesuite | 14:03 |
| mgz | natefinch: native colo? | 14:04 |
| natefinch | mgz: yeah, I use bzr switch between colocated branches | 14:04 |
| mgz | `bzr branch lp:~USER/PROJ/BRANCH co:BRANCH` | 14:05 |
| natefinch | awesome, thanks | 14:05 |
| mgz | with --switch if you want to switch to it with one command | 14:05 |
| natefinch | mgz: wow, that is abnormally really really really slow (compared to normally branching) | 14:07 |
| mgz | natefinch: ...might not be doing what you want? | 14:10 |
| mgz | I'd only expect slow if the branches had no common history | 14:10 |
| natefinch | mgz: actually , I just did it in the wrong directory, which probably confused the hell out of BZR | 14:10 |
| mgz | or if you missed the co: so it was creating a new branch in a subdir | 14:10 |
| mgz | natefinch: right... not too harmful though | 14:11 |
| mgz | I generally just ctrl+c if I notive it's doing too much work, generally something like that | 14:11 |
| mgz | the problem of colo working, harder to keep track of where you are | 14:11 |
| * rogpeppe is off for the day. should make it for the meeting tomorrow, but probably not earlier than that | 14:13 | |
| mgz | rogpeppe: later! | 14:13 |
| * rogpeppe has a wedding to go to... | 14:13 | |
| natefinch | rogpeppe: good luck, hope she's worth it ;) | 14:14 |
| === vladk is now known as vladk|offline | ||
| perrito666 | sinzui: hello, the comments on https://bugs.launchpad.net/juju-core/+bug/1305780?comments=all are you testing with the same backup/restore test I used for the other restore bug? | 16:10 |
| _mup_ | Bug #1305780: juju-backup command fails against trusty bootstrap node <backup-restore> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1305780> | 16:10 |
| === hatch__ is now known as hatch | ||
| === psivaa_ is now known as psivaa | ||
| hazmat | anyone around to help debug a user issue.. he's on 1.18.. there's a panic in his machine-0.log (amd64) http://paste.ubuntu.com/7262521/ | 17:00 |
| hazmat | also discussing with him #juju | 17:02 |
| natefinch | hazmat: I'm around | 17:04 |
| hazmat | natefinch, basically he can't connect to his state server from client.. more interestingly is the panic in the state server log | 17:07 |
| hazmat | in that pastebin | 17:07 |
| perrito666 | hazmat: did he/she try the kvm module suggestion from the error? (yes, I know, stupid question but has to be asked :) ) | 17:08 |
| natefinch | hazmat: looking | 17:09 |
| hazmat | perrito666, not sure that its related | 17:09 |
| hazmat | perrito666, natefinch what does look interesting is the ip he's trying to connect to is discovered by juju after the state server has bound all ip addresses. shouldn't matter though as he's also restarted it by hand | 17:09 |
| perrito666 | hazmat: most likely not, but can cause extra entropy in the output :s | 17:09 |
| hazmat | 192.168.1.2 | 17:09 |
| hazmat | perrito666, there's lot of output entropy | 17:10 |
| hazmat | perrito666, natefinch but the panic in that pastebin link above is a there is a separate issue | 17:13 |
| * hazmat grammar fails | 17:13 | |
| natefinch | hazmat: the panic is interesting. implies we called the stateworker multiple times... | 17:14 |
| natefinch | hazmat: I think the panic is an effect, not a cause | 17:14 |
| hazmat | natefinch, the cause issue he's having is networking connectivity i suspect.. the panic is a separate unrelated issue which also needs looking at | 17:15 |
| natefinch | hazmat: yep, ok | 17:15 |
| perrito666 | anyone seen this on before? (error: no "trusty" images in az-1.region-a.geo-1 with arches [amd64 armhf i386]) | 17:47 |
| natefinch | hmm no | 17:47 |
| perrito666 | :( life | 17:49 |
| natefinch | man I hate tests that test huge parts of the system all at once. They're such a gigantic time sync whenever anything changes. | 17:49 |
| perrito666 | natefinch: tell me about :p | 17:51 |
| === psivaa is now known as psivaa-afk | ||
| jam1 | hazmat: the close of closed channel might have come up with the Upgrader code having access to call EnsureStateWorker at the same time that the normal StateWorker would start up from the APIWorker. At least ISTR someone patching the Upgrader logic to deal with double startup. I thought that was in 1.18, though. | 20:34 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === psivaa-afk is now known as psivaa | ||
| === Ursinha-afk is now known as Ursinha | ||
| === hatch__ is now known as hatch | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!