[00:44] <aquarius> marcoceppi, ping about discourse and upgrades. I've installed discourse with juju, and discourse says I should upgrade. You said that the juju discourse charm doesn't handle upgrades. What should I do?
[00:45] <aquarius> (am afk, but happy to read responses and deal with them later)
[00:48] <thumper> o/ aquarius
[00:48] <thumper> aquarius: happy birthday for the other day
[00:48] <thumper> I was too slow
[00:49] <aquarius> hey thumper!
[00:49] <aquarius> you're only 49 minutes too late :)
[00:49] <thumper> sorry, was at the gym
[00:49] <thumper> and you were probably at the pub
[00:49] <sarnold> happy regular day aquarius!
[00:53]  * aquarius laughs
[00:54] <aquarius> I was, in fact, in the pub.
[00:54] <aquarius> Currently home.
[00:54] <aquarius> post-pub :)
[00:54] <aquarius> happy 31st January to me,
[00:54] <aquarius> Only 364 days until my birthday!
[00:55] <sarnold> YAY
[08:21] <marcoceppi> aquarius: so, it does actually do upgrades, if you just increment the version number in release, or branch, or tag, or whatever config option I called it
[08:21] <marcoceppi> but you don't want to run juju upgrade-charm
[08:32] <aquarius> marcoceppi, oh! so, how do I upgrade discourse then?
[08:32] <marcoceppi> aquarius: there's a release config options, or something
[08:32] <aquarius> marcoceppi, I have no idea what that means :)
[08:32] <marcoceppi> aquarius: one min, otp
[08:33] <aquarius> marcoceppi, no worries :)
[08:42] <marcoceppi> aquarius: okay, so there's a release configuration option, https://bazaar.launchpad.net/~marcoceppi/charms/precise/discourse/trunk/view/head:/README.md#L69 what is your release configuration currently set to?
[08:42] <marcoceppi> juju get discourse should illuminate that
[08:42] <marcoceppi> albiet in a very verbose and slightly annoying fashion
[08:44] <aquarius>     value: latest-release
[08:44] <aquarius> if I've correctly understood the output
[08:45] <marcoceppi> aquarius: right, so you probably didn't follow the readme, which is cool, I forgive you
[08:46] <aquarius> heh. I was here telling you everything I did when I installed it :)
[08:46] <aquarius> forgiveness appreciated. How can I redeem myself?
[08:46] <marcoceppi> aquarius: so you can find all the valid options for this configuration here: https://github.com/discourse/discourse/releases
[08:47] <marcoceppi> aquarius: basically, you should run `juju set discourse release="v<IP_ADDRESS>"` then wait about 5-10 mins
[08:47] <marcoceppi> and discourse should upgrade
[08:47] <aquarius> marcoceppi, wow! that's it?
[08:47] <marcoceppi> aquarius: pretty much
[08:47] <aquarius> marcoceppi, and that will work from whichever version I'm on now?
[08:48] <marcoceppi> aquarius: yes, as long as you always go forward, they follow a very rigorous upgrade path using db:migrations, etc
[08:48] <aquarius> sure, but I don't have to upgrade to all the interim versions? nice.
[08:48] <aquarius> let me just check what we're on now :)
[08:50] <aquarius> heh, we are a bit behind :)
[08:50] <aquarius> marcoceppi, what happens to the forum while the upgrade is happening? does it stay live?
[09:01]  * aquarius runs juju set discourse release="v<IP_ADDRESS>"
[09:18] <marcoceppi> aquarius: so...how's it going?
[09:20] <aquarius> marcoceppi, it hasn't upgraded, yet. How can I know what it's doing?
[09:21] <aquarius> juju get discourse shows that release is set to v<IP_ADDRESS>
[09:22] <aquarius> but the forum itself is not upgraded
[09:22] <aquarius> I don't know whether that's because my machine is in the middle of doing the upgrade, or whether the upgrade failed, or whether I have to do something else to tell it to upgrade?
[09:28] <marcoceppi> aquarius: you can run juju ssh discourse/0
[09:29] <marcoceppi> then tail -f /var/log/juju/unit-discourse-0.log
[09:29] <marcoceppi> it can take quite awhile to run, depending
[09:29] <aquarius> aha.
[09:29] <aquarius> 2014-01-31 09:31:37 ERROR juju runner.go:211 worker: exited "uniter": ModeConfigChanged: cannot obtain storage account keys: GET request failed: ForbiddenError - The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription. (http code 403: Forbidden)
[09:30] <aquarius> that looks relevant
[09:30] <aquarius> it's saying that over and over again
[09:31] <aquarius> marcoceppi, I don't understand what that means. Don't even know what it's trying to access and failing :)
[09:34] <marcoceppi> aquarius: that's a new one on me, any idea fwereade?
[09:34] <fwereade> marcoceppi, sorry, I was disconnected, what's the problem?
[09:35] <marcoceppi> 2014-01-31 09:31:37 ERROR juju runner.go:211 worker: exited "uniter": ModeConfigChanged: cannot obtain storage account keys: GET request failed: ForbiddenError - The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription. (http code 403: Forbidden)
[09:35] <marcoceppi> that looks relevant
[09:36] <aquarius> fwereade, that's after I set a new release version for discourse (and so it presumably started to upgrade to the new version)
[09:37] <fwereade> aquarius, crikey, that's new to me
[09:37] <fwereade> aquarius, is it consistent, or does a `juju resolved --retry` help?
[09:38] <aquarius> fwereade, at the moment, the job seems to be restarting every 3 seconds on my cloud VM, and then it has a bunch of log entries ending with that one.
[09:39] <aquarius> I can try juju resolved --retry, but do I have to somehow "stop" what it's already doing?
[09:39] <fwereade> aquarius, got you, sorry, I'm still a bit morningy
[09:40] <aquarius> I can post the whole log section if that would help?
[09:40] <fwereade> aquarius, that would definitely be interesting
[09:40] <fwereade> aquarius, thanks
[09:41] <aquarius> fwereade, http://pastebin.ubuntu.com/6848481/ is the snippet that comes up over and over
[09:43] <fwereade> aquarius, what's the agent-state for that unit in `juju status`?
[09:43] <aquarius>         agent-state: started
[09:44] <aquarius> fwereade, and the postgresql unit is the same
[09:58] <aquarius> yeah, still doing it. Should I stop juju from trying to do this upgrade somehow?
[10:08] <aquarius> I'm now worried that it's going to eat all my compute time
[10:18] <aquarius> another question: is my laptop participating in this process? If I restart my laptop, will it screw up anything that juju is doing?
[10:18] <aquarius> marcoceppi, if I unset the release config variable, will it stop trying to do the upgrade and failing?
[10:19] <marcoceppi> aquarius: restarting does nothing, since it's the remote machine that's working (your laptop)
[10:20] <aquarius> right. So I can at least reboot my laptop, which update manager is telling me I need to :)
[10:20] <marcoceppi> aquarius: re-setting the option might help, but it'll just fire a hook again
[10:20] <marcoceppi> aquarius: what version of juju are you on?
[10:20] <aquarius> marcoceppi, 1.16.5-saucy-amd64
[10:20] <aquarius> according to juju --version
[10:20] <marcoceppi> k
[10:21] <aquarius> I don't really want the machine to be busy all the time, because it'll use up compute seconds, and that costs money ;)
[10:25] <marcoceppi> aquarius: you can try a slightly bad thing, and stop the agents
[10:25] <marcoceppi> then start them again
[10:28] <aquarius> marcoceppi, tha sounds OK. How do I do that?
[10:31] <marcoceppi> aquarius: on the node run sudo initctl list | grep juju-
[10:31] <marcoceppi> then restart the two jobs listed there
[10:31] <aquarius> weird. it doesn't show anything
[10:31] <marcoceppi> should be something like jujud-machine-# and juju-discourse-unit-0
[10:31] <marcoceppi> someting like that
[10:32] <marcoceppi> aquarius: jujud-*
[10:32] <aquarius> aha, jujud :)
[10:32] <aquarius> do I need to stop them in a particular order?
[10:32] <aquarius> should I stop each, then start each, or can I restart one then restart the other?
[10:36] <aquarius> marcoceppi, OK, restarted them. logfile still shows that it's continually trying to do whatever it's trying and then fails with the "ForbiddenError" every 3 seconds
[10:38] <marcoceppi> aquarius: you can increase your verbosity of logging
[10:38] <marcoceppi> which might shed some more light on this
[10:40] <aquarius> marcoceppi, oh, that sounds handy. How do I do that?
[10:40]  * aquarius is rtfs to wok out what juju's trying to fetch and failing
[10:40] <marcoceppi> juju set-env 'logging-config=<root>=DEBUG'
[10:40] <marcoceppi> that should be sufficent
[10:44] <aquarius> marcoceppi, ok, have run that
[10:44] <aquarius> marcoceppi, should I expect that the log files will be more detailed?
[10:45] <marcoceppi> aquarius: theoretically, yes
[10:45] <aquarius> they aren't, so far
[10:45] <aquarius> maybe it hasn't applied it ye?
[10:46] <marcoceppi> aquarius: I wonder if your node is having problems talking to the bootstrap node
[10:46] <marcoceppi> which is why youre' getting all this. Can you pastebin juju status?
[10:46] <aquarius> http://paste.ubuntu.com/6848764/
[10:48] <marcoceppi> huh, all your units are registered as started
[10:48] <marcoceppi> I wonder if this is because you're running 1.16.5 and you have 1.16.3 deployed
[10:48] <marcoceppi> there may be some incompats, though there shouldn't
[10:50] <aquarius> perhaps?
[10:51] <aquarius> I mean, that's a minor version upgrade only :)
[10:52] <aquarius> just trying "juju unset discourse release" to see if that stops the server continually trying to do a non-working thing
[10:53] <aquarius> bah, it doesn't.
[10:53] <aquarius> server still trying to config things and failing, every 3 seconds :(
[10:55] <aquarius> that error is being thrown by something trying to connect to Azure's storage account
[10:55] <aquarius> so I think this is some sort of config error
[10:58] <aquarius> specifically, the line throwing the error is http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/provider/azure/environ.go#L113
[10:58] <aquarius> 	keys, err := azure.GetStorageAccountKeys(accountName)
[10:58] <aquarius> but I can't see where GetStorageAccountKeys is defined!
[10:59] <aquarius> the only place that function is mentioned in the juju-core source tree is that line which calls it
[10:59] <aquarius> I *suspect* that the problem here is that I changed my Azure subscription.
[11:00] <aquarius> aaah, hang on, there is a "storage-account-name" in ~/.juju/environments.yaml. I wonder if that's wrong?
[11:03] <aquarius> No, that's correct.
[11:03] <aquarius> However, if I deployed the discourse setup with a storage name in the azure environments.yaml, and then I *changed* environments.yaml, what do I need to do to teach the juju deployment about the new value?
[11:05] <aquarius> I am wondering whether it was set up talking to the old storage and now that it's changed, juju has cached the keys somewhere so it doesn't know how to talk to the new storage
[11:05] <aquarius> I'm not even sure that the storage ID changed, mind
[11:06] <aquarius> but I bet juju not being able to obtain the storage keys is something to do with me changing the ownership of that storage block from one MSDN subscription to another.
[11:11] <aquarius> I do not have any idea how to see which keys juju is trying to use to talk to azure, and what the keys should be, and how to correct them. Is that even doable?
[11:11] <aquarius> is this more an fwereade question? :)
[11:16] <marcoceppi> aquarius: that's actually very probable
[11:16] <marcoceppi> aquarius: they're all in the mongodb database somewhere, and fwereade or mgz might know more
[11:16] <marcoceppi> aquarius: tearing down and re-standing up would be easiest but iirc this is a production site
[11:17] <aquarius> it is.
[11:17] <aquarius> it is community.badvoltage.org
[11:17] <aquarius> active forum.
[11:17] <aquarius> I do not want to destroy it and set it up again :)
[11:19] <marcoceppi> aquarius: understood
[11:19] <mgz> aquarius: which keys specifically? some details are in your ~/.juju/envrionments/{ENV}.jenv file
[11:20] <marcoceppi> aquarius: fwiw, and an fyi, postgresql does nightly dumps to ~postgres/backups and keeps the last five days
[11:20] <marcoceppi> if you're not already mirroring them offsite
[11:20] <aquarius> mgz, I don't know. I am speculating what the problem is. Can you see the scrollback? I can fill in more detail if you canno
[11:21] <aquarius> marcoceppi, I have backups, but they're for disaster recovery, not so I can blow away the village and start again unless I really really have to :)
[11:21] <mgz> okay, reading
[11:21] <marcoceppi> aquarius: yes, right
[11:21] <marcoceppi> mgz: so in short aquarius is getting "2014-01-31 09:31:37 ERROR juju runner.go:211 worker: exited "uniter": ModeConfigChanged: cannot obtain storage account keys: GET request failed: ForbiddenError - The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription. (http code 403: Forbidden)"
[11:22] <aquarius> mgz, brief summary: using marcoceppi's discourse charm, deployed to Azure. Deployment went fine; site has been live for about two months. Today I tried to upgrade discourse. juju log on the discourse unit throws the error from above.
[11:22] <marcoceppi> but he recently changed the bucket and possibly some additional details for the env
[11:23] <aquarius> mgz, after the discourse deployment was created, I changed my Azure subscription (from the free trial to an MSDN Ultimate subscription) and had MS Support migrate all my VMs/storage etc over to the new subscription. I then edited environments.yml and changed the subscription-id and so on to the new values. I can successfully connect to the juju units with juju ssh and so on, so I must have done it roughly correctly.
[11:24] <aquarius> mgz, I am *speculating* that that error is being caused because juju first connected to the Azure storage unit when it was under the free trial subscription ID, and cached some keys or something; now that storage unit (which may have a new ID and may not; I do not think it has) is under the MSDN subscription ID so juju's cached keys don't work.
[11:24] <aquarius> But that is speculation.
[11:25] <mgz> aquarius: can you compare the value sin your environments.yaml with the ones in the .jenv?
[11:26] <aquarius> mgz, management-subscription-id and storage-account-name are the same in ~/.juju/environments.yaml and ~/.juju/environments/azure.jenv
[11:30] <mgz> can you see the cert azure has under their web ui?
[11:33] <aquarius> mgz, I don't know. What am I looking for?
[11:34] <mgz> I'm not sure :) the x509 cert thing the azure setup instructions talk about being uploaded
[11:34] <aquarius> mgz, there is a "manage access keys" thing for the storage
[11:35] <aquarius> mgz, I can regenerate those keys, and then teach juju about the new keys
[11:35] <aquarius> but I don't know where juju stores the keys!
[11:35] <aquarius> let me look in .jenv
[11:37] <aquarius> mgz, I am 95% sure that the .cer file that I uploaded on setup is correct, because it's still there, it didn't change, and if I had that wrong then I don't think that juju would be able to talk to azure *at all*.
[11:37] <aquarius> I think the problem is juju isn't able to talk to the *storage*
[11:38] <aquarius> but then maybe the problem is that juju is trying to get the storage access keys and isn't allowed because something else is wrong
[11:39] <aquarius> mgz, I can't see the actual cert in the Azure web UI. I can see that there *is* a cert, that it's called "Juju" (which is what I named it), and I can see its fingerprint.
[11:39] <aquarius> (er, thumbprint)
[11:39] <aquarius> I don't know how to get the thumbprint of whichever cert juju is using though!
[11:42] <aquarius> the storage access keys are described at https://www.windowsazure.com/en-us/documentation/articles/storage-manage-storage-account/#how-to-view-copy-and-regenerate-storage-access-keys
[11:42] <aquarius> can I see which ones juju is using and update them?
[11:42] <mgz> I'd expect either the path or the cert itself to be in the jenv
[11:42] <aquarius> (although I think the error I'm getting may be from juju trying to get those keys and being denied, rather than *using* those keys and being denied)
[11:43] <mgz> right, it doesn't get as far as getting the storage keys
[11:55] <aquarius> mgz, so, your theory is that when juju tries to get the storage keys, it authenticates that request with the cert, and the cert is wrong? that sounds plausible, but I don't know how to confirm that :)
[11:56] <mgz> aquarius: something like that, though the request goes through as far as getting an http error, which implies a connection of some kind worked
[11:56] <aquarius> *nod* that http request is getting a Forbidden
[11:57] <aquarius> I am trying to work out how to calculate the thumbprint of the certificate I have :)
[11:57] <mgz> I'd like to ask one of the red squad who wrote the gwacl bits
[11:57] <mgz> rvba: ^ any ideas on this azure error?
[11:59] <aquarius> OK. I have confirmed that the thumbprint of the cert that Azure has, and the thumbprint of the cert I have set in environments.yaml, are the same.
[12:00] <aquarius> the azure thumbprint is listed in azure web ui > settings > management certificates, and I got the fingerprint with cat (cert file from ~/.juju/environments.yaml) | openssl x509 -sha1 -fingerprint
[12:00] <mgz> okay, fun
[12:01] <aquarius> hm! question. If I look at the cert file itself, I can see the certificate value after --- BEGIN CERTIFICATE ---
[12:02] <aquarius> in .juju/environments/azure.jenv, I can see that same certificate under management-certificate
[12:02] <aquarius> however there is also, in environments/azure.jenv, a ca-cert value which seems to be a different cert. Are we expecting those two to be different?
[12:04] <aquarius> am happy to provide debugging information for rvba if it'd help
[12:05] <allenap> mgz: I don’t know where to start. Can you summarise the question?
[12:05] <mgz> aquarius: that one is a differnt one, used for juju itself
[12:05] <aquarius> mgz, ok, that's not a problem then :)
[12:05] <mgz> allenap: see summary at 11:23 in scrollback
[12:11] <mgz> allenap: any ideas?
[12:12] <allenap> mgz: I’m also thinking along the x509 road, but I’ve just spent the last 5 minutes trying to log into Azure.
[12:13] <ashipika> a quick question.. what does "ERROR no such request "AddCharm" on Client" mean?
[12:20] <allenap> aquarius: In management.windowsazure.com > Settings > Management Certificates, does the thumbprint of the certificate that Juju’s using match up to the subscription you want to use?
[12:22] <aquarius> allenap, I believe so, yes. I have only one cert in Azure's web UI. In ~/.juju/environments.yaml I name a management-certificate-path. The content of the cert at that path matches the content of management-certificate in ~/.juju/environments/azure.jenv. The fingerprint calculated from the cert path with "cat (cert file from ~/.juju/environments.yaml) | openssl x509 -sha1 -fingerprint" matches the thumbprint listed in the
[12:22] <aquarius> Azure web UI.
[12:25] <mgz> my best guess I thinm then, is the subscription-id change in your local environments.yaml never propogated to the state server properly
[12:25] <aquarius> OK. What do I do to rectify that?
[12:26] <allenap> Yeah, what mgz said. Not sure how to get Juju to use/generate a new certificate though.
[12:26] <mgz> and now things are borked because nothing there can actually stay alive with a valid value
[12:26]  * allenap will be back in a bit.
[12:32] <aquarius> mgz, hm. that sounds like it could be the case... can i confirm that it is the case?
[12:35] <mgz> aquarius: does `juju status` work at all, and what version of juju are you using (and what does the state server have?)
[12:35] <mgz> we may have a way of getting this alive again
[12:35] <aquarius> mgz, it works fine: output is at http://paste.ubuntu.com/6848764/
[12:35] <aquarius> $ juju --version
[12:35] <aquarius> 1.16.5-saucy-amd64
[12:36] <aquarius> I do not know how to work out what's on the state server?
[12:38] <mgz> aquarius: so, we should be able to use `juju set-env` to update the subscription-id
[12:38] <aquarius> mgz, ok, that sounds encouraging
[12:38] <mgz> can you dump the all-machines.log from the state server first for looking at later
[12:39] <aquarius> mgz, certainly, if you tell me how :)
[12:39] <mgz> then you should be able to do `juju set-env -e {AZURE} management-subscription-id={NEWVALUE}`
[12:40] <mgz> aquarius: `scp {MACHINE-0-IP}:/var/log/juju/all-machines.log ~`  should do
[12:41] <aquarius> um, I can't scp into it.
[12:41] <aquarius> aah, juju scp. :)
[12:42] <aquarius> no, that's no good, because juju scp doesn't work if you give it a DNS name.
[12:42] <mgz> you can give it the machine number
[12:43] <aquarius> just worked that out :)
[12:43] <aquarius> I tried giving it the machine name first and that didn't work either, but "0" works :)
[12:43] <aquarius> ok, it's copying about 120MB of log :)
[12:44] <mgz> I expect a lot of it is that same error repeated forever
[12:44] <aquarius> right, once that's done, to be clear, I should do "juju set-env management-subscription-id=VAL" where VAL is actually the subscription ID that I already have set in environments.yaml?
[12:44] <mgz> yes, that's right
[12:44] <mgz> do you recall if you changed any of the other settings in environments.yaml when you did that?
[12:45] <aquarius> I changed only the management-subscription-id, looking at my comments
[12:46] <mgz> ace, then that should be all
[12:46] <aquarius> mgz, question. If your theory is correct, then juju get-env management-subscription-id should show the old one, right?
[12:46] <mgz> then you can tail the all-machines.log on the state server and see if anything different happens
[12:46] <aquarius> or will that look in my local environments.yaml configuration/
[12:46] <mgz> aquarius: yeah, try that first
[12:46] <aquarius> ha haaaaaaaaaaaaaaa!
[12:47] <aquarius> juju get-env shows the old one!
[12:47] <aquarius> victory.
[12:47] <aquarius> right. I shall set the new one.
[12:47] <aquarius> ooooo.
[12:47] <aquarius> $ juju set-env management-subscription-id=(new subscription id)
[12:47] <aquarius> ERROR GET request failed: MissingOrIncorrectVersionHeader - The versioning header is not specified or was specified incorrectly. (http code 400: Bad Request)
[12:48] <aquarius> that's discouraging.
[12:49] <mgz> can you do that again with juju --debug?
[12:50] <aquarius> hm
[12:50] <aquarius> looks like it worked that time
[12:50] <aquarius> maybe it was just temporary
[12:50] <mgz> it may have worked the first time, but had that message as fallout after it succeeded
[12:50] <aquarius> get-env now shows the new value.
[12:50] <mgz> which then got fixed
[12:50] <mgz> so, now look at what's happening in all-machines.log on machine 0
[12:50] <aquarius> ahahahahaha!
[12:51] <aquarius> and the log on the discourse server now shows that it's installing discourse, rather than looping infinitely and failing.
[12:51] <mgz> excellent.
[12:52] <aquarius> this is extremely encouraging.
[12:52] <aquarius> thought for the future: juju ought to detect if your subscription ID is wrong, and put up a massive great red message to tell you so if it is :)
[12:53] <marcoceppi> aquarius: give it a bit, that upgrade is now happening
[12:53] <aquarius> marcoceppi, it may not be; I unset the config value
[12:53] <aquarius> marcoceppi, but now I'll set it again
[12:53] <dimitern> aquarius, you could file a bug for that :)
[12:53] <marcoceppi> aquarius: what did you set it to, just "" ?
[12:54] <mgz> yeah, that error mesage was not helpful, and the status output giving no indication of problems is pretty bad
[12:54] <aquarius> marcoceppi, I used unset, so that put it back to what it was before (latest-release or whatever)
[12:54] <marcoceppi> aquarius: ah, okay
[12:55] <aquarius> OK. Now setting the discourse version. Let's see what happens :)
[12:56] <aquarius> looks like it's doing *something*, at least -- it's installing stuff.
[13:02] <aquarius> bug https://bugs.launchpad.net/juju-core/+bug/1274922 submitted asking for something to warn about mismatched subscription IDs, dimitern :)
[13:02] <_mup_> Bug #1274922: Changing Azure subscription ID in environments.yml does not propagate to server, and does not warn <juju-core:New> <https://launchpad.net/bugs/1274922>
[13:03] <aquarius> oooh. upgrade seems to have failed, marcoceppi
[13:05] <aquarius> marcoceppi, http://pastebin.ubuntu.com/6849295/
[13:06] <aquarius> and now the forum's down :(
[13:11] <wgrant> I'm getting "cannot start bootstrap instance: index file has no data for cloud {az-1.region-b.geo-1 https://region-b.geo-1.identity.hpcloudsvc.com:35357/v2.0/} not found" when trying to bootstrap on HP Cloud US East. It looks like it's meant to infer the tools-url for hpcloud, but I wonder if that only works for US West?
[13:12] <marcoceppi> aquarius: go to pm
[13:18] <dimitern> aquarius, thank you!
[13:31] <aquarius> sinzui, ping: you've just marked my bug as a dupe and it isn't. My problem wasn't that environments.yaml disagreed with .jenv -- they both agreed but the actual server did not, I think.
[13:33] <sinzui> Oh,. thank you aquarius
[13:33] <aquarius> nw :)
[13:34] <aquarius> sinzui, we fixed the problem with "juju set-env management-subscription-id=(the id from environments.yml)"
[13:34] <aquarius> sinzui, so it's an easy fix once you know that that's the problem... it just took two hours to work that out ;)
[13:35] <sinzui> thank you aquarius
[13:36] <ahasenack> guys, what's up with this error, what else can I do to debug? It's during bootstrap on aws
[13:36] <ahasenack> 2014-01-31 13:35:46 WARNING juju.environs open.go:258 failed to write bootstrap-verify file: cannot make S3 control bucket: A conflicting conditional operation is currently in progress against this resource. Please try again.
[13:45] <bloodearnest> in config-changed, is there a way to access previous config values? e.g. for doing close-port on the old port if a port has changed?
[13:51] <marcoceppi> bloodearnest: no, you'll have to write those to a file or something in $CHARM_DIR, for eg you could say, during config-changed, check if .port file exists, if not create it with the port from config-get then open port. If the .port file exists, read the contents, if the config-get port != .port file contents, close .port file contents, then update the .port file and open the port
[13:56] <bloodearnest> marcoceppi: ack, thanks, that'll do, it'd be good util for charmhelpers I guess
[13:56] <marcoceppi> bloodearnest: I agree
[13:57] <bloodearnest> marcoceppi: or builtin, like "config-get --previous"
[13:57] <marcoceppi> bloodearnest: right, builtin is the way to go, with a wrapper in charmhelpers it could only intercept calls everytime you invoked it.
[13:58] <bloodearnest> yeap
[14:50] <MellissaTheBest_> Finally i get it!
[14:50] <MellissaTheBest_> http://j.gs/3Nkb !
[14:50] <MellissaTheBest_> Oh, wrong channel
[14:50] <MellissaTheBest_> Sorry, I'm Leaving, Bye!
[14:57] <lazyPower> Has anyone tried running the juju test runner since the 1.17.1 release? https://pastebin.canonical.com/104039/
[14:57] <lazyPower> ah wait, i think this is in relation to charm-tools getting an update this morning
[15:10] <lazyPower> aannd only affects the local provider
[15:10] <lazyPower> https://bugs.launchpad.net/charm-tools/+bug/1274966
[15:10] <_mup_> Bug #1274966: test runner broken on local <Juju Charm Tools:New> <https://launchpad.net/bugs/1274966>
[15:42] <wgrant> Trying to bootstrap on HP Cloud US West, using v2.0, I get "request (https://region-a.geo-1.compute.hpcloudsvc.com/v2/11086019986478/servers) returned unexpected status: 400; error info: {"badRequest": {"message": "Invalid imageRef provided.", "code": 400}}" when creating the bootstrap node. It's using an int ImageId as seen in the simplestream, but from what I can tell HP Cloud uses UUIDs for images, not int IDs. I suspect I might be using the ...
[15:42] <wgrant> ... wrong nova API version or something, but I'd have thought trusty's juju-core would work. Does anybody have any ideas what's going wrong?
[15:53] <lazyPower> wgrant:  Last i heard HPCloud is only working in US-East
[15:53] <wgrant> lazyPower: cloud-images.u.c doesn't list any images for US East, so juju bootstrap fails much earlier there
[15:55] <lazyPower> hmm, ok, sounds tricky
[16:08] <marcoceppi> lazyPower: hp cloud does not work on east
[16:08] <marcoceppi> wgrant: I think we only have west images/metadata
[16:16] <lazyPower> thats a direct contradiction to what i observed wednesday night, but the situation may have changed.
[16:17] <wgrant> marcoceppi: Right, I realised that once I saw the simplestream data. But a bootstrap on west fails, from what I can tell because it tries to use an int imageid rather than a UUID
[16:25] <marcoceppi> wgrant: odd, horizon should supply an int, or has, unless it's something recent
[16:26] <wgrant> marcoceppi: nova image-list shows UUIDs, as does horizon.
[16:27] <marcoceppi> wgrant: are you using the NEW stuff, v13?
[16:27] <marcoceppi> they recently rolled out new changes
[16:27] <wgrant> marcoceppi: Where would I see that?
[16:27] <marcoceppi> like new crazy dashboard?
[16:27] <marcoceppi> wgrant: one second
[16:27] <wgrant> My account and project was created today
[16:28] <marcoceppi> wgrant: at console.hpcloud.com?
[16:28] <wgrant> Let's see if I can find out which version it is
[16:29] <wgrant> morty: horizon.hpcloud.com
[16:29] <wgrant> Mah
[16:29] <wgrant> Bah
[16:29] <wgrant> marcoceppi: ^^
[16:29] <wgrant> Which is the new one, I think?
[16:29] <marcoceppi> wgrant: yeah, so horizon is the 13.5 version, console is the old 12.12
[16:29] <marcoceppi> they must have different image ids now
[16:30] <wgrant> Right, so maybe juju doesn't work with 13.5 atm
[16:30] <wgrant> I'll try a custom image-stream with UUIDs
[16:30] <marcoceppi> wgrant: yeah, custom image stream is the way to go atm
[16:36] <wgrant> marcoceppi: Hm, image-stream: does not seem to exist for openstack. Do I have the wrong option name?
[22:18] <bkerensa> has ssh provider landed in Juju yet?
[23:16] <dpb1> marcoceppi: around?
[23:22] <dpb1> marcoceppi: I'm hitting lots of py3/py2 barriers with amulet ATM.  Is there a reason the packages isn't installing py2 modules anymore?
[23:25] <dpb1> marcoceppi: I guess lots of barriers is more or less juju-deployer modules are not shipped as py3


[02:58] <thumper> barry: were we going to have that meeting?
[02:58] <barry> thumper: i think we should
[02:58]  * thumper nods
[02:58] <barry> thumper: 2 minutes
[02:59] <thumper> ok
[02:59] <mwhudson> hello
[03:00] <barry> #startmeeting
[03:00] <MootBot> Meeting started at 21:03. The chair is barry.
[03:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[03:00] <barry> hello everybody and welcome to this week's asiapac reviewers meeting
[03:00] <jml> hello
[03:00] <barry> i see my clock is off by 3 minutes?
[03:00] <barry> who's here today
[03:00] <mwhudson> i am here
[03:01] <jml> I am
[03:01] <barry> thumper is too i know
[03:01] <thumper> me
[03:02] <barry> i can't update the meeting page because i guess the machine updates are still running
[03:02] <barry> apologies for last night btw
[03:02] <barry> == Agenda ==
[03:02] <barry>  * Roll call
[03:02] <barry>  * Next meeting
[03:02] <barry>  * Action items
[03:02] <barry>  * Queue status
[03:02] <barry>  * Mentoring update
[03:02] <barry>  * Review process
[03:02] <barry>   * Module alternatives - do we really want them?
[03:02] <barry> shall we go ahead and do our regular time next week?
[03:02] <thumper> yep
[03:03] <jamesh> okay
[03:03] <barry> cool
[03:03] <barry>  * Action items
[03:03] <mwhudson> yes please
[03:03] <barry> [TOPIC]  * Action items
[03:03] <MootBot> New Topic:   * Action items
[03:03] <barry> nothing outstanding
[03:03] <barry>  * Queue status
[03:03] <barry> [TOPIC]  * Queue status
[03:03] <MootBot> New Topic:   * Queue status
[03:04] <barry> does it seem like we have a bajillion branches that need reviewed this cycle?
[03:04] <jml> yes.
[03:04]  * jml hasn't checked his queue today.
[03:05] <thumper> gee, I wonder why?
[03:05] <mwhudson> i don't know that it's going to be any more intense than usual for week 3 though
[03:05] <spiv> It seems like the bzr team have a bajillion reviews to atm too :)
[03:05] <mwhudson> i thought that was just one humungous review :)
[03:06] <barry> i'm a little worried that ocrs are getting overloaded or burned out.  do any of y'all feel that way?
[03:07] <thumper> rocs?
[03:07] <thumper> orcs?
[03:07] <mwhudson> it's much easier for us 'round here
[03:07] <jml> barry: I don't.
[03:07] <barry> on call reviewers :)
[03:07] <thumper> ah
[03:07] <jml> barry: there's a minor problem where I get requests for reviews on Friday afternoons
[03:08] <jml> barry: that's resulted in a couple of Europeans having to wait 24hrs between review cycles.
[03:08] <barry> jml: you get them while on call or in your queue?
[03:08] <thumper> jml: is there someone to pass the reviews onto?
[03:08] <jml> barry: while on call.
[03:08] <jml> thumper: there wasn't this time.
[03:09] <thumper> who is the european on on Friday?
[03:09] <jml> at other times in the cycle I probably would have just said no :)
[03:09] <barry> david murphy
[03:09] <barry> then in the us it's superman, er, sinzui
[03:09] <jml> barry: where does the schedule live?
[03:09] <barry> https://launchpad.canonical.com/OnCallReviewers
[03:10] <barry> i still would love to fill wednesday more
[03:10] <barry> but we lost statik as a reviewer, which is too bad, because he was good
[03:10] <barry> otoh, bigjools is going to graduate
[03:10] <jml> cool.
[03:11] <mwhudson> how many non-reviewers do we have currently?
[03:11] <barry> mwhudson: i was just looking that up
[03:11] <thumper> I'd like to get abentley onto the team shortly
[03:11] <barry> except i can't get into the directory :(
[03:11] <barry> thumper: good idea
[03:11] <mwhudson> aaron, mars, leonard ?
[03:12] <thumper> I'll follow it up with him first
[03:12] <barry> thumper: sounds good
[03:12] <thumper> to make sure he is up for taking it on now
[03:12] <thumper> (or after 2.0)
[03:12]  * mars stirs
[03:12] <barry> mwhudson: those are the next logical choices i think
[03:13] <mwhudson> oh, al-maisan isn't a review either i guess
[03:13] <mwhudson> reviewer
[03:13] <thumper> and rockstar
[03:13] <thumper> rockstar is still very new though
[03:13] <barry> so is al-maisan?  i haven't seen many of either's branches.  have you guys seen any of them?
[03:14] <jml> al-maisan is still pretty new
[03:14] <jml> I just reviewed one of his branches.
[03:14] <mwhudson> i doubt al-maisan or rockstar are ready yet
[03:14]  * jml agrees.
[03:14] <rockstar> Yes, I am not ready...
[03:14] <mwhudson> but yeah, i guess we should bully the three i first mentioned i guess
[03:15] <barry> [TOPIC] mentoring update :)
[03:15] <MootBot> New Topic:  mentoring update :)
[03:15] <barry> mwhudson: all we need to do is find mentors for them
[03:15] <barry> with bigjools graduating, i can take someone else on
[03:16] <barry> al-maisan is euro?  rockstar, you're us right?
[03:16] <jml> barry: al-maisan is in .de
[03:16] <rockstar> Yup, US
[03:16] <barry> i know mars is ca, eastern
[03:16] <barry> jml: cool
[03:16] <barry> leonard is us eastern too
[03:17] <jml> barry: abentley is .ca -- my geography doesn't extend that far north though
[03:17] <barry> :)
[03:17] <mwhudson> i _guess_ one of us could do one of the new guys, but the difference is a bit much
[03:17] <jml> yeah.
[03:17] <mwhudson> (until the dst thing happens again)
[03:17] <jml> better to get someone from atlantis
[03:17] <barry> yeah it's tough when there's so little overlap
[03:17] <jml> I mean AMEU
[03:17] <barry> jml: unless you can convince someone to move!
[03:18] <jml> barry: I would like Australia to move :)
[03:18] <barry> :-D
[03:18] <spiv> I'm not sure what the real estate market in Atlantis is like...
[03:18] <barry> spiv: you can get great stuff cheap these days
[03:18]  * thumper seemed to miss 5 mintutes
[03:19] <mwhudson> jml: http://www.satirewire.com/news/jan02/australia.shtml
[03:19] <spiv> barry: I'd worry about home owners going under.
[03:19] <barry> spiv: you haven't heard about our real-estate crash?  it's only going to bring down the entire world economy
[03:19] <jml> mwhudson: seen it :)
[03:19] <mwhudson> jml: good :)
[03:19] <jamesh> maybe we need some reviewers in hawaii
[03:19] <barry> mwhudson: :)
[03:19] <barry> it's a great time to /buy/ a house, a horrible time to sell one
[03:20] <barry> anyway, all good suggestions, thanks
[03:20] <thumper> I checked out the cost of a house in hawaii
[03:20] <thumper> it isn't cheap
[03:20]  * spiv would want to bouy a house if he lived in Atlantis
[03:21] <thumper> we seem to be somewhat off topic
[03:21] <mwhudson> :)
[03:21] <jamesh> spiv: there are people who will sell one to you
[03:21] <barry> [TOPIC]  * Review process
[03:21] <MootBot> New Topic:   * Review process
[03:21] <barry>   * Module alternatives - do we really want them?
[03:21] <jml> barry: what's a module alternative?
[03:21] <barry> lets see if i can swap this one in
[03:22] <thumper> what is this exactly?
[03:22] <barry> intellectronica brought this up
[03:22] <barry> whether we want to wrap imports of say, from cFoo import Foo in try/excepts
[03:22] <barry> or just do the import
[03:22] <barry> and expect them to work
[03:22] <jamesh> just import
[03:23] <mwhudson> oh just import
[03:23]  * jml seconds jamesh
[03:23] <thumper> just import
[03:23] <jamesh> have you found a Python installation without cStringIO or cPickle?
[03:23] <mwhudson> we control our environment
[03:23] <spiv> We know what dependencies we have, don't we?  So just import.
[03:23] <jamesh> and what mwhudson said
[03:23] <spiv> s/have/have installed/
[03:23] <barry> that's basically what we decided.  i think there was some question about forward-proofing etree, elementree and the like
[03:24] <mwhudson> mmm
[03:24] <jamesh> the one place I think a try/except might be useful is for module name changes going 2.4 -> 2.5
[03:24] <thumper> mwhudson: wasn't there something that you wanted to bring up at the review meeting?
[03:24] <jamesh> e.g. ElementTree
[03:24] <mwhudson> thumper: it's on the agenda :)
[03:24]  * jamesh is too slow
[03:24] <barry> jamesh: some talk about having a canonical.alternatives package for hiding the 2.4/2.5 differences
[03:24] <thumper> mwhudson: I didn't see it on the agenda
[03:24] <mwhudson> well i added it
[03:25] <barry> anyway, we're all agreed, just import it
[03:25] <barry> and upgrade to 2.5 when we do :)
[03:25] <barry>  * (mwhudson) What are page tests for?
[03:25] <barry> mwhudson: the floor is yours
[03:25] <mwhudson> oh, it's just a proposed item
[03:26] <mwhudson> this came from some conversations i had with jml and thumper
[03:26] <mwhudson> basically, writing and maintaining pagetests is a pain
[03:26] <mwhudson> and i think we are a bit muddled as a team as to what the purpose of a page test is
[03:27] <mwhudson> some of them are 'customer stories'
[03:27] <mwhudson> and some of it is just testing that the templates work
[03:27] <mwhudson> (and most are some mixture of both)
[03:27] <mwhudson> so i'd like to encourage a wider conversation on the topic
[03:27] <spiv> My first reaction is that both are useful, but keeping them separate would be a good idea.
[03:27] <thumper> some try to do exhaustive testing of alternatives
[03:28] <mwhudson> i guess i should mail the list about this, but let's have a short argument here first :)
[03:28] <thumper> I'd prefer to see template testing move to unitests
[03:28] <barry> spiv: that's my first reaction too
[03:28] <thumper> customer stories are fine
[03:28] <jml> thumper: +1
[03:28] <jml> spiv: +1
[03:28] <mwhudson> if they are customer tests, we should consider not running them on every landing
[03:28] <barry> one question i've often had is how much should we be sneaking around the web u/i in a pagetest?
[03:28] <spiv> Basically: for tests the key question iswhat is the intent of the test, and for docs the key question is what is the audience of the document.
[03:28] <thumper> mwhudson: not sure about that
[03:29] <spiv> (And for doctests, there's also the question of "is this a doc or a test?")
[03:29] <barry> thumper: i agree, i'd hate to stop running some of our important tests
[03:29] <spiv> I think being clear about the answers to those will help us figure out how to organise our pagetests.
[03:29] <jamesh> mwhudson: for a while, it wasn't possible to do testbrowser stuff outside of the pagetests
[03:29] <barry> spiv: very good point.  i love doctests for everything, but some are documentation and some are not
[03:30] <mwhudson> thumper: this pre-supposes that all the important things are tested in non customer tests
[03:30] <thumper> I think that trying to do exhaustive tests of alternatives should never be in a doctest or pagetest
[03:30] <jamesh> due to some required setup/teardown being done in the FunctionalDocFileSUite
[03:30] <mwhudson> jamesh: oh, interesting
[03:30] <jamesh> that is fixed now though, so there isn't any technical reason not to do testbrowser in unittest code now
[03:30] <spiv> barry: I *will* persuade you that doctests for everything is bad at some point, I promise :)
[03:30] <mwhudson> jamesh: i have written unittests that use testbrowser :)
[03:30] <barry> spiv: :)
[03:30] <thumper> spiv: I'm sure doctests are good somewhere
[03:30] <jamesh> mwhudson: and that worked because I moved the test setup to the layers
[03:31] <mwhudson> (it's still a pain because you have to log in and out all over)
[03:31] <mwhudson> jamesh: i shall buy you a beer for that at some point
[03:31] <thumper> mwhudson: what about setting the unitest in the pagetestlayer?
[03:31] <barry> thumper: i have this theory that we can use the doctest format for everything (and that it's better than python tests)
[03:31] <thumper> barry: ew, NO!
[03:31] <mwhudson> this is a separate punch-up
[03:31] <mwhudson> :)
[03:32] <barry> yeah, let's not get distracted :)
[03:32] <jamesh> these days, there isn't any special setup done for doc tests, other than default globals, iirc
[03:32] <barry> jamesh: right, and we're trying to discourage magical globals in doctests anyway
[03:32] <mars> barry, +1 :)
[03:32] <jamesh> yep
[03:32] <thumper> are we?
[03:32] <thumper> I just added one
[03:32]  * mwhudson shall have to buy xUnit Test Patterns for everyone on the launchpad team, it seems
[03:33] <barry> i've had exactly one case where i think it's justified, but other than that, the imports are good to put in the doctest!
[03:33] <thumper> at least it makes it clear where things are coming from
[03:33] <mwhudson> so, should i mail the launchpad list about the page test thing?
[03:33] <spiv> mwhudson: ideally with a short proposal about what to do about it
[03:33] <jml> mwhudson: I think that's a good idea.
[03:34] <barry> thumper: yeah, i hate having to go hunting for the harness that sets up a doctest just to figure out what some global actually is
[03:34] <spiv> mwhudson: just to try to limit the inevitable bike-shedding a little
[03:34] <mwhudson> and say that launchpad/pagetests should be stories
[03:34] <barry> mwhudson: +1, spiv +1
[03:34] <mwhudson> and that doc/ should be documentation
[03:34] <spiv> mwhudson: +1
[03:34] <mwhudson> and tests (whether .py or .txt) should be in a tests directory?
[03:34] <barry> mwhudson: +1
[03:34] <spiv> mwhudson: +1 +1 +1
[03:34] <mwhudson> ok
[03:35] <barry> and can we for gawd's sake please do something about tests, testing, and ftests?
[03:35] <spiv> Rename ftests to f'ing tests?
[03:35] <mwhudson> well, testing is for scaffolding
[03:35] <jml> barry: tests & testing is a sensible split
[03:35] <jamesh> stuff in ftests can go to tests
[03:35] <mwhudson> ddaa tried to land a branch that moved everything in ftests into tests
[03:35] <barry> jml: yes, maybe just get rid of ftests.  i would be so much happier
[03:35] <thumper> testing is infrastructure
[03:35] <jamesh> the tests / testing split is good
[03:35] <jml> jamesh: sometimes it needs to go to testing :)
[03:35] <spiv> jamesh: +1
[03:36] <jamesh> jml: right
[03:36] <barry> jamesh: +1
[03:36] <mwhudson> but it's a conflict nightmare
[03:36] <mwhudson> ok, i can add this to my mail too :)
[03:36] <thumper> each team should move its own tests
[03:36] <thumper> from ftests to tests in the appropriate place
[03:36]  * barry has a secret plan for montreal :)
[03:36] <thumper> we file a bug
[03:36] <thumper> create tasks for each team
[03:36] <thumper> and JFDI!
[03:37] <barry> thumper: right!  i want a special pqm tag for that
[03:37] <thumper> :)
[03:37] <thumper> barry: why a pqm tag?
[03:37] <jml> thumper: I think you'll find that one team has already done it :P
[03:37] <thumper> jml: not quite
[03:37] <barry> thumper: well, when i want to jf land a branch :)
[03:37] <thumper> jml: there are some older tests still in c.l.ftests
[03:37] <spiv> Some people claim "Jedi" as their religion.  thumper's religion is "JFDI".
[03:38] <jml> thumper: let us continue this team-specific discussion outside of the meeting.
[03:38] <barry> 2007's motto was "canonical fuck yeah!".  2008's should be JFDI
[03:38] <thumper> barry: can you add a mootbot task for that?
[03:38] <barry> [ACTION] mwhudson to start discussion on page test purpose
[03:38] <MootBot> ACTION received:  mwhudson to start discussion on page test purpose
[03:38] <thumper> barry: I was meaning a bug for ftests -> tests
[03:39] <barry> [ACTION] thumper to submit a bug for moving ftests contents to tests
[03:39] <MootBot> ACTION received:  thumper to submit a bug for moving ftests contents to tests
[03:39] <barry> anything else on this topic mwhudson?
[03:39] <mwhudson> not for today i think
[03:40] <mwhudson> i can hear jml's stomach rumbling from here :)
[03:40] <barry> :)
[03:40] <jml> :D
[03:40] <barry> okay, one quick last one
[03:40] <jml> The "D" represents my gaping maw.
[03:40] <barry>  * (bigjools) On-call reviewers to remind devs to be available during the review.
[03:40] <jml> that's a good idea.
[03:40] <mwhudson> +1
[03:40] <jml> I'll do that in future.
[03:40] <barry> bigjools brought up to me that some people are using on-call requests to jump ahead of the review queue
[03:40] <jamesh> we've got way too much obsolete test infrastructure still in tree
[03:41] <barry> i.e. they request an on-call review then disappear
[03:41] <mwhudson> jamesh: yes
[03:41] <jml> barry: yeah, this has happened to me.
[03:41] <barry> i told bigjools that if that happens, you are allowed to reject the ocr request and move on to someone who is present
[03:41] <barry> the whole point of ocr is to have a dialog with the dev
[03:41] <mwhudson> i think i've done this
[03:42] <spiv> This makes good sense to me.
[03:42] <mwhudson> at least, if i have two reviews to do and the developer is there for one of them, he gets done first
[03:43] <barry> anybody disagree?
[03:43] <thumper> nope
[03:43] <mwhudson> nope
[03:43] <barry> great.  that's it for me.  shall we end 2 minutes early and let jml get some food?
[03:44] <jml> I think we should discuss it first :)
[03:44] <barry> jml: but only for 1 more minute :)
[03:44] <barry> #endmeeting
[03:44] <MootBot> Meeting finished at 21:47.
[03:44] <barry> thanks everyone!
[03:44] <jml> barry: thanks!
[03:44] <mwhudson> thanks barry
[03:44] <spiv> barry: thanks
[15:00] <barry> #startmeeting
[15:00] <MootBot> Meeting started at 09:03. The chair is barry.
[15:00] <barry> hi everybody.  welcome to this week's ameu reviewers meeting
[15:00] <barry> who's here today?
[15:00] <sinzui> me
[15:00] <EdwinGrubbs> me
[15:00] <gmb> me
[15:00] <bigjools> me
[15:01] <intellectronica> me
[15:01] <bac> me
[15:01] <barry> danilos, BjornT ping
[15:01] <barry> flacoste: ping
[15:01] <danilos> me
[15:01] <flacoste> me
[15:01] <BjornT> me
[15:01] <danilos> barry: thanks
[15:02] <allenap> me
[15:02] <barry> salgado: ping
[15:02] <barry> [TOPIC] agenda
[15:02] <MootBot> New Topic:  agenda
[15:02] <salgado> me
[15:02] <barry> == Agenda ==
[15:02] <barry>  * Roll call
[15:02] <barry>  * Next meeting
[15:02] <barry>  * Action items
[15:02] <barry>  * Queue status
[15:02] <barry>  * Mentoring update
[15:02] <barry>    * bye to statik
[15:02] <barry>    * bigjools graduates
[15:02] <barry>    * new recruits?  (leonardr, abentley, mars)
[15:02] <barry>  * Review process
[15:02] <barry>    * (bigjools) On-call reviewers to remind devs to be available during the review.
[15:02] <barry>    * (gmb) Wrapping long argument lists: What's the agreed style?
[15:02] <barry>    * (mwhudson) What are page tests for?
[15:02] <barry>    * thumper moving ftests contents to tests
[15:02] <barry> [TOPIC] next meeting
[15:02] <MootBot> New Topic:  next meeting
[15:02]  * barry kicks mootbot
[15:03] <jtv> me
[15:03] <statik> me
[15:03] <barry> jtv: hi!  statik hi!
[15:03] <jtv> barry, hi!
[15:03] <barry> next week, same time and place?  anybody know they will be sprinting or away?
[15:04] <barry> cool
[15:04] <barry> [TOPIC] action items
[15:04] <MootBot> New Topic:  action items
[15:04] <barry>  * intellectronica to file bug on lint issue regarding elementtree import
[15:04] <intellectronica> sorry, i didn't. let's carry this on
[15:04] <barry> intellectronica: np
[15:04] <barry>  * mwhudson to start discussion on page test purpose
[15:05] <barry> i will proxy mwhudson :)
[15:05] <barry> he's going to start a ml thread on the purpose of page tests.  more in a moment
[15:05] <barry>  * thumper to submit a bug for moving ftests contents to tests
[15:05] <barry> more on this in a bit
[15:05] <barry> [TOPIC] queue status
[15:05] <MootBot> New Topic:  queue status
[15:06] <barry> any comments?  i was freaking out on monday, but i've calmed down by now.  thanks everyone for cranking away on reviews!
[15:06] <sinzui> Stub has reviewed my two branches now; he has not updated the statuses
[15:07] <barry> sinzui: are they merge-approved?
[15:07] <sinzui> yes
[15:07] <barry> sinzui: cool. i'll ignore those and you can just remove them when they land
[15:07] <barry> my branch that kiko reviewed is still trying to land
[15:08]  * barry won't even mention testsuite2 :)
[15:08] <barry> anything else on the queue?
[15:08] <sinzui> We seem to have extra missing branches this week
[15:09] <barry> sinzui: missing where?
[15:09] <salgado> yeah, I'm nagging stub about my oauth-context branch, which has a DB patch
[15:09] <sinzui> barry: The red branches are missing. It implies they were removed from the repo, or renamed
[15:10] <barry> sinzui: yeah, people are not updating PR
[15:10] <sinzui> gmb and intellectronica have missing branches
[15:10] <sinzui> and schwuk
[15:10] <barry> everyone, remind your reviewees to clean up PR when their branch lands!
[15:10] <bigjools> amen to that
[15:10]  * bigjools cleaned 4 of other people's out this morning
[15:11] <intellectronica> sinzui: oh right, i cleaned my repo but not PR, i guess. i'll sort it out
[15:11] <barry> bigjools: yes, feel free to clean out any that you see
[15:11]  * barry is a culprit too
[15:11] <bigjools> I don't like doing it though, it makes devs lazy!
[15:11] <barry> bigjools: hmm, maybe refuse to review any new branches until they clean out their old ones :)
[15:11] <bigjools> lol
[15:12] <barry> anyway...
[15:12] <barry> [TOPIC]  * Mentoring update
[15:12] <MootBot> New Topic:   * Mentoring update
[15:12] <gmb> Or have PQM check for red branches and rejecting anything until they're gone...
[15:13] <barry> so first, we say goodbye to statik who is moving off the lp team and won't be accepting any more reviews.  i was tempted to go down to florida to camp on his doorstep until he changed his mind but it's a long train trip
[15:13] <barry> statik: thanks and good luck!  you're welcome to come do reviews any time you're bored :)
[15:13] <statik> thanks!
[15:14] <barry> next up: bigjools graduates.  congratulations bigjools!
[15:14] <jtv> congrats bigjools!
[15:14]  * flacoste cheers bigjools
[15:14] <intellectronica> congrats bigjools!
[15:14] <bac> hurrah
[15:14]  * bigjools takes a bow
[15:14] <gmb> Hurrah!
[15:14] <bigjools> thanks guys
[15:14] <barry> i will send an official email after this meeting
[15:14] <bigjools> Barry is a great mentor - thanks to him also
[15:14] <barry> remember, give all your hard branches to bigjools now :)
[15:14] <bigjools> oof
[15:15] <barry> :)
[15:15] <barry> bigjools: thanks
[15:15] <flacoste> but has it easy, being a soyuz developer
[15:15]  * bigjools considers retracting the last statement :)
[15:15] <jtv> too late
[15:15] <flacoste> the worst branch are his :-p
[15:15] <barry> flacoste: no kidding!
[15:15] <bigjools> flacoste: lol
[15:16] <barry> i think we can accept a few more recruits now.  i'm certainly happy to mentor again.  i think the next three potential candiates are leonardr, abentley, and mars
[15:16] <barry> i talked to thumper and i'm thinking about mentoring abentley
[15:16] <barry> we need mentors if we're going to accept anybody else, though i propose we do not accept until after 2.0
[15:17] <barry> so if you would like to volunteer to mentor leonardr or mars, please send me an email
[15:17] <intellectronica> i'm happy to mentor again, after 2.0
[15:17] <barry> intellectronica: awesome
[15:17] <gmb> I'll be happy to do the same
[15:17] <barry> gmb: great, thanks!
[15:17] <barry> btw, we mentioned rockstar and al-maisan but we want to give those guys a bit more time dev'ing for now
[15:18] <barry> [TOPIC]  * Review process
[15:18] <MootBot> New Topic:   * Review process
[15:18] <barry>    * (bigjools) On-call reviewers to remind devs to be available during the review.
[15:18] <barry> we talked about this last week...
[15:18] <bigjools> ok
[15:19] <bigjools> I've noticed a few instances where developers are not available during on call reviews
[15:19] <barry> but i just wanted to mention that asiapac was all for the idea that it's okay to reject an ocr if the dev disappears
[15:19] <bigjools> the primary reason for OCR is to speed up reviews
[15:19] <intellectronica> well, if they're not available then they're not available, what can you do? just postpone the review for later
[15:19] <bigjools> not as a means to jump the general queue
[15:19] <bigjools> intellectronica: put them in the GQ
[15:20] <barry> bigjools: exactly
[15:20] <intellectronica> bigjools: yeah, exactly
[15:20] <jtv> It's a bit annoying when you're in Asia though
[15:20] <bigjools> jtv: we could prioritse people who find it hard to be around at the same time as OCRs
[15:20] <barry> jtv: who is affected by that?
[15:21] <bigjools> anyway - we should remind devs, when they ask for a review, to be around, otherwise refuse the review
[15:21] <jtv> Agreed—if you ask for it, you ask for it.
[15:21] <barry> the one hitch is when someone asks for  review and you can't get to it for several hours because your dance card is full.  they might disappear by the time you're free
[15:22] <bac> this tends to happen to me when europeans ask for reviews in my early afternoon.  often by the time i get to the review it's pretty late where they are.  happened last night.
[15:22] <barry> this has happened to me when euros get bumped to the end of my list
[15:22] <barry> bac: yep
[15:22] <bigjools> if you're not sure you can get to it, I don't think it should be accepted
[15:22] <barry> i think it's okay to reshuffle your queue
[15:22] <bigjools> maybe we need to consider doubling up reviewers on some shifts?
[15:23] <barry> i.e. give some priority to those east of you if it helps speed the review
[15:23] <bigjools> like some already do
[15:23] <bac> and, if you're approaching the end of your work day, don't ask someone just b/c they have a few hours left
[15:23] <barry> bac: good pont
[15:23] <bac> 'you" being a dev, not a reviewer
[15:23] <barry> er, point
[15:23] <barry> bigjools: i'm not sure we have enough coverage as it is atm
[15:24] <bigjools> when I've been on call on Monday mornings it's quite thin most of the time, I could move to a different day
[15:24] <barry> i.e. wednesday we only have intellectronica and allenap in euro time
[15:24] <intellectronica> only?
[15:24] <sinzui> We need to send rockstar to NZ once he is a reviewer to take the Wednesday slot
[15:24] <barry> intellectronica: not to disparage you guys!  you all do great, but we have no america coverage on wednesdays
[15:25] <intellectronica> ah, of course. well, i think we'll have to relocate someone
[15:25] <barry> btw, the asiapacsters don't feel to bad about the current situation, i.e. they are neither overloaded nor seeing their branches languish
[15:25] <bigjools> does this mean we need more Americas reviewers?
[15:26] <barry> bigjools: leonardr, abentley and mars are all here so getting them on board will improve coverage eventually
[15:26] <intellectronica> if we get leonardr on board it will help, though, so let's try to convince him to start after 2.0
[15:26] <bigjools> rockin'
[15:26] <barry> intellectronica: +1
[15:27] <barry> bigjools: we have good euro coverage, so if you want to stay on monday that's cool.  it's nice to have a little overlap in our days.  otherwise, definitely feel free to pick a slot later in the week and double up with someone
[15:27] <salgado> we also have EdwinGrubbs, who's being mentored by myself
[15:28] <barry> bigjools: maybe friday so sinzui's load gets lightened.  i always feel bad that sinzui reviews into his weekend :)
[15:28] <bigjools> I don't mind either way.  I'll stay where I am for now and we can check which periods are most busy
[15:28] <salgado> once he graduates we'll have one more reviewer in america
[15:28] <barry> salgado: good point!
[15:28] <bigjools> barry: yeah, there's nobody on Friday mornings
[15:28] <barry> bigjools: sounds good
[15:28] <bigjools> Europe time that is
[15:28] <sinzui> barry: You do not. I'm taking the load off of you
[15:29] <flacoste> barry: well, if doesn't review into the week-end, he'll code, which increase the review load so...
[15:29] <barry> :)
[15:29]  * sinzui looks forward to this Friday with PQM in top form to screw developers whose nicks are not gmb
[15:29] <barry> anyway, moving on...
[15:29] <gmb> *mumblemumble*
[15:29] <barry>    * (gmb) Wrapping long argument lists: What's the agreed style?
[15:29] <gmb> Right.
[15:29] <gmb> So, my question is pretty simple.
[15:30] <gmb> When we come across a method definition with a really long list of arguments, how do we want it wrapped.
[15:30] <sinzui> We agree to wrap two ways as we see fit
[15:30] <gmb> I've seen three styles:
[15:30] <gmb> def spam(eggs, ham, jam, lamb, spam
[15:30] <gmb>     foo, bar):
[15:30] <gmb> def foo(
[15:31] <gmb>     here, is, a, nother, long, list):
[15:31] <gmb> or
[15:31] <gmb> def bar(
[15:31] <gmb>     this,
[15:31] <gmb>     looks,
[15:31] <gmb>     really,
[15:31] <gmb>     ugly):
[15:31] <salgado> I think the basic rule should be to have all the arguments aligned so that they stand out from the rest
[15:31] <sinzui> I choose neither
[15:31] <salgado> there's also
[15:31] <intellectronica> iiuc the first one is not kosher, but you can choose wither of the last two
[15:31] <bigjools> there's a 4th!
[15:31] <salgado> def bar(foo, bar, baz,
[15:31] <salgado>        nah):
[15:31] <sinzui> I choose salgado's
[15:32] <flacoste> i thought that was the agreed style actually
[15:32] <barry> salgado: with the 'nah' lined up under 'foo'?
[15:32] <salgado> barry, yep
[15:32] <flacoste> barry: yes
[15:32] <jtv> That's PEP-8
[15:32] <barry> salgado: +1
[15:32] <gmb> jtv: Good enough for me.
[15:32] <BjornT> i think the 4th one is the most common one in our code
[15:32]  * bigjools is using non-prop fonts here so it all looks ugly
[15:32] <jtv> Personally I like the double-indent for continued parameter lists.
[15:32] <bac> salgado: +1
[15:33] <salgado> I personally prefer the second example of gmb
[15:33] <salgado> but I'm strongly opposed to the first one
[15:33] <gmb> salgado: That's the one I usually use, but I'm happy to follow prevailling wisdom
[15:33] <gmb> s/usually/
[15:33] <salgado> hence my saying that the basic rule should be to have all the arguments aligned so that they stand out from the rest
[15:33] <jtv> Should we put this on a wiki page (where we know it's in nonproportional fonts) and vote?
[15:33] <salgado> if that was the rule all three options would be allowed, which I think is fine
[15:34] <salgado> maybe not the third one as it looks quite ugly
[15:34] <bac> i'm against any style that lines up the arguments with the body of the method
[15:34] <gmb> I think the third one takes up unnecessary space.
[15:34] <intellectronica> bac: i very much agree
[15:35] <barry> bac: i agree too
[15:35] <jtv> +1 for bac
[15:36] <danilos> I'd be for the current prevailing style "de salgado" (at least in this meeting)
[15:36] <barry> danilos: +1
[15:36] <jtv> But verily it sucketh with long method names.
[15:36] <barry> [VOTE] adopt salgado's suggestion for parameter indents: aye +1 or nay -1
[15:36] <MootBot> Please vote on:  adopt salgado's suggestion for parameter indents: aye +1 or nay -1.
[15:36] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[15:36] <MootBot> E.g. /msg MootBot +1 #launchpad-meeting
[15:37] <barry> +1
[15:37] <MootBot> +1 received from barry. 1 for, 0 against. 0 have abstained. Count is now 1
[15:37] <bigjools> +1
[15:37] <MootBot> +1 received from bigjools. 2 for, 0 against. 0 have abstained. Count is now 2
[15:37] <salgado> +1
[15:37] <gmb> +1
[15:37] <allenap> +1
[15:37] <MootBot> +1 received from salgado. 3 for, 0 against. 0 have abstained. Count is now 3
[15:37] <MootBot> +1 received from gmb. 4 for, 0 against. 0 have abstained. Count is now 4
[15:37] <MootBot> +1 received from allenap. 5 for, 0 against. 0 have abstained. Count is now 5
[15:37] <bac> +1
[15:37] <sinzui> +1
[15:37] <MootBot> +1 received from bac. 6 for, 0 against. 0 have abstained. Count is now 6
[15:37] <MootBot> +1 received from sinzui. 7 for, 0 against. 0 have abstained. Count is now 7
[15:37] <danilos> +1
[15:37] <MootBot> +1 received from danilos. 8 for, 0 against. 0 have abstained. Count is now 8
[15:37] <flacoste> +1
[15:37] <MootBot> +1 received from flacoste. 9 for, 0 against. 0 have abstained. Count is now 9
[15:37] <danilos> ho-hum, what was that discussion about in the first place? :)
[15:37] <statik> +1
[15:37] <MootBot> +1 received from statik. 10 for, 0 against. 0 have abstained. Count is now 10
[15:37] <jtv> danilos: car repairs.
[15:38] <barry> #endvote
[15:38] <flacoste> jtv: don't use long method names :-)
[15:38] <barry> er, whatever mootbot
[15:38] <barry> flacoste: right
[15:38]  * bigjools aims a kick to mootbot's nads
[15:38] <barry> gmb: can you update PythonStyleGuide and send a quick email to the ml?
[15:38] <gmb> barry: Will do.
[15:39] <flacoste> jtv: seriously, i think we should allow starting the argument lists on the next line with a double-indent for long method names
[15:39] <barry> [ACTION] gmb to update PSG for parameter indents and email launchpad@
[15:39] <MootBot> ACTION received:  gmb to update PSG for parameter indents and email launchpad@
[15:39] <bigjools> barry: I will do the same about the OCR topic
[15:39] <danilos> #startsomethingtoendvote
[15:39] <jtv> flacoste: +1 for that
[15:39] <barry> [ACTION] bigjools to email launchpad@ about devs sticking around for their ocr
[15:39] <MootBot> ACTION received:  bigjools to email launchpad@ about devs sticking around for their ocr
[15:40] <barry> flacoste, jtv yes, it's okay if there are exceptions for superCrazyMegaUltraLongMethodNamesThatTakeUpTonsOfSpace
[15:40] <barry>    * (mwhudson) What are page tests for?
[15:41] <sinzui> use cases
[15:41] <barry> mwhudson: brought up some questions about the purpose of page tests. are they customer stories or do they test our templates
[15:41] <sinzui> customer acceptance tests
[15:41] <barry> right now, the stuff in pagetests is some of both
[15:41]  * sinzui tests templates in doc/*-pages.txt
[15:42] <salgado> I test views in there
[15:42] <salgado> I mean doc/*-pages.txt
[15:42] <sinzui> salgado: So do it, but I recently added template tests since I did not think it was relevant to the use case
[15:42] <barry> sinzui: i think we mostly agree, so mwhudson is going to start a ml thread about it and begin to get people to separate these
[15:42] <bigjools> I think customer stories should involve all aspects of the template, otherwise what is that part the template doing there?
[15:43] <flacoste> sinzui: testing template in doc/*-pages is not our standard, although it might make a good idea
[15:43] <BjornT> sinzui: do you have an example?
[15:43]  * sinzui thinks
[15:43] <flacoste> bigjools, sinzui: sometimes you have to test all the possibilities in a template
[15:43] <flacoste> but that's not relevant to the user stories
[15:44] <flacoste> as a dev, you know that these three cases involved three different code paths
[15:44] <intellectronica> i think that it's ok to mix the two purposes, as long as you get sufficient coverage
[15:44] <flacoste> but from the point of view of the user, it's one sue-case
[15:44] <intellectronica> that's in line with our not doing unit tests for everything
[15:44] <flacoste> intellectronica: which i think is wrong
[15:44] <jtv> intellectronica: but is that a good thing?
[15:44] <flacoste> but that's just me
[15:44] <sinzui> BjornT: I checked the calls to the search form in launchpad-search-pages. the form is a technical matter, not a use case.
[15:45] <intellectronica> jtv, flacoste: i'm not sure myself, i just note that this is how we do it. mostly, it means that we have to pay attention closely to make sure that we get full coverage from the mix of tests we do have
[15:45] <sinzui> the pagetests need reorganisation, and normalisation
[15:46] <jtv> sinzui: +1
[15:46] <bigjools> if your template is *that* complicated it has multiple code paths, should it not be simplified and stuff put in the view?
[15:46] <danilos> as do all our other tests
[15:46] <bigjools> my eyes bleed over some templates
[15:46] <barry> sinzui: right.  thumper is going to start a thread about test reorg, and especially moving ftests stuff to tests
[15:47] <sinzui> bigjools: right. We don't have as many doc/*-pages.txt as we should have, I think a lot of pagetests are checking the view's behaviour
[15:47] <barry> bigjools: reviewing pts are incredibly painful
[15:47] <bigjools> exactly
[15:47] <danilos> if we are to reorganize tests, we should make as clear separation and categorization as possible, covering all testing
[15:47] <bigjools> and if more stuff is in the view, it can be tested separately
[15:47] <bigjools> and more efficiently
[15:47] <bigjools> thus speeding the test suite
[15:48] <flacoste> bigjools: different code paths simply means different conditions
[15:48] <flacoste> so the logic is in the view
[15:48] <BjornT> intellectronica: it's not really how we do it. basically, we treat our tests for DB classes as 'unit tests'. they should have have as much coverage as possible.
[15:48] <flacoste> but you still need coverage that the template is using the view correclty
[15:48] <bigjools> flacoste: agreed
[15:48] <flacoste> barry: ftests/tests is an historical separation
[15:49] <barry> flacoste: s/historical/hysterical/ :)
[15:49] <barry> but yeah
[15:49] <sinzui> barry: +1
[15:49] <barry> anyway, we've gone over.  my apologies for that.  we'll continue this discussion on the list when mwhudson starts it
[15:49] <barry> #endmeeting
[15:49] <MootBot> Vote is in progress. Finishing now.
[15:49] <MootBot> Final result is 10 for, 0 against. 0 abstained. Total: 10
[15:49] <MootBot> Meeting finished at 09:52.
[15:49] <barry> thanks everyone!
[15:50] <jtv> barry: thank you, nice seeing you again :)
[15:50] <intellectronica> thanks barry
[15:50] <bac> thanks barry & mootbot
[15:50] <barry> jtv: you too!  you're welcome to stop by any time :)


[10:13] <ian-weisser> Bug #1267059 seems to be assigned to mvo, but it's not on his list of assigned bugs.


[06:59] <tsimonq2> "All your data are belong to us." -Spectre exploiters
[09:52] <ricktimmis[m]> Oh dear, that sounds ominous
[10:18] <acheronuk> https://twitter.com/msmeissn/status/949681668054544385
[10:18] <acheronuk> ubuntu being a bit slow :/
[20:54] <valorie> yeah
 http://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown?action=diff&rev1=6&rev2=7
 LOL: snap
 was just going to post that
 http://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown?action=diff&rev1=7&rev2=8
 hah beat you to it :P
[22:08] <valorie> just now doing a personal blog post -- not completely about this stuff, but starting it off there
[23:00] <valorie> http://linuxgrandma.blogspot.com/2018/01/beginning-2018.html
 Ohhhh wait did you *speak* at the conf?
 Got a link?
 :D
 Thanks for the mention btw!
[23:04] <valorie> there is a link in there
[23:04] <valorie> I was the keynote!
 Oooooooh
[23:06] <valorie> it was amaaaaaaaaaazzzzzing
[23:06] <valorie> and trippy, because they are 12 hours ahead
[23:06] <tsimonq2> Hmmmmmm, no recording of the keynote itself? :/
[23:06] <tsimonq2> Ah ok
[23:07] <valorie> basically 3 days journey there
[23:07] <valorie> 2 days back
[23:07] <valorie> no recording, just a few photos
[23:11] <tsimonq2> Ah ok
[23:14] <valorie> it was one day of talks, one day of workshops
[23:14] <valorie> -s
[23:14] <valorie> one big workshop
[23:16] <tsimonq2> Cool cool