[04:48] wgrant: So, microservices? [04:49] StevenK: Have you adequately stress-tested the implementation, including how it behaves around failed transactions and similar scenarios? [04:50] wgrant: You were attempting to break it, last I heard. [04:50] So I'm curious how that went. [04:50] I recall I couldn't get it to actually start. [04:50] How were you trying to start it? [04:50] I think even the tests failed. [04:51] I don't recall if you fixed that [04:51] Bleh, auditor tests fail on saucy due to django 1.5.4 [04:52] ... python-django is 44MiB? [04:52] So remember what I said about framework choice. [04:53] I don't really want to rewrite auditor at this point :-) [04:55] wgrant: Keep in mind that auditor is an django app -- auditorfixture provides a handy wrapper to run it by hand [05:02] wgrant: http://pastebin.ubuntu.com/6322268/ [05:19] StevenK: Looks like you fixed the bug. [05:20] StevenK: So, last time I had you make substantial changes, you added transaction support. How do failed transactions behave? What happens if the service is down? What is the HA story to prevent the service from going down except in network outages? [05:21] Has performance been tested? How will we handle upgrades? [05:22] wgrant: Failed transactions should be handled by the transaction manager, we only commit if the transaction status is COMMITTED [05:23] wgrant: I *think* we time out after 1 second if the service is down when trying to GET or POST. [05:23] "time out" [05:23] What does that mean? [05:24] The urlopen() calls in auditorclient have a default timeout of 1 second. [05:24] Sure. [05:24] But that doesn't tell us what happens when the service is down or there is a network fault. [05:24] That tells us that something will probably happen after approximately one second. [05:25] I think I tested this, and you get back no data on GET or POST [05:26] In terms of the HA story, I'm not sure. [05:27] Is it reasonable for it to simple return no data for failed reads, and throw away failed writes? [05:28] For the former, yes, probably not for the latter. [05:28] But I'm still trying to swap stuff in, since it's been months. [05:28] For the former it may be acceptable for the current scenario, I'm not sure. But it's certainly not acceptable for all scenarios. [05:28] I raised these issues last time too, and you ignored them :P [05:30] Performance was going to be looked at closely when I actually got this onto staging, since it won't be ready for an end-to-end test until this stuff lands. [05:31] Upgrades involves pushing a new dist tarball into the download-cache, and bumping versions.cfg of LP, auditorfixture and production-auditor. [05:31] DB upgrades? [05:32] Auditor is a well-isolated service; performance testing would want to be done outside the context of LP. [05:32] There is some support for south sprinkled in, but I've not had to change the schema yet. [05:32] Doing it on LP staging would be prohibitively slow; you'd need hundreds of thousands to millions of uploads. [05:32] Even if you do use south, how do we do DB upgrades? [05:32] Remember that Launchpad likes to read from and write to auditor. [05:33] Turn the feature flag off, and it will not any more. [05:33] But now I've lost data. [05:33] Now malicious archive admins have just approved a thousand rootkitted SRUs :( [05:33] And I can't tell who to fire :( [05:34] wgrant: Sure, and I answer "I don't know", and that's the answer I get if I ask if you're happy with the branch. :-P [05:35] Answers to these questions are essential for approval of the branch, because this is the first significant separate datastore we have. [05:35] Yes. [05:35] "Do it as a service, [05:35] Blah [05:36] "Do it as a microservice, it will be easy" and other lies lifeless has told. [05:36] It would be easy if we had existing microservice patterns, or even rules that they should follow. [05:36] But this is breaking new ground. [05:36] In the Launchpad world. [05:36] Sorry :) [05:36] But they aren't lies. [05:36] Is this where I give up horribly and put up a DB patch? [05:37] If I was still working on LP, I'd happily be helping you get through this transition. [05:37] Sure. [05:40] lifeless: Sure, and then you get to point at the ground that auditor has forged when someone writes another microservice, but there is no forging, just lots of roadblocks. [06:37] StevenK: wgrant: so, looking back at the discussion [06:38] StevenK: wgrant: it seems to me that the questions wgrant is asking are generic and a checklist for them around the design and client-usage-of microservices would be a good idea. [06:38] Certainly :) [06:38] The goal of the review process for the auditor integration is to become such a checklist. [06:39] That is, I believe, fundamentally more valuable than auditor itself. [06:39] so, my point is that listing them here is lossy. [06:39] How about wiki page in the services area [06:39] and a second wiki page with the concrete answers to the questions for auditor [06:40] I still don't know the answers. [06:40] where there answers may either answer it (at a design level) or say 'pending' or whatever if some evaluation hasn't been done [06:40] and then the two of you (plus LOSAs as appropriate) can collaborate on getting good answers and fillout out the questionnaire === hloeung is now known as Guest93605 === Guest93605 is now known as hloeung === hloeung is now known as Guest69967 === Guest69967 is now known as hloeung === Ursinha-afk is now known as Ursinha === Laney is now known as KruSha666 === KruSha666 is now known as Laney