/srv/irclogs.ubuntu.com/2016/07/20/#juju.txt

kjackal magicaltrout magicaltrout Hello juju world! 05:44 === frankban|afk is now known as frankban lightning talks today.... 09:21 hopefully mark has a good sense of humour.... https://imagebin.ca/v/2oh1GLMMHBVk 09:22 === rcj is now known as rcj 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 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 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 magicaltrout BRILLIANT! 13:05 sharan - you will need to change the scope of the relationship to scope: unit, and handle each conversation 13:05 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:07 lol 13:08 nice deq 13:08 i feel like I should own one 13:08 * lazyPower approves 13:08 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:09 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:10 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:11 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:12 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 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 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:15 so after updating scope in interface then i need to change some code in DB2 charm also right 13:16 yeah, mostly you'll need to iterate over the conversations and address as appropriate. 13:20 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:21 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:23 the guy playing the final solo at 17mins is pretty epic 13:24 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:25 oooo magicaltrout :fire: 13:26 lazyPower - http://bazaar.launchpad.net/~ibmcharmers/interface-ibm-db2/trunk/files 13:26 * 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:27 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:28 sharan - make sure you're familiar with https://jujucharms.com/docs/devel/developer-layers-interfaces#communication-scopes 13:32 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:33 cory_fu kwmonroe it's demo time, whats the best bundle to deploy for big software 13:34 lots of bigdata people here 13:34 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:35 * magicaltrout adds "finishing off apachedrill" to his todo list 13:37 lazyPower -  thanks, i will look into the link shared by you 13:44 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:47 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 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 woop 15:21 jcastro: i got turned down for linuxcon.... sad times 15:21 jcastro: i got accepted for mesoscon..... good times 15:21 so you're dispatching me to amsterdam 15:22 lazyPower: --^ 15:24 Nice! 15:24 I wish i could come with 15:24 It would be great to tag-team the casuals 15:24 hehe 15:25 does mean I have some work to do... only a month away :P 15:28 wooo thats true 16:17 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 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:03 lazyPower: +1 17:05 ta 17:08 lazyPower: Oops.  https://github.com/juju/plugins/pull/68 17:31 +1'd 17:34 Anybody seen this error before?  http://pastebin.ubuntu.com/20203784/ 17:47 (This is on AWS) 17:47 i have not, and thats an odd duck cory_fu 17:48 that looks like the image is missing core system components 17:48 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:49 Ah! 17:51 http://www.sillycodes.com/2015/06/quick-tip-couldnt-create-temporary-file.html saved my bacon 17:51 ah so the rest of that was red herring 17:52 cleaning up the apt bits worked, good to know 17:52 here's a very weird observation..... its funny how different the juju dev team is to the snaps dev team 20:42 in what way? 20:45 the type of person 20:46 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 you mean we're more optimistic? :D 20:56 lol 20:58 if i'm  honest i'd probably call you more "ballttle hardened" 20:58 (except for marcoceppi ) 20:59 stupid wifi lag: battle hardened 20:59 === natefinch is now known as natefinch-afk haha 21:08 we're battle hardened 21:08 hear that jrwren? He called us a noble steed 21:08 magicaltrout: great observation 21:11 well, I know /I/ am. 21:13 but I'd have called marcoceppi the most battle hardened. 21:13 not the exception. 21:13 you're not wrong :) 21:27 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 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 (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 Actually, github does the magic for me -- just needed to add .patch to the url of the old PR. Awesome :-) 21:52 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:03 just needs a charmer , and I think we need to update the charms to get them in a non-lp ingestion world 22:04 lazyPower: ? ^ 22:05 * lazyPower looks 22:07 arosales - have we found resolution on https://code.launchpad.net/~jamesj/charms/trusty/haproxy/xenial-support/+merge/299196/comments/772700? 22:08 ah mult-series and charm push 22:09 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:11 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:12 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:13 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:14 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:15 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:16 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:17 lazyPower same issues with https://code.launchpad.net/~stub/charms/trusty/nrpe/py3/+merge/300153 ? 22:18 nrpe doesn't look to touch the series 22:19 no i think nrpe is just a push 22:19 * lazyPower double checks 22:19 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:20 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:21 ya https://jujucharms.com/q/nrpe looks to support all series 22:22 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:23 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:24 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:25 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:26 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:27 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:28 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:29 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:30 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:31 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:32 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:33 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:34 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:35 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:36 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:39 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:40 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:41 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:42 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:43 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:44 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:45 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:46 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:47 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:48 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:49 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:50 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:51 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:52 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:53 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:54 arosales: So just start an issue for best practices docs and throw things in there as they come up? 22:55 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:56 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:57 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:58 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 22:59 there's nothing stopping you from comitting an svg and embedding it as an image 23:00 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:01 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:02 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:03 aight, same bat channel /time tomorrow then 23:04 * lazyPower doffs hat 23:04 you know it 23:04 thanks guys 23:06 lazyPower: i'm not sure, but I think so... 1hr ago :] 23:13 look what happens when my battery goes flat and canonical employees buy me beer 23:36 you lot have a bit fat irc chat 23:37 :) 23:37 its like we knew 23:37 jrwren - gracias 23:37 sickening 23:38 instead someone from opensuse told me brexit was cool! ;) 23:38 what conference are you at? 23:39 lol 23:40 Snappy Sprint 23:40 oh right, i knew this 23:40 s/this/that/ 23:40 hehe 23:41 well got invited by dustin 23:41 showed up 23:41 flamed ya boss 23:41 have a hangout with Bill Bauman tomorrow 23:42 sounds like a regular week 23:42 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!