[09:23] jamespage, coreycb, fyi https://github.com/juju/charm-tools/issues/69 [09:53] gnuoy, urgh [09:56] jamespage, https://code.launchpad.net/~gnuoy/charms/+source/interface-rabbitmq/+git/interface-rabbitmq/+merge/279743 does that address your concerns? [09:58] gnuoy, yes [10:50] gnuoy, newer odl versions appear to have a way to determine whether they are up or not [10:51] https://github.com/openstack/networking-odl/blob/master/devstack/odl-releases/lithium-snapshot-0.3.2#L28 [10:51] \o/ [10:51] Christmas has come early [12:44] 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] "you would" being the reply I'm hoping for [12:47] probably [12:47] gnuoy, I'd put auto_accessors in for any key that will be eventually consistent across all remote units [12:48] jamespage, so we should remove 'private-address' then I guess [12:51] gnuoy, yeah I guess so [12:51] gnuoy, and pick on from the list of hosts for 'host' in the adapter === kwmonroe_ is now known as kwmonroe [15:24] jamespage, got a sec for https://code.launchpad.net/~gnuoy/charms/trusty/openvswitch-odl/duplicate-controllers/+merge/279251 ? [15:29] gnuoy, I'll peek in a bit [16:39] 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] lazypower: the magic is in charms/__init__.py [16:40] aisrael https://github.com/juju-solutions/charms.docker/blob/master/charms/__init__.py [16:40] and then your code in charms/docker/* will be properly namespaced [16:42] 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] aisrael: i'm not entirely convinced, that I have some hinky package setup in this module [16:42] fair, ta [16:42] lazypower: link to your setup.py? [16:43] marcoceppi https://github.com/juju-solutions/charms.docker/blob/master/setup.py [16:43] lazypower: you're missing a packages declaration [16:44] Ah! [16:44] thanks :) [16:50] marcoceppi: I need to declare both 'charms' and 'charms.docker' corect? [16:50] lazypower: im not sure. it seems wrong, tbh [16:51] Declaring both packages in the setup.yaml? [16:51] er .py [16:51] lazypower: yes, seems wrong to me [16:52] does it work with just charms.docker as the package? [16:52] yep [16:52] i just veriified in a venv [16:52] you found your answer :) [16:57] lazypower: and marcoceppi is this package declaration a pip thing, or a pypi thing? [16:57] Pip thing [16:57] It's a python thing. [16:57] ^ that [17:17] so In my charm's amulet test I do self.d.add("mycharm") [17:17] shouldn't that work out what charm it's in and use that? [17:18] because I'm getting charmworldlib.charm.CharmNotFound: API request failed: Request failed with: 404 [17:18] also - if it's using layers, do I have to build the charm first? [17:19] mattyw: yes you have to build the charm first, for now (?) we've not thought that far [17:19] mattyw: we'd need a full traceback and the version of amulet you're using [17:20] marcoceppi, ok, but there'll be spoilers [17:20] mattyw: spoilers? [17:21] marcoceppi, http://paste.ubuntu.com/13793744/ [17:21] marcoceppi, you'll know what charm I'm working on ;) [17:21] WELL NOW THIS LOOKS FAMILAR :) [17:22] lol [17:22] marcoceppi, 1.12.1 [17:22] mattyw: don't use the charm= commmand [17:22] mattyw: just d.add('minecraft') [17:22] charm= overrides the autodetection behaviour, since you've explicitly given it a charm to use [17:23] marcoceppi, nope, I get the same thing [17:23] mattyw: bleh [17:23] sorry :( [17:24] mattyw: Ah [17:24] have you tried tests/01-listening [17:24] instead of doing it from within the tests directory [17:24] that works [17:24] but unit: minecraft/0: machine: 1 agent-state: error details: hook failed: "leader-settings-changed" [17:25] is that the charm-tools bug? [17:25] actually [17:25] ignore me [17:25] actually yeah, that does seems like the problem I see now [17:26] cory_fu: ping for when you have a moment [17:28] mattyw: yeah, so amulet assumes the tests is executed from CHARM_DIR, since that's a requirement of all test runners [17:28] mattyw: what's the error for that say? [17:30] marcoceppi, nah - might be me actually [17:38] 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] marcoceppi, if I have some library code for my charm's reactive hooks, where should that live in the charm? [17:39] fwiw, the code foo can import bar perfectly fine when running unit tests [17:44] bloodearnest: what are you trying to import? [17:45] marcoceppi, my own code, just in a different file in the charm [17:45] lazypower: Ok, just finished. What's up? Hangout? [17:45] I can stick it all in the same file, but it would be nicer separate [17:45] cory_fu: sure, point the direction [17:46] lazypower: https://plus.google.com/hangouts/_/canonical.com/big-data-sync [17:46] bloodearnest: well, we've adopted a convention of putting code you want shared between layers in lib/.py [17:46] eg, the nginx layer produces a lib/nginxlib.py, django has a lib/charms/django.py, etc [17:47] lib is in the import path for charms, so it works around the entry_point issue [17:48] 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] cory_fu: Getting an error with the wheelhouse, http://paste.ubuntu.com/13794767/ [18:00] mbruzek: File "/var/lib/juju/agents/unit-k8s-0/charm/reactive/k8s.py", line 44 [18:00] def leader-settings-changed(): [18:00] Can't use dashes in function names [18:01] I fixed that in the code, and re-installed [18:01] mbruzek: Also, the error at the bottom indicates that your wheelhouse still contains actual wheels. Are you on the newest charm-tools? [18:02] cory_fu: possibly not [18:02] marcoceppi: When will the point release of charm-tools be available? [18:02] mbruzek: which version of charm-tools are you using? [18:07] charm-tools 1.10.0 [18:11] mbruzek: You might need to rebuild your charm from the layer from scratch, or manually remove wheelhouse/*.whl [18:12] cory_fu: whenever you want me to cut it [18:12] I was going to wait until 3pm EST but can move to get it out before 2PM [18:13] I think we should probably get it out, since charms being built now are broken because of the newline. [18:28] cory_fu: ack, will cut asap [18:29] marcoceppi: You're the best. :) [18:41] 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] wasn't doing that last week [18:44] mattyw: sounds like its python3 now when it was python2 before? [18:45] jrwren, could be - but the charm was working on friday [18:45] jrwren, and today it isn't [18:45] mattyw: oh, same charm. nevermind. === scuttle` is now known as scuttle|afk [19:12] mattyw: charm-tools revved to 1.10.0 on Friday evening [19:12] mattyw: and the base layer was updated in sync w/ that charm tools rel, the hooks are now python3 by default [19:16] lazypower, makes sense [19:16] lazypower, might be a problem with install_remote then [19:16] lazypower, I'm cheating for now [19:26] jcastro: Is the tag named "adoption" no other hyphens or prefix ? [19:27] jcastro: https://bugs.launchpad.net/juju-core/+bug/1495978 [19:27] Bug #1495978: Juju does not deploy CentOS images in LXC

[19:42] mbruzek: yeah [19:42] jcastro: thanks [19:42] arosales: I need some graph help if you have a minute [19:44] jcastro: yo, for sure [19:44] https://plus.google.com/hangouts/_/canonical.com/eco-wx?authuser=1 [19:44] arosales: ^^^ [20:11] 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] ah yeah, i didnt know what to put there [20:11] i forgot to remove the section title/link [20:13] mbruzek: Which branch should I be using? developer-guide or mbruzek-developer-guide? [20:13] developer-guide [20:15] Actually [20:15] i dont see encapsulation in the navigation.tpl [20:15] :-/ [20:16] mbruzek: https://github.com/mbruzek/docs/pull/40 [20:16] Hopefully that's on the righ tbranch now [20:19] 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] 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] krondor: It looks like that assertion is no longer true and GitPython should work fine on Python 3 [20:29] In fact, according to https://github.com/gitpython-developers/gitdb/issues/4 it's been supported for 2 years [20:29] Sorry, 1 year [20:30] 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] cory_fu gnuoy cmars axw_: charm-tools 1.10.1 is out [20:31] marcoceppi, thanks! [20:31] Thanks for the report! [20:31] krondor: It won't have: https://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/fetch/giturl.py#L25 [20:31] marcoceppi: Thanks! === scuttle|afk is now known as scuttlemonkey [20:51] krondor (and also marcoceppi): https://code.launchpad.net/~johnsca/charm-helpers/python3/+merge/279817 [20:53] cory_fu: Thank you, I'll test [21:18] 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] Ah. Shoot [21:22] And there isn't a python3-git packages [21:22] *package [21:23] cory_fu, right kind of a bind [21:48] 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] True. I was just hoping it would be a trivial change. But I guess not === scuttlemonkey is now known as scuttle|afk [21:56] bscaller: yeah I'm going back to subprocess at least for the interim [21:57] +1 on subprocess, the sooner we can drop bzrlib the closer we get to Python3 support === scuttle|afk is now known as scuttlemonkey [22:35] charmers: kindly requeue http://review.juju.solutions/review/2357 please. [22:47] krondor: I ran into a snag in magento so you might end up beating me on this [22:52] good day charmers! [22:52] run into an issue deploying things, hopeing you can clarify [22:54] ack in just a few minutes because fire. [23:00] alright I'm back -- so I'm following this here guide: [23:00] https://help.ubuntu.com/lts/clouddocs/en/Installing-OpenStack.html [23:00] I'm at the point where I source novarc [23:01] # nova endpoints <-- execute this, got Invalid Openstack Nova credentials [23:01] now, I'm sure I need to change the novarc file - it's mostly autopoulated [23:01] from that script [23:01] assume its the OS_password variable [23:02] TheJeff: if you add --debug you can see the actualy request json you send to keystone [23:02] 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] password is what is set up for that user in keystone [23:03] seems that throws the same error though [23:04] assuming its what i set as admin-password: in my yaml when I spun it up [23:04] nope [23:05] hm, I can't remember all the details here, [23:05] and nova endpoints --debug throws an error that --debug isnt a valid flag [23:06] can I reset this somehow? [23:06] I'm less concerned with where it went sideways than setting it right side up [23:07] it's `nova --debug endpoints` [23:07] Could not find user, admin.", "code": 401, "title": "Unauthorized" [23:08] is this perhaps my maas user? [23:08] TheJeff: see https://bugs.launchpad.net/charms/+source/keystone/+bug/1435906 [23:09] Bug #1435906: provide stable mechanism to retrieve admin credentials [23:09] look in that file for the real password, /var/lib/keystone/keystone.passwd [23:09] and yeah, looks like you have the user name wrong too? [23:09] that's `admin-user` in the charm config [23:11] mgz: admin-user huh [23:11] that's not anywhere in this yaml [23:12] nor this doc :( [23:12] and this workaround you linked states 'use juju-set' -- but that's not a command I've got [23:13] the default should be 'admin''' [23:13] TheJeff: it's `juju set` [23:13] see the help for that, takes a service and config key/value pair [23:14] aha [23:15] so is it OS_PASSWORD I'm setting? [23:15] as is in the nova.rc [23:15] is that the key? can I list keys? [23:16] juju list|grep user && juju set {} [23:16] ^some way of this??? [23:26] TheJeff: hey [23:27] * marcoceppi reads scroll [23:30] TheJeff: did you run the script here? https://help.ubuntu.com/lts/clouddocs/en/Installing-OpenStack.html#configuring-access-to-openstack [23:43] marcoceppi: yep [23:43] that populated nova.rc fine [23:43] TheJeff: does the .novarc file look right? [23:43] cool [23:44] but it says invalid creds [23:44] actually just sat back down nothing has changed since my last message above^ [23:44] still trying to read through the backlog [23:44] TheJeff, the keystone charm generates admin password for you, unless one is configured. try: juju set keystone admin-password=foo [23:44] let it run its config-changed hook and that should now be the admin password [23:44] ooo [23:44] ok [23:44] update OS_PASSWORD in your envirnment accordingly [23:46] ok ok wait so i actually just ran that shell script again [23:46] and it punched back keystone admin token [23:46] is that it? [23:49] yeah ok so thats a neat thing [23:49] I ran juju set admin-user=admin [23:49] warning: already set [23:49] ran juju set admin-password= [23:49] warning already set (and matches [23:49] source nova.rc [23:49] nova endpoints [23:49] invalid nova credentials :( [23:51] oh. there's all kinds of bad looking stuff in my juju status [23:51] keystone: message: 'Missing relations: database' [23:51] rabbit saying message: 'hook failed: "shared-db-relation-changed" for mysql:shared-db' [23:51] swift saying [23:51] message: Not enough related storage nodes [23:52] ugh [23:52] related? [23:54] yeah keystone saying message: 'hook failed: "shared-db-relation-changed" for mysql:shared-db' [23:57] alright, I'm starting over. [23:59] 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