[04:34] Another reason to dislike using HTTP as an RPC mechanism is $http_proxy. [04:35] I need to unset the http_proxy environment variable in the Librarian process, so Swift requests don't go via Squid [04:35] (which would be wasteful, and won't work anyway since the firewall rules won't let it happen) [04:36] Is it OK to hack this in in lp.scripts.runlaunchpad.start_librarian ? [04:43] stub: That's rather a reason to dislike mandatory egress HTTP proxies :) [04:43] stub: But that might be the least bad solution. [04:48] stub: Though, why is the librarian running with http_proxy at all? [04:48] Only certain scripts + the appservers should be [04:48] And the latter only due to retarded firewall rules. [04:49] stub: wgrant: just set no_proxy [04:49] no need to unset http_proxy [04:49] wgrant: It is in .bashrc, probably because we didn't think it would be harmful [04:49] lifeless: I don't know that one [04:49] no_proxy=hostname [04:49] -> requests to hostname won't go via the proxy. [04:50] That's an excellent recipe for totally breaking production. [04:50] wgrant: howso ? [04:50] lifeless: Nobody will think to check for that when changing the swift hostname. [04:50] wgrant: you could set that in the librarian code itself. [04:51] vom [04:51] wgrant: that seems a little shallow a response [04:53] lifeless: I don't think I can set it in process. I will know the Keystone URL, but I don't know the Swift endpoint URLs. [04:57] wgrant: it would work if we are consistently using internal DNS names now... All the keystone/swift stuff is new since we started doing that, so it should be reliable enough. [04:58] stub: Heh, you overestimate the sanity of our firewall configs. [04:58] wgrant: Although fixing it in .bashrc would just be a foot gun, so no real difference between unsetting http_proxy and setting no_proxy [04:58] We need to use http_proxy in order to connect to some internal hosts. [04:58] wgrant: Yeah. I already checked if staging's upstream librarian is directly connectable ;) [04:59] The example that immediately comes to mind is blog.launchpad.net from the appservers, but that's probably not the only one. [04:59] wgrant: productreleasefinder, bug-watcher... there are others. [05:00] stub: don't you get the swift urls from keystone? [05:00] lifeless: I don't. The swift library I'm using does. [05:01] stub: ah === Ursinha_ is now known as Ursinha [16:04] hello everybody, i've been trying to fix a couple of 'trivial' bugs and i have questions, can anyone help? [21:23] replaceafill: (I'm only here for about twenty seconds, but) it's usually best to ask questions straight out and then leave your client hanging around for a while - LP devs are on various timezones but should be able to reply eventually [21:24] cjwatson, ah ok understood, thanks! [22:05] replaceafill: Hi [22:07] hi wgrant [22:09] replaceafill: What questions did you have? [22:09] wgrant, i'm trying to fix this bug: https://bugs.launchpad.net/launchpad/+bug/260677 [22:09] <_mup_> Bug #260677: Include date with milestones on advanced search page

[22:10] let me push my branch [22:18] wgrant, my push is taking way too long :( [22:18] here's the diff though: [22:18] http://pastebin.ubuntu.com/6681167/ [22:19] replaceafill: Where are you pushing to? [22:19] wgrant, i added a new vocabulary to be used in the "advanced" view [22:19] wgrant, launchpad [22:19] wgrant, my bandwitdh is very limited :( [22:19] Ah :( [22:20] It should only need to push a few hundred kilobytes. [22:20] it finished! [22:21] https://code.launchpad.net/~replaceafill/launchpad/bug-260677 [22:21] now lp is updating :) [22:21] So, what's not working? [22:21] basically i'm not sure if my approach is correct [22:22] i followed Curtis Hovey's suggestion about creating a new vocabulary [22:23] the name of the new vocabulary for example MilestoneWithExpectedDateVocabulary [22:23] seems "funny" [22:25] It's not too bad. [22:25] ah, ok [22:25] It would be nice if Zope let us pass an argument into the vocab constructor, but it does not. [22:26] you mean, so we could pass something to tell the vocabulary to insert the dates, right? [22:26] (in the titles) [22:32] replaceafill: Right, that would be nicer than having AWholeNewClassWithAVeryLongName [22:32] But it's sadly not possible. [22:32] right [22:32] does this look good enough to you? [22:32] i was also adding a unit test for the new vocabulary [22:33] based on the tests of the existing one [22:33] lp/registry/tests/test_milestone_vocabularies.py [22:34] Right, that would be a good idea. [22:34] I'd just add two additional tests, I think. [22:35] One for a milestone with a date, and one without. [22:35] ah, ok [22:36] in the unit test or the doctest? [22:36] The unit test. Doctests are deprecated. [22:37] ah ok [22:37] good to know :) [22:37] can i set you as the reviewer of my branch after i'm done with the test? [22:39] Sure [22:40] ok, i will [22:40] thank you wgrant [22:40] np, thanks for working on this [22:40] and expect some other nagging questions from me [22:40] i've been working on a couple more :) [22:41] I look forward to it.