=== zenlot_away is now known as zenlot === natefinch-voting is now known as natefinch === bruno is now known as Guest56910 === scuttlemonkey is now known as scuttle|afk [06:17] Is there a way to get juju to create containers directly on openstack compute nodes rather than creating nova instances on top? [06:19] metsuke: you can either deploy directly to MAAS-deployed nodes, or into LXC containers on those nodes [06:23] blahdeblah: the lxc method is for evaluation though so it is not recommended? We are trying to cut out the additional layer that Nova creates. [06:24] metsuke: do you mean using lxc instead of kvm for nova instances? [06:25] I'm not sure whether the LXC method is officially supported, but it definitely works, and there is an LXD version coming in 16.04. [06:25] * blahdeblah defers to bradm on this :-) [06:25] bradm: It's more like not using nova instances at all [06:25] maybe this isn't really a problem [06:26] metsuke: there's a nova-compute-lxd coming [06:26] but it just seemed overbearing for juju to create 50 separate vms for separate containers [06:26] change OpenStack to use the LXC driver (nova.virt.lxc.LXCDriver)? I haven't tried it myself, but https://wiki.ubuntu.com/OpenStack/LXC might help [06:27] metsuke: Why do you want to use openstack compute nodes without nova? The point of nova is to make it easy to create your compute instances, whether they're containers or VMs. [06:27] blahdeblah: well, we wanted everything from Openstack except Nova, but it is installed by fuel and juju leverages it automatically [06:28] I think you will find the upcoming LXD version of nova that bradm mentioned pretty good. [06:29] ok. Upcoming like mitaka? =) [06:41] in terms of scaling charms, my company has always used haproxy to scale horizontally for web apps. However, just looking at the Wordpress charm, that methodology is very different now. Should all new, non-inherently scalable, http charms use the same methodology as Wordprerss (apache load balancer?) or is there a Good way to use haproxy? [06:42] metsuke: upcoming in xenial (16.04) [06:42] metsuke: If we're talking about the old public Wordpress charm, it's not a great example. [06:43] The haproxy charm has relations that you can hook up to anything supporting the http interface. [06:44] blahdeblah: would you recommend that for http scaling as opposed to doing it in-charm? [06:44] That's how we usually do it [06:45] cool, it would definitely be easier [06:45] It may work well for you that way, or it may be better to do it in-charm, depending on your application. [06:45] But the general idea is that charms are composable pieces that can be hooked together into application suites [07:19] Can ironic be in place of MAAS for cutting nova vm's out of the equation? === Guest56910 is now known as BrunoR [10:34] gnuoy, if you are around - https://code.launchpad.net/~james-page/charm-helpers/fix-ssl-certs/+merge/287639 could do with a review [10:35] jamespage, +1 [10:36] gnuoy, thankyou [10:36] np [11:12] this looks rubbish, but is actually pretty cool: http://ibin.co/2Yr5fKlDWBeD the first Juju controlled PDI ETL cluster [11:15] gnuoy, wanna do a +2 and landing? https://review.openstack.org/#/c/287087/ [11:15] ready to go imho [11:17] jamespage, done [11:25] gnuoy, you have to hit the "workflow +1 as well" [11:25] to move things along... [11:26] What am I =1'ing when I do that> [11:26] ? [11:27] gnuoy, http://docs.openstack.org/infra/manual/developers.html#project-gating [11:27] gnuoy, the +2 is a review; the +1 is actually 'approve' [11:27] workflow +1 that is [11:40] gnuoy, and job done.. [11:40] thanks! [11:46] dosaboy, https://review.openstack.org/#/q/project:%22%255Eopenstack/charm.*%22+status:open is a useful view btw [11:46] yep i got that thanks [12:06] gnuoy, beisner: pushing up a charmhelpers resync for review/test [12:07] https://review.openstack.org/#/q/status:open+topic:charmhelpers-resync [12:11] magicaltrout: hey! ...i still havent thought of a comeback. [12:12] lazyPower: some of the times the leadership broke, a force destroy of a machine was involved, other times a service destroy / resolved and no force [12:14] hehe [12:16] magicaltrout: i was introduced to 2 expats here as 'british but doesnt want to be british'. they were not impressed. [12:17] are they the expats I see on facebook who don't want refugees coming into the UK whilst they live on the costa del sol? ;) [12:18] magicaltrout: no.. one was this english artist / yoga teacher who told one of our spanish friends that 'english people are much more interesting' though.. so less beer-drinking-lobster tan but similar amount of strange++ [12:19] ah yes [12:19] those interesting english-folk [12:19] of course [12:19] magicaltrout: i met another english girl here who told me her parents had a place somewhere in the south of mallorca. i asked her: "are there many foreigners there?" and she replied "no, its mostly english" [12:19] oooh [12:19] thats bad [12:20] did she looks that stupid or just act it? [12:20] ...yes :} === admcleod1 is now known as admcleod [12:23] magicaltrout: nice blog post btw [12:24] random ramblings on a monday afternoon [12:25] for the people I work with in the "real world" I'm hopefully doing a PDI ETL cluster demo this afternoon if Amazon speeds the f**k up [12:25] hah [12:25] now my charm has leader election, config detecion stuff in, it should be ready for people to test. I'll get it into the listings and worry about unit tests later ;) [12:27] magicaltrout: what ver juju are you using? [12:27] once juju<->lxd stops messing up my ip addressing, I reckon most of my development workload will switch to some form of charmed up development process [12:28] Trunk! :) [12:28] beisner, getting alot of "ImportError: No module named pika" [12:28] for amulet test executions.... [12:37] magicaltrout: Having had to do Pentaho ETL stuff many years ago, I'm curious what you've whipped up [12:37] having never used PDI clustering before.... so am i [12:38] as a point of reference, the project I was working on basically piloted pentaho, but ended up making us write our own ETL tool [12:39] well my background for the last decade has been mostly Open Source BI around Pentaho and stuff [12:39] I've done some Talend projects, but I absolutely hate the platform [12:39] so we mostly end up using PDI [12:42] anyway so my plan is thus..... get this deployed which will allow users to either, run upload jobs & transformations and run them via actions or cron tab them for scheduled execution or use PDI Carte as a webservice so people can create stuff in Spoon and either run it as a slave server or, if they want to scale up juju add-unit pdi and run as a PDI cluster [12:42] thats phase 1 [12:42] and will give people scale out capabilities and remote execution capabilities with little effort on my/our part [12:43] this pretty much works, i'm just putting some finishing touches to it, like informing the user of the leaders public ip etc [12:44] phase 2 will work as a subordinate to the hadoop and yarn charms, because PDI these days has Big Data scaleout stuff that the Hadoop folk use, I've never touched it myself but now I have an excuse to [12:44] and you can write MapR transformations within PDI and run them in a Hadoop cluster [12:45] so my plan is to create something that allows you to hook it up to Hadoop, at which point it will embed itself like their docs explain, and then allow users to run PDI jobs in the Hadoop/Yarn environment [12:49] http://ibin.co/2Yr5fKlDWBeD as you'll sorta see here marcoceppi on the left, pdi doing some stuff on the right, carte these days doesn't suck too much and you get some basic webservices with a picture of the transformation you select, the run log, etc [12:49] so there might be some scope to write a nice carte UI as well to wrap it all up, but thats somewhere down the road [12:50] sounds awesome [12:50] marcoceppi, can you take a peek at https://github.com/marcoceppi/leankit.hostmar.co/pull/3 ? [12:51] well if no one else uses it I certainly will. But in reality it should fit in quite well with the stuff kwmonroe and cory_fu do, so I'm sure once the hadoop stuff is up and running there will be some fun stuff to demo around Hadoop ETL work [12:51] jamespage: i just opened it up, looking now! [12:51] magicaltrout: It's a great solution space. Lots of users and little operational knowledge. So this fits well with the write once use many idea of Juju [12:51] yup [12:53] jamespage: deployed, cheers! [12:55] aww marcoceppi [12:55] get amazon to up your quote allowance :P [12:56] -e +a [12:56] marcoceppi, working nicely - thanks! [12:56] magicaltrout: eu-west-1 is full of a lot of other people [12:57] magicaltrout: you might want to try eu-central-1, no one is in it atm. We may need to spin up another AWS account to support all the CDP members [12:57] k [12:57] magicaltrout: actually, I'm the problem in eu-west-1 [12:57] magicaltrout: let me tear down an old demo [12:58] hehe, get back the other side of the pond! [12:58] magicaltrout: when at MWC, it was much more convient ;) [12:58] magicaltrout: + kostas + I ;} [12:59] show off [12:59] magicaltrout: I just cleared out 6 instances [13:00] will work with amazon to get better resources [13:00] magicaltrout: even chocolate blue cheese icecream is all about the showmanship [13:01] don't you worry marcoceppi once LXD stuff is done, I'm all over LXD based development :P [13:01] admcleod: that I can understand [13:08] magicaltrout: well you're not the first to hit limits, I've started a dialog with aws [13:11] jamespage, yep that's the amulet smoke not doing the 00-setup bit. fixed and will recheck those. [13:12] jamespage, ps. the amulet smoke is live! ;-) [13:14] jamespage, rechecking just this one to confirm, then will rerun the others https://review.openstack.org/#/c/286451/2 [13:18] ..chocolate..bluecheese...icecream? [13:18] but...why [13:18] yeah [13:18] weirdly, everyone else on the table also decided to try it [13:18] i was wise [13:18] and refused :P [13:19] beisner, i saw and did some low risk landings on that basis [13:21] actually.. i had some 'white chocolate blue cheese icecream' again in valencia and it was quite nice... [13:21] you disgust me [13:21] thats why im here [13:21] that said [13:21] admcleod, hmmm i'll have to take your word on that [13:21] it would certainly be an improvement on white chocolate and american cheese.... [13:22] i dont know where you're getting this crazy amount of chocolate and cheese, but they really aren't complimentary flavors in my mind [13:23] correct [13:23] tell that to philadelphia [13:23] or like, cheese cakes [13:25] thats not a winning argument [13:25] for starters they aren't blue cheese cakes [13:26] thats not to say you can't get such a thing, i'm sure you can [13:26] doesn't make it right though === Guest84461 is now known as CyberJacob [13:26] beisner, guess we can turn off the +1 code review from uosci now right? [13:27] * beisner looks [13:27] oh sweet! yep that change landed. [13:27] beisner, it did - I asked this morning and got perms on the charms-ci group and twiddled things around [13:27] verification is working fine for uosci [13:28] ok cool i'll make it so [13:28] magicaltrout: well.. the second time was good. [13:29] jamespage, fyi, anything that's currenty running will still crvw vote, but new jobs won't [13:34] beisner, ok [13:34] beisner, I also have a juju-deployer branch that deals with using anything other than the master branch with git repo's [13:34] jamespage, ah nice. -b ftw? [13:35] beisner, yah [13:35] beisner, https://github.com/openstack/charm-percona-cluster;stable format [13:37] beisner, also noticed that recheck-charm also gets picked up by the standard check processes as well [13:38] jamespage, yeah it's all regex based. so, they must be ^recheck.* [13:39] jamespage, i noticed that too in the sandbox. but not everyone retriggered on recheck-charm. i'm going to add charm-recheck and see if that limits the scope. [13:45] jamespage, ok, charm-recheck is hot, and i just did that on: https://review.openstack.org/#/c/286669/1 [13:46] if that confirms a-ok, i'll update the comment template. but recheck-charm will continue to work as well. [13:52] beisner, I guess that we don't have vast capacity for concurrency atm right? [13:52] check is taking >1.5 hrs atm [13:54] beisner, good - I think not consuming vast amount of openstack resources when we don't need to is optimal... [13:56] jamespage, each check is about 45 min. i just bumped the concurrency up from 4 to 6. [13:58] jamespage, depending on which charm some are as low as 30 min for lint, unit, charm-single, and amulet-smoke. that's from the moment the start running of course. [14:10] beisner, hmm - test_charm_single: FAILURE [14:11] jamespage, 00:06:10.118 W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/universe/i18n/Translation-en Hash Sum mismatch [14:16] jamespage, looks like a launchpad ppa blip got a handful of those jobs at about the same time. [14:42] okay leadership reactive knowitalls [14:42] beisner, \o/ [14:42] i'm clearly not doing something write [14:42] oh crappers [14:43] marcoceppi: I want to set a bunch of variables when the leader is elected and also reset those variables if a new leader is elected [14:43] but [14:43] I don't want to set those variables if the leader isn't changed [14:44] https://gist.github.com/buggtb/328f36919bd637811a61 that was my latest attempt [14:44] but it seems leadership.changed is only called when you update one of the variables [14:45] magicaltrout leader-elected [14:46] and all followers should just consume the data via leader-get when leader-settings-changed [14:46] leader-elected will be run on *any* leader, the first cycle that they get elected. so control clsuter state there. I'm doing something very similar in layer-etcd [14:46] hmm [14:47] exchange data over peer-relation-joined on first run, then all subsequent cluster status is formed based on data being received from leader-get, as registration is 2 step w/ a http post (Self registration) and then reading cluster data broadcast from the leader. [14:47] according to the leadership layer it means I don't have to write leader-elected hooks :P [14:47] @when('leader.elected') i guess? i'm not sure, i haven't used stubs leadership layer yet [14:47] magicaltrout: right leadership.changed is for the settings, not the leader itself [14:48] magicaltrout lazyPower there is no leader.elected https://git.launchpad.net/layer-leadership/tree/README.md [14:48] stub: ^^ opinions? [14:49] nope [14:49] magicaltrout: actually [14:49] magicaltrout: wouldn't this just work? https://gist.github.com/marcoceppi/d91d6b2cc5072f8204d2 [14:50] marcoceppi - seems like an oversight, the leader being elected is totally an event we care about [14:50] magicaltrout: or do you only want to have the settings sent once? [14:50] lazyPower: it's not, you care about the state [14:50] schenanigans [14:50] either you are the leader or you're not [14:50] what if hte leader changed, and i have stale cluster data? [14:50] that leader-elected state gives me an opportunity to cleanup and reconcile before i declare the current cluster state again, from my leader perspective [14:51] lazyPower magicaltrout how aobut this? https://gist.github.com/marcoceppi/d91d6b2cc5072f8204d2 [14:51] marcoceppi: thats sort of what I had before [14:51] magicaltrout: right, so I added one more state [14:51] but i seem to get dumped into an endless restart cycle because the leader_set appears to trigger a change even it it remains the same [14:51] if the leader changes, that unit becomes the leader and sees it hasn't been configured yet for leadership [14:52] err [14:52] crap, I rushed that [14:52] mmhmm [14:52] i was playing around with something along your lines marcoceppi with my init=True stuff [14:52] magicaltrout: https://gist.github.com/marcoceppi/d91d6b2cc5072f8204d2 [14:52] seems to me it would be good to have a fire and forget call that runs on leader elected [14:52] maybe I'm just lazy ;) [14:53] magicaltrout: just set and manage the state instead [14:53] that way it'll only be run once if you're the leader and you haven't run through that method yet [14:53] hmm didn't thinkg about that [14:53] still need to use states better [14:53] thanks marcoceppi I'll give it a go [14:53] magicaltrout - or, do the dreaded antipattern of using @hook('leader-settings-changed') and defend the users right to choice :P [14:53] magicaltrout: replace "self" with the layer name and you're on your way [14:53] rather @hook('leader-elected') [14:53] lazyPower: no! hooks are for fools [14:54] lol [14:54] lazyPower: and you can't combine with states [14:54] only if you care about stacked decorators [14:54] if i have a single method, decorated by @hook('leader-elected') that runs everytime a leader is elected, i've solved this with a one liner [14:54] * marcoceppi beats lazyPower with a pillow full of quarters for using @hook [14:54] * lazyPower points at the field where his figs are grown [14:54] i heard if I mix hooks and states cory_fu will force feed me admcleod's ice cream [14:55] behold my field of figs, notice they are barren [14:55] lazyPower: however, if you want to update the leadership settings, you can just remove the state [14:55] lazyPower: don't have to wait for a hook now === scuttle|afk is now known as scuttlemonkey [15:02] jamespage, will be retriggering pxc for amulet smoke after resolving an env var that the test expects: Please set the vip in local.yaml or env var AMULET_OS_VIP to run this test suite [15:04] * magicaltrout wonders if he can get around lxd deploying to localhost by blocking up localhost.... [15:04] booo [15:04] bloody thing [15:04] Hey, sorry I'm late to the leadership party. Don't use @hook [15:05] told you.... [15:05] magicaltrout: I think you're over thinking it. You don't need to care specifically about when leadership changes, you just need to react to @when('leadership.is_leader') and @when_not('leadership.is_leader') [15:05] hmm [15:05] well i need the leader to broadcast new variables and I need the slaves to pick them up [15:06] I also need to trigger a carte restart [15:06] In the @when('leadership.is_leader') handler, write the leadership settings. If they're different, all the peers will get notified that they changed [15:06] And they can then react to leadership.changed [15:06] (all the peers, including the leader) [15:07] okay i'll just put something together and you can tell me if you think it works [15:07] then we'll have a bet :) [15:09] https://github.com/OSBI/layer-pdi/blob/master/reactive/pdi.py#L113 bit of that cory_fu ? [15:11] magicaltrout: I was thinking like this: https://gist.github.com/johnsca/8cf0f25cce06c13bdecb [15:11] Also, no need to leader_set something that's already in config [15:12] good point [15:12] beisner, ack [15:13] magicaltrout: Note the first line. It's important to use that version of leader_set to ensure the leader gets notified of the settings changes internally [15:13] (It might get notified by another hook call, but I'm not certain, and it would take quite a bit longer even if it works) [15:13] yeah i'm using that one [15:14] jamespage, looks like charm-recheck is the ticket. [15:15] beisner, awesome [15:18] Hi everyone, what is your setup to deploy charms in xenial? Do you use the local provider while in trusty? [15:19] marcoceppi, magicaltrout: @when('leadership.is_leader') ? [15:19] stub: yeah, we moved on a bit from that [15:21] cory_fu: I was tempted to monkeypatch charmhelpers.core.hookenv, but thankfully thought better of that. [15:21] I am also interested in kjackal's question about deploying xenial units using local provider on trusty [15:21] stub: :) [15:29] right then [15:30] cory_fu: this is why i asked the question in the first place [15:30] https://github.com/OSBI/layer-pdi/blob/master/reactive/pdi.py#L120 [15:30] post bootstrap it all sorted itself out [15:30] but then update_master_config is run [15:30] which triggers a restart [15:31] https://gist.github.com/buggtb/1cab57c0f1d1d4a7fa99 [15:31] magicaltrout: It should only trigger that if the leadership settings had changed [15:31] well i only have 1 node [15:31] Which would imply that it needed to restart [15:32] leader-settings-changed seems tor un anytime you leader-set, it doesn't retain the same behavior as relation-set [15:32] unless i'm completely mistaken [15:32] but thats what i've seen the last week or so in 2.x land [15:32] yeah that was my thinking [15:32] its not like the other properties [15:32] so i'm 98% certain thats teh case [15:32] this stuff is rexecuted verbatim [15:32] and this entire conversation about not caring when leader changes is fud [15:32] well not fud [15:32] but not right [15:33] magicaltrout: In a meeting now [15:33] oh any excuse when you don't know the answer :P [15:33] :) [15:33] I haven't tested it, but what you just said doesn't sound right at all, per my understanding. Maybe stub could help [15:33] sure. But I'm siding with lazyPower, leader_set seems to force leadership.changed to trigger [15:33] which is why it sucks a bit :) [15:33] yep [15:33] doesn't matter if the data changed or not [15:33] it has different behavior characteristics [15:33] sooooo hello stub [15:34] do you have an opinion? :) [15:34] magicaltrout what you could do.. [15:34] there's a @leader.setting_changed context, you can stuff the data into a cache, and do something like the data_changed bits that cory exposed [15:35] so it only does a restart if the leader-data differed from the last hearbeat it got from leader-set [15:35] s/hearbeat/heartbeat-update-thing-whatever-we-call-this [15:36] charms.leadership.leader_set should set leadership.changed, and that state will remain set for the remainder of the hook [15:36] @when('leadership.changed.admin_password') [15:36] jamespage, so are you thinking we could just serialize the next-sync with the existing gh2lp sync job? [15:36] magicaltrout ^ is what i was looking for [15:37] or does that trigger regardless of the actual value changing? [15:37] yeah stub so if I wanted to set some variables on leader election but not reset them later how do you go about catching it? [15:38] lazyPower: dunno, i was trying to avoid just annotating all the config stuff [15:38] give it a whirl though i guess [15:39] oh that way i need a method per config as well I think [15:39] which is annoying [15:40] magicaltrout: http://pastebin.ubuntu.com/15267478/ ? [15:41] ah right you do a state set as well [15:41] okay stub thanks [15:41] Or just use @hook('leader-elected') :) [15:42] lol [15:42] * magicaltrout ducks the projectiles coming from cory_fu [15:43] magicaltrout, stub: I really think that thinking about it in terms of "I need to do something when leadership has changed" is the wrong way to think about it [15:43] 1 min, I'll explian more [15:43] well, I can't ignore a leadership change event :P [15:43] magicaltrout: Mixing leadership.is_leader and leadership.changed could be dangerous, as you can't tell if the leadership settings where changed in the current hook by the current leader, or by the previous leader that has been deposed. [15:44] cory_fu: Normally, yeah. But if you want to ensure the credentials are cycled every time the leadership has changed, you want to do something when leadership has changed. [15:44] I just set the credentials once and leave them no matter who the leader is [15:45] But I guess if you were setting a public key, and the private key never left the leader, there might be some sense in regenerating the creds rather than unnecessarily share the secret. [15:45] A fresh install of juju on windows 7 gives "ERROR there was an issue examining the environment: dial tcp 127.0.0.1:37017: ConnectEx tcp: No connection could be made because the target machine actively refused it." when running bootstrap. Any hints? [15:46] (although my example is also simple without using @hook either) [15:46] stub: so if running leadership.changed and leadership.is_leader is dangerous, how do you know if your running on the leader or slave? [15:47] magicaltrout: leadership.is_leader is only ever set on the leader. leadership.changed is set at the start of a hook if the leadership settings are different to the last hook. [15:48] So if a leader did leader_set, then died, a new leader will get its leader-elected hook run but find leadership.changed already set. [15:48] stub: My point is that if you just set the leader settings whenever you are leader, then they will naturally update when it changes [15:49] cory_fu: Yup. [15:49] And if you also gate your restart on leader settings changed, then, even if you are the only unit, you will still be elected leader and the config write and restart will happen at the right place [15:49] this is turning into a much larger exercise than it should be. How had can it be for the leader to propogate a few variables, and then the leader set 1 config, the slaves set another config and they all restart, but only when a leader changes or a config variable is *actually* updated? :P === nagyz_ is now known as nagyz [15:50] magicaltrout: That means, don't do a separate config write + (re)start other than the leadership.changed; that can be your main config write + (re)start handler [15:50] cory_fu: Where was your example? [15:51] magicaltrout: My point is that it's easier than you're making it out to be. If you just work under the assumption of leadership and don't worry about specifically reacting to changes in leadership status (only to changes in leadership values) then it becomes much simpler [15:51] stub: https://gist.github.com/johnsca/8cf0f25cce06c13bdecb [15:52] Yeah, ^ [15:52] With that, if you don't have any other calls to render_*_config and restart(), then you will only ever get restarted when it [15:52] how can i work under the assumption of leadership when I have a separate master and slave template to fill? [15:52] *it's necessary [15:53] magicaltrout: I mean, under the assumption that you will always either be leader or not, like in my example [15:53] i.e., don't have a separate set of handlers for "no leadership" or "single unit" case [15:54] So the crazy edge case that would be next to impossible to engineer is update_master_config being called before change_leader [15:54] That's just naturally handled because Juju will always pick a leader, even for a single unit [15:54] stub: How could that happen if change_leader is what updates the leader settings? [15:54] I don't assume there will be no leadership. Do i? [15:54] beisner, that might work ok [15:55] cory_fu: Another unit is leader and changes settings, and loses the leadership lease. This unit is elected leader, and runs leader-elected. The leadership settings have changed, so that state is true when the hook starts. [15:56] cory_fu: So both handlers are valid, and it is undefined which is called first. [15:56] Hrm [15:56] but pretty much impossible due to the 30s lease period on leadership. It really means I've thought about this too much :) [15:56] ^__^ [15:57] LET ME SPECIFY PRIORITY OF MY HANDLERS DAMMIT [15:57] lol [15:58] i'm still lost [15:58] how on earth do I set the config without it restarting? :P [15:59] magicaltrout: If you set the config and it's different, that implies that you *need* to restart. [15:59] magicaltrout: What is the actual problem you are trying to solve btw? [15:59] magicaltrout: The coordinator layer might be a better fit. [15:59] cory_fu: I set the config because is_leader is called [16:00] nothing in that configuration actually changes [16:00] but leader_set is called so leadership.changed is fired [16:00] * magicaltrout feels like we've been here before.... [16:01] magicaltrout: If nothing in the settings changes, then it shouldn't trigger that changed state. [16:01] lazyPower: can you have a word with cory_fu please :P [16:01] magicaltrout: I could see it triggering on the first run, since the leader settings aren't set before [16:02] Yeah, just checked the code. If it sets leadership.changed even if its a noop, then its a bug. [16:02] stub: Actually, is it the case that on the first run, leadership.changed will always be set? [16:02] Yes [16:02] Well, that means your "nearly impossible" edge case is guaranteed to happen on the first run. :( And that explains magicaltrout's gist [16:03] https://gist.github.com/buggtb/e6faa5b897bcf7d5d282 [16:03] thats happened whilst we've been mulling this over [16:03] (because in Juju, deleting a key is just setting its value to None) [16:04] Well, there's your problem. Your charm is full of Java. [16:04] lol [16:04] well that I have no control over, but at least I know how Java works :P [16:04] why so much Java hate? [16:05] It is *just* a language people! [16:05] the java appeared because after a bunch of restarts that failed its given up and run out of memory :) [16:05] yeah i got called out on an ASF mailing list last week for mocking PHP, I'm keeping quiet now ;) [16:06] mbruzek: For me, because of the damn click through license and the effort involved in working around it :-P [16:06] magicaltrout: Hrm. That is a problem. I really don't understand why update_master_config would be running during update_status [16:06] It really shouldn't be [16:06] magicaltrout: Can you point me to the code that that is running right now [16:06] ? [16:07] s/right now/currently/ [16:08] er http://paste.ubuntu.com/15267724/ [16:08] I think its that [16:08] but we've been talking and I've been messing around with ideas [16:08] cory_fu: leadership.changed will always be set the first time leader_set is called, not always set the first run at the start. === psivaa_ is now known as psivaa === rockstar_ is now known as rockstar [16:16] stub: Sure, but in that case it's guaranteed that you'll end up with both leadership.changed and leadership.is_leader at the start of the hook at the same time [16:16] So at least once, it could potentially run in the wrong order === FourDollars_ is now known as FourDollars [16:17] And since changing the values would then not update leadership.changed (since it would already be set), the @when('leadership.changed') handler would not run again after the leader settings were updated [16:18] cory_fu: I don't follow. The first handler runs, guarded by @when('leadership.is_leader'). It sets stuff, turning on leadership.changed. Then the other hook runs. [16:19] stub: Oh, I misunderstood [16:20] okay so can we try and agree on what everyone thinks will work [16:20] then we can test it in reality [16:20] https://gist.github.com/buggtb/a96f3ea9d1044760b642#file-gistfile1-txt-L111 [16:20] if I'm following, leader_set should run [16:20] then on the leader I should get leadership.changed and it update and restart? [16:21] stub: However, I think what I was saying was still true, because for the very first hook run, https://git.launchpad.net/layer-leadership/tree/reactive/leadership.py#n41 is going to return an empty dict [16:22] magicaltrout: Yes. I'm concerned that for the very first hook run, you could have leadership.changed set from the start of the hook, which could cause the order of change_leader and update_master_config to be undetermined [16:22] okay i'm gonna refresh and see how knackered it is [16:22] It would be correct for the following hook runs, but that first run seems like it will hit the edge case [16:23] cory_fu: Right, but there are no keys in an empty dict so we have nothing to iterate over and the flag remains unset [16:23] (previous is an empty dict, current is an empty dict) [16:24] stub: Oh yeah! Great [16:25] Ok, so I'm back to having no idea why update_master_config is running before change_leader in update_status for magicaltrout [16:26] well i'll run this clean one with code I know what it looks like and we can argue about it some more [16:28] beisner, https://review.openstack.org/#/q/status:open+topic:charmhelpers-resync status atm [16:28] I submitted a few rechecks... [16:28] jamespage, ok cool. the queue is pretty clear atm. [16:35] hi! I've started to use LXD. I would want to know whether Juju is integrated or is going to be integrated with LXD? [16:35] LXD!!!! woop [16:38] HollyRain: from an unofficial POV, 2.0 will include LXD support [16:38] magicaltrout, how to install that beta? [16:39] you need to wait a few days or get Xenial installed and compile Juju lxd-container-type branch [16:42] stub: Did you see https://github.com/juju-solutions/charms.reactive/pull/56 [16:50] cory_fu: yes. might simplify some things here. [16:51] Are java subordinates rather than java layers the future ? [16:52]