[01:01] <marcoceppi> stub: you about?
[01:01] <blahdeblah> marcoceppi: Bit early in the day for him
[01:01] <marcoceppi> blahdeblah: he seems to always be around when I need him :)
[01:01] <blahdeblah> Well, don't let me stand in the way, then. :-)
[01:02] <marcoceppi> blahdeblah: haha, I'll just leave a question for him ;)
[01:03] <marcoceppi> stub: I want to store about 8,000 lines of text in a single column in psql. What's the best data type for that?
[03:09] <cholcombe> is juju going to support instance-type i3.large?  it says it's not valid as of juju: 2.1.0
[04:05] <stub> marcoceppi: 'text'
[04:08] <stub> marcoceppi: That will keep you happy until you approach 1GB. The json type may also be interesting if you have json or something that serializes well to json.
[07:53] <kjackal> Good morning Juju world!
[08:35] <anrah_> Newbie question about actions.. I have difficulties implementing action in a way that I have one actions.py and then just "dummy" action executables under actions-folder
[08:35] <anrah_> which just say "actions.py"
[08:36] <anrah_> output of the action says: message: 'fork/exec /var/lib/juju/agents/unit-my-charm-0/charm/actions/do-stuff: exec format error'
[08:45] <kjackal> anrah_: I am going to need moreinfo on this. Do you have your code somewhere public so I can take a look?
[08:47] <anrah_> Just a sec
[09:15] <kklimonda> should juju create bridge interfaces for all physical ones on the host?
[09:16] <kklimonda> or is there some logic behind it?
[09:17] <kklimonda> my controller is 2.0.2
[09:19] <kklimonda> (I'll try with 2.1.1 in the meantime)
[09:23] <anrah_> kjackal: got it solved, thanks anyway :) I was missing the obvious symlinks between <action> and actions.py :/
[09:24] <kjackal> cool anrah_
[09:29] <cnf> morning
[09:33]  * cnf sighs
[09:33] <cnf> error: failed install
[09:33] <cnf> any more info, juju?
[09:35] <kjackal> cnf: have you tried asking in the juju list?
[09:36] <cnf> juju list?
[09:36] <kjackal> there might have been some one with similar setup as yours
[09:36] <cnf> oh, mailing list?
[09:36] <kjackal> yes, wait
[09:36] <cnf> those tend to be my very last resort
[09:36] <kjackal> cnf: juju@lists.ubuntu.com
[09:37] <cnf> hmm...
[09:37] <kjackal> cnf: agreed but i see you stuck for too long, and i cannot help
[09:37] <cnf> well, i appreciate that you care :P
[09:40] <cnf> kjackal: problem with mailing lists is that the feedback is so slow
[09:41] <cnf> and i am going forward, just step by step
[09:41] <cnf> by the time someone responds on a list, i'm generally on the next problem
[09:42] <kjackal> cnf: I see. In any case if you you find yourself stuck for too long, remember there is always the list
[09:42] <cnf> yeah, thanks
[09:43] <cnf> maybe i am trying to use broken bundles...
[09:45] <cnf> kjackal: one of my big problems is that the debug info isn't very informative, and the documentation is hard to use
[09:45] <cnf> doesn't make things easier :P
[09:46] <cnf> so i got that little part solved, i think
[09:47] <cnf> i'm watching juju debug-log
[09:47] <cnf> any way to kick a node to retry installing stuff?
[09:51] <cnf> do juju charms often use ansible? or is that just randomly this one?
[09:52] <kklimonda> 2.1 created two bridges for defined networks, but not bridge for the "management" network, and container can't reach controller
[09:58] <kklimonda> I wonder if that's what "empty" binding is for
[10:05] <kjackal> cnf: juju charms can be written in whatever language you want. You can use ansible, puppet, whatever you know best
[10:06] <kjackal> cnf: I usually login to the unit I want to check and look at the logs under /var/logs/juju/
[10:10] <cnf> kjackal: uhu, that looks to be about the same as juju debug-log
[10:10] <cnf> atm it's the only thing on my juju, so that makes it easy :P
[10:11] <cnf> I _think_ it's the ansible playbook not having the proxy set
[10:11] <cnf> i think...
[10:13] <cnf> kjackal: yep, https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1665623 already has a bug for it
[10:13] <mup> Bug #1665623: Does not install behind a proxy <landscape> <elasticsearch (Juju Charms Collection):New> <https://launchpad.net/bugs/1665623>
[10:14] <cnf> balls, ok i'll try a different bundle
[10:15] <kjackal> cnf: if I may ask, what are you interested in?
[10:16] <cnf> i am evaluating juju/maas as a means to install / manage openstack
[10:16] <cnf> but the openstack bundle is a bit complex to learn how juju works, so i picked something simple with 2 nodes
[10:17] <cnf> the openstack bundle needs 4 machines, i only have 3 for my test
[10:18] <kjackal> ah openstack is in a pretty good shape, we have a number of customers using them those bundles. You are aware of the #openstack-charms channel, right?
[10:18] <cnf> i am now :P
[10:19] <cnf> (openstack has too many channels :P )
[10:19] <cnf> joined
[10:19] <cnf> i do want to get a hang of juju a bit more, though
[10:19] <cnf> do you know of a bundle that runs on 2 or 3 machines that i can poke around in?
[10:20] <cnf> i just want to get something that i know works, and then poke around in it
[10:22] <kjackal> kubernetes-core should be small enough
[10:22] <kjackal> or spark processing
[10:25] <cnf> hmm, can't remove units / applications in error?
[10:27] <kjackal> juju remove-machne --force and then remove-appliaction
[10:27] <kjackal> cnf: or remove the model and add a new one?
[10:27] <cnf> yeah, i was considering removing the model
[10:28] <cnf> remove machine --force also worked, it seems
[10:28] <cnf> cool
[10:29] <cnf> k, lets try kubernetes core
[10:29] <cnf> and i should go for drinks
[10:29] <cnf> those HP machines take a while to boot :P
[10:31] <cnf> kjackal: great, that charm seems to have the exact same problem
[10:31] <cnf> >,<
[10:32] <kjackal> can you please file a bug?
[10:32] <cnf>  https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1665623 already exists
[10:32] <mup> Bug #1665623: Does not install behind a proxy <landscape> <elasticsearch (Juju Charms Collection):New> <https://launchpad.net/bugs/1665623>
[10:32] <cnf> i'll see what it is for this one
[10:32] <cnf> ah, nm
[10:32] <cnf> i was too quick
[10:33] <cnf> kjackal: i was looking at the old logs, the HP machines really ARE slow
[10:49] <cnf> kjackal: ok, looking good so far
[10:51] <cnf> ok, all green \o/
[10:53] <kjackal> :)
[10:54] <cnf> now lets see how to use that
[11:43] <psarwa> Hi folks. Have a question regarding relation hooks.
[11:43] <psarwa> I have two db relations with mysql and I need db-admin to execute only after shared-db has executed. Any way to do this?
[11:58] <cnf> hmm
[11:58] <cnf> the k8s core is up
[11:58] <cnf> the dashboards are not working,  it seems
[12:03] <cnf> kjackal: everything seems to work, except the dashboards :P
[12:04] <kjackal> cnf: is it because of proxy issues or because something is wrong in the bundle?
[12:04] <cnf> kjackal: the API responds, but /ui/ gives me an error
[12:04] <kjackal> which bundle did you endup deplying?
[12:05] <cnf> https://jujucharms.com/kubernetes-core/
[12:06] <cnf> so i can connect to https://ip:6443/ui/ which forwards me to /api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard
[12:06] <cnf> which tells me service unavailable
[12:06] <cnf> and i did do `juju config kubernetes-master enable-dashboard-addons=true`
[12:07] <cnf> and my kubectl command works, as well
[12:14] <cnf> hmm, and a  juju add-unit kubernetes-worker isn't working...
[12:14] <cnf> but maybe that's a maas issue >,<
[12:21] <cnf> hmm
[12:21] <cnf> no error, just not not making the maas node
[12:21] <cnf> o,O
[12:28] <cnf> hmz
[12:28] <cnf> tireing :P
[13:57] <cnf> can juju configure network settings on different interfaces separate from maas? or does maas need to be aware of it?
[14:00] <cnf> so all my machines have a 2 x 10G LAG
[14:27] <ahasenack> lazyPower: do you have something new in the elasticsearch/kibana front?
[14:28] <cnf> ahasenack: did that break for you as well? :P
[14:28] <cnf> (it doesn't respect http_proxy settings)
[14:29] <ahasenack> cnf: I filed a bug about e/s not respecting http_proxy iirc
[14:29] <cnf> ah, was that your bug
[14:29] <cnf> i clicked the "affects me too" button
[14:29] <ahasenack> what broke for me here is kibana actually, both firefox and chrome/chromium can't type in search queries anymore
[14:29] <ahasenack> backspace doesn't work, delete doesn't work, it keeps trying to find a previous search in the history
[14:29] <cnf> weird
[14:29] <ahasenack> I think it was a browser upgrade, because it started happening with a long-lived elk deployment I have which was not updated
[14:46] <jamespage> cory_fu, tinwood_swap: what did we decide the best way todo a 'run-at-end-of-execution' type thing was in reactive?
[14:47] <jamespage> I'm experimenting with a partial step towards reactive for our legacy charm codebase and need to ensure that 'assess_status' is executed at the end of each hook exec
[14:48] <tinwood_swap> jamespage, I wrote an at_exit type thing during my testing of reactive for a blog post: http://blog.ajkavanagh.me/2016/12/30/better-charm-interfaces/
[14:49] <tinwood_swap> Basically, I used hookenv.atexit(function) to run at the end after reactive had finished calling handlers.
[14:49] <tinwood_swap> But the set_state, etc. still works without invoking new handler runs.
[14:50] <jamespage> tinwood_swap: right
[14:50] <jamespage> tinwood_swap: if you're interested - https://review.openstack.org/#/c/444318
[14:50] <jamespage> it's not passing unit or lint atm - but the charm is functional
[14:51] <jamespage> tinwood_swap: one of the challenges i had was that reactive always tries to load the interface provides.py - I mocked those out for now
[14:51] <jamespage> but I feel a base-reactive-stepping-stone layer coming on
[14:51] <jamespage> that does that as part of a tactic
[14:51] <jamespage> tinwood_swap: I quite like the idea of taking 29k lines of code out of ceph-mon :-)
[14:53] <jamespage> cory_fu - or maybe that might be better in the base layer as a layer option
[14:54] <tinwood_swap> jamespage, interesting :)  I'll take a quick look as all I'm doing is scanning old invoices so I can shred them (going back 10 years)
[14:55] <tinwood_swap> jamespage, so many files deleted! :)
[14:55] <jamespage> tinwood_swap: charmhelpers gets consumed via wheelhouse.txt so no need to hold the synced copy...
[14:56] <tinwood_swap> yeah, and the review looks *huge* :)
[14:59] <magicaltrout> your life is so rock and roll tinwood_swap
[14:59] <magicaltrout> \o/
[14:59] <skayskay> stub: hi, I notice the snap-layer checks the version during install
[14:59]  * tinwood_swap smiles
[15:00] <skayskay> stub: I think juju 2.1 should also be okay with resources, but it's checking for 2.0
[15:07] <cnf> what does a blue ball mean next to an application in the GUI ?
[15:08] <magicaltrout> it means your $hit is building okay
[15:08] <magicaltrout> https://jenkins.io/blog/2012/03/13/why-does-jenkins-have-blue-balls/
[15:08] <magicaltrout> japanese traffic lights! :)
[15:09] <skayskay> stub: oh! I just checked the hookenv call. it's checking >= and I didn't realize that at first. all good
[15:09] <cnf> hmm
[15:09] <cnf>  either the GUI broke again
[15:09] <cnf> or my deploy is completely broken
[15:09] <cnf> i have no idea which one it is
[15:11] <cnf> no, it's not the gui
[15:12] <cnf> the openstack deploy is completely fucked
[15:12] <magicaltrout> they're the best types of deployment
[15:13] <cnf> no machines come up etc
[15:13] <cnf> but no units
[15:13] <cnf> none
[15:13] <cory_fu> jamespage: Instead of saying that you need assess_status to run "at the end of each hook context" it would be better to think of it as needing to run after any handler that might mutate the state. In that case, it would be better to be explicit and have those handlers end with a set_state('assess_status') and the assess_status handler remove that state when it has run.
[15:29] <cnf> hmm, what would cause me to end up with http://termbin.com/fyzz ?
[15:33] <magicaltrout> marcoceppi: i'm in DC the last week in March if you're around
[15:55] <marcoceppi> magicaltrout: isn't that the week of kubecon berlin?
[15:55] <magicaltrout> duno i'm not hip enough for such events
[15:55] <magicaltrout> yeah seems so
[15:55] <magicaltrout> oh well
[15:56] <magicaltrout> I'll just swing by The Donald instead then
[15:56] <magicaltrout> see if he wants a round of golf
[15:57] <jamespage> cory_fu: yeah thats an approach
[16:12] <cmagina> huh, so with juju 2.1.0 for xenial on arm64, action-get of an integer of size 1000000, results in a scientific notation return: 1e+06 while 1000 returns 1000. is that expected behavior?
[16:12] <marcoceppi> cmagina: this has been a problem for quite a while
[16:13] <marcoceppi> cmagina: use --string-args when running an action to make sure it doesn't reduce down
[16:13] <cmagina> marcoceppi: ok, thanks. not sure why i hadn't seen it before
[16:14] <marcoceppi> cmagina: let me see if I can find you the bug
[16:48] <marcoceppi> stub: thanks
[18:29] <stormmore> o/ Juju world