/srv/irclogs.ubuntu.com/2016/03/16/#juju.txt

=== natefinch-afk is now known as natefnich
=== natefnich is now known as natefinch
=== bruno is now known as Guest32213
=== Guest32213 is now known as BrunoR
axinohi09:18
axinohas anyone ever tested a reactive charm on xenial ?09:18
jaceknand I would like to remind you about my collectd subordinate: https://bugs.launchpad.net/charms/+bug/1538573 review :)09:33
mupBug #1538573: New collectd subordinate charm <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1538573>09:33
fstyrellI just found the Juju is a great tool.09:37
magicaltroutfstyrell: you're late! ;)09:38
fstyrellhaha,😃09:39
magicaltroutjacekn: http://review.juju.solutions/ you're not in the review queue09:40
fstyrellI am thinking play Juju with ansible.09:41
magicaltroutah cool, well lazyPower was the guy that gave the talk about juju & ansible in Belgium this year09:42
magicaltroutwhen he wakes up you should prod him about it :)09:42
fstyrelloh, thanks. Can i find the talk video at youtube ?09:46
magicaltrouterm09:46
magicaltroutshould be able to09:46
fstyrellfound it.😉09:47
magicaltrouthttps://www.youtube.com/watch?v=0eymk93lY8k09:47
magicaltroutquicker than me :P09:47
fstyrellthanks, you are very nice.09:48
magicaltroutI'm not, i'm just bored :P09:48
jaceknmagicaltrout: so what do I need to do to be there? I was told in the past that setting my bug to "fix commited" was good enough10:00
magicaltroutjacekn: thats the $1m question, I don't know that either :)10:00
jaceknmagicaltrout: I've been trying to get that charm merged since January....10:00
marcoceppiaxino: it should work, what's the problem?10:30
stubmarcoceppi: axino's problem is his charm is attempting to pull in charmhelpers from pypi, which isn't going to work in his environment.11:37
stubmarcoceppi: I think the problem is he specified to use a venv and not fall back to system packages in his layer options, but I'm not sure.11:38
stubmarcoceppi: sorry, not charmhelpers. setuptools.11:40
stub2016-03-16 07:52:42 INFO install Installing setuptools, pkg_resources, _markerlib, pip, wheel...11:41
stub2016-03-16 07:52:42 INFO install   Complete output from command /var/lib/juju/agents...-0/.venv/bin/python3 - setuptools pkg_resources _markerlib pip wheel:11:41
stub2016-03-16 07:52:42 INFO install   Collecting setuptools11:41
stubAnd then it explodes, because it can't collect setuptools11:41
marcoceppiaxino: stub: yeah looks you'll want to use both venv and system-packages options in the layer.yaml cory_fu ^^12:49
dosaboygnuoy: qq on https://code.launchpad.net/~gnuoy/charm-helpers/keystone_authtoken/+merge/28904213:21
jcastrolazyPower: 16gb of RAM, usage seems fine, it's IO that gets wailed on13:21
jcastrolazyPower: I'll fire up the bundle again next daily and you can observe13:21
BrunoR"import amulet" yields an "ImportError: No module named 'path'" in python3 for amulet 1.13.0-0ubuntu1~ubuntu15.10.1~ppa1 ~ is this a missing dependency?13:39
tvansteenburghmarcoceppi: ^13:40
marcoceppiBrunoR: it's being worked on13:41
BrunoRmarcoceppi: can you give me a work-around or an estimate how long this will take?13:56
magicaltrout\_____________________o_________________/13:56
rick_h__best answer ever?13:57
magicaltrouthehe13:58
magicaltroutrick_h__: marcoceppi someone who knows me and jacekn want to know how you get stuff that has been reviewed and rejected back into the review queue13:58
marcoceppiBrunoR: 2 hours, pip install amulet into an activated python virtualenv for now13:58
marcoceppimagicaltrout: move the bug to new or fix committed13:59
magicaltroutfair enough13:59
magicaltroutjacekn: dunno then, you're just in limbo somewhere :)13:59
marcoceppimagicaltrout: this/next month new review queue where this will be streamlined13:59
marcoceppijacekn: ^^13:59
magicaltroutcool, *finally* got Saiku 3.8 cut14:01
magicaltroutso i *am* going to get this fscking charm finished :P14:01
lazyPowermagicaltrout schenanigans ;)14:07
jaceknmarcoceppi: yes I'm aware of that. Are you saying I just have to wait and there is no way around it?14:07
magicaltroutjacekn: can you set the bug to new?14:08
jaceknmarcoceppi: (I've been trhing to get this charm into the charmstore since Jan)14:08
magicaltroutmight trigger the regrepping of the issue and pick it back up14:08
jacekndone14:08
jaceknmarcoceppi: magicaltrout: there is also another thing that is problematic - because charmstore submissions can take months and we have to keep working I had to "freeze" that layer for submissions and I work on it's fork. That fork is moving furgher and further away from what you are reviewing14:10
marcoceppijacekn: again, these are all growing pains as we wait for teh new charm upload command and review queue14:10
marcoceppithat goes away come the new charmstore14:10
marcoceppijacekn: I found the issue with teh review queue, give me a min to address14:11
jaceknmarcoceppi: ok, I thoujgh there was also resources problem but if it's just the queu itself it's easy to solve14:11
marcoceppijacekn: trhe problem is the review queue is tied to the old charm store method of "everything in lp" going forward, you'll just submit a charmsto0re url, like cs:~jacekn/collectd-10 for review and you can continue to dev/rev, the review queue will be quicker to pick things up, quicker to test, and quicker to land fixes while also adding a lot of observability to you and charmers14:13
marcoceppito do this we're decoupling from the lp, like the charmstore is currently, but until the new charm command lands (hopefully this week) we can't really switch over or finish the new review queue14:13
marcoceppiso we're in a weird transition state14:13
cory_fuaxino, stub, marcoceppi: Sorry I'm late to the conversation, but does your charm layer have its own wheelhouse.txt?  Also, did you do the initial charm-build on a xenial box?  That error looks somewhat similar to https://github.com/juju/charm-tools/issues/117 though not exactly the same.14:15
marcoceppijacekn magicaltrout I've just kicked the reviewqueue with a large boot, in the next few hours it should be up-to-date (after it finishes crawliing lp)14:15
marcoceppijacekn: in the meantime, I'll take a look and review your charm now!14:15
magicaltroutta14:16
jaceknthanks!14:18
marcoceppijacekn: I've just kciked off a test against AWS, pending that coming back pass it LGTM14:23
jaceknmarcoceppi: great! thanks!14:23
marcoceppitvansteenburgh: something just crossed my mind, bundletester isn't really packaged anywhere and now is the best time to deprecate charm test for bundletester14:28
tvansteenburghmarcoceppi: okay. what would you like me to do?14:30
marcoceppitvansteenburgh: does that sound like a good idea?14:30
marcoceppior should we just package bundle tester seperate?14:30
tvansteenburghmarcoceppi: separate from what?14:30
marcoceppicharm-tools14:31
tvansteenburghyes14:31
tvansteenburghmarcoceppi: package separate, then we can change the impl of `charm test` to call bundletester, or charmbox, or whatever14:31
marcoceppiah, yeah, true14:32
beisnerhi marcoceppi, tvansteenburgh - os-charms aren't clear yet to break from juju test (need to be able to preserve enviro variables a la `juju test -p`)  if i'm mistaken on that, thump me on the noggin.14:35
lazyPower+1 to that14:35
marcoceppibeisner: well, adding preserve env variables is easy enough, but I'll keep that in mind14:37
beisnermarcoceppi, tyvm.  for ref:  https://github.com/juju-solutions/bundletester/issues/1714:37
=== rogpeppe2 is now known as rogpeppe
tvansteenburghbeisner, marcoceppi: bundletester already preserves all envvars by default15:04
beisnertvansteenburgh, sweet.  thank you for confirming.15:07
jcastrohey bdx, I'm going to mail the fiche author and let him know the charm has been promulgated15:13
jcastroI figured it'd be cool to let him know15:13
marcoceppirick_h__: urulama the charm push command doesn't upload dot files?15:31
rick_h__marcoceppi: nope, due to size/etc it's not a replacement for git clone15:31
marcoceppirick_h__: wtf, .build.manifest is not a version control file15:32
marcoceppiyou can't blanket assume any dot file or directory is for vcs15:32
marcoceppirick_h__ urulama I can apprecaite a whitelist of thigns like .git, .bzr, .gitignore, but there are files in charms that are dot files that are needed for operationa nd we're stripping them out.15:35
* marcoceppi opens bug15:35
magicaltroutyou need .charmignore! ;)15:35
lazyPoweryou gest, but i think thats a great idea ;D15:35
lazyPowers/gest/jest/15:36
jrwrenhidden files look to have been excluded since 2011: https://github.com/juju/charm/commit/ddf98e0f66ebad7ccb9c41d409b64c1febbd4cf3#diff-59640b4e3d1c61f83bdd75d573589453R15415:44
marcoceppijacekn: what. this is stupid, it only hides on the top level15:45
magicaltroutdon't abuse the wrong person :P15:45
rick_h__marcoceppi: fair enough, please open a bug. This is good feedback from testing things out15:46
marcoceppijrwren: **15:46
marcoceppirick_h__: bug opened, I'll open one against charm as well15:46
rick_h__marcoceppi: appreciate it15:46
jrwreni agree. it is stupid.15:55
marcoceppi<3 didn't realize how long that's been a thing15:56
jrwrenI also agree, a .charmignore would be nice.15:58
lazyPowermarcoceppi - sounds great, but the base layer is GPL-3'd as well :-\16:18
marcoceppilazyPower: sure, we should change that cory_fu ^16:19
lazyPowerhttps://github.com/juju-solutions/layer-basic/issues/4716:20
lazyPoweri bug'd it16:20
cory_fuo_O  I've been making all of my layers Apache licensed.  I had no idea that basic was GPL.16:22
lazyPowerthats what i considered then i saw the base layer was GPL'd, soooo16:23
lazyPoweri figured i had to follow suit16:23
cory_fubcsaller: I think you chose the original license for the basic layer.  Any reason you chose GPL?16:23
bcsallercory_fu: no, we can issue it under a new license at any time16:24
cory_fulazyPower: I'm not seeing the comment that was the original context for you noting that the basic layer is GPL16:26
lazyPowercory_fu - ah thread origin started in the logstash layer - https://github.com/juju-solutions/layer-logstash/pull/1116:26
cory_fuSo I certainly have no objections to changing the license, and I'm sure none of the other committers or members of juju-solutions would object, but is there a formal process we need to follow?16:27
magicaltrouttechnically afaik you need written consent from the copyright holders16:27
cory_fumagicaltrout: The copyright is assigned to Canonical16:29
cory_fuWould a PR from a Canonical employee count as written consent?  :p16:29
lazyPoweri vote ben saying we can at any time on IRC as the word of good16:29
bcsallerthe only commiters I see are canonical as well16:29
cory_fuYeah16:29
magicaltroutdepends who commits I guess if its canonical, who cares16:30
magicaltroutyou guys have no ICLA in place for outside commits16:30
magicaltroutnot that I think you'll get into issues, but there's no formal joint copyright holding or migration of ownership16:30
magicaltroutbut IANAL, so just going from past experience16:30
bcsallerI'd rather err of the side of too permissive than make a choice that made people feel unable to use this code16:31
magicaltroutcory_fu: for example I remember when PDI swapped from GPL to ASL, and they had to find every committer and get them to sign off on the license change as there was no CLA just adhoc contributions from the outside world :)16:34
magicaltroutwe did the same with Saiku and now have a CLA for committers to sign16:34
magicaltroutand obviously in Apache land we all have to sign a CLA before committing anything16:35
=== alexisb is now known as alexisb-afk
=== natefinch is now known as natefinch-lunch
=== alexisb-afk is now known as alexisb
matt_dupreHi!  I was wondering if anyone knew roughly when OpenStack charms for Mitaka on Xenial will be available (pre-releases / testing are fine)?18:31
matt_dupreI see there are some mentions in the store: https://jujucharms.com/q/openstack?series=xenial, but 0 deploys on most of them still18:32
cholcombeanyone know how to mock os.lstat?  I'm trying to instantiate posix.stat_result manually and it's trickier than i thought18:34
cholcombenvm i just figured it out.  posix.stat_result wants a list not a dict18:39
marcoceppimatt_dupre: beisner or coreycb might be able to help. We've been deploying them on Xenial for a bit, and I think that the last charm release in January helped carve out Mitaka support18:40
beisnerhi matt_dupre - the "next" charms track the development version of the charms (beware, they have a lot of movement currently).  https://jujucharms.com/u/openstack-charmers-next/18:43
=== natefinch-lunch is now known as natefinch
beisnerwolsen, can you have a cruise through these?:19:27
beisnerhttps://review.openstack.org/#/c/293616/19:28
beisnerhttps://review.openstack.org/#/c/293608/19:28
beisnerhttps://review.openstack.org/#/c/293625/19:28
wolsenbeisner, sure19:28
beisnerwolsen, ta19:28
wolsenbeisner, np19:28
fritchieHi all, if 'juju status' just hangs how can the issue be diagnosed?20:19
beisnerhi fritchie - i'm out shortly, but i'd do `juju status --debug` to get more info about where it's hanging.20:40
marcoceppifritchie: yup --debug is a good start. Also, out of curiosity, what is the environment you're using and juju version?20:41
lazyPowercory_fu - didn't you write a layer for templating to break that out of CH?20:44
cory_fulazyPower: I did: https://github.com/juju-solutions/charms.templating.jinja220:45
lazyPoweri just found it, gracias20:45
cory_fulazyPower: The main reason I did that was because I needed to add the ability to provide custom filters & tests, and didn't want to keep CH alive20:46
lazyPowerI completely respect this decision20:46
lazyPowerso, i need to add this to my layers wheelhouse.txt correct?20:46
lazyPowercharms.templating.jinja2>=0.0.1<=1.0.020:46
cory_fuYes, though I started it at 1.0.020:47
lazyPowero, even better20:47
fritchiemarcoceppi, juju and maas on same node20:48
fritchiefor version, I am reinstalling now :-)20:48
marcoceppifritchie: does maas show the bootstrap node as still running?20:48
fritchieright now 5 hp dl380s, 2 nics each, 2nd nic being used for dhcp, no external router20:49
lazyPowercory_fu I just added that ot my wheelhouse, re-built, and upgrade-charm'd, however i get this during baselayer updating from the wheelhouse - https://gist.github.com/chuckbutler/5b7a70a8a2e944cfa31b20:52
cory_fuI could swear that was fixed20:57
cory_fulazyPower: That was fixed in 1.0.1, 20 days ago: https://github.com/juju-solutions/charms.templating.jinja2/commit/9df7ef886ec6e3f570f103422c0804501ca56d3120:58
cory_fuDid your charm-build pick up 1.0.1 or 1.0.0?20:58
cholcombebeisner, my test failure on 287500 is quite odd.  the unit test works locally but fails when i upload it20:58
lazyPowercory_fu 1.0.020:58
lazyPowerlet me try again, and see if it pulls in 1.0.120:59
magicaltrouthere's a question for you marcoceppi et al https://jujucharms.com/q/?text=pentaho20:59
cory_fulazyPower: Yeah, pypi definitely has 1.0.121:00
beisnercholcombe, looks like dev_name != 'sda'  re:  http://logs.openstack.org/00/287500/4/check/gate-charm-ceph-osd-python27/ae7b39a/console.html#_2016-03-16_19_15_09_75821:00
magicaltrouthow does the charm store come to its conclusion, for example, i write a charm, its not recommended but there is nothing else pentaho related in the store21:00
cholcombebeisner, yeah i saw that.  the odd thing is that works fine on my local box21:00
cholcombei patched python's open function21:00
marcoceppimagicaltrout: you should talk to rick_h__ about this one. I can't explain the searching results stuff, but I know that it's something our web team is looking into.21:01
magicaltrouthow come i get 54(!) recommended charms21:01
magicaltroutfair enough21:01
=== natefinch is now known as natefinch-afk
cholcombebeisner, maybe marcoceppi is there a better way to patch open in python?21:01
magicaltroutit just seems a bit loaded, i'm all for recommended charms clearly, but when the search must return basically 0, how it ends up so far down the page is a bit tedious21:01
magicaltroutand hard for users who just want to see if anything pentaho related happens to be in the store21:02
marcoceppimagicaltrout: I agree21:02
marcoceppicholcombe beisner how can I help?21:02
lazyPowerrick_h__ - have we thought about talking to merlijin and team about a recommendation engine for the charm store? Might make our search story significantly better21:02
beisnercholcombe, destroy your venvs and re-run with `tox -e py27` ?21:02
cholcombeok21:02
lazyPowerrick_h__ - and i cant think of anyone better to ask than data scientists21:02
lazyPowermagicaltrout - you're completely included in this list as well ^21:03
magicaltrouthehe21:03
lazyPoweri can see it now21:03
magicaltroutwell sometimes i put the scientist hat on, but most of the time I hide it behind the sofa21:03
lazyPower"You just deployed wordpress. Can i interest you in VARNISH?"21:03
magicaltroutit just strikes me that there should be some ranking going on, keyword relevance, recommended vs non recommended, times deployed, age, last updated etc21:04
magicaltroutput it in a pot and give it a stir and come up with a search ranking algo that makes it better21:05
cholcombelazyPower, can I pay to have my charm moved up the list? lol21:05
lazyPowermagicaltrout - best SOW ever21:05
beisnercharmwords(tm)21:05
magicaltrouthehe21:05
lazyPowercholcombe - thats unethical21:06
cholcombehehe21:06
lazyPowersmall merge or new charm?21:06
cholcombei'm just kidding21:06
lazyPowerhey  i try to bribe with pizza all the time21:06
cholcombehah21:06
lazyPoweri guess people dont like bread and cheese as much as they used to21:06
axinocory_fu: I don't know if the charm was built on xenial21:07
cory_fuaxino: It may be that pip has different requirements on xenial, though I would expect it to not matter since it's a python lib.21:08
lazyPowercory_fu - pebkac in the wheelhouse.txt, i had >=1.0.0, so it stopped. >1.0.0,<=2.0.0 seems to have pulled in the right dep.21:08
cory_fulazyPower: Odd.  I would have thought that >=1.0.0 would still have pulled in the highest version21:08
lazyPowerdidn't appear to, i got 1.0.0 otherwise21:09
axinocory_fu: "include_system_packages: false" in layer.yaml21:09
axinocory_fu: perhaps I should change that ?21:09
cory_fuaxino: It's certainly worth a shot, but shouldn't be necessary21:10
cory_fuaxino: If it works, please let me know21:10
axinocory_fu: it does have a wheelhouse directory with tar.gz in it, but no wheelhouse.txt afaics21:11
cory_fuaxino: Is that the built charm or the source layer?  I don't suppose you can provide a link?21:11
axinothe built charm21:12
axinocory_fu: try https://launchpad.net/~canonical-sysadmins/canonical-is-charms/collectd/ ?21:12
axinoI doubt it though21:13
axinocory_fu: https://code.launchpad.net/~axino/canonical-is-charms/collectd should work for you21:16
cory_fuaxino: I can access the first one, actually  :)21:16
axinoho21:16
axinowell21:16
cory_fuaxino: So, that's the built charm artifact, so I wouldn't expect it to have the wheelhouse.txt; that gets converted to the wheelhouse/ directory during build.21:17
axinook good21:17
cory_fu(Though, now that I think about it, it should probably preserve the combined wheelhouse.txt as well, just in case)21:17
cory_fuaxino: That wheelhouse looks entirely reasonable, except that it has two versions of charms.reactive in it21:17
axinodoes that include setuptools ?21:18
axinolooks like not21:18
cory_fuNo, it doesn't.21:18
cory_fuHowever, if pip depends on it, it ought to.  My guess is that there is a difference in how venvs are created between xenial and trusty and perhaps setuptools is included by default in the former.21:19
axinocory_fu: https://pastebin.canonical.com/151985/ is the error I get, in case you didn't see it21:20
cory_fuQuite possibly, doing the charm-build from the source layer on a xenial box might fix it.21:20
axinook21:20
cory_fuaxino: Ok, so that's not even getting to the wheelhouse.  It's actually failing trying to create the venv21:22
axinocory_fu: if you have any additional insight, I'll take it :)21:24
cholcombebeisner, i'm pushing up a patch set with more logging.  It def works fine locally21:26
cholcombebeisner, i tried a clean docker env also and it's fine21:27
cory_fuaxino: I think it's actually a problem with xenial.  Creating a virtualenv apparently requires setuptools but the python3-virtualenv package isn't listing it as a dependency21:27
cory_fuaxino: Normally, that wouldn't be too big of a deal, as it gets pip installed on demand when creating the venv, but in that network-restricted environment, it fails.21:27
axinocory_fu: note that I have this behaviour even with python3-setuptools installed21:27
cory_fuaxino: Ok, what about with python-setuptools?21:27
axinocory_fu: same21:28
cory_fuaxino:  If you have a restricted network xenial env, can you try manually doing the following:21:29
cory_fusudo apt-get install python3-virtualenv21:29
cory_fupython3-virtualenv testenv21:29
cory_fu(That last one might be virtualenv3)21:29
cory_fuProbably is21:29
axinook, trying now21:29
cory_fuAnd then also try `virtualenv --python=python3 testenv2`21:30
axinocory_fu: I have no virtualenv3, and no python3-virtualenv binary21:30
cory_fuaxino: Ok, I'm not surprised.  Try the other one, please.21:31
cory_fuI saw the python3-virtualenv package in your error and got optimistic21:31
cory_fu:p21:31
axino:)21:32
axinocory_fu: yup that's failing the same way21:32
axinotiming out21:32
cory_fuaxino: Yeah.  The problem isn't reactive charms, per se.  It's that virtualenvs don't work in network-restricted envs in xenial21:32
cory_fuaxino: What *should* happen is that, if python{,3}-setuptools is installed, it should use setuptools from that and not try to pip install it21:33
axinocory_fu: just tried virtualenv --python=python3 --system-site-packages testenv2, same error21:33
axinohmm, Ubuntu/Debian install in dist-packages though21:34
axino"virtualenv --python=python3 --no-setuptools --no-pip testenv2" now it's timing out on "installing wheel"21:35
cory_fuaxino: Honestly, I don't know why virtualenv is trying to install anything from pypi.  It shouldn't.21:35
cory_fuaxino: What version of pip does xenial have?21:38
axinocory_fu: 8.1.0-221:38
axinocory_fu: !! virtualenv --python=python3 --never-download testenv2 <= that worked21:39
axinoof course this option is not in the man21:39
axinohttp://ccnmtl.columbia.edu/compiled/released/new_features_in_virtualenv.html found it here21:40
cory_fuaxino: That's terrible.  If it can succeed with that option, that means it has the packages locally and so why did it even attempt to download them in the first place?21:40
axinocory_fu: yeah. :(21:41
cory_fuaxino: That option seems to work on trusty's virtualenv as well, so I'm fine with adding it to layer-basic21:42
cory_fuaxino: I'm a little bit concerned about any repercussions that might have on trying to install the wheelhouse after that.  I don't suppose you have the wheelhouse dir handy on that unit?21:44
axinocory_fu: I have, this is the unit where the charm is failing its install hook21:44
cory_fuOk, I was hopeful.  Can you try doing: testenv2/bin/pip install -U --no-index -f wheelhouse wheelhouse/*21:45
axinocory_fu: https://github.com/pypa/virtualenv/pull/412 looks like this may become the default ? or something, just skimmed over the comments21:45
axinocory_fu: https://pastebin.canonical.com/152054/ LGTM21:47
cory_fuaxino: Ok, great.21:48
axinolet me hack lib/charms/layer/basic.py on disk and juju resolved -r that install hook21:50
marcoceppicory_fu tvansteenburgh BrunoR amulet 1.14.0 fixes all issues for trusty and xenial21:55
marcoceppiit's out, it's tested, it's working21:55
tvansteenburghyay, thanks marcoceppi!21:55
cory_fuaxino: https://github.com/juju-solutions/layer-basic/pull/4821:56
axinocory_fu: cool ! thanks21:56
cory_fumarcoceppi: Awewsome!  Thanks21:57
marcoceppitvansteenburgh: bleh @ your pull req22:01
tvansteenburgh?22:01
tvansteenburghmarcoceppi: you don't have to do another release22:01
marcoceppitvansteenburgh: Oh I won't22:01
tvansteenburghmarcoceppi: i was just about to upload new docs and figured i'd do that first22:01
marcoceppitvansteenburgh: ack, lgtm22:01
kwmonroecory_fu: will this fire if a different function (like quorum_add on line 43) changes zoo.cfg?22:04
kwmonroehttps://github.com/juju-solutions/layer-apache-zookeeper/blob/master/reactive/zookeeper.py#L3322:04
tvansteenburghmarcoceppi: thanks, docs uploaded22:04
kwmonroecory_fu: i'm seeing stuff like "Invoking reactive handler: reactive/zookeeper.py:41:quorum_add" when a peer comes along, and i know that function updates zoo.cfg, but i don't see a subsequent firing of the method gated by @when_file_changed(zoo.cfg)22:05
kwmonroeeven when i go on that unit and type naughty words into zoo.cfg, i don't see that method being called on the next status_update.22:06
cory_fukwmonroe: Yes.  Any time that file changes, it should trigger that handler.  However, combining @when and @when_file_changed may run you up against the open issue(s) with @when_file_changed22:06
kwmonroeah, yeah, you warned me of that22:07
cory_fukwmonroe: Actually, even without the @when, I think you're running up against those issues.  I'm pretty sure zkpeer.dismiss_joined() is removing a state, which can cause the @when_file_changed to get dropped22:07
cory_fukwmonroe: https://github.com/juju-solutions/charms.reactive/issues/4422:08
kwmonroeyeah, i need to double check if we really need to do the dismiss_joined.  i think we're doing that so we pick up subsequent peer joins.22:08
kwmonroebut dunno if that's really needed.22:08
cory_fuI doubt that it's necessary22:08
kwmonroeack cory_fu.  is the "any_file_changed" helper safer than @when_file_changed whilst issue 44 gets worked?22:09
cory_fuYes22:09
kwmonroeroger dodger.  thanks.22:09
cory_fuThat will avoid the issue.22:09
cory_fukwmonroe: I'd very much like to spend some time trying to fix @when_file_changed because it's a great decorator.  But I have to EOD soon22:10
fritchieis there a way to view the porogress when importing boot images to a new MAAS install - seems to be taking longer than I would imagine22:30
rick_h__fritchie: on the images page in the webui?22:31
rick_h__fritchie: I know they were working on a new page there, not sure if progress is on the new one vs the one you're using22:32
fritchiesorry rick, message was meant for maas channel, the wheel is just spinning22:32
rick_h__fritchie: understand, we try to help here too :)22:32
cos1Hey guys. Hi @arosales23:50
fritchiehas anyone seen this error? DEBUG juju.provider.common bootstrap.go:259 connection attempt for 172.16.100.101 failed: /var/lib/juju/nonce.txt does not exist23:50
fritchiejuju.network address.go:504 removing unresolvable address "dnjostack01.maas": lookup dnjostack01.maas: no such host23:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!