=== pmatulis_ is now known as pmatulis [08:53] gnuoy, https://code.launchpad.net/~james-page/charms/trusty/mysql/forward-compat-xenial/+merge/287311 [08:53] if you have a sec === zenlot1 is now known as zenlot === dooferlad_ is now known as dooferlad [12:16] jamespage, +1 @ https://code.launchpad.net/~james-page/charms/trusty/mysql/forward-compat-xenial [12:17] jamespage, fwiw, that should unblock our gate on several charm amulet tests that started failing with the python 2 default change. === verterok` is now known as verterok === lazypower is now known as lazyPower === bladernr_ is now known as bladernr === Saviq_ is now known as Saviq [15:41] icey, for https://code.launchpad.net/~chris.macnaughton/charms/trusty/ceph-osd/add-encryption/+merge/287483 [15:41] what happens with regards to keys when I turn on that feature? [15:41] they get placed in /etc/ceph/dmcrypt-keys [15:41] jamespage: [15:41] (that's ceph's default key location) [15:41] generated? [15:41] yes [15:42] ceph generates keys and drops them in that location if you don't specify otherwise [15:42] so this deals with the someone steals the disks, but not the server problem [15:42] ? [15:42] yes [15:42] I'd really love to see an amulet test for this as well [15:42] server problem is more complex and will have a subordinate charm that abuses this a bit :) [15:42] not for every combination but for one would be nice [15:43] jamespage: agreed, I'd like to do an amulet that adds a disk and checks that the directory is created methinks [15:43] +1 [15:43] the change generally looks OK to me [15:43] I'd be tempted to drop that version check - firefly is now the older supported release of ceph we have [15:44] so only someone doing something really backward would hit an error there.... [15:44] then we could remove all of the version checks :) [15:44] yes I know [15:44] that would be a nice bit of maintenance todo [15:44] how about a sepoarate MP for that :) [15:44] yes please.. [15:44] but don't add a new one if its not required... [15:44] +1 will get the test written, then start working on removing unneeded version checks [15:45] what's the cost of an additional (minimal) MP? [15:49] do we have any example openstack charms that test differing config? It looks like the config is setup once for all tests, and that the tests all verify with the same config currently in the ceph-osd charm [15:49] jamespage: ^ [16:43] Hello Team, We are facing issue while we are trying to upload product installer files which has size of more than 700 MB to https://files.support.canonical.com/ The actual issue is file uploading progess will be interrupted in middle of transfer. We have tried both CLI and UI mode of file upload still we are facing this issue. Could someone please advise on this issue. [16:45] icey, ^ re: cost of diff configs ... is that re: amulet tests or unit tests? [16:46] icey, fyi - rule of thumb for amulet tests: if you need to exercise a topology or a configuration which is significantly different than what we exercise there, then that is a candidate for a mojo spec test. [16:47] icey, otherwise it is actually quite resource-expensive to add an alternate config/topology to exercise against all currently-supported ubuntu+openstack release targets. [17:21] hey cory_fu jcastro: Prabakaran was asking about videos related to layered charm development. do we have any recordings (maybe from Ghent) about the layered approach? [17:24] Prabakaran: i found this on our youtube channel -- it may be a bit basic for you, but marcoceppi gives a good overview of layers: https://www.youtube.com/watch?v=UzgW1NW1M6A [17:25] there's https://www.youtube.com/watch?v=aRQcERLnbIQ too [17:27] https://www.youtube.com/watch?v=UzgW1NW1M6A [17:28] kwmonroe: ^ [17:28] Prabakaran: there's a couple for ya ^^ (thx sparkieg` jcastro) === sparkieg` is now known as sparkiegeek [17:38] Thank you all .. [17:38] I will refer those videos... [17:47] beisner: I think there may be a confusion in the communication; I'm adding a new single test to verify config stuff [17:47] icey, yep that's all good. [17:47] and talking about a separate merge proposal fo removing the unnecessary version checks === Guest67703 is now known as me_ === me_ is now known as med_ === redelmann__ is now known as redelmann === mux_ is now known as mux === bdx_ is now known as bdx [19:38] charmers: can we get some review here? --> https://code.launchpad.net/~stub/charms/trusty/postgresql/built/+merge/282588 [19:39] bdx: THERE YOU ARE! [19:40] are you busy atm? [19:40] jose: ehh, define busy .. :-) [19:40] jose: i have a few mins to spare for you, whats up? [19:41] I wanted to help you out with your charm, that's it [20:09] kwmonroe - ping [20:10] pong lazyPower [20:11] kwmonroe - i've heard a lot about this "layer:java" from jcastro - but i think what he means is "interface:java" - https://github.com/juju-solutions/interface-java - and this is a pattern is houdl be adopting when charming up java services right? [20:12] right lazyPower, there are interface providers (openjdk, zulu8, and ibm-jdk), but currently only 1 consumer, layer-ubuntu-devenv [20:12] this will be the second consumer I suppose :) [20:13] w00t [20:13] ok cool so i just implement the interface, and adjust my metadata accordingly [20:13] get some spiffy reactive magic like you have in the interface readme, and build the open-jdk subordinate? [20:13] actually, are those java subordinates already listed in the store? [20:14] yeah lazyPower, not promulgated, but openjdk is in my namespace [20:14] https://jujucharms.com/u/kwmonroe/openjdk/trusty/6 [20:14] look at that spiffy little java dude [20:14] thanks man, i'll let ya know how i get along with this shortly [20:14] heh, 2 hours on the charm, 2 days on the icon ;) [20:15] amir would be proud ;) [20:16] lazyPower: the current (simple) java consumer is here: https://github.com/juju-solutions/layer-ubuntu-devenv -- note the provides: java there because we expect javas to be a subordinate. [20:16] ah right, just as iw as putting it under requires [20:16] derp [20:16] :) [20:17] kwmonroe: We should probably get that openjdk charm promulgated, no? [20:18] Otherwise, the ibm-java charm is gonna beat you. ;) [20:18] hold on, one consumer, just cause I've not bothered publishing my charm yet, doesn't mean there is just one consumer! ;) [20:18] yeah cory_fu, can't have that. but i think i wanted to revisit the interface: java bits first. i seem to recall you objecting to the readme.. [20:19] and by "readme", i mean "core logic in the interface" [20:19] same same [20:19] kwmonroe: What you mean? [20:19] six of one, half dozen of the other ;) [20:19] magicaltrout: Ha, too right! [20:19] lazyPower any ideas when the networking layer might be working with the kubernetes bundles? I am not really able to use it until that gets resolved for me [20:19] firl - we're workign on logging infrastructure now [20:20] kwmonroe: I don't actually remember what you're referring to, and I didn't open an issue [20:20] the manic Xenial LXD hacking has been in part so I can finish off PDI in a sensible manner [20:20] should have something testable over the next couple of days [20:20] kk, if it’s on the roadmap and you want me to test it, let me know. [20:21] firl - thats not currently in our backlog, its on the long term roadmap solvables, but we're not scheduling time for it atm. I'll bring it up with marco to see where it sits on our delivery timeline and if we can squeeze it in directly after cycle close [20:21] firl - that being said, if you want to get some dev cycles in on it, i'm game to help and we'd <3 the contribution [20:21] yeah I would love to, just don’t have the dev cycles either :( [20:22] cory_fu: in the java interface readme, we have example usage for people that are providing the interface (eg, JREs), but we don't document how to consume it. i think we also wanted to put JAVA_OPTS bits in there for consumers, though i'm fuzzy on that. [20:22] Oh, so it really is just README changes? Yeah, it needs to be improved [20:22] also, this was around the time we were talking connected vs related. but i think we settled on connected. [20:22] But the README on the interface doesn't block the openjdk charm in any way [20:23] kwmonroe: Well, now that seems to have gone to "joined" in the big data charms. We can't ever decide on anything, can we? :p [20:24] yeah cory_fu, so we should decide pretty quick on that... before magicaltrout and lazyPower get to work. do you have current objections to .connected? [20:25] I don't [20:25] too late on "before lazypower" [20:25] but i'm sniffing on "java.installed" [20:25] :) motion carries. we're connected. [20:25] so if thats wrong, speak now :P [20:25] don't make me sad :P [20:26] magicaltrout: You ok with "java.connected" as the state name? [20:28] lazyPower: java.installed is set within the providers (like openjdk). you want to sniff on java.ready. [20:28] i'm okay with whatever you're okay with :P [20:28] ah solid [20:28] whats the difference between java.connected and java.installed? [20:28] like, i get installed :P but how would it be installed but not connected? [20:29] the step in the dance of communication where the units are aware of one another but may not have all the data required to configure the java service [20:30] cool [20:30] whatever, when it doesn't work i'll just defer to you guys anyway :P [20:30] so... firstly, stop saying java.installed ;) that doesn't matter for consumers of the java interface. that's just a thing that the JREs will do to know if they need to install java. what you guys want (magicaltrout and lazyPower) is to watch for java.ready. once you see that, you know java has been installed and things like "java_home" and "java_version" are available on the java relation. [20:31] * magicaltrout greps his code [20:31] oh yeah [20:31] you're not lying [20:31] :) [20:31] okay, whats the difference between ready and connected :P [20:32] ie: I don't really care, but which do I listen for? [20:32] java.ready i assume from your comment [20:32] in which case I shall ignore you all for ever more [20:33] magicaltrout: you could have your charm report "blocked: waiting on java relation", then @when java.connected @when_not java.ready report "waiting for java to become ready", then @when java.ready report "java in da house" [20:34] * lazyPower raises the java roof [20:34] heh [20:35] magicaltrout: so it's just available for you to inform your users when a java relationship is present, but may or may not be ready (apt-get install openjdk can take a few minutes, so people might like to know that the relation is there, but we're waiting on java to ready itself) [20:35] k [20:42] kwmonroe - well this is weird. provides: java: interface: java - is clearly in my metadata, doesn't look like builder likes it though :( http://paste.ubuntu.com/15246844/ [20:43] https://github.com/OSBI/layer-pdi here's my attempt lazyPower [20:45] lazyPower: i'm not sure what you mean by "provides: java: interface: java", but if you do it like magicaltrout's magicaltrout's metadata and layer.yaml, you should be 2legit2quit. [20:48] kwmonroe, lazyPower, magicaltrout: https://github.com/juju-solutions/interface-java/pull/2 [20:49] look at the fingers on cory_fu! i was gonna draft more messages about how the readme is lacking, but you just straight up fixed the problem. nice. [20:49] :) [20:49] I was waiting for my spark deployment to fail anyway. ;) [20:49] ha! [20:54] acceptable fast fingers, acceptable [20:55] now if only kwmonroe had written that readme before the meetup, i'd not have been stuck.... :P [20:55] aww but what would have done in the bar for 5 hours.... [21:03] saved a bunch of money, for one.