[00:52] bigjools: sup [00:52] thumper: do you have any contacts on u1 ? [00:53] sidnei: ping [01:10] davecheney: pong [01:11] sidnei: nate is looking for someone that can help him with windows installer tools [01:11] thumper: did you write the DiskManager stuff for tools? [01:11] does u1 use anything for producing it's windows installer that would be of use ? [01:12] davecheney: uhm, brian curtin was our windows guy, i think mike mccraken is in charge now. let me see if i can figure out what they are using. [01:12] sidnei: what timezone are they in [01:13] i wanna try to cross connect nate and those two guys [01:13] mike is in cali [01:13] kk [01:13] that'll work [01:13] i think brian left recently [01:13] oh snap [01:13] ok, i'll write to mike [01:17] davecheney: seems to be bitrock: http://bitrock.com/ [01:17] http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-windows-installer/trunk/view/head:/scripts/build_installer.py fwiw [01:17] sidnei: thanks [01:18] * sidnei disappears again [01:34] wallyworld_: no [01:34] yeah, i saw john did it [01:34] davecheney: yes [01:34] but nothing seems to use it apart from tests [01:34] thumper: yes what [01:34] * thumper shrugs [01:35] i think I forgot the question [01:35] davecheney: yes I have contacts on u1 [01:35] davecheney: beuno [01:35] thumper: ahh, this is a question from Nate [01:35] who wants to know what we use for win32 installers [01:35] ah [01:35] sidnei: said talk to Miek McCracken [01:35] they are in very similar time zones [01:36] thumper: anyone else who delivers one win32 in the company I can point him too ? [01:36] sorry, don't really know [01:36] thumper: s'okj [01:36] it's an unusual request [01:36] although jamesh used to work on u1 [01:36] he may know [01:37] * thumper pings him [01:37] axw: do you get much chance to talk with Nate ? [01:37] he's in a pretty shitty timezone for you [01:37] WA <> Central time is not awesome [01:37] davecheney: haven't spoken to him since I've started [01:37] yeah it's like, the opposite [01:37] :) [01:38] they must be ~12 hours apart [01:38] yep [01:38] axw: it is the fall that enslaves us all [01:39] "most isolated city in the world", even when you're working remotely [01:40] axw: you have your own currency over there, right ? [01:41] yeah, the WA bux [01:41] actually we just trade in iron ore [01:41] with a picture of the little creatures brewery on the $20 bill [01:41] davecheney: The win32 code is at https://launchpad.net/ubuntuone-windows-installer [01:41] ha! raw coke iron [01:41] thumper: ta [01:42] heh, might be using py2exe [01:42] axw: do the ATMs dispence iron ore and uranium ? [01:42] but should still use a .msi somehwere [01:42] looks the same as bzr's [01:43] davecheney: what is an ATM? I keep my money under my bed [01:43] anyway... ;) [01:43] money... or opals and ore? [01:44] yep, not a very comfortable bed [01:53] I am shattered [01:53] my daughter woke up twice last night, my son three times [01:53] :( [01:53] :( [01:53] I remember those days [01:54] axw: don't stress, and sleep if you need to [01:54] the world won't fall apart if you miss a day :) [01:54] thumper: thanks, I'm kinda used to it, just a bit worse than usual [01:55] * thumper nods [01:56] thumper: have you ever tried upgrading a local provider? :) [01:56] thumper: the bootstrap machine agent restarts repeatedly [01:59] I'll make sure I can reproduce it again, and log a bug.. [02:06] axw: we decided that we didn't support upgrading with the local provider [02:06] axw: however, if it is easy to fix [02:06] then we could do it I suppose [02:06] I just wasn't going to waste cycles on it [02:06] thumper: ah ok [02:07] we should either document the limitation or fix it I guess [02:07] do we want a bug in LP anyway? at least then we can decide to tell "upgrade-juju" to not attempt [02:10] Bug #1214676 -- logged anyway, at least then there's a record for the next unsuspecting user [02:10] <_mup_> Bug #1214676: upgrade-juju in local environment causes bootstrap machine agent to restart continuously [02:39] jamespage: thanks for keeping https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-2-delivery up to date [02:39] i'll try to find out when we're going to deliver 1.14 stable as soon as I can [03:07] o/ [03:56] axw: thanks for 12742045/ [03:56] how come none of the tests have to change ? [03:57] does that mean we don't have a test that checks that the listener file exists on disk ? [03:57] davecheney: because you don't need to manually delete unix sockets in Go [03:57] Close() unlinks them [03:58] axw: you can still leave socket turds around [03:58] if the process terminates, yes [03:58] service jujud-unit-agent stop [03:58] will leave a turd around [03:58] that was how I ran across this [04:00] the existing tests all specify the path as non-abstract [04:00] i.e. they don't go through that codepath that specifies them as abstract [04:00] hmm, ok [04:00] i'm not going to complain [04:00] but maybe someone will [04:00] ideally we'd have a test for it, but it seemed like an awful lot of work for very little gain [04:01] axw: yup [04:02] davecheney: so, you are prepared for an Azure onslaught? [04:02] and axw :) [04:02] bigjools: yes, bring it on [04:02] because bugs are getting filed already (not sure if they are real bugs yet...) [04:03] bigjools: yeah, we'll manage [04:03] I'll help as much as I can of course [04:03] will take you through it next week [04:03] ok [04:03] will prob make Monday after all [04:03] \o/ [04:04] your weed delivery came through early ? [04:04] nah sending the wife to get it [04:04] bigjools: I know nothing about Azure, so ... probably not prepared. But I'll look forward to learning [04:04] axw: there is indeed much to learn [04:05] on the bright side, the weather here is marvellous [04:05] here too - spring is slightly early [06:03] has anyone been trying canonistack with 'use-floating-ip: true' ? I saw the machine come up, and I can ssh to the private address, but the public address tells me invalid public key [06:05] I haven't, but I can give it a try [06:05] axw: if you would, to give me a point of comparison [06:15] jam: it works for me if I specify the identity file (~/.canonistack/axw_lcy02.key) and user as ubuntu [06:15] i.e. what's in my .ssh/config for canonistack, for the private IP range [06:16] axw: ah, user ubuntu, probably my fault [06:16] different machine, I don't have my normal setup [06:17] axw: thanks for the reminder [06:17] jam: no worries [06:17] default key was fine, didn't have the config for ubuntu@ for 172.* addresses. [06:18] axw: interestingly, username isn't part of the 'ssh -v' output. [06:18] so it would seem - helpful! [06:25] arosales: hopeful ping [06:26] bigjools, hello [06:26] arosales: wow you're up! [06:26] arosales: I updated your config doc with my version of things, let me know how it looks [06:26] for a little bit longer [06:27] bigjools, thanks [06:27] * arosales is waiting for agent-state to go to started in Azure [06:27] using --upload-tols [06:28] bigjools, I saw your and gavin's reply so I was mistaken there. I was unaware the --upload-tools built juju-tools locally to match the version being used [06:28] arosales: no worries [06:28] I'll see if I can re-create your deployment bug [06:30] https://bugs.launchpad.net/juju-core/+bug/1214636 may be due to mismatch juju-tools [06:30] I highly suspect so yes [06:30] I am trying with --uploads-tools now [06:30] https://bugs.launchpad.net/juju-core/+bug/1214178 I think we can make better by having the user specify the settings file [06:30] I am just bootstrapping then I'll try to deploy [06:31] arosales: this is the first time I ever saw a settings file :) [06:31] https://bugs.launchpad.net/juju-core/+bug/1214181 ~should~ be resolved once we get the correct tools in Azure [06:31] <_mup_> Bug #1214181: Azure Provider always uploading 1.12 tools [06:31] bigjools, I take it you also saw Ben's tool in the google set up doc [06:31] I did [06:31] not looked at the code [06:31] ok [06:32] we just saw the stuff on the management UI about creating and uploading a certificate [06:32] Azure complained my pem didn't have the right structure when I openssl command [06:32] I too went that route initially [06:33] I love the way their ui insists your file must be a .cer, like that means anything [06:33] but I think the settings file makes for a better user experience. [06:33] bigjools, I feel your guys' pain [06:33] arosales: all of Red used the openssl tool to generate a certificate fine [06:33] to a _very_ small degree [06:33] ha :) [06:33] arosales: the settings file can only be downloaded once you upload a certificate, right? [06:33] arosales: openssl req -config /usr/share/ssl-cert/ssleay.cnf -x509 -nodes \ [06:33] -days 3650 -newkey rsa:2048 -keyout azure.pem -out azure.pem [06:34] openssl x509 -inform pem -in azure.pem -outform der -out azure.cer [06:34] bigjools, that may be my pilot error on the pem gen . . [06:34] davecheney: exactly [06:34] I thought I was following Azure instructions, but the settings file helps simplify that. [06:34] is the settings file documented anywhere? [06:35] hm . . . I'll have to check with utlemming on that [06:35] I can't see anything on manage.windowsazure.com about it [06:35] what is the settnigs file ? [06:35] Azure hands down the pems for a subscription in a xml based file [06:36] AFAICT it's some xml that contains a subscription ID and the certificate [06:36] but given that you have to generate and upload a certificate I question its usefulness for juju [06:37] bigjools, aiui this settings file generates the need certificate. [06:37] so I didn't have to upload a cert to have juju work. [06:38] just needed to parse the settings file and put the pem in the correct path [06:38] arosales: ok, would love to see any docs on that [06:38] how did you find out about it? [06:38] bigjools, ok I'll follow up with utlemming on it. [06:38] thanks [06:38] utlemming also says this helps solve the China Azure endpoint problem too [06:39] arosales: what problem? [06:39] utlemming told me about it when I was having some initial bootstrap issues [06:39] managing multiple certificates for different Azure end points [06:40] bigjools, I'll start a thread with utlemming so when he gets up the morning he can shed some more light on it. [06:40] arosales: I honestly can't work out what the problem is with that, if Azure needs a separate cert then we just config it in a separate juju env [06:40] ok cool [06:41] ubg state still in pending with --upload-tools [06:42] bigjools, http://pastebin.ubuntu.com/6009219/ [06:42] I seem to not be able to get out of pending [06:42] what version of juju should I be using? [06:43] and is there any other special juju set up I need? [06:44] * arosales using 1.13.2 (compiled yesterday) [06:44] arosales: I am using tip of trunk [06:45] I just did a deployment, so let's see how it goes [06:45] bigjools, ok thanks [06:45] arosales: you can try ssh-ing into machine 1 [06:45] check the agent log [06:46] * arosales just destroyed [06:46] will redeploy again [06:47] I just deployed deploy cs:precise/juju-gui on saucy [06:47] bigjools, juju didn't complain about the series mismatch? [06:48] it does unless you force the series [06:48] I was just deploying wordpress out of a local saucy repo [06:49] ok [06:49] bigjools, I guess you just set you "default-series" to "precise" in your env.yaml, correct? [06:49] arosales: no, that's saucy still. I literally just did "juju deploy cs:precise/juju-gui" [06:50] and off it goes [06:50] huh ok [06:51] bigjools, have you had success with a local deploy? [06:51] I haven't tried [06:51] I just downloaded the latest wordpress charm and did [06:52] --repository=/home/arosales/devel/local-charms/ local:saucy/wordpress [06:52] * arosales stating the obvious [06:53] I'm getting public key error trying to ssh into machine 1 [06:53] this means cloud-init is probably hosed [06:54] either that or juju's user data went wrong - and given the bootstrap worked I suspect the latter [06:54] ugh [06:54] I've definitely deployed before so something has recently broken [06:55] there was a recent fix for cloud-init ssh access on azure . . . [06:55] sadly no way of finding out since I can't ssh in ... [06:55] oh do you have a reference? [06:56] the fix might not be in the image [06:56] https://bugs.launchpad.net/cloud-init/+bug/1212723 [06:56] <_mup_> Bug #1212723: cloud-init fails to set user password on Windows Azure

[06:56] I had thought that had gone into the Monday's daily . . . [06:56] arosales: ah that's not relevant here [06:56] we don't use passwords [06:57] so I can ssh into machine 0 but not 1 [06:57] ah ok [06:57] something catastrophic has gone wrong in cloud-init if it hasn't picked up the ssh key [06:57] I'll write this up on the bug arosales [06:57] ya 0 has been able to go to a started state for me, its just subsequent services that get stuck in pending [06:58] bigjools, if you can point to something in cloud-init I can pick this back up with utlemming and smoser in the morning (us time) [06:58] it could be cloud-init or juju's fault [06:59] so I'll write up as much as I can and then you can get smoser to take a look I guess [06:59] we could do with a debug setting to put a password on the account [07:00] bigjools, which bug are you documenting in? [07:00] arosales: https://bugs.launchpad.net/juju-core/+bug/1214636 [07:00] <_mup_> Bug #1214636: Azure Provider: Deployed service never goes to started [07:00] ok [07:01] bigjools, did that fail with the charm store gui deploy and the local charm or just the local? [07:02] arosales: with the cs one [07:02] ok [07:02] not sure it matters [07:03] it's not getting that far [07:05] arosales: I'm going to try with a different (older) image that I used successfully before and see if that helps [07:05] bigjools, ack, thanks for looking into and the help [07:07] arosales: not a problem [07:08] geesh deploys are taking about 9 minutes [07:08] and that just waiting for the service to connect to the state server [07:09] arosales: azure is slow :/ [07:10] bigjools, is there a particular API call that takes long [07:10] I would like to bring this up with msft on why deploys take so long [07:10] arosales: most of them return quickly, it's just the provisioning process [07:11] waiting for a machine to come up and then boot and then provision. [07:11] a certain amount of time is wasted if the image is not new enough as the apt-get update/upgrade takes a while [07:12] we should be hitting a local mirror for apt-get updates on the order of less than a minute, especially for a daily image. [07:13] It seems the console provisions vms faster than 5 minutes, but I haven't done one recently [07:13] would be good comparison [07:14] arosales: the api calls that are slow are mostly deletion of stuff [07:14] but there's plenty of bugs filed about that already [07:14] ok, but that shouldn't affect the deploy times [07:14] and there are fixing delete [07:15] I think you saw the latest API for that [07:15] yep [07:23] jam: I can't make the standup. should I just send comments to the list? [07:23] (for shared review) [07:26] allenap: Hi! I saw your branch with improvements to the Makefile... Another thought I had the other day is adding -y to the apt-add-repository and apt-get installs (or at least allowing -y via env or similar?). What do you think? [07:28] bigjools, on a quick test from the console gallery it takes about 4 minutes to create a virtual machine [07:28] arosales: sounds about right [07:32] arosales: huh, my known-good image no longer works [07:33] davecheney: why would mongo be coming up on port 27017 and juju wanting to connect on 37017? [07:33] :-( === tasdomas_afk is now known as tasdomas [07:38] arosales: you should probably call it a night! If you can grab Scott tomorrow maybe he can help debug based on my bug comments [07:41] bigjools, will do [07:42] ok good night fellas [07:42] nn arosales [07:42] bigjools, I'll touch base with smoser tomorrow morning [07:42] ok [07:43] thanks [07:43] * bigjools eats [07:54] 5 [07:55] axw: sounds good. I think we're going to try and have Tim run a shared review conversation sometime in the AU-friendly timezones. But I haven't seen him to coordinate it. [07:57] jam: okey dokey, thanks [08:03] mornin' all [08:04] rogpeppe, heyhey [08:04] fwereade: yo! [08:06] rogpeppe: heya [08:06] TheMue: hiya [08:13] TheMue, ping [08:13] noodles775: I think that's a fair point. I'll add the -ys. [08:14] TheMue, actually I'll just mark https://codereview.appspot.com/12347043/ WIP, please reject it yourself if you're doing a fresh branch for unset [08:15] allenap: thanks (it wasn't really a point about your branch, just something I needed/wanted yesterday, and since you were there... :) ). [08:27] Gna, update just made me reboot. [08:27] fwereade: Seen that you pinged me? [08:59] hey, anyone know why would mongo be coming up on port 27017 and juju wanting to connect on 37017? [09:01] bigjools: "apt-get install mongodb" brings it up on 27017 [09:01] bigjools: but jujud coming up sets an upstart config that puts a different one on 37017 [09:01] with TLS enabled, etc. [09:01] jam: this was after I did a bootstrap [09:01] b [09:01] bootstrap node didn't finish coming up [09:01] bigjools: that sounds like cloud-init successfully installed mongodb-server, but jujud did not successfully finish bringing itself and mongodb up [09:01] and ssh-ing in showed this [09:01] yeah [09:02] in cloud-init-output.log it just shows lots of failed connections [09:02] no other errors obvious [09:02] can you tar up and post the cloud-init-output ? [09:02] I can take a look at it [09:02] I an do better and put your public key on the machine if you want? [09:02] bigjools: ssh-import-id jameinel should wokr [09:02] work [09:03] one sec [09:03] ssh ubuntu@juju-azure-9nz3pmvw7e.cloudapp.net [09:03] success [09:04] jam: I'll come clean on something - this is using an old-ish saucy image but I needed to work out why I can't deploy on the latest daily. This old image used to work. [09:04] the latest daily shows a publickey error, so can't ssh in and see [09:06] bigjools: root@default:~# mongod --version [09:06] db version v2.0.4, pdfile version 4.5 [09:06] Wed Aug 21 09:05:32 git version: nogitversion [09:06] that looks like a really old db version [09:06] 2.0.4 [09:06] vs 2.4+ should be in new saucy [09:06] weird - I have deployed with this image before [09:06] why would this stop working? [09:06] ||/ Name Version Description [09:06] +++-========================-========================-=================================================== [09:06] ii mongodb-server 1:2.0.4-1ubuntu2.1 object/document-oriented database (server package) [09:07] bigjools: /etc/lsb-release says this is a Precise image, not saucy [09:07] yeah was about to sya [09:07] but should still work nonetheless [09:07] oh wait ... haha [09:07] bigjools: if we know it is precise, we add-apt-repository ppa:juju/stable to get newer mongodbx [09:08] I know what;s up, I think my default series is wrong :) [09:08] right :) [09:08] thanks for helping me see the end of my nose! [09:08] bigjools: so your machine thinks it is deploying saucy, but it is actually precise [09:26] jam: bigjools you need to install juju:ppa/stable [09:27] to pick up the mongodb dep [09:27] davechen1y: jam figured it out, I had a dodgy config [09:29] bigjools: also [09:29] i wasn't thinking [09:29] we always insert that ppa via cloud-innit on the remote bootstrap machine [09:29] if required [09:29] understandable [09:30] * bigjools heads towards TV to watch Aussies lose at cricket again [09:30] bigjools: we're going to get on like a house on fire next week [09:30] i'm super confident of that fact [09:30] jam: yolanda has a questoin about bootstrapping on canonistack [09:30] davechen1y: :D [09:31] hi, i just upgraded to 1.12 version of juju, trying to deploy on canonistack, but deployment is stuck on INFO juju open.go:69 state: opening state; mongo addresses: ["10.55.60.49:37017"]; entity "" [09:31] she's seeing it trying to contact the bootstrap node on the private 10 [09:31] ip [09:31] gives timeout [09:31] jam: mgz any ideas ? [09:31] how do you setup the port forwarding for canonistack ? [09:34] fwereade, jam, mgz, TheMue: https://codereview.appspot.com/13089045 [09:34] fwereade: i hope this addresses your concerns about the lax stuff. [09:35] davechen1y: you can either use 'sshuttle' or you can just set "use-floating-ips: true' [09:35] davechen1y: canonistack got 2 new /24 for public IPs, so we should have enough now. [09:36] rogpeppe1: *click* [09:36] davechen1y: but the port forwarding I use is: apt-get install sshuttle; sshuttle -r ubuntu@$BOOTSTRAP 10.55.0.0/16 [09:37] jam, so i'll try it [09:38] yolanda: k, if you have any more questions, feel free to ask [09:40] jam, that worked! [09:40] woot [09:43] yolanda: i the default image type on openstack machines is 1core 1gb ram [09:44] jam: and mgz wrote this [09:44] they would be able to tell you [09:48] i just realised that i reviewed (comprehensively) entirely the wrong file [09:48] rogpeppe1: we'll still appreciate that review :) [09:48] tried a juju debug-log, having that error: http://paste.ubuntu.com/6009664/ [09:48] jam: i reviewed constraints.go [09:49] jam: (a small file, but with primitives used in quite a few places) [09:49] rogpeppe1: I can make that the assignment for next week :) I was going to do relations.go but constraints is worthwhile for the group, too. [09:49] * davechen1y looks [09:49] that url that it complains about, works nice in a browser [09:49] yolanda: could be sporadic [09:49] can you try again [09:49] yolanda: you can try a) swift list and b) just try juju debug-log again [09:54] jam, davechen1y, different answer now [09:54] jujy deploy --constraints="cores=4 mem=4G" $SERVICE [09:54] something like this should ask for a different instance [09:55] i forget if constraints are best fit or absolute match [09:55] rogpeppe1: you've got a review [09:55] TheMue: thanks! [09:55] yolanda: if you need more disk i *beleve* you get it by matching an instance type that has more cores and more ram [09:56] davechen1y: they should be a "minimum" so if there is only a 4-core 8G service we'll give it to you [09:56] jam: /me can't remember the instance types available on canonistack [09:56] TheMue: as I said in the description, the plan is to rename Sync to StartSync - i didn't want to confuse matters by doing it in this CL [09:56] yolanda, davechen1y: sidnei was putting together a patch to add a "root-disk" constraint to specify how much disk space the OS gets. But that isn't in a released version. (It might have landed and will be in 1.13.2, though) [09:57] jam, fwereade: i would very much appreciate your feedback on this CL https://codereview.appspot.com/13089045 [09:58]