[09:23] <gnuoy> jamespage, coreycb, fyi https://github.com/juju/charm-tools/issues/69
[09:53] <jamespage> gnuoy, urgh
[09:56] <gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/+source/interface-rabbitmq/+git/interface-rabbitmq/+merge/279743 does that address your concerns?
[09:58] <jamespage> gnuoy, yes
[10:50] <jamespage> gnuoy, newer odl versions appear to have a way to determine whether they are up or not
[10:51] <jamespage> https://github.com/openstack/networking-odl/blob/master/devstack/odl-releases/lithium-snapshot-0.3.2#L28
[10:51] <gnuoy> \o/
[10:51] <gnuoy> Christmas has come early
[12:44] <gnuoy> jamespage, why wouldn't I put every possible key the service I'm joining with could throw back at me in auto_accessors ?
[12:44] <gnuoy> "you would" being the reply I'm hoping for
[12:47] <jamespage> probably
[12:47] <jamespage> gnuoy, I'd put auto_accessors in for any key that will be eventually consistent across all remote units
[12:48] <gnuoy> jamespage, so we should remove 'private-address' then I guess
[12:51] <jamespage> gnuoy, yeah I guess so
[12:51] <jamespage> gnuoy, and pick on from the list of hosts for 'host' in the adapter
[15:24] <gnuoy> jamespage, got a sec for https://code.launchpad.net/~gnuoy/charms/trusty/openvswitch-odl/duplicate-controllers/+merge/279251 ?
[15:29] <jamespage> gnuoy, I'll peek in a bit
[16:39] <lazypower> aisrael marcoceppi tvansteenburgh - http://paste.ubuntu.com/13792602/ i appear to have whiffed on making my module extension. Can I bother one of you for help debugging this?
[16:40] <aisrael> lazypower: the magic is in charms/__init__.py
[16:40] <lazypower> aisrael https://github.com/juju-solutions/charms.docker/blob/master/charms/__init__.py
[16:40] <aisrael> and then your code in charms/docker/* will be properly namespaced
[16:42] <aisrael> That's a bit odd, then. cory_fu might be better suited to help with this. He came up with the original pattern (I think)
[16:42] <lazypower> aisrael: i'm not entirely convinced, that I have some hinky package setup in this module
[16:42] <lazypower> fair, ta
[16:42] <marcoceppi> lazypower: link to your setup.py?
[16:43] <lazypower> marcoceppi https://github.com/juju-solutions/charms.docker/blob/master/setup.py
[16:43] <marcoceppi> lazypower: you're missing a packages declaration
[16:44] <lazypower> Ah!
[16:44] <lazypower> thanks :)
[16:50] <lazypower> marcoceppi: I need to declare both 'charms' and 'charms.docker' corect?
[16:50] <marcoceppi> lazypower: im not sure. it seems wrong, tbh
[16:51] <lazypower> Declaring both packages in the setup.yaml?
[16:51] <lazypower> er .py
[16:51] <marcoceppi> lazypower: yes, seems wrong to me
[16:52] <marcoceppi> does it work with just charms.docker as the package?
[16:52] <lazypower> yep
[16:52] <lazypower> i just veriified in a venv
[16:52] <marcoceppi> you found your answer :)
[16:57] <mbruzek> lazypower: and marcoceppi is this package declaration a pip thing, or a pypi thing?
[16:57] <lazypower> Pip thing
[16:57] <marcoceppi> It's a python thing.
[16:57] <lazypower> ^ that
[17:17] <mattyw> so In my charm's amulet test I do self.d.add("mycharm")
[17:17] <mattyw> shouldn't that work out what charm it's in and use that?
[17:18] <mattyw> because I'm getting charmworldlib.charm.CharmNotFound: API request failed: Request failed with: 404
[17:18] <mattyw> also - if it's using layers, do I have to build the charm first?
[17:19] <marcoceppi> mattyw: yes you have to build the charm first, for now (?) we've not thought that far
[17:19] <marcoceppi> mattyw: we'd need a full traceback and the version of amulet you're using
[17:20] <mattyw> marcoceppi, ok, but there'll be spoilers
[17:20] <marcoceppi> mattyw: spoilers?
[17:21] <mattyw> marcoceppi, http://paste.ubuntu.com/13793744/
[17:21] <mattyw> marcoceppi, you'll know what charm I'm working on ;)
[17:21] <marcoceppi> WELL NOW THIS LOOKS FAMILAR :)
[17:22] <mattyw> lol
[17:22] <mattyw> marcoceppi, 1.12.1
[17:22] <marcoceppi> mattyw: don't use the charm= commmand
[17:22] <marcoceppi> mattyw: just d.add('minecraft')
[17:22] <marcoceppi> charm= overrides the autodetection behaviour, since you've explicitly given it a charm to use
[17:23] <mattyw> marcoceppi, nope, I get the same thing
[17:23] <marcoceppi> mattyw: bleh
[17:23] <mattyw> sorry :(
[17:24] <marcoceppi> mattyw: Ah
[17:24] <marcoceppi> have you tried tests/01-listening
[17:24] <marcoceppi> instead of doing it from within the tests directory
[17:24] <mattyw> that works
[17:24] <mattyw> but unit: minecraft/0: machine: 1 agent-state: error details: hook failed: "leader-settings-changed"
[17:25] <mattyw> is that the charm-tools bug?
[17:25] <mattyw> actually
[17:25] <mattyw> ignore me
[17:25] <mattyw> actually yeah, that does seems like the problem I see now
[17:26] <lazypower> cory_fu: ping for when you have a moment
[17:28] <marcoceppi> mattyw: yeah, so amulet assumes the tests is executed from CHARM_DIR, since that's a requirement of all test runners
[17:28] <marcoceppi> mattyw: what's the error for that say?
[17:30] <mattyw> marcoceppi, nah - might be me actually
[17:38] <bloodearnest> marcoceppi, hey there. My code in reactive/foo.py cannot import code from reactive/bar.py, due I think it not being a normal import, rather using manual load_source
[17:39] <bloodearnest> marcoceppi, if I have some library code for my charm's reactive hooks, where should that live in the charm?
[17:39] <bloodearnest> fwiw, the code foo can import bar perfectly fine when running unit tests
[17:44] <marcoceppi> bloodearnest: what are you trying to import?
[17:45] <bloodearnest> marcoceppi, my own code, just in a different file in the charm
[17:45] <cory_fu> lazypower: Ok, just finished.  What's up?  Hangout?
[17:45] <bloodearnest> I can stick it all in the same file, but it would be nicer separate
[17:45] <lazypower> cory_fu: sure, point the direction
[17:46] <cory_fu> lazypower: https://plus.google.com/hangouts/_/canonical.com/big-data-sync
[17:46] <marcoceppi> bloodearnest: well, we've adopted a convention of putting code you want shared between layers in lib/<module>.py
[17:46] <marcoceppi> eg, the nginx layer produces a lib/nginxlib.py, django has a lib/charms/django.py, etc
[17:47] <marcoceppi> lib is in the import path for charms, so it works around the entry_point issue
[17:48] <bloodearnest> marcoceppi, right, sounds like that's what I want. My code is not really for sharing between layers, more for organisation with a layers (and testing usage)
[18:00] <mbruzek> cory_fu: Getting an error with the wheelhouse, http://paste.ubuntu.com/13794767/
[18:00] <cory_fu> mbruzek: File "/var/lib/juju/agents/unit-k8s-0/charm/reactive/k8s.py", line 44
[18:00] <cory_fu> def leader-settings-changed():
[18:00] <cory_fu> Can't use dashes in function names
[18:01] <mbruzek> I fixed that in the code, and re-installed
[18:01] <cory_fu> mbruzek: Also, the error at the bottom indicates that your wheelhouse still contains actual wheels.  Are you on the newest charm-tools?
[18:02] <mbruzek> cory_fu: possibly not
[18:02] <cory_fu> marcoceppi: When will the point release of charm-tools be available?
[18:02] <lazypower> mbruzek: which version of charm-tools are you using?
[18:07] <mbruzek> charm-tools 1.10.0
[18:11] <cory_fu> mbruzek: You might need to rebuild your charm from the layer from scratch, or manually remove wheelhouse/*.whl
[18:12] <marcoceppi> cory_fu: whenever you want me to cut it
[18:12] <marcoceppi> I was going to wait until 3pm EST but can move to get it out before 2PM
[18:13] <cory_fu> I think we should probably get it out, since charms being built now are broken because of the newline.
[18:28] <marcoceppi> cory_fu: ack, will cut asap
[18:29] <cory_fu> marcoceppi: You're the best.  :)
[18:41] <mattyw> marcoceppi, has there been a new release of charmhelpers over the past couple of days? install_remote keeps failing for me with TypeError: must be str, not bytes
[18:41] <mattyw> wasn't doing that last week
[18:44] <jrwren> mattyw: sounds like its python3 now when it was python2 before?
[18:45] <mattyw> jrwren, could be - but the charm was working on friday
[18:45] <mattyw> jrwren, and today it isn't
[18:45] <jrwren> mattyw: oh, same charm. nevermind.
[19:12] <lazypower> mattyw: charm-tools revved to 1.10.0 on Friday evening
[19:12] <lazypower> mattyw: and the base layer was updated in sync w/ that charm tools rel, the hooks are now python3 by default
[19:16] <mattyw> lazypower, makes sense
[19:16] <mattyw> lazypower, might be a problem with install_remote then
[19:16] <mattyw> lazypower, I'm cheating for now
[19:26] <mbruzek> jcastro: Is the tag named "adoption" no other hyphens or prefix ?
[19:27] <mbruzek> jcastro: https://bugs.launchpad.net/juju-core/+bug/1495978
[19:27] <mup> Bug #1495978: Juju does not deploy CentOS images in LXC <adoption> <centos> <containers> <juju> <lxc> <system> <juju-core:Triaged> <https://launchpad.net/bugs/1495978>
[19:42] <jcastro> mbruzek: yeah
[19:42] <mbruzek> jcastro: thanks
[19:42] <jcastro> arosales: I need some graph help if you have a minute
[19:44] <arosales> jcastro: yo, for sure
[19:44] <jcastro> https://plus.google.com/hangouts/_/canonical.com/eco-wx?authuser=1
[19:44] <jcastro> arosales: ^^^
[20:11] <mbruzek> lazypower: cory_fu found an empty sections on the proposed docs. http://52.0.202.26:8000/en/developer-layers.html  Should "Layer Encapsulation" have a paragraph describing that?
[20:11] <lazypower> ah yeah, i didnt know what to put there
[20:11] <lazypower> i forgot to remove the section title/link
[20:13] <cory_fu> mbruzek: Which branch should I be using?  developer-guide or mbruzek-developer-guide?
[20:13] <mbruzek> developer-guide
[20:15] <lazypower> Actually
[20:15] <lazypower> i dont see encapsulation in the navigation.tpl
[20:15] <lazypower> :-/
[20:16] <cory_fu> mbruzek: https://github.com/mbruzek/docs/pull/40
[20:16] <cory_fu> Hopefully that's on the righ tbranch now
[20:19] <krondor> what's the story with charmhelpers.fetch.giturl?  Was working earlier in the week, and now fails GitPython does not support Python 3.
[20:21] <krondor> ahh nevermind I see mattyw seeing similar issues with python 2 to 3 switch.  Any chance we'll see fetch git working again or should I work around?
[20:27] <cory_fu> krondor: It looks like that assertion is no longer true and GitPython should work fine on Python 3
[20:29] <cory_fu> In fact, according to https://github.com/gitpython-developers/gitdb/issues/4 it's been supported for 2 years
[20:29] <cory_fu> Sorry, 1 year
[20:30] <krondor> cory_fu:  That's the error that fetch threw, but I see now there is an new charm tools as of this afternoon for me.  I'll update again and see if anything has changed.
[20:31] <marcoceppi> cory_fu gnuoy cmars axw_: charm-tools 1.10.1 is out
[20:31] <cmars> marcoceppi, thanks!
[20:31] <marcoceppi> Thanks for the report!
[20:31] <cory_fu> krondor: It won't have: https://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/fetch/giturl.py#L25
[20:31] <cory_fu> marcoceppi: Thanks!
[20:51] <cory_fu> krondor (and also marcoceppi): https://code.launchpad.net/~johnsca/charm-helpers/python3/+merge/279817
[20:53] <krondor> cory_fu:  Thank you, I'll test
[21:18] <krondor> cory_fu:  I think it's going to be more involved than that.  giturl tries to apt install python-git which depends on 2.7.  from git import Repo fails with No Module Named 'git'
[21:22] <cory_fu> Ah.  Shoot
[21:22] <cory_fu> And there isn't a python3-git packages
[21:22] <cory_fu> *package
[21:23] <krondor> cory_fu, right kind of a bind
[21:48] <bcsaller> iirc our deps on git stuff are very thin and could be handled with subprocess, we don't really inspect the data very much
[21:53] <cory_fu> True.  I was just hoping it would be a trivial change.  But I guess not
[21:56] <krondor> bscaller: yeah I'm going back to subprocess at least for the interim
[21:57] <marcoceppi> +1 on subprocess, the sooner we can drop bzrlib the closer we get to Python3 support
[22:35] <jrwren> charmers: kindly requeue http://review.juju.solutions/review/2357 please.
[22:47] <jcastro> krondor: I ran into a snag in magento so you might end up beating me on this
[22:52] <TheJeff> good day charmers!
[22:52] <TheJeff> run into an issue deploying things, hopeing you can clarify
[22:54] <TheJeff> ack in just a few minutes because fire.
[23:00] <TheJeff> alright I'm back -- so I'm following this here guide:
[23:00] <TheJeff> https://help.ubuntu.com/lts/clouddocs/en/Installing-OpenStack.html
[23:00] <TheJeff> I'm at the point where I source novarc
[23:01] <TheJeff> # nova endpoints <-- execute this, got Invalid Openstack Nova credentials
[23:01] <TheJeff> now, I'm sure I need to change the novarc file - it's mostly autopoulated
[23:01] <TheJeff> from that script
[23:01] <TheJeff> assume its the OS_password variable
[23:02] <mgz> TheJeff: if you add --debug you can see the actualy request json you send to keystone
[23:02] <TheJeff> where would one obtain said password?  Is it the one I set in the keystone portion of the openstack-config?  Otherwise its all default afaik, and it's still not working
[23:02] <mgz> password is what is set up for that user in keystone
[23:03] <TheJeff> seems that throws the same error though
[23:04] <TheJeff> assuming its what i set as admin-password: in my yaml when I spun it up
[23:04] <mgz> nope
[23:05] <mgz> hm, I can't remember all the details here,
[23:05] <TheJeff> and nova endpoints --debug throws an error that --debug isnt a valid flag
[23:06] <TheJeff> can I reset this somehow?
[23:06] <TheJeff> I'm less concerned with where it went sideways than setting it right side up
[23:07] <mgz> it's `nova --debug endpoints`
[23:07] <TheJeff> Could not find user, admin.", "code": 401, "title": "Unauthorized"
[23:08] <TheJeff> is this perhaps my maas user?
[23:08] <mgz> TheJeff: see https://bugs.launchpad.net/charms/+source/keystone/+bug/1435906
[23:09] <mup> Bug #1435906: provide stable mechanism to retrieve admin credentials <keystone (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1435906>
[23:09] <mgz> look in that file for the real password, /var/lib/keystone/keystone.passwd
[23:09] <mgz> and yeah, looks like you have the user name wrong too?
[23:09] <mgz> that's `admin-user` in the charm config
[23:11] <TheJeff> mgz: admin-user huh
[23:11] <TheJeff> that's not anywhere in this yaml
[23:12] <TheJeff> nor this doc :(
[23:12] <TheJeff> and this workaround you linked states 'use juju-set' -- but that's not a command I've got
[23:13] <mgz> the default should be 'admin'''
[23:13] <mgz> TheJeff: it's `juju set`
[23:13] <mgz> see the help for that, takes a service and config key/value pair
[23:14] <TheJeff> aha
[23:15] <TheJeff> so is it OS_PASSWORD I'm setting?
[23:15] <TheJeff> as is in the nova.rc
[23:15] <TheJeff> is that the key?  can I list keys?
[23:16] <TheJeff> juju list|grep user && juju set {} <password>
[23:16] <TheJeff> ^some way of this???
[23:26] <marcoceppi> TheJeff: hey
[23:27]  * marcoceppi reads scroll
[23:30] <marcoceppi> TheJeff: did you run the script here? https://help.ubuntu.com/lts/clouddocs/en/Installing-OpenStack.html#configuring-access-to-openstack
[23:43] <TheJeff> marcoceppi: yep
[23:43] <TheJeff> that populated nova.rc fine
[23:43] <marcoceppi> TheJeff: does the .novarc file look right?
[23:43] <marcoceppi> cool
[23:44] <TheJeff> but it says invalid creds
[23:44] <TheJeff> actually just sat back down nothing has changed since my last message above^
[23:44] <marcoceppi> still trying to read through the backlog
[23:44] <adam_g> TheJeff, the keystone charm generates admin password for you, unless one is configured. try: juju set keystone admin-password=foo
[23:44] <adam_g> let it run its config-changed hook and that should now be the admin password
[23:44] <TheJeff> ooo
[23:44] <TheJeff> ok
[23:44] <adam_g> update OS_PASSWORD in your envirnment accordingly
[23:46] <TheJeff> ok ok wait so i actually just ran that shell script again
[23:46] <TheJeff> and it punched back keystone admin token
[23:46] <TheJeff> is that it?
[23:49] <TheJeff> yeah ok so thats a neat thing
[23:49] <TheJeff> I ran juju set admin-user=admin
[23:49] <TheJeff> warning: already set
[23:49] <TheJeff> ran juju set admin-password=<password>
[23:49] <TheJeff> warning already set (and matches
[23:49] <TheJeff> source nova.rc
[23:49] <TheJeff> nova endpoints
[23:49] <TheJeff> invalid nova credentials :(
[23:51] <TheJeff> oh.  there's all kinds of bad looking stuff in my juju status
[23:51] <TheJeff> keystone:      message: 'Missing relations: database'
[23:51] <TheJeff> rabbit saying           message: 'hook failed: "shared-db-relation-changed" for mysql:shared-db'
[23:51] <TheJeff> swift saying
[23:51] <TheJeff>       message: Not enough related storage nodes
[23:52] <TheJeff> ugh
[23:52] <TheJeff> related?
[23:54] <TheJeff> yeah keystone saying           message: 'hook failed: "shared-db-relation-changed" for mysql:shared-db'
[23:57] <TheJeff> alright, I'm starting over.
[23:59] <TheJeff> is there a doc that's up to date?  The one I'm following (canonical) mentions deploying quantum-gateway, which juju states is end of life, and deploying openstack-dashboard for example complains there's no config