=== natefinch-afk is now known as natefinch
=== dooferlad_ is now known as dooferlad
=== scuttle|afk is now known as scuttlemonkey
=== scuttlemonkey is now known as scuttle|afk
[12:58] <marcoceppi> hey cory_fu
[12:59] <marcoceppi> so I know we talked about charms.tool for core.hookenv naming. What do you think about charms.model instead?
[13:00] <marcoceppi> charms.model.log, charms.model.relation_id, charms.model.config
[13:15] <cory_fu> marcoceppi: I like that much better
[13:15] <tvansteenburgh> marcoceppi: i like charms.unit better than charms.model
[13:18] <cory_fu> tvansteenburgh: unit is ok with log, but doesn't make as much sense as model for thinks like relations, config, leadership, etc
[13:19] <cory_fu> kjackal: Hey, do you have the full unit log for that plugin instance, by chance?
[13:19] <tvansteenburgh> true i guess. i was thinking of it in terms of "this operates in the context of a single unit"
[13:19] <marcoceppi> tvansteenburgh: I might keep tool for things like log
[13:19] <kjackal> cory_fu: let me check
[13:20] <cory_fu> kjackal: Also, what arch did you run this on?  I think the lzo test might need a skipIf for arch, since it's not supported everywheree
[13:21] <kjackal> cory_fu: I do not have the full logs. I am sorry. Arch, its x86_64
[13:21] <cory_fu> Though I guess the only place it's missing right now is aarch64, and I doubt you ran the tests on that
[13:22] <kjackal> I would like a walkthough the test
[13:23] <kjackal> I am not sure why we expect those messages. For example we ask two slaves to upgrade and in the status messages we expect only one to report spec missmatch
[13:23] <kjackal> cory_fu, there is always the chance I am reading this the wrong way
[13:23] <marcoceppi> maybe charms.model.service.config charms.model.unit.log charms.model.action charms.model.relation* ? cory_fu tvansteenburgh
[13:24]  * marcoceppi will play around with it a bit
[13:24] <cory_fu> kjackal: Yes, I wanted to confirm that if the admin forgets to upgrade a unit, the status message will let them know
[13:24] <tvansteenburgh> marcoceppi: i like that a lot
[13:25] <cory_fu> marcoceppi: Yeah, me too
[14:19] <aisrael> tvansteenburgh: bundletester isn't juju 2 compatible yet, right?
[14:19] <tvansteenburgh> aisrael: it is
[14:20] <aisrael> tvansteenburgh: latest in pip?
[14:20] <tvansteenburgh> aisrael: yeah. you also need the juju2 versions of deployer and jujuclient, one sec
[14:21] <tvansteenburgh> aisrael: well you can install those from tips in launchpad if you want. if you want a ppa instead lmk
[14:23] <marcoceppi> tvansteenburgh: eta on landing the last few patches so we can just release those?
[14:23] <tvansteenburgh> marcoceppi: they need reviews
[14:23] <marcoceppi> tvansteenburgh: link?
[14:24] <aisrael> tvansteenburgh: a ppa would be great, as long as that's no more work for you
[14:24] <tvansteenburgh> marcoceppi: https://bugs.launchpad.net/juju-deployer/+bug/1575863 https://bugs.launchpad.net/juju-deployer/+bug/1576519
[14:24] <mup> Bug #1575863: .deployer-store-cache relies on ~/.juju <juju-deployer:Fix Committed by tvansteenburgh> <https://launchpad.net/bugs/1575863>
[14:24] <mup> Bug #1576519: Not able to deploy a local charm <juju-deployer:Fix Committed by tvansteenburgh> <https://launchpad.net/bugs/1576519>
[14:25] <tvansteenburgh> aisrael: ppa:ahasenack/python-jujuclient and ppa:ahasenack/juju-deployer-daily
[14:27] <aisrael> tvansteenburgh: ta!
=== scuttle|afk is now known as scuttlemonkey
[14:47] <aisrael> stub: Have you tested your cassandra test changes with juju 2? Specifically, it seems like juju-deployer-wrapper.py isn't fully compatible.
=== med_ is now known as Guest82506
=== Guest82506 is now known as medberry
=== medberry is now known as med_
[16:17] <lazyPower> thedac beisner - question for you: What is the best way to make changes to python configs? like dashboard settings.py, where I need to add value to the installed apps array... do we expose any of this for ISV's to tap into?
[16:19] <thedac> lazyPower: for openstack-dashboard you want to update the local_settings.py template which should override settings.py
[16:19] <lazyPower> thedac - pointer to where i can find that? (sorry!)
[16:20] <thedac> lazyPower:  https://github.com/openstack/charm-openstack-dashboard/blob/master/templates/mitaka/local_settings.py
[16:23] <lazyPower> thedac - so for nexenta's case, they need to add a subordinate to configure this? or are there existing relations/amenities to do so for them?   this isn't as straight forward as the cinder plugin stuff i'm afraid
[16:24] <thedac> lazyPower: there is a dashboard-plugin subordinate relationship with openstack-dashboard which is what you will want. I am trying to find you an example
[16:24] <pmatulis> is there a way to see available charm-tools subcommands while in plugin mode? i.e. `juju charm ...`
[16:24] <lazyPower> perfect, thats enough to get us started. Thanks thedac!  If you do fish up the example, i'd appreciate it :)
[16:25] <marcoceppi> pmatulis: charm help plugins ?
[16:25] <thedac> ok
[16:25] <marcoceppi> pmatulis: why do you care about plugins specifically?
[16:27] <thedac> jamespage: gnuoy: do you know of any examples of subordinates to opentack-dashbaord that use the dashboard-plugin relationship?
[16:27] <pmatulis> marcoceppi, 'charm help plugins' doesn't give me anything. i'm reviewing existing docs. currently it says available commands can be discovered with `juju charm`
[16:29] <thedac> lazyPower: looks like Nexta already has a charm with that relation. https://jujucharms.com/u/anton-skriptsov/dashboard-nexentaedge/trusty/0
[16:30] <thedac> https://api.jujucharms.com/charmstore/v5/~anton-skriptsov/trusty/dashboard-nexentaedge-0/archive/metadata.yaml
[16:30] <lazyPower> yeah, i'm bringing this up with him now.
[16:30] <thedac> coolio
[16:30] <lazyPower> do you have a moment to run support with me thedac?
[16:30] <lazyPower> it would be helpful to have an openstacker wingman this with me
[16:31] <thedac> Sure
[16:32] <marcoceppi> pmatulis: no
[16:33] <marcoceppi> pmatulis: where are you looking at this? we re-wrote the entire charm-tools guide already
[16:33] <gnuoy> thedac, isn't there a juju gui subordinate that uses it?
[16:33] <thedac> gnuoy: thanks. I look
[16:35] <thedac> s/I/I'll
[16:35] <gnuoy> thedac, looks like you can search the charm store by relation https://jujucharms.com/requires/dashboard-plugin
[16:36] <thedac> ok, that is the only one I found already. :)
[16:36] <thedac> gnuoy: thanks
[16:44] <pmatulis> marcoceppi, should this page just be deleted then? https://jujucharms.com/docs/devel/juju-offline-charms
=== freyes_ is now known as freyes__
[16:53] <marcoceppi> pmatulis: not really, charm pull is the new command
[16:54] <marcoceppi> and charm pull-source
[17:02] <pmatulis> marcoceppi, i see 'pull-source' only. anyway, is the juju plugin mode depracated then?
=== freyes__ is now known as freyes
[17:04] <rick_h_> pmatulis: yes, it's now only through the charm command itself
[17:05] <pmatulis> rick_h_, thank you
[17:06] <marcoceppi> pmatulis: you need the latest charm command
[17:11] <pmatulis> marcoceppi, meaning? is there a ppa?
[17:12] <pmatulis> developer-getting-started doesn't mention one
[17:12] <marcoceppi> pmatulis: it's in xenial, or in ppa:juju/stable for trusty https://jujucharms.com/docs/devel/tools-charm-tools
[17:12] <pmatulis> marcoceppi, perfect, i'm on xenial
[17:12] <marcoceppi> pmatulis: sudo apt install charm then
[17:12] <pmatulis> ah, not charm-tools ?
[17:13] <marcoceppi> pmatulis: both
[17:13] <marcoceppi> http://marcoceppi.com/2016/04/charm-2-point-oh/
[17:13] <pmatulis> interesting. maybe update the above page? or is that not for public consumption?
[17:14] <pmatulis> ok, looks like 'charm' is a dep of 'charm-tools'
[17:15] <wolsen> marcoceppi, fyi I have a mongodb charm for xenial (with minimal changes to work + get amulet passing) here - https://code.launchpad.net/~billy-olsen/charms/xenial/mongodb/lp1513094 , where do I target an MP at? since the xenial series for the charm doesn't exist yet
[17:16] <marcoceppi> wolsen: it's a new charm review
[17:16] <pmatulis> marcoceppi, also, any reason why this command takes ~8 seconds to complete? 'charm --help add'
[17:16] <wolsen> marcoceppi: ack
[17:16] <marcoceppi> pmatulis: it's faster to do charm add --help
[17:16] <marcoceppi> pmatulis: if you're going to overwrite that page with the auto help stuff you all do for juju charms could you not?
[17:19] <pmatulis> marcoceppi, the waiting time is the same for me. and i don't know what you mean with your second sentence
[17:20] <marcoceppi> pmatulis: it takes a few seconds because it has to load the plugins on each run, and you guys have a script that auto generates the reference page for juju commands, I'm request we not do the same for this charm-tools page
[17:25] <pmatulis> marcoceppi, oh, well the commands.md file is auto-generated but it only affects juju-core. anyway, we still need to explain stuff and we need to use commands here and there to do that. we also use commands in examples
[17:33] <tvansteenburgh> ahasenack: can you kick off a rebuild of python-jujuclient for your ppa?
[17:33] <ahasenack> tvansteenburgh: sure
[17:34] <ahasenack> tvansteenburgh: done
[17:34] <tvansteenburgh> ahasenack: thanks!
[17:34] <aisrael> Any thoughts on what's causing this? "update-alternatives: error: no alternatives for juju"
[17:34] <tvansteenburgh> aisrael: that's gone
[17:35] <tvansteenburgh> can't do it any more
[17:35] <tvansteenburgh> to switch to juju1, sudo apt install juju-1-default
[17:35] <tvansteenburgh> uninstall to switch back
[17:36] <aisrael> tvansteenburgh: Shoot. Ok. I'm reviewing a charm that's doing some juju 1-specific stuff. Have we switched the jenkins stuff to use 2.0 yet? I'm wondering if I should test on juju 1, or push for changes to the tests.
[17:37] <tvansteenburgh> aisrael: jenkins still using juju1
[17:38] <aisrael> tvansteenburgh: roger, I'll switch and test, and comment about future compatibility wrt tests. Any idea when we'd require 2.0 compat?
[17:38] <tvansteenburgh> aisrael: i defer to marcoceppi :)
[17:39] <marcoceppi> aisrael tvansteenburgh when 2.0 is released
[17:39] <aisrael> marcoceppi: tvansteenburgh ack, thanks!
[17:40] <aisrael> and no quickstart in xenial? boo
[17:40] <tvansteenburgh> juju deploy bundle.yaml
[17:40] <tvansteenburgh> no need for quickstart :)
[17:41] <tvansteenburgh> oh, juju1
[17:41] <marcoceppi> aisrael: no quickstart
[17:44] <lazyPower> drop it like its hot tvansteenburgh
[17:44] <lazyPower> gah i wasn't all the way at the bottom i throught you dropped the science about juju deploy
[17:44] <lazyPower> then i see there's no quickstart for juju-1 in xenial. d'oh
[17:48] <ahasenack> tvansteenburgh: I need to do a dummy commit to trigger a version change, or else the builds won't upload
[17:48] <ahasenack> this sometimes happens when a manual build is triggered, LP doesn't remember that
[17:49] <tvansteenburgh> ahasenack: i'm sure i can find something to improve in a trivial commit
[17:49] <ahasenack> tvansteenburgh: oh, ok. I was going to do it in the packaging branch, but if you have something trivial at hand, go for it
[17:52] <tvansteenburgh> ahasenack: oh, in the packaging branch. yeah that makes more sense, go for it.
[17:53] <ahasenack> ok
[17:53] <ahasenack> tvansteenburgh: buld requested
[17:54] <tvansteenburgh> ahasenack: thanks again
[18:01] <tvansteenburgh> ahasenack: how do the versions get updated for the juju-deployer and python-jujuclient builds? is that a manual step?
[18:02] <ahasenack> tvansteenburgh: yes. Since the recipe uses the revno, that's a free incrementing number we get, but the actual version has to be set in the debian/changelog file
[18:03] <ahasenack> so the revno is enough for us to get upgrades in the same version, but if ubuntu releases something with a new version, the ppa, even though having more recent code, won't upgrade that
[18:05] <ahasenack> tvansteenburgh: hm, deployed just failed to build
[18:05] <ahasenack> test errors
[18:05] <ahasenack> ERROR: test_multiple_connections (deployer.tests.test_guienv.TestGUIEnvironment)
[18:06] <ahasenack> ERROR: test_deploy_unqualified_url (deployer.tests.test_guienv.TestGUIEnvironment)
[18:06] <ahasenack> ERROR: test_deploy (deployer.tests.test_guienv.TestGUIEnvironment)
[18:06] <ahasenack> ERROR: test_connect (deployer.tests.test_guienv.TestGUIEnvironment)
[18:06] <ahasenack> and
[18:06] <ahasenack> ERROR: test_close (deployer.tests.test_guienv.TestGUIEnvironment)
[18:06] <ahasenack> all failed with OSError: [Errno 2] No such file or directory
[18:06] <plars> Hi, I'm trying to deploy to an lxc container on maas, and I've done this for many other units that are deployed, but all the others have been on trusty. The lxc host is trusty as well, but the new one I'm trying to deploy needs to be xenial. I never see the machine come up though, and I suspect I'm hitting a systemd related incompatibility with trying to do
[18:06] <plars> this:
[18:06] <ahasenack> that's when calling     ["juju", "--version"], log).split('.')[0])
[18:06] <plars> https://www.irccloud.com/pastebin/rciZj6wP/
[18:06] <ahasenack> xenial
[18:07] <plars> sorry ahasenack, didn't mean to interleave... thought you were finished :)
[18:07] <ahasenack> I guess we need to update the dependencies to use juju-1-default or get the right juju2 one
[18:07] <ahasenack> plars: no worries :)
[18:08] <ahasenack> plars: never seen that error, sorry
[18:09] <plars> So - 1. Am I right in assuming I cannot deploy lxc machines onto a trusty host? and 2. Does anyone know if I could simply upgrade to a xenial base for my lxc machines and deploy trusty *and* xenial lxc units to it?
[18:09] <plars> err... s/lxc machines/xenial lxc units/
[18:10] <pmatulis> marcoceppi, previously, there was a 'getall' tools command to grab all charms. how is that done now?
[18:11] <tvansteenburgh> ahasenack: i'll take a look
[18:12] <ahasenack> tvansteenburgh: I'll just update the deps, I bet there was no /usr/bin/juju
[18:12] <ahasenack> just the versioned ones
[18:12] <ahasenack> tvansteenburgh: do these tests work with juju-2? Do you know?
[18:12] <tvansteenburgh> ahasenack: they do, yes
[18:12] <ahasenack> ok, I'll put juju-2 in front then, so xenial uses juju2, and the rest will use juju1
[18:12] <tvansteenburgh> ahasenack: sounds good
[18:27] <pmatulis> marcoceppi, i tried 'charm pull wordpress ~/charms/' and the charm's files get put directly under ~/charms and not under ~/charms/wordpress . normal?
[18:33] <marcoceppi> pmatulis: I didn't write that, you could file a bug against https://github.com/juju/charmstore-client
[18:33] <lazyPower> that is however strange, as i've used charm-pull and it puts the code in a subdirectory named after teh charm
[18:33] <lazyPower> eg if i'm in /tmp and i run charm pull elasticsearch, it creates /tmp/elasticsearch and puts the charm there
[18:34] <lazyPower> pmatulis - ^   it really stripped the dir and spit out charm files in $JUJU_REPOSITORY (~/charms)?
[18:38] <pmatulis> lazyPower, but what you wrote is not what i did so i'm not sure why you say it's strange. i don't know how i can be clearer. why don't you try it?
[18:41] <lazyPower> oh, i missed the path at the end
[18:41] <lazyPower> my mistake
=== scuttlemonkey is now known as scuttle|afk
[19:28] <suchvenu> Hi
[19:28] <suchvenu> I am getting the following error in my debug-log
[19:28] <suchvenu> unit-ibm-db2-0[19719]: 2016-05-05 19:27:42 ERROR juju.worker.uniter.filter filter.go:137 tomb: dying unit-ibm-db2-0[19719]: 2016-05-05 19:27:42 WARNING juju.worker.dependency engine.go:304 failed to start "uniter" manifold worker: dependency not available unit-ibm-db2-0[19719]: 2016-05-05 19:27:45 ERROR juju.worker.uniter.filter filter.go:137 tomb: dying
[19:28] <suchvenu> How can I resolve this ?
[19:35] <lazyPower> suchvenu see this bug: https://bugs.launchpad.net/juju-core/+bug/1513667
[19:35] <mup> Bug #1513667: Better error messaging around uniter failure <juju-core:Triaged> <https://launchpad.net/bugs/1513667>
[19:39] <suchvenu> Hi lazyPower
[19:39] <suchvenu> You restart the juju machine daemon by running `sudo restart jujud-machine-0` from machine 0
[19:39] <suchvenu> Where should i run this from ?
[19:41] <suchvenu> machine 0 is local host, right ?
[19:44] <lazyPower> suchvenu - are you using the local provider?
[19:44] <suchvenu> yes
[19:45] <lazyPower> yeah but thats not the name of the service you need unfortunately. can you pastebin the output of initctl list | grep juju for me?
[19:46] <lazyPower> sorry, sudo initctl list | grep juju
[19:48] <suchvenu> sudo initctl list | grep juju juju-agent-charm-local start/running, process 9596 juju-db-charm-local start/running, process 9529 charm@islrpbeixv665:~$
[19:48] <suchvenu> http://pastebin.ubuntu.com/16245865/
[19:49] <lazyPower> restart both of those and if you could, let us know on the bug if it resolved the issue or if it gets better/worse/about-the-same?
[19:52] <suchvenu> Restarted both and now the debug-log is moving further, I don;t see the error now
[19:52] <suchvenu> However I see this status in Juju status
[19:53] <suchvenu> http://pastebin.ubuntu.com/16245919/
[19:55] <lazyPower> suchvenu - ok, sounds like the agent needs to be cycled on the db-2 unit. Its lost because it hasn't checked in with the controller in a specified time, is what i recall that meaning.
[19:56] <suchvenu> I am redeploying the service
[19:59] <suchvenu> lazyPower, why is this happening ?
[20:00] <lazyPower> suchvenu i'm not certain :(
[20:01] <lazyPower> suchvenu - the logs of that deployment would be helpful, and if we can capture any of the unit agent logs that are failing to start due to that uniter failure would be helpful.  so if it happens again, ping me and i can step you through capturing that. I haven't been able to reproduce that bug.
[20:04] <suchvenu> ok
[20:08] <jcastro> http://askubuntu.com/questions/766661/openstack-lxc-containers-missing-dns
[20:08] <jcastro> can anyone help with this one?
[20:08]  * jcastro glances over at beisner
[20:41] <bdx> whats going on everyone?
[20:41] <lazyPower> yo yo bdx
[20:41] <bdx> lazyPower: how can I generate/obtain tools for beta7?
[20:42] <lazyPower> bdx juju bootstrap --upload-tools doesn't work?
[20:42] <bdx> unfortunately not
[20:42] <lazyPower> hmm, not certain. I'm still on beta6 here.
[20:42] <lazyPower> thanks for the heads up that i need to recycle my env :)
[20:43] <bdx> ok, thanks. It could be another issue, I'm about to start debugging it now
[20:43] <bdx> yea, good luck!
[20:43] <lazyPower> oh hey bdx , not sure if you saw last week. hattip @ your contributions to the tls-layer. Skinnied up some code i had to write for swarm :)
[20:44] <bdx> nice!!!!
[22:02] <bdx> https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1578838
[22:02] <mup> Bug #1578838: Services not running that should be: mysql <percona-cluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1578838>