=== freyes_ is now known as freyes === tris- is now known as tris === beisner- is now known as beisner === zz_CyberJacob is now known as CyberJacob [06:55] aisrael: users are just roles in PostgreSQL. When the PG charm generates the new user/role, we grant it the old user/role so it gets all the old permissions. [06:55] aisrael: So we don't need to introspect the database and change all the ownership, which is good as it is a) non trivial and b) quite invasive. [07:50] Hi jujuers. IS there a way to run a sandbox of juju on my laptop ? === Guest19391 is now known as frobware === CyberJacob is now known as zz_CyberJacob [09:10] gnuoy: dosaboy: wolsen: can I get some review ♥ for https://code.launchpad.net/~adam-collard/charms/trusty/swift-storage/guard-paused-unit-service-restarts/+merge/269860 please? [09:12] sparkiegeek, isn't pause_aware_restart_on_change going to be applicable to lots of your maintenance actions? [09:12] gnuoy: yes, I assume your next question is "why not charm-helpers?" [09:13] sparkiegeek, it is, but maybe that's the layout change [09:13] gnuoy: to which the response is - thought about it, but the is_paused() semantics could be different for each charm [09:17] sparkiegeek, merged [09:17] gnuoy: thank you! [09:17] np [10:40] Is it still possible for juju to be running 2 hooks simultaneously in the case where you have two units smooshed onto one machine? Or are hooks serialized per machine now? [10:40] I think they are serialized now, as my primary and my subordinate hooks no longer clash. [10:41] And if so, anyone know what version this changed in? [10:42] Thinking that apt failing to grab a lock may indicate a real failure now, rather than something intermittent requiring retries === perrito667 is now known as perrito666 [12:37] stub: there's a broken assumption there .. brb [12:37] broken assumption? [13:16] But the assumption is too large for this margin [13:17] haha [13:18] stub: the broken assumption is that only juju is invoking apt on a system [13:18] stub: the classic counterexample is landscape [13:19] elmo: stub: right! I'm wondering if aptdaemon has a role to play here [13:20] of course it's not a complete answer because there will always be something else invoking APT and taking locks [13:22] I think we need a synchronous apt-get update that keeps retrying until it works or fails hard (screwed apt, timeout). And an apt-get install that just tries and fails (eg. trying to install an unsigned package) [13:22] I know nothing about aptdaemon or if it can help. [13:23] I've looked at the code and can adjust retries or add my own timeout easily enough, so I can work around for a particularly problematic charm like Cassandra [13:23] stub: well the idea of aptdaemon is that it's one process that talks to APT and clients just make requests of it to do things [13:24] stub: I'm curious, what is it about Cassandra charm that makes the current logic problematic? [13:24] Sounds good if you can wait for it to report success, rather than fire and forget and hope the job is done before you need it [13:25] The Cassandra charm can install DataStax Enterprise, which exists in a password protected apt archive. Remembering to add the URL in the first place, getting it right - it doesn't sound like much, but so far everybody has screwed up some part of the configuration. [13:28] so the issue is that it takes 5mins to report the screw up? [13:29] With archive.ubuntu.com, a ppa, the us datastax.com - apt-get update takes a minute or two to run and fail. 30 times that is not 5 minutes. [13:31] Now I realize it is retrying a fixed number of times, I can lower that number. I'd assumed it was retrying forever, because that is what it felt like :) [13:31] :) [13:35] aptdaemon looks nice. I'm also drawn to a few nice features like partial updates (update only the sources in a given sources.list). [13:37] I have a feeling some of this will need work for wily. aptdaemon may simplify things. [13:37] i'm not sure whether we ship policykit in cloud images, do you know? [13:39] No idea. Does it matter for root? [13:42] well it seems that aptdaemon depends on PolicyKit, *shrug* [13:43] I mean depending on aptdaemon just gives you a bootstrap issue - how do we get aptdaemon in the first place :) === verterok` is now known as verterok [14:03] sparkiegeek: The bootstrap packages aren't as hard, as we know there is a working primary archive or we would not have gotten as far as an install hook. [14:03] sparkiegeek: but yeah, it would need to retry there. [14:03] stub: right, that's what I meant - two units racing to install aptdaemon [14:04] sparkiegeek: Until juju sticks charmhelpers on the units for us and the charm dependency bootstrap problem goes away. [14:04] stub: I Want To Believe [14:05] Or we make aptdaemon a snap. === wendar_ is now known as wendar === l6unchpad is now known as l6unchpad|away === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa