[05:44] Hello juju world! === frankban|afk is now known as frankban [09:21] lightning talks today.... [09:22] hopefully mark has a good sense of humour.... https://imagebin.ca/v/2oh1GLMMHBVk === rcj` is now known as rcj [11:27] Data Server Manager product monitor the all DB2 which is present. I have deployed multiple units of DB2. In my Data server manager, it is having a relation with DB2 charm. It should get the all the DB2 units like private-address as well as db2Port,db2username, db2password of each unit in DSM charm. As DB2 interface uses Scope.Service, i am getting only one DB2 unit information. How do i get multiple DB2 unit information please help me o [11:28] Data Server Manager product monitor the all DB2 which is present. I deployed multiple units of DB2. In my Data server manager, it is having a relation with DB2 charm. It should get the all the DB2 units like private-address as well as db2Port,db2username, db2password of each unit in DSM charm. As DB2 interface uses Scope.Service, i am getting only one DB2 unit information. How do i get multiple DB2 unit information please help me on thi [12:32] Data Server Manager product monitor the all DB2 which is present. I deployed multiple units of DB2. In my Data server manager, it is having a relation with DB2 charm. It should get the all the DB2 units like private-address as well as db2Port,db2username, db2password of each unit in DSM charm. As DB2 interface uses Scope.Service, i am getting only one DB2 unit information. How do i get multiple DB2 unit information please help me on thi === CyberJacob is now known as zz_CyberJacob [13:05] magicaltrout BRILLIANT! [13:05] sharan - you will need to change the scope of the relationship to scope: unit, and handle each conversation [13:07] hehe [13:07] https://docs.google.com/presentation/d/1UdKSsuXpYSy25V9HuxnqgzQRmlC1DEtLJUgEY-5PDoc/edit?usp=sharing [13:07] magicaltrout - https://www.sunfrog.com/LINUX-SYSTEM-ADMINISTRATION--WE-DO-T4-Dark-Grey-Guys.html?70283 [13:08] lol [13:08] nice deq [13:08] i feel like I should own one [13:08] * lazyPower approves [13:09] very tongue in cheek :) [13:09] hehe [13:09] the presentation tonight is a similar thing to what we discussed in juju re: adoption [13:10] if you tell everyone they're going to have to rip their existing stuff out [13:10] they'll tell you to get lost [13:10] which hinders adoption [13:10] so i figured i might as well make an amusing lightning talk out of it [13:11] that is a REALLY good point. I've thought for a while that a nice pattern would be to allow any setting that is set by a relation to be overridden by config. That way juju deployed apps could play nicely with existing apps. [13:11] lazyPwer-will it work if i change scope:unit? handle each conversation means, i need to handle that in my DSM charm by having for loop [13:12] yeah jrwren and why in a juju context puppet/chef etc interoperability either by embedding modules or whatever is important [13:12] because companies already have all their automation stuff [13:12] i have update the DB2 interface scope:service to scope:unit right [13:12] if you tell them they need to throw it all in the bin, they'll just ignore you [13:13] sharan - right, any unit that's not currently broadcasting its information on the relationship will need to be updated to scope:unit, and you'll need to iterate over each conversation and handle it appropriately [13:14] sharan - mbruzek and i have an example of this in some of our relationship interfaces we've done. I'm sure there are others though. as an example, here is a peer relationship that is scope unit - https://github.com/juju-solutions/interface-etcd/blob/master/peers.py [13:15] ok let me go through this link, thanks [13:15] and for a slightly more complex example, here is the peering interface for layer-tls https://github.com/juju-solutions/interface-tls/blob/master/peers.py - its managing certificate signing requests, and managing host details. [13:16] so after updating scope in interface then i need to change some code in DB2 charm also right [13:20] yeah, mostly you'll need to iterate over the conversations and address as appropriate. [13:21] conv = self.conversations(); for unit in conv: # do something useful here like unit.set_remote(data={'foo':'bar'}) [13:21] magicaltrout - today kicks off with a phil collins diddy - https://www.youtube.com/watch?v=sRY1NG1P_kw [13:23] hehe [13:23] actually I was listening to a bit of phil collins today [13:23] but with a sligtht twist [13:23] https://www.youtube.com/watch?v=YIVUCwRVUBY [13:24] the guy playing the final solo at 17mins is pretty epic [13:25] lazyPower - in DB2 charm i have to use self.conversations(); to iterate each unit right. I have never used this in any of my charm but i saw this code in DB2 interface "provides.py" and "requires.py" files [13:25] sharan - link to your interface code? [13:26] oooo magicaltrout :fire: [13:26] lazyPower - http://bazaar.launchpad.net/~ibmcharmers/interface-ibm-db2/trunk/files [13:27] * lazyPower looks [13:27] http://bazaar.launchpad.net/~ibmcharmers/interface-ibm-db2/trunk/view/head:/provides.py#L73 -- yep you're already working with the same primitives i was speaking to. this line here http://bazaar.launchpad.net/~ibmcharmers/interface-ibm-db2/trunk/view/head:/provides.py#L73 [13:28] you're using that same iterator and pulling the charm unit-name from teh conversation. [13:28] and sorry about hte double link paste.... hurr durr i need coffee [13:28] * lazyPower goes to put the kettle on [13:32] sharan - make sure you're familiar with https://jujucharms.com/docs/devel/developer-layers-interfaces#communication-scopes [13:33] pay special attention to the example that is scope unit [13:33] https://jujucharms.com/docs/devel/developer-layers-interfaces#writing-the-requires-side [13:34] cory_fu kwmonroe it's demo time, whats the best bundle to deploy for big software [13:34] lots of bigdata people here [13:35] where you at marcoceppi ? [13:35] DOD Minnesota [13:35] er Minneapolis [13:35] close enough ;) [13:35] magicaltrout: if you've got something too ;) [13:37] * magicaltrout adds "finishing off apachedrill" to his todo list [13:44] lazyPower - thanks, i will look into the link shared by you [13:47] sharan np. let me know how you get along after reviewing the source material. I think it's pretty straight forward but if there's anything we can improve there for clarity i'd love to get your feedback [13:47] marcoceppi: Sorry, was afk. https://jujucharms.com/hadoop-processing/ is good. [13:47] It's the Bigtop Hadoop bundle [13:47] https://jujucharms.com/apache-processing-mapreduce/ if you want more units [13:48] magicaltrout - ok my response to your big band https://www.youtube.com/watch?v=KKXBAw5K6Fg [13:48] * lazyPower wishes we still had turntable.fm now === natefinch is now known as natefinch-afk [14:50] * magicaltrout wonders how far he can push the lighthearted trolling without getting kicked out of the sprint [14:53] I have 3 machines running 16.04 from MAAS; I would like to use them as a VM failver cluster; is juju->openstack-base/43 the right way to go? [15:21] woop [15:21] jcastro: i got turned down for linuxcon.... sad times [15:21] jcastro: i got accepted for mesoscon..... good times [15:22] so you're dispatching me to amsterdam [15:24] lazyPower: --^ [15:24] Nice! [15:24] I wish i could come with [15:24] It would be great to tag-team the casuals [15:25] hehe [15:28] does mean I have some work to do... only a month away :P [16:17] wooo thats true [16:17] again, if there's anything I can do to lend a hand and make your presentation a success lmk === natefinch-afk is now known as natefinch === frankban is now known as frankban|afk === cmagina is now known as cmagina_lunch [17:03] cory_fu https://github.com/juju-solutions/layer-tls/pull/42/files [17:03] mind taking a look there? I think this was along the lines of what we had discussed [17:05] lazyPower: +1 [17:08] ta [17:31] lazyPower: Oops. https://github.com/juju/plugins/pull/68 [17:34] +1'd [17:47] Anybody seen this error before? http://pastebin.ubuntu.com/20203784/ [17:47] (This is on AWS) [17:48] i have not, and thats an odd duck cory_fu [17:48] that looks like the image is missing core system components [17:49] It was working on this instance a few minutes ago [17:49] was this a single hiccup or is this consistently happening? [17:49] It worked, and now it's failing consistently [17:51] Ah! [17:51] http://www.sillycodes.com/2015/06/quick-tip-couldnt-create-temporary-file.html saved my bacon [17:52] ah so the rest of that was red herring [17:52] cleaning up the apt bits worked, good to know [20:42] here's a very weird observation..... its funny how different the juju dev team is to the snaps dev team [20:45] in what way? [20:46] the type of person [20:47] thats not a bad thing in either case, but the juju team is much more US based I guess than the snaps team and of course that makes a difference in interaction [20:56] you mean we're more optimistic? :D [20:58] lol [20:58] if i'm honest i'd probably call you more "ballttle hardened" [20:59] (except for marcoceppi ) [20:59] stupid wifi lag: battle hardened === natefinch is now known as natefinch-afk [21:08] haha [21:08] we're battle hardened [21:08] hear that jrwren? He called us a noble steed [21:11] magicaltrout: great observation [21:13] well, I know /I/ am. [21:13] but I'd have called marcoceppi the most battle hardened. [21:13] not the exception. [21:27] you're not wrong :) [21:49] cory_fu, kjackal, kwmonroe: I think that we may need to come up with a better way of ensuring that the patches in the bigtop base layer actually match up with the code that we merge upstream. [21:50] I'm kind of in tool hell with the kafka patches right now -- in order to get the charm to deploy, I need to patch on top of what's in the patches directory, but that's different than the code that I actually want to submit upstream. [21:51] (I think that the solution is probably to sync up the BIGTOP-1624.patch file first; I think that I can do some git magic to make that process a little less painful.) [21:52] Actually, github does the magic for me -- just needed to add .patch to the url of the old PR. Awesome :-) [22:03] any ~charmers around? [22:03] based off recent reviews in [22:03] https://code.launchpad.net/~stub/charms/trusty/nrpe/py3/+merge/300153 [22:03] and https://code.launchpad.net/~jamesj/charms/trusty/haproxy/xenial-support/+merge/299196 [22:03] it looks like we can land these [22:04] just needs a charmer , and I think we need to update the charms to get them in a non-lp ingestion world [22:05] lazyPower: ? ^ [22:07] * lazyPower looks [22:08] arosales - have we found resolution on https://code.launchpad.net/~jamesj/charms/trusty/haproxy/xenial-support/+merge/299196/comments/772700? [22:09] ah mult-series and charm push [22:11] who needs access to it? [22:11] i can go ahead and start the process but i think there's more to be done here, [22:12] lazyPower: so we can't just bzr branch the latest and then push because it would be under your name space correct? [22:12] well, thats what i'm saying. we can create the new lp group and push it, and i am happy to add any maintainers. This will wind up unpromulgating the precise charm however [22:13] for haproxy James Jesudason (jamesj) needs it according the the MP and the landscape team I also think needs it according to dpb1_ [22:13] is that something we're super concerned about? [22:13] does this one support precise? [22:13] I don't care about precise, no [22:14] ok, give me a bit to take a look and i'll work those tickets [22:14] lazyPower: it doesn't looks like it does [22:14] dpb1_: well I wonder if others do though [22:15] hmm, 36 deploys with https://jujucharms.com/haproxy/precise/36 [22:15] why can't precise by eol already [22:15] arosales: they can use old versions just fine [22:15] dpb1_: old version of the charm? [22:15] yes [22:16] the readme could even be updated if that is really something we are concerned about... [22:16] lazyPower: what name space would https://jujucharms.com/haproxy/precise/36 go to if you were to charm push the trusty/xenial charm? [22:16] dpb1_: I am guessing the precise one isn't in use, but trying to have some due dilligence [22:16] sure, I respect that [22:16] still [22:17] precise. [22:17] :) [22:17] I hear you :-) [22:17] but, yes, thanks for giving it a good think [22:17] precise is killing us in reactive to [22:17] perhaps we email the juju list and just ask if we can deprecate precise charms [22:18] lazyPower same issues with https://code.launchpad.net/~stub/charms/trusty/nrpe/py3/+merge/300153 ? [22:19] nrpe doesn't look to touch the series [22:19] no i think nrpe is just a push [22:19] * lazyPower double checks [22:20] https://jujucharms.com/nrpe/ - yeah, there's already a push target for xenial [22:20] oh wait, no, this is the older lp ingested target, so that will require another owner [22:21] which in turn creates the same problem if nrpe is not multi-series, iirc, promulgation works across series, and this would cause the trusty nrpe to drop unless we copy/push to the same owner org [22:21] jrwren ^ check my math? [22:22] ya https://jujucharms.com/q/nrpe looks to support all series [22:23] so we would need to add a series to the meta-data as well [22:23] lazyPower: can you school me on why we can't just push then promulgate? [22:23] why we need to move the charm under a new name space [22:24] I guess cause the owner of the charm would show as the person who pushed the charm, correct? [22:24] the short answer - is ~charmers shouldn't own anything. we're a fixture of the store, not the owners of everything good :) [22:24] lazyPower: so the process should look like [22:24] but there's another answer thats longer winded that i'm not fully certain i remember. it has to do with push targets though, and how ownership works in the newer store model [22:24] 1. make a new lp group with charm- [22:25] 2. add current maintainer(s) of the charm as admins including ~charmers [22:25] 3. push the charm under the new group name [22:25] 0. See if the new push unpromulgates any other charms [22:25] arosales: you don't need 2 anymore, for ~charmers [22:25] since we don't ingest anymore [22:26] arosales: also, -team is a better name for lp [22:26] i did -charmers [22:26] lazyPower: don't [22:26] but i'm not married to any of that [22:26] charmers is too confusing for people not familar with "charmers" as a concept [22:26] I have see -charmers more [22:26] it's tested poorly with user testing [22:26] -team or something similar is better [22:26] ok, we should document this somewhere [22:27] marcoceppi: doesn't ~charmers need to be a part of the new team so folks like lazyPower can do the initial push? [22:27] https://irclogs.ubuntu.com/2016/07/20/#juju.txt [22:27] arosales: no [22:28] so what team would lazyPower push nrpe under then? [22:28] -team [22:28] nrpe-team i assume [22:28] marcoceppi: sorry I meant docs some where other than obscure irc logs [22:28] or nagios-team [22:28] arosales: file a bug on docs, this just shook out last week from the design folks [22:28] will do [22:28] for docs [22:28] but on the team name [22:28] tbh, the -charmers isn't documented anywhere either [22:29] i'm less concerned with the team name [22:29] thats painting the bikeshed [22:29] lets say we create -team [22:29] more concerned with validating my statements above that i remember this correctly [22:29] team thre just seems redundant [22:29] how does lazyPower push a new charm under nrpe-team if he or charmers isn't included as a member of the new group? [22:30] sorry I am being dense here [22:30] arosales: well, he needs to be a member. [22:30] ah ok [22:30] charmers doesn't push for people, we simply promulgate [22:30] I was just saying add ~charmers in general [22:30] arosales: why though? [22:30] we have no dog in that teams charm [22:30] for initial promulgation [22:30] don't need it [22:30] we can promulgate even without being in the team [22:31] promulgation is an implicit action, allowed to anyone in ~charmers, against an entity [22:31] I guess we could just add the person doing the initial push if that person isn't an active maintainer of said charm [22:31] ack on promulgation [22:31] I am just hung up on the initial push [22:31] it sounds like in that case we just make lazyPower a member of nagios-team [22:32] lazyPower: does the initial push under nagios-team [22:32] arosales - so your steps were fairly spot on [22:32] arosales: let the team do the push [22:32] but yeah, ^ [22:32] why are we doing things for people, if they're going to own, let them own it [22:32] cause its an infrastructure change [22:32] it's not [22:32] it is [22:32] anyone in ~nagios-team can run `charm push . ~nagios-team/nagios` [22:33] you don't need a charmer for that [22:33] in an ideal world, jamesj will have pushed this to nagios-team/nrpe [22:33] but sure we can also the maintainers to do it [22:33] and i just come along ahd issue charm promulgate on its published revision [22:33] exactly [22:33] marcoceppi: agreed any person in nagions-team can push, that is my point is in adding lazyPower [22:33] arosales - this is in the copy of hte new revq [22:33] but it is a infrastructure change [22:33] from LP ingestion to charm push [22:33] the teams going to have to do the next push [22:33] they need to learn how to do it [22:33] just looking for ways to ease that on charm authors [22:33] us doing it affords us nothing in the long term [22:34] we can certainly ask the maintainer to do the push and even set up the team [22:34] but we should note that it is due to the move to charm push, which is infrastructure change [22:34] fair point on maintainers knowing where their code lives [22:35] https://www.evernote.com/l/AX4egQ_nhRRCSaoWHZgwEnxC-k7lQc_EBI8B/image.png -- as we're working towards this end goal, here's a clip of reference material that will help soften the distribution of knowledge here [22:35] I think we just need to refer folks to some sort of page that tells them what to do [22:35] arosales: the documentations. [22:35] 1. make an lp team with -team [22:36] https://jujucharms.com/docs/stable/authors-charm-store [22:36] 2. add maintainers to the team [22:36] 3. charm push [22:36] 4. ping in here for promulgation until new review queue is running [22:36] correct marcoceppi ^ [22:36] * marcoceppi eod [22:39] marcoceppi: I don't think https://jujucharms.com/docs/stable/authors-charm-store explains the steps we specifically need here to move a charm from LP auto-ingestion to charm push [22:39] but I'll file a bug and take it from there have a good evening, thanks for the info [22:40] lazyPower: I'll ping maintainers of nrpe and haproxy and give them the instructions to move to non-lp charm push [22:40] until the review queue is ready I'll ask folks to ping in here for promulgation [22:41] While we have a few ecosystem folks around, I have a question: do you have any guidelines for writing reactive charms in a "defensive" manner that guards against race conditions? Yesterday I spent most of my day fixing those in a couple of our charms. [22:41] arosales - ok so, pause working those tickets until tomorrow? [22:42] its nearly 6, so i'm good to hold until tomorrow ;) but if they are emergent i can triage and deal with whatever mess i create :) [22:42] lazyPower: ya per marcoceppi suggestion we need to get the maintainers to push [22:42] Also, any best practices on how to automate branch management (in both bzr & git) of layer source vs. built layers? [22:42] ok, i'll follow up in the morning then. [22:42] lazyPower: no many thanks for the help and sticking around to make sure its all wrapped up well [22:43] blahdeblah - we haven't been versioning the assembled charms outside of what is pushed to the store. we only concern ourselves with keeping the layer in DVCS [22:43] s/dvcs/vcs/ [22:43] lazyPower: So that works for public charms; what about private ones? [22:44] blahdeblah - same :) [22:44] you dont have to add --acl=READ everyone [22:44] thats only if you *want* the charm to be public. You can give a select few people read access to your charm, which will prevent it from showing up in search/etc. [22:44] Hmmm. Doesn't it require charmers permission to push charms to the store? [22:44] naw [22:44] you can push charms to your namespace [22:45] Including team namespaces? [22:45] when its g2g for promulgation, we will ask you add the everyone read, and we then promulgate from your namespace [22:45] as long as you are a member [22:45] ^ [22:45] OK - might have to look into that. stub, mthaddon ^ FYI [22:46] blahdeblah: https://jujucharms.com/docs/stable/authors-charm-store should explain it [22:46] thanks [22:46] but if it doesn't file a bug at https://github.com/juju/docs/issues/new [22:46] arosales, lazyPower: What about the issue of writing reactive charms "defensively"? Any good resources? [22:46] we know we can make it better, just need feedback [22:46] blahdeblah: that is a tougher one [22:47] yer not wrong :-) [22:47] blahdeblah - when you say defensively, what d you mean? [22:47] I don't think we have any docs on it, but seems like a good candidate for best practices [22:47] lazyPower: I mean at the moment it's really easy to shoot yourself in the foot [22:48] i'm still not sure i follow [22:48] in creating states what are the best practices so one doesn't deadlock themselves [22:48] ^ that right there [22:48] deadlock is bad; race conditions that mean that charms sometimes work and sometimes randomly fail in CI is even worse, IMO [22:49] lazyPower: example: https://code.launchpad.net/~paulgear/charms/trusty/grafana/layer-grafana-reactive-states-fix/+merge/300547 [22:49] ya deadlock we can usually reproduce and debug, race that is just a hard to debug [22:50] lazyPower: if you read through the target branch of that merge, there are some conditions that simply weren't guaranteed to work in the right order [22:50] races can be guarded against, but your reactive modules become a huge stack of states [22:50] i encoutered this very problem with ETCD earlier today and had mattrae help debug it [22:50] *huge stack of necessary states <-- FTFY :-) [22:51] So in that particular example we had the admin password of grafana getting reset on every run of the update-status hook, and the db initialisation getting tried before the db existed [22:51] so the admin pasword being set - why isn't that a state? [22:51] It is now :-) [22:51] \o/ [22:52] thats basically my answer though, is to split apart your states to be more granular and even adopt some singleton states [22:52] meaning they only have a single context and are quite silly, but keep you from running the same method block 10000000x [22:52] My point is that going into writing reactive charms without a really clear plan and knowing the pitfalls can result in this. [22:52] yes [22:52] yes it can [22:52] you are not wrong at all [22:52] And it would be good to have some patterns & anti-patterns documented somewhere [22:53] we need to just put cory_fu on paper. he's got a ton of patterns and anti-patterns [22:53] but at least collecting a few them in best practices would help folks [22:53] as a starting point [22:53] Yep [22:53] arosales - you're really pounding the drum of docs today... [22:53] blahdeblah: I'll also file a docs bug on that [22:54] does this mean i'm going to see not bruzer and lazy doc commits soon? [22:54] If I get a chance to start on this, where and in what form would you like my thoughts? [22:54] lazyPower: if users don't know about it then its not a feature [22:54] (dont mind me nic and team, you guys do it all <3) [22:54] blahdeblah: https://github.com/juju/docs/issues/new [22:55] arosales: So just start an issue for best practices docs and throw things in there as they come up? [22:56] blahdeblah: I'll start the issue, and you can comment. We'll probably start with an initial page then take pulls and issues to continually update as we learn more. [22:56] Is there any ability to add graphviz (or graphviz-like) diagrams to the docs that way? [22:56] lazyPower: we all need to do more doc commits :-) [22:56] <3 [22:56] juju 2.0 is the default now in the store and in docs [22:56] blahdeblah - so, there's some interesting conversation around that [22:56] blahdeblah - i was using omnigraffle, but i did stumble across a markdown javascript lib that gives you the ability to make inline flow/uml charts [22:57] i know, markdown javascript lib? give me a sec to find the link, it'll blow your mind [22:57] lazyPower: omnigraffle - that's like a proprietary package that's only available on proprietary OS platforms, right? :-P [22:57] yep [22:57] http://markdown.dasapp.co/editor [22:58] its embedded in this markdown editor -- i think its the mathjax lib [22:58] I'll be giving omnigraffle a flying miss... :-) [22:58] * lazyPower redirects the obvious trolling about my choice in diagramming software to the real conversation about the js lib embedded in this markdown editor [22:59] blahdeblah: https://github.com/juju/docs/issues/1263 [22:59] lazyPower: Sorry dude; for me, it's still all about the licensing. :-) [22:59] I just want to be able to put stuff like http://graphviz.org/content/fsm or http://graphviz.org/content/traffic_lights in docs [23:00] there's nothing stopping you from comitting an svg and embedding it as an image [23:01] Looks like that's what existing docs use, e.g. https://jujucharms.com/docs/stable/developer-getting-started [23:01] thanks arosales - will put some thoughts there [23:01] oh you like my graphs? :) [23:01] i did those [23:02] With some proprietary app, no doubt. :-P [23:02] blahdeblah: thanks for adding your thoughts to it [23:02] !!! [23:02] Why you gotta hate on my non-proprietary pngs [23:02] * lazyPower sulks in the corner [23:03] lazyPower: The results are just fine. :-) [23:03] <3 ;) [23:03] arosales - we good then on all of the above? i need to run to catch a dinner date [23:03] lazyPower: I think we are good for today [23:03] have a good evening [23:03] thanks for the help [23:04] aight, same bat channel /time tomorrow then [23:04] * lazyPower doffs hat [23:04] you know it [23:06] thanks guys [23:13] lazyPower: i'm not sure, but I think so... 1hr ago :] [23:36] look what happens when my battery goes flat and canonical employees buy me beer [23:37] you lot have a bit fat irc chat [23:37] :) [23:37] its like we knew [23:37] jrwren - gracias [23:38] sickening [23:38] instead someone from opensuse told me brexit was cool! ;) [23:39] what conference are you at? [23:40] lol [23:40] Snappy Sprint [23:40] oh right, i knew this [23:40] s/this/that/ [23:41] hehe [23:41] well got invited by dustin [23:41] showed up [23:41] flamed ya boss [23:42] have a hangout with Bill Bauman tomorrow [23:42] sounds like a regular week [23:46] oooh lazyPower unlike kostas Mark knew who you were and infact told me to speak to you re DC/OS.....