[04:34] <stub> Another reason to dislike using HTTP as an RPC mechanism is $http_proxy.
[04:35] <stub> I need to unset the http_proxy environment variable in the Librarian process, so Swift requests don't go via Squid
[04:35] <stub> (which would be wasteful, and won't work anyway since the firewall rules won't let it happen)
[04:36] <stub> Is it OK to hack this in in lp.scripts.runlaunchpad.start_librarian ?
[04:43] <wgrant> stub: That's rather a reason to dislike mandatory egress HTTP proxies :)
[04:43] <wgrant> stub: But that might be the least bad solution.
[04:48] <wgrant> stub: Though, why is the librarian running with http_proxy at all?
[04:48] <wgrant> Only certain scripts + the appservers should be
[04:48] <wgrant> And the latter only due to retarded firewall rules.
[04:49] <lifeless> stub: wgrant: just set no_proxy
[04:49] <lifeless> no need to unset http_proxy
[04:49] <stub> wgrant: It is in .bashrc, probably because we didn't think it would be harmful
[04:49] <stub> lifeless: I don't know that one
[04:49] <lifeless> no_proxy=hostname
[04:49] <lifeless> -> requests to hostname won't go via the proxy.
[04:50] <wgrant> That's an excellent recipe for totally breaking production.
[04:50] <lifeless> wgrant: howso ?
[04:50] <wgrant> lifeless: Nobody will think to check for that when changing the swift hostname.
[04:50] <lifeless> wgrant: you could set that in the librarian code itself.
[04:51] <wgrant> vom
[04:51] <lifeless> wgrant: that seems a little shallow a response
[04:53] <stub> 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] <stub> 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] <wgrant> stub: Heh, you overestimate the sanity of our firewall configs.
[04:58] <stub> 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] <wgrant> We need to use http_proxy in order to connect to some internal hosts.
[04:58] <stub> wgrant: Yeah. I already checked if staging's upstream librarian is directly connectable ;)
[04:59] <wgrant> The example that immediately comes to mind is blog.launchpad.net from the appservers, but that's probably not the only one.
[04:59] <stub> wgrant: productreleasefinder, bug-watcher... there are others.
[05:00] <lifeless> stub: don't you get the swift urls from keystone?
[05:00] <stub> lifeless: I don't. The swift library I'm using does.
[05:01] <lifeless> stub: ah
[16:04] <replaceafill> hello everybody, i've been trying to fix a couple of 'trivial' bugs and i have questions, can anyone help?
[21:23] <cjwatson> 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] <replaceafill> cjwatson, ah ok understood, thanks!
[22:05] <wgrant> replaceafill: Hi
[22:07] <replaceafill> hi wgrant
[22:09] <wgrant> replaceafill: What questions did you have?
[22:09] <replaceafill> 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 <lp-bugs> <oem-services> <search> <trivial> <ui> <Launchpad itself:Triaged> <https://launchpad.net/bugs/260677>
[22:10] <replaceafill> let me push my branch
[22:18] <replaceafill> wgrant, my push is taking way too long :(
[22:18] <replaceafill> here's the diff though:
[22:18] <replaceafill> http://pastebin.ubuntu.com/6681167/
[22:19] <wgrant> replaceafill: Where are you pushing to?
[22:19] <replaceafill> wgrant, i added a new vocabulary to be used in the "advanced" view
[22:19] <replaceafill> wgrant, launchpad
[22:19] <replaceafill> wgrant, my bandwitdh is very limited :(
[22:19] <wgrant> Ah :(
[22:20] <wgrant> It should only need to push a few hundred kilobytes.
[22:20] <replaceafill> it finished!
[22:21] <replaceafill> https://code.launchpad.net/~replaceafill/launchpad/bug-260677
[22:21] <replaceafill> now lp is updating :)
[22:21] <wgrant> So, what's not working?
[22:21] <replaceafill> basically i'm not sure if my approach is correct
[22:22] <replaceafill> i followed Curtis Hovey's suggestion about creating a new vocabulary
[22:23] <replaceafill> the name of the new vocabulary for example MilestoneWithExpectedDateVocabulary
[22:23] <replaceafill> seems "funny"
[22:25] <wgrant> It's not too bad.
[22:25] <replaceafill> ah, ok
[22:25] <wgrant> It would be nice if Zope let us pass an argument into the vocab constructor, but it does not.
[22:26] <replaceafill> you mean, so we could pass something to tell the vocabulary to insert the dates, right?
[22:26] <replaceafill> (in the titles)
[22:32] <wgrant> replaceafill: Right, that would be nicer than having AWholeNewClassWithAVeryLongName
[22:32] <wgrant> But it's sadly not possible.
[22:32] <replaceafill> right
[22:32] <replaceafill> does this look good enough to you?
[22:32] <replaceafill> i was also adding a unit test for the new vocabulary
[22:33] <replaceafill> based on the tests of the existing one
[22:33] <replaceafill> lp/registry/tests/test_milestone_vocabularies.py
[22:34] <wgrant> Right, that would be a good idea.
[22:34] <wgrant> I'd just add two additional tests, I think.
[22:35] <wgrant> One for a milestone with a date, and one without.
[22:35] <replaceafill> ah, ok
[22:36] <replaceafill> in the unit test or the doctest?
[22:36] <wgrant> The unit test. Doctests are deprecated.
[22:37] <replaceafill> ah ok
[22:37] <replaceafill> good to know :)
[22:37] <replaceafill> can i set you as the reviewer of my branch after i'm done with the test?
[22:39] <wgrant> Sure
[22:40] <replaceafill> ok, i will
[22:40] <replaceafill> thank you wgrant
[22:40] <wgrant> np, thanks for working on this
[22:40] <replaceafill> and expect some other nagging questions from me
[22:40] <replaceafill> i've been working on a couple more :)
[22:41] <wgrant> I look forward to it.