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