[02:32] <blahdeblah> Hi. Anyone know of a good example of combining multiple charms.reactive states? It's driving me a bit mental at the moment.
[02:32] <blahdeblah> I've got these reactive handlers: https://pastebin.canonical.com/156991/ both executing in the same hook invocation. o.O
[02:32] <blahdeblah> even if I remove the @when_all part on the 2nd method, it still executes
[02:37] <blahdeblah> Or even a way to debug what reactive's doing when I call main, so I can work it out?
[02:42] <rick_h_> blahdeblah: sorry, the reactive experts are cory_fu and marcoceppi and bcsaller who aren't around atm.
[02:42] <rick_h_> blahdeblah: the big data charms are the latest biggest reactive things to try to peek at, those and the docker/swarm observable bundles
[02:42] <rick_h_> as far as ones to look at
[02:43] <rick_h_> blahdeblah: if those don't help I'd shoot off a layers email to the list as there's a growing community of folks that know this stuff pretty well there
[02:43] <rick_h_> and I can make sure to poke you a reply from the experts
[02:43] <blahdeblah> rick_h_: Yeah - wasn't expecting many of those guys to be around. :-)
[02:43] <rick_h_> blahdeblah: heh, just covering my "hmm, sorry I don't know" :P
[02:43] <blahdeblah> Is there a separate list for charms, or do you mean just the main juju users list?
[02:44] <rick_h_> blahdeblah: the main juju@ one
[02:44] <blahdeblah> rick_h_: Thanks - much appreciated; I'll check out the charms you mentioned.
[02:44] <blahdeblah> (and do a bit more debugging to see if I can work out what's going on)
[02:45] <veebers> Is the juju user features complete or WIP? The web docs mention the command 'user add' which doesn't exist, the help for the command 'add-user' mentions the command 'switch-user' which also doesn't exist. Anyone have pointers?
[02:45] <rick_h_> veebers: it's in 2.0
[02:45] <veebers> rick_h_: I'm running 2.0 from source
[02:45] <rick_h_> veebers: you can add-user, send a register command to another user, etc
[02:46] <rick_h_> veebers: I've run through it a couple of times
[02:46] <rick_h_> user add I think was the pre 2.0 one
[02:46] <rick_h_> veebers: and I think switch user was replaced with logout/login (to do a switch)
[02:46] <veebers> rick_h_: ah aye, sorry wasn't very clear,  I can add user and reg. But no such command 'switch-user'
[02:46] <veebers> ah ok
[02:46] <veebers> the help strings for the command seem out of date then
[02:47] <rick_h_> veebers: right, I think in testing that we decided to replace that with just logout/in. Docs still need updating there.
[02:47] <veebers> (in multiple places).
[02:47] <rick_h_> veebers: rgr
[02:47] <veebers> rick_h_: Should I file a bug somewhere/
[02:47] <rick_h_> veebers: sure, https://bugs.launchpad.net/juju-core
[02:48] <veebers> rick_h_: sweet, will file that now
[02:48] <rick_h_> veebers: <3
[02:48] <rick_h_> and thanks for trying it out
[02:49] <veebers> rick_h_: heh, I'm writing tests as I'm on the jujuqa team ;-)
[02:50] <rick_h_> veebers: still ty
[02:50] <veebers> nw
[02:50] <rick_h_> veebers: and welcome, we've not had a chance to meet up yet
[02:50] <veebers> rick_h_: Cheers, no not yet. Looking forward to it
[02:54] <veebers> rick_h_: rats, how do I log back into the systems 'admin' user? (i.e. the user I used by default when I wasn't messing with user stuff)
[03:00] <lazyPower> blahdeblah if you're still around i can lend a hand
[03:00] <blahdeblah> \o lazyPower - I sure am
[03:01] <blahdeblah> I was just about to have lunch, but now that you're here... ;-)
[03:01] <lazyPower> o/ - so, i see some new decorators here that i was unaware of
[03:01] <lazyPower> @When_all an @when_not_all -- those are wholly new to me. @when_all seems like a direct clone of @when - as its goign to fail if any of the conditions are not true
[03:01] <lazyPower> and @when_any  is a if any of these are true, do your thangggg
[03:01] <blahdeblah> I've been going by the doc at https://pythonhosted.org/charms.reactive/charms.reactive.decorators.html
[03:02] <blahdeblah> that is pretty much my understanding of it
[03:02] <blahdeblah> when is apparently just an alias to when_all
[03:02] <blahdeblah> ditto for when_not -> when_none
[03:02] <lazyPower> yep
[03:02] <lazyPower> looks to be the case. #TIL
[03:03] <blahdeblah> So I think there's actually a bug in whatever provides config.set.VAR
[03:03] <lazyPower> Thats possible
[03:03] <lazyPower> I know we've had some issues with the @when_file_changed decorator in the past
[03:03] <blahdeblah> Because if I dump the corresponding hookenv config variables in the 2nd handler (which shouldn't execute), they are definitely set.
[03:03] <veebers> rick_h_: ah I think I got it, I just had to change to a controller that 'I owned' i.e. not one created with a different juju user
[03:06] <veebers> ok I take it back, I'm not 100% how that works. I was able to switch controllers which automatically logged me in as admin? At any rate, when I tried to login as new user again it gave me a message about setting a passwd
[03:06] <lazyPower> blahdeblah - i know that i've used the config.changed state bits which are provided by layer-basic... its entirely possible there's a bug lingering around in some of that
[03:07] <blahdeblah> I might have a bit of a dig into layer-basic and see what I can find.
[03:07] <lazyPower> https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/basic.py#L126
[03:07] <lazyPower> that should help make it easy, there's the init / changed methods handling those states
[03:11] <blahdeblah> Looks pretty simple, TBH
[03:14] <lazyPower> blahdeblah - if your layer is public i'd be happy to build it and give it a go at debugging the behavior
[03:16] <blahdeblah> lazyPower: It will be public once I make it do something. :-)
[03:17] <blahdeblah> But maybe I'll just have no shame and put it out there and ping you with the location
[03:17] <blahdeblah> I'm pretty sure my peer relation hook could use some work as well - it seems to execute 20-30 times before stabilising.
[03:24] <lazyPower> blahdeblah - i had that issue before i started gating on the data being available. This is why in the ~containers charms you'll see a lot of use of .connected and .available states (connected is as it sounds, available only gets set when we have all the actionable data)  - without seeing the code, i'm assuming that is the root cause.
[03:25] <lazyPower> but i dont want to hold you up. I'll be around ~ another hour and a half if you want to run and grab lunch. I'll be around to riff when you get back
[03:25]  * lazyPower is catching up on Sunday Night TV before the spoiler tweets land
[03:57] <blahdeblah> lazyPower: thanks - will let you know how I go
[04:12] <blahdeblah> lazyPower: So here's what I did after your last comment: https://pastebin.canonical.com/156993/ ; then I changed the other methods to gate on dynect.config-available, and it all worked as expected.
[04:13] <blahdeblah> Personally, I think that's still a bug in config.set.* handling, since those states (AFAICT) are supposed to work for exactly this purpose.  But at least I've unblocked that path.
[04:15] <ejat> rick_h_: juju mlist or askubuntu ?
[04:25] <veebers> Surely if I add a user and grant them 'read' they should be able to execute 'status' on the controller? (i.e. they can deploy a charm, I want to be able to monitor it's status)
[04:40] <ejat> rick_h_: bugs no 1584582
[04:41] <ejat> https://bugs.launchpad.net/charms/+source/rabbitmq-server/+bug/1584582
[04:41] <mup> Bug #1584582: ERROR juju.worker.uniter.operation runhook.go:107 hook "config-changed" failed (dns resolver) <rabbitmq-server (Juju Charms Collection):New> <https://launchpad.net/bugs/1584582>
[08:53] <jamespage> morning all
[08:53] <jamespage> happy monday :-)
[09:04] <Rajith> Hi while using juju set command getting error unknown option
[09:07] <Rajith> this is happening while deploying service
[09:23] <jamespage> gnuoy, https://review.openstack.org/#/c/319779/
[09:23] <jamespage> can you take a peek? working through Juju 2.0 related bugs this morning - bdx ^^ that should fixup your dvr issue - charm store accessible version in the bug report
[10:01] <jamespage> gnuoy, two more for you:
[10:01] <jamespage> https://review.openstack.org/#/q/topic:bug/1572575
[10:01] <mup> Bug #1572575: Charm looks for JUJU_ENV_UUID but that does not exist in juju 2 models <bug-squad> <canonical-bootstack> <juju-2.0-api> <landscape-client-charm:New> <landscape-client (Juju Charms Collection):New> <swift-proxy (Juju Charms Collection):In Progress by james-page> <swift-storage (Juju
[10:01] <mup> Charms Collection):In Progress by james-page> <https://launchpad.net/bugs/1572575>
[10:27] <gnuoy> jamespage, tinwood if you get a chance can you take a look at https://github.com/openstack-charmers/charm-layer-openstack/pull/4 . It adds ha support to the Openstack layer. I think the method for passing kwargs to the config adapter within OpenStackRelationAdapters  and the implicit adding of the cluster adapter are the more controversial bits.
[10:33] <tinwood> gnuoy, we're slightly pulling in opposite directions here.  I've pulled the code OUT of charm-layer-openstack into a charms_openstack module to make layered openstack charms easier to test.  Thus, all the layer has is the templates and a reference to charms_openstack in the wheelhouse.txt -- thus, I'll need to merge this code back into that at the appropriate time?
[10:35] <tinwood> gnuoy, it's currently sitting at https://github.com/ajkavanagh/charm.openstack (but we'll hopefully (if agreed on approach) pull it into an openstack-charmers/charms-openstack git repo.
[10:40] <gnuoy> tinwood, I don't think we're pulling in different directions. I think it will be straightforward to apply my changes to the module rather than the layer. I just did it againt the layer as the module work has not landed yet.
[10:41] <tinwood> gnuoy, kk - I was just making sure *I* wasn't going in the wrong direction! :)
[12:15] <stub> Is anyone else able to login to jujucharms.com ?
[12:16] <stub> I'm getting a generic error page after the return from login.ubuntu.com
[12:23] <gnuoy> stub, I'm able to login to it
[12:27] <stub> gnuoy: ta
[12:55] <jamespage> gnuoy, ok https://review.openstack.org/#/c/319787/ is OK
[12:55] <jamespage> its counterpart failed - looking at that
[12:55] <gnuoy> ok
[12:55] <jamespage> and the change to n-ovs failed to bootstrap one test...
[13:20] <lazyPower> blahdeblah - thats great! It may be worthwhile to file a bug against layer-basic to start the discussion around that behavior.
[13:23] <jamespage> gnuoy, swift-storage review tests fail for mitaka due to out-of-date swift-proxy branches in LP - fixing that now...
[13:27] <gnuoy> jamespage, can you make 17:00 UTC on a wednesday for charmers IRC meeting?
[13:30]  * jamespage thinks
[13:30] <jamespage> yah
[13:36] <lazyPower> wait, we're having a meeting on wednesay? or is this specifically for the ~openstack charmers?
[13:36]  * lazyPower doesn't see anything on the calendar for wednesday
[13:36] <lazyPower> gnuoy ^
[13:37] <gnuoy> lazyPower, openstack charmers
[13:37] <lazyPower> Ok, phwew
[13:37] <lazyPower> I thought I missed the memo
[13:37]  * magicaltrout hands lazyPower the memo
[13:37] <gnuoy> lazyPower, you'd be more than welcome if you fancy it
[13:37] <lazyPower> i mean, if you need me i'll be there buddy
[13:43] <lazyPower> gnuoy - whats the focus of the meeting? i may crash regardless so i can lend a hand while running support in here during off-hours.
[13:43] <lazyPower> if there's going to be a knowledge dump or something :)
[13:44] <gnuoy> lazyPower, Rap about all think Openstack charm related really
[13:44] <gnuoy> https://wiki.ubuntu.com/ServerTeam/OpenStackCharmsMeeting
[13:46] <gnuoy> jamespage, it's all booked with the fridge and I've created a basic wiki area https://wiki.ubuntu.com/ServerTeam/OpenStackCharmsMeeting
[13:50] <jamespage> \o/
[14:14] <gnuoy> jamespage, I've pushed hacluster up to github and have a project-config change ready to propose, is there anything else I need to do to get hacluster in?
[14:14] <jamespage> gnuoy, I don't think so
[14:14] <gnuoy> kk, ta
[14:15] <jamespage> gnuoy, oh wait - does it have a stable branch?
[14:15]  * jamespage looks
[14:15] <gnuoy> jamespage, it does not have a stable branch
[14:15] <jamespage> gnuoy, OK we can cut that once we move over if need be
[14:16] <jamespage> gnuoy, I can't remember what I did to each repo proir to proposing
[14:16] <jamespage> gnuoy, I think it was a) add tox and testr configuration stuff a b) add .gitreview so that git review dtrt once moved
[14:17] <gnuoy> ah, I haven't checked those, thanks
[14:29] <jose> gnuoy: only 30m for that meeting?
[14:31] <gnuoy> jose, I was going by the server team meeting which is usually done within 30mins tbh
[14:31] <jose> ah, ok :)
[14:43] <gnuoy> jamespage, tinwood, do either of you do some mocking recently of apt_pkg? I'm sure I saw that fly by in a review
[14:45] <tinwood> gnuoy, not that I specifically remember, but I'm pretty good at mocking things out now (properties notwithstanding)
[14:45]  * tinwood shakes fist at code.
[14:57] <jamespage> gnuoy, erm yes - in a action unit test
[14:58] <gnuoy> jamespage, ah, I think I've got it, heat
[15:02] <jamespage> gnuoy, ggnnnnnn
[15:02] <jamespage> gnuoy, keep hitting that juju bug where the private/public address disappears
[15:02] <jamespage> twice today
[15:02] <gnuoy> yeah, it's a real pain
[15:04] <jamespage> gnuoy, I'll poke the juju team again, but so far...
[15:04] <jamespage> grag
[15:59] <coreycb> jamespage, this is fixed up: https://code.launchpad.net/~corey.bryant/charm-helpers/systemd/+merge/287110
[16:39] <cory_fu> lazyPower: The filebeat and topbeat charms were promulgated from ~containers, right?  And they're up to date with what's in the ~containers namespace?
[16:42] <lazyPower> cory_fu - uhh, no. there's some slight changes that landed in repo that need to make it to the store
[16:42] <lazyPower> but correct. promulgated sources point at ~containers
[17:18] <lazyPower> hey dimitern o/   Re: your questions about amulet with juju2.  From what I remember, tvansteenburgh has landed some new code and PPA's to make getting at this easier. If you add ppa:tvansteenburgh/ppa and apt-get install python-jujuclient from there, that should be all you need to get amulet working under juju2.
[17:18] <lazyPower> if i'm missing anything, i'm sure he will correct me :)
[17:18] <dimitern> lazyPower: thanks, I'll give that a try and come back with feedback then :)
[17:19] <tvansteenburgh> dimitern: you want juju-deployer from that ppa also
[17:19] <dimitern> lazyPower: e.g. it will be much faster to use lxd + zfs backing to run amulet tests, rather than old lxc even with btrfs backing
[17:19] <dimitern> tvansteenburgh: because amulet uses it?
[17:20] <tvansteenburgh> dimitern: yeah
[17:20] <dimitern> tvansteenburgh: (I haven't specifically needed the deployer yet)
[17:20] <dimitern> tvansteenburgh: right, good to know, thanks!
[17:21] <dimitern> tvansteenburgh, lazyPower: so by the end of the week I might poke you guys for a official review :) \o/
[17:21] <dimitern> once I get the clustering working and a few other things, and ofc lots more tests
[17:21] <lazyPower> dimitern i look forward to it :) good luck man, and hi5 on the progress
[17:23] <dimitern> lazyPower: thanks! I was kinda scared by the apparent complexity of the layers, but it only took me a couple of hours following various guides to grok all the awesomeness..
[17:23] <dimitern> indeed the interface layers I got almost immediately
[17:23] <lazyPower> dimitern - we're highly interested in feedback in that dept. Such as how good our docs are, what was missing/good. etc.
[17:24] <dimitern> lazyPower: well, as for feedback, some docs / guides need updating.. but that's true for most of juju's docs heh
[17:25] <dimitern> lazyPower: I'll keep a list of comments / thoughts to share at the end of it
[17:25] <lazyPower> dimitern dont tell me, go file bugs <3
[17:25] <dimitern> hehe will do
[17:25] <lazyPower> nick reassigns them to us when he identifies its an eco-wheelhouse thing
[17:25] <lazyPower> so the more feedback the better off our docs will be. ta in advance :D
[17:26] <dimitern> sure, no probs :)
[17:37] <cory_fu> lazyPower: What's the status on the kibana charm support for beats?  I see that the promulgated version doesn't have the dashboard?
[17:37] <lazyPower> cory_fu pending a review as pointed out last week https://code.launchpad.net/~lazypower/charms/trusty/kibana/add-dashboard-loader-action/+merge/295359
[17:38] <cory_fu> Ah, you got the config change in there, I see.  Nice
[17:38] <lazyPower> i didnt know if you wanted to wait fo rthis to come up to the top in the revq or get it triaged sooner as its a dpeendency for your work.
[17:38] <cory_fu> I'll review that now, since I need to publish the Spark bundle using it
[17:38] <lazyPower> ok, i have a rev increment on filebeat/topbeat as well
[17:39] <lazyPower> let me finish this isv work and i'll switch feet to make sure that i've got latest in teh store. there were some fixes that made the layers easier to digest with the apt_layer
[17:39] <cory_fu> Sounds good
[18:15] <cory_fu> lazyPower: Please see review comments on https://code.launchpad.net/~lazypower/charms/trusty/kibana/add-dashboard-loader-action/+merge/295359
[18:16] <cory_fu> If you can inform me what the correct fixes are, I'm happy to work on them as part of merging, since I need this for our bundle.
[18:17] <cory_fu> The first couple seem self-evident, but I'm not sure how to handle the elasticsearch relation requirement
[18:18] <lazyPower> cory_fu - i'm checking for the relationship in the action and failing if its not present
[18:18] <lazyPower> is that not good enough?
[18:19] <cory_fu> There are some gaps
[18:19] <lazyPower> cory_fu - but thats bs
[18:20] <lazyPower> config-changed is executed after the relationship hooks
[18:20] <cory_fu> I don't believe that is true, and even if it's true for bundles, it's not true for manual deploys
[18:20] <lazyPower> bundles have zero bearing over hook sequence
[18:21] <lazyPower> cory_fu - did you deploy to verify the gaps?
[18:21] <lazyPower> i did and it worked as expected. i didn't need to force a config-changed event
[18:22] <cory_fu> I did manually test all of the issues I noted
[18:22]  * lazyPower sighs heavilly
[18:22] <lazyPower> i dont know why this worked for me and not for you then
[18:22]  * lazyPower bootstraps and gets ready to sink more time in this
[18:23] <cory_fu> Of possible relevance is that I'm testing on 1.25
[18:23] <lazyPower> i dont think there was any change to hook sequencing of that nature between 1.25 -> 2.0
[18:23] <lazyPower> i guess the easy fix is to implicity call config-changed from the relation-changed hook
[18:23] <lazyPower> s/implicitly/explicitly
[18:25] <cory_fu> lazyPower: Case one: I left the config at default value, added the relation, then changed the checksum option to trigger a config-changed hook.  That config-change hook failed with http://pastebin.ubuntu.com/16640068/
[18:25] <cory_fu> The config-changed hook definitely did not fire after the relation hook until I manually changed a config value
[18:26] <cory_fu> I can believe that relation-ids returns values during config-changed in a bundle deploy because the relations are established early.  That won't even depend on the hook order
[18:26] <lazyPower> there's no good way to validate this then
[18:27] <cory_fu> o_O
[18:27] <cory_fu> I can replicate this entirely consistently
[18:27] <lazyPower> i'm saying if ES is there
[18:27] <lazyPower> i cant reasonably do this without some kind of state mechanism letting me know the data is there
[18:27] <lazyPower> i've been spoiled with reactive
[18:27] <lazyPower> and this is not reactive
[18:28] <cory_fu> True
[18:28] <cory_fu> But you can always use relation-get
[18:28] <lazyPower> cory_fu - contributions welcome <#
[18:28] <lazyPower> <3
[18:28] <cory_fu> But I was wondering if you even care about the relation data, because it doesn't appear to be used in load.sh.  That just defaults to localhost anyway
[18:28] <cory_fu> lazyPower: I'm perfectly happy to make the changes and run them by you.
[18:28] <lazyPower> that vhost isn't created until elasticsearch is joined
[18:29] <lazyPower> so it'll fail either way
[18:29] <cory_fu> The action should be validating the presence of the vhost, then
[18:29] <lazyPower> hmmm
[18:29] <cory_fu> But should load.sh be using the relation data?  That was my main question
[18:29] <cory_fu> Or is localhost ok?
[18:29]  * lazyPower shrugs
[18:30] <lazyPower> what makes more sense?
[18:30] <lazyPower> its both going to the same place, just depends if its going through the proxy or directly to ES
[18:30] <cory_fu> I don't know anything about kibana, so I have no idea
[18:30] <cory_fu> Ok, so either will work?  That's fine, then.
[18:30] <cory_fu> I just saw that it accepted the host as a param that wasn't being provided and figured it was a bug
[18:30] <lazyPower> yeah, that proxy was an addon a while back so you dont have to juju expose es ot the world
[18:31] <lazyPower> i really really really want to re-write this charm
[18:31] <cory_fu> :)
[18:31] <lazyPower> i just dont have the time :/
[18:31] <cory_fu> Yeah, I understand
[18:31] <cory_fu> Ok, I'll make the changes that I think are appropriate and run them by you
[18:32] <lazyPower> kk thanks man. sorry i dont know juju hook-execution as well as i used to
[18:32] <lazyPower> i blame you for this though... or credit. Either way, its a positive thing
[18:32] <cory_fu> ha
[18:32] <cory_fu> Indeed
[18:33] <cory_fu> lazyPower: Was the intent of the load-dashboard action to support custom (manually uploaded) dashboard?  Or only pre-baked?
[18:34] <lazyPower> both
[18:34] <cory_fu> Ok, that's what I thought
[18:34] <lazyPower> so long as it lives in $CHARM_DIR/dashboards/$DASH  and has a load.sh
[18:34] <cory_fu> Yep
[18:34] <lazyPower> which i think is outlined in the readme
[18:34]  * lazyPower crosses fingers
[18:34] <lazyPower> phwew, yeah i did cover that.
[18:35] <cory_fu> Oh, good, it even talks about the localhost proxy
[18:35] <cory_fu> I guess I should have read that before bugging you.  :p
[18:37] <lazyPower> nah :D its all good. thats a common gotchya because we do this, its not necessarily required
[18:37] <lazyPower> artifact of the charm being smarter than the deployment guide
[18:38] <lazyPower> also, man, dang i see what you meant by it failed with action-get. you removed the config value and it still triggered calling the loader.
[18:38] <lazyPower> thats a hairy assumption
[18:39] <lazyPower> mbruzek - just landed tls/k8s. \o/
[18:40] <lazyPower> ready for you to rev at your leisure sir
[18:40] <lazyPower> cory_fu - did you want me to get the other concerns aside from the elasticsearch relation sniffing? I can fix the logic erorrs in the action/loader.
[18:40] <cory_fu> No, I'll address them
[18:40] <lazyPower> ack
[18:42] <cory_fu> lazyPower: Does Kibana do anything useful w/o ElasticSearch?
[18:42] <lazyPower> negative
[18:42] <lazyPower> it no-ops without ES
[18:42] <cory_fu> That's what I thought.  It should probably just report blocked pending the relation
[18:42] <lazyPower> i mean, it does deploy kibana
[18:42] <lazyPower> but kibana directs you to a status page that points out its unhealthy
[18:43] <lazyPower> and doesn't tell you what it really needs, it just reports an error in the "ES Driver"
[18:43] <cory_fu> Hrm.  Why wasn't it made subordinate to ES, I wonder?
[18:43] <cory_fu> *shrug*
[18:43] <lazyPower> yeah, its just a webapp that does very little server side processing.... it makes sense to make it a sub
[18:49] <cory_fu> lazyPower: I assume that calling a dashboard's load.sh is idempotent and there's no significant cost to calling it again?
[18:50] <lazyPower> correct, it will overwrite what was there before
[18:51] <lazyPower> so if you load up a visualization and manually edit it, then re-run that ocnfig-changed block wave bye to your custom visualization that was a derivative from what was included.  (this was the original reason i made it an action)
[18:51] <cory_fu> And it's not terribly expensive to re-load it?
[18:52] <cory_fu> Wait, by manually edit it... Do you mean via the GUI or such?  Is that expected to happen?  If so, I'll add checking to not reload them automatically
[18:53] <cory_fu> Actually, I think I'll do that anyway
[18:54] <lazyPower> right. so you load it, and then you go into kibana and modify one of the "beats visualizations"  - like the mongodb connection visualizer to include latency. it will forefit that visualization modification. They have the same ID unless you explicitly make a copy of the visualization.
[20:10] <cory_fu> lazyPower: This look good to you?  https://bazaar.launchpad.net/~johnsca/charms/trusty/kibana/dashboard-review/revision/27
[20:11] <lazyPower> will TAL in a sec, verifying k8s
[20:15] <lazyPower> cory_fu omg the return of sentinel files
[20:15] <lazyPower> but man, you really gave this some TLC
[20:15] <cory_fu> I know.  Without charmhelpers, there's no alternative
[20:16] <cory_fu> I wonder if it wouldn't have been faster to convert it to layers.  ;)
[20:16] <lazyPower> hooks/install may want a mkdir -p in the event it exists. (no idea why, but better to be ok with it existing than fail)
[20:16] <cory_fu> mkdir -p on what?
[20:16] <cory_fu> Oh yeah
[20:17] <lazyPower> this looks great. i would +1 this as is. that comment was a nit
[20:18] <cory_fu> Ok, if you're ok with that, I'm ok with the original review, so I can go ahead and merge it
[20:18] <lazyPower> SGTM
[20:18] <lazyPower> +1000 for hte contribution, thanks for being a fixer
[20:19] <cory_fu> Hrm.  That charm is still depending on ingestion.
[20:19]  * lazyPower awards cory the fixer badge
[20:19] <cory_fu> :)
[20:19] <lazyPower> nah i just kept that up to date as its the only canonical source i could find for kibana
[20:19] <cory_fu> Should I re-promulgate that using the new workflow?
[20:19] <lazyPower> we still need ot charm push it
[20:19] <lazyPower> yeah
[20:19] <lazyPower> i was going to take it, but if you're ok with owning it, i'm +1 to you owning it
[20:19]  * lazyPower has ~ 20 charms he's responsible for already... 5 of which i'm actively maintaining
[20:19] <cory_fu> Are you guys taking ownership of it (i.e., should I promulgate from ~containers)?
[20:20] <lazyPower> i mean, you can :D
[20:20] <lazyPower> we'll take it int eh namespace so it lives with logstash and the beats
[20:20] <lazyPower> i suppose that makes the most sense, keep em all together
[20:21] <cory_fu> Though it's not really anything to do with containers
[20:21] <lazyPower> right
[20:21] <lazyPower> it has more to do with little data
[20:21] <cory_fu> I feel like this is a slight rough edge to the new process
[20:23] <lazyPower> i've been pointing people at ~containers to deploy kibana for beats since step 1, its probably fine to push it there and re-point the promulgated copy
[20:23] <lazyPower> i'll shepherd it
[20:23] <lazyPower> pretty sure mbruzek will too
[20:34] <cory_fu> lazyPower: Actually, I don't have access to ~containers
[20:35] <lazyPower> cory_fu - adding you individually. If you like you can supplant that with the bigdata team so we can jointly maintain it
[20:35] <lazyPower>   Write:
[20:35] <lazyPower>   - containers
[20:35] <lazyPower>   - johnsca
[20:36] <lazyPower> should be g2g now
[20:36] <cory_fu> lazyPower: Hrm.  I can't push to LP, though.
[20:36] <lazyPower> hrm
[20:36] <lazyPower> you cant push to lp:~charmers/charms/trusty/kibana/trunk?
[20:36] <cory_fu> β bzr push lp:~containers/charms/trusty/kibana/trunk
[20:36] <cory_fu> bzr: ERROR: Permission denied: "~containers/charms/trusty/kibana/trunk/": : Cory Johns is not a member of Charm Containers
[20:36] <lazyPower> oh, ooooohhhhh
[20:36] <lazyPower> i see what you did there
[20:37] <lazyPower> hang on i can fix that as well
[20:37] <cory_fu> I could push it to ~charmers, though, but you'll want to re-own it, right?
[20:37] <lazyPower> well, i'm jsut now catching up to what you're concerned with. that the source branch is  not obvious living in ~charmers, and its only further compouding old behavior of who owns what that we dont want to persist
[20:38] <cory_fu> Yeah, we should promulgate from the same namespace that the code lives in.
[20:38] <cory_fu> Unless we move it to GitHub, of course
[20:38] <cory_fu> I mean, I guess it doesn't technically matter where the source lives
[20:38] <lazyPower> as the meme implies "Sooooooon"
[20:38] <lazyPower> oh we care
[20:38] <lazyPower> or we should
[20:39] <lazyPower> when we go to patch it, if we have no idea where it came from we're kinda asked out
[20:39] <cory_fu> Well, that's what the homepage and bugs-url extra-info are for, right?  ;)
[20:39] <lazyPower> oh, yeah
[20:39] <lazyPower> i suppose thats right
[20:39] <cory_fu> But it will be easier if the namespaces match up
[20:39] <lazyPower> yep i'll add ya
[20:40] <lazyPower> or i would if marcoceppi didn't own everything i ever did ever
[20:40] <cory_fu> :)
[20:40] <lazyPower> marcoceppi <3 can you add cory to ~containers?
[20:40] <cory_fu> lazyPower: Why I don't I just push it to ~charmers and let you re-own it?
[20:40] <lazyPower> i'm ok with this too
[20:40] <lazyPower> pretty sure the bugs url points to that location anyway
[20:42] <cory_fu> lazyPower: Ok, pushed
[20:43] <cory_fu> If you can re-push it to ~containers, I can re-promulgate from there
[20:43] <cory_fu> Actually, I guess I can go ahead and do the store updates and you can do the code move at your leisure
[20:44] <cory_fu> Or not.  Still unauthorized to `charm push` to ~containers
[20:44] <lazyPower> cs:~containers/trusty/kibana-4
[20:44] <lazyPower> i just pulled and pushed
[20:44] <lazyPower> weird that you're denied when you're implicitly added, are you johnsca on launchpad?
[20:45] <cory_fu> lazyPower: Oh, I'd need read & write perms to the unpublished channel as well
[20:45] <lazyPower> hrm, i didn't know permissions were by channel. thats news to me
[20:45] <cory_fu> Yep
[20:45] <lazyPower> i thought it was ACL'd on the entity itself
[20:45] <lazyPower> like, one step below that
[20:45] <cory_fu> Nope.  Do `charm show cs:~containers/trusty/kibana id perm --channel=unpublished`
[20:46] <lazyPower> yeah i see this now in the charm grant help output
[20:46] <lazyPower> #TIL
[20:46] <cory_fu> Makes sense, too.  You may well want different perms on unpublished, development, stable
[20:46] <cory_fu> Might want unpublished to not be publicly visible, for instance
[20:47] <lazyPower> yar, i just updated the unpublished channel. Shouldn't be an issue next time around
[20:47] <lazyPower> warning: bugs-url is not set.  See set command. -- i do need to plug that warning though
[20:49] <lazyPower> ok cory_fu, last bit thats needed that i see is re-pointing the promulgated link
[20:50] <cory_fu> lazyPower: Ok, done
[20:50] <lazyPower> boom ^5 on the teamwork
[20:51] <cory_fu> lazyPower: Are topbeat and filebeat updated?
[20:51] <lazyPower> thats also 2 closed bugs, great succes
[20:51] <lazyPower> doing that now
[20:51] <cory_fu> Those will both be -2 right?
[20:51] <lazyPower> i believe so yes
[20:52] <lazyPower> yep, current promulgated revisions are -1 on both filebeat and topbeat, so next push should rev to -2
[20:56] <lazyPower> cory_fu ok both are pushed and published
[20:56] <cory_fu> Thanks!
[20:57] <lazyPower> should be all good in the hood for CWR now
[21:24] <ryebot> tvansteenburgh, does amulet handle deploying different services to different series in the same deployment? e.g., service A -> trusty & service B -> xenial?
[21:29] <cholcombe> lazyPower, are you good with sphinx docs for python?
[21:36] <tvansteenburgh> ryebot, yes
[21:36] <ryebot> tvansteenburgh: thanks, that's also true under juju2?
[21:36] <tvansteenburgh> ryebot, yep
[21:36] <ryebot> tvansteenburgh: thanks
[21:37] <tvansteenburgh> ryebot, see the 'series' kwarg to Deployment.add()
[21:51] <petevg> I have a newbie question: what does a "series is empty" error mean? (The context is that I'm doing "juju deploy hadoop-processing", and it fails on openjdk with 'cannot add service "openjdk": series is empty')
[21:52] <petevg> "juju deploy openjdk" does work, as a standalone command. Am I doing the right thing if I deploy openjdk, then trying redeploying hadoop-processing?
[21:53] <petevg> (This is on an Ubuntu Xenial box, deploying locally to lxc containers. My juju version is 2.0-beta3-xenial-amd64)
[22:07] <tvansteenburgh> petevg: i think that was a bug in the bundle handling in beta3, it works with beta7
[22:07] <tvansteenburgh> js
[22:08] <petevg> tvansteenburgh: Cool. I didn't realize that I was that far behind. I'll update. Thank you :-)
[22:11] <ryebot> tvansteenburgh: ah, needed to update the amulet lib to get it to work right; thanks again!
[22:11] <cholcombe> i uploaded the ceph_api to pypi: https://pypi.python.org/pypi/ceph_api and docs: http://pythonhosted.org/ceph_api/.  Let me know what you guys think!
[22:25] <petevg> Aha. I had the juju2 package installed from juju/stable. Removing it and installing juju-2.0 from juju/devel made everything a lot happier.
[22:40] <blahdeblah> lazyPower: It actually turns out I was doing something bone-headed, which is not using the hook template from layer-basic.
[22:40] <blahdeblah> Not sure if that requirement is documented anywhere, but I certainly haven't come across it in my travels.
[22:40] <blahdeblah> Anyway, stub pointed out where I was wrong and next time I get a chance to hack on it I'll try going back to the original state-based way once I get my hooks right.