[03:24] <stub> marcoceppi: I vaguely recall issues around newer versions building platform specific extensions
[07:14] <godleon> Doesn't juju-gui supper xenial yet ?
[11:16] <jamespage> gnuoy, https://github.com/openstack-charmers/charm-specs/blob/master/specs/newton/approved/sriov-support.rst
[12:26] <axino> heh
[12:35] <bbaqar> Hey guys .. while deploying a node using juju with maas .. cloud-init gets stuck at add juju-br0 (/usr/bin/python2 /tmp/add-juju-bridge.py
[12:35] <bbaqar> any thoughts?
[12:42] <marcoceppi> bbaqar: that's odd, is this juju 1.25?
[13:01] <gnuoy> jamespage, did you in disable 'issues' in someway for openstack-charmers repos?
[13:04] <bbaqar> marcoceppi: yes 1.25.5
[13:04] <bbaqar> marcoceppi trusty
[13:05] <bbaqar> marcoceppi so i got past that issue. Now i have my nodes in pending state .. i can ssh into then with ubuntu@ip
[13:05] <bbaqar> marcoceppi: i can also ping the outside world from there
[13:05] <bbaqar> marcoceppi but no juju process is running ..
[13:05] <bbaqar> marcoceppi can i run the juju tools manually over there
[13:05] <marcoceppi> bbaqar: not really, cloud-init is responsible for getting tools setup, I don't know if that runs before or after bridge creation
[13:06] <bbaqar> marcoceppi i got past the bridge creation part .. cloud init has finished successfully
[13:06] <bbaqar> marcoceppi still state of nodes are pending
[13:07] <marcoceppi> bbaqar: is there an upstart job for juju* on the machines
[13:08] <bbaqar> marcoceppi: there is only juju-clean-shutdown.conf
[13:08] <marcoceppi> bbaqar: can you pastebin /var/log/cloud-init* logs?
[13:10] <bbaqar> marcoceppi its seams like a connectivity issue ..
[13:11] <bbaqar> let me sort that out
[13:15] <aisrael> TIL if you're disconnected from a debug-hooks session (like the ssh connection drops), you can re-run the debug-hooks command and it'll drop you right where you left off.
[13:16] <magicaltrout> the wonders of screen/tmux ;)
[13:21] <aisrael> yep! I've used screen a lot, but not so much tmux. It impresses me every time I do, though.
[13:21] <magicaltrout> every box I have, the first 2 things I install are Byobu and Mosh
[13:24] <SaMnCo> marcoceppi: hi
[13:25] <marcoceppi> cory_fu: SaMnCo is writing a bash layer but needs to connect to an interface layer. Is this how you would send data over to an interface layer? http://bazaar.launchpad.net/~ibmcharmers/charms/trusty/ibm-java/source/view/head:/reactive/ibm-java#L174
[13:25] <marcoceppi> relation_call ?
[13:25] <aisrael> magicaltrout: Ohh, I've never seen mosh before
[13:26] <magicaltrout> aisrael: i live in the sticks and also just for when I'm moving my laptop around, saves me having to reconnect 100 terminals
[13:26] <magicaltrout> saves me endless amounts of time
[13:26] <jamespage> gnuoy, not that I was aware of
[13:26] <aisrael> *nod* same here
[13:26] <cory_fu> marcoceppi, SaMnCo: Yep.  Obviously bash is a bit more limited in data types that you can pass, so it's good idea to keep the interface signatures down to simple strings.
[13:27] <gnuoy> jamespage, ok, strange. There is no 'issue' tab between 'cpde' and 'pull requests' on https://github.com/openstack-charmers/charms.openstack for example
[13:27] <marcoceppi> cory_fu SaMnCo is trying to do provide from http://bazaar.launchpad.net/~canonical-is-sa/charms/trusty/grafana/interface-grafana-source/view/head:/provides.py my guess is `relation_call --state {rel}.available provide "type" "port" "description"`
[13:28] <cory_fu> Yep
[13:29] <cory_fu> Replacing "{rel}" "type" "port" and "description", of course
[13:29] <jamespage> gnuoy, issues is turned off for that repo
[13:29] <SaMnCo> hmm that's cool I didn't know about that relation_call stuff
[13:29] <SaMnCo> I had seen it in the script, but didn't know how to use it
[13:30] <gnuoy> jamespage, oh , ok, I failed to find whetever turns issues on and off
[13:30] <jamespage> gnuoy, hit "settings"
[13:30] <jamespage> for the repo itself, not the org...
[13:30] <cory_fu> SaMnCo: Documentation is here: https://pythonhosted.org/charms.reactive/charms.reactive.relations.html#charms.reactive.relations.relation_call but it ought to also be mentioned in the jujucharms.com/docs if it isn't
[13:30] <cory_fu> Also, that doc there is rather lacking as well
[13:31] <gnuoy> jamespage, I did that and somehow failed to see  the "Issues " radio button thats fron and center. sorry for the noise.
[13:31] <gnuoy> * front
[13:40] <lazyPower> godleon - it does, if you're using juju 2.0 beta7 or > it ships with the controller. You can verify this by typing in `juju gui` after you've bootstrapped your cloud.
[13:42] <icey> can somebody look at bumping the c-h version in pip? also, is there any chance to get that moving forward more regularly?
[13:46] <marcoceppi> icey: we're looking to kill charm-helpers, what from it are you using?
[13:48] <Spads> hm, it has some useful functions for idempotent operations on a system
[13:48] <icey> marcoceppi: a lot of the contrib stuff, hookenv stuff
[13:48] <Spads> have those been replaced?
[13:49] <marcoceppi> icey Spads: we're working on pulling all the charm specific bits out to a new concise library, everything in contrib we expect to have the people who wish to continue those pull them out to their own projects. The openstack charms do this today with a new library called charms.openstack
[13:52] <godleon> lazyPower: so it means I don't have to install juju gui additionally after bootstrapping controller on juju beta 7 or above?
[13:52] <lazyPower> correct
[13:52] <lazyPower> it ships with the controller
[13:53] <godleon> lazyPower: can I install any charm on controller just like I did in juju 1.25?
[13:53] <marcoceppi> godleon: if you want to, yes, but we still don't recommend it
[13:53] <lazyPower> i wouldn't recommend it :)
[13:53] <magicaltrout> lol `juju gui` opens in lynx
[13:53] <lazyPower> marcoceppi gmta
[13:54] <godleon> marcoceppi: oh? Why not?
[13:54] <marcoceppi> magicaltrout: you have to have a web-browser installed on that machine, or use the --no-browser flag ;)
[13:54] <lazyPower> hurray for launchy! its aggressively trying to get you to your gui
[13:54] <magicaltrout> clearly I do, its called lynx :P
[13:54] <lazyPower> via any browser necessary
[13:55] <marcoceppi> godleon: well, it's the controller node, it's the thing managing all of Juju, and some software may conflcit with that (mongodb charm as an example). If you want to co-locate services on the controller, you should put them in containers
[13:59] <godleon> marcoceppi: hmm, if I didn't remenber wrong, bootstrap node should be machine 0 in Juju 1.25, I just feel weird why machine 0 does not exist after bootatrapping controller in juju 2.0
[13:59] <marcoceppi> godleon: it does, it's just in a different model
[13:59] <marcoceppi> godleon: Juju 2.0 allows for multiple models to be created on a single controller, this cuts down on the number of bootstrap/controller nodes to run
[14:00] <marcoceppi> godleon: try `juju switch admin` then juju status to see the lonely machine 0 running
[14:00] <marcoceppi> `juju list-models` shows all the current models, and the `juju gui` has a drop down to switch/create more models
[14:03] <godleon> marcoceppi: oh y3s I just saw the term `model` in the juju document today.
[14:04] <godleon> marcoceppi: by the way, if I want to build an openstack with existing remote ceph, how can I do that?
[14:05] <godleon> Write a charm to do that is the only way?
[14:17] <lazyPower> godleon - i would ask that question the juju mailing list.  juju@lists.ubuntu.com - that way the openstackers can formulate a proper response. I dont have the expertise in openstack to answer that as is.
[14:20] <godleon> lazyPower: ok, got it. Sorry for that.
[14:20] <lazyPower> no worries! I just want to make sure you're finding answers to your questions :)
[14:20] <godleon> lazyPower: thanks! :)
[14:22] <godleon> Another question is.....will lxc/lxd support OCI standard?
[14:23] <lazyPower> what is the OCI standard?
[14:23] <gnuoy> jamespage, got a sec for https://github.com/openstack-charmers/charms.openstack/pull/4 ?
[14:24] <godleon> lazyPower: https://www.opencontainers.org
[14:24] <lazyPower> ah that i'm not sure of, probably another good question to post to the list
[14:24] <jrwren> open container init.  afaik the answer is "nope, we dont need it" as I heard in a number of presentations re:lxd
[14:25] <lazyPower> or jrwren seems to have the science
[14:25] <lazyPower> :)
[14:25] <lazyPower> jrwren hey did i see that there was a re-work merge of the plugin work that deprecated the MP for plugin caching?
[14:25] <jrwren> opencontainers and docker/kuber is all about process containers.   lxd is about system containers.
[14:25] <lazyPower> re: caching stuff for charm vs charm-tools
[14:25] <jrwren> lazyPower: yes, basically it is still slow, but ONLY for running help now, but we cleaned up a mess of code and now can move forward with further fixes.
[14:26] <lazyPower> oh nice
[14:26] <jrwren> lazyPower: so... we are still on it and in a better place to better support the other core modules (i'm not calling them plugins because they are not plugins.)
[14:27] <lazyPower> yeah, i think that was nomenclature used in the thread
[14:27] <lazyPower> well cool. \o/ i wont campaign on your PR anymore then :D
[14:27] <lazyPower> "Merge this change! Make charm great again"
[14:27] <jrwren> lazyPower: thanks.  It was a good discussion and we are in a much better place thanks to all the points raised.
[14:28] <godleon> jrwren: ok, then speaking of kube, what's the advantages of juju if compares to kube?
[14:28] <jrwren> lazyPower: on a completely diff topic. I started looking at beats + kibana and I'm wondering if you have any wisdom re: moving from old to new and setting up a dashboard.
[14:29] <lazyPower> well you'r ein luck if you want dashboards for packetbeat(still pending) or topbeat
[14:29] <godleon> jrwren: I am in a loss, too many tools now.
[14:29] <jrwren> godleon: I'm not knowledgable re: that, but others here are. My limited understanding is that juju makes a great tool for deploying a kubernetes infrastructure.  Kubes need to run somewhere and juju can help manage that somewhere.
[14:29] <lazyPower> i'm not so savvy at visualizations to build one for filebeat...
[14:29] <lazyPower> with that said, kibana just got a rev that adds config/actions to deploy the "beats" dashboard
[14:29] <lazyPower> so you get a prefabricated layout, its probably not 100% applicable for your wants, but its easy enough to edit
[14:30] <jrwren> lazyPower: newer than kibana 4.5.1? I just installed kibana yesterday!
[14:30] <lazyPower> ewll it just got revved on Monday
[14:30] <lazyPower> soooo, you got it
[14:30] <jrwren> lazyPower: link to post or news that tells me how? It wasn't obvious.
[14:30] <jamespage> gnuoy, pass unit tests and work for you in your charm?
[14:31] <lazyPower> uhhh jrwren
[14:31] <lazyPower> did you not read the readme?
[14:31] <jrwren> godleon: more here: https://insights.ubuntu.com/2015/07/30/juju-kubernetes-the-power-of-components/
[14:31] <lazyPower> https://jujucharms.com/kibana/  "Deploy / Add Dashboards"
[14:31] <jrwren> lazyPower: i probably did not read the readme. apt install doesn't display a readme :]
[14:31] <lazyPower> :O you didnt use the charm?
[14:31] <gnuoy> jamespage, yes and yes. fwiw the unit test reproduces the bug against the current codebase and is fixed by my mp
[14:32] <jrwren> lazyPower: WHOA!!! I wasn't using this charm. juju actions to load dashboards is AWESOME!
[14:32] <jrwren> lazyPower: well done!
[14:32] <lazyPower> now i feel bad for all the mean things i was saying about you over here just now ;)
[14:32] <jamespage> gnuoy, going to get travis setup on that repo for the moment
[14:32] <jamespage> gnuoy, feel blind with no automated CI
[14:32] <gnuoy> jamespage, makes sense
[14:34] <jrwren> lazyPower: lol. stop muttering under your breath ;]
[14:34] <lazyPower> and to be completely fair it was a joint effort between myself and cory_fu to land that
[14:34] <lazyPower> so props cory_fu we <3 you
[14:35] <lazyPower> godleon - i think its easiest to put it this way. Juju at its core is a way to model open source operations. Kubernetes is an application container orchestrator.  They are two wildly and vastly different tools and disciplines
[14:36] <lazyPower> godleon - for example, you can use juju to model a kubernetes deployment (the full infrastructure, including workloads you wish to deploy into k8s (needs citation)) however the same is not exactly true in reverse.
[14:38] <kjackal> Hey lazyPower, do you have a minute? Its regarding the the ELK stack bunlde that is in the review Q.
[14:38] <lazyPower> surely
[14:38] <lazyPower> whats up kjackal?
[14:39] <kjackal> The ELK bundle.yaml seems to be pointing to the containers namespace for logstash
[14:39] <lazyPower> chicken/egg problem of which lands first
[14:39] <kjackal> Did we promulgate logstsh?
[14:39] <lazyPower> i dont think we did, let me check
[14:39] <lazyPower> nope
[14:40] <lazyPower> https://jujucharms.com/u/containers/logstash/trusty/5  <- is the most recent revision, and it has not been promulgated yet.
[14:40] <kjackal> It is waiting for a review?
[14:41] <kjackal> it=logstash/trusty/
[14:41] <lazyPower> it should be....
[14:41] <lazyPower> it might have been reviewed and nack'd
[14:42] <lazyPower> i submit the entire belk stack at once
[14:42]  * lazyPower goes fishing for a bug
[14:43] <jamespage> gnuoy, https://github.com/openstack-charmers/charms.openstack/pull/5
[14:44] <gnuoy> jamespage, merged and thanks for #4
[14:44] <lazyPower> kjackal - hah! you reviewed it! https://bugs.launchpad.net/charms/+bug/1560167
[14:44] <mup> Bug #1560167: New Charm Proposal: Logstash <Juju Charms Collection:In Progress> <https://launchpad.net/bugs/1560167>
[14:46] <kjackal> lazyPower, awesome! So any comments I had seem to addressed
[14:46] <lazyPower> nope
[14:46] <lazyPower> i'm updating the layer real fast while you're "not looking"
[14:46] <lazyPower> :)
[14:47] <kjackal> :)
[14:48] <lazyPower> i take that back, i do see a merge here from you
[14:48] <lazyPower> so i think it just needs rebuilt and a re-push
[14:50] <kjackal> cool
[14:51] <cory_fu> lazyPower: What happened to bundletester in jujusolutions/charmbox:devel
[14:51] <lazyPower> cory_fu - i dont think it was reintroduced after a long hiatus - it jsut recently got a bump to add tims ppa and get the prereqs
[14:52] <lazyPower> so it should be ready to be re-added assuming i've got all the right things in place
[14:53] <cory_fu> I'm confused as to why it was removed.  I was working previously
[14:53] <lazyPower> it stopped working, and it was removed months ago
[14:54] <cory_fu> Ok, I see the bug now where it stopped working due to an upstream dep issue in charm-tools
[14:55] <lazyPower> cory_fu https://github.com/juju-solutions/charmbox/commit/79a5733a6a248c0e8f91bb3fdf8e616f4a4f612d
[14:55] <lazyPower> looks like that commit is the culprit
[14:56] <cory_fu> lazyPower: Yeah, I saw that.  I was just confused because I had been using it daily for a while (but clearly hadn't in some time), and kwmonroe kept trying to tell me that it had never worked.  :P
[14:56] <lazyPower> LOL
[14:56] <jcastro> lazyPower: do you intent to promulgate ~containers/beats-core at some point?
[14:56] <lazyPower> "this doesnt work"
[14:56] <lazyPower> "i use it all teh time"
[14:56] <lazyPower> jcastro - err, we dont promulgate bundles? is this new?!
[14:56] <lazyPower> can we do that now?!
[14:57] <lazyPower> kjackal - pushed at cs:~containers/trusty/logstash-6  - do you mind reviewing from that instead of me hacking in a bzr repo for the purpose of that bug?
[14:57] <jcastro> https://jujucharms.com/apache-processing-spark/
[14:57] <cory_fu> tvansteenburgh: Is the old RQ ingestion / update stopped?  The top item in Charm Reviews is a 404
[14:58] <jcastro> why wouldn't we promulgate bundles?
[14:58] <lazyPower> jcastro #TIL
[14:58] <lazyPower> so yeah, we can totally do that. the current beats-core bundle has been updated to deploy the latest on all teh charms and all the charms are pointed at promulgated revisions, so we should be g2g on that front, just need someone to flip the switch
[14:59] <ryebot> What is RQ?
[14:59] <lazyPower> ryebot Review Queue
[14:59] <cory_fu> ryebot: Review Queue.  http://review.juju.solutions/
[14:59] <ryebot> thanks
[15:00] <magicaltrout> the place you send stuff to sit for years ;)
[15:00] <lazyPower> sadtrombone.wav
[15:00] <Odd_Bloke> s/sit/mature like a fine wine/
[15:00] <lazyPower> rimshot.wav
[15:00] <magicaltrout> lol
[15:01] <tvansteenburgh> cory_fu: you'll need to ask marcoceppi, i can't ssh to it
[15:01] <magicaltrout> I've got to 44 days, what upsets me the most is we're going to release 3.9 shortly, so I'll have to yank it and submit a new one ;)
[15:01] <cory_fu> marcoceppi: Is the old RQ ingestion / update stopped?  The top item in Charm Reviews is a 404
[15:01] <cory_fu> :)
[15:03] <cory_fu> aisrael: You have two Cassandra RQ items locked; are you currently reviewing those?
[15:04] <aisrael> cory_fu: No, I'm not. I'll go unlock those
[15:04] <cory_fu> Ok
[15:04] <cory_fu> thanks
[15:07] <kjackal> hey lazyPower, the logstash charm says it is in  https://github.com/juju-solutions/layer-logstash is this accurate?
[15:08] <lazyPower> yessir
[15:08] <kjackal> I do not see any changes there after the 4th of April
[15:08] <kjackal> Awesome!
[15:08] <lazyPower> yep :) that was the last time it was touched. i can confirm
[15:43] <ryebot> What's the best way to dynamically add a file or files to a service unit? Or even better, if possible, add it/them to all the units of a service?
[15:44] <kjackal> Hey lazyPower, I am afraid we are going to need a new clean build of logstash before promulgating it
[15:44] <kjackal> kwmonroe spotted the bug that we fixed some days ago in the elasticsearch interface https://api.jujucharms.com/charmstore/v5/~containers/trusty/logstash-6/archive/hooks/relations/elasticsearch/requires.py
[15:45] <kjackal> We removed the broken hook bu the cs:~containers/trusty/logstash-6 still has it there
[15:46] <kjackal> there is no point in promulgating this version of logstash as it will break when it gets tested in te context of the bundle
[15:50] <jamespage> gnuoy, https://github.com/openstack-charmers/charms.openstack/pull/6
[15:55] <lazyPower> kjackal ah, thats good feedback
[15:55] <lazyPower> i think i have a stale interface in my path
[15:55] <kwmonroe> lazyPower: friendly reminder to charm build --no-local-layers
[15:55] <cory_fu> lazyPower: charm build --no-local-layers
[16:01] <lazyPower> kjackal kwmonroe - ok rev -7 was just published. can you give that a whirl and let me know?
[16:01] <kwmonroe> roger that
[16:08] <lazyPower> ryebot your PR reverting pinning pip landed yesterday right?
[16:08] <ryebot> lazyPower still under discussion: https://github.com/juju-solutions/layer-basic/pull/70
[16:11] <lazyPower> ryebot ta, i've poked it with a stick
[16:11]  * lazyPower now campaigns for ryebot - he has all the pips, all the best pips. 
[16:11] <ryebot> :D
[16:11] <ryebot> \o/
[16:12] <rick_h_> huge pips?
[16:12] <ryebot> You've never seen pips like this.
[16:12] <lazyPower> and small pips, dont be a discriminator
[16:13] <lazyPower> ryebot - is there a work around to this other than building from that mp? i'm failing left and right on a client deliverable due to this bug
[16:13] <lazyPower> and whats funny is it happened today, not yesterday *magic shrug*
[16:13] <ryebot> lazyPower: I haven't tried; the only thing I can think of is to make sure pip7.1.2 is installed on the host before installing the charm
[16:14] <lazyPower> nope, unpinning and progressing forward to the future you promised me
[16:14] <lazyPower> deliver me to the promised land
[16:14] <ryebot> hahaha
[16:14] <ryebot> I mean, I can just click the green button. :P
[16:15] <ryebot> You're the guy with the rubber stamp though
[16:19]  * marcoceppi narrows eyes at the mention of rubber and stamp
[16:19] <jamespage> gnuoy, cargonza: https://github.com/openstack-charmers/charm-specs/pull/1
[16:19] <lazyPower> ryebot DUDE how you gonna throw me under the bus like that?
[16:19] <nottrobin> is there any way to search for available layers?
[16:20] <ryebot> hahaha :D
[16:20] <marcoceppi> nottrobin: http://interface.juju.solutions
[16:20] <nottrobin> marcoceppi: nothing there for me
[16:20] <marcoceppi> nottrobin: http://interfaces.juju.solutions
[16:21] <jcastro> kwmonroe: I found a nitpick in the bundle
[16:21] <nottrobin> ah great thanks
[16:21] <jcastro> the charm for spark is named `apache-spark`
[16:21] <jcastro> in the bundle you named it just `spark`
[16:21] <jcastro> so in my mind I just went to jujucharms.com/spark
[16:22] <jcastro> which doesn't exist
[16:22] <nottrobin> marcoceppi: I see you wrote a django/gunicorn layer
[16:22] <jcastro> so I decided to search for "spark"
[16:22] <marcoceppi> I have
[16:22] <nottrobin> marcoceppi: I don't suppose there's a layer for simply gunicorn?
[16:23] <marcoceppi> nottrobin: probably not, well not yet at least ;)
[16:23] <nottrobin> marcoceppi: cool. I may have a crack at it
[16:24] <nottrobin> marcoceppi: the other layer I'd be interested in is a content-fetcher later, to grab and expand a tarball from a given URL
[16:24] <nottrobin> do you know if anything like that exists?
[16:24] <lazyPower> nottrobin oh! oh! oh! you may want to look into resources then!
[16:24] <lazyPower> no need for a layer, juju exposes this to you natively in juju 2.0+
[16:24] <nottrobin> yeah we were having a resources conversation a while ago
[16:25] <nottrobin> I don't think it'll help, as it currently exists
[16:25] <nottrobin> 'cos isn't it about pulling a specifically uploaded resource from the charm store?
[16:25] <nottrobin> I'm talking about a user-specified payload
[16:25] <nottrobin> lazyPower: ^
[16:25] <lazyPower> ah yeah, the store hates charms that define resources and doesn't provide them..
[16:25] <lazyPower> so when you go to publish it'll complain :(
[16:26] <nottrobin> yeah. what I'm trying to write is a charm which runs a specific *type* of app
[16:26] <nottrobin> but you provide the app
[16:27] <nottrobin> (wsgi)
[16:28] <gnuoy> jamespage, https://github.com/openstack-charmers/openstack-community/pull/8
[16:29] <marcoceppi> nottrobin lazyPower you can upload a dummy resources to the store
[16:30] <marcoceppi> then the user provide their resource either at deploy time, or later one
[16:30] <marcoceppi> on*
[16:30] <nottrobin> marcoceppi: I don't think what I want to do should be store-based
[16:30] <marcoceppi> nottrobin: you don't have to have resources in the store at all
[16:30] <marcoceppi> nottrobin: yhou can deploy resources for a charm from your local machine
[16:31] <nottrobin> marcoceppi: okay maybe that could work then. do you have an example of what the commands for that look like?
[16:32] <marcoceppi> nottrobin: mbruzek was documenting this, not sure where that is
[16:33] <mbruzek> nottrobin: marcoceppi: it is currently a PR waiting to be reviewed. If you are OK with the non-reviewed copy: https://github.com/mbruzek/docs/blob/abd31c0962d73efea76a1381a857a279e27d384d/src/en/developer-resources.md
[16:34] <nottrobin> mbruzek: assuming the commands more-or-less work, absolutely
[16:34] <jamespage> gnuoy, merged
[16:34] <gnuoy> jamespage, thanks
[16:34] <jamespage> I'd still love to see some cookie cutter or charm create templates for these things...
[16:34] <mbruzek> nottrobin: The commands to the Juju Charm Store are not working until juju-2.0 beta 8.
[16:35] <mbruzek> nottrobin: but you can upload a resource to your controller using juju 2.0 beta 7 which is what I used
[16:35] <nottrobin> sounds good
[16:35] <nottrobin> I'll have a play
[16:35] <nottrobin> mbruzek: thanks
[16:35] <gnuoy> jamespage, yes, that'd be better, but in the meantime...
[16:35] <jamespage> yah gotcha
[16:35] <nottrobin> is there an expected timeline for juju 2.0 to be stable?
[16:35] <nottrobin>  /released
[16:36] <mbruzek> nottrobin: very soon
[16:37] <bryan_att> hi, I'm looking for help on a Charm for the OpenStack Congress service. Working w/Narinder on #opnfv-joid,  going here also for support. Current error I have in deploying this charm is "hook failed: "install". Not sure how to debug that - no clear signs in the bootstrap log, pastebin'ed on #opnfv-joid.
[16:38] <gnuoy> bryan_att, hi o/
[16:38] <bryan_att> gnuoy: hi!
[16:40] <gnuoy> bryan_att, what does the /var/log/juju/unit-congress*log say (on congress/0) ?
[16:41] <bryan_att> gnuoy: is that log on the bootstrap node or on the target node?
[16:41] <gnuoy> bryan_att, I've updated the guidelines at https://github.com/openstack-charmers/openstack-community/blob/master/openstack-api-charm-creation-guide.md fwiw
[16:41] <gnuoy> bryan_att, the target node
[16:41] <bryan_att> gnuoy: ok, that part was not clear. Let me look.
[16:43] <bryan_att> gnuoy: I tried "juju ssh ubuntu@congress/0" - not found
[16:43] <gnuoy> bryan_att, drop the ubuntu@ bit
[16:43] <bryan_att> gnuoy: not found
[16:44] <gnuoy> bryan_att, what does "juju status congress" give?
[16:44] <bryan_att> https://www.irccloud.com/pastebin/J8qyCWkd/gnuoy%3A%20here%20you%20go
[16:45] <gnuoy> bryan_att, ok, my bad, I assumed you were on unit 0 but you're on 3, so should be "juju ssh ocngress/3"
[16:46] <bryan_att> gnuoy: ok, let me look
[16:47] <bryan_att> gnuoy: here's part of the log https://www.irccloud.com/pastebin/MRzFi9i8/
[16:48] <bryan_att> gnuoy: seems the same as what is logged on the bootstrap node
[16:48] <gnuoy> bryan_att, look like the charm has a mix of tabs and spaces in it
[16:48] <bryan_att> gnuoy: I saw that but it was not an error level issue
[16:49] <bryan_att> gnuoy: picky parsers... if that's an error driver I can go fix it. but is that really a potential failure cause?
[16:49] <gnuoy> bryan_att, I think it is
[16:49] <bryan_att> gnuoy: ok let me check it and fix
[16:50] <gnuoy> bryan_att, we did rejig the layers yesterday so if you haven't already it'd be worth going over that guide I mentioned again.
[16:51] <bryan_att> gnuoy: ok, let me do that also. There were a number of things I had to change in the instructions btw
[16:51] <bryan_att> gnuoy: I can pass them on here when I go thru it again if that's the best way
[16:52] <bryan_att> gnuoy: or as issues in github - your choice
[16:54] <gnuoy> bryan_att, git hub issues would be great
[16:54] <gnuoy> bryan_att, I have a branch to go with the docs https://github.com/gnuoy/charm-congress
[16:55] <gnuoy> bryan_att, thats the src of the congress charm so it should just be a case of building and deploying that
[16:55] <bryan_att> gnuoy: ok, I thought I had to build it from scratch again based upon your guide
[16:56] <bryan_att> gnuoy: the folder structure looks to have changed significantly so I was going to start over
[16:56] <gnuoy> bryan_att, you can just clone that git hub branch, not sure if you've added anythin thats not in the guide yet?
[16:57] <gnuoy> bryan_att, only difference is the source charm directory was renamed from "charm" to "src"
[16:57] <gnuoy> thats the only directory structure difference I mean
[16:59] <bryan_att> gnuoy: yes, I saw that. one point to clarify before I fork and update the charm - I have to do this for OPNFV under the Apache 2.0 license and that needs to be explicit in the charm files, (c) AT&T etc... is that OK for you? I assume all the charm files can carry comments for licensing etc.
[17:00] <bryan_att> gnuoy: if not I will continue by developing the one I have started with based upon your guide
[17:01] <gnuoy> bryan_att, yes, that's fine
[17:02] <bryan_att> gnuoy: ok, let me work on it
[17:24] <bryan_att> gnuoy: I can't seem to get the command "juju deploy <full path>/build/congress" from the guide to work. What's in the "build" folder is "deps" and "trusty".
[17:24] <gnuoy> bryan_att, are you using juju 2.0 ?
[17:24] <bryan_att> gnuoy: not sure how do I tell
[17:25] <gnuoy> juju --version
[17:25] <bryan_att> gnuoy: 1.25.5-trusty-amd64
[17:25] <gnuoy> ok, so...
[17:25] <gnuoy> cd build
[17:25] <gnuoy> juju deploy local:trusty/congress
[17:26] <gnuoy> should work, although you'll need to specify a cloud archive if its trusty
[17:26] <bryan_att> gnuoy: ok, that looks more like the command I used in the last attempt
[17:27] <gnuoy> bryan_att, http://paste.ubuntu.com/16712437/
[17:27] <gnuoy> bryan_att, I'm not sure that the congress packages are actually availabe on trusty tbh
[17:28] <bryan_att> gnuoy: ok, I'm not sure because I'm just trying to get a charm developed. So far I have been building it from github directly.
[17:30] <bryan_att> gnuoy: I'm trying to remove the existing congress service from the last attempt. But "juju remove-service congress" is taking a while...
[17:36] <bryan_att> gnuoy: I can't try the new charm until the old congress service is removed, but the command doesn't seem to be removing it (no error response or log entries related to the action). What should I do?
[17:39] <gnuoy> bryan_att, does "juju status congress" show its in an error state?
[17:39] <bryan_att> gnuoy: yes
[17:39] <gnuoy> bryan_att, "juju resolved congress/N" where N is the unit number
[17:40] <gnuoy> bryan_att, you might have to issue that a few time till its gone
[17:40] <gnuoy> bryan_att, can you hangon before doing the redeploy ? I'm adding deploy from src atm
[17:40] <bryan_att> gnuoy: ok, let me try that
[17:42] <bryan_att> gnuoy: ok, let me know
[17:54] <ryebot> cynerva and I are wondering - how do subordinate charms work with multiple series?
[17:55] <ryebot> or do we just enforce a single series?
[18:06] <bbaqar> marcoceppi: can you look at this cloud-init log http://paste.ubuntu.com/16713677/ and see if there is anything wrong .. node is still in pending state
[18:10] <bbaqar> anyone else
[18:17] <gnuoy> bryan_att, sorry, I've run out of day. I'll try and push an update up in  the morning
[18:17] <bryan_att> gnuoy: np, I'll look for it
[18:17] <bryan_att> gnuoy: thanks for your help!
[18:21] <mpjetta> I changed some config and got 2x units stuck in “(config-changed) SSH key exchange” for some reason. any way to retry or debug what it is doing ?
[18:30] <lazyPower> ryebot - you cannot mix/match subs across series
[18:30] <lazyPower> juju wont let you, it will tell you the principal service and the subordinate must match series
[18:30] <ryebot> +1 thanks lazyPower
[18:36] <bbaqar_> Hey guys .. any idea why cloud-init would stay stuck for a long time on this /usr/bin/python2 /tmp/add-juju-bridge.py --bridge-name=juju-br0 --interface-to-bridge=eth2 --one-time-backup --activate /etc/network/interfaces
[18:39] <bbaqar_> and after a while i loose connectivity to the node
[18:45] <aisrael> In a reactive charm, how do you access code from the included layers? i.e., I include the storage layer, and want to call a method within it from my charm, but just `import storage` fails
[18:47] <lazyPower> aisrael - unless its shipping alib, thats difficult. i dont think you can import reactive modules in/from one another.
[18:47] <lazyPower> this was a problem statement raised by stub with the apt layer a while back
[18:48] <aisrael> lazyPower: Hm. It'd be a really useful feature to have, though. I'll open a bug for it, unless there's already one
[18:49] <aisrael> lazyPower: layer namespaces might be what I'm looking for
[18:50] <lazyPower> Makes sense
[18:50] <lazyPower> the ability to call the module by name, ergo: from storage import format_and_set_fire as cheers
[18:50] <aisrael> lazyPower: exactly
[18:50] <lazyPower> storage being reactive/storage.py
[18:51] <aisrael> Adding it to storage now
[19:23] <kwmonroe> cory_fu: i'm thinking we should make zeppelin standalone (vs spark subordinate).  you ok if i poke around for a rabbit down there?
[19:24] <cory_fu> Yeah, as long as it's feasible (i.e., Zeppelin doesn't have some hard lib dependencies on Spark or otherwise have to be co-located) it seems like the better topology
[19:25] <kwmonroe> yeah cory_fu, it's easier if it's on spark (because it can look at SPARK_HOME), but i think it would be better to discover the relevant info from the spark relation.  it's not clear to me if the zepp binaries include enough spark jars though.  i'll have to see what those debs look like.
[19:25] <cory_fu> Presumably Zeppelin would then be able to work without Spark entirely?
[19:26] <cory_fu> (Using some other backend)
[19:27] <kwmonroe> yup cory_fu.. it's good as a general notebook (%md + %sh), but also has %hive and plenty of other interpreters that i think could be useful without spark... of course spark is super useful too (which is why we made it a sub in the first place)
[19:27] <cory_fu> Yeah, +1, let's break it out
[19:28] <magicaltrout> there's a bunch more always in motion on the mailing list as well
[19:28] <magicaltrout> especially as its just become a TLP
[19:41] <kwmonroe> what's this magicaltrout?  zepp is out of the incubator?
[19:42] <kwmonroe> cory_fu: this is redundant, right?  basic: packages: would do the same thing? https://github.com/juju-solutions/layer-apache-bigtop-base/blob/master/layer.yaml#L58
[19:43] <cory_fu> Yess
[19:43] <cory_fu> That was a copypasta from the dist.yaml
[19:45] <magicaltrout> yeah kwmonroe it graduated a couple of weeks ago
[19:46] <kwmonroe> neat
[19:48] <kwmonroe> dupey dupey here too cory_fu: https://github.com/juju-solutions/layer-hadoop-client/blob/master/layer.yaml#L4
[19:49] <cory_fu> kwmonroe: Yep.  Well, hadoop-client and bigtop-base both originally copypasta'd it from hadoop_base, which copypasta'd it from dist.yaml.
[19:49] <cory_fu> So it's in layer-apache-hadoop-base as well
[19:49] <kwmonroe> mmmmm.  pasta.
[19:51] <cory_fu> kwmonroe: Does the order that we apply the patches in bigtop-base matter?
[19:52] <cory_fu> I guess it might
[19:52] <kwmonroe> depends on how tolerant patch is to fuzz.  i can't remember if those built on top of each other (meaning patch-1 adds 10 lines, patch-2 starts 10 lines down), or if they were independent.
[19:53] <kwmonroe> ear regardless, i'm like 99% sure the default patch invocation will find the blocks and do the right thing.  for sure we dont fuzz=0
[20:05] <cory_fu> kwmonroe: https://github.com/juju-solutions/layer-apache-bigtop-base/pull/12
[20:24] <bbaqar_> hey guys can i edit the juju cloud-init script ?
[20:30] <magicaltrout> client asks for bespoke work to be done, and gives us a windows box to test on. We validate bespoke work on windows and hand it over. Client then tries to install bespoke work on Linux. We rework bespoke work to work on Linux. Client then says stuff isn't working, and I find out they're back to using windows
[20:31] <magicaltrout> if lazyPower wasn't around, I'd be swearing, a lot
[20:31]  * lazyPower eyes narrow as he reads backscroll
[20:31] <lazyPower> in this instance, i'll allow it magicaltrout - so long as it follows the ubuntu CoC
[20:31] <magicaltrout> hehe
[20:31] <lazyPower> because yah, thats poopy
[20:32] <magicaltrout> i dunno, clients suck
[20:32]  * lazyPower sings the hot garbage song
[20:32] <magicaltrout> technically its java, so you know, it shouldn't matter, but you tend to test on the target OS and then figure out the nuances later
[20:33] <lazyPower> yeah, mbruzek i mean java is supposed to run everywhere
[20:33] <mbruzek> It does
[20:33] <lazyPower> but thats the rub, it was all marketing \o/ if your devs dont code it to be platform independent
[20:34] <lazyPower> i used to be over this cloud based call center platform i inhereted by the name of five9, they would get really irate when i called in for support and was on linux.
[20:35] <magicaltrout> the only java issues we face cross platform are like this one, filesystem access based stuff
[20:35] <jrwren> bbaqar_: I think I have an open feature request for that, but no, currently you cannot.
[20:35] <magicaltrout> with paths, separators, browsers putting in different separators etc
[20:35] <magicaltrout> absolute killer
[20:35] <lazyPower> critical path stuff
[20:35] <lazyPower> yeah
[20:35] <lazyPower> you'd htink there would be an abstraction for that by now, i mean its only been what? 3 decades?
[20:36] <lazyPower> even *python* has that
[20:36]  * lazyPower hides
[20:36] <magicaltrout> hehe
[20:37] <jrwren> write once. debug everywhere.
[20:38] <magicaltrout> technically c:/ on windows is fine
[20:38] <magicaltrout>  / on linux is fine
[20:38] <cory_fu> kwmonroe: Not saying we shouldn't test that PR, but the patch order should be the same due to sorting by ticket number (in the filename)
[20:38] <magicaltrout> but.. browsers still try and do the right thing and do c:\ ....
[20:38] <magicaltrout> fail
[20:38] <magicaltrout> users are worse though
[20:38] <magicaltrout> they fill in all their variables incorrectly, every time ;)
[20:39] <magicaltrout> never trust a user to fill a variable
[20:39] <cory_fu> magicaltrout: Just use os.pathsep and os.path.join and you should be fine.  ;)
[20:39] <jrwren> bbaqar_: i'm wrong. I never created a bug. if you want to, I will +1 it ;]
[20:40] <magicaltrout> now funny you say that, we had more issues with paths by using the java filesep variable, than just hardcoding everything to /
[20:40] <magicaltrout> because then you'd end up with weird stuff like c:\myfolder/path/to/my file
[20:40] <magicaltrout> at which point I wanted to cry
[20:41] <magicaltrout> anyhow, I digress. The real point is that clients suck.
[20:46] <bbaqar_> jrwren: i ll definitely open one but is there anywhere i can get the script from?
[20:51] <jrwren> bbaqar_: once a machien is deployed you can always get it from /var/lib/cloud/instance/cloud-config.txt  you'll notice its very small and basic for juju managed machines.
[20:52] <bbaqar_> jrwren: cool .. let me check
[21:42] <x58> lazyPower: Hey, this is Bert. I'm working mattrae
[21:42] <x58> with *
[21:44] <x58> lazyPower: One of the things I've noticed with etcd and static clustering is that you have to bring up the followers one at a time. I have noticed with the old etcd charm, and the new one, that the followers will both attempt to cluster at the same time, which goes horribly wrong because both do member add, and things go boom.
[21:46] <marcoceppi> x58: I think lazyPower has left for the day
[21:52] <x58> marcoceppi: He'll get it when he gets back then :-)
[21:52] <marcoceppi> x58: absolutely