| bodie_ | https://github.com/juju/charm/pull/4 (fwereade, mgz, rogpeppe1) | 00:29 |
|---|---|---|
| bodie_ | (and jcw4) | 00:29 |
| bac | hi bigjools | 00:31 |
| sinzui | axw, The unittest jobs and build action in the publish revision job uses golang 1.2 from the ~juju experimental ppa for saucy and precise | 01:02 |
| axw | sinzui: cool, thank you | 01:02 |
| waigani | thumper: you about? | 01:09 |
| axw | sinzui: doesn't build-revision need it too? | 01:16 |
| axw | sinzui: seems that juju-ci.vapour.ws still has 1.1.2, and that's where build-revision runs right? | 01:16 |
| sinzui | axw no, really | 01:18 |
| sinzui | axw we make a tarball in that step. the tarball only has source code | 01:19 |
| thumper | waigani: am now | 01:19 |
| davecheney | sinzui: so should I try to land that branch again ? | 01:19 |
| sinzui | axw, the build step does give some confidence that it works, but the output is ignored | 01:20 |
| waigani | thumper: just wondering about the info cmd | 01:20 |
| waigani | thumper: did you catch up with fwereade about it? | 01:20 |
| sinzui | axw the tarball made into a source package for each series, then for each source package a builder of the right series and arch is provisioned. That builder gets the right golang of gccgo. | 01:21 |
| sinzui | axw, that is how Ubuntu and Lp does, so we do it too | 01:21 |
| axw | sinzui: except it's "set -e", so the "go build" fails the whole script if it fails? | 01:22 |
| axw | mmk | 01:22 |
| sinzui | oh, well I will remove that now. it is vestigial | 01:23 |
| thumper | waigani: yeah... | 01:23 |
| thumper | waigani: we should chat, let me get some food first | 01:23 |
| axw | sinzui: I think it's nice to have, but if we could drop it for now that'd be great | 01:24 |
| sinzui | axw, the build step is gone | 01:26 |
| axw | thanks! | 01:26 |
| axw | davecheney: ^^ try your merge again | 01:26 |
| davecheney | axw: ok | 01:27 |
| davecheney | thanks | 01:27 |
| wallyworld | axw: morning. will you have time today to look at bug 1240146 ? after the current az stuff is landed? | 01:28 |
| axw | wallyworld: sure | 01:29 |
| wallyworld | axw: thanks :-) azure provider performance and bugs is becoming a hot topic | 01:29 |
| axw | wallyworld: ehm, I think I already did this a while ago :) | 01:31 |
| axw | will look deeper, but I'm pretty sure this is resolved | 01:31 |
| wallyworld | axw: i wondered about that, i figured there must be something new that we didn't know about | 01:31 |
| wallyworld | i didn't look too closely, just added the card | 01:32 |
| axw | wallyworld: I believe I added this when I did the availability set revamp | 01:32 |
| wallyworld | that was post 1.18 right? | 01:32 |
| axw | anyway, will confirm | 01:32 |
| axw | yes | 01:32 |
| axw | 1.19 | 01:32 |
| wallyworld | so it must just be people on 1.18 complaining | 01:32 |
| wallyworld | and 1.20 is due out next week | 01:32 |
| axw | it is? okay, I better fix that local-provider HA thing then | 01:33 |
| wallyworld | that's the plan - release 1.19.4 this week and turn into 1.20 if all good | 01:33 |
| wallyworld | the current 1.19.4 milestone has no show stopper bugs that are recorded against it | 01:34 |
| wallyworld | if there's somthing to do, the bug needs to be added to the milestone | 01:34 |
| axw | I will add it | 01:34 |
| wallyworld | ta | 01:34 |
| axw | davecheney: what's that error? went too far and got 1.3 changes? | 01:35 |
| axw | oh, it's getting vet | 01:35 |
| axw | groan | 01:36 |
| bodie_ | sigh, I really need to set up my dev system in a vagrant box | 01:47 |
| bodie_ | I want to use mongo for something I'm working on personally but I'm not confident about installing it alongside the "special" version | 01:48 |
| bodie_ | anyone know if that should be relatively painless? | 01:48 |
| bodie_ | I'm assuming more on the relatively painful end of the spectrum | 01:48 |
| axw | davecheney: I've updated the build config to checkout go.tools as at the 1.2 release, retrying your build now | 01:49 |
| sinzui | bodie_, I run in lxc | 01:49 |
| bodie_ | sinzui, did you see the lxc cluster scheduler google open-sourced today? | 01:49 |
| bodie_ | hmmmm... so you run mongo itself in lxc if you need your own version? I've never played w/ lxc much | 01:50 |
| sinzui | bodie_, I haven't | 01:50 |
| sinzui | bodie_, give me a moment to paste bin what I think is my last container and setup | 01:51 |
| bodie_ | sinzui, https://github.com/GoogleCloudPlatform/kubernetes | 01:53 |
| sinzui | bodie_, http://pastebin.ubuntu.com/7631475/ | 01:54 |
| axw | you could just use the local provider, too | 01:55 |
| bodie_ | that's awesome, thanks :) | 01:55 |
| bodie_ | true | 01:55 |
| sinzui | axw, the juju-reports project's makefile always runs the project in the charm, and it sets a bzr server to server updates to the branch to the charm. instant updates that always run in production | 01:56 |
| waigani | thumper: ready when you are | 01:56 |
| thumper | waigani: I have a scheduled call with wallyworld shortly, how about after that? | 01:57 |
| waigani | thumper: okay, I have to do school run at 3 | 01:57 |
| sinzui | bodie_, I think I installed this the first time I used the container because it was missing something that made apps misbehave | 02:06 |
| sinzui | sudo apt-get install language-pack-en avahi-daemon build-essential python-dbus | 02:06 |
| bodie_ | hmm, I just did a go install ./... from my root juju source directory, and juju bootstrap is asking me to apt-get install juju-local | 02:06 |
| bodie_ | I don't think I want to do that | 02:06 |
| bodie_ | do I? | 02:06 |
| axw | you do if you want to use the local provider | 02:06 |
| bodie_ | isn't that part of our repo? | 02:06 |
| axw | juju-local juse installs prereq packages: mongo, rsyslog, etc. | 02:07 |
| axw | just* | 02:07 |
| bodie_ | I see | 02:07 |
| bodie_ | it also wants to install juju-core | 02:07 |
| bodie_ | I just don't want to override my $GOPATH/bin juju stuff | 02:08 |
| axw | you'll have to ensure that $GOPATH/bin comes before /usr/bin in $PATH | 02:08 |
| bodie_ | fair enough, that makes sense | 02:08 |
| axw | hurrrngh | 02:12 |
| * axw has flashbacks to building The Build Guy at his previous job | 02:13 | |
| axw | being | 02:13 |
| bodie_ | heh | 02:14 |
| bodie_ | sorry *pat pat* | 02:14 |
| thumper | waigani: let me know when you are back from the school run | 03:05 |
| thumper | waigani: and we can talk | 03:05 |
| thumper | https://github.com/juju/juju/pull/81 for anyone, simple, found the code lying around... | 03:15 |
| thumper | wallyworld: https://bugs.launchpad.net/juju-core/+bug/1329154 | 03:52 |
| _mup_ | Bug #1329154: Make it possible to create the lxc templates without a running environment <local-provider> <plugin> <juju-core:Triaged by niedbalski> <https://launchpad.net/bugs/1329154> | 03:52 |
| wallyworld | ta | 03:53 |
| thumper | wwitzel3: ta | 03:56 |
| wwitzel3 | thumper: np | 03:56 |
| * thumper goes to make coffee | 03:58 | |
| waigani | thumper, menn0: ModifyUser - all tests pass. | 04:10 |
| menn0 | waigani: we just both wrote about the same email at the same time | 04:10 |
| waigani | great minds... | 04:11 |
| waigani | thumper if it is okay to keep it as is, can I just remove the annotation from Tag? Or is there more to it? | 04:14 |
| waigani | thumper: also, did you want to talk about juju info? | 04:15 |
| * thumper looks | 04:28 | |
| * thumper wonders what the hell he was thinking about... | 04:29 | |
| thumper | I'm sure there was something... | 04:29 |
| thumper | waigani: when you said you ran all the tests, did you mean *ALL* or just the apiserver tests? | 04:31 |
| waigani | lol thumper all | 04:31 |
| * thumper pulls a face | 04:31 | |
| waigani | thumper: some failed with panics, reran those and they passed | 04:32 |
| thumper | I'm sure the api client user manager tests would fail at least one | 04:32 |
| waigani | $ cd state/apiserver/usermanager/ | 04:34 |
| waigani | .../state/apiserver/usermanager$ nolog | 04:34 |
| waigani | OK: 10 passed | 04:34 |
| waigani | PASS | 04:34 |
| waigani | ok github.com/juju/juju/state/apiserver/usermanager2.377s | 04:34 |
| waigani | /state/apiserver/usermanager$ | 04:34 |
| waigani | thumper: ^ | 04:34 |
| * thumper checks | 04:34 | |
| thumper | hmm... perhaps the default json serialisation is to lower case the names... | 04:35 |
| thumper | that is the only thing that makes sense there... | 04:35 |
| thumper | bit I seem to recall logs where that wasn't the case... | 04:36 |
| thumper | although that may have been the deserialized json | 04:36 |
| thumper | although... | 04:36 |
| waigani | thumper: I don't follow, where are you looking? | 04:36 |
| thumper | based on what menn0 said, and that this wasn't hooked up before... | 04:36 |
| thumper | we should just make the api clean | 04:36 |
| thumper | which means I should delete my backwards compatability bit | 04:37 |
| thumper | because that's dumb | 04:37 |
| menn0 | thumper: good point | 04:38 |
| waigani | okay, actually, do we even need to keep Tag then? | 04:38 |
| menn0 | I wish I'd remember that when you made the change | 04:38 |
| thumper | heh | 04:38 |
| thumper | waigani: I hold to my thought that the two structures are for different things | 04:39 |
| thumper | and we should reuse them because they are "kinda similar" | 04:39 |
| thumper | that way lies pain as code moves on | 04:39 |
| thumper | we never pass back password | 04:39 |
| thumper | for example | 04:39 |
| waigani | thumper: did you see fwereade's comment on this? | 04:39 |
| * thumper sighs | 04:39 | |
| thumper | no | 04:39 |
| * thumper looks | 04:39 | |
| waigani | thumper: If I understand him correctly, he is arguing the opposite | 04:40 |
| thumper | waigani: there are a lot of fwereade's comments hidden due to changing code. | 04:40 |
| * thumper looks at the email trail | 04:40 | |
| waigani | thumper: comment below | 04:41 |
| waigani | so this looks to me very much like a UserInfo. What's the thinking behind having separate types? The params package really ought to be expressing the language we're using in the api, not just a grab-bag of ad-hoc structs. | 04:41 |
| waigani | NOTE: there are certainly reasons to choose to split the types. I'm not sure the ones I can think of are quite good enough to justify it, but I want to be sure we've considered them. | 04:41 |
| thumper | yeah | 04:41 |
| thumper | reading and thinking | 04:41 |
| thumper | I think we do want to split them | 04:41 |
| thumper | because we are about to return "date created, creator, and last connection" | 04:42 |
| waigani | okay, and the justification? | 04:42 |
| thumper | these are not fields you send up | 04:42 |
| thumper | make sense? | 04:42 |
| waigani | right | 04:42 |
| waigani | yep | 04:42 |
| thumper | so... | 04:42 |
| thumper | ModifyUser should stay distinct from the UserInfo struct | 04:42 |
| thumper | ModifyUser is for add/modify user client -> server instructions | 04:43 |
| waigani | okay, should we remove Tag from it now? | 04:43 |
| thumper | UserInfo is for server-> client info | 04:43 |
| thumper | well... | 04:43 |
| thumper | that is an interesting question... | 04:43 |
| waigani | yep, that is clear | 04:43 |
| thumper | when we create a user, we are specifying a username for them | 04:44 |
| thumper | this clearly isn't a tag | 04:44 |
| thumper | however when we modify them, we may well want to define them with a tag (even though I think it is dumb) | 04:44 |
| thumper | as long as it is a real tag | 04:44 |
| thumper | bah humbug | 04:44 |
| waigani | in which case we should remove the deprecated comment | 04:44 |
| thumper | agreed | 04:45 |
| thumper | and the behaviour should change... | 04:45 |
| thumper | but don't do it all at ocne | 04:45 |
| thumper | we have never ending feature creep | 04:45 |
| thumper | we want small defined bits of work | 04:45 |
| thumper | with as little extraneous bits of change as possible | 04:45 |
| waigani | agreed | 04:45 |
| thumper | so it should change, but not in this branch | 04:46 |
| waigani | just remove the comment? and add a todo? | 04:46 |
| thumper | no, don't touch it | 04:46 |
| waigani | okay | 04:46 |
| waigani | I'll remove the annotation though | 04:46 |
| waigani | actually what am i saying | 04:46 |
| thumper | no, it is a different struct | 04:47 |
| waigani | it will be like it was before, no annotations | 04:47 |
| thumper | right | 04:47 |
| waigani | yep | 04:47 |
| thumper | just add the new UserInfo | 04:47 |
| waigani | yep | 04:47 |
| thumper | although add in the extra fields that landed yesterday | 04:47 |
| thumper | that way the struct is obviously different | 04:47 |
| thumper | to the Modify User one | 04:47 |
| waigani | right, cool new fields :) | 04:47 |
| thumper | you may also want to update your tests to create the users with the factory | 04:48 |
| waigani | oh nice :) | 04:48 |
| waigani | is there an example to look at? | 04:48 |
| waigani | or at least what package is it? | 04:48 |
| thumper | yes | 04:48 |
| waigani | suite even? | 04:48 |
| thumper | and yes | 04:48 |
| thumper | testing/factory | 04:49 |
| waigani | cool, I'll get onto it | 04:49 |
| thumper | ok | 04:49 |
| thumper | wallyworld: here is another bug you could pass on: https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1290920 | 04:58 |
| _mup_ | Bug #1290920: non-default lxc-dir breaks local provider <local> <lxc> <regression> <juju-core:Triaged> <juju (Ubuntu):Confirmed> <https://launchpad.net/bugs/1290920> | 04:58 |
| wallyworld | will do | 04:58 |
| wallyworld | ta | 04:58 |
| * thumper back later tonight for team meeting | 05:12 | |
| thumper | team leads that is | 05:13 |
| dimitern | morning | 05:35 |
| dimitern | any reviewers wanna have a look ? https://github.com/juju/juju/pull/78 | 05:43 |
| dimitern | jam, fwereade, TheMue, vladk|offline, ^^^ | 06:05 |
| === vladk|offline is now known as vladk | ||
| wallyworld | fwereade: i've addressed all your suggestions in that txn branch, not sure if anyone else has looked. off to soccer now, back later for more meetings \o/ | 07:12 |
| jam | dimitern: so I'm trying to sort out where pending networks helps us. If it is just the list from the provider, can't we just list the provider when we need to? | 07:22 |
| dimitern | fwereade, ping | 07:38 |
| rogpeppe1 | anyone know a decent way to easily fetch someone's pull request branch locally? | 07:40 |
| dimitern | rogpeppe1, it's best to add another upstream first | 07:41 |
| rogpeppe1 | dimitern: that would mean i'd need an upstream for everyone that sends a PR | 07:41 |
| rogpeppe1 | dimitern: which seems a bit like overkill | 07:41 |
| dimitern | rogpeppe1, only if you need to collaborate on another guy's branches in his fork | 07:42 |
| rogpeppe1 | dimitern: i saw this, but it doesn't seem to correspond to reality: https://help.github.com/articles/checking-out-pull-requests-locally | 07:42 |
| rogpeppe1 | dimitern: i don't want to do that | 07:42 |
| rogpeppe1 | dimitern: i just want to fetch it and maybe run the tests | 07:42 |
| voidspace | morning all | 07:43 |
| dimitern | rogpeppe1, if you're using github/hub, it's as easy as hub clone user/repo dir | 07:43 |
| rogpeppe1 | voidspace: hiya | 07:43 |
| voidspace | o/ | 07:43 |
| dimitern | voidspace, yo! | 07:43 |
| rogpeppe1 | dimitern: i don't want to clone, i want to create a new branch in an existing dir | 07:43 |
| * rogpeppe1 wishes the hub command had a hub-specific help | 07:43 | |
| axw | rogpeppe1: https://help.github.com/articles/merging-a-pull-request ? | 07:44 |
| dimitern | rogpeppe1, then git fetch | 07:44 |
| dimitern | git remote add mislav git://github.com/mislav/REPO.git | 07:44 |
| dimitern | git fetch mislav | 07:44 |
| dimitern | rogpeppe1, ^^ that's what i'd do | 07:44 |
| rogpeppe1 | dimitern: unfortunately github doesn't actually make the name of the remote repo clear | 07:44 |
| dimitern | rogpeppe1, naming is always user/repo | 07:45 |
| rogpeppe1 | dimitern: yeah, but the "repo" might be different if the user has renamed it | 07:45 |
| dimitern | rogpeppe1, what?! :) | 07:45 |
| dimitern | rogpeppe1, why is that a concern if you're fetching something now? | 07:46 |
| rogpeppe1 | dimitern: like my fork of github.com/juju/utils is github.com/rogpeppe/juju-utils | 07:46 |
| rogpeppe1 | dimitern: ok, my specific example is this: https://github.com/juju/charm/pull/4/commits | 07:47 |
| dimitern | rogpeppe1, so? you can name your fork however you wish | 07:47 |
| jam | (11:22:43 AM) jam: dimitern: so I'm trying to sort out where pending networks helps us. If it is just the list from the provider, can't we just list the provider when we need to? | 07:47 |
| rogpeppe1 | dimitern: where can i see the repo that the pull request is coming from? | 07:47 |
| dimitern | rogpeppe1, if you click on the commit (a58c39a in this case) it will take you to the commit, where at the top you can see the repo | 07:48 |
| dimitern | binary132/charm | 07:48 |
| dimitern | forked from juju/charm | 07:48 |
| rogpeppe1 | dimitern: ah, i didn't know those hex commit numbers were links | 07:49 |
| rogpeppe1 | dimitern: thanks | 07:49 |
| dimitern | jam, we need to know what networks are there from state | 07:49 |
| dimitern | rogpeppe1, np :) | 07:49 |
| dimitern | jam, 1) they don't change that often, so once we have them we don't need to ask every time we try to use a network | 07:49 |
| rogpeppe1 | dimitern: i've also found that there's a link at the bottom "You can also merge branches on the _command line_" and if you click on _command line_, you get all the useful info | 07:49 |
| dimitern | jam, 2) it allows us to watch for changes from one place over pendingnetworks and update them from another | 07:50 |
| dimitern | rogpeppe1, nice! | 07:50 |
| dimitern | jam, the idea is, once we have them to implement add-network --existing <provider-id> ... or even list-networks --existing | 07:51 |
| jam | dimitern: sure, but both of those use cases should arguably go query the provider directly rather than using possibly stale data from state | 07:51 |
| dimitern | jam, so why store addresses when we can always get them from the provider when we need to? | 07:52 |
| dimitern | :) | 07:52 |
| jam | dimitern: frequency of use | 07:52 |
| jam | dimitern: I don't see us using "unknown" networks frequently | 07:52 |
| jam | and the use cases for tracking them seem to actually be "we should refresh before using them" which means we should just probe the provider directly. | 07:53 |
| dimitern | jam, we will use them to detect the default private/public networks | 07:53 |
| jam | dimitern: but aren't those public and private networks in the model, and not pending networks? | 07:53 |
| dimitern | jam, they will be promoted to be the defaults | 07:53 |
| dimitern | jam, all this is the result of my discussion with fwereade | 07:54 |
| dimitern | (if i understood him correctly, that is) | 07:54 |
| jam | dimitern: fwereade: so my thought, at least, was that we would make our best guess as to public and private and then the user could fix them from there. | 07:55 |
| jam | which is still we have 2 concrete networks out of the box | 07:55 |
| jam | dimitern: I think the code you wrote looks pretty good (I haven't finished reading all of it), | 07:55 |
| jam | I'm just trying to understand the specific benefit we get from caching it. | 07:55 |
| rogpeppe1 | dimitern: ha, it's actually even easier: hub checkout https://github.com/juju/charm/pull/4 | 07:55 |
| dimitern | jam, re IsVLANTag - originally I wanted to have either a (bool, error) return - returning false, nil for 0 and true, nil for 0 < tag <= 4094, false, err otherwise | 07:56 |
| jam | because if they really are *pending* then it isn't something I feel we should be touching except for times when we actually do need to ask the provider. | 07:56 |
| jam | dimitern: that could be ok, though it is a rather subtle distinction it does fit the question of "is this Valid, and is this a VLAN" | 07:57 |
| dimitern | jam, the idea eventually is to have a way do define mapping in env config how to translate provider-id -> juju-name for the default networks, but first we'll have cli commands to do it manually | 07:57 |
| jam | dimitern: you still haven't shown me a case for where we need to record the provider network as something we only sort-of know about (pending). Either it is mapped in and we track it, or it is still pending and we don't care. | 07:58 |
| jam | when you go to "list networks" we really do need to probe the provider | 07:58 |
| dimitern | jam, ok, so I can make it return err for 0 >= tag > 4094 | 07:58 |
| jam | because they might have just added one | 07:58 |
| dimitern | jam, it's pending, because we need the user to give it a name | 07:58 |
| dimitern | which is descriptive for them | 07:59 |
| dimitern | jam, i can come up with a quick-n-dirty scheme to name any network with a private CIDR range as "private#" (if more than 1) | 08:00 |
| dimitern | jam, but fwereade didn't like that and i can concur | 08:00 |
| jam | dimitern: so I still don't know why we need to have described a network we haven't named yet | 08:01 |
| jam | when the user does something to map a provider ID into a known network, we'll go find the details and put it into the model | 08:02 |
| jam | dimitern: is this for listing what networks a machine has access to? | 08:02 |
| jam | if so, we *still* need a name for them | 08:02 |
| jam | to display them | 08:02 |
| jam | unknown-$PROVIDER_ID could work | 08:02 |
| dimitern | jam, no | 08:03 |
| jam | but then we just need a boolean/empty name field in the actual network collection | 08:03 |
| dimitern | jam, these are potentially all the networks, not machine-specific ones | 08:03 |
| dimitern | jam, provider-id can be anything, that's why we don't want it as part of the strictly defined juju network name | 08:04 |
| dimitern | (unless we transform it to contain only [a-z][a-z0-9-] | 08:04 |
| jam | dimitern: so I still go back to "what are the concrete use cases for having a pending-networks" and do we actually benefit from it. Yes we can put the data there, but we can't *use* it yet (because it doesn't have a name), and the use cases *I* can sort out should really go back to the provider on demand. | 08:05 |
| jam | Maybe so we have a list of "these are the other networks the machine has access to, but I don't actualyl know what to call them yet " ? | 08:05 |
| jam | IS it so when a machine starts we can use that list to filter out matches and ignore them? | 08:05 |
| jam | I'm not trying to fight you, I just haven't actually come up with a useful use case, if you have one, I'm happy to hear about it. | 08:06 |
| dimitern | jam, i understand your concern :) | 08:06 |
| dimitern | jam, i really wish fwereade could join us on this one | 08:06 |
| dimitern | jam, i'm starting to have doubts about the approach | 08:07 |
| jam | dimitern: so it seems better (to me) if we just had a table of known provider networks, and some of them are as-yet-unnamed | 08:08 |
| mattyw | morning | 08:14 |
| dimitern | mattyw, hey | 08:21 |
| dimitern | mattyw, something occurred to me yesterday about the --dry-run option of upgrade-juju | 08:21 |
| dimitern | mattyw, if you're not uploading the tools with --dry-run, you won't get the same results as without --dry-run, because different tools will be selected | 08:22 |
| mattyw | dimitern, sorry - I'm still waking up, what do you mean? | 08:23 |
| dimitern | mattyw, well, when you're about to upgrade, a check is performed first to make sure the environ agent-versions are "stable", then when --upload-tools is specified, the tools need to be uploaded to be considered for upgrade | 08:25 |
| dimitern | mattyw, without uploading the effective version picked for upgrade will differ with and without --dry-run | 08:26 |
| mattyw | dimitern, this only applies to --upload-tools? | 08:27 |
| dimitern | mattyw, i think only then we try to upload new tools, no? | 08:27 |
| dimitern | vladk, you've got a review on the networker PR | 08:28 |
| dimitern | vladk, you should add a kanban card for the IsVirtual removal, despite being a trivial change btw :) | 08:29 |
| dimitern | jam, right? | 08:29 |
| jam | dimitern: yes | 08:29 |
| jam | well, if it is follow up work, vs do this as a tweak and land it. | 08:30 |
| dimitern | jam, it's kinda a follow-up, but the whole PR is about that | 08:31 |
| mattyw | dimitern, we make a call to validate() before we print which I believe ensures we output the correct version in the not --upload-tools case | 08:31 |
| vladk | dimitern: thanks | 08:31 |
| jam | vladk: dimitern: so my statement is "if it is tweaking work that is going to take an afternoon and/or require another review" it is probably worthy of a kanban task. | 08:32 |
| jam | if it is "tweak this and land" then that probably isn't a new task | 08:32 |
| dimitern | mattyw, right, so I might be wrong then about it differing :) np, it was just a red light i needed to mention | 08:33 |
| mattyw | dimitern, thanks for pointing it out, this is an area of the code I'm new to so any pointers on things to watch out for is greatly appreciated | 08:34 |
| dimitern | jam, if by "tweak this and land" you refer to a review suggestion on an exiting PR, yes this should be part of the work associated with that PR's card in the first place, but i find it's best to have card-per-PR usually | 08:34 |
| mattyw | dimitern, do you think I should get someone else to do a review as well? | 08:35 |
| dimitern | mattyw, either fwereade or wallyworld should know a great deal wrt upgrades | 08:35 |
| mattyw | dimitern, ok great, I'll make sure I get their eyes on it as well | 08:36 |
| dimitern | mattyw, i did some stuff around it some time ago, but it seems things have changed since :) | 08:36 |
| fwereade | jam, dimitern: I'm totally cool with as-yet-unnamed networks -- but what are we going to use for the _id? | 08:39 |
| fwereade | jam, dimitern: if we make sure the _id isn't connected to the name then that's great, we'll be able to rename them | 08:40 |
| fwereade | jam, dimitern: I got the impression we weren't planning/expecting to rename networks, so keeping track of the possibilities separately seemed smarter to me | 08:41 |
| jam | fwereade: so the other question is what are we actually using the unnamed networks for? (why put them in our local model and have to keep them up to date) just to be consistent with the other ones that we do have names for? | 08:43 |
| dimitern | fwereade, the providerId is the _id in pendingnetworks | 08:44 |
| dimitern | fwereade, jam's point is we don't need to store unusable networks, which are likely to change, so instead we can fetch them when we call add-network --existing | 08:45 |
| fwereade | jam, dimitern may be in a position to correct me on this, but even if we're not *configuring* the networks on the machines I feel we still need to include them in the model so that when we *do* name the networks we don't have to rescan all the machines for whether they have access to these new networks | 08:45 |
| jam | fwereade: so I was trying to come up with those use cases, but it means we need to be careful about how we link them | 08:46 |
| jam | since we need a way to link them not-by-name | 08:46 |
| jam | otherwise aren't we scanning again? | 08:46 |
| dimitern | fwereade, ah, so here's the quirk - we get all networks, but no machines associated with them | 08:46 |
| fwereade | dimitern, re _id: hmmmmm, this has the hallmarks of the relation id troubles all over again | 08:47 |
| dimitern | fwereade, perhaps we should though | 08:47 |
| dimitern | fwereade, expand on that please? | 08:47 |
| fwereade | dimitern, take a look at the relation doc sometime | 08:48 |
| dimitern | fwereade, we have Key as _id and a separate int Id | 08:48 |
| fwereade | dimitern, it has Key (_id) which we use in tags, and Id (id) that we use in other places, and we dance back and forth over which to use in which place | 08:48 |
| dimitern | fwereade, right, but that's not true for networks - we always use the juju name, not providerId | 08:49 |
| dimitern | fwereade, except when talking to the provider - like in StartInstance | 08:49 |
| fwereade | dimitern, and pow, we introduce weird ugly races while watching | 08:49 |
| jam | dimitern: except if we wanted to link machines to networks that we don't-yet have names for | 08:49 |
| fwereade | dimitern, that's the main thing with relations | 08:50 |
| fwereade | dimitern, it is fucking stupid that we can't use the int ids when watching (say) service relations | 08:50 |
| tasdomas | is there any support for anything similar to prerequisite branches (in LP) in github? | 08:50 |
| fwereade | dimitern, but we literally can't do that | 08:50 |
| jam | tasdomas: not that we've sorted out | 08:50 |
| jam | Its something we want to bring up in a wider conversation (how to do the equivalent on git) | 08:50 |
| jam | there are a few ideas out there | 08:50 |
| jam | (rebase, create a PR to your prereq branch, etc) | 08:51 |
| fwereade | dimitern, because when we get a this-doc-went-away notification, we no longer have the id available to send down the wire, because it's in the doc that just went away | 08:51 |
| jam | fwereade: is it reasonably to go to an abstract "network id" that is just the identifier for the doc in the DB ? | 08:51 |
| dimitern | fwereade, ok, so should we drop the pending networks altogether? | 08:51 |
| dimitern | fwereade, instead, when we need to add them, we always give them a juju name for a given provider id | 08:52 |
| fwereade | dimitern, ...maybe? can we shelve this until the hangout, I'm kinda hoping that the relation-addresses stuff will be relatively quikc to get everyone one the same page for | 08:53 |
| * fwereade wants a ciggie | 08:53 | |
| dimitern | fwereade, sgtm | 08:53 |
| dimitern | mattyw, axw, fwereade, hangout? | 09:01 |
| axw | brt | 09:01 |
| jam | menno is gone, right? | 09:34 |
| jam | He linked a doc, but didn't share it with comments enablefd. | 09:34 |
| perrito666 | morning | 09:35 |
| voidspace | perrito666: morning | 09:35 |
| mattyw | fwereade, dimitern can we make it 15 minute break, just need to run a quick errand, will ping when I'm back | 09:54 |
| dimitern | mattyw, sure, we're there when you're back | 10:02 |
| voidspace | perrito666: so the main entry point to your new backup work is the BackUp function (which I think should be called Backup by the way) | 10:02 |
| voidspace | perrito666: this returns the backup filename and an sha filename | 10:03 |
| voidspace | perrito666: we're changing the backup api to be a synchronous one that returns the backup file | 10:03 |
| voidspace | perrito666: so we can't return the sha file *as well* | 10:03 |
| wallyworld | mgz: 1:1 time | 10:03 |
| voidspace | perrito666: maybe we could return the sha (instead of writing a file) and set it as a header on the response | 10:03 |
| perrito666 | voidspace: could be, I was writing into a file because we had an async api | 10:07 |
| perrito666 | I could just return the sha | 10:08 |
| voidspace | perrito666: yep, I assumed that was the case | 10:08 |
| voidspace | perrito666: I'm pretty sure natefinch has agreed to switch to a synchronous one | 10:08 |
| perrito666 | yup he did | 10:09 |
| perrito666 | ok, you can assume sha string is returning there instead of the filename, Ill change it | 10:09 |
| voidspace | perrito666: cool - thanks | 10:10 |
| voidspace | shame I can't use your branch as a dependent branch for my work :-) | 10:10 |
| perrito666 | you "can" but the workflow is not pretty | 10:11 |
| voidspace | perrito666: and your changes show up as a diff in my branch | 10:11 |
| perrito666 | ah, true | 10:11 |
| voidspace | perrito666: I can add your branch as a remote to my repo and then keep merging | 10:11 |
| perrito666 | voidspace: or I could have forked from you repo and then pull request to it instead of to upstream | 10:12 |
| perrito666 | but that is quite a pita | 10:12 |
| voidspace | perrito666: right, and then it's harder to just merge your work to trunk | 10:12 |
| natefinch | voidspace: I talked with fwereade. he suggested doing both synchronous and saving the backup to wallyworld's gridfs storage that goes across HA servers. | 10:13 |
| perrito666 | I think that is sort of the kernel way, people send patches to each maintainer who integrates the thing | 10:13 |
| voidspace | natefinch: so we have a storage story | 10:13 |
| natefinch | voidspace: I think we can do the synchronous approach first, and add in the save to gridfs later (should be trivial) | 10:13 |
| natefinch | voidspace: sounds like it | 10:13 |
| voidspace | natefinch: is that "done" or "in progress"? | 10:13 |
| voidspace | right | 10:13 |
| natefinch | voidspace: in progress | 10:13 |
| voidspace | sync is easy | 10:13 |
| voidspace | adding to storage (and adding async api) should also be easy | 10:14 |
| voidspace | so no problem | 10:14 |
| voidspace | natefinch: did you manage to have a look at what I've done so far? | 10:14 |
| voidspace | natefinch: should I be using errors.Errorf from juju/errors to be creating the errors? | 10:15 |
| voidspace | natefinch: also, should I send the sha of the backup file as a response header? | 10:15 |
| natefinch | voidspace: yes, I don't think so, yes | 10:15 |
| voidspace | heh, cool - thanks | 10:16 |
| natefinch | voidspace: I'll do a proper review, but overall it looks good | 10:16 |
| voidspace | natefinch: sorry to bombard you with questions | 10:16 |
| voidspace | sure, it's not "done" yet - so long as you're happy with the basic direction | 10:16 |
| natefinch | voidspace: I don't think we're quite ready to use the errors package. Last I heard it was getting tweaked but that was a long time ago and I haven't heard anything since. | 10:17 |
| natefinch | (where a long time is a couple weeks) | 10:17 |
| voidspace | ok, cool - there was a review comment on perrito666's branch suggesting using it | 10:17 |
| perrito666 | yup menn0 suggested I change fmt.Errorf for errors.Errorf or errors.Annotate/Annotatef | 10:19 |
| natefinch | perrito666: I'd hold off on that for now | 10:21 |
| perrito666 | we should implemente a EOR marker to know when someone ended a review :p I just wait until the mails stop for a moment but you never know if the other person is reading or just finished | 10:30 |
| perrito666 | :p | 10:30 |
| natefinch | That's a really good idea, actually. | 10:30 |
| natefinch | post it on the list | 10:31 |
| * perrito666 writes | 10:33 | |
| wallyworld | mgz: around? | 10:34 |
| voidspace | natefinch: ping | 10:37 |
| perrito666 | natefinch: sent, let the bikeshedding begin | 10:38 |
| natefinch | voidspace: what's up? | 10:39 |
| natefinch | perrito666: cool | 10:39 |
| mattyw | dimitern, fwereade, could we organise some time probably tomorrow to start break the open port stuff into tasks? | 10:45 |
| dimitern | mattyw, i'm available, we can arrange it | 10:46 |
| mattyw | dimitern, now? | 10:49 |
| dimitern | mattyw, we're just in our standup now, but it should be short | 10:49 |
| mattyw | dimitern, ok, just ping when you are ready | 10:50 |
| jam | fwereade: just finishing up, will be at team leads in 1m | 11:02 |
| natefinch | oops me too | 11:04 |
| jam | natefinch: :) | 11:04 |
| dimitern | mattyw, hey, just finished, but i'll need a 15m break as well (meetings for 2h+ straight so far - need to eat:) | 11:08 |
| mattyw | dimitern, no problem, I've only just managed to open vim myself, can we start later this afternoon? | 11:10 |
| dimitern | mattyw, sure, even better | 11:10 |
| dimitern | mattyw, if you can some up with a rough task list breakdown by then, as you see it, we'll polish it quickly | 11:11 |
| mattyw | dimitern, sounds good | 11:12 |
| voidspace | perrito666: to properly cleanup after a backup, do *I* need to delete the tempdir - or will just deleting the backup file do? | 11:29 |
| mattyw | has anyone seen these errors before? I get the same kind of failure in a number of tests http://paste.ubuntu.com/7633251/ | 11:32 |
| voidspace | mattyw: hmm... no | 11:39 |
| voidspace | mattyw: is that trunk? | 11:39 |
| voidspace | natefinch: is standup at "normal" time today? | 11:39 |
| wwitzel3 | natefinch: time for a hangout when you're done with the leads meeting? | 11:39 |
| natefinch | voidspace: yep | 11:40 |
| mattyw | voidspace, yep | 11:40 |
| wwitzel3 | voidspace: yes, it should be | 11:40 |
| mattyw | voidspace, yes it is trunk | 11:40 |
| voidspace | wwitzel3: morning! | 11:40 |
| wwitzel3 | voidspace: hi ya :) | 11:41 |
| mattyw | updating mongodb did the job | 11:52 |
| voidspace | client.call calls state.Call which calls conn.Call which delegates to conn.Go which creates a Call | 12:01 |
| wwitzel3 | obviously | 12:02 |
| voidspace | :-) | 12:02 |
| voidspace | and on that note | 12:03 |
| * voidspace lunches | 12:03 | |
| natefinch | wwitzel3: I have to help with the kids, can it wait anhour? | 12:05 |
| wwitzel3 | natefinch: yep, np | 12:06 |
| perrito666 | voidspace: I should delete it | 12:22 |
| perrito666 | I will | 12:22 |
| hazmat | why does juju download tools from the internet for every machine, instead of using a consistent version / tools already in the env | 12:24 |
| perrito666 | rogpeppe1: I notice the error on the test with the checksums after I pushed it I am doing something wrong with the sum bc it works | 12:26 |
| perrito666 | I mean the test passes everytime, which means I am doing something wrong | 12:27 |
| rogpeppe1 | perrito666: yes, you're doing a checksum on no bytes at all | 12:32 |
| rogpeppe1 | perrito666: (as i think i mentioned in another comment) | 12:32 |
| bodie_ | morning all | 12:44 |
| perrito666 | rogpeppe1: well making a pull request is like sending a letter, you only realize you missed something once you have done it | 12:45 |
| bodie_ | so, apparently juju is bootstrapping on my machine at startup? when I try to control it, I get this: ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: dial tcp 10.0.3.1:17070: connection refused | 12:57 |
| bodie_ | it tests fine and all that, I never use it outside of testing, so I had no idea I was running it, heh | 12:57 |
| bodie_ | anyway, I also can't kill the processes (even with kill -9, they just restart on a new pid) and I'm just not sure what to do with this | 12:58 |
| bodie_ | is this a known thing? | 12:58 |
| rogpeppe1 | perrito666: definitely! | 13:00 |
| rogpeppe1 | perrito666: that's why we have code reviews... | 13:00 |
| rogpeppe1 | perrito666: and i missed it the first time i looked through | 13:00 |
| perrito666 | rogpeppe1: I just noticed it after I pushed, then I noticed.. are we supposed to code review ourselves? because I could have totally added a few comments myself when looking at the diff | 13:01 |
| rogpeppe1 | perrito666: if i notice something after pushing and it's going to take a little while to fix, i'll sometimes comment on my own review | 13:02 |
| rogpeppe1 | perrito666: i think it can be useful | 13:02 |
| rogpeppe1 | perrito666: it's also possible (i think) to retract the PR if you want | 13:03 |
| rogpeppe1 | perrito666: although you probably don't want to do that after others have commented on it | 13:03 |
| perrito666 | rogpeppe1: well I see more value on people taking a look before I continue with it | 13:03 |
| perrito666 | or while I do | 13:03 |
| rogpeppe1 | perrito666: yeah, that too | 13:03 |
| rogpeppe1 | perrito666: i hope my comments were helpful | 13:04 |
| perrito666 | they where actually I read a few, but was waiting until you where done or the page gets a bit annoying with the notifications | 13:04 |
| rogpeppe1 | perrito666: most were trivial stuff - just usual conventions | 13:04 |
| rogpeppe1 | perrito666: yeah, i really miss rietveldt for that | 13:05 |
| rogpeppe1 | perrito666: i'm finished now, BTW | 13:05 |
| rogpeppe1 | perrito666: usually i'll try to finish the review with a general comment that's not attached to a line of code | 13:05 |
| perrito666 | I saw that | 13:06 |
| rogpeppe1 | perrito666: ha, just saw your juju-dev post | 13:06 |
| perrito666 | I will say this in favor of github, the diffs look really stylish | 13:09 |
| rogpeppe1 | perrito666: i find it difficult to see small changes, as nothing smaller than a line is highlighted | 13:11 |
| perrito666 | I did not say they where useful, just stylish | 13:12 |
| bodie_ | there we go | 13:16 |
| bodie_ | looks like my path was out of order | 13:16 |
| perrito666 | rogpeppe1: interesting, I was not aware you could do that with multiwriter | 13:28 |
| rogpeppe1 | perrito666: do what? | 13:28 |
| perrito666 | the way you included gzuo | 13:30 |
| perrito666 | gipz | 13:30 |
| perrito666 | aghh gzip | 13:30 |
| wallyworld_ | fwereade: heya, that txn branch has been updated. i don't think anyone else has looked at it. but i need to land it. all the tests pass. any chance you could take a look at my udpates to it sometime during your day? | 13:38 |
| rogpeppe1 | perrito666: that's not really a multiwriter thing, but the io.Writer interface is very nice and flexible | 13:39 |
| rogpeppe1 | perrito666: i particularly like the way that it's easy to use conditional defers | 13:40 |
| === Ursinha is now known as Ursinha-afk | ||
| natefinch | wwitzel3: is 15 minutes enough time, or do you want to wait until after the standup? | 13:45 |
| fwereade | wallyworld_, sure, will do | 13:45 |
| wwitzel3 | natefinch: that's enough | 13:45 |
| wallyworld_ | awesome thanks | 13:45 |
| === Ursinha-afk is now known as Ursinha | ||
| natefinch | ericsnow: standup? | 14:01 |
| voidspace | My connection is back - but I have 344kbits downstream! | 14:09 |
| voidspace | natefinch: so not enough to join the hangup I don't think | 14:09 |
| voidspace | I'm in, but terrible quality | 14:09 |
| sinzui | jamespage, can you look at bug 1329256? I don't know if a dep like distro-info is missing | 14:16 |
| _mup_ | Bug #1329256: juju-core on openstack failing with trusty <juju-core:New> <https://launchpad.net/bugs/1329256> | 14:16 |
| wwitzel3 | fwereade: so calling StartSync on only the presence pinger, doesn't work | 14:28 |
| fwereade | wwitzel3, ha | 14:28 |
| fwereade | wwitzel3, now that is interesting :/ | 14:28 |
| wwitzel3 | fwereade: yeah :/ | 14:28 |
| fwereade | wwitzel3, Sync on the presence pinger? | 14:29 |
| natefinch | fwereade:in a standup, almost done | 14:29 |
| wwitzel3 | fwereade: Sync instead of StartSync did the trick | 14:31 |
| fwereade | wwitzel3, awesome | 14:31 |
| wwitzel3 | fwereade: well I addressed all the implentation comments from your review at this point, just been futtzing around with testing it all. | 14:33 |
| fwereade | wwitzel3, great | 14:33 |
| wwitzel3 | fwereade: thanks again for the hand holding :) | 14:33 |
| fwereade | wwitzel3, a pleasure, thank you for doing all the actual work ;) | 14:33 |
| bodie_ | fwereade, what's your handle on github? | 14:40 |
| bodie_ | I' | 14:40 |
| bodie_ | I'll take an answer to that from anyone :P | 14:40 |
| jcw4 | "fwereade" | 14:41 |
| natefinch | bodie_: https://github.com/orgs/juju/members | 14:41 |
| bodie_ | hmm, it's not offering a completion for fwereade, but it is for natefinch | 14:42 |
| natefinch | wwitzel3: you need to set yourself to public here: https://github.com/orgs/juju/members?page=2 | 14:42 |
| fwereade | bodie_, heyhey, I'm pretty sure I'm fwereade everywhere, and I'm sure I set myself public | 14:42 |
| jcw4 | I thought it only offered completion for folks already on the thread | 14:42 |
| fwereade | cmars, reviewed, coming along nicely | 14:43 |
| fwereade | cmars, let me know if anything's unclear :) | 14:43 |
| wwitzel3 | natefinch: done, was that sent out in an email? I must of missed it :/ | 14:43 |
| cmars | fwereade, thanks for the feedback | 14:43 |
| bodie_ | jcw4, I think it's org-wide | 14:44 |
| bodie_ | could be mistaken about that | 14:44 |
| === revagomes_ is now known as revagomes | ||
| natefinch | wwitzel3: not sure | 14:46 |
| fwereade | cmars, btw, heads-up re: https://github.com/juju/juju/pull/50 which I expect to land soon -- will move the transaction hooks stuff to a different package, should be a trivial merge but will affect you | 14:46 |
| * fwereade also issues a general call for help re https://github.com/juju/juju/pull/50 -- I'll be going through it with all the focus I can muster, but I'd really like it if someone else also audited the txn changes | 14:47 | |
| fwereade | natefinch, since you seem to be on call: ^^ | 14:48 |
| fwereade | natefinch, and I'm well aware you're not super-familiar with state so feel free to talk to me about it | 14:49 |
| natefinch | fwereade: I'm on call? | 14:50 |
| jcw4 | what does this idiom mean: txnRunner.testHooks = make(chan([]TestHook),1); txnRunner.testHooks <- nil; | 14:53 |
| jcw4 | specifically.. the last statement? | 14:53 |
| jcw4 | context ^^^: its in NewRunner() in state/txn/txn.go | 14:56 |
| voidspace | rogpeppe1: ping | 14:57 |
| jcw4 | oh, I see, I think it's filling the channel with nil so that reading it won't block if there are no TestHooks | 14:59 |
| jcw4 | (filling the channel buffer) | 15:00 |
| bodie_ | https://github.com/juju/charm/pull/4 | 15:01 |
| bodie_ | should be shipshape | 15:01 |
| bodie_ | oops, failing a test | 15:01 |
| dimitern | mattyw, the call is still on, right? | 15:04 |
| mattyw | dimitern, sorry - can we do it tomorrow instead? | 15:04 |
| dimitern | mattyw, even better :) np | 15:04 |
| mattyw | dimitern, I've not managed to get anything down yet | 15:05 |
| mattyw | dimitern, I'll set something up for the morning before we get too busy | 15:05 |
| bodie_ | there we go | 15:05 |
| voidspace | natefinch: ping | 15:07 |
| dimitern | mattyw, ok, but please after 7 UTC :) | 15:07 |
| mattyw | dimitern, as far as I know nothing exists before 7 UTC | 15:08 |
| fwereade | jcw4, exactly right, yes | 15:09 |
| jcw4 | fwereade: thanks... PR 50 is heavy going, but looks great to me so far | 15:09 |
| jcw4 | basically a nice abstraction of the transaction retry logic I'd implemented under your direction before | 15:10 |
| fwereade | jcw4, yeah, it's making me really happy :) | 15:11 |
| dimitern | mattyw, :D | 15:11 |
| fwereade | jcw4, but it is indeed heavy going | 15:11 |
| fwereade | jcw4, a lot to check | 15:11 |
| jcw4 | I'll at least try to read the new code and the resulting changes to code I wrote before | 15:13 |
| rogpeppe1 | voidspace: pong | 15:13 |
| voidspace | rogpeppe1: hey, got a minute? | 15:13 |
| rogpeppe1 | voidspace: sure | 15:13 |
| * perrito666 just tried to grep on a piece of paper... my brain is jello | 15:14 | |
| rogpeppe1 | perrito666: lol | 15:23 |
| rogpeppe1 | fwereade: do you know if we are able to mandate go 1.2 ? | 15:23 |
| ericsnow | perrito666: wishful thinking :) | 15:23 |
| voidspace | natefinch: unping (just in case) | 15:23 |
| mgz | rogpeppe1: we need to for trunk now | 15:23 |
| rogpeppe1 | mgz: cool | 15:24 |
| voidspace | great | 15:24 |
| rogpeppe1 | that means we can get rid of the NonValidatingHTTPClient security hole | 15:24 |
| jcw4 | if we already import github.com/juju/errors should we always deprecate fmt.Errorf in favor of errors.Errorf? | 15:25 |
| fwereade | rogpeppe1, I'm not sure... I think that we should as soon as we can, but I can't remember what was stopping us | 15:25 |
| mgz | fwereade: largely toolchain things I believe, which are now resolved | 15:25 |
| voidspace | state/api/client.go | 15:25 |
| voidspace | / Due to issues with go 1.1.2, fixed later, we cannot use a | 15:26 |
| voidspace | // regular TLS client with the CACert here, because we get "x509: | 15:26 |
| voidspace | // cannot validate certificate for 127.0.0.1 because it doesn't | 15:26 |
| voidspace | // contain any IP SANs". Once we use a later go version, this | 15:26 |
| voidspace | // should be changed to connect to the API server with a regular | 15:26 |
| voidspace | // HTTP+TLS enabled client, using the CACert (possily cached, like | 15:26 |
| voidspace | // the tag and password) passed in api.Open()'s info argument. | 15:26 |
| voidspace | r | 15:26 |
| bodie_ | urk | 15:26 |
| rogpeppe1 | voidspace: i suggest that you write a method on Client that returns an http client suitable for connecting to the API. it would have only a single allowed root cert (the CACert) | 15:27 |
| voidspace | rogpeppe1: ok, I'll look at that | 15:28 |
| voidspace | rogpeppe1: I may request some assistance on getting the certs right | 15:28 |
| rogpeppe1 | voidspace: take a look at the setUpWebsocket function for inspiration | 15:29 |
| voidspace | rogpeppe1: cool, thanks | 15:29 |
| natefinch | fwereade: the problem with 1.2 is getting it into precise | 15:29 |
| natefinch | fwereade: although if we wait a week or two maybe we can skip right to 1.3 | 15:29 |
| fwereade | natefinch, that'd reduce the effort ;p | 15:30 |
| natefinch | fwereade: btw, I think this says I'm not the on call reviewer? Or is the spreadsheet not what we're going by? https://docs.google.com/a/canonical.com/spreadsheets/d/1iQLLOWrjzxddm5VhYWYi0-2k3xI6wTMlpkvnVNJCYGY/edit#gid=0 | 15:32 |
| jcw4 | sounds like fwereade was trying to pass the buck natefinch | 15:32 |
| voidspace | natefinch: just FYI, I finally did my vegas expenses... | 15:34 |
| fwereade | natefinch, sorry! | 15:34 |
| fwereade | natefinch, you're absolutely right, I think I had it open from a few days before or something :/ | 15:35 |
| natefinch | voidspace: cool, I'll check them | 15:45 |
| rogpeppe1 | anyone know why CmdSuite.TestHttpTransport is there? | 15:51 |
| rogpeppe1 | (in the cmd package) | 15:52 |
| rogpeppe1 | it doesn't look like it's testing anything to do with the cmd package | 15:52 |
| perrito666 | natefinch: | 15:53 |
| perrito666 | unping | 15:54 |
| natefinch | perrito666: howdyt | 16:05 |
| alexisb | natefinch, be there soon | 16:06 |
| perrito666 | natefinch: voidspace and I had a doubt but we end up peer solving it | 16:06 |
| natefinch | alexisb: me too | 16:06 |
| natefinch | perrito666: achievement unlocked! | 16:06 |
| voidspace | heh | 16:08 |
| mgz | sinzui: what's our solution for a newer go version on precise? | 16:09 |
| sinzui | mgz: two phases | 16:10 |
| sinzui | mgz, 1. I backported trusty's 1.2 to saucy and precise last month and released package built on it. CI adds the ~juju/experimental PPA to saucy and trusty testers/builders. CI and Users don't see issues with 1.2 | 16:11 |
| sinzui | mgz, 2. The server team, Robbie or James will backport that same package to ctools for precise | 16:12 |
| mgz | sinzui: okay, have we bugged them about that yet? | 16:12 |
| sinzui | mgz, saucy is in a grey are of not getting the needed golang from Ubuntu. | 16:12 |
| sinzui | mgz, an email was sent without response. They are honestly working with 1.18.4 and ubuntu. That is their top priority | 16:13 |
| mgz | k | 16:13 |
| mgz | means we can't bot on precise for now, right? | 16:14 |
| sinzui | mgz, ?? | 16:16 |
| mgz | sinzui: I can't set up a precise machine which *builds* juju easily on precise | 16:17 |
| sinzui | mgz, you mean Ubuntu cannot build 1.19.4+ on precise or saucy without the golang update? | 16:17 |
| mgz | yup | 16:17 |
| sinzui | mgz, good news, golang is queued for ctools | 16:19 |
| sinzui | https://launchpad.net/~ubuntu-cloud-archive/+archive/cloud-tools-next | 16:19 |
| mgz | ace | 16:20 |
| voidspace | I have to EOD a bit early | 16:24 |
| voidspace | going to London to meetup with some ex-colleagues | 16:24 |
| voidspace | I'll try and persuade them that they want to work on juju | 16:24 |
| voidspace | see you all tomorrow folks | 16:24 |
| sinzui | mgz, saucy has 35 days left, I am confident that Ubuntu will delay backport or juju 1.20.0 to saucy's eol to avoid the golang issue | 16:25 |
| === psivaa is now known as psivaa-afk | ||
| rogpeppe1 | if anyone's around and willing, there's a PR here that factors cmd out of core. i haven't updated core to use it yet. https://github.com/juju/cmd/pull/1 | 17:40 |
| jcw4 | rogpeppe1: don't know if you want more than an LGTM from me :) Looks pretty mechanical except for the Version change and the nice DefaultConfig refactor | 17:53 |
| jcw4 | I wanted to comment but couldn't find anything to comment on but +1 :) | 17:54 |
| natefinch | rogpeppe1: is that the right license? I thought we were using canonical's special static-linking-ok LGPL | 17:56 |
| perrito666 | we should start adding "rant git" as part of our agendas :p | 18:33 |
| bodie_ | git rant -vvv | 18:36 |
| jcastro | https://bugs.launchpad.net/juju-core/+bug/1329425 | 18:44 |
| _mup_ | Bug #1329425: Fatal out of memory error when bootstrapping on Azure <juju-core:New> <https://launchpad.net/bugs/1329425> | 18:44 |
| jcastro | anyone see this before? | 18:44 |
| natefinch | jcastro: nope... I'd be interested to know if it always fails at approximately the same spot, or if it looks random | 19:06 |
| jcastro | found the issue | 19:06 |
| natefinch | oh yeah? | 19:06 |
| jcastro | sinzui figured it out, I was specifying the .cer file, not the .pem | 19:06 |
| jcastro | I am making a note for the docs now | 19:06 |
| sinzui | I just updated to bug. | 19:07 |
| natefinch | jcastro: oh yeah... the whole .cer .pem BS for azure. Feh. | 19:11 |
| jcastro | is it possible to tell which one is which so we can give a smarter error? | 19:12 |
| jcastro | "Wrong certificate, idiot" would be nicer I think. | 19:12 |
| natefinch | jcastro: they're vastly different formats. It should be easy to differentiate | 19:13 |
| jcastro | natefinch, also: https://bugs.launchpad.net/juju-quickstart/+bug/1329449 | 19:25 |
| _mup_ | Bug #1329449: Don't allow a .cer file to be used in Azure <juju-quickstart:New> <https://launchpad.net/bugs/1329449> | 19:25 |
| jcastro | that outta help too | 19:25 |
| natefinch | it's very interesting that it caused an out of memory error... I wonder how that happened | 19:26 |
| natefinch | neither cert is very large, but that error was in the YAML code, I wonder if it's a bug in yaml when trying to write binary to a yaml file or something | 19:27 |
| === BradCrittenden is now known as bac | ||
| sebas5384 | Feature request: https://github.com/juju/juju/issues/87 | 19:56 |
| leftyfb | can someone help me with this issue? https://pastebin.canonical.com/111624/ | 20:02 |
| natefinch | leftyfb: can you post the contents of /home/leftyfb/.juju/local/cloud-init-output.log ? There's probably more useful information in there | 20:04 |
| leftyfb | https://pastebin.canonical.com/111626/ | 20:04 |
| perrito666 | can I do an gc.Assert() that outputs a custom error if the assertion fails? | 20:06 |
| perrito666 | in a test | 20:06 |
| natefinch | perrito666: no, you want gc.Log to output custom stuff | 20:07 |
| perrito666 | ah great | 20:07 |
| natefinch | leftyfb: hmm... less than useful | 20:07 |
| leftyfb | 1329480 | 20:07 |
| leftyfb | https://bugs.launchpad.net/juju-core/+bug/1329480 | 20:07 |
| _mup_ | Bug #1329480: ERROR state/api: websocket.Dial wss://10.0.2.1:17070/: dial tcp 10.0.2.1:17070: connection refused <juju-core:New> <https://launchpad.net/bugs/1329480> | 20:07 |
| natefinch | leftyfb: hmm... weird, why is it running 1.18.1 .... I think 1.18.4 is the most recent stable | 20:09 |
| natefinch | sinzui: ^^ | 20:09 |
| leftyfb | natefinch: I'm running trusty and installed from main repo's | 20:09 |
| leftyfb | natefinch: I did have the stable ppa before following instructions from ubuntu.com, but ran into this issue and decided to limit variables | 20:10 |
| natefinch | oh ok | 20:10 |
| natefinch | 1.18.4 is probably a much better bet. We fixed a bunch of bugs in those .3 | 20:10 |
| leftyfb | ok, I can install from ppa, though I was getting the same or similar issues | 20:11 |
| leftyfb | btw, I go through this process when starting over: https://pastebin.canonical.com/111628/ | 20:11 |
| natefinch | leftyfb: killing any lxc related processes is often helpful... and... I hate to say it, but rebooting often helps with the local provider when it gets wedged | 20:15 |
| leftyfb | natefinch: I do that as well | 20:15 |
| leftyfb | natefinch: for some reason reinstalling lxc doesn't start the dnsmasq process properly.... can only seem to get it going after a reboot | 20:15 |
| leftyfb | tried sudo service lxc-net start ... says it starts but it doesn't | 20:16 |
| bodie_ | https://github.com/juju/charm/pull/4 | 20:17 |
| leftyfb | bodie_: was that for me? | 20:20 |
| bodie_ | sorry, no | 20:21 |
| bodie_ | just could use a review on that when someone gets a chance :) | 20:21 |
| leftyfb | natefinch: https://pastebin.canonical.com/111630/ after installing 1.18.4 from ppa:juju/stable and trying to bootstrap | 20:32 |
| natefinch | leftyfb: that all looks good. Is it working or? | 20:32 |
| leftyfb | negative | 20:33 |
| leftyfb | #leftyfb@blanchard[0]:~$ juju status | 20:33 |
| leftyfb | ERROR state/api: websocket.Dial wss://10.0.2.1:17070/: dial tcp 10.0.2.1:17070: connection refused | 20:33 |
| natefinch | leftyfb: can you paste /home/leftyfb/.juju/local/cloud-init-output.log again? | 20:33 |
| leftyfb | natefinch: that's what the pastebin above is | 20:34 |
| natefinch | oh right... uh, huh | 20:37 |
| thumper | morning | 20:38 |
| natefinch | morning thumper | 20:39 |
| thumper | hi natefinch | 20:40 |
| wwitzel3 | morning thumper | 20:40 |
| thumper | hi wwitzel3 | 20:40 |
| thumper | I hate friday mornings | 20:41 |
| thumper | so tired | 20:41 |
| wwitzel3 | you could always wake up later? | 20:41 |
| wwitzel3 | :D | 20:41 |
| === vladk is now known as vladk|offline | ||
| leftyfb | natefinch: does this help at all: | 20:51 |
| leftyfb | 2014-06-12 20:30:10 ERROR juju.cmd supercommand.go:305 symlink /home/leftyfb/.juju/local/tools/machine-0/jujud /usr/local/bin/juju-run: no such file or directory | 20:51 |
| leftyfb | 2014-06-12 20:30:10 INFO juju.cmd supercommand.go:302 running juju-1.18.4.1-trusty-amd64 [gc] | 20:51 |
| leftyfb | /home/leftyfb/.juju/local/tools/machine-0/jujud does exit | 20:52 |
| leftyfb | /usr/local/bin/juju-run does not exist | 20:52 |
| natefinch | weird.... it sounds like /home/leftyfb/.juju/local/tools/machine-0/jujud didn't exist | 20:54 |
| leftyfb | it does | 20:54 |
| leftyfb | I just created the link and trying to bootstrap again | 20:55 |
| natefinch | maybe it didn't exist when that line was running | 20:55 |
| leftyfb | hm | 20:56 |
| leftyfb | that was it | 20:56 |
| leftyfb | I can get status now | 20:56 |
| natefinch | thumper: any idea why leftyfb's jujud wouldn't have existed when we were trying to make the juju-run symlink? | 20:56 |
| leftyfb | so after all my purging of packages and deleting of files, rebooting and reinstalling, juju isn't creating that link | 20:57 |
| leftyfb | you know what didn't exist? | 20:57 |
| leftyfb | /usr/local/bin | 20:57 |
| leftyfb | I had to create that | 20:57 |
| natefinch | heh | 20:59 |
| natefinch | interesting | 20:59 |
| natefinch | can you create a bug for that? | 21:00 |
| natefinch | I gotta run | 21:00 |
| waigani | fwereade: are you still up? | 21:14 |
| waigani | thumper or fwereade: could one of you review this please: https://github.com/juju/juju/pull/22 | 21:18 |
| thumper | waigani: yeah, in the middle of a thought stream right now, will look soon | 21:18 |
| menn0 | perrito666: ping? | 21:18 |
| perrito666 | menn0: oibg | 21:18 |
| perrito666 | pong | 21:18 |
| menn0 | :) | 21:18 |
| perrito666 | sorry I am working in a different kb today | 21:19 |
| menn0 | off by one on your right hand :) | 21:19 |
| menn0 | perrito666: I just wanted to confirm a few things with you regarding the upcoming backup system | 21:19 |
| perrito666 | menn0: shoot | 21:20 |
| waigani | thumper: thanks, I've got a mountain of email to get through plus juju info so no rush | 21:20 |
| menn0 | perrito666: did I get it right that backups will be stored server side with the juju client growing some commands to list, download and remove them? | 21:21 |
| perrito666 | menn0: while you where sleeping we changed that a bit | 21:21 |
| perrito666 | and by a bit I mean completely | 21:21 |
| menn0 | ok :) | 21:21 |
| perrito666 | menn0: now backup is no longer async | 21:22 |
| menn0 | perrito666: so backups are downloaded to the client immediately without the option of storage server side? | 21:23 |
| perrito666 | menn0: that is right | 21:23 |
| perrito666 | altough you should be able to use the backup function which is rather simple | 21:24 |
| perrito666 | and that will put a backup wherever you ask it to | 21:24 |
| menn0 | perrito666: ok that's good to know | 21:25 |
| menn0 | it's a pity that things have changed because the previous proposal worked rather nicely with schema migrations but I can work with the new approach too | 21:26 |
| * menn0 goes to update the schema migrations design document | 21:26 | |
| menn0 | perrito666: at a guess, how far away is the backup functionality from landing? | 21:26 |
| perrito666 | menn0: well I am finishing the tests to re-propose it | 21:27 |
| menn0 | perrito666: that's the core backup piece right? The client and API changes are still to come? | 21:28 |
| menn0 | (although I probably don't care much about those now...) | 21:28 |
| perrito666 | yes, that you should ping voidspace for | 21:28 |
| menn0 | perrito666: thanks | 21:38 |
| menn0 | review please: https://github.com/juju/juju/pull/84 (thumper perhaps?) | 21:38 |
| perrito666 | menn0: sorry if you get a ton of spam, I just commented on the review you did.. a lot | 22:21 |
| wallyworld_ | fwereade: not sure if you're still awake/coherent - i've addressed all the txn package changes. one main difference remains - i kept the various Refresh() calls to preserve existing behaviour. if that's ok with you, i'll look to land | 22:30 |
| menn0 | perrito666: no problems. looking now. | 22:37 |
| * menn0 misses reitveld | 22:38 | |
| perrito666 | menn0: let me know when you go again to sleep so I ca change backup's arch again | 22:50 |
| perrito666 | :p | 22:50 |
| menn0 | perrito666: umm sure ;-) | 22:50 |
| * perrito666 makes backup now require port knocking | 22:50 | |
| menn0 | perrito666: screw you ;-p | 22:58 |
| perrito666 | lol | 22:58 |
| menn0 | perrito666: review done. just tiny things. you probably want to wait to here back from the others | 22:58 |
| perrito666 | menn0: yeah I am EOD | 22:59 |
| menn0 | perrito666: cool, TTYL | 22:59 |
| perrito666 | but since I have no life I stay on irc ;p | 22:59 |
| waigani | thumper: NewUserManagerAPI already only allows client connections to use it: line 41: if !authorizer.AuthClient() | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!