Re: [Launchpad-dev] Connections left open after switching to read only mode
On 05/08/2010 07:34 PM, Stuart Bishop wrote: Hmm... yeah. All the DatabasePolicies would need to know about RO mode, which sucks. Instead, we could just do this in the IStoreSelector - if read-only mode is detected, ignore any installed DatabasePolicy and return the read-only Stores. Would it make sense (and help) to keep existing read-write connections alive, but make them begin only read-only transactions when read-only mode is detected? Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Connections left open after switching to read only mode
On Tue, 2010-05-11 at 13:36 +0700, Jeroen Vermeulen wrote: On 05/08/2010 07:34 PM, Stuart Bishop wrote: Hmm... yeah. All the DatabasePolicies would need to know about RO mode, which sucks. Instead, we could just do this in the IStoreSelector - if read-only mode is detected, ignore any installed DatabasePolicy and return the read-only Stores. Would it make sense (and help) to keep existing read-write connections alive, but make them begin only read-only transactions when read-only mode is detected? No. The goal here is to close these read-write connections so that the roll out can proceed -- the LOSAs don't proceed with a roll out if there's any open connections to any DB other than the standalone (read-only) replica. -- Guilherme Salgado https://launchpad.net/~salgado signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Launchpad meet-up in Brussels Weds evening
Hi all, Those of us Launchpadders at UDS are heading into Brussels tomorrow evening to meet up at Cafe Delirium. From the Launchpad blog: What: Launchpad meet-up Where: Delirium Café, Impasse de la Fidélité, 4A – 1000 Brussels When: From around 7.30pm on Wednesday the 12th of May If you're at UDS, we'll be meeting in the lobby at around 6.20pm to get the first bus into Brussels. -- Matthew Revell -- https://launchpad.net/~matthew.revell Launchpad.net -- cross-project collaboration and hosting ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Mirroring branches with username/password
On 05/11/2010 03:21 AM, Karl Fogel wrote: In a nutshell: svn repo behind a thin connection, not meant to take a full server workload. Username/password is a great way to get the branch onto LP and available to the world, but our displaying the login to the public would be a blocker. If the user is worried about malicious denial-of-service stuff, then having anon access information published would be a problem. But a deliberate DoS is pretty unlikely, and they could avoid any accidental DoS by setting up a dedicated username/password pair just for Launchpad: I don't know what the user is and isn't concerned about; it may just be general principle, or they may not have full control of this for whatever reason. But I could imagine, for instance, a spambot trying to read anything that looks like a URL, maybe using some library for recognizing URLs that's flexible enough for non-http URLs and login credentials. That could suddenly create a lot of spurious traffic... someday, if not necessarily today. I haven't mentioned any of this in the Question #100519, because that user is still unaware of the new username/password feature entirely. But I think the above might address that users' concerns. IMHO, mirrored branches on Launchpad should show viewers all the information they'd need to reach the master source; otherwise they are put in the position of having to trust Launchpad. Dubious economic policy notwithstanding, Reagan still had it right with trust but verify :-). It's best if we offer users a way to verify. I don't think I follow the argument here. What kind of trust are you talking about? If it's trust in honesty on our part, viewers already have to trust that we deploy the same code we publish, with no hidden tricks. If it's trust in timely synchronization, we have logs. If it's trust in us making faithful copies, well, if there's a password on the master then the owner clearly wants it restricted. So the question of trust lies on that side, not on ours. The main kind of trust I personally would worry about here is the blind trust that when you invite me to enter a password, you imply that you're not going to tell the world what it is(*). That's a blind trust in the sense that I might easily skip over any notices to the contrary unless maybe they're in big, red, bold flashing letters and accompanied by blaring sirens(**). By design we currently don't justify that trust. Jeroen (*) Of course you may be mistaken or dishonest; whether what you're _really_ going to do also depends on how much I trust you. (**) The kind the police use. With the other kind, it's pretty much a given that I'm going to be too distracted to read the notice. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Launchpad's service WADL clarification
Hi Manish. Thank you for your work. Leonard won't be available till next week, and he is the expert. The only other person I know who might answer is also unavailable right now. Maybe there is another person who can speak up now, but in case you don't get a reply right now, I wanted you to know the situation. Gary On Apr 25, 2010, at 4:18 AM, Manish Sinha wrote: Hi, I am working on a WADL--C# converter and taking Launchpad WADL file as the example. This project is mainly targeted at generating client proxy code for Launchpad. I ran into a few issues: in the request section of WADL, it can contain param[] and representation_type[] both together I can understand that param[] can be used for generating a method which has all the parameters given in param[] For representation_type[] I understood that the method is overloaded and each there are as many overloaded methods as the number of representation_type My doubt comes that, when both param[] and representation_type[] are present in a single request. Let's take we have m param and n representation_type In this case, does all the methods look like? foo(param1, param2,.,paramm, representation_type1) foo(param1, param2,.,paramm, representation_type2) ... .. foo(param1, param2,.,paramm, representation_typen) Or in most situations param[] and representation_type[] wont occur together? Can I safely assume this? I know many people on this list don't deal with development and not many use WADL since they are comfortable with launchpadlib. It would be kind if some launchpad hacker answers this question. If anyone is familiar with WADL, your suggestions are appreciated. If the hacker who wrote Launchpad WADL can answer this, it would be a cherry on the ice. P.S. I had initially sent this mail to launchpad-users instead. Sending it to the correct list now, -- Manish ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Launchpad's service WADL clarification
On 5/11/2010 5:57 PM, Gary Poster wrote: Hi Manish. Thank you for your work. Leonard won't be available till next week, and he is the expert. The only other person I know who might answer is also unavailable right now. Maybe there is another person who can speak up now, but in case you don't get a reply right now, I wanted you to know the situation. Hi Gary, This confusion still persists. Till date I have recieved replies which are mere speculations of what it should be. No clear cut answer. Here is the conversation between Me and James on this issue. James: https://lists.launchpad.net/launchpad-dev/msg03267.html Me: https://lists.launchpad.net/launchpad-dev/msg03268.html James: https://lists.launchpad.net/launchpad-dev/msg03269.html Me: https://lists.launchpad.net/launchpad-dev/msg03270.html James: https://lists.launchpad.net/launchpad-dev/msg03271.html Me: https://lists.launchpad.net/launchpad-dev/msg03272.html I am just hoping to hear from Leonard or anyone who made this WADL file. I had a small conversation with Leonard on IRC related to the design of the library[1] , but this WADL issue is still unsolved [1] http://dl.dropbox.com/u/1237964/IRC-Logs/leonardr-OnMail.txt -- Manish Sinha ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Mirroring branches with username/password
Jeroen Vermeulen j...@canonical.com writes: I don't think I follow the argument here. What kind of trust are you talking about? If it's trust in honesty on our part, viewers already have to trust that we deploy the same code we publish, with no hidden tricks. If it's trust in timely synchronization, we have logs. If it's trust in us making faithful copies, well, if there's a password on the master then the owner clearly wants it restricted. So the question of trust lies on that side, not on ours. Oh, I didn't mean trust in the sense of worrying about malicious intent. I more meant trust in the sense of one can independently verify that Launchpad's mirror of the code is complete and up-to-date with respect to the upstream repository -- i.e., that no technical glitches have occurred. -Karl ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
