=== natefinch-afk is now known as natefinch
=== thumper is now known as thumper-afk
=== zz_CyberJacob is now known as CyberJacob
=== CyberJacob is now known as zz_CyberJacob
=== psivaa is now known as psivaa-lunch
=== psivaa-lunch is now known as psivaa
=== JoshStrobl is now known as JoshStrobl|AFK
=== JoshStrobl|AFK is now known as JoshStrobl
[14:39] <tvansteenburgh> rick_h_: what am i doing wrong here? https://api.jujucharms.com/charmstore/v4/bundle/mediawiki-single-8
[14:39] <rick_h_> tvansteenburgh: https://api.jujucharms.com/charmstore/v4/mediawiki-single/meta/any
[14:40] <rick_h_> tvansteenburgh: no need for /bundle
[14:40] <rick_h_> tvansteenburgh: and you have to have an endpoint (meta/any is the simplest, see /meta for the list of supported
[14:41] <tvansteenburgh> rick_h_: thanks, was tripped up by paragraph 2 here https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md#intro
[14:42] <rick_h_> tvansteenburgh: yes, why technically bundle is implemented as a series, it's not meant to ever be exposed to end users or the api
[14:42] <tvansteenburgh> ack
[14:42] <rick_h_> tvansteenburgh: but yea, taht paragraph sohuld ignore that vs noting that
[14:43] <rick_h_> though I guess this is charmstore docs...which is implementation
[14:43] <rick_h_> tough line there
[14:44] <tvansteenburgh> rick_h_: is there a python client for this already?
[14:44] <rick_h_> tvansteenburgh: yes sec
[14:44] <rick_h_> tvansteenburgh: https://github.com/juju/theblues has the python client that is used in the storefront
[14:44] <rick_h_> tvansteenburgh: and please feel free to file bugs/patches
[14:44] <rick_h_> tvansteenburgh: and we might end up trying to get this into jujulib one day, but for now it's on its own
[14:44] <tvansteenburgh> rick_h_: excellent, thanks
[14:44] <rick_h_> tvansteenburgh: storefront = web front end on jujucharms.com
[15:37] <firl> anyone have experience hooking up logstash with apache logs?
[15:38] <lazypower> firl, i have done this. which version of the charm are you using? there's currently 2 completely diverged charms. 1 that I am keeping on life support, and one i would recommend that is under maintenance by jrwren
[15:39] <firl> lazypower: I haven’t hooked it up yet. I just deployed 4 nodes of a web frontend using my charm
[15:39] <firl> and wanted to know how hard / easy it was to get a logstash setup working across it
[15:39] <lazypower> jrwren, you've added combined apachelog grok filters setup haven't you?
[15:40] <jrwren> yes?
[15:41] <lazypower> the certainty is comforting :D
[15:41] <jrwren> firl: i'll start by saing, it ain't easy :)
[15:41] <lazypower> actually, you have apache_access in here...
[15:41] <jrwren> the grok filter is an easy part.
[15:41] <lazypower> not the combined log
[15:41] <lazypower> so, there's that
[15:42] <jrwren> lazypower: look again.
[15:42] <lazypower> http://bazaar.launchpad.net/~evarlast/charms/trusty/logstash/trunk/view/head:/files/filter.conf  - is what i'm looking at
[15:42] <lazypower> ah disregard, line 9 has the magic
[15:42] <firl> haha
[15:43] <jrwren> the thing is, I'm not aware of any apache charm which uses the log relation to expose to a logstash or beaver subordinate which logs to ship, so its a largely unsolved convention in all juju charm.s
[15:43] <firl> so is there another easy way to aggregate apache logs using juju charms or should I try on getting the logstash working?
[15:43] <firl> gotcha
[15:43] <lazypower> jrwren, we should write an interface stub for it
[15:44] <lazypower> that way all you're doing is "filling in the blanks" in whatever consumer charm
[15:44] <firl> it be nice if I could just have my charm expose the relation
[15:44] <lazypower> firl, +1 to that. why eat an agent when your relation can do what it needs to do
[15:44] <firl> ( I was kinda hoping it was that easy )
[15:44] <jrwren> lazypower: yup. i have that, probably could be a lot better.
[15:44] <lazypower> firl, it will be basically that easy. THere's some dependency work to be done though.
[15:44] <firl> gotcha
[15:45] <lazypower> jrwren, correct me if i'm wrong, but beaver is the only *supported* shipping method atm right?
[15:45] <jrwren> lazypower: supported by whom? me? :)  beaver is the most tested by me.
[15:45] <firl> hah
[15:45] <lazypower> jrwren, well the charm is in *your* namespace :)
[15:46] <jrwren> lazypower: right, and for good reasons that it is not promulgated :)
[15:47] <lazypower> jrwren, are we still working towards making that charm the ~recommended? its lightyears ahead of the revision i currently have on life support
[15:47] <lazypower> IS is still submitting patches to that charm as well. the sooner we can deprecate it, the better we will be in terms of getting additional hands on helping w/ maintenance
[15:48] <jrwren> lazypower: its taken a lower priority lately.
[15:48] <jrwren> lazypower: we do want to get back to it.
[15:48] <lazypower> understood, so long as its still on the list :)
[15:49] <lazypower> firl, i would highly recommend tracking jrwren's logstash charm, and doing a beaver integration w/ the apache logs vs using whats currently in ~recommended
[15:49] <firl> kk
[15:49] <lazypower> I'll have to put in some time to add some relations + migration path for consumers of the currently recommended logstash charm, and if you go that route, you'r elikely to have an upgrade surprise.
[15:49] <firl> So basically, expose the apache relation into my charm, add the beaver to the units, spin up a logstash and add the relationship
[15:50] <lazypower> yep, that *should* (tm) be all you need to do. Add beaver + write the config for beaver w/ the logstash unit address + port for shipping.
[15:50] <jrwren> right.
[15:51] <lazypower> jrwren, when i'm not buried (ha!) i'll try to get some additional time in on this stack as well and contribute the legacy interfaces we will want to support moving forward. logstash-agent + lumberjack
[15:51] <lazypower> i have a pretty good idea how we can do lumberjack integration + ssl shipping as well
[15:52] <lazypower> self signed cert, but it'll work regardless. Just means we're shipping a CA cert from the leader and normalizing on that certificate
[15:52] <firl> thanks guys, looks like it’s trusty only. I will have to wait a couple weeks until the code base gets upgraded for trusty
[15:52] <jrwren> lazypower: cool. i'm so negative on jvm that what I'd really like to do is move to Heka
[15:52] <jrwren> firl: yeah, sorry. I've not been on precise for quite a while.
[15:52] <lazypower> jrwren, whit did some work there to. Hekka is great for log shipping but writing that config file is hairy
[15:53] <firl> jrwren: haha … I hadn’t until I started helping a side project get up to date. they are feeling the upgrade pains now
[15:53] <lazypower> jrwren, i think i'd rather use the logstash-agent (? i forget which one is the golang bin) and use the recommended plugin
[15:53] <jrwren> firl: yeah? what side project?
[15:54] <firl> jrwren: helping get a php website up on amazon using juju and charms. they were on rackspace and could only scale vertically
[15:54] <jrwren> lazypower: if you can solve the ssl issue with logstash-agent (lumberjack?) you'd be my hero. :)  its a bit convoluted.
[15:54] <lazypower> jrwren, challenge accepted... in due time.
[15:54] <jrwren> firl: that sounds fun! :)
[15:55] <firl> jrwren: lol, getting mellanox support on openstack sounds more fun currently. But yeah, juju has helped quite a bit in getting some standards and environments managed for the side project
=== ming is now known as Guest97207
[17:06] <coreycb> jamespage, did you have a comment on keystone action-managed upgrade?
[17:06] <coreycb> ah maybe amulet failures
[17:08] <jamespage> coreycb, yeah - hence the recheck
[17:23] <bdx> hatch: you around?
[17:23] <hatch> hello bdx
[17:24] <bdx> hatch: do you know how socket_url is set?
[17:24] <bdx> hatch: in juju-gui
[17:24] <hatch> we've actually been doing a bit of work around that of late, I'll have to refresh my memory on that version
[17:25] <bdx> app.env.getAttrs() returns an object, one attribute of the object is socket_url, which is set to "wss://10.16.100.123/ws/environment/46da5e13-3bbe-4751-8935-e113fd4a0196/api"
[17:25] <hatch> https://github.com/juju/juju-gui/blob/develop/app/app.js#L693
[17:26] <bdx> hatch: should socket_url be indicitave the ip of my bootstrap nodes ip address?
[17:26] <hatch> bdx: it should point to the gui instance
[17:26] <bdx> oh ok
[17:26] <hatch> as it needs to talk through its server
[17:26] <hatch> still can't connect hey?
[17:27] <bdx> no
[17:27] <hatch> I'm guessing that there is a communication issue between the gui instance and your bootstrap node
[17:27] <hatch> which we should be surfacing but aren't
[17:27] <hatch> if you log into it, there should be a log in the upstart logs
[17:27] <hatch> maybe there is an indication to the problem in there
[17:29] <bdx> ok...I feel like I've checked them out and didn't see anything jumping out at me ....is there something I should be looking for inparticular?
[17:30] <hatch> honestly I have no idea, I have never heard of this issue before :)
[17:30] <hatch> I asked a couple others, just waiting to see if they have any ideas
[17:31] <bdx> hatch: great, thank you
[17:34] <frankban> bdx: could you please try if the ws connects in incognito mode?
[17:34] <bdx> yes, omp
[17:35] <bdx> frankban: nothing
[17:35] <bdx> frankban: same result
[17:36] <frankban> bdx: do you have python available?
[17:36] <frankban> bdx: to check that the ws is listening
[17:36] <bdx> frankban: of course
[17:37] <frankban> bdx: could you please pip install websocket-client?
[17:38] <bdx> yes, done
[17:40] <hatch> thanks frankban :) bdx he is much more familiar with the guiserver side than I am :)
[17:40] <bdx> hatch: awesome, thanks for your help!
[17:40] <frankban> bdx: python -c 'import websocket; websocket.create_connection("wss://10.16.100.123/ws/environment/46da5e13-3bbe-4751-8935-e113fd4a0196/api", sslopt={"cert_reqs": 0, "ssl_version": 3})'
[17:42] <bdx> frankban: I can successfully create a ws object
[17:44] <frankban> bdx: so the problem is that the GUI is not able to connect to that endpoint?
[17:45] <bdx> If I assign the object to a variable e.g. ws = websocket.create_connection("wss://10 ......), and then do a result =  ws.recv(), ws.recv() never returns....
[17:46] <bdx> is this behavior expected?
[17:47] <frankban> bdx: yes
[17:48] <frankban> bdx: you should send something before receiving, like: {
[17:48] <frankban>         'Type': 'Admin',
[17:48] <frankban>         'Request': 'Login',
[17:48] <frankban>         'Params': {'AuthTag': 'user-admin', 'Password': password},
[17:48] <frankban>     'RequestId': 1}
[17:49] <frankban> bdx: maybe I am missing some background, is the GUI not connecting to the socket?
[17:50] <bdx> I mean....I feel like I would be seeing errors in the console if it wasn't.....
[17:51] <frankban> bdx: yes, so what are the symptoms?
[17:53] <bdx> frankban: http://cl.ly/image/0h1N3P3k0Z28
[17:54] <frankban> bdx: I see, no services in the canvas
[17:54] <bdx> frankban: I can deploy juju-gui to lxc, baremetal, or kvm, no mater what It wont display my environment details...
[17:54] <bdx> exactly
[17:54] <frankban> bdx: could you please run this script passing your env name? http://pastebin.ubuntu.com/12544350/
[17:56] <bdx> frankban: done. What am I looking for here?
[17:56] <frankban> bdx: alos, i see an error notification on your GUI, what does it say?
[17:56] <frankban> bdx: could you please paste the output of the script?
[17:56] <frankban> bdx: oh wait
[17:57] <bdx> http://cl.ly/image/0G2l290Y140J
[17:57] <frankban> bdx: the output will include your env password, so you might want to remove that
[17:57] <bdx> the script runs indefinitely
[17:57] <frankban> bdx: cool that error is unrelated
[17:57] <frankban> bdx yes, just the initial output is ok
[17:58] <frankban> bdx: the script watches the juju env in a similar way than the GUI does
[17:58] <bdx> frankban: nice, ok : http://paste.ubuntu.com/12544391/
[17:58] <bdx> nice!
[17:58] <bdx> finally some introspection.....
[17:59] <frankban> bdx: so you are getting a "unit not found" error from the watcher, and that would explain why the GUI is not showing services
[17:59] <frankban> bdx: juju version?
[17:59] <bdx> frankban: totally, nice.
[17:59] <hatch> yay progress! :)
[17:59] <bdx> 1.24.5-trusty-amd64
[18:02] <frankban> bdx, hatch: looks like https://bugs.launchpad.net/juju-gui/+bug/1485249 to me, and looks like a juju-core bug
[18:02] <mup> Bug #1485249: Juju gui is not loading. Because: "Error":"unit not found" <juju-gui:New> <https://launchpad.net/bugs/1485249>
[18:02] <frankban> bdx: simple fix would be updating juju version
[18:03] <frankban> hatch: I need to go now, could you please take care of triaging that bug and gather info from bdx?
[18:03] <hatch> you bet
[18:04] <hatch> thanks a lot frankban
[18:04] <bdx> hatch, frankban: if I update juju-core, do I need to also need to update juju on machines where the agent runs?
[18:05] <frankban> bdx: yes I guess you need to run "juju upgrade-juju" but never run that so hatch can be more helpful there (or core devs)
[18:05] <frankban> done for the day, good night!
[18:05] <hatch> actually I've never run it either :D
[18:05] <bdx> frankban: thanks alot! night!
[18:06] <frankban> yw
=== zz_CyberJacob is now known as CyberJacob
[18:16] <bdx> hatch: so I have upgraded juju such that juju-core and all of my agents are running 1.24.6
[18:16] <bdx> hatch: the issue persists after the upgrade even
[18:16] <hatch> bdx: alright so it appears that the issue has not yet been resolved in juju-core
[18:17] <bdx> hatch: gotcha, I see that.
[18:17] <hatch> could I get you to add your report to that bug frankbank linked?
[18:17] <hatch> I can then pass it up the food chain to get it looked at
[18:17] <hatch> (I'll do that regardless, but if you comment you'll be notified)
[18:17] <hatch> :)
[18:17] <bdx> hatch: Totally, will do
[18:18] <hatch> thanks, sorry about the bug
[18:24] <bdx> hatch: Ok, bug updated. Let me know if you need any other info. Thanks for your help!
[18:24] <hatch> excellent thanks
=== CyberJacob is now known as zz_CyberJacob
[20:09] <beisner> o/ well hi there bdx, firl
[20:15] <firl> hey beisner, how’s it going?
[20:16] <beisner> ahh pretty good here, thanks firl
[20:17] <beisner> firl, infinibanding yet?
[20:17] <firl> I sent a message to the mailing list, mark responded saying some people might reach out
[20:17] <firl> but I think I am going to start by cloning the charms I need and one by one hooking it up proper
[20:19] <beisner> oh yes i recall now seeing that.
[20:21] <firl> So I might ask you some questions on the sanity of my environment since you’ve tested everything under the sun haha
[20:22] <beisner> ha, feel free to ask.  if i don't know i'll try to find info.
[21:03] <beisner> coreycb, jamespage - neutron-gateway/next unit tests start failing @ rev 142
[21:03] <beisner> coreycb, oh that one.  well now my branch fails as i rebased ;-)  http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/neutron-gateway/next/revision/142
[21:05] <beisner> fyi output @ http://paste.ubuntu.com/12546097/
[21:15] <niedbalski_> aisrael, ping
=== thumper-afk is now known as thumper
[22:11] <coreycb> beisner, oops, yeah that commit fixed amulet but broke unit
[22:15] <coreycb> beisner, ok that's fixed now in next
=== zz_CyberJacob is now known as CyberJacob
[22:45] <aisrael> niedbalski_: pogn
=== CyberJacob is now known as zz_CyberJacob