| davechen1y | waigani: /o | 01:07 |
|---|---|---|
| davechen1y | o/ | 01:07 |
| waigani | davechen1y: hiya | 01:07 |
| davechen1y | waigani: whatya working on ? | 01:08 |
| davechen1y | at the 11th hour, i'm not quite sure what I should work on | 01:08 |
| davechen1y | sinzui: there won't be another release into trusty at this stage, right ? | 01:08 |
| waigani | davechen1y: adding tests for the mock functions BundleTools etc | 01:08 |
| davechen1y | waigani: SGTM | 01:08 |
| davechen1y | maybe i'll look at some of those race detector failures | 01:08 |
| waigani | davechen1y: writing tests forces me to actually understand what the functions are meant to do and their consequences | 01:09 |
| waigani | davechen1y: so I've been going a bit slow as I rethink / re-understand things | 01:10 |
| sinzui | davechen1y, I doubt it. We might rebuild 1.18.1 if there are linking issues. I think there ill be a 1.18.2 before we do 1.20. I expect 1.18.2 to get excepted into trusty | 01:10 |
| waigani | my IRC has been playing up, just noticed that I was not connected all morning | 01:11 |
| davechen1y | sinzui: it was not clear what the state of the linking issue was | 01:12 |
| davechen1y | is arm64 the only build affected ? | 01:12 |
| sinzui | I don't know. jamespage asked about my packaging branches. We can rebuild to fix bugs easily | 01:13 |
| davechen1y | sinzui: can you point me to the package branch | 01:14 |
| davechen1y | please | 01:14 |
| sinzui | davechen1y, , 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 | 01:14 |
| davechen1y | sinzui: ta | 01:14 |
| davechen1y | /win13 | 01:21 |
| thumper | hmm... | 01:31 |
| * thumper seems to have a test failure on trunk | 01:31 | |
| davechen1y | thumper: what do you see | 01:32 |
| thumper | davechen1y: bootstrap test failure | 01:32 |
| * davechen1y has many test fialures | 01:33 | |
| * thumper is running them all | 01:33 | |
| davechen1y | god damn store errors | 01:34 |
| davechen1y | is that branch ever going to bemerged ? | 01:34 |
| davechen1y | $ rm -rf store/ | 01:34 |
| davechen1y | fixed | 01:35 |
| thumper | heh | 01:35 |
| thumper | I haven't double checked dependencies for a while | 01:36 |
| thumper | should do that | 01:36 |
| thumper | menn0: oh hai | 01:42 |
| thumper | davechen1y: does the -exec flag for 'go test' in 1.3 allow for different test runners? | 01:47 |
| davechen1y | thumper: possibly | 01:47 |
| davechen1y | actually no | 01:47 |
| davechen1y | it was added so we could insert the nacl loader | 01:47 |
| davechen1y | so go run x.go | 01:48 |
| davechen1y | compiles x.go | 01:48 |
| davechen1y | then rathre than calling ./x | 01:48 |
| davechen1y | it calls -$(thing you execed) ./ | 01:48 |
| davechen1y | thumper: what do you mean by test runner | 01:48 |
| thumper | I mean an alternative way to run and format outputs | 01:49 |
| thumper | for example, being able to output subunit format | 01:49 |
| thumper | so you can then hook into things like testrepository | 01:49 |
| thumper | davechen1y, waigani, axw, wallyworld: BootstrapSuite.TestTest in cmd/juju fails for me on trunk paste.ubuntu.com/7265017/ can anyone else reproduce? | 01:52 |
| axw | thumper: heh, proposing a fix now :) | 01:52 |
| thumper | could be a precise vs trusty test failure | 01:52 |
| thumper | axw: ah cool | 01:52 |
| thumper | thanks | 01:52 |
| davechen1y | thumper: what the hell | 01:53 |
| davechen1y | never seen that before | 01:53 |
| axw | nps, I guess it was a package update that triggered it | 01:53 |
| thumper | davechen1y: we upload different tools for different versions | 01:53 |
| axw | davechen1y: what's your "distro-info --lts" say? | 01:53 |
| thumper | davechen1y: could be an error from that | 01:53 |
| axw | if it says trusty, then it will (should?) break the test | 01:53 |
| axw | thumper: https://codereview.appspot.com/88730043 | 01:53 |
| davechen1y | $ distro-info --lts | 01:54 |
| davechen1y | trusty | 01:54 |
| davechen1y | axw: my tests are running | 01:54 |
| davechen1y | ... they take a while | 01:54 |
| axw | davechen1y: go test -gochech.v -gocheck.f BootstrapSuite.TestTest launchpad.net/juju-core/cmd/juju | 01:55 |
| axw | gocheck.v* | 01:55 |
| davechen1y | $ go test -gocheck.v -gocheck.f BootstrapSuite.TestTest launchpad.net/juju-core/cmd/juju | 01:56 |
| davechen1y | OK: 0 passed | 01:56 |
| davechen1y | PASS | 01:56 |
| davechen1y | ok launchpad.net/juju-core 0.079s | 01:56 |
| davechen1y | oh | 01:56 |
| davechen1y | 0 tests ran :) | 01:57 |
| axw | ehh | 01:57 |
| davechen1y | oh cmd/juju and cmd/jujud don't pass on ppc | 01:57 |
| davechen1y | they take > 600 seconds | 01:57 |
| axw | ah, heh :) | 01:57 |
| menn0 | thumper: g'day. just lurking :) | 01:57 |
| thumper | menn0: I'm just writing you an email :) | 01:57 |
| davechen1y | machine_test.go:849: c.Assert(err, gc.IsNil) | 01:58 |
| davechen1y | ... value *errors.errorString = &errors.errorString{s:"cannot assign unit \"s0/0\" to machine 1: machine \"1\" cannot host units"} ("cannot assign unit \"s0/0\" to machin | 01:58 |
| davechen1y | e 1: machine \"1\" cannot host units") | 01:58 |
| davechen1y | I get this faliure all thetime | 01:58 |
| menn0 | thumper: ok cool | 01:58 |
| davechen1y | axw: $ go test -gocheck.v -gocheck.f BootstrapSuite launchpad.net/juju-core/cmd/juju | 02:00 |
| davechen1y | OK: 0 passed | 02:00 |
| davechen1y | i don' tthink that is the test you mean | 02:00 |
| davechen1y | PASS | 02:00 |
| davechen1y | ok launchpad.net/juju-core 0.077s | 02:00 |
| axw | davechen1y: lemme check what I actually did | 02:00 |
| axw | davechen1y: sorry, package needs to come directly after "go test" | 02:02 |
| * davechen1y would like to remove all the use of version.Current in our test | 02:02 | |
| davechen1y | what we _actually_ mean is version.Current.Binary | 02:02 |
| davechen1y | ie, make tools of the current development version | 02:02 |
| davechen1y | but the use of the larger version.Current means the series of the host that is running the tests leaks into the test | 02:02 |
| axw | davechen1y: but actually I just ran from cmd/juju | 02:02 |
| axw | davechen1y: and now I'm not sure specifying it on the command line works | 02:02 |
| * axw stops trying to be helpful | 02:03 | |
| === Ursinha is now known as Ursinha-afk | ||
| axw | thumper: I know why it broke now, if you care: distro-info returns different values depending on the date | 02:17 |
| === Ursinha-afk is now known as Ursinha | ||
| axw | wallyworld_: do you have an SSD? | 02:20 |
| thumper | axw: wallyworld_ is having irc connection fun | 02:21 |
| axw | so it seems | 02:21 |
| thumper | on a hangout with him now | 02:22 |
| thumper | the hangout is fine | 02:22 |
| axw | ok | 02:22 |
| wallyworld_ | axw: my irc is shit today :-( | 02:22 |
| axw | okey dokey | 02:22 |
| axw | wallyworld_: I will ask you about it in the hangout | 02:22 |
| wallyworld_ | ok | 02:22 |
| wallyworld | davechen1y: hi, what was the final outcome of the discussion about bug 1308263? is there something for james to fix or do we need to engage someone else? | 02:47 |
| _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> <packaging> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1308263> | 02:47 |
| davechen1y | wallyworld: finger pointing mainly | 02:52 |
| wallyworld | :-( | 02:52 |
| davechen1y | nobody knowns who owns the package branch | 02:52 |
| davechen1y | when we find tat | 02:52 |
| davechen1y | that | 02:52 |
| davechen1y | apply the diff I included in the issue and bobs your uncle | 02:52 |
| wallyworld | what's the branch url? | 02:52 |
| davechen1y | wallyworld: i'm afraid i don't know | 02:53 |
| wallyworld | ok, i'll find someone to annoy about it | 02:53 |
| thumper | *big sad face* | 03:53 |
| thumper | more intermittent failures in cmd/juju and cmd/jujud | 03:53 |
| davechen1y | thumper: http://paste.ubuntu.com/7265483/ | 03:55 |
| davechen1y | my hammer | 03:55 |
| * thumper does the lbox wait | 04:02 | |
| thumper | a not very interesting branch: https://codereview.appspot.com/88800043 | 04:05 |
| davechen1y | thumper: LGTM | 04:08 |
| davechen1y | nice cleanup | 04:08 |
| thumper | davechen1y: ta | 04:16 |
| davechen1y | instance, ok := instance.(*azureInstance) | 04:18 |
| davechen1y | if !ok { | 04:18 |
| davechen1y | continue | 04:18 |
| davechen1y | should we really be ignoring that someone has passed instances from one provider to another ? | 04:19 |
| * axw tries to remember why that's there | 04:19 | |
| axw | davechen1y: no I don't think we need that actually, that was my mistake | 04:21 |
| axw | davechen1y: I *think* that I was thinking manual instances would come through, but they won't | 04:21 |
| davechen1y | axw: we can return an error from that method | 04:22 |
| axw | davechen1y: I don't think there's any need to check at all | 04:23 |
| axw | nothing should be passing in foreign instances | 04:23 |
| davechen1y | axw: ok, i'll just remove the 2 arg check | 04:24 |
| === vladk|offline is now known as vladk | ||
| jam1 | thumper: LGTM, though there was a 'debugf' helper, that should probably be Tracef rather than Debugf, because it had extra suppression | 04:54 |
| jam1 | thumper: and pinger/watcher stuff is likely to be quite noisy otherwise | 04:55 |
| thumper | jam1: ah.. good point | 05:07 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| jam1 | axw: are you actually working on bug #1247232 ? | 06:43 |
| _mup_ | Bug #1247232: Juju client deploys agent newer than itself <canonical-is> <ci> <deploy> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1247232> | 06:43 |
| jam1 | axw: also, your Kanban cards seem out of sync with reality. "provider-driven machine/unit assignment policy" seems to actually be landed. | 06:43 |
| axw | jam1: not really, there's more work to be done to support ec2 AZs | 06:44 |
| axw | jam1: yes just started working on #1247232 | 06:44 |
| _mup_ | Bug #1247232: Juju client deploys agent newer than itself <canonical-is> <ci> <deploy> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1247232> | 06:44 |
| jam1 | axw: it isn't a huge deal, but it would be nice if you could add cards when you pick things up, since it gives visibility on my team to all the great stuff that you're getting done. | 06:45 |
| jam1 | axw: and great about #1247232, really looking forward to that one | 06:45 |
| _mup_ | Bug #1247232: Juju client deploys agent newer than itself <canonical-is> <ci> <deploy> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1247232> | 06:45 |
| axw | jam1: sure, I try to - bad memory :( | 06:46 |
| axw | jam1: would've been good to do it before 1.18 I guess, but it shouldn't be too difficult to maintain bootstrap compat within the 1.18 series | 06:46 |
| jam1 | axw: yeah, honestly breaking bootstrap compatibility in a stable release would really make me question our guidelines of what "stable" is | 06:47 |
| === vladk is now known as vladk|offline | ||
| dimitern | 218609 | 07:59 |
| dimitern | ahem, morning :) | 07:59 |
| jam1 | morning dimitern, welcome back, did you have a good break? | 08:10 |
| dimitern | jam1, hey, yeah, only the weather is shitty :) | 08:12 |
| jam1 | dimitern: were you diving? | 08:12 |
| dimitern | jam1, ah, no - it's too cold for that yet | 08:14 |
| dimitern | jam1, i'm showing william & co around | 08:14 |
| rogpeppe | mornin' all | 08:22 |
| * rogpeppe wishes trusty hadn't halved his battery life | 08:23 | |
| dimitern | hey rogpeppe | 08:23 |
| rogpeppe | dimitern: hiya | 08:23 |
| dimitern | rogpeppe, wow i haven't experienced such change in battery life | 08:23 |
| dimitern | with trusty | 08:23 |
| === vladk|offline is now known as vladk | ||
| rogpeppe | dimitern: i just opened the laptop and it predicts me 3.40h lifetime. previously it would predict 8-10 hours | 08:24 |
| vladk | jam1, dimitern, rogpeppe: morning | 08:25 |
| rogpeppe | vladk: hiya | 08:25 |
| jam1 | morning vladk | 08:25 |
| jam1 | rogpeppe: the question is whether the prediction is wrong or the usage is wrong :) | 08:26 |
| rogpeppe | jam1: usually the prediction overestimates somewhat | 08:26 |
| jam1 | rogpeppe: I can change your indicator to *predict* 5 days if you like :) | 08:26 |
| vladk | dimitern: I'm going to start work on NetworkerWorker | 08:26 |
| rogpeppe | jam1: i certainly used to be able to use it for almost the entirety of a transatlantic flight. i suspect that won't be possible any more. | 08:27 |
| jam1 | rogpeppe: you could always just boot into the terminal prompt... runlevel 2, IIRC | 08:27 |
| rogpeppe | jam1: not great if i want to watch videos, though :-) | 08:28 |
| jam1 | rogpeppe: http://www.youtube.com/watch?v=0nRPoS2WDJA | 08:28 |
| jam1 | Text mode Quake | 08:28 |
| rogpeppe | ha ha | 08:28 |
| jam1 | IIRC, it was a OpenGL driver to text | 08:29 |
| jam1 | but in Unity everything is just a GL texture anyway, right? | 08:29 |
| dimitern | hey vladk | 08:31 |
| dimitern | vladk, that sgtm | 08:32 |
| dimitern | rogpeppe, re ErrorContextf - it's actually a good thing that now errors.Contextf will preserve known error types | 08:32 |
| rogpeppe | dimitern: i'm afraid i don't agree | 08:33 |
| vladk | dimitern: could you explain shortly the purpose of NetworkerWorker | 08:33 |
| dimitern | rogpeppe, why is that? | 08:33 |
| rogpeppe | dimitern: it can actually open up possible bugs | 08:33 |
| dimitern | rogpeppe, I havent' seen any failures | 08:34 |
| dimitern | rogpeppe, and william agrees on the changes btw :) | 08:34 |
| rogpeppe | dimitern: because error types (particularly not-found errors) are used to mean many different things | 08:34 |
| rogpeppe | dimitern: our error paths are not that well tested | 08:34 |
| dimitern | vladk, it's a simple worker that on startup gets the networks the machine is supposed to be on and does what we're currently doing in cloudinit | 08:35 |
| dimitern | rogpeppe, this is a gradual improvement on that as well | 08:36 |
| rogpeppe | dimitern: if i have a function that uses errors.Contextf that has 10 possible error return paths, currently I know that it doesn't matter if one of them might return a non-found error for some unrelated reason - it won't cause the function itself to return a not-found error | 08:36 |
| rogpeppe | dimitern: the direction i'm trying to move towards with errgo is to explicitly mention what error types might pass through | 08:36 |
| dimitern | rogpeppe, some users of ECf are actually checking for a specific error before returning the prefixed error, so that it's not lost | 08:37 |
| rogpeppe | dimitern: except that it is adding more possible typed errors to the return | 08:37 |
| dimitern | rogpeppe, the errgo direction is the way to go I agree, but until we have that, this CL makes things slightly better | 08:37 |
| rogpeppe | dimitern: i actually don't think so | 08:38 |
| dimitern | rogpeppe, can we agree to disagree? :) | 08:38 |
| rogpeppe | dimitern: it changes every single place where errors were masked by ErrorContextf into a place where the error type can pass through | 08:38 |
| rogpeppe | dimitern: that invalidates one of the key transformations that my errgo gofix module puts in place | 08:38 |
| dimitern | rogpeppe, masking errors with ECf is wrong imo | 08:38 |
| rogpeppe | dimitern: i think it's usually right | 08:39 |
| dimitern | rogpeppe, well then that means the assumption can be improved, no? | 08:39 |
| dimitern | vladk, and in order to do that, we'll need a Networker API facade, similarly to Provisioner API for example | 08:40 |
| rogpeppe | dimitern: by making errorcontextf preserve type in all circumstances, it's moving further away from where we want to be (explicitly mentioning what errors pass through) | 08:40 |
| rogpeppe | dimitern: which is why i'd like to see two versions of it | 08:40 |
| rogpeppe | dimitern: (or perhaps one with a filter function) | 08:40 |
| dimitern | rogpeppe, i'm afraid i don't get it still | 08:41 |
| dimitern | rogpeppe, what's stopping us from giving a list of errors to pass through ECf later? | 08:41 |
| vladk | dimitern, please, take a look https://codereview.appspot.com/88380044/ | 08:41 |
| rogpeppe | dimitern: because then we have to audit each place to see what errors need to be preserved | 08:41 |
| dimitern | vladk, looking | 08:41 |
| rogpeppe | dimitern: currently we *know* that those places that use ErrorContextf do not preserve the error type | 08:42 |
| dimitern | rogpeppe, won't we need to do that anyway? | 08:42 |
| rogpeppe | dimitern: not in places that use ErrorContextf | 08:42 |
| rogpeppe | dimitern: which is why i'm not keen on the change - it adds more work to do | 08:42 |
| axw | rogpeppe: if battery life has gone down, check if your video drivers are getting loaded correctly - in the past I've had that, and it turned out my driver failed and my CPU was busy software rendering everything | 08:43 |
| dimitern | rogpeppe, expand a bit on what more work it creates? | 08:43 |
| rogpeppe | axw: hmm, where would i check that? | 08:43 |
| axw | rogpeppe: glxinfo, I forget what to grep for though | 08:43 |
| rogpeppe | dimitern: it means that we need to audit all those places that previously we would not | 08:43 |
| axw | rogpeppe: (I think) glxinfo | grep "OpenGL renderer string" | 08:44 |
| rogpeppe | axw: i guess i need to apt-get that | 08:44 |
| rogpeppe | hmm, no glxinfo | 08:44 |
| * rogpeppe googles it | 08:44 | |
| axw | anyone know how I can find the revno for 1.18.0? seems there's no tag | 08:45 |
| axw | oh.. because we branched | 08:45 |
| axw | never mind | 08:45 |
| rogpeppe | axw: i can't see any obvious errors in this | 08:47 |
| rogpeppe | name of display: :0 | 08:47 |
| rogpeppe | display: :0 screen: 0 | 08:47 |
| rogpeppe | direct rendering: Yes | 08:47 |
| rogpeppe | server glx vendor string: SGI | 08:47 |
| dimitern | rogpeppe, and none of the packages changed in any way since the last audit? | 08:47 |
| rogpeppe | http://paste.ubuntu.com/7266522/ | 08:47 |
| rogpeppe | dimitern: ? | 08:47 |
| dimitern | rogpeppe, my point is we need to do the audit anyway | 08:47 |
| dimitern | again | 08:47 |
| axw | rogpeppe: yeah, looks like it's not that. | 08:47 |
| rogpeppe | dimitern: when we use ErrorContextf, there's no need currently to do an audit | 08:48 |
| rogpeppe | dimitern: because we *know* that the error type is not preserved | 08:48 |
| rogpeppe | dimitern: by making ErrorContextf preserve the type, it adds the need to audit all those places | 08:48 |
| dimitern | vladk, reviewed | 08:50 |
| dimitern | rogpeppe, that's not true | 08:50 |
| dimitern | rogpeppe, in all cases | 08:50 |
| rogpeppe | dimitern: no? | 08:50 |
| dimitern | rogpeppe, i'll give you an example, just a sec | 08:50 |
| dimitern | rogpeppe, there are a few cases where ECf is not called when a specific error needs to be returned | 08:54 |
| dimitern | rogpeppe, because it masks the error | 08:54 |
| dimitern | rogpeppe, like in service.SetConstraints | 08:55 |
| rogpeppe | dimitern: indeed. places that don't use ECf need to be audited | 08:55 |
| rogpeppe | dimitern: but my point is that places that *do* use ECf do not need to be audited | 08:55 |
| rogpeppe | dimitern: (currently) | 08:56 |
| dimitern | rogpeppe, so you're saying "let's keep the old inflexible behavior, so that when we start using errgo it will all get better, rather than incrementally improving bits of the error handling" | 08:57 |
| rogpeppe | dimitern: i'm saying keep the masking in the places where we're already masking | 08:58 |
| rogpeppe | dimitern: because masking is actually good (although less flexible, as you say - we do need a way of avoiding the masking when we need to) | 08:58 |
| rogpeppe | dimitern: so i'd much prefer that we explicitly change a few places where we really know that we want to pass through the type | 08:59 |
| rogpeppe | dimitern: rather than changing everything wholesale | 09:00 |
| dimitern | rogpeppe, "masking is good" is the root cause of my disagreement here - it's not good, it's actually bad, because even when you have specific error types you need to pass through and have them annotated for the user's sake, you can't do that and have to resort to trickery like "is it ErrX? ok, pass it through unannotated; otherwise just mask it" | 09:11 |
| dimitern | rogpeppe, but just so that I'm not the unyielding bad guy here, i'll take your suggestion and have a errors.Maskf working as before and Contextf as it is now and use the latter for networks/interfaces | 09:13 |
| dimitern | ;) | 09:13 |
| rogpeppe | dimitern: thanks a lot | 09:14 |
| rogpeppe | dimitern: BTW re the trickery - that's why errgo.Mask takes a function that allows it to choose which errors to mask | 09:14 |
| rogpeppe | dimitern: i'm not that keen on ErrorContextf in general - it adds the same info to all returned errors, where we actually usually want to add specific info about what error path has failed | 09:16 |
| dimitern | rogpeppe, i'm just saying that not having proper/smarter error handling is bad and blocking any improvements to the existing error handling so that once if have errgo everything will be perfect is not ok | 09:17 |
| rogpeppe | dimitern: i certainly don't want to block improvements to the existing error handling | 09:18 |
| rogpeppe | dimitern: but i don't want to move a lot of it in the wrong direction either | 09:18 |
| axw | rogpeppe: when you're free, I reproposed the HA upgrade changes: https://codereview.appspot.com/88790043/ | 09:25 |
| rogpeppe | axw: cool | 09:25 |
| axw | rogpeppe: I missed a bunch of things before. this version generates the shared secret and sets it in agent config and state on upgrade | 09:26 |
| axw | rogpeppe: there was missing code in agent config serialisation for shared secret, so I added that | 09:26 |
| rogpeppe | axw: lovely stuff, thanks | 09:26 |
| rogpeppe | axw: looking | 09:26 |
| axw | cheers | 09:27 |
| axw | btw if anyone gets weird errors when testing cmd/juju (specifically in BootstrapSuite), then pull trunk | 09:27 |
| axw | the LTS release date triggered a test failure | 09:27 |
| dimitern | rogpeppe, changing all error types to embed wrapper instead of *wrapper forces me to implement func (e *errorType) Error() on each one, and all of them are the same | 09:34 |
| rogpeppe | dimitern: i don't think so | 09:34 |
| rogpeppe | dimitern: define func (*wrapper) Error() string | 09:34 |
| rogpeppe | dimitern: but embed wrapper by value | 09:34 |
| rogpeppe | dimitern: and it'll just work | 09:35 |
| dimitern | rogpeppe, ah, sorry - i needed to change the Is<type> type assertions to use *type | 09:35 |
| rogpeppe | dimitern: yes, definitely | 09:35 |
| rogpeppe | dimitern: that's a good thing | 09:35 |
| rogpeppe | dimitern: error types by convention are almost always pointers | 09:35 |
| dimitern | rogpeppe, right | 09:36 |
| axw | jam1: if you have any time for a review, here's a CL for the bootstrap tools match: https://codereview.appspot.com/88840043/ | 09:36 |
| natefinch | morning all | 09:37 |
| axw | morning natefinch | 09:37 |
| jam1 | axw: so one thing I hit recently, is using trunk to bootstrap | 09:38 |
| jam1 | because 1.19.0 is publicly available, it uses that, even though local is 1.19.1 | 09:38 |
| jam1 | have you tried that? | 09:38 |
| jam1 | axw: I'm concerned it will bootstrap 1.19.1 and then immediately downgrade to 1.19.0 which seems a bit odd | 09:38 |
| axw | jam1: if you don't --upload, it'll try but warn | 09:38 |
| axw | (try to use 1.19.0 that is) | 09:39 |
| axw | jam1: it's based on whatever tools it finds in the tools source | 09:39 |
| axw | agent-version is set to the most recent tools matching major/minor that exist in the tools source | 09:39 |
| axw | jam1: I'll add another test with patch > what's available, so it's more obvious | 09:41 |
| jam1 | axw: so where is it setting AgentVersion, as I don't see that in your patch | 09:41 |
| jam1 | perhaps it was already being done elsewhere | 09:41 |
| axw | jam1: already done, in SetBootstrapTools | 09:42 |
| jam1 | axw: so LGTM though I'd like to see the new chunk of code in its own function | 09:46 |
| jam1 | it seems tightly focused, so lets put it somewhere focused | 09:46 |
| jam1 | something like "findExactToolMatch" or somesuch | 09:46 |
| axw | jam1: sure, will do | 09:46 |
| axw | thanks | 09:46 |
| === vladk is now known as vladk|offline | ||
| jam1 | axw: so "APIEndpointFor" I could say APIEndpointFromName, but I really don't like to call it APIEndpoint when it isn't the same signature as the existing APIEndpoint functions. | 09:47 |
| axw | jam1: I think FromName would be preferable, to keep in line with NewConn* | 09:48 |
| jam1 | axw: can you look at https://code.launchpad.net/~jameinel/juju-core/api-caches-connected-to-1308487/+merge/216091 while your there? | 09:49 |
| axw | jam1: sure | 09:50 |
| === vladk|offline is now known as vladk | ||
| jam1 | axw: alternatively APIEndpointForEnv() ? | 09:51 |
| axw | jam1: that reads better than For. your choice, but IMHO I think it would be better to be consistent with NewConn/NewAPI*FromName | 09:52 |
| jam1 | axw: well, we got rid of FromName for NewKeyManagerClient and NewUserManagerClient | 09:52 |
| jam1 | because FromName was considered ugly | 09:52 |
| axw | heh :) | 09:52 |
| jam1 | but this doesn't actually return a client-like thing so I can't use that pattern | 09:53 |
| axw | jam1: LGTM on the API caching one | 09:57 |
| axw | erm | 09:57 |
| axw | sliding | 09:57 |
| axw | whatever :) | 09:57 |
| natefinch | meeting everybody | 10:02 |
| jam1 | switching machines | 10:04 |
| jam | perrito666 mgz standup | 10:07 |
| wallyworld | jam: my connection dropped out earlier when you were talking about upload tools issues. Do you have bug numbers you can point me at? | 10:35 |
| jam | wallyworld: https://bugs.launchpad.net/juju-core/+bug/1307643 | 10:36 |
| _mup_ | Bug #1307643: juju upgrade-juju --upload-tools does not honor the arch <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1307643> | 10:36 |
| jam | wallyworld: that one? | 10:36 |
| wallyworld | ta | 10:36 |
| wallyworld | yeah | 10:36 |
| wallyworld | was there one more? | 10:36 |
| jam | that one links to: https://bugs.launchpad.net/bugs/1304407 | 10:36 |
| _mup_ | Bug #1304407: juju bootstrap defaults to i386 <amd64> <apport-bug> <ec2-images> <metadata> <trusty> <juju-core:Triaged> <juju-core 1.18:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1304407> | 10:36 |
| jam | and https://bugs.launchpad.net/bugs/1282869 | 10:36 |
| _mup_ | Bug #1282869: juju bootstrap --upload-tools does not honor the arch of the machine being created <bootstrap> <constraints> <ppc64el> <upload-tools> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1282869> | 10:36 |
| wallyworld | that's the one | 10:37 |
| jam | wallyworld: right, you roughly fixed bootstrap, but upgrade-juju doesn't have the same check | 10:37 |
| wallyworld | hmmm, well that sucks :-( | 10:37 |
| wallyworld | i guess we'd wat that in 1.18.2 | 10:38 |
| jam | yeah, I think so | 10:38 |
| rogpeppe | i'm a bit sad that the default-series inference when deploying charms is done client-side | 11:01 |
| === vladk is now known as vladk|offline | ||
| rogpeppe | it means that juju deploy needs to do an additional EnvironmentGet, which seems wrong, especially as that's an API call we may very well want to restrict access to in the future | 11:02 |
| rogpeppe | wallyworld: https://bugs.launchpad.net/juju-core/+bug/1308966 | 11:03 |
| _mup_ | Bug #1308966: default-series choice is inconsistent <juju-core:New> <https://launchpad.net/bugs/1308966> | 11:03 |
| wallyworld | great, thank you | 11:04 |
| rogpeppe | afk for 40 mins or so | 11:06 |
| jam | rogpeppe: so the way it is supposed to work is that it bootstraps based on the version of the charm | 11:08 |
| jam | so if you "juju deploy mysql" and there is a "trusty" version of it, it will create trusty targets. | 11:09 |
| jam | But maybe there is a second check based on what tools are available? | 11:09 |
| jam | (also, if there is only a precise version of mysql, then it deploys that, and you can force it with "juju deploy precise/mysql") | 11:09 |
| jam | and *that* resolution of "what does 'mysql' mean" is supposed to be done by the charm store, proxied by the API Server | 11:09 |
| * jam1 switches back to other machine | 11:15 | |
| === vladk|offline is now known as vladk | ||
| evilnickveitch | jamespage, sorry, didn't see that earlier. Hopefully i will have another draft today! | 12:10 |
| jamespage | evilnickveitch, cool - great | 12:10 |
| natefinch | rogpeppe: how goes? | 12:52 |
| rogpeppe | natefinch: just doing a live test now | 12:53 |
| rogpeppe | natefinch: seems to be working | 12:54 |
| rogpeppe | natefinch: it's really hard to see what's going on without some visibility into the state server status though | 12:55 |
| rogpeppe | natefinch: would you be able to run up a CL that adds the state server status as we discussed? | 12:55 |
| natefinch | rogpeppe: yeah, that's a good idea. I haven't actually looked at the status code before, so pointers to the right spot would help speed things up. | 12:56 |
| rogpeppe | natefinch: here's a branch containing what i did before: lp:~rogpeppe/juju-core/556-status-show-stateserver | 13:04 |
| rogpeppe | natefinch: i *think* that we can keep the API interface the same (Jobs, WantsVote, HasVote) because we're already exposing Jobs in the API. | 13:05 |
| natefinch | rogpeppe: ok | 13:06 |
| rogpeppe | natefinch: but you'll need to change machineStatus in cmd/juju to hold the new string field | 13:06 |
| rogpeppe | natefinch: and change formatMachine to set it, based on the jobs/wantsvote/hasvote tuple | 13:06 |
| natefinch | rogpeppe: cool. doing | 13:11 |
| dimitern | rogpeppe, I've updated https://codereview.appspot.com/87560043/ and it should be good to land now, can you take a look please? | 13:13 |
| rogpeppe | dimitern: looking | 13:13 |
| wallyworld | jamespage: hi, i need to ask you about bug 1308263 again. i'm not sure of where you and dave got to talking about it. is it just a case of updating the packaging branch with dave's patch? the patch seems to remove a note with your name on it and makes static linking unconditional. i don't know anything about packaging. is there a branch for which a merge proposal can be put up? | 13:29 |
| _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> <packaging> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1308263> | 13:29 |
| jamespage | wallyworld, I really don't have anything todo with the PPA packaging | 13:30 |
| wallyworld | oh, i didn't realise it was for a ppa | 13:30 |
| sinzui | wallyworld, he speaks the truth | 13:30 |
| jamespage | but I would suspect that the debian/rules file needs sycning from lp:ubuntu/trusty/juju-core | 13:30 |
| jamespage | sinzui, fwiw I don't intend to track the devel releases next cycle | 13:31 |
| jamespage | :-) | 13:31 |
| sinzui | \o/ | 13:31 |
| jamespage | thought that might make you happy :-) | 13:31 |
| sinzui | jamespage, Since I cannot build the an arm package and test it, I hesitated to take the changes and do a rebuild. And the PPA doesn't make arm64/ppc | 13:33 |
| jamespage | sinzui, indeed | 13:34 |
| sinzui | jamespage, a package rule sync is sane at least. I will find some victims | 13:35 |
| wallyworld | jamespage: am i looking in the right url? https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/juju-core i get a 404 | 13:36 |
| jamespage | wallyworld, gah - not quite released yet | 13:36 |
| jamespage | lp:ubuntu/juju-core | 13:36 |
| natefinch | FFS, I wish bzr would just f'ing warn me when I'm about to switch branches and have local changes. | 13:38 |
| wallyworld | jamespage: right, so i can see the debian/rules file in lp:ubuntu/juju-core needs to have dave's patch applied. is that something you do? | 13:42 |
| jamespage | wallyworld, the debian/rules file in that branch works just fine | 13:42 |
| jamespage | if you take that it will dtrt on ppc64el and arm64 | 13:42 |
| natefinch | can anyone else bootstrap trunk? | 13:43 |
| natefinch | (in local) | 13:43 |
| wallyworld | jamespage: so dave's patch which removes the conditional and simple enables static linking everywhere is wrong? | 13:44 |
| jamespage | wallyworld, its not required | 13:44 |
| natefinch | rogpeppe, jam, dimitern, mgz, perrito666: can you guys bootstrap local on trunk? Mine doesn't seem to be starting mongo for some reason | 13:44 |
| wallyworld | hmmm. why was the issue seen then? | 13:44 |
| jamespage | wallyworld, the rules file right now only applies the static linking for builds using gccgo | 13:44 |
| rogpeppe | natefinch: i haven't tried recently | 13:45 |
| jamespage | wallyworld, I have no idea | 13:45 |
| jamespage | if this was a problem all of the 1.18.x builds in the archive would be broken as well - and they are not | 13:45 |
| wallyworld | ok. i'll ask dave to clarify. but he is away till las vegas i think | 13:45 |
| wallyworld | we do need to get tis sorted before then though | 13:46 |
| wallyworld | so we can release 1.19.1 | 13:46 |
| wallyworld | jamespage: actually, this line: golang_archs:= amd64 i386 armhf why is arm64 not listed? | 13:47 |
| wallyworld | could that have something to do with it? | 13:47 |
| jamespage | wallyworld, because its not a golang arch | 13:47 |
| jamespage | its a gccgo arch | 13:47 |
| jamespage | golang == gc | 13:47 |
| wallyworld | rightio | 13:48 |
| jamespage | wallyworld, i suspect the confusion is around the filter | 13:48 |
| jamespage | that kicks in the logic if the arch is not in that list | 13:48 |
| jamespage | i.e. gccgo | 13:48 |
| wallyworld | is there any harm is just using the flags all the time? | 13:48 |
| === Ursinha is now known as Ursinha-afk | ||
| jamespage | wallyworld, probably not but I can't change it for trusty now | 13:49 |
| wallyworld | ok. that means folks on arm64 will need to get their juju from a ppa then i guess | 13:49 |
| rogpeppe | natefinch: here are the last few HA changes, BTW: https://codereview.appspot.com/88860043 | 13:50 |
| natefinch | rogpeppe: looking | 13:51 |
| rogpeppe | natefinch: i'm currently factoring out the peergrouper changes into their own CL with tests | 13:51 |
| rogpeppe | natefinch: so it's not quite ready for review | 13:51 |
| rogpeppe | natefinch: but it's good to see :-) | 13:51 |
| natefinch | rogpeppe: very cool | 13:52 |
| natefinch | rogpeppe: if I could bootstrap, I could test out the status change I made. But I can't even get trunk to bootstrap for some reason | 13:52 |
| rogpeppe | natefinch: on ec2, or local? | 13:52 |
| natefinch | rogpeppe: local. haven't tried ec2 yet | 13:53 |
| rogpeppe | natefinch: ah. | 13:53 |
| rogpeppe | natefinch: let me know if you find the reason | 13:53 |
| rogpeppe | natefinch: i'm not going to get distracted right now :-) | 13:54 |
| natefinch | rogpeppe: good, keep focused. The end is in sight :) | 13:54 |
| alexisb | rogpeppe, do you need to skip our 1x1 to stay focused | 13:55 |
| rogpeppe | alexisb: let's do it anyway. we can keep it short. | 13:57 |
| alexisb | sounds good | 13:57 |
| === Ursinha-afk is now known as Ursinha | ||
| wallyworld | sinzui: i found the rules file for the ppa and it seems quite different to the one used for packaging into the distro, and it seems to not use any go build flags at all. it seems to be that rules file needs to be updated? | 14:01 |
| sinzui | wallyworld, that is exactly what I will do. I need a victim to test it | 14:02 |
| wallyworld | sinzui: dannf is your man | 14:03 |
| sinzui | wallyworld, I cannot build arm64... | 14:03 |
| wallyworld | sinzui: dannf can, and is the one who raised the bug so i'm sure he would be fine to help test a fix | 14:03 |
| sinzui | yep | 14:03 |
| wallyworld | sinzui: do you mind if i assign the bug to you? | 14:04 |
| wallyworld | or would you prefer it stays with me? | 14:05 |
| sinzui | go ahead wallyworld | 14:05 |
| sinzui | I can make the changes in a few hours | 14:05 |
| wallyworld | ok. it took me way too long to figure out who to nag to get it fixed. i owe jamespage an apology for pestering him about it | 14:05 |
| wallyworld | packiging is not my strong point :-( | 14:06 |
| * hazmat stares at ouija board to estimate the time/cost of a new provider in core | 14:24 | |
| alexisb | Hi all, can someone tell me if juju-core has done any work for MaaS name constraints? | 14:24 |
| sinzui | rogpeppe, Juju CI has a HA test. We will turn it on when you tell me you want the feature tested | 14:24 |
| dimitern | rogpeppe, LGTM? :) | 14:24 |
| rogpeppe | dimitern: oh, sorry, totally got distracted staring at that test code again. | 14:25 |
| rogpeppe | dimitern: going back to it :-) | 14:25 |
| alexisb | wallyworld, see my q above | 14:26 |
| wallyworld | alexisb: yes, it has a constraints attribute called "tags" | 14:26 |
| wallyworld | which i believe are used to match with maas names | 14:27 |
| wallyworld | but i've not used them mysel | 14:27 |
| alexisb | landscape is asking if it it is "available" | 14:27 |
| alexisb | I am trying to figure out how to answer them :) | 14:27 |
| wallyworld | it should be | 14:27 |
| dimitern | rogpeppe, cheers | 14:27 |
| alexisb | when did it land? | 14:27 |
| wallyworld | a while back i think | 14:27 |
| sinzui | FAILURE lp:juju-core r2644 broke local upgrades http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/local-upgrade/1099/console | 14:27 |
| wallyworld | dimitern: ^^^^^^^^^^^^^^^^^^^^ can you clarify when maas name supported landed? | 14:28 |
| wallyworld | i think it was for 1.16? | 14:28 |
| sinzui | ^ abentley is looking to how to change the test. We will report a bug if we think Juju really has a regression | 14:28 |
| * rogpeppe breathes a sigh of relief that r2644 isn't his. | 14:29 | |
| wallyworld | rogpeppe: do you know when maas name support (via the tags constraint) landed? 1.16? | 14:29 |
| rogpeppe | wallyworld: sorry, i have no idea | 14:29 |
| dimitern | wallyworld, i'm not sure - have to look at the blame log | 14:29 |
| wallyworld | ok, np | 14:30 |
| wallyworld | dimitern: np. but we *do* support ir right? | 14:30 |
| natefinch | alexisb: I think what the deal is, IIRC, is that tags doesn't actually match names, unless you give each maas machine a tag equal to it's name | 14:30 |
| natefinch | alexisb: and I think that's why the people using maas don't really like it, because it's a kind of a PITA | 14:30 |
| natefinch | alexisb: I wrote the tags code a long time ago (October, maybe? Definitely before 2014) | 14:31 |
| alexisb | wallyworld, I am taking over the corss team meeting but I wasnt given a leader code | 14:31 |
| dimitern | wallyworld, I'm not sure how that failure has to do with maas agent name? | 14:31 |
| wallyworld | dimitern: no, separate question :-) | 14:31 |
| dimitern | wallyworld, support for maas name was added long ago | 14:32 |
| wallyworld | dimitern: alexisb was asking to tell the landscape folks | 14:32 |
| dimitern | wallyworld, but not sure who or when | 14:32 |
| wallyworld | ok, thanks, i thought it was added a while back, yeah | 14:32 |
| natefinch | dimitern: I thought we didn't support constraint by name, thought they had to create a tag with the maas name... or maybe I missed the time where we fixed that | 14:33 |
| dimitern | natefinch, ok, sorry I don't really follow | 14:33 |
| dimitern | natefinch, the name thing was something maas api needed from some point on | 14:33 |
| dimitern | natefinch, i don't think it's a constraint, or if it is, it's maas specific | 14:34 |
| wallyworld | dimitern: natefinch: there's a tags constraint which was done for maas IIRC | 14:34 |
| wallyworld | which matches with nate's recollection you need to add tags t your maas instances i think | 14:34 |
| * wallyworld -> bed, then 4 days off for easter :-D | 14:35 | |
| natefinch | wallyworld: night! | 14:35 |
| rogpeppe | dimitern: reviewed | 14:44 |
| dimitern | rogpeppe, thanks! | 14:45 |
| natefinch | sonofa | 14:52 |
| natefinch | $which juju | 14:52 |
| natefinch | /usr/bin/juju | 14:52 |
| natefinch | well there was like 4 hours wasted | 14:53 |
| natefinch | gah... I hate it when tests are so DRY'd out that I can't figure where the actual data is that I need to change to make them pass :/ | 15:25 |
| natefinch | rogpeppe: how do I fix the status tests so they expect the new status item I added? it's 2000 lines and the assertion that fails is in the middle somewhere | 15:28 |
| rogpeppe | natefinch: i'm afraid you'll have to work that out... | 15:28 |
| natefinch | and OMG, whose idea was it to use single letter type names? | 15:29 |
| natefinch | M and L my ass | 15:29 |
| * natefinch is grumpy | 15:29 | |
| natefinch | rogpeppe: btw, the status change shows a single bootstrap node stays in "adding vote" perpetually (has vote:n, wants vote: y). Is that correct? | 15:31 |
| rogpeppe | natefinch: that seems wrong, and i didn't observe that | 15:32 |
| rogpeppe | natefinch: except... perhaps it needs to peergrouper worker enabled for that to work | 15:32 |
| natefinch | rogpeppe: possible | 15:33 |
| rogpeppe | natefinch: so, yeah, that's probably right in your branch | 15:33 |
| rogpeppe | natefinch: i suppose we could change the state initialisation to set machine 0's HasVote to true | 15:33 |
| natefinch | gah, fixing these tests is going to take like 10 times as long as actually writing the code | 15:39 |
| hazmat | so how would you guys feel about a provisioner that took 3-4 hrs for a machine.. | 15:40 |
| natefinch | hazmat: so, azure? | 15:40 |
| hazmat | i ask cause that's roughly the time for a baremetal machine on softlayer | 15:40 |
| natefinch | hazmat: do they have to go build the machine from parts first? | 15:41 |
| hazmat | natefinch, interestingly enough.. after we did all that work for availability set on azure.. there's a new azure tier thats cheaper and sans az and auto load balance. | 15:41 |
| hazmat | natefinch, i dunno.. rack and stack via robots i'd assume ;-) | 15:41 |
| natefinch | hazmat: it would be an interesting test of our timeouts.... I don't really know how we'd do in such a situation. | 15:42 |
| natefinch | I gotta run to pick up my daughter from preschool | 15:42 |
| natefinch | I'll be back in probably 45 minutes | 15:43 |
| hazmat | natefinch, well for bootstrap we'd use a cloudinstance which would take 3m | 15:51 |
| rogpeppe | natefinch, mgz, dimitern: a necessary peergrouper worker fix prior to final HA proposal, review appreciated: https://codereview.appspot.com/88000050 | 16:10 |
| mgz | rogpeppe: looking | 16:10 |
| rogpeppe | mgz: ta! | 16:11 |
| dimitern | rogpeppe, looking as well | 16:11 |
| rogpeppe | dimitern: ta! | 16:11 |
| dimitern | rogpeppe, reviewed | 16:17 |
| rogpeppe | dimitern: brill, thanks | 16:17 |
| mgz | rogpeppe: just reading through the last test, everything so far makes sense to me | 16:19 |
| rogpeppe | mgz: great, thanks | 16:19 |
| mgz | heh, mini language for statuses | 16:20 |
| mgz | rogpeppe: lgtm. that watch machines bit at the end is slightly hairy, but I guess timeout for failure cases is fine | 16:24 |
| rogpeppe | mgz: ta. better than polling i think. | 16:24 |
| mgz | only one machine will actually change, right? (or at least change significatly) | 16:25 |
| mgz | watching all of them is just for sanity | 16:25 |
| rogpeppe | mgz: yeah | 16:29 |
| rogpeppe | mgz, dimitern, natefinch: cherry on the cake: https://codereview.appspot.com/87860047/ | 16:29 |
| rogpeppe | when that lands, i think we can finally say that HA is "in" | 16:29 |
| mgz | can say HA! to HA | 16:30 |
| dimitern | rogpeppe, will look in a bity | 16:30 |
| * rogpeppe tries another live test | 16:30 | |
| dimitern | bit | 16:30 |
| rogpeppe | dimitern: thanks | 16:30 |
| natefinch | rogpeppe: looking | 16:32 |
| rogpeppe | natefinch: ta! | 16:32 |
| natefinch | rogpeppe: lgtm'd | 16:56 |
| rogpeppe | natefinch: thanks! | 16:56 |
| rogpeppe | mgz: any chance you could have a once-over? this is an important step... | 16:57 |
| mgz | rogpeppe: I'll try | 16:57 |
| mgz | rogpeppe: seems fine | 17:08 |
| rogpeppe | mgz: thanks for looking | 17:08 |
| rogpeppe | mgz: i'll land it then. i just encountered a live failure mode, but i think it's better in where people can play with it. | 17:09 |
| rogpeppe | mgz: i agree about the random set of changes - it's just the dross after everything else has been parcelled up nicely... | 17:11 |
| mgz | :) | 17:12 |
| rogpeppe | natefinch: how's the status stuff coming along? | 17:18 |
| rogpeppe | natefinch: i was just debugging an issue that could really have benefitted from it... | 17:18 |
| natefinch | rogpeppe: trying to fix all the tests.. The code was easy, the tests are a PITA, because I don't get a line number of where the failure actually is | 17:18 |
| natefinch | rogpeppe: so I have to infer what data it was using to test | 17:19 |
| rogpeppe | natefinch: hmm | 17:19 |
| rogpeppe | natefinch: is that the problem where gocheck doesn't print the whole stack? | 17:19 |
| rogpeppe | natefinch: if so, that's bugged me for years | 17:19 |
| natefinch | rogpeppe: it's more that we're using table-ish driven tests... without any unique identifier on the row we're testing (at least as far as I can tell) | 17:20 |
| rogpeppe | natefinch: in which case, please add an identifier | 17:20 |
| natefinch | rogpeppe: that's a good idea | 17:21 |
| rogpeppe | natefinch: in the meantime, could you push your branch so that i can use it to debug my stuff? :-) | 17:22 |
| natefinch | rogpeppe: sure | 17:22 |
| natefinch | rogpeppe: lp:~natefinch/juju-core/rogpeppe-556-status-show-stateserver | 17:23 |
| natefinch | rogpeppe: I was wrong, there is an identifier, it's just logged nondescriptly like 50 lines before the test failure output (due to all the log output), | 17:28 |
| rogpeppe | natefinch: ah. maybe make it more obvious by adding a newline then? | 17:28 |
| natefinch | rogpeppe: yeah | 17:29 |
| rogpeppe | HA has landed | 17:32 |
| rogpeppe | woo | 17:32 |
| natefinch | wooo! | 17:33 |
| rogpeppe | natefinch: i thought we were going to go with a single string representation of the server status | 17:41 |
| rogpeppe | natefinch: as we discussed yesterday | 17:41 |
| natefinch | rogpeppe: sorry, I thought those were the strings we had agreed on... I tried to get them from chat history, but might have grabbed a non-final proposal | 17:42 |
| rogpeppe | natefinch: hmm, maybe i've used the wrong branch | 17:42 |
| natefinch | rogpeppe: the ones I put in were, indeed multi-word, honestly, I thought it was odd that we had decided on that after you mentioned wanting single word statuses | 17:43 |
| rogpeppe | natefinch: i'm still not sure :-) | 17:44 |
| natefinch | rogpeppe: we can just hyphenate them, if you want | 17:44 |
| rogpeppe | natefinch: hmm, looks like i was using the wrong branch | 17:44 |
| natefinch | rogpeppe: this is what I have: | 17:44 |
| natefinch | switch { | 17:44 |
| natefinch | case hasVote && wantsVote: | 17:44 |
| natefinch | s = "has vote" | 17:44 |
| natefinch | case hasVote && !wantsVote: | 17:44 |
| natefinch | s = "removing vote" | 17:44 |
| natefinch | case !hasVote && wantsVote: | 17:44 |
| natefinch | s = "adding vote" | 17:44 |
| rogpeppe | natefinch: if that saves them from being quoted by yaml, i reckon that's maybe goo | 17:44 |
| natefinch | case !hasVote && !wantsVote: | 17:44 |
| rogpeppe | d | 17:44 |
| natefinch | s = "no vote" | 17:44 |
| natefinch | } | 17:44 |
| natefinch | rogpeppe: good point | 17:45 |
| rogpeppe | natefinch: i still see the jobs field in there though | 17:47 |
| rogpeppe | natefinch: on balance i think perhaps the hyphen will be better | 17:47 |
| natefinch | rogpeppe: I thought you had wanted the jobs field? | 17:47 |
| rogpeppe | natefinch: no, i don't think it's necessary in the human-readable status | 17:48 |
| natefinch | rogpeppe: ok, my misunderstanding, I'll remove it | 17:48 |
| rogpeppe | natefinch: the existence of member-status implies that it's an environ manager | 17:48 |
| natefinch | rogpeppe: right, I was thinking that, and pretty much everything can host units | 17:49 |
| rogpeppe | natefinch: i'm wondering whether "state-server-member-status" might be a slightly more obvious name | 17:49 |
| rogpeppe | natefinch: (long, but more self-explanatory that it's referring to a state server) | 17:50 |
| natefinch | rogpeppe: if we had more than one state-specific status I'd suggest indenting them all under a "state-server" heading | 17:51 |
| natefinch | rogpeppe: but for now, I guess an extra-long name is ok | 17:51 |
| === vladk is now known as vladk|offline | ||
| rogpeppe | natefinch: one other tiny thing: perhaps put the member status at the start of the struct, so it's more obvious when reading the status output | 17:56 |
| rogpeppe | yay! i just successfully deleted the bootstrap machine entirely and i've still got a working environment | 18:03 |
| natefinch | nice | 18:03 |
| rogpeppe | it does take ages for mongo to recover | 18:04 |
| rogpeppe | sinzui: you can try enabling the HA test now... | 18:04 |
| rogpeppe | sinzui: although i think you'll probably want to wait for natefinch's status change so you can gate the test's actions on state server status changes | 18:05 |
| rogpeppe | s/status change/status change CL/ | 18:05 |
| natefinch | rogpeppe: https://codereview.appspot.com/87760057/ | 18:09 |
| rogpeppe | natefinch: BTW having seen the voting status in action, it reads very nicely | 18:11 |
| natefinch | rogpeppe: yeah, it's definitely nice to have | 18:11 |
| rogpeppe | alexisb: HA has landed and seems to work (to a first approximation anyway :-]) | 18:11 |
| rogpeppe | natefinch: LGTM | 18:13 |
| rogpeppe | natefinch: ideally there would be some tests for different statuses, but i'm not overly picky | 18:14 |
| natefinch | rogpeppe: I presume the hasvote wantsvote stuff is tested on the server, and testing the tiny functionality of the thing that translates those into strings would just require duplicating the function itself. I guess testing that the API returns the right data could be useful. | 18:17 |
| rogpeppe | natefinch: well, you wouldn't strictly need to duplicate the function itself | 18:17 |
| rogpeppe | natefinch: as i said, i don't mind too much otherwise i wouldn't've LGTM'd | 18:18 |
| alexisb | sweetness rogpeppe !!!!! | 18:22 |
| alexisb | well done team! | 18:22 |
| rogpeppe | alexisb: thanks | 18:23 |
| bac | sinzui: how would you like to do a charmworld review for old time's sake? | 18:29 |
| sinzui | okay bac | 18:29 |
| bac | sinzui: sweet. https://codereview.appspot.com/88980043 | 18:29 |
| bac | its a mishmash of drive bys on my way to doing a real branch. but solves some very annoying problems. | 18:30 |
| sinzui | bac: LGTM | 18:33 |
| sinzui | thank you for modernising the interpolation too | 18:33 |
| rogpeppe | natefinch: failed test... | 18:39 |
| natefinch | rogpeppe: yeah, I forgot the api server changed, too, so I hadn't run those tests. Fixing now | 18:39 |
| rogpeppe | natefinch: np | 18:39 |
| rogpeppe | natefinch: i'm just about to send an email to juju-dev@lists.ubuntu.com mentioning the HA changes. it mentions the status. i'll postpone the email until your branch lands | 18:40 |
| rogpeppe | right, that's me done | 18:42 |
| natefinch | rogpeppe: fixed, re-approving | 18:43 |
| natefinch | rogpeppe: good work on the HA stuff. | 18:43 |
| rogpeppe | natefinch: you too | 18:43 |
| rogpeppe | see y'all in denver or las vegas! | 18:44 |
| natefinch | rogpeppe: I swept up the few scraps you left in your wake. But glad it's done | 18:44 |
| natefinch | rogpeppe: have a good trip! | 18:44 |
| rogpeppe | natefinch: i will do my best | 18:44 |
| rogpeppe | natefinch: hopefully i won't discover my passport's gone missing :-) | 18:44 |
| rogpeppe | g'night all | 18:44 |
| natefinch | rogpeppe: haha | 18:46 |
| bac | thanks sinzui. a modern interpolation is a happy interpolation. | 19:13 |
| lazyPower | is there an upper limit to the number of machines you can utilize on the local provider? | 20:42 |
| natefinch | lazyPower: generally RAM is the limiting factor. | 20:42 |
| natefinch | lazyPower: there's no hard coded limit | 20:43 |
| lazyPower | ok thats what i was looking for. thanks natefinch | 20:44 |
| natefinch | lazyPower: welcome | 20:47 |
| stokachu | so juju will copy my apt proxy information on my host system in a local provider install | 20:58 |
| stokachu | but if i set my host system to localhost:8000 then the deployed instances in the local provider wont work | 20:58 |
| stokachu | as the lxc device is 10.0.3.1 | 20:58 |
| stokachu | is that expected? | 20:58 |
| natefinch | stokachu: that sounds like something we haven't tested, but I'm not 100% sure. | 21:00 |
| stokachu | i guess _should_ juju be copying an existing apt-proxy conf file from the host system to the deployed | 21:00 |
| natefinch | stokachu: well, so for local, your host system *is* the bootstrap node | 21:00 |
| stokachu | right, so, if my host system has an apt proxy conf directive pointing to http://localhost:8000 then thats whats in the deployed node | 21:01 |
| stokachu | however localhost:8000 on the deployed node doesn't work | 21:01 |
| stokachu | should be 10.0.3.1 for the lxc device or whatever network bridge is defined | 21:01 |
| stokachu | i could be totally off on this | 21:02 |
| natefinch | That's probably not something we really support. You're welcome to file a bug and people who know that area of the code better than I do will look at it :) | 21:02 |
| natefinch | It's EOD for me, and the boss is getting antsy, so I gotta run | 21:02 |
| psivaa | hello, could i know how to workaround 'src/launchpad.net/juju-core/utils/ssh/ssh_gocrypto.go:84: undefined: ssh.ClientConn' when running 'go install -v launchpad.net/juju-core/...' pls? | 21:30 |
| psivaa | go get -u -v launchpad.net/juju-core/... gives the following logs: http://pastebin.ubuntu.com/7270917/ | 21:30 |
| lazyPower | psivaa: they may be EOD'd/about to EOD. normal hours are 9am - 5pm EST | 21:44 |
| psivaa | lazyPower: ack, my bad in fact. was supposed to query this earlier, but got held up fixing some issues in my system. thx . i'll pick it up when someone answers | 21:51 |
| lazyPower | ack. I just wanted you to know they will see it, but it may be a bit before you get a response. | 21:51 |
| psivaa | ack, thank you :) | 21:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!