[00:03] wallyworld_: https://plus.google.com/hangouts/_/76cpj15en6ms7kb8jr9r3fvhco?hl=en [01:28] eh wtf [01:28] I had a dupe of the standup in my calendar and deleted one, now calendar says I'm not coming to the other one [01:29] axw: https://codereview.appspot.com/61560045/ [01:29] davecheney: about to go to standup, will look a bit later [01:30] ta [02:03] * axw wonders if he can justify going to gophercon as well [02:05] thumper: https://codereview.appspot.com/49640050/ [02:09] axw: canonical has 10 entrances due to sponsorship [02:09] axw: could always see if you could acquire one of those [02:10] ooer [02:10] who do I ask? [02:17] axw: um... not sure actually [02:18] axw: mramm to start I guess [02:18] ok [02:20] ah bugger [02:20] package review [02:20] * thumper kicks it again [02:20] perhaps one day soon again [02:21] although I think it is important, especially with waigani needing to learn stuff [02:21] we should definitely get back into it [02:21] however today, I have to take a daughter to the physio === thumper is now known as thumper-afk === thumper-afk is now known as thumper [03:56] WTF? [03:56] bootstrapping local provider fails with trunk [03:57] and it didn't delete the .jenv [03:58] and destroy environment failed === mwhudson is now known as zz_mwhudson [03:58] as did with --force [04:37] thumper: figure out what's breaking? I'm just testing a fix for azure, I can look after that [04:56] axw: thanks for the review [04:56] davecheney: nps [05:03] wallyworld_: a real quick one please, fixes at least one of the critical azure bugs. https://codereview.appspot.com/51300044/ [05:04] sure [05:04] axw: oh shit that looks like my fault [05:04] yeah, it's easy to do.. the defaults stuff is pretty confusing IMO [05:06] the whole config stuff is confusing [05:16] axw: yeah, it was my code in cloudinit causing it to break [05:16] but it should have been able to remove it, but it didn't [05:16] mk [05:39] axw: doesn't look like the bot is running [05:40] hm yeah mine hasn't landed either. I don't have access [05:40] thumper: can you please poke the bot? [06:47] wallyworld_: hey, can you please poke the bot? [06:47] sure [06:47] once it's moved, I'll see if I can get poking privileges... [06:49] yeah, will be different infrastructure [08:58] mornin' all [08:58] dimitern: heya. just saw your comment. I don't understand how the preferences file gets picked up by apt-get? runcmds run after apt-get installs packages? [08:58] morning rogpeppe1 [08:58] axw: hiya === rogpeppe1 is now known as rogpeppe [08:58] morning all [08:59] axw, in sshinit I made it so that it gets called immediately after add-apt-repo [08:59] dimitern: yep that bit works, but sshinit is only used for bootstrap [08:59] (and add-machine ssh) [09:00] axw, so both add-machine and bootstrap manual will work, don't you agree? [09:01] dimitern: I don't, because they're doing things at different times. For add-machine, cloud-init runs apt-get update, apt-get upgrade, apt-get install XXX, then finally it'll write the preferences file [09:01] so I can't see how the pinning takes effect for non-bootstrap machines [09:02] axw, can you point me to the code you're referring to that executes runcmd after any packages were installed? [09:03] dimitern: it's in cloud-init itself. I'll have a rummage in my downloads.. [09:04] axw, so, looking at cloudinit/sshinit/configure.go - we have addPackageCommands very early, before the runcmds are executed [09:05] dimitern: yes, this is meant to mimic cloud-init [09:05] axw, and in case we have an apt source with prefs, we do add-apt-repository, and then immediately it installs the prefs file [09:05] axw, (in addPackageCommands) [09:05] yes I get that - just ignore sshinit [09:06] it is not used for add-machine [09:06] bootstrap is fine [09:06] axw, ok, so going back to environs/cloudinit/ then? [09:06] yes [09:07] and what happens when you provision a non-bootstrap machine [09:07] axw, in ConfigureJuju we have several AddPackage commands before getting to MaybeAddCloudArchiveCloudTools [09:07] axw, but that's fine, because none of these packages are affected by the bug - they're in main, not in cloud-tools [09:07] axw, the only problematic package is mongodb-server [09:08] dimitern: ok. if we don't care if we get other things from cloud-tools that's fine [09:09] axw, yep, sorry if i wasn't clear [09:09] no worries [09:09] axw, only mongodb-server and only on precise needs to be installed from cloud-tools pocket [09:09] dimitern: if you don't mind I will move it up into environs/cloudinit though, as a bootcmd [09:09] when I have nothing better to do :) [09:10] axw, i don't mind at all, but please live test it ;) [09:10] yes definitely [09:10] axw, now there's a slight imperfection (two actually) - the prefs file is created twice [09:10] how's that? [09:11] axw, due to the addfile call - both after adding the repo and when all the rest runcmds are run, but the contents are the same [09:11] ah right [09:11] axw, and the second issue is the duplication of logic in sshinit, but adding a boot cmd should fix both [09:12] mgz, hey [09:13] rogpeppe: did you get anywhere with reporting bootstrap errors back to the user? [09:13] or if you've shelved it, is there something I can pick up? [09:13] axw: no, i didn't [09:14] axw, i had some issues trying out manual bootstrapping on an existing saucy VM [09:14] axw: i had an idea as to how i might do it, but the sprint got in the way and then i haven't got back to it, i'm afraid [09:14] rogpeppe: nps [09:14] thanks [09:14] dimitern: what's issues? [09:14] what* [09:14] axw, it seems it tries to use ubuntu@ even if I set bootstrap-user to something else; and doesn't get very far [09:15] dimitern: it will first try to use ubuntu@ tosee if it has already set up the ubuntu user. it *should* then use bootstrap-user to initialise the ubuntu user [09:15] * axw checks that this works on his machine still [09:15] axw, I had to actually create an ubuntu user and authorize my ssh key so i can login passwordless, but it still insisted on asking for password in sudo [09:17] axw, although, it might be all moot, because some time down the road i realized i was using sudo juju bootstrap, and that was getting /usr/bin/juju, i.e. 1.16.5 from the ppa [09:17] hrm, seems it's broken [09:17] you shouldn't be using sudo for manual [09:17] but once i started using trunk it went fine, except for one small thing [09:17] yeah, i know - i was just lazy and relying on bash history :) [09:18] ok [09:18] the small thing is I get "storage-auth-key" expected string, got "" after I did destroy-environment, and then status [09:19] hrm [09:19] let me try again [09:19] sounds like prepare failed [09:19] dimitern: it is broken on trunk tho [09:19] axw, what is? [09:19] dimitern: I started getting rid of BootstrapStorager, and broke it in the process. will see if I can fix it now [09:20] axw, ah, ok [09:20] initialising the ubuntu user [09:21] dimitern: in the mean time, if you enable passwordless sudo for unbuntu, you should be good to go [09:21] axw, yep, that's how I finally made it [09:22] axw, is it normal to get "manual:" instance names in a manual env? when I used add-machine the instance name was "manual:" [09:23] dimitern: just for the bootstrap node [09:24] axw, but since you can't start more instances.. [09:24] axw, i successfully deployed stuff on 0, but deploying without --to gets me phantom machines and some errors later on in status [09:25] dimitern: yeah, I've got a branch up for review that disallows add-machine (except ssh:...) [09:25] the "Wire up prechecker" one [09:25] it's back from the dead [09:26] axw, perhaps any commands that could result in an environs.StartInstance call should be disallowed [09:26] dimitern: yes, that's what will happen [09:26] axw, sweet! [09:27] dimitern: also, you won't be allowed to create contains on providers that don't support it [09:27] containers* [09:28] axw, ah! that reminds me - i've encountered an issue while live testing in ec2 yesterday - the lxc provisioner kept dying because lxc is not supported [09:29] * dimitern should make a habit of saving odd errors and stuff like that for easier reporting later [09:29] had you tried adding a container? [09:30] nope [09:30] it's no use - nothing can access it yet [09:30] yeah, just wondering why it would be doing that [09:31] i did in previous tests, they deploy ok, but can't relate to each other [09:33] mgz, so i can see bug 1241674 you fixed is released in 1.17.1, and bug 1188126 is still in progress? [09:33] <_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks

[09:33] <_mup_> Bug #1188126: Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured

[09:50] adeuring, hey, are you working on bug 1276462 ? [09:50] <_mup_> Bug #1276462: add a JUJU_TESTING environment variable for stats=0 on charm store interactions [09:50] dimitern: yes [09:51] adeuring, but there's no MP yet? [09:52] dimitern: not yet ready -- i'm still learning the code base, so I#m not that fast [09:52] adeuring, ok, just checking, thanks [10:47] mgz, standup? [11:56] niemeyer, thanks for replying - i understand you've been busy lately, didn't mean to bug you unnecessarily :) [12:00] dimitern: Heya [12:01] niemeyer, welcome back! [12:02] dimitern: Thanks.. sorry for taking longer than I wish [12:02] niemeyer, no problem [14:11] jamespage, maybe I was confused about packaging for the 1.16.6 release. Since trusty is leaping to 1.17.x, should I release 1.16.6 though the stable ppa only? [14:11] sinzui, yes [14:11] sounds good to me [14:14] thank you jamespage === frankban_ is now known as frankban [14:14] sinzui, I started work on the .5 SRU for saucy last week - I'll hold off until .6 is done as well [14:15] understood [14:28] dimitern: ping [14:28] niemeyer, hey [14:28] dimitern: Heya [14:29] dimitern: We have a small inconsistency being introduced which would be nice to brainstorm on [14:29] dimitern: Nowdays we have ec2.RunInstances [14:29] Nowadays [14:30] dimitern: This type is used as an options structure when calling EC2.RunInstances [14:30] niemeyer, yes? [14:30] dimitern: The network support is now adding NetworkInterfaceOptions, and NetworkInterfaceSpec [14:30] dimitern: Which is not quite great [14:31] niemeyer, yeah, it was bugging me a bit [14:31] dimitern: They're both very specific to a given context [14:31] dimitern: although their names say nothing about that context [14:31] niemeyer, they are [14:31] dimitern: What will we have next? NetworkInterfaceStuff? :) [14:31] niemeyer, i'm open to suggestions on naming :) [14:32] dimitern: Following the lead of RunInstances, NetworkInterfaceOptions should probably be called CreateNetworkInterface [14:32] niemeyer, ok and NetworkInterfaceSpec - NetworkInterfaceOptions? [14:34] dimitern: What's the difference between the two? [14:34] dimitern: In terms of data [14:34] niemeyer, just a sec [14:35] niemeyer, so the *Spec is used only in RunInstances, because it can specify either a new or an existing NIC (Id empty or not) [14:35] dimitern: In terms of data [14:36] dimitern: It looks like they are exactly the same, except for two fields.. and one of these fields runs every other field irrelevant [14:36] niemeyer, in RunInstances you can specify more things (and different ones) than in CreateNIC [14:37] niemeyer, DeviceIndex and DeleteOnTermination do not apply for CreateNIC [14:38] niemeyer, and security groups are specified only by id, not name or id [14:38] dimitern: Right.. what is device index about? [14:38] niemeyer, where to "mount" the NIC [14:38] niemeyer, eth0, 1, .. [14:41] dimitern: I'm tempted to suggest RunNetworkInterface [14:41] niemeyer, sgtm [14:41] dimitern: It's not great, but I cannot come up with anything nice that would fit in a tweet :) [14:42] niemeyer, indeed :) [14:42] niemeyer, so i'll s/NetworkInterfaceOptions/CreateNetworkInterface/ and in the next branch s/NetworkInterfaceSpec/RunNetworkInterface/ [14:43] dimitern: Thanks [14:50] mgz, ping [14:53] niemeyer, I've just noticed in https://codereview.appspot.com/54570048/ there are similar *Status constants - do you want them removed like in the vpc prereq? [14:54] niemeyer, I can do it in the RunInstances CL, because I've just submitted the NICs one [15:01] sinzui: not sure if this classifies as critical or not, but manual provider is buggered on trunk -- https://bugs.launchpad.net/juju-core/+bug/1279259 [15:01] <_mup_> Bug #1279259: manual: bootstrap fails if ubuntu user is not initialised

[15:02] I'm working on it now, but haven't marked it against 1.17.3 in case you want to release without the fix [15:10] natefinch, are you around for a review of https://codereview.appspot.com/60620043/ ? [15:14] axw__, I think it is critical. I think we are two weeks away from having a manual provisioning env that is tested with every revision merged [15:16] sinzui: ok, will try to get it fixed tomorrow. thanks [15:17] niemeyer, ..or you think it's ok to leave them as they are? [15:19] dimitern: yeah [15:19] natefinch, ta! [15:23] rogpeppe, afternoon - do you have a moment? [15:23] mattyw: hiya [15:23] mattyw: yeah, i do === luca__ is now known as luca === hatch___ is now known as hatch [16:06] dimitern: Hmm [16:07] natefinch, review poke [16:09] dimitern: INdeed, it's the same issue [16:09] dimitern: and we can already see the mentioned issue surfacing [16:09] niemeyer, ok then, I'll remove the constants before I submit the next CL [16:09] dimitern: ec2.AvailableState, and ec2.AvailableStatus [16:10] niemeyer, AvailableState is gone now [16:10] dimitern: Right, I mean that the motivation I provided to not do that is real [16:11] dimitern: Either we put context in their name, or we drop them.. I suggest dropping until we have a better idea of how/when to use them [16:11] niemeyer, noted, will drop them [16:13] niemeyer, and apart from that only one CL left - yay! :) [16:15] dimitern: can you tell me something about the intended use of juju.apiState.cachedInfo ? [16:16] rogpeppe, that's where the api info creds are cached for the CLI [16:17] dimitern: ah, i see where it's initialised now [16:17] dimitern: it seems a weird place to stash that [16:17] dimitern: apiState is supposed to be an ultra-thin wrapper around state [16:17] dimitern: not a place to store arbitrary runtime context [16:18] rogpeppe, if that was the intent, it wasn't well documented :) [16:19] dimitern: sorry, i thought this comment was reasonably clear. [16:19] // apiState wraps an api.State, redefining its Close method [16:19] // so we can abuse it for testing purposes. [16:19] rogpeppe, also, you're the reviewer on this change btw ;) r2209 [16:19] dimitern: i'm sure we need something like this - i was just a bit surprised :-) [16:20] dimitern: memory shmemory :-) [16:22] rogpeppe, hehe [16:22] dimitern: sorry, got sidetracked by the kids for a bit. Review is pretty much done [16:32] natefinch, thanks! [17:19] niemeyer, thanks for all the reviews! [17:19] dimitern: np, thanks for pushing these change [17:19] s [17:20] niemeyer, there might be more to come, but these should suffice for now [17:39] g'night all! [18:39] natefinch: largest CL ever? https://codereview.appspot.com/62230043 :-) [19:02] do people use the GUI with maas? [19:06] hatch: I do/have [19:06] marcoceppi thanks :) [19:11] rogpeppe: lol, nice === zz_mwhudson is now known as mwhudson [20:33] natefinch: is juju ipv6 safe? [20:34] marcoceppi: I believe so, but I don't know that I've actually tried it. I know there's code for IPv6 in there, though., [20:38] marcoceppi: i think it's somewhat unlikely [20:38] marcoceppi: for example, i think we often assume we can make a valid host/port combo by simply appending ":port" [20:39] rogpeppe1: you mean within charms, or within the juju core? [20:39] marcoceppi: the latter [20:40] marcoceppi: it *might* be ok, but it hasn't been verified [20:40] ah, yeah, it'd need to be encapsulated within [] [20:41] marcoceppi: yup [20:41] marcoceppi: I certainly wouldn't count on it without some heavy testing. [20:42] thanks [20:58] o/ marcoceppi [20:58] thumper: \o/ [20:58] marcoceppi: if juju isn't ipv6 safe we damn well ought to make it so [20:58] I'd like charms to be able to ask for an ipv6 address [21:00] hey marcoceppi, are you wanting my incredibly hacked up github webhook charm? [21:04] natefinch: are you currently working on any of the 1.17.3 or 1.18.0 bugs? [21:06] thumper: I just started looking into the mongo location bug, but haven't gotten far with it [21:06] ok [21:08] thumper: hey, got a sec? I hear you're the guy to talk to about getting multiple local envs working in lxc land? [21:09] rick_h_: yes [21:09] thumper: I hear there's 3ish tricks to make it work? [21:09] rick_h_: it works [21:09] thumper: in trunk? in 1.17.3 I get an error on the mongo port not being available [21:09] errr 1.17.2 [21:09] rick_h_: you just need to make sure that you have different ports for mongo, api, storage [21:09] ok, yea I've got different ports for the api/storage but didn't know what key to use for mongod [21:10] I didn't see any docs around it for the env.yaml [21:10] rick_h_: here is my config for a local that will run with a default local. http://pastebin.ubuntu.com/6922215/ [21:11] thumper: thanks, looking [21:11] ah, state-port I don't have [21:12] thanks thumper, I'll try that out. [21:38] I think I could save myself a lot of frustration if I just did ln -s /usr /user [21:42] I love it when comments just outright lie. [21:42] / This is a variable only to support unit testing. [21:42] var mongodPath = "/usr/bin/mongod" [21:42] (is then used in production code) [21:43] thumper: yes please, I heard I should know more about it [21:43] marcoceppi: ok, will send, but you have to realize it is demo-ware :-) [21:43] that's fine! [21:45] thumper: where does the new mongod live in trusty? [21:45] natefinch, It was true when the test was written :) Well I assume test-driven development...otherwise it is a malicious lie [21:45] natefinch: *shrug* [21:46] natefinch: do you mean the juju-db package one? [21:46] thumper: yeah [21:46] natefinch: that is somewhere special [21:46] probably need to look in the package itself [21:46] I do know that it isn't in th path [21:46] sinzui: heh, yeah. I assume someone put it there for a test,and then someone else came along, needed a path for mongo, and said "hey, there's one already defined" and used it. [21:46] natefinch, I had the path, and getting it again [21:47] * sinzui keeps switching between version of juju and deps [21:48] natefinch, /usr/lib/juju/bin/mongod [21:49] sinzui: thanks [21:50] natefinch, this is all that juju-mongodb added to /usr/lib/juju [21:50] http://pastebin.ubuntu.com/6922408/ [21:53] can the bot owner please update distinfo on that bot host [21:53] I can't land my change because the os runnong on that machine doesn't know about trusty [22:21] thumper: pong [22:21] davecheney: did I ping you? [22:21] thumper: do you have access to the bot ? [22:22] davecheney: yeah... [22:22] what do you need? [22:22] can you do a `apt-get update && apt-get install distro-info` [22:22] so that the bot knows about trusty [22:22] * thumper goes to try [22:22] thank you [22:23] davecheney: it says it is already at the latest revision [22:25] davecheney: however that doesn't list trusty [22:26] davecheney: how do we update the source for it? [22:26] oh dear [22:27] thumper: shoulnd't need to [22:27] we publish distro-info's for all supported releases [22:27] is the bot running quantal ? [22:27] --devel still doesn't list it [22:27] bot is running precise [22:27] lists up to saucy [22:27] so... [22:27] something there is all fubared [22:27] try --all [22:28] did [22:28] no trusty [22:28] maybe juju shouldn't depend on this pacakge [22:28] heh [22:28] this isn't the first time it's let us down [22:28] blame someone, anyone else [22:29] can't be our fault [22:29] we had the same bullshit in August when Saucy came out [22:29] sinzui: hey. is bug # 1247175 really a block for 1.18? can't we just use the release notes to tell people to update any scripts rather than having to develop/test code which will be removed next release? [22:29] <_mup_> Bug #1247175: juju sync-tools does not support --destination

[22:29] who updates this? [22:29] wallyworld: hey [22:29] o/ [22:29] wallyworld: I have a proposal that adds an upgrade script [22:29] wallyworld: needs agent.Config in the upgrade context [22:29] ok [22:29] will add it [22:29] my branch adds it [22:29] :-) [22:29] take a look [22:29] rightio [22:30] wallyworld, How do we get people to read the release notes and update their scripts when apt-put it there [22:30] sinzui: put clues in the release notes [22:30] to install the package users must answer 5 questions drawn from the release notes [22:31] it's like copy protection in the 80's [22:31] wallyworld, I think the win users are the only one who know there are release notes because they are downloading the client from the milestone page [22:31] sinzui: ok, i'll add the code to support --destination with a deprecation warning [22:33] thumper: i'm seriously considering having each major.minor version have its own sub package under juju-core/upgrades [22:33] otherwise that top level package will bloat [22:33] wallyworld: I have no strong feelings either way [22:33] +1 to avoiding bloat [22:34] subpackage sounds fine [22:34] wallyworld: this one is important because I fucked up: https://code.launchpad.net/~thumper/juju-core/fix-provider-query-in-machine-env-worker/+merge/205864 [22:34] ok, will look at that one too [22:34] wallyworld: and this one is the one with the upgrade https://code.launchpad.net/~thumper/juju-core/juju-run-on-machine-with-no-units/+merge/206050 [22:34] yeah already found that one [22:35] * thumper goes to file a bug for the fuckup [22:37] davecheney, we could have a dot-file for each juju version in the user HOME. when juju runs and doesn't find the dot-file, it shows the user the release notes and will not do anything unit the user agrees to save the file. [22:38] sinzui: like the thing that sudo does [22:39] \o/ home brew accepted juju 1.16.6. I can close the release log [22:40] \o/ [22:42] thumper: i was imagining description would be short, able to be used in logging. look like i need to add a Name field [22:42] wallyworld: yeah, ok [22:43] wallyworld: I was wanting it to be nice and long and descriptive :-) [22:43] not sure who would see it [22:43] maybe it doesn't need to be there [22:43] i'dd do it as a code comment [22:43] and instead becomes a "docstring" on the function [22:43] and keep the desc short [22:43] I'm happy either way [22:43] wan't sure what was needed [22:44] since we are in a brave new world [22:44] it's really for devs what you have done i think [22:44] yeah [22:44] I'm happy to change it [22:44] so +1 to doc string :-) [22:44] thanks :-) [22:44] i'll update the Description attr doc string also [22:44] kk [22:44] so people know to keep it short [22:44] yep [22:49] thumper: i has upgradeOperation as a base struct for UpgradeStep implementations. if you want to introduce upgradeStep instead, which I think is fine, can you remove upgradeOperations? [22:49] s/s// [22:51] I assumed that you would have one soon, but I needed something for the branch [22:51] happy to wait until you've landed something and update it [22:51] or merge in as a dependency [22:51] if yours is ready first, you can land it and i'll deal with it [22:51] kk [22:52] thumper: we are missing a test for the actual business logic [22:52]