[20:02] <boredandblogging> Rinchen: is there a way to get Ubuntu Media Relations LP team decoupled from the marketing team?
[20:02] <boredandblogging> looks like media relations is getting notified about all ubuntu bugs
[20:21] <beuno> boredandblogging, hi
[20:21] <beuno> what's the URL?
[20:22] <beuno> the marketing team shouldn't be notified about ubuntu bugs
[20:22] <beuno> in fact, I'm part of it, and I don't get norified
[20:23] <beuno> actually, I'm part of the other team as well, and don't get those notifications either...
[20:26] <boredandblogging> beuno: url for what?
[20:26] <beuno> boredandblogging, nm, found the team
[20:26] <boredandblogging> a bug?
[20:26] <boredandblogging> ok
[20:26] <beuno> who is getting notifications?
[20:27] <beuno> I can decouple the team (so can you)
[20:27] <beuno> but, I'm interested in what is happening
[20:27] <beuno> and, who would own it?
[20:27] <boredandblogging> can we get media relations to unsubscribe to the bugs?
[20:27] <boredandblogging> any and/or all bugs?
[20:28] <boredandblogging> the team is deprecated, really shouldn't be attached to any other team
[20:28] <beuno> I see
[20:28] <boredandblogging> the marketing LP contact is the marketing list
[20:28] <boredandblogging> think I'm the owner of the marketing list
[20:29] <boredandblogging> so I'm getting emails asking for the updates to get approved
[20:29] <boredandblogging> to go out to the marketing list
[20:29] <beuno> bhavi seems like the administrator of that team
[20:30] <beuno> I can re-asign it to him
[20:31] <beuno> I deactivated the marketing team as a member
[20:31] <boredandblogging> beuno: thanks
[20:31] <beuno> boredandblogging, I can deactivate the rest, and file a question to get that team deleted
[20:35] <boredandblogging> beuno: that would be great
[20:41] <beuno> boredandblogging, done and one
[20:41] <beuno> https://answers.edge.launchpad.net/launchpad/+question/45216


 I was picked for FOSDEM23 \o/
 @RikMills can we meet in person? Omg
 I'd owe him many beers...
[20:32] <valorie> @ahoneybun Very Kool!
[20:32] <valorie> I didn't hear that RikMills was attending in person
 Indeed!
[20:32] <valorie> how fun
 I don't know if he is
[20:33] <valorie> mixed rain & snow here now


[09:01] -queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Preparing packages
[09:15] -queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Failed to build (zesty/indicator-bluetooth). Pending binary packages (vivid/indicator-bluetooth, xenial/indicator-bluetooth). Ready to build (zesty/libindicator). Successfully built (vivid/indicator-application, vivid/indicator-datetime, vivid/indicator-display, vivid/indicator-keyboard, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-network, vivid/in
[10:55] -queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Failed to build (zesty/indicator-bluetooth). Ready to build (zesty/libindicator). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-display, vivid/indicator-keyboard, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-network, vivid/indicator-power, vivid/indicator-session, vivid/indicato
[15:55] -queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Ready to build (zesty/libindicator). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-display, vivid/indicator-keyboard, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-network, vivid/indicator-power, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, vivid/libi
[17:07] -queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 QA Signoff: Ready
[18:35] -queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Preparing packages
[18:52] -queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Dependency wait
[21:17] -queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 QA Signoff: Required
[21:32] -queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 xenial/unity-scope-snappy: Failed to update local lp:~ci-train-bot/unity-scope-snappy/+git/unity-scope-snappy-ubuntu-xenial-2071 cache


[02:10] <lemasney> I can see you, Jono
[06:41] <dholbach> good morning
[09:49] <akiva-mobile> dholbach, morning
[09:49] <dholbach> hi akiva-mobile
[09:50] <akiva-mobile> dholbach, How was april fools?
[09:53] <dholbach> good - I liked Jono's Q&A and FB buying Ubuntu for 3bn - I didn't see too many surprises outside the tech press though - how was yours?
[10:00] <frango> is jono here?
[10:01] <dholbach> frango, no - you're probably looking at a recorded video right now
[10:01] <dholbach> where Jono lives it's 3:00 in the morning
[10:03] <frango> oh i know its not live atm
[10:03] <frango> he's in the UK isnt he?
[10:03] <frango> thought he might idle on irc
[10:04] <dholbach> no, he's in the US
[10:10] <akiva-mobile> dholbach, Jono made me cry numerous times on his Q&A. ;_;
[10:11] <dholbach> :-)
[18:04] <mhall119_> you can ask questions at any time here, just start it with "QUESTION"
[18:07] <nar_> yes
[18:07] <AUX> I see you
[18:08] <Dule_SRB> :D
[18:08] <MrGiue> Hi
[18:08] <mutlucan96> have good work!
[18:08] <lei_> QUESTION: UBUNTU NEEDS TO USE WAYLAND
[18:09] <mhall119> not really a question
[18:09] <Paddy_NI> :-D
[18:10] <lei_> I AM HELPING CODING
[18:10] <nar_> first time I watch this and your leaving
[18:11] <mhall119> nar_: I think you have an old video, if you're seeing jono
[18:11] <TonyBarrio> ####
[18:11] <zonovroman> I want to ask about download and upload files. Do you plan to implement it with only QML, without C++ backend?
[18:11] <nik90> mhall119: sry, but did bill say anything about when the right edge app navigation land? (Just got here)
[18:11] <Paddy_NI> April Fools :-(
[18:11] <mhall119> zonovroman: please start it with "QUESTION"
[18:11] <mhall119> nik90: not yet, ask it
[18:11] <nar_> it is the 2 april...
[18:11] <JavaProgramming> what a beautiful bass guitar :D
[18:11] <nar_> or is it the 1
[18:11] <zonovroman> QUESTION: I want to ask about download and upload files. Do you plan to implement it with only QML, without C++ backend?
[18:11] <N8100> Hi all.
[18:12] <nik90> QUESTION: When is the right-edge app navigation planned to land in the images?
[18:13] <Robby___> QUESTION - May not be the right venue, but I'm having a hard time finding info on USB webcams that are compatible. I have 12.04 32 bit.
[18:13] <Paddy_NI> Eric Cantona lost his passion for the game too
[18:13] <Guest77909> QUESTION: Do we have any update on the work going on for Ubuntu phone?
[18:13] <nar_> like the 1 April 2014 title
[18:13] <nar_> QUESTION: what day is today
[18:13] <Robby___> YES, I would like more info on the phone too!
[18:13] <mhall119> Guest77909: that's a big topic, do you have specifi cquestions?
[18:14] <Boocita23> ohai
[18:14] <N8100> Have we (community) attained some achievements in the field of power management on laptops with new Ubuntu relese?
[18:14] <nar_> 14 years, you said it already
[18:14] <TonyBarrio> https://www.facebook.com/photo.php?fbid=716122128445530&set=a.140245649366517.25142.137947596262989&type=1&theater
[18:14] <mhall119> nar_: you're watching an old video
[18:14] <ahmaad> hello
[18:14] <nar_> youl get attitude everywhere
[18:14] <warfares> there is a eco ... !!
[18:14] <nik90> mhall119: we are hearing the echo of jorge
[18:14] <TonyBarrio> Stremming
[18:14] <Robby___> QUESTION - As far as the phone goes, I've read that you can root some phones and install the OS, but are there any phones that run it out of the box in the pipeline??
[18:14] <nik90> mhall119: nevermind it is gone now
[18:14] <TonyBarrio> Try a refresh
[18:15] <benj1o> Hi Mother fucker !!! How are you ?
[18:15] <mhall119> zonovroman: lp:ubuntu-download-manager
[18:15] <TonyBarrio> http://linux.iatkos.net works too?
[18:15] <nik90> benj1o: please behave yourself in this channel
[18:15] <tombuntu> Thanks michael was having feedback
[18:15] <mhall119> you can ask questions at any time here, just start it with "QUESTION"
[18:15] <ubuntu-guy> "QUESTION" is digtalocean cloud supported like amazon is?
[18:15] <benj1o> Yeah Scuse man !
[18:16] <lei_> JONO BACON I FEEL WHAT U SAY I FEEL LINUX IS NOT GOING ANYWHERE
[18:17] <Paddy_NI> QUESTION Perhaps you need to find your inner NeckBeard again Jono?
[18:17] <zonovroman> QUESTION: Firstly, thank you for your answer. Secondly, Ubuntu.Content (ContentHub) is not working both on desktop and phone. What I'm doing wrong? I have Trusty, with last updates.
[18:17] <Robby___> Awesome, thanks guys!
[18:18] <nar_> OK, got the right video now ;)
[18:18] <lei_> UBUNTU SUCKS
[18:18] <lei_> L
[18:18] <jcastro> https://github.com/kapilt/juju-digitalocean
[18:19] <Robby___> PERFECT, thanks!!
[18:19] <Robby___> Awesome
[18:19] <mhall119> if you're seeing Jono, you're watching an old video
[18:19] <mhall119> that was from yesterday
[18:19] <Dipesh> I have problem installing Google chrome...
[18:20] <bfiller> just confirmed right edge stuff is in latest trusty-proposed image
[18:20] <JavaProgramming> The problem maybe isn't your os
[18:20] <nik90> bfiller: thnx
[18:21] <SlowLigh> when will we find a decent DVB-S/T/C player for linux? especially DVB-S
[18:21] <mhall119> you can ask questions at any time here, just start it with "QUESTION"
[18:21] <zonovroman> QUESTION: I'll try in next 5-10 minutes. It's not a question, sorry for lie.
[18:21] <warfares> hey QUESTION will be  MIR in the next release ??
[18:21] <CheeseBurg> Sorry, what did I miss?
[18:22] <mhall119> CheeseBurg: everything :)
[18:22] <CheeseBurg> Aww man
[18:22] <SlowLigh> Question : when will we find a decent DVB-S/T/C player for linux? especially DVB-S
[18:22] <lei_> QUESTION: THANK U  AND I USE WINDOWS 8.1
[18:22] <Paddy_NI> lei_: That is not a question
[18:22] <nik90> QUESTION: You mentioned that uploading to the app store can be done via the Web UI or API. Which API are you referring to?
[18:23] <mhall119> does the caplock key stay on in Windows 8.1?
[18:23] <Dipesh> "QUESTION" Any solution for installing Google Chrome??
[18:23] <Stern_> Use chromium.
[18:23] <CheeseBurg> Dipesh: Just go to the website
[18:23] <zonovroman> QUESTION: What about policies in Ubuntu Touch? As you knows, there are some bugs (connected with security), and I can't upload my app with accounts and friends permissions. When you expect to fix bugs?
[18:23] <Paddy_NI> Dipesh: Use gdebi to install it
[18:24] <Paddy_NI> Dipesh: https://www.youtube.com/watch?v=eUqMVJ-Gz4I
[18:25] <ubuntu-guy> "QUESTION" do you check click app pagages to see if they are malware as we need to have a solid way to not have malware in the app store as googles one has lots of malware
[18:25] <CheeseBurg> QUESTION: Will there be a replacement for U1 or integration with other services like ownCloud or GDrive?
[18:26] <CheeseBurg> What is with the echo?
[18:26] <warfares> great thanks
[18:27] <jeffrey_f> QUESTION: Would love to see a free version of Landscape.  Maybe a stand-alone version (local cloud?).  Would be great to be able to manage up to 5 systems at home.
[18:27] <beuno> nik90, https://launchpad.net/click-toolbelt
[18:28] <taurus> awesome ubuntu...
[18:29] <nik90> beuno: thnx. I asked because of the hope this might lead to uploading from Qtcreator itself using the API :)
[18:30] <joe_____> Hi what is going with the Ubuntu phone?
[18:32] <beuno> nik90, that is in progress  ;)
[18:32] <nik90> beuno: awesome :D
[18:32] <ubuntu-guy> "QUESTION" can users create there own security polices?
[18:32] <Dipesh> "QUESTION" Are there any configuration issue installing ubuntu server os in raspberry pi??
[18:32] <CheeseBurg> joe_____: You have to preface with QUESTION
[18:33] <taurus> how safe is ubuntu regarding viruses and malware....?
[18:33] <btroot> ubuntu is more safe than windows
[18:33] <mhall119> taurus: start questions with "QUESTION"
[18:34] <Paddy_NI> I started on a BBC Micro
[18:35] <Paddy_NI> ASCII Pr0n is what it's all about
[18:35] <taurus> "QUESTION" do we need to install any kind of antivirus ?
[18:35] <CheeseBurg> jcastro: Awesome with the owncloud thing!
[18:36] <jcastro> https://code.launchpad.net/~jorge/charms/bundles/owncloud/bundle
[18:36] <jcastro> but currently it's an old version of owncloud, but someone is working on it
[18:37] <ubuntu-guy> they are as a user
[18:38] <fcumbadass> QUESTION do you/anyone in the team see anything in the future in wearable tech?
[18:39] <Guest84857> Contest url
[18:39] <Guest84857> ?
[18:39] <CrazyHair> "QUESTION" could you please reshare the link, u just talked about here?
[18:39] <ubuntu-guy> "QUESTION" do you still need no anti-virus even for malware that is cross platform that for example targets java?
[18:39] <mhall119> Guest84857: http://developer.ubuntu.com/showdown/
[18:39] <Paddy_NI> Okay I'm an idiot I thought Ubuntu on Air was currently live! I have just been mind farting into this channel thinking it was live
[18:40] <jeffrey_f> QUESTION: If no priority for a free small version of Landscape, is there any way now or into the future to manage a small collection of systems/desktops?
[18:40]  * Paddy_NI facepalm
[18:40] <Guest84857> ty
[18:41] <aladdin> "QUESTION" : sorry if it's out the topic, what will be the audio/video IM on Ubuntu ? Will you have a partnership with another company or will you push WebRTC  app ??
[18:41] <Dipesh> "QUESTION" Can you send me the project link of raspberry pi with ubuntu os
[18:42] <Paddy_NI> jcastro: I must apologise for the garbage, I thought this was live XD
[18:43] <jeffrey_f>  Thanks!
[18:44] <CheeseBurg> QUESTION: Is there a timeline for Unity 8 Desktop session?
[18:44] <jcastro> http://www.theopensourcerer.com/2013/11/building-ubuntu-for-the-raspberry-pi/
[18:44] <jcastro> Dipesh, ^
[18:46] <Dipesh> thanks..
[18:46] <ubuntu-guy> "QUESTION" will ubuntu ever become a rolling release distro as then you would not need to patch a kernel like you do for 14.04
[18:47] <Nivex> QUESTION: What kind of testing does Ubuntu do with IPv6? How well would it do on an IPv6-only network at this point?
[18:47] <CheeseBurg> QUESTION: Is there any plans for redoing the audio on Ubuntu? Like how Mir is for display server
[18:47] <tuxkalle> QUESTION: What version is the latest for the phone ?
[18:48] <Nasacra> debian!!! :P
[18:48] <jcastro> ubuntu-devel is a rolling release. :)
[18:48] <tuxkalle> QUESTION: my nexus 4 doesen't look to install apps is it just me ?
[18:50] <DetroitDKush> Now that antialiasing is on ubuntu, Would it be possible to port Fallout games to be native on linux?
[18:51] <adsv> gucci?
[18:51] <adsv> gucci gucci
[18:51] <jagdeep> QUESTION: Why most of the games are released for windows not ubuntu ?
[18:52] <mhall119> jagdeep: directx
[18:52] <CheeseBurg> laters
[21:10] <lotfi> hello


[00:18] <DarkTrick> brainwash, interestingly enough, I could not start them via systemd
[00:19] <DarkTrick> brainwash, ah, so startup would only disable ./config/autostart/tracker*
[00:19] <DarkTrick> ?
[09:08] <brainwash> DarkTrick: exactly
[09:10] <brainwash> DarkTrick: therefore, it's not a bug in Xfce (unless you want Xfce to have an interface to configure systemd user services)
[09:42] <DarkTrick> brainwash, then it's not an Xfce bug, but an xubuntu bug, where would I report an xubuntu bug? Or could it be a ubuntu bug saying that tracker* is configured as `autostart` AND service, where it should really be only either one?
[09:43] <brainwash> DarkTrick: are you certain it is autostarted?
[09:43] <brainwash> it could be some application (Nautilus) starting it
[09:49] <DarkTrick> brainwash, I did not thoroughly analyze it, but they are getting started during bootup - even before logging in. I would guess nautilus is not yet present at that time (except there is some hidden feature of nautilus I'm not seeing)
[09:50] <DarkTrick> Also, if I change /usr/lib/systemd/user/tracker*.service to /usr/lib/systemd/user/tracker*.service.disabled they don't get started anymore
[09:54] <brainwash> you'll have to find out why they are enabled/activated by default
[09:55] <brainwash> could be packaging or an upstream decision -> GNOME
[09:55] <DarkTrick> by "they" you mean the services or the "autostarts"?
[09:56] <DarkTrick> brainwash, ↑
[10:02] <brainwash> DarkTrick: tracker and its miners
[10:04] <brainwash> you apparently don't want them to run
[10:04] <DarkTrick> brainwash, well.. I think they are enabled because they are part of the system, I guess?
[10:04] <DarkTrick> So having them autostarted by default is not the problem I see
[10:05] <brainwash> ah okay
[10:05] <DarkTrick> (sorry, miscommunication :/ )
[10:05] <DarkTrick> The problem is, that they are not easily disable-able
[10:06] <brainwash> you can disable them via systemctl
[10:06] <DarkTrick> because they apparently get autostarted from two different positions: ~/.config/autostart and through systemd
[10:06] <DarkTrick> regarding xubuntu the problem arises, when using "session and startup", because the user *thinks* they have disabled it, while it is still started by systemd
[10:07] <DarkTrick> so the system is not clear towards the user
[10:08] <brainwash> isn't this true for pulseaudio too?
[10:08] <brainwash> it has an autostart launcher I think
[10:10] <brainwash> another example is xfsettingsd which has an autostart entry, but Xfce starts it anyway as part of the session
[10:10] <brainwash> the entry is meant as fallback
[10:11] <brainwash> maybe that's the case for tracker too
[10:12] <DarkTrick> brainwash, this sounds to me, that the system is even more flawed in this area
[10:13] <DarkTrick> If the user can turn something off, that gets started anyway, that's the system lying to the user
[10:14] <DarkTrick> The question would then be: who is is charge (project) and what is to change...
[10:22] <brainwash> the system isn't lying
[10:23] <brainwash> I don't know how to solve this
[10:23] <brainwash> https://docs.xfce.org/_media/xfce/xfce4-session/xfce4-session-preferences-autostart.png
[10:24] <brainwash> that info text is gone in Xfce 4.16
[10:27] <brainwash> my idea was to add a hint to explain that autostart can be done through other ways also
[10:30] <DarkTrick> brainwash, thank you for your input. I guess I'll go with a "config problem" for now. As it seems this also happens on ubuntu, I will move the bug there and see what happens.


[00:06] <jcsackett> wallyworld_: Don't know if you want to chat, but I'm back if you want to. Hackerspace meeting ran long.
[00:06] <wallyworld_> jcsackett: sure, just give me a minute
[00:07] <jcsackett> Anytime. Going to have to be irc tho. Too loud here for anything else. PM me when you want.
[00:12] <wallyworld_> jcsackett: tl;dr; we will be adding a (+)Team link to the person picker, will transition picker content to simplified add team form like we do for confirmation stuff in the picker
[00:12] <wallyworld_> this outcome is different to what you discussed with sinzui yesterday
[00:13] <jcsackett> Yeah. Y'all convinced him?
[00:14] <wallyworld_> jcsackett: we also need to look at simplifying the open/closed team choices from 4 radio buttons down to 2 choices (open/close) with an option checkbox for each (thus providing the 4 scenarios)
[00:14] <wallyworld_> we talked it through
[00:14] <wallyworld_> was a good discussion
[00:14] <wallyworld_> jcsackett: i believe you will be asked to look at the open/closed policy choices as per the above
[00:15] <jcsackett> Cool. I'll bug sinzui about it tomorrow then. :-)
[00:15] <wallyworld_> and then we can combine that work with the new picker/overlay form
[00:15] <wallyworld_> sounds good
[00:24] <wallyworld_> StevenK: were there no other soyuz vocab tests you could add to? ie did you have to create a new test module just for that one test?
[00:30] <wallyworld_> wgrant: we have a small workflow issue. share all es with aaa. subscribe aaa to es bug. no aag created because apg exists so bug is visible. change sharing permission for es for aaa to some. bug not visible and no aag created
[00:39] <wgrant> wallyworld_: Yeah, that's where conflating subscription and visibility continues to be awkward..
[00:39] <wgrant> wallyworld_: I suspect we should just create the usual revocation job and remove the subscription.
[00:40] <wallyworld_> wgrant: not sure that's the best thing to do. i mean the user intent is to be subscribed to that bug still, but only see that and not all other private things
[00:42] <wgrant> wallyworld_: Doesn't that same argument apply to the team's members?
[00:43] <wallyworld_> in which scenario?
[00:43] <wgrant> eg. foo a member of bar, foo is subscribed to an artifact on a policy on which bar has an APG
[00:43] <wgrant> bar's APG is revoked.
[00:43] <wgrant> Possibly changing to Some.
[00:43] <wgrant> Or to None.
[00:44] <wallyworld_> yes, the case for apg revocation converting existing subscriptions to aag should be transitive
[00:44] <wallyworld_> maybr
[00:45] <wallyworld_> no, i mean the team gets the aag
[00:45] <wallyworld_> and then the members can see the bug while they remain in the team
[00:46] <wgrant> That's illegal
[00:46] <wgrant> Since the team doesn't have a subscription.
[00:46] <wgrant> It can't have an AAG.
[00:46] <StevenK> wallyworld_: There are no other Soyuz vocab tests that I could find.
[00:47] <wallyworld_> really? that's not good
[00:47] <wallyworld_> not even in doc tests?
[00:48] <StevenK> wallyworld_: I grepped the entire tree for the vocab names
[00:48] <wallyworld_> wgrant: my assumption was the team did have a subscription, but if not, then i think what you say sounds ok
[00:49] <wallyworld_> StevenK: r=me
[00:51] <wallyworld_> wgrant: so everything looks ok so far on qas with the triggers removed, except for an oops in the job created when a team member is removed.
[00:51] <StevenK> wallyworld_: Thanks, I've tossed it at ec2.
[00:51] <wgrant> wallyworld_: What's that OOPS?
[00:51] <wallyworld_> OOPS-96532e891268827ddb456c0488c160ef
[00:51] <wallyworld_> i haven't looked at it yet, created a card
[00:59]  * wallyworld_ goes to get key cut, bbiab
[01:08] <StevenK> wgrant: So, query?
[01:12] <wgrant> StevenK: The query itself is probably fine.
[01:12] <wgrant> But we likely want an index on access_policy
[01:13] <StevenK> There is one?
[01:14] <StevenK> The EXPLAIN ANALYZE mentions an index scan
[01:14] <wgrant> It was probably an index scan on information_type.
[01:16] <wgrant> However
[01:16] <wgrant> There's few enough private branches that that might not be a problem.
[01:18] <StevenK> wgrant: It's worse with an index on access_policy
[01:19] <StevenK> wgrant: http://pastebin.ubuntu.com/1050184/ both hot, top is without the index on access_policy.
[01:20] <wgrant> StevenK: Try now
[01:22] <StevenK> wgrant: Same as the top one
[01:22] <wgrant> StevenK: Also, what's the actual query you're using?
[01:23] <StevenK> wgrant: Oh, sorry. http://pastebin.ubuntu.com/1050188/
[01:25] <wgrant> So, that's not quite the actual query.
[01:25] <wgrant> The real thing will have a LIMIT foo at the end
[01:37] <StevenK> wgrant: http://pastebin.ubuntu.com/1050199/
[01:38] <wgrant> StevenK: It seems to be fine without the extra index.
[01:38] <wgrant> Not marvellously fast.
[01:38] <wgrant> But the public branches aren't clustered badly enough that it will be a problem.
[01:43] <cjwatson> Is utilities/prioritygrid.py in use any more?  It looks obsolete since I don't believe those wiki prioritisation tables are being used any more (?).  Maybe 146 easy LoC for somebody.
[01:47] <lifeless> nuke from orbit
[01:48] <StevenK> wgrant: Right, so do you want to approve the MP, then?
[01:49] <cjwatson> lifeless: righto, will do
[01:50] <wgrant> StevenK: Done
[01:50] <lifeless> cjwatson: classic NIH stuff that
[01:51] <lifeless> cjwatson: https://dev.launchpad.net/VersionThreeDotO/Soyuz/Inputs - last edit 2009
[01:53] <wgrant>     def __getitem__(self, name):
[01:53] <wgrant>         for series in self.series:
[01:53] <wgrant>             if series.name == name:
[01:53] <wgrant>                 return series
[01:53] <wgrant>         raise NotFoundError(name)
[01:53] <wgrant> wtf
[03:21] <wgrant> wallyworld_, StevenK: Extremely challenging review for one of you: https://code.launchpad.net/~wgrant/launchpad/bug-1015289/+merge/111139
[03:22] <wallyworld_> wgrant: looks ok to me, i assume we have an approximatedate tal formatter
[03:22] <wallyworld_> there are no tests needing updating?
[03:22] <lifeless> wallyworld_: wgrant: if you guys have FDT pending stuff, I'm willing to grant exceptions to the one-patch-per rule; I'll be updating docs shortly to reflect that.
[03:23] <lifeless> needs to route through me or flacoste on a case by case basis.
[03:23] <wgrant> wallyworld_: All the tests use sampledata, so they're a bit awkward to test this with. It's the formatter we use for dates basically everywhere, so I don't think tests are very useful.
[03:23] <wgrant> lifeless: We deployed the last of the two week-long batches on Monday.
[03:24] <wallyworld_> wgrant: ok, r=me
[03:25] <wgrant> wallyworld_: Thanks.
[03:25] <wallyworld_> np
[03:31] <StevenK> lifeless: Oh, because I don't do DB patches? :-P
[03:31] <lifeless> StevenK: because you haven't been whinging about it :)
[03:32] <lifeless> StevenK: (actually, I forgot to ping you as well, mea culpa)
[03:32] <StevenK> lifeless: wgrant is very good at whinging, so I've been letting him play to his strengths ...
[03:33] <lifeless> LOL
[03:36] <wgrant> Heh
[04:04] <wgrant> Ah, 8-way UNION ALLs, my favourite.
[04:14] <lifeless> wgrant: the openid thing thats terrible, or something else ?
[04:19] <wgrant> lifeless: My bugsummary recalculator.
[04:19] <wgrant> lifeless: The OpenID thing being the name-generation timeout you pointed out yesterdayish?
[04:19] <lifeless> funky chicken
[04:19] <lifeless> wgrant: is that what it was?
[04:20] <wgrant> lifeless: Yeah
[04:20] <wgrant> email address started with launchpad@
[04:20] <lifeless> wgrant: win.
[04:20] <wgrant> So it tried to generate a nick from that
[04:20] <wgrant> Conflict, so add number
[04:20] <wgrant> Conflict, so increment number
[04:20] <wgrant> Conflict, so increment number
[04:20] <wgrant> Conflict, so increment number
[04:20] <lifeless> haha
[04:21] <wgrant> Although we may have another bug, since there aren't *that* many, I don't think.
[04:21] <lifeless> perhaps it should select count(*) from person where name like 'prefix-%' instead.
[04:24] <lifeless> and docs updated
[04:24] <lifeless> -> to buy a PC powersupply for his reprap
[04:25] <wgrant> My god
[04:25] <wgrant> The algorithm isn't actually that stupid
[04:25] <wgrant> It's even worse
[04:25] <wgrant> I don't even...
[04:25] <wgrant> what the heck is it trying to do
[04:25] <mwhudson> does the name blacklist get in on the fun too?
[04:25] <wgrant> (for those playing at home, it gets from 'launchpad' to '78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgs-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze')
[04:26] <mwhudson> actual lol
[04:26] <mwhudson> (must be tired)
[04:26] <StevenK> Oh my ...
[04:26] <wgrant> So it tries to add a random suffix.
[04:26] <wgrant> Then a random prefix
[04:26] <wgrant> Then mutate a character
[04:26] <wgrant> Then a prefix and a suffix
[04:27] <wgrant> Then all three
[04:27] <wgrant> And somehow it gets 78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgs-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze
[04:27] <wgrant> Still
[04:27] <wgrant> Not as bad as it could have been
[04:27] <wgrant> It does up to 1000 attempts
[04:28] <wgrant> Each of which adds a character to the prefix and suffix, and mutates the name further
[04:28] <lifeless> wgrant: how did it get to the number it got to ?
[04:28] <wgrant> So if we didn't ahve the timeout...
[04:28] <wgrant> I suspect it's because it contains launchpad
[04:28] <wgrant> So is blacklisted
[04:28] <lifeless> hah
[04:28] <wgrant> Hm
[04:28] <lifeless> so, just plain fail.
[04:28] <wgrant> Except then the mutation should pass
[04:28] <wgrant> So maybe not
[04:29] <wgrant> Hmmmmmmmmmmmmmmmm
[04:29] <wgrant> mmmmmmm
[04:29] <wgrant> mmmmmmm
[04:29] <wgrant> mmmmmm
[04:29] <wgrant> The mutation it ends up with is cdpq7ln4t
[04:29] <wgrant> Which is already the name of a person
[04:29] <wgrant> Surely we don't actually start with a predictable seed.
[04:29] <wgrant> ROFL
[04:29] <wgrant> ROFL
[04:29] <lifeless> whatever could go wron with that ?
[04:29] <lifeless> back soon, to hear the end of the story
[04:30] <wgrant>     # We seed the random number generator so we get consistent results,
[04:30] <wgrant>     # making the algorithm repeatable and thus testable.
[04:30] <wgrant>     random_state = random.getstate()
[04:30] <wgrant>     random.seed(sum(ord(letter) for letter in generated_nick))
[04:30] <wgrant> Hahahahahahah
[04:30] <mwhudson> ah uh what
[04:30] <wgrant> Because that's a good idea.
[04:31] <mwhudson> i presume this means there are some truly comedy nicks already
[04:31] <wgrant> So because so many people have a local user part of 'launchpad'...
[04:31] <wgrant> yes
[04:31] <wgrant> that
[04:31] <wgrant> Checking for just what we have...
[04:31] <wgrant> That must mean that 78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgs-cdpq7ln4t-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze already exists
[04:31] <wgrant> Or it's too long
[04:32] <wgrant> http://launchpad.net/~78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgs-cdpq7ln4t-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze :)
[04:32] <mwhudson> https://launchpad.net/~78luphr-lannyuwgd-a811i2i
[04:32] <mwhudson> hahahahahahahahahahahahaha
[04:32] <mwhudson> ahah
[04:33]  * mwhudson runs out of breath
[04:33] <wgrant> I'd seen crazy stuff like this before
[04:33] <wgrant> But assumed it was just users being strange
[04:33] <mwhudson> given
[04:33] <mwhudson>             "This should be impossible to trigger unless some twonk has "
[04:33] <mwhudson>             "registered a match everything regexp in the black list.")
[04:33] <mwhudson> i'd be inclined to blame SteveA
[04:33] <wgrant> Nah
[04:33] <wgrant> Not really
[04:33] <mwhudson> (probably not for the seeding though)
[04:33] <wgrant> Back in his day it included the domain
[04:33] <mwhudson> ah
[04:34] <wgrant> But we stopped including the first segment of the domain because people complained it gave away their email address.
[04:34] <mwhudson> heh
[04:34] <mwhudson> sha256 the address instead? :)
[04:34] <wgrant> launchpad_dogfood=# SELECT COUNT(*) FROM person WHERE name LIKE '78lup%';
[04:34] <wgrant>  count
[04:34] <wgrant> -------
[04:34] <wgrant>    306
[04:34] <wgrant> And that's less than half of them.
[04:35] <mwhudson> length(name) > 100 ?
[04:35] <mwhudson> or whatever the sql is for that
[04:36] <wgrant> 275
[04:36] <mwhudson> oof
[04:36] <wgrant> Lots of those are deactivatedaccount, though
[04:37] <wgrant> Lots is actually only 14
[04:37] <StevenK> Lots, in troll.
[04:37] <wgrant> Most of the rest are the 78luphr things
[04:37] <wgrant> Except for the ones that are generated from ubuntu@ instead of launchpad@
[04:37] <wgrant> eg. mrzx4l98d4tp89jab6giohdrjqysbyjs4npz2ccq25kvjmf5h8u4cmidcko7s4tfr6ur1teuv4ju1af4k-bp84z2-hwbqs6tox1bv6csee9psn5309v7488f3dugifm692db2xfq8n1fsz7l87835tr0q36m2p3ftwpoqoy6v6
[04:38] <StevenK> Memorable.
[04:38] <wgrant> admin@ and info@ are also not uncommon
[04:39] <mwhudson> https://launchpad.net/~mrzx4l98d4tp89jab6giohdrjqysbyjs4npz2ccq25kvjmf5h8u4cmidcko7s4tfr6ur1teuv4ju1af4k-bp84z2-hwbqs6tox1bv6csee9psn5309v7488f3dugifm692db2xfq8n1fsz7l87835tr0q36m2p3ftwpoqoy6v6 -> "Are you Ubuntu?"
[04:39] <wgrant> Heh
[04:39] <mwhudson> "we are all ubuntu!"
[04:41] <StevenK> Ubuntu does not use Launchpad. This page was created on 2012-05-03 when the landscape-api_12.04+bzr4143-0ubuntu1.8.04+jenkins547 package was uploaded to hardy/RELEASE.
[04:41]  * StevenK cackles
[04:45] <wgrant> So
[04:45] <wgrant> Things that shouldn't be deterministic:
[04:45] <wgrant>  - Collision resolution algorithms
[04:53] <lifeless> indeed.
[05:18] <StevenK> steven@undermined:~/launchpad/lp-branches/destroy-old-privacy-ui% bzr di | diffstat -s
[05:18] <StevenK>  20 files changed, 72 insertions(+), 425 deletions(-)
[05:19] <StevenK> I am disappoint.
[05:20] <wgrant> StevenK: Must have missed some stuff.
[05:22] <StevenK> wgrant: But where?
[05:23] <wgrant> Yes.
[05:23] <StevenK> steven@undermined:~/launchpad/lp-branches/destroy-old-privacy-ui% bzr grep show_information_type_in_ui
[05:23] <StevenK> steven@undermined:~/launchpad/lp-branches/destroy-old-privacy-ui% bzr grep show_information_type_in_branch_ui
[05:23] <StevenK> steven@undermined:~/launchpad/lp-branches/destroy-old-privacy-ui%
[05:25] <StevenK> I'm going to toss it at ec2 and see how much carnage there is.
[05:25] <lifeless> wgrant: did you file a bug about th eappserver src ip visibility ?
[05:29] <wgrant> lifeless: No.
[05:31] <lifeless> wgrant: will you?
[05:33] <wgrant> lifeless: Not unless there's a good argument for it :)
[05:35] <lifeless> the law isn't good enough?
[05:37] <wgrant> The DPA doesn't, AFAIK, say "Launchpad engineers aren't allowed to see source IP addresses in request logs to diagnose operational issues"
[05:38] <wgrant> That may be implied somehow, but I haven't seen an argument to that effect.
[05:38] <wgrant> Perhaps there is a wiki page on this.
[05:42] <stub> Huh. So I accidentally landed my branch by using bzr lp-land instead of ec2 land yesterday, and reverted when this was noticed due to buildbot failure. I then ran ec2 land as intended. And it landed, and buildbot is green.
[05:44] <stub> The errors buildbot yesterday looked like they should consistently fail too...
[05:44] <wgrant> stub: What was the buildbot failure like?
[05:44] <wgrant> stub: It was only on the non-real buildbot.
[05:44] <wgrant> So it might have been using 8.4, for example
[05:45] <stub> ohh.... that would explain it
[05:45] <stub> xx-dbpolicy thinking the slave was the master etc.
[05:45] <wgrant> I don't know what gary's setup is these days.
[05:45] <wgrant> But it's reasonable plausible that it's still on 8.4, since we haven't used 9.1-specific stuff yet.
[05:45] <wgrant> Hm
[05:46] <wgrant> Except I think StevenK did last week
[05:46] <stub> Real buildbot is green so the landing is good.
[05:46] <wgrant> 2209-16-6 uses ORDER BY in an aggregate, so that should have weeded out any 8.4 installations
[05:46] <wgrant> Do you recall the traceback?
[05:47] <stub> It must have been some other buildbot - can't see read on the board
[05:48] <wgrant> It was an ephemeral parallel buildbot test from gary.
[05:48] <wgrant> It's gone now.
[05:48] <wgrant> Anyway, let's migrate staging to streaming replication now :)
[05:48] <stub> yer, looks like an ec2 instance in my history
[05:48] <wgrant> Right? :)
[05:49] <stub> yes, that is what this landing is. when it is on staging and qastaging, I can convert the staging dbs.
[05:49] <lifeless> wgrant: its the conclusion of IS, after discussion with legal etc.
[05:50] <stub> Unfortunate side effect - at the moment, we have a single cluster so all the RAM on sourcherry can be dedicated to it. With the new setup, we have to run two clusters so ram usage will be less optimal because we will have two copies of the hot set in shared_buffers, and probably should reduce shared_buffers too.
[05:50] <stub> no, that isn't quite right.
[05:51] <stub> but it will still be less optimal, as load isn't split 50/50.
[05:51] <wgrant> lifeless: Is this insanity documented anywhere? :/
[05:52] <lifeless> wgrant: rt 52417
[05:52] <lifeless> wgrant: I wanted a solid ruling, so I sought clarity.
[05:52] <wgrant> Doesn't this also mean that non-EU sysadmins shouldn't be able to see it?
[05:52] <wgrant> Since that would involve transferring the data to somewhere outside the EU
[05:53] <lifeless> wgrant: I'm not going to go seeking trouble; elmo has presumably walked through all of that
[05:53] <lifeless> wgrant: the issue for our purposes is sysadmin/non-syadmin/reason-for-access
[05:56] <wgrant> brb, starting new planet
[05:58] <wgrant> I guess sysadmins will have to do all further analysis of load issues.
[05:58] <bigjools> did you remember the Genesis device?
[05:58] <lifeless> yes
[05:58] <lifeless> wgrant: I think thats an extreme proposition to take
[05:59] <wgrant> Nah, the extreme (but probably correct) position here is the EU should be involved purely because of batshit insane laws like this.
[05:59] <wgrant> s/involved/dissolved/
[05:59] <lifeless> actually, if we operated in NZ, we'd have similar constraints
[05:59] <lifeless> EU is in no way a special snowflake
[06:00] <stub>  hey, some of us like batshit insane laws protecting privacy :)
[06:01] <bigjools> wgrant has a point - the EU should be dissolved for plenty of reasons :)
[06:01] <wgrant> stub: Filtering source IP addresses from the engineers operating the service is hardly protecting privacy in any useful manner :)
[06:03] <stub> Assuming benevolent engineers
[07:41] <wgrant> Ah
[07:42] <wgrant> The initial bugsummary population query counted assignees in viewed_by, but the triggers to maintain it did not.
[07:43] <wgrant> That explains some of the drift.
[08:03] <adeuring> good morning
[08:21] <cjwatson> wgrant: Thanks for your review of https://code.launchpad.net/~cjwatson/launchpad/gina-deb-vendor-debian/+merge/111120.  I made that correction; could I have "Status: Approved"?
[08:22] <wgrant> cjwatson: Sorry, probably had too many MPs open so the request didn't make it through before I closed the tab. Fixed.
[08:22] <cjwatson> Thought so, thanks.
[08:31] <lifeless> wgrant: \o/
[08:32] <lifeless> wgrant: (finding a/the bug)
[08:32] <wgrant> lifeless: It's one of the bugs, but there's at least one other that there's probably no hope of ever finding.
[08:32] <wgrant> I suspect it's gone now.
[08:54] <ivory> frankban: could you review this? https://code.launchpad.net/~ivo-kracht/launchpad/bug-425934/+merge/110786
[08:55] <frankban> ivory: sure
[08:56] <ivory> frankban: thx
[09:39] <cjwatson> Dear qastaging, would you care to be any slower?  I'm sure it's possible.
[09:39]  * czajkowski hands cjwatson a baseball bat
[10:47] <cjwatson> wgrant: Re the pcj-reupload / PermissiveSecurityPolicy discussion from last night: the test that fails if I ditch that removeSecurityProxy is lib/lp/soyuz/stories/ppa/xx-ppa-files.txt:274.  Is it even possible to run PermissiveSecurityPolicy stuff within pagetests?
[10:47] <cjwatson> It certainly isn't obvious how to e.g. change the layer to something zopeless.
[10:49] <cjwatson> I suppose I could change that code to run Archive.copyPackage rather than running do_copy directly, but ISTM that that would just move the problem to one of how to run the job in-place with a permissive security policy
[11:11] <mpt> "Visible only to users with whom the project has shared embargoed but you've stopped reading by this point anyway."
[11:11] <jml> :)
[11:18] <mpt> (reported as bug 1015509)
[12:25] <wgrant> cjwatson: Yeah, pagetests will be a problem there.
[12:45] <adeuring> frankban: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-29713/+merge/111212 ?
[12:46] <frankban> adeuring: on it in a minute
[12:46] <adeuring> frankban: thanks!
[12:47] <adeuring> stub: since this MP adds a DB patch file, you might want to have a look too, though it's just a change of ftq() and _ftq(): https://code.launchpad.net/~adeuring/launchpad/bug-29713/+merge/111212
[12:53] <stub> adeuring: Ta. I'll look at it later. Not sure if this counts as a db patch or a code patch really with all that python.
[12:53] <adeuring> stub: yeah, but formally it's a DB patch ;)
[12:54] <stub> adeuring: I think the old code duplication between _ftq and ftq was because we were generating it from a single source. Making one depend on the other now is a good move.
[12:54] <adeuring> thanks :)
[13:01] <StevenK> stub: Can you tag the bug related to r15444 as 'qa-bad bad-commit-15444' ?
[13:02] <StevenK> Hmmm, and then it lands in r15448.
[13:50] <cjwatson> What happened to http://lpqateam.canonical.com/qa-reports/deployment-stable.html?
[13:51] <cjwatson> (404)
[13:52] <james_w> looks like maybe the vhost is now served by something else on the same machine?
[13:52] <james_w> http://lpqateam.canonical.com now looks suspiciously like https://lpbuildbot.canonical.com/
[13:53] <cjwatson> Yes, quite
[13:54] <cjwatson> (Only without HTTPS/openid)
[13:55] <cjwatson> webops: lpqateam.canonical.com appears broken - see above
[13:55] <cjwatson> james_w: weirdly, those two aren't on the same IP address
[13:55] <gnuoy> I'll take a look
[13:56] <mthaddon> cjwatson: interesting, I suspect that's me - checking
[13:57] <cjwatson> mm, wrong VirtualHost in /etc/apache2/sites-enabled/lpbuildbot.canonical.com perhaps
[13:57] <mthaddon> cjwatson: sorry about that, fixed
[13:57] <cjwatson> thanks
[14:04] <deryck> adeuring, https://plus.google.com/hangouts/_/698ee8339ef1f2f3cbdce4185991264b12204423?authuser=0&hl=en
[14:05] <stub> StevenK: Did I break qatagger?
[14:12] <sinzui> jcsackett, we have a busy day today. I think we have a check point in 20 minutes and I need to inform you of the revelations about creating a team
[14:16] <jcsackett> sinzui: yeah, i talked a bit with wallyworld_ about it last night, but i def need more info.
[14:17] <jcsackett> you want to talk post-checkpoint?
[14:17] <sinzui> yes.
[14:17] <jcsackett> cool. long round of meetings then. i better go make more coffee. :-P
[14:17] <sinzui> Maybe we can hijack the hangout
[14:17] <jcsackett> i'm fine with that.
[16:40] <gary_poster> stub, I suspect (hope for your sake) that you are long gone, but just in case, http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/15448 is causing failures on the parallel test machine.  the default flavor of stores that we are getting in the failing tests is master, not slave, which appears to be the source of the errors.  I can't duplicate locally, but I duplicate every time, including across new
[16:40] <gary_poster> machines, on EC2.
[16:40] <gary_poster> Failures look like this: http://ec2-184-72-208-228.compute-1.amazonaws.com:8010/builders/lucid_db_lp/builds/0/steps/shell_9/logs/summary
[16:40] <gary_poster> I can duplicate on the EC2 machine trivially, just by running the first test in the lxc container in isolation.
[16:41] <gary_poster> the store provides IMasterStore, not ISlaveStore.
[16:41] <gary_poster> I'm digging in, but three reliably failing tests is a big step back for us
[16:41] <gary_poster> so help would be appreciated.
[16:42] <gary_poster> I'll send you a note at my EoD to let you know where we are with this, one way or the other
[16:42] <stub> gary_poster: yo
[16:43] <gary_poster> oh, hey stub!  I'm sorry you are still around :-)
[16:43] <stub> so it went through ec2 and buildbot fine. I'm not sure why it fails there, but a start would be to confirm PG 9.1
[16:44] <gary_poster> stub, yeah, I saw it passed everywhere else fine, and I have not been able to dupe locally at all
[16:44] <gary_poster> and yes, just verified the verification: the machine is running 9.1
[16:44] <gary_poster> well, to be precise--
[16:45] <gary_poster> 9.1.4-1~lucid4
[16:46] <stub> xx-dbpolicy.txt is the interesting one. Others will be fallout I assume.
[16:46] <stub> We seem to be in master only mode
[16:46] <gary_poster> right
[16:46] <gary_poster> lp.services.webapp.tests.test_dbpolicy.LaunchpadDatabasePolicyTestCase.test_defaults is really just the same thing
[16:47] <gary_poster> when I put a pdb in there, it says that the store implements master
[16:47] <stub> getting timeouts on launchpad...
[16:47] <gary_poster> yeah, me too, but it eventually loaded
[16:48] <stub> gary_poster: It is valid to get the master store if you are asking for a slave store. We need to trace that to see why it is deciding to do that. For this, it would mean the lag is too high and it considers the slave useless.
[16:48] <gary_poster> oh
[16:48] <gary_poster> ok
[16:49] <stub> +        streaming_lag = slave_store.execute(
[16:49] <stub> +            "SELECT now() - pg_last_xact_replay_timestamp()").get_one()[0]
[16:49] <stub> I think that is the only relevant line added
[16:51] <gary_poster> stub, in dbpolicy.py, in getStore, self.default_flavor == 'master'.  Is that consistent?
[16:51] <gary_poster> (this is in a pdb, I mean)
[16:52] <stub> test_dbpolicy.py is probably better to debug this I guess.
[16:53] <gary_poster> yeah, that's where I am
[16:53] <gary_poster> I got the lp.services.webapp.dbpolicy.LaunchpadDatabasePolicy
[16:54] <gary_poster> which in says the default_flavor is master, in code and in pdb, so I must have zigged when I should have zagged earlier, because it makes sense that the store should be a master once I'm here.
[16:55] <gary_poster> s/which in/which/
[16:55] <stub> gary_poster: So we attach the interface to the object we return from getStore? How could this happen then?
[16:57] <gary_poster> stub, I'm currently exploring whether lib/lp/services/webapp/adapter.py(848)get() should not have a LaunchpadDatabasePolicy from StoreSelector.get_current()
[16:57] <gary_poster> because once it does, afaict, we're on the wrong path
[16:57] <stub> gary_poster: and in that test, yes, it should be default of slave because we are testing the Slave policy
[16:58] <gary_poster> stub, so the following result is the wrong one--we should see some other policy class, right?
[16:58] <gary_poster> ((Pdb)) p StoreSelector.get_current()
[16:58] <gary_poster> <lp.services.webapp.dbpolicy.LaunchpadDatabasePolicy object at 0x134b76cc>
[16:59] <stub>    def setUp(self):
[16:59] <stub>         if self.policy is None:
[16:59] <stub>             self.policy = SlaveDatabasePolicy()
[16:59] <stub>         super(SlaveDatabasePolicyTestCase, self).setUp()
[17:00] <stub> so yeah, should be a slave policy
[17:00] <gary_poster> huh
[17:00] <gary_poster> ok, I'll do my pdb in that setUp
[17:01] <stub> I'd watch SlaveDatabasePolicyTestCase.setup
[17:01] <stub> It will not set the policy if it is not None, to avoid stoping on subclasses having already set it.
[17:01] <gary_poster> yeah that's what I meant; trying
[17:03] <gary_poster> whoa!
[17:03] <gary_poster> self.policy is not None
[17:03] <gary_poster> it is LaunchpadDatabasePolicy.
[17:03] <gary_poster> Who did that and why!
[17:04] <gary_poster> oh
[17:04] <gary_poster> it is a confusing test assembly
[17:05] <gary_poster> stub, notice the failing test is actually lp.services.webapp.tests.test_dbpolicy.LaunchpadDatabasePolicyTestCase
[17:05] <gary_poster> which has its won setUp
[17:05] <stub> oh
[17:05] <gary_poster> which sets the policy to LaunchpadDatabasePolicy
[17:05] <gary_poster> So now I'm wondering why it is working everywhere else
[17:06] <stub> DEFAULT_FLAVOR is decided on by the policy, it might be slave, might be master
[17:07] <stub> line 246 of dbpolicy.py
[17:07] <stub> That line should be hit, and I bet it isn't
[17:07] <stub> the getReplicationLag call above it is the new code I landed.
[17:08] <gary_poster> stub, the code I saw in pdb was getStore in the base class, not install
[17:09] <gary_poster> line 100 (with line 92) were the pertinent bits
[17:09] <gary_poster> oh
[17:09] <stub> gary_poster: Can you run "SELECT now() - pg_last_xact_replay_timestamp()" on one of your test dbs if you have one available from a paused test?
[17:09] <gary_poster> but then we set
[17:09] <gary_poster> k
[17:10] <stub> It should always be returning NULL since the database isn't replicated
[17:10] <stub> Unless I've misunderstood something, and your dbs are being setup differently
[17:13] <gary_poster> stub, I should be connecting to a db that looks something like launchpad_ftest_2391, yes
[17:13] <gary_poster> ?
[17:14] <stub> gary_poster: yes, that looks fine
[17:14] <gary_poster> stub, I get 02:17:48.970632
[17:14] <stub> 2 hours, 17 minutes.
[17:14] <stub> Bum.
[17:15] <stub> So how are you setting your databases up?
[17:15] <gary_poster> using lpsetup, which call launchpad-database-setup or whatever it is called.  Lemme get that code for us...
[17:15] <stub> nah, that is fine. it is the standard stuff.
[17:15] <stub> Hmm...
[17:16] <stub> I get null, lucid staging database 9.1.4...
[17:17] <stub> But I think this means my landing needs to be reverted, and I need to detect if the slave database is using pg 9.1 replication before doing that check.
[17:17] <stub> I'll double check the docs first.
[17:20] <gary_poster> stub, fwiw, the database is setup in line 222 of http://bazaar.launchpad.net/~canonical-launchpad-branches/lpsetup/trunk/view/head:/lpsetup/subcommands/install.py
[17:20] <stub> gary_poster: but parallel testing hasn't changed this?
[17:20] <gary_poster> hasn't changed what, stub?  We're using the same LP tree as everyone else, if that's what you mean
[17:20] <stub> database setup.
[17:21] <stub> If you start with 'make schema', it should all be fine.
[17:22] <stub> which is utilities/launchpad-database-setup, and that should be fine :-/
[17:22] <gary_poster> stub, we do run make schema.  results of all of that per-build setup are here:
[17:22] <gary_poster> http://ec2-184-72-208-228.compute-1.amazonaws.com:8010/builders/lucid_db_lp/builds/0/steps/shell_8/logs/stdio
[17:22] <stub> Unless perhaps your database crashed at some point and started up in recovery mode? Which would mean it replayed logs, and that function would return something.
[17:22] <gary_poster> We've gotten the LANG complaints forever.  We now know the cause but we haven't bothered to change anything
[17:23] <gary_poster> because it's been working fine up to now
[17:23] <stub> yer, I think I need to revert and not assume pg_last_xact_replay_timestamp() returns NULL on unreplicated systems.
[17:24] <gary_poster> stub, where would I look to see if we have the crash you expect?  or do you not want to bother?
[17:24] <stub> Don't bother.
[17:24] <gary_poster> ok cool
[17:24] <stub> If it can happen, it can happen.
[17:24] <gary_poster> ok
[17:25] <stub> This code needs to cope.
[17:25] <gary_poster> gotcha
[17:29] <gary_poster> stub, fwiw, I see this: http://pastebin.ubuntu.com/1051255/ .  That seems to align with the time frame that we are talking about.  I bet we are shutting down the lxc containers harder than postgres expects, so that's what it is complaining about.
[17:29]  * gary_poster likes tidy explanations
[17:29] <stub> gary_poster: Yes. So replication works the same was as recovery after a hard shutdown.
[17:30] <stub> The wal files are replayed to ensure the data files are correct.
[17:30] <gary_poster> gotcha
[17:30] <stub> Which makes my replication lag check return a value
[17:30] <stub> Bum.
[17:30] <gary_poster> gotcha. :-/
[17:31] <stub> I'll revert that again now
[17:31] <gary_poster> ok thanks stub, and thank you very much for helping so far past EoD
[17:31] <stub> np. I had a few hours in the middle off so am catching up :)
[17:33] <gary_poster> :-) cool
[18:12] <lifeless> stub: good $midnight?
[18:13] <stub> 1am?
[18:13] <lifeless> yowser :>
[18:13] <stub> gary defeated my cunning plans
[18:13] <lifeless> I see
[18:14] <czajkowski> is launchad the team that never sleeps!
[18:14] <lifeless> this is the team that goes on and on
[18:30] <stub> gary_poster: If you haven't messed with your evil postgresql installation, can you run 'SELECT pg_is_in_recovery(), pg_last_xact_replay_timestamp()' for me?
[18:31] <gary_poster> stub, sorry, you missed the window by seconds
[18:31] <stub> doh.
[18:31] <gary_poster> stub, although...
[18:31] <stub> I'll try and break my local install then :)
[18:31] <stub> unless...
[18:32] <gary_poster> (1) I got trunk after your branch and things were fine again, and (2) if you give me about five minutes, I can log into a running instance (with tests running) and do stuff there if that helps
[18:33] <gary_poster> or (3) I could kill the running tests and do stuff then.
[18:33] <gary_poster> any of those of interest, stub?
[18:33] <stub> Nah, I think I've reproduced it here (shutdown immediate with changes made but before checkpoint).
[18:33] <gary_poster> cool
[22:31] <wallyworld_> sinzui: wgrant: StevenK: jcsackett: link works now
[22:34] <wgrant> sinzui: http://launchpad.net/~78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgs-cdpq7ln4t-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze
[22:34] <wgrant> (that's where 'launchpad' gets you)
[22:34] <cjwatson> That's still the best URL ever
[22:34] <wgrant> The 'cdpq7ln4t' is 'launchpad'
[22:34] <wgrant> Mutated deterministically to avoid collisions.
[22:41] <cjwatson> wgrant: My theory is that Launchpad is trying to beat bug 255161 for the funniest bug ever.
[22:41] <_mup_> Bug #255161: I am unable to print from open office, I tried reinstalling open office but it did not work. I use a brother mfc240c printer and I am running Hardy. Printing from other apps has not been an issue. <OpenOffice:Invalid> <cupsys (Ubuntu):Invalid> < https://launchpad.net/bugs/255161 >
[22:49] <wgrant> cjwatson: Ah yes, I remember that one.
[22:49] <cjwatson> wgrant: Does http://paste.ubuntu.com/1051761/ look about right as a gina hack to make it not commit anything?
[22:49] <cjwatson> For dogfood
[22:49] <cjwatson> It has commits all over the place so it's a little awkward
[22:51] <wgrant> cjwatson: I think that's correct.
[22:52] <cjwatson> I won't try it until after I next regain consciousness, so there's a while to catch idiocies :-)
[22:53] <wgrant> Yep.
[23:28] <lifeless> wgrant: so, why don't we just count the matching things and add -(N+1) and be done with it ?
[23:31] <wgrant> lifeless: Because seeding an RNG deterministically is more fun.


[00:02] <xavierbick> Hello everyone, I saw this bug on launchpad (https://bugs.launchpad.net/juju-core/+bug/1336473) and wanted to submit a fix to github, but I'm not quite sure what the normal procedure is for contributing a bug fix to juju.  Can I just assign myself to the bug and mark it as in progress?
[00:02] <mup> Bug #1336473: Support new t2 instance types on AWS <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1336473>
[00:03] <davecheney> xavierbick: sure
[00:04] <xavierbick> great, thanks davecheney
[00:05] <perrito666> davecheney: I need to make the api server able to restart jujud with a given result from a FacadeCall, much like what happens for workers but in this case the call would answer to the client forwarding the result and then restart, yet I am not very sure where to add this
[00:07] <davecheney> perrito666: i think someone else asked this question recently
[00:07] <davecheney> menn0-afk: did you ask this recently
[00:12] <perrito666> davecheney: I send a similar question to the mailing list some time ago
[00:12] <perrito666> before understanding the actual problem fully
[00:17] <davecheney> ahh
[00:50] <perrito666> davecheney: that means you dont have an answerfor me right?
[00:50] <perrito666> :p
[00:53] <davecheney> perrito666: i'm not even sure I understand the question
[00:53] <perrito666> I most likely suck at explaining it
[00:54] <davecheney> perrito666: you want an api method to restart the apiserver, but not just exit the process ?
[00:54] <perrito666> Ill try to explain better, bear with me Its late :)
[00:57] <perrito666> I created a Client API method for Restore, which basically... restores :)
[00:58] <perrito666> now restore its a rather destructive thing which shuffles things around so, after finishing it I need to restart jujud
[00:59] <perrito666> so It was suggested by william that I should handle the return value of said call and restart jujud on a given result
[00:59] <perrito666> now, even if restarting jujud, I need to answer to the client first so it acknowledges that the command finished
[01:04] <davecheney> perrito666: i dunno
[01:04] <davecheney> i'd just do exit(0)
[01:08] <perrito666> davecheney: what I am not sure is where to :) there is a blurry area between state/api/client and state/apiserver/client :p which is not all that clear to me, even though is properly documented
[01:08] <perrito666> anyway, 31C at 11PM is too much for my brain I am going to sleep under the AC until the head clears off
[01:09] <perrito666> jam: if you read the abovewhen you arrive and have an answer please drop it here and Ill read it in the morning
[01:09] <davecheney> 31c, fuk that noise
[01:09] <perrito666> noise?
[01:10] <perrito666> 31°C <-- temp, fun fact, we are in the middle of winter
[01:10] <davecheney> bzzt
[01:40] <wallyworld> davecheney: that status bug has been fixed in trunk, i just backported to 1.20
[01:40] <wallyworld> you did the fix for trunk a little while back
[01:41] <davecheney> it's sort of a fix
[01:41] <davecheney> it's still shit
[01:41] <davecheney> we should just stop trying to carry on if api.GetStatus screws up
[01:58] <wallyworld> sure, but at least the nil pointer is fixed and 1.20 is consistent with master
[02:00] <wallyworld> axw: just otp, there soon
[02:00] <axw> wallyworld: nps
[02:05] <wallyworld> axw: ready now
[02:36] <katco> wallyworld: i need to take care of some things, but i think i addressed all the issues your brought up in https://github.com/juju/juju/pull/584
[02:37] <wallyworld> katco: awesome, thank you, will look
[02:37] <katco> wallyworld: no, thank you :)
[02:38]  * katco away for a bit, maybe for the night.
[02:42] <axw> wallyworld: just putting my desk back together, will bbs to review
[02:42] <wallyworld> sure
[03:26] <jam> perrito666: state/api/client is the actual user/client/not-the-server side of the code, and state/apiserver/client is the stuff running inside the API server. "client" in this case is that it is the set of "client facing" APIs (Status, Deploy, Upgrade, etc), not Agent facing APIs.
[03:27] <jam> perrito666: essentially everything in state/apiserver should be mirrored as state/api, the former being the one producing the API, and the latter being the one consuming it.
[03:28] <jam> perrito666: as for restarting gracefully, the worker/Upgrader code does this by raising UpgradeReadyError
[03:28] <jam> which signals up the worker/runner stack that we want to restart our process.
[03:28] <jam> However, that is being run in a *worker* not during an API call.
[03:29] <jam> I don't have an immediate "this is clearly how to do it" but we should probably take this to an on list discussion, so that fwereade et al can get in on the conversation
[03:52] <wallyworld> axw: manual provisioning question - in manual/provisioner.go, there's a ProvisionMachine() method; know the one i mean?
[03:55] <axw> wallyworld: yup?
[03:55] <wallyworld> in that method, we call args.Client.ProvisioningScript
[03:55]  * axw nods
[03:55] <wallyworld> and DisablePackageCommands will be false
[03:55] <katco> wallyworld: i have to go to bed, but i just pushed up more changes. thanks for the review.
[03:55] <wallyworld> katco: np, still going through it :-)
[03:55] <axw> wallyworld: orly? /me looks
[03:56] <wallyworld> katco: thanks for the effort :-)
[03:56]  * katco hands wallyworld a fine-toothed comb
[03:56] <wallyworld> lol
[03:56] <wallyworld> i don't have nits :-P
[03:56] <katco> wallyworld: yeah well, this has drug out long enough. i wanted to take advantage of you being online ;)
[03:56] <axw> wallyworld: DisablePackageCommands isn't set, so yes, it'll be false
[03:57] <wallyworld> axw: so that means we will run upgrade/update on manual machines, no?
[03:57] <katco> ok, sorry, off to bed. thanks again wallyworld, axw.
[03:57] <axw> wallyworld: ProvisioningSCript calls cloudcfg.SetAptUpgrade(false)
[03:57] <wallyworld> katco: night
[03:57] <axw> katco: night night
[03:58] <axw> wallyworld: the idea was that manual should only install what it needs, and not muck about with the machine otherwise
[03:58] <wallyworld> axw: oh, so it does, so it ignores the DisablePackageCommands
[03:59] <wallyworld> whereas now, we want to default to the current behaviour, but allow it to be overridden
[03:59] <axw> wallyworld: IIRC, DisablePackageCommands is set on the MachineConfig in the API server code
[04:00] <axw> wallyworld: probably do that in the API server code then, I think.
[04:00] <axw> apiserver/client
[04:00] <wallyworld> axw: it's not set all for the ProvisioningScript call
[04:00] <wallyworld> it's only set on machineconfig by the lxc container manager
[04:01] <axw> wallyworld: it is. look at state/apiserver/client/client.go
[04:01] <axw> there's a Client.ProvisioningScript method that sets up the MachienConfig, then calls manual.ProvisioningSCript
[04:03] <wallyworld> yes, i meant that nothing sets its value to true
[04:03] <axw> wallyworld: kapil's external code does :)
[04:03] <wallyworld> right
[04:03] <wallyworld> nothing in juju
[04:04] <wallyworld> so instead in juju we hard code disableaptupgrade to false
[04:04] <wallyworld> so now in the new branch, that is configurable
[04:04] <axw> wallyworld: upgrade is *always* false for manual, regardless of what you do. you can *also* disable update&install by setting DisablePackageCommands
[04:04] <axw> ok
[04:04] <axw> mmm
[04:05] <axw> yeah, that sounds fine
[04:05] <wallyworld> ie it defaults to disabled like now
[04:05] <wallyworld> but the user can choose to have their box upgraded if they want
[04:05] <axw> as long as it doesn't override DisablePackageCommands
[04:06] <wallyworld> that's the hard bit i'm pondering about - how to stay backwards compatible
[04:06] <wallyworld> since we don't know if DisablePackageCommands was explicitly set or not
[04:07] <wallyworld> if think if it is false, we use the new config settings
[04:07] <wallyworld> if true, we disable everything regardless of the settings
[04:08] <axw> wallyworld: +1
[04:08] <axw> wallyworld: the client side doesn't need to change at all
[04:08] <wallyworld> it's not "perfect", bu i think the best we can do
[04:08] <axw> just state/apiserver/client/client.go
[04:08] <wallyworld> yep
[04:09] <axw> manual.ProvisioningScript shouldn't force upgrade=false anymore, that needs to move into apiserver
[04:09] <axw> which has access to config
[04:11] <wallyworld> yep
[04:21] <menn0> wallyworld, thanks for dealing with bug 1359435
[04:21] <mup> Bug #1359435: Next version selection for upgrades is no longer correct <juju-core:Triaged> <juju-core 1.20:In Progress by wallyworld> <https://launchpad.net/bugs/1359435>
[04:22] <wallyworld> menn0: no problem, thanks for noticing the issue
[05:17] <wallyworld> axw: a small one https://github.com/juju/juju/pull/591
[05:18] <axw> looking
[05:20] <wallyworld> axw: thanks
[05:59] <davecheney> wallyworld: could you please kill http://juju-ci.vapour.ws:8080/job/github-merge-juju/390/console
[05:59] <davecheney> it's not going to pass and there is a large backlog behind it
[05:59] <wallyworld> davecheney: it will pass, why won't it?
[06:00] <wallyworld> that uniter failure happens all the time
[06:00] <wallyworld> passes 2nd time through
[06:01] <davecheney> wallyworld: ok,
[06:01] <wallyworld> davecheney: did i mention i hate our tests?
[06:14] <davecheney> wallyworld: to tell
[06:15] <wallyworld> of late, most runs require the fallback -p 2 to pass
[06:15] <wallyworld> i will be cataloging the failures and trying to get people to fix them
[06:18] <davecheney> wallyworld: +1 to turning off the retry
[06:19] <davecheney> tests pass or GTFO
[06:19] <wallyworld> i think so, we'll try and get an itemised list of failures first
[06:26] <davecheney> you'll have no shortage of canidates then
[06:47] <davecheney> wallyworld: i'll close with this graph, http://juju-ci.vapour.ws:8080/job/github-merge-juju/buildTimeTrend
[06:47] <davecheney> things clearly went wrong, around this commit waigani endpoint-on-bootstrap-take3
[06:47] <davecheney> not saying it was this commit
[06:48] <wallyworld> davecheney: yeah, early after the cutover, we were building in 18 or so minutes
[06:49] <wallyworld> we had hoped to get it down to 10 or 11 with the use of lxc or nail up instances
[08:02] <mattyw> morning folks
[08:11] <TheMue> morning
[08:14] <voidspace> TheMue: morning
[08:15] <voidspace> TheMue: I updated this PR to use errors.Annotate everywhere
[08:15] <voidspace> TheMue: https://github.com/juju/juju/pull/561
[08:15] <TheMue> voidspace: great, will take a look
[08:15] <voidspace> TheMue: I would appreciate a quick look for the sake of sanity when you have a moment
[08:15] <voidspace> thanks!
[08:16] <voidspace> TheMue: as I was touching the file I did all of the ones that were appropriate to change
[08:16] <voidspace> (in some cases there isn't an existing error to annotate of course, so those remain Errorf)
[08:16] <TheMue> voidspace: I’m still fighting with changing an existing API part into a new version. it’s a rattail :/
[08:16] <voidspace> fun
[08:17] <TheMue> voidspace: the errors package IMHO has useful funcs there too
[08:17] <voidspace> TheMue: ok
[08:18] <TheMue> voidspace: you’ve got a LGTM
[08:19] <voidspace> TheMue: awesome, thanks
[08:19] <voidspace> TheMue: and are you happy(ish) for me to merge the other PR without an additional test?
[08:19] <voidspace> TheMue: given that we concluded that we *do* test (in provider specific ways) that only the requested ports are open
[08:20] <TheMue> voidspace: here’s the errors package http://godoc.org/github.com/juju/errors
[08:20] <TheMue> voidspace: have to take a deeper look myself
[08:20] <voidspace> TheMue: thanks
[08:20] <voidspace> I will peruse
[08:20] <voidspace> I wonder how good the documentation is
[08:22] <TheMue> voidspace: and regarding the other PR I can live w/o another test, yes. it only have been more general thoughts about how to ensure that only the wanted ports are open. but that would be a huge change :)
[08:22] <voidspace> TheMue: and we have to open some ports in a provider specific way - as we have to specify some ports when we create the machine for some providers I believe
[08:22] <voidspace> as we need some ports immediately
[08:23] <voidspace> so a *general change* is maybe not even possible
[08:23] <voidspace> although we don't need the state port immediately just to bootstrap
[08:23] <TheMue> voidspace: yep, you’re right
[08:57] <Beret> wallyworld, nice update, thanks
[08:58] <Beret> wallyworld, we'll do all we can to get you more information when we hit those LXC issues
[08:58] <wallyworld> Beret: no problem and thank you
[10:30] <perrito666> morning all
[10:50] <voidspace> perrito666: morning
[10:50] <voidspace> dimitern: TheMue: standup?
[10:51] <TheMue> dimitern, voidspace: standup?
[10:51] <TheMue> voidspace: oh, just typed the same
[10:51] <voidspace> hah
[10:51] <TheMue> ;)
[10:51] <dimitern> voidspace, TheMue, sorry, brt
[13:00] <dimitern> voidspace, TheMue, others? networker refactoring branch - https://github.com/juju/juju/pull/593 , I'd appreciate a review when you have some time
[13:05] <wwitzel3> dimitern: I will take a look, I'm one of the on-call reviewers today :)
[13:06] <TheMue> dimitern: will look
[13:26] <dimitern> wwitzel3, TheMue, cheers guys!
[13:27] <perrito666> natefinch: 1:1?
[13:28] <perrito666> lol just saw the email
[13:35] <wwitzel3> man, trying to use our existing providers as a baseline for reviewing a new provider is turning out to be confusing.
[13:36] <wwitzel3> I feel like all our existing providers implement the same behavior as each other, just in a slightly different way.
[13:36] <wwitzel3> which provider should be considered the "gold standard"?
[13:36] <katco> wwitzel3: +1
[13:36] <katco> wwitzel3: i just did some work on providers, and i can't answer that.
[13:36] <mgz> wwitzel3: well, ah
[13:37] <mgz> they're all bad in different ways :)
[13:37] <katco> wwitzel3: if i had to guess, i'd say ec2 since it's probably been around the longest?
[13:37] <TheMue> wwitzel3: always the next one, which will make it all better
[13:37] <katco> TheMue: lol!
[13:38] <wwitzel3> I can distill these answers to "Yes, good luck"
[13:38] <wwitzel3> :D
[13:38] <TheMue> wwitzel3: +1
[13:39] <katco> wwitzel3: haha... well what are you trying to review? there are probably some concepts that in their pure form remain the same
[13:39] <wwitzel3> katco: the CloudSigma provider set of PRs
[13:39] <katco> wwitzel3: link to one?
[13:40] <wwitzel3> katco: https://github.com/juju/juju/pull/173
[13:41] <wwitzel3> katco: it is also the fact that it is just 2,000+ new lines. So there is no reference built in to the diff.
[13:41] <katco> wwitzel3: yeah, i see that! tough review...
[13:41] <wwitzel3> katco: that's why I'm trying to look to our existing providers as a reference / guide
[13:42] <katco> wwitzel3: yeah, i think i'd be doing what you are. and probably bouncing between ec2 which is probably the oldest, and maybe local which is one of the newer ones. or azure.
[13:43]  * katco dusts hands off. glad i could provide absolutely no value for you. ;)
[13:44] <wwitzel3> sanity checks are always helpful
[13:45] <perrito666> katco: well if you manage to make a career out of that you can become an argentinian real stateagent
[13:45] <wwitzel3> hah
[13:45] <katco> perrito666: i don't have it in me, unfortunately. it would drive me crazy.
[13:46] <perrito666> katco: there is good money in it and you can code while ignoring your customers
[13:47] <perrito666> fwereade: are you around?
[13:47] <fwereade> perrito666, yeah
[13:47] <katco> perrito666: lol
[13:47] <fwereade> perrito666, meant to ping yu this morning
[13:48] <fwereade> perrito666, you were asking last night about restarting the state server from within an api call?
[13:48] <perrito666> fwereade: heh yeah, our discussion the other day end up including more people and opinions and I am not entirely sure how to implement that :p
[13:48] <fwereade> perrito666, so, I have been 100% focused on leader-election things for the last day or two, I am probably missing context
[13:49] <perrito666> fwereade: Well I triedto implement that according to what we spoke, and suddenly I noticed that there was a gray area on state where I am not that familiar
[13:49] <fwereade> perrito666, are there concerns about the special-error approach?
[13:49] <fwereade> perrito666, ah, go on
[13:49] <fwereade> perrito666, I'd expect state to be out of the loop on that sort of question
[13:50] <perrito666> fwereade: the deal is, I am not entirely sure where is that I should be catching the error to ensure the client gets the response and trigger the restart (I might not be as good explaining myself as I think I am on this particular matter)
[13:53] <fwereade> perrito666, well -- somewhere after the function returns, and before it gets packaged up and sent back over the API
[13:53] <fwereade> perrito666, how many choices do you have there?
[13:54] <fwereade> perrito666, presumably it needs to be a layer that has, or can easily and sanely be given, access to the apiserver worker's tomb
[13:54] <fwereade> perrito666, so I would guess that the apiserver worker itself would be the right one to actually handle sending on the error to its runner
[13:54] <fwereade> perrito666, but I can well believe that we need another layer in there somewhere
[13:55] <fwereade> perrito666, I don't immediately recall what's actually in play there
[13:56] <perrito666> fwereade: as I get it th call propagates like this: apiclient->rpc layer->(X)->apiserver
[13:56] <perrito666> and I believe I should be standing in (X)
[13:56] <fwereade> perrito666, hmm, that sounds wrong
[13:57] <fwereade> perrito666, the apiserver needs to know that it should stop
[13:58] <fwereade> perrito666, and I think it has to finish the call, passing a "everything's good, restarting now!" response down via rpc, while arranging its own tidy suicide separately
[13:59] <perrito666> fwereade: I see, makes sense
[13:59] <fwereade> perrito666, possible approach: return result *and* error in that situation
[14:00] <fwereade> perrito666, in apiserver, define the error (type) that indicates "return these results and then terminate the api server with ErrStateRestored(?)"
[14:01] <fwereade> perrito666, except
[14:01] <fwereade> perrito666, can you really actually *do* the restore while everything's running?
[14:02] <fwereade> perrito666, what's the actual sequence of events?
[14:02] <perrito666> fwereade: yes, writing
[14:03] <natefinch> perrito666: standup?
[14:04] <perrito666> natefinch: getting there, I was looking for a webcam
[14:04] <perrito666> :p
[14:07] <TheMue> dimitern: great work, but I would like a second to take a look too
[14:08] <perrito666> fwereade: so this is how it works: [Bootstrap in safe mode][Upload File]<stop mongo><restore mongo><restore conf files for juju> <start mongo><restart jujud?>
[14:09] <fwereade> perrito666, then I don't quite understand where the API server comes in
[14:10] <fwereade> perrito666, ah: so immediately after you've bootstrapped, you tell the API server to do all that stuff?
[14:10] <perrito666> yup
[14:10] <perrito666> fwereade: so once I have a working api server I ask for it to perform the restore
[14:10] <fwereade> perrito666, and is the API server still responding to requests while this is going on?
[14:12] <perrito666> fwereade: mm I see where you are going, I could make API server deny requests, much like what upgrade does
[14:12] <perrito666> update
[14:12] <sinzui> natefinch, jam: We have a new regression. Can you find an engineer to fix or revert the problem? https://bugs.launchpad.net/juju-core/+bug/1360286
[14:12] <mup> Bug #1360286: ppc64el and i386 unittests cannot find tools <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1360286>
[14:12] <fwereade> perrito666, I'm really rather nervous about having the api server running at all while this is going on
[14:14] <fwereade> perrito666, in particular I am nervous about what firewaller, networker, etc might do while running against incorrect state
[14:14] <fwereade> perrito666, the provisioner might take down machines so that's the obvious risk
[14:14] <perrito666> fwereade: actually the state is down (and API will not connect to it until restarted)
[14:15] <fwereade> perrito666, how do you ensure it's down? starting jujud will start all sorts of workers, surely, and you won't know to shut them down until you get this api request
[14:21] <perrito666> fwereade: hold, I think we could be not on the same page here, let me finish this standup and then I can give you my full attention (I would really love tho have a white board between us but that is too much asking)
[14:22] <fwereade> perrito666, a whiteboard in one's webcam's FOV is a useful thing, I never got round to setting it up though
[14:22] <fwereade> perrito666, could be
[14:22] <fwereade> perrito666, natefinch: brb, but will join yu in your standup in 5
[14:22] <perrito666> fwereade: we are no longer there, just ping me when you are back
[14:29]  * perrito666 suddenly hits his head on an open window... brb
[14:29] <fwereade> perrito666, natefinch: will be in the hangout when you're ready
[14:29] <perrito666> back
[14:30] <ericsnow> fwereade, perrito666: mind if I join?
[14:30] <fwereade> ericsnow, ofc not
[14:30] <perrito666> ericsnow: you are welcome to join
[14:30] <ericsnow> fwereade, perrito666: you guys are the best! :)
[15:43] <perrito666> aghh my ears are aching
[15:44] <natefinch> anyone have thoughts on why a machine after upgrading from 1.18 to 1.20 would says "missing API Hosts"?
[15:45] <wwitzel3> it's lonely?

[15:45] <perrito666> natefinch: agent.conf corrupted?
[15:46] <natefinch> perrito666: interesting you should say that, he did say he had to update the agent.conf by hand to add apiaddresses
[15:46] <natefinch> or at least, he thought that was the problem, but adding it didn't help
[15:50] <natefinch> can someone else give me a hand? I may have to leave soonish.  On #juju in canonical irc, guy's nick is ivoks, he's onsite with a customer right now.
[15:55]  * fwereade bbs
[15:56] <perrito666> natefinch: sorry was buying foood
[16:20] <katco> how do i got about upgrading an environment to my dev version? "juju upgrade-juju --dry-run --version 1.21-alpha1" gives me "ERROR no matching tools available"
[16:23] <natefinch> --upload-tools should work I think
[16:24] <natefinch> can anyone else help ivoks in canonical irc #juju?  I have to go
[16:25] <natefinch> sinzui, alexisb, mgz, wwitzel3 ^
[16:25] <natefinch> perrito666 was looking at iot but had to go too
[16:25] <katco> natefinch: ah i see... it doesn't like --upload-tools with --dry-run
[16:25] <katco> natefinch: that's what was tripping me up
[16:26] <sinzui> katco, interesting. tip is definitely broken for ppc64el and i386, what arch you testing?
[16:26] <sinzui> see bug 1360286
[16:26] <mup> Bug #1360286: ppc64el and i386 unittests cannot find tools <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1360286>
[16:26] <katco> sinzui: amd64, i think it was just the combination of --dry-run
[16:27] <katco> sinzui: if i do --upload-tools alone, it gives me a list of available tools, and best version
[16:27] <sinzui> katco, oh, we have one or two related bugs where --upload-tools doesn't in other combinations
[16:27]  * sinzui looks
[16:30] <sinzui> katco, These are the upload-tools bugs https://bugs.launchpad.net/juju-core/+bugs/?field.tag=upload-tools and bug 1307643 looks like the issue
[16:30] <mup> Bug #1307643: juju upgrade-juju --upload-tools does not honor the arch <upgrade-juju> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1307643>
[16:32] <katco> sinzui: interesting, thank you so much. it looks like it might? have worked?
[16:32] <katco> sinzui: i'm noticing it incrementing the agent-version
[16:33] <sinzui> katco, status shows the new version?
[16:33] <katco> sinzui: yeah: 1.21-alpha1.x
[16:33] <katco> sinzui: where x is incrementing...
[16:34] <sinzui> katco, upload-tool will always do that
[16:35] <sinzui> katco, that is to distinguish a version taken from the client instead of the net
[16:35] <katco> sinzui: so how do i know that it's actually updated? state is started
[16:41] <sinzui> katco, I trust the log 99% of the time. When I doubt, I ssh to the machine and run "jujud version"
[16:42] <sinzui> katco, I have never seen it differ from status. Once, did this and found th reason for a failed upgrade was bad symlink. There were to jujuds on the machine. I deleted the symlink and juju correctly upgraded itself a minute later
[16:43] <katco> sinzui: lol ok, so rule of thumb: trust agent-status
[18:17] <perrito666> ericsnow: you are a cruel man, such lengthy email on a friday afternoon
[18:19] <perrito666> ericsnow: why would backup allow upload?
[18:20] <perrito666> ericsnow: I have not yet looked at the metadata but I do have a request
[18:21] <perrito666> ericsnow: lemme know when we can have a call
[18:56] <perrito666> ericsnow: ?
[19:09] <ericsnow> perrito666: hey just got back
[19:10] <perrito666> hey, read above :)
[19:10] <ericsnow> we should hang out
[19:10] <ericsnow> moonstone?
[19:10] <perrito666> ericsnow: sure
[21:57] <katco> rick_h__: you still around?