[00:29] https://github.com/juju/charm/pull/4 (fwereade, mgz, rogpeppe1) [00:29] (and jcw4) [00:31] hi bigjools [01:02] 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] sinzui: cool, thank you [01:09] thumper: you about? [01:16] sinzui: doesn't build-revision need it too? [01:16] sinzui: seems that juju-ci.vapour.ws still has 1.1.2, and that's where build-revision runs right? [01:18] axw no, really [01:19] axw we make a tarball in that step. the tarball only has source code [01:19] waigani: am now [01:19] sinzui: so should I try to land that branch again ? [01:20] axw, the build step does give some confidence that it works, but the output is ignored [01:20] thumper: just wondering about the info cmd [01:20] thumper: did you catch up with fwereade about it? [01:21] 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] axw, that is how Ubuntu and Lp does, so we do it too [01:22] sinzui: except it's "set -e", so the "go build" fails the whole script if it fails? [01:22] mmk [01:23] oh, well I will remove that now. it is vestigial [01:23] waigani: yeah... [01:23] waigani: we should chat, let me get some food first [01:24] sinzui: I think it's nice to have, but if we could drop it for now that'd be great [01:26] axw, the build step is gone [01:26] thanks! [01:26] davecheney: ^^ try your merge again [01:27] axw: ok [01:27] thanks [01:28] axw: morning. will you have time today to look at bug 1240146 ? after the current az stuff is landed? [01:29] wallyworld: sure [01:29] axw: thanks :-) azure provider performance and bugs is becoming a hot topic [01:31] wallyworld: ehm, I think I already did this a while ago :) [01:31] will look deeper, but I'm pretty sure this is resolved [01:31] axw: i wondered about that, i figured there must be something new that we didn't know about [01:32] i didn't look too closely, just added the card [01:32] wallyworld: I believe I added this when I did the availability set revamp [01:32] that was post 1.18 right? [01:32] anyway, will confirm [01:32] yes [01:32] 1.19 [01:32] so it must just be people on 1.18 complaining [01:32] and 1.20 is due out next week [01:33] it is? okay, I better fix that local-provider HA thing then [01:33] that's the plan - release 1.19.4 this week and turn into 1.20 if all good [01:34] the current 1.19.4 milestone has no show stopper bugs that are recorded against it [01:34] if there's somthing to do, the bug needs to be added to the milestone [01:34] I will add it [01:34] ta [01:35] davecheney: what's that error? went too far and got 1.3 changes? [01:35] oh, it's getting vet [01:36] groan [01:47] sigh, I really need to set up my dev system in a vagrant box [01:48] 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] anyone know if that should be relatively painless? [01:48] I'm assuming more on the relatively painful end of the spectrum [01:49] davecheney: I've updated the build config to checkout go.tools as at the 1.2 release, retrying your build now [01:49] bodie_, I run in lxc [01:49] sinzui, did you see the lxc cluster scheduler google open-sourced today? [01:50] hmmmm... so you run mongo itself in lxc if you need your own version? I've never played w/ lxc much [01:50] bodie_, I haven't [01:51] bodie_, give me a moment to paste bin what I think is my last container and setup [01:53] sinzui, https://github.com/GoogleCloudPlatform/kubernetes [01:54] bodie_, http://pastebin.ubuntu.com/7631475/ [01:55] you could just use the local provider, too [01:55] that's awesome, thanks :) [01:55] true [01:56] 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] thumper: ready when you are [01:57] waigani: I have a scheduled call with wallyworld shortly, how about after that? [01:57] thumper: okay, I have to do school run at 3 [02:06] bodie_, I think I installed this the first time I used the container because it was missing something that made apps misbehave [02:06] sudo apt-get install language-pack-en avahi-daemon build-essential python-dbus [02:06] 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] I don't think I want to do that [02:06] do I? [02:06] you do if you want to use the local provider [02:06] isn't that part of our repo? [02:07] juju-local juse installs prereq packages: mongo, rsyslog, etc. [02:07] just* [02:07] I see [02:07] it also wants to install juju-core [02:08] I just don't want to override my $GOPATH/bin juju stuff [02:08] you'll have to ensure that $GOPATH/bin comes before /usr/bin in $PATH [02:08] fair enough, that makes sense [02:12] hurrrngh [02:13] * axw has flashbacks to building The Build Guy at his previous job [02:13] being [02:14] heh [02:14] sorry *pat pat* [03:05] waigani: let me know when you are back from the school run [03:05] waigani: and we can talk [03:15] https://github.com/juju/juju/pull/81 for anyone, simple, found the code lying around... [03:52] 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

[03:53] ta [03:56] wwitzel3: ta [03:56] thumper: np [03:58] * thumper goes to make coffee [04:10] thumper, menn0: ModifyUser - all tests pass. [04:10] waigani: we just both wrote about the same email at the same time [04:11] great minds... [04:14] 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:15] thumper: also, did you want to talk about juju info? [04:28] * thumper looks [04:29] * thumper wonders what the hell he was thinking about... [04:29] I'm sure there was something... [04:31] waigani: when you said you ran all the tests, did you mean *ALL* or just the apiserver tests? [04:31] lol thumper all [04:31] * thumper pulls a face [04:32] thumper: some failed with panics, reran those and they passed [04:32] I'm sure the api client user manager tests would fail at least one [04:34] $ cd state/apiserver/usermanager/ [04:34] .../state/apiserver/usermanager$ nolog [04:34] OK: 10 passed [04:34] PASS [04:34] ok github.com/juju/juju/state/apiserver/usermanager 2.377s [04:34] /state/apiserver/usermanager$ [04:34] thumper: ^ [04:34] * thumper checks [04:35] hmm... perhaps the default json serialisation is to lower case the names... [04:35] that is the only thing that makes sense there... [04:36] bit I seem to recall logs where that wasn't the case... [04:36] although that may have been the deserialized json [04:36] although... [04:36] thumper: I don't follow, where are you looking? [04:36] based on what menn0 said, and that this wasn't hooked up before... [04:36] we should just make the api clean [04:37] which means I should delete my backwards compatability bit [04:37] because that's dumb [04:38] thumper: good point [04:38] okay, actually, do we even need to keep Tag then? [04:38] I wish I'd remember that when you made the change [04:38] heh [04:39] waigani: I hold to my thought that the two structures are for different things [04:39] and we should reuse them because they are "kinda similar" [04:39] that way lies pain as code moves on [04:39] we never pass back password [04:39] for example [04:39] thumper: did you see fwereade's comment on this? [04:39] * thumper sighs [04:39] no [04:39] * thumper looks [04:40] thumper: If I understand him correctly, he is arguing the opposite [04:40] waigani: there are a lot of fwereade's comments hidden due to changing code. [04:40] * thumper looks at the email trail [04:41] thumper: comment below [04:41] 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] 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] yeah [04:41] reading and thinking [04:41] I think we do want to split them [04:42] because we are about to return "date created, creator, and last connection" [04:42] okay, and the justification? [04:42] these are not fields you send up [04:42] make sense? [04:42] right [04:42] yep [04:42] so... [04:42] ModifyUser should stay distinct from the UserInfo struct [04:43] ModifyUser is for add/modify user client -> server instructions [04:43] okay, should we remove Tag from it now? [04:43] UserInfo is for server-> client info [04:43] well... [04:43] that is an interesting question... [04:43] yep, that is clear [04:44] when we create a user, we are specifying a username for them [04:44] this clearly isn't a tag [04:44] however when we modify them, we may well want to define them with a tag (even though I think it is dumb) [04:44] as long as it is a real tag [04:44] bah humbug [04:44] in which case we should remove the deprecated comment [04:45] agreed [04:45] and the behaviour should change... [04:45] but don't do it all at ocne [04:45] we have never ending feature creep [04:45] we want small defined bits of work [04:45] with as little extraneous bits of change as possible [04:45] agreed [04:46] so it should change, but not in this branch [04:46] just remove the comment? and add a todo? [04:46] no, don't touch it [04:46] okay [04:46] I'll remove the annotation though [04:46] actually what am i saying [04:47] no, it is a different struct [04:47] it will be like it was before, no annotations [04:47] right [04:47] yep [04:47] just add the new UserInfo [04:47] yep [04:47] although add in the extra fields that landed yesterday [04:47] that way the struct is obviously different [04:47] to the Modify User one [04:47] right, cool new fields :) [04:48] you may also want to update your tests to create the users with the factory [04:48] oh nice :) [04:48] is there an example to look at? [04:48] or at least what package is it? [04:48] yes [04:48] suite even? [04:48] and yes [04:49] testing/factory [04:49] cool, I'll get onto it [04:49] ok [04:58] 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

[04:58] will do [04:58] ta [05:12] * thumper back later tonight for team meeting [05:13] team leads that is [05:35] morning [05:43] any reviewers wanna have a look ? https://github.com/juju/juju/pull/78 [06:05] jam, fwereade, TheMue, vladk|offline, ^^^ === vladk|offline is now known as vladk [07:12] 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:22] 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:38] fwereade, ping [07:40] anyone know a decent way to easily fetch someone's pull request branch locally? [07:41] rogpeppe1, it's best to add another upstream first [07:41] dimitern: that would mean i'd need an upstream for everyone that sends a PR [07:41] dimitern: which seems a bit like overkill [07:42] rogpeppe1, only if you need to collaborate on another guy's branches in his fork [07:42] 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] dimitern: i don't want to do that [07:42] dimitern: i just want to fetch it and maybe run the tests [07:43] morning all [07:43] rogpeppe1, if you're using github/hub, it's as easy as hub clone user/repo dir [07:43] voidspace: hiya [07:43] o/ [07:43] voidspace, yo! [07:43] 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:44] rogpeppe1: https://help.github.com/articles/merging-a-pull-request ? [07:44] rogpeppe1, then git fetch [07:44] git remote add mislav git://github.com/mislav/REPO.git [07:44] git fetch mislav [07:44] rogpeppe1, ^^ that's what i'd do [07:44] dimitern: unfortunately github doesn't actually make the name of the remote repo clear [07:45] rogpeppe1, naming is always user/repo [07:45] dimitern: yeah, but the "repo" might be different if the user has renamed it [07:45] rogpeppe1, what?! :) [07:46] rogpeppe1, why is that a concern if you're fetching something now? [07:46] dimitern: like my fork of github.com/juju/utils is github.com/rogpeppe/juju-utils [07:47] dimitern: ok, my specific example is this: https://github.com/juju/charm/pull/4/commits [07:47] rogpeppe1, so? you can name your fork however you wish [07:47] (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] dimitern: where can i see the repo that the pull request is coming from? [07:48] 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] binary132/charm [07:48] forked from juju/charm [07:49] dimitern: ah, i didn't know those hex commit numbers were links [07:49] dimitern: thanks [07:49] jam, we need to know what networks are there from state [07:49] rogpeppe1, np :) [07:49] 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] 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:50] jam, 2) it allows us to watch for changes from one place over pendingnetworks and update them from another [07:50] rogpeppe1, nice! [07:51] jam, the idea is, once we have them to implement add-network --existing ... or even list-networks --existing [07:51] dimitern: sure, but both of those use cases should arguably go query the provider directly rather than using possibly stale data from state [07:52] jam, so why store addresses when we can always get them from the provider when we need to? [07:52] :) [07:52] dimitern: frequency of use [07:52] dimitern: I don't see us using "unknown" networks frequently [07:53] 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] jam, we will use them to detect the default private/public networks [07:53] dimitern: but aren't those public and private networks in the model, and not pending networks? [07:53] jam, they will be promoted to be the defaults [07:54] jam, all this is the result of my discussion with fwereade [07:54] (if i understood him correctly, that is) [07:55] 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] which is still we have 2 concrete networks out of the box [07:55] dimitern: I think the code you wrote looks pretty good (I haven't finished reading all of it), [07:55] I'm just trying to understand the specific benefit we get from caching it. [07:55] dimitern: ha, it's actually even easier: hub checkout https://github.com/juju/charm/pull/4 [07:56] 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] 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:57] 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] 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:58] 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] when you go to "list networks" we really do need to probe the provider [07:58] jam, ok, so I can make it return err for 0 >= tag > 4094 [07:58] because they might have just added one [07:58] jam, it's pending, because we need the user to give it a name [07:59] which is descriptive for them [08:00] 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] jam, but fwereade didn't like that and i can concur [08:01] dimitern: so I still don't know why we need to have described a network we haven't named yet [08:02] 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] dimitern: is this for listing what networks a machine has access to? [08:02] if so, we *still* need a name for them [08:02] to display them [08:02] unknown-$PROVIDER_ID could work [08:03] jam, no [08:03] but then we just need a boolean/empty name field in the actual network collection [08:03] jam, these are potentially all the networks, not machine-specific ones [08:04] 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] (unless we transform it to contain only [a-z][a-z0-9-] [08:05] 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] 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] IS it so when a machine starts we can use that list to filter out matches and ignore them? [08:06] 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] jam, i understand your concern :) [08:06] jam, i really wish fwereade could join us on this one [08:07] jam, i'm starting to have doubts about the approach [08:08] 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:14] morning [08:21] mattyw, hey [08:21] mattyw, something occurred to me yesterday about the --dry-run option of upgrade-juju [08:22] 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:23] dimitern, sorry - I'm still waking up, what do you mean? [08:25] 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:26] mattyw, without uploading the effective version picked for upgrade will differ with and without --dry-run [08:27] dimitern, this only applies to --upload-tools? [08:27] mattyw, i think only then we try to upload new tools, no? [08:28] vladk, you've got a review on the networker PR [08:29] vladk, you should add a kanban card for the IsVirtual removal, despite being a trivial change btw :) [08:29] jam, right? [08:29] dimitern: yes [08:30] well, if it is follow up work, vs do this as a tweak and land it. [08:31] jam, it's kinda a follow-up, but the whole PR is about that [08:31] 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] dimitern: thanks [08:32] 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] if it is "tweak this and land" then that probably isn't a new task [08:33] mattyw, right, so I might be wrong then about it differing :) np, it was just a red light i needed to mention [08:34] 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] 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:35] dimitern, do you think I should get someone else to do a review as well? [08:35] mattyw, either fwereade or wallyworld should know a great deal wrt upgrades [08:36] dimitern, ok great, I'll make sure I get their eyes on it as well [08:36] mattyw, i did some stuff around it some time ago, but it seems things have changed since :) [08:39] jam, dimitern: I'm totally cool with as-yet-unnamed networks -- but what are we going to use for the _id? [08:40] 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:41] 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:43] 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:44] fwereade, the providerId is the _id in pendingnetworks [08:45] 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] 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:46] 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] since we need a way to link them not-by-name [08:46] otherwise aren't we scanning again? [08:46] fwereade, ah, so here's the quirk - we get all networks, but no machines associated with them [08:47] dimitern, re _id: hmmmmm, this has the hallmarks of the relation id troubles all over again [08:47] fwereade, perhaps we should though [08:47] fwereade, expand on that please? [08:48] dimitern, take a look at the relation doc sometime [08:48] fwereade, we have Key as _id and a separate int Id [08:48] 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:49] fwereade, right, but that's not true for networks - we always use the juju name, not providerId [08:49] fwereade, except when talking to the provider - like in StartInstance [08:49] dimitern, and pow, we introduce weird ugly races while watching [08:49] dimitern: except if we wanted to link machines to networks that we don't-yet have names for [08:50] dimitern, that's the main thing with relations [08:50] dimitern, it is fucking stupid that we can't use the int ids when watching (say) service relations [08:50] is there any support for anything similar to prerequisite branches (in LP) in github? [08:50] dimitern, but we literally can't do that [08:50] tasdomas: not that we've sorted out [08:50] Its something we want to bring up in a wider conversation (how to do the equivalent on git) [08:50] there are a few ideas out there [08:51] (rebase, create a PR to your prereq branch, etc) [08:51] 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] fwereade: is it reasonably to go to an abstract "network id" that is just the identifier for the doc in the DB ? [08:51] fwereade, ok, so should we drop the pending networks altogether? [08:52] fwereade, instead, when we need to add them, we always give them a juju name for a given provider id [08:53] 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] fwereade, sgtm [09:01] mattyw, axw, fwereade, hangout? [09:01] brt [09:34] menno is gone, right? [09:34] He linked a doc, but didn't share it with comments enablefd. [09:35] morning [09:35] perrito666: morning [09:54] fwereade, dimitern can we make it 15 minute break, just need to run a quick errand, will ping when I'm back [10:02] mattyw, sure, we're there when you're back [10:02] 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:03] perrito666: this returns the backup filename and an sha filename [10:03] perrito666: we're changing the backup api to be a synchronous one that returns the backup file [10:03] perrito666: so we can't return the sha file *as well* [10:03] mgz: 1:1 time [10:03] perrito666: maybe we could return the sha (instead of writing a file) and set it as a header on the response [10:07] voidspace: could be, I was writing into a file because we had an async api [10:08] I could just return the sha [10:08] perrito666: yep, I assumed that was the case [10:08] perrito666: I'm pretty sure natefinch has agreed to switch to a synchronous one [10:09] yup he did [10:09] ok, you can assume sha string is returning there instead of the filename, Ill change it [10:10] perrito666: cool - thanks [10:10] shame I can't use your branch as a dependent branch for my work :-) [10:11] you "can" but the workflow is not pretty [10:11] perrito666: and your changes show up as a diff in my branch [10:11] ah, true [10:11] perrito666: I can add your branch as a remote to my repo and then keep merging [10:12] voidspace: or I could have forked from you repo and then pull request to it instead of to upstream [10:12] but that is quite a pita [10:12] perrito666: right, and then it's harder to just merge your work to trunk [10:13] 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] I think that is sort of the kernel way, people send patches to each maintainer who integrates the thing [10:13] natefinch: so we have a storage story [10:13] voidspace: I think we can do the synchronous approach first, and add in the save to gridfs later (should be trivial) [10:13] voidspace: sounds like it [10:13] natefinch: is that "done" or "in progress"? [10:13] right [10:13]