kjackal | Hello juju world! | 05:44 |
---|---|---|
=== frankban|afk is now known as frankban | ||
magicaltrout | lightning talks today.... | 09:21 |
magicaltrout | hopefully mark has a good sense of humour.... https://imagebin.ca/v/2oh1GLMMHBVk | 09:22 |
=== rcj` is now known as rcj | ||
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:27 |
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 | 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 |
=== CyberJacob is now known as zz_CyberJacob | ||
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:05 |
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:07 |
magicaltrout | lol | 13:08 |
lazyPower | nice deq | 13:08 |
magicaltrout | i feel like I should own one | 13:08 |
* lazyPower approves | 13:08 | |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
sharan | so after updating scope in interface then i need to change some code in DB2 charm also right | 13:16 |
lazyPower | yeah, mostly you'll need to iterate over the conversations and address as appropriate. | 13:20 |
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:21 |
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:23 |
magicaltrout | the guy playing the final solo at 17mins is pretty epic | 13:24 |
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:25 |
lazyPower | oooo magicaltrout :fire: | 13:26 |
sharan | lazyPower - http://bazaar.launchpad.net/~ibmcharmers/interface-ibm-db2/trunk/files | 13:26 |
* 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:27 |
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:28 | |
lazyPower | sharan - make sure you're familiar with https://jujucharms.com/docs/devel/developer-layers-interfaces#communication-scopes | 13:32 |
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:33 |
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:34 |
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:35 |
* magicaltrout adds "finishing off apachedrill" to his todo list | 13:37 | |
sharan | lazyPower - thanks, i will look into the link shared by you | 13:44 |
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:47 |
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 | 13:48 | |
=== natefinch is now known as natefinch-afk | ||
* magicaltrout wonders how far he can push the lighthearted trolling without getting kicked out of the sprint | 14:50 | |
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? | 14:53 |
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:21 |
magicaltrout | so you're dispatching me to amsterdam | 15:22 |
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:24 |
magicaltrout | hehe | 15:25 |
magicaltrout | does mean I have some work to do... only a month away :P | 15:28 |
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 | 16:17 |
=== natefinch-afk is now known as natefinch | ||
=== frankban is now known as frankban|afk | ||
=== cmagina is now known as cmagina_lunch | ||
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:03 |
cory_fu | lazyPower: +1 | 17:05 |
lazyPower | ta | 17:08 |
cory_fu | lazyPower: Oops. https://github.com/juju/plugins/pull/68 | 17:31 |
lazyPower | +1'd | 17:34 |
cory_fu | Anybody seen this error before? http://pastebin.ubuntu.com/20203784/ | 17:47 |
cory_fu | (This is on AWS) | 17:47 |
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:48 |
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:49 |
cory_fu | Ah! | 17:51 |
cory_fu | http://www.sillycodes.com/2015/06/quick-tip-couldnt-create-temporary-file.html saved my bacon | 17:51 |
lazyPower | ah so the rest of that was red herring | 17:52 |
lazyPower | cleaning up the apt bits worked, good to know | 17:52 |
magicaltrout | here's a very weird observation..... its funny how different the juju dev team is to the snaps dev team | 20:42 |
mgz | in what way? | 20:45 |
magicaltrout | the type of person | 20:46 |
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:47 |
lazyPower | you mean we're more optimistic? :D | 20:56 |
magicaltrout | lol | 20:58 |
magicaltrout | if i'm honest i'd probably call you more "ballttle hardened" | 20:58 |
magicaltrout | (except for marcoceppi ) | 20:59 |
magicaltrout | stupid wifi lag: battle hardened | 20:59 |
=== natefinch is now known as natefinch-afk | ||
lazyPower | haha | 21:08 |
lazyPower | we're battle hardened | 21:08 |
lazyPower | hear that jrwren? He called us a noble steed | 21:08 |
marcoceppi | magicaltrout: great observation | 21:11 |
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:13 |
lazyPower | you're not wrong :) | 21:27 |
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:49 |
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:50 |
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:51 |
petevg | Actually, github does the magic for me -- just needed to add .patch to the url of the old PR. Awesome :-) | 21:52 |
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:03 |
arosales | just needs a charmer , and I think we need to update the charms to get them in a non-lp ingestion world | 22:04 |
arosales | lazyPower: ? ^ | 22:05 |
* lazyPower looks | 22:07 | |
lazyPower | arosales - have we found resolution on https://code.launchpad.net/~jamesj/charms/trusty/haproxy/xenial-support/+merge/299196/comments/772700? | 22:08 |
arosales | ah mult-series and charm push | 22:09 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
arosales | lazyPower same issues with https://code.launchpad.net/~stub/charms/trusty/nrpe/py3/+merge/300153 ? | 22:18 |
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:19 | |
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:20 |
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:21 |
arosales | ya https://jujucharms.com/q/nrpe looks to support all series | 22:22 |
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:23 |
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:24 |
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:25 |
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 | 22:26 |
marcoceppi | <app>-team or something similar is better | 22:26 |
arosales | ok, we should document this somewhere | 22:26 |
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:27 |
arosales | so what team would lazyPower push nrpe under then? | 22:28 |
marcoceppi | <app>-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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 | |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
blahdeblah | arosales: So just start an issue for best practices docs and throw things in there as they come up? | 22:55 |
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:56 |
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:57 |
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:58 | |
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 | 22:59 |
lazyPower | there's nothing stopping you from comitting an svg and embedding it as an image | 23:00 |
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:01 |
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:02 | |
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:03 |
lazyPower | aight, same bat channel /time tomorrow then | 23:04 |
* lazyPower doffs hat | 23:04 | |
arosales | you know it | 23:04 |
blahdeblah | thanks guys | 23:06 |
jrwren | lazyPower: i'm not sure, but I think so... 1hr ago :] | 23:13 |
magicaltrout | look what happens when my battery goes flat and canonical employees buy me beer | 23:36 |
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:37 |
magicaltrout | sickening | 23:38 |
magicaltrout | instead someone from opensuse told me brexit was cool! ;) | 23:38 |
lazyPower | what conference are you at? | 23:39 |
magicaltrout | lol | 23:40 |
magicaltrout | Snappy Sprint | 23:40 |
lazyPower | oh right, i knew this | 23:40 |
lazyPower | s/this/that/ | 23:40 |
magicaltrout | hehe | 23:41 |
magicaltrout | well got invited by dustin | 23:41 |
magicaltrout | showed up | 23:41 |
magicaltrout | flamed ya boss | 23:41 |
magicaltrout | have a hangout with Bill Bauman tomorrow | 23:42 |
magicaltrout | sounds like a regular week | 23:42 |
magicaltrout | oooh lazyPower unlike kostas Mark knew who you were and infact told me to speak to you re DC/OS..... | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!