=== axw_ is now known as axw [03:19] marcoceppi: I don't know and I don't care. Should I care? [03:19] stub: we accidentally merged it with precise [03:20] Hmmm... [03:21] It should work - it just relies on charmhelpers and the PG stuff is common, and the default PG version for precise is still coded in there. [03:21] stub: we can revert, but it seems to be working [03:22] Ok. I was kind of hoping to just drop support for precise (since we don't need it any more), but we can drop support for this version rather than the previous version [03:24] If the basic deployment, the rest will work the same or better than the previous version. Replication or some extensions like wal_e might be wonky, but the older version would be wonkier. [03:25] So lets leave it. [03:30] I'll try and have the reactive rewrite up soon :) === scuttlemonkey is now known as scuttle|afk === JoshStrobl is now known as Josh|Class [09:21] jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/odl-controller/new-tests/+merge/277258 is ready for another review if you have a moment [09:28] gnuoy, ok looking now [09:37] gnuoy, https://code.launchpad.net/~james-page/charms/trusty/neutron-openvswitch/lp1515008/+merge/277325 [09:40] gnuoy, I'll just wait for amulet to pass that before landing [09:40] kk [09:40] gnuoy, can we get osci pointed at the odl-controller branches? [09:41] yep [09:47] jamespage, when the branches exist I think https://code.launchpad.net/~gnuoy/ubuntu-openstack-ci/odl/+merge/277327 should do the trick [09:47] beisner, ^ [09:56] gnuoy, can we create /next branches now from the current source branches and propose against those? running things by hand is nasty [09:56] hi all. i need to create specific instance type of aws ec2 instance for my service. [09:57] i know about juju set-constraints --service instance-type=m3.xlarge [09:57] jamespage, yes, but I don't know what needs to happen to get osci to pick up the change to lp:ubuntu-openstack-ci [09:57] we can wait for beisner if you like [09:57] gnuoy, sure [09:57] if your branch tests out ok I'll land it [09:57] but when i add unit from juju-gui it creates default instance tyoe [10:01] gnuoy, we need to plumb in AMULET_ODL_LOCATION=http://10.245.161.162/swift/v1/opendaylight/distribution-karaf-0.2.3-Helium-SR3.tar.gz as well [10:02] yep [10:08] jamespage, added setting AMULET_ODL_LOCATION to the mp [10:48] hi all, anyone around who is familiar with https://jujucharms.com/python-django and can help with a couple of questions? [10:56] frobware: Hi. I was told it is you who works on juju networking and using OpenStack for providing machines to Juju [10:56] apuimedo, yes [10:56] apuimedo, (and the team!) [10:56] frobware: that was fast :P [10:56] frobware: who's the team? [10:56] *in [10:56] apuimedo, dimitern, voidspace, dooferlad [10:57] nice to meet you guys ;-) [10:57] hi [10:58] apuimedo, want to briefly HO - I saw you had some questions earlier in the week [10:58] HO? [10:58] apuimedo, google hangout [10:58] sounds good [10:58] apuimedo, https://plus.google.com/hangouts/_/canonical.com/juju-sapphire [10:59] frobware: there in a couple of minutes [11:03] frobware: I'm getting a google hangout error trying to join [11:03] when requesting permission to join [11:04] frobware, you'll have to allow external participants as thats under a canonical.com hangout [11:04] apuimedo, OK, let's just try here in IRC [11:04] frobware: let me create a meeting on ho [11:05] frobware: https://plus.google.com/hangouts/_/midokura.com/juju_openstack [11:08] hey apuimedo [11:08] hey ;-) [11:19] gnuoy, juju-test INFO : Results: 4 passed, 0 failed, 0 errored [11:19] awesome [11:19] \o/ [11:26] gnuoy, ok landed all of that [11:26] ta [11:26] gnuoy, also snuck in the tox bits needed for if we want to upstream this charm to /openstack [11:26] k [11:27] gnuoy, I think we could also run func tests under tox as well [11:33] dimitern: is there any trick that would make the openstack provider set up the bridges as if it were maas? [11:33] (I can disable the arp anti spoofing filter in my openstack provider) [11:34] jamespage, I'm guessing I need to [11:35] create the /next branches and delete the originals [11:35] or is there a smarted way [11:35] yeah [11:35] smarted? smarter [11:35] kk [11:35] just branch then and mark the old ones as decprecated [11:36] jamespage, I see Abandoned is that the one? [11:36] yah [11:36] ta [11:36] gnuoy, I'd create the trunk and next branches for all of them now under openstack-charmers [11:37] will do === scuttle|afk is now known as scuttlemonkey [15:50] beisner, I've probably missed something but if you get a sec https://code.launchpad.net/~gnuoy/ubuntu-openstack-ci/odl/+merge/277327 [16:51] Hello [16:51] does someone is familiar with add_source(source, key=None): in juju helpers python ?? [16:51] I try to pass a block with the gpg key starting with -----BEGIN PGP PUBLIC KEY BLOCK----- and it fails on safe_loader .. [16:53] thomnico: I think you need a key ID not a key file, not sure though [16:54] correct, it polls the configured keyserver for the key [16:55] checking the code it show I should be able to add a keyfile .. [16:55] or at least thats how i've used it [16:55] and I won't have access to hard coded keyserver.ubuntu.com [16:56] when live gives you lemons, write a bash script and use subprocess *ducks from impending object trajectory* [16:56] s/live/life/ [16:56] hehehe you guys are the python fans [16:56] I'm a pragmatist, I'm a fan of what works reliably [16:57] so do I lazypower (but you know already) [16:57] <3 [16:57] where should I raise bug on helpers please ?? [16:57] launchpad.net/charm-helpers [16:58] It might pretty well be me not putting the expcted syntax though .. [16:58] thats possible, but if there's a bug for it we can get it on the docket to take a closer look [16:58] there very well may be a bug in there [16:58] ok ... === sarnold_ is now known as sarnold [17:40] jamespage: nice presentation! How can I start testing nova-compute-lxd? I'm checking out the lxd charm now....is there a method or procedure you have defined for how you are doing this? [17:49] bdx, https://jujucharms.com/u/openstack-charmers-next/openstack-lxd [17:51] ooooohhh nicceeeee!! thx! [18:05] bdx: fyi, jamespage fixed a bug with DVR. This should help you. https://bugs.launchpad.net/charms/+source/neutron-openvswitch/+bug/1515008 [18:05] Bug #1515008: L3 agent missing on compute node in DVR setup

[18:41] Anyone knowledgeable on the python-django charm? I'm trying to use fabric as described on https://jujucharms.com/python-django , but whenever I try to execute a task with 'fab', I'm being asked for "Login password for 'ubuntu': " [18:41] lazypower perhaps? ^ [18:54] thedac: YES! [18:55] jamespage: ^^ [18:55] bdx: Fix already landed in next and the backport to stable is on the way [19:01] thedac, jamespage: nice fix! ... it totally makes sense that was the issue...I can't stop smiling [19:08] thedac: thanks for your help over the last few days investigating that [19:09] bdx: no problem. Sorry I did not catch it sooner [19:10] thedac: your good man... ditto [19:21] gnuoy, jamespage - fyi uosci is now feeding on the odl trio; please see proposals on those charms for a few cosmetic adjustments. [19:31] dpm_ sorry i'm not sure whats going on there. thumper is the current maintainer of the django charm. I think a mail to the list as he's in NZ timezones, would be a good path forward to getting support with that particular error :( [19:31] sorry i'm not of more help [19:33] lazypower: remind me, did you do the charm testing and debugging at the last summit? [19:33] negatory [19:34] ah, that was you mbruzek iirc [19:35] yeah that was me [19:35] ok you're doing one for cfgmgmntcamp. :) [19:35] lazypower, no worries, I ended up posting on http://askubuntu.com/questions/697318/how-to-use-fabric-with-juju and pinging cory_fu - will ask thumper on e-mail if all else faile [19:35] *fails [19:36] that reads like it's a key issue doesn't it? [19:37] like, you should be able to just ssh in there without any prompts [19:39] jcastro: Yes, though per the instructions in the README it ought to just work. I'm not sure how the charm is supposed to tell fab to use the Juju SSH key, nor even how it tells it how to resolve a unit ID (foo/0) into a host name === med_ is now known as openstackgerrit_ === openstackgerrit_ is now known as med_ [19:40] I'm going to stab in the dark and I bet thumper exports a bunch of environment variables for fab that juju consumes or the other way around [19:40] * thumper has burning ears [19:42] Oh, no, it's the fabfile.py in the charm. You have to have that locally. I haven't used Fabric before. :) [19:43] cory_fu, yeah, you bzr branch the charm, and then you can point fab to the fabfile [19:43] if you're running fab from the charm's code directory, it finds the fabfile.py automatically too [19:44] I've also added [19:44] what you do need? [19:44] thumper: https://askubuntu.com/questions/697318/how-to-use-fabric-with-juju [19:44] http://askubuntu.com/questions/697318/how-to-use-fabric-with-juju [19:44] thanks guys :) [19:44] It's prompting for the ubuntu user's password [19:44] lazypower: that reminds me, I need to propose another change to the django charm as I've deployed celery in prod now [19:45] Not using Juju's ssh key file [19:45] lazypower: and I need to support upgrading django so I can get to 1.8 [19:47] dpm_: I'm unclear as to what you are attepmting [19:49] dpm_: Ok, so if your SSH public key is on Launchpad, you can get this to work by importing your key into the Juju deployment: juju authorized-keys import [19:49] thumper, essentially to be able to run "fab -R python-django/0 manage:collectstatic" from my desktop PC [19:49] thumper: I think either that needs to be added to the Fabric section of the README, or it should somehow use the juju_id_rsa key [19:50] ("that" being the auth-keys import instructions) [19:50] hmm... not at all familiar with fabric [19:51] why does this not just translate through a juju run thing? [19:51] cory_fu, that worked nicely, thanks! Now the actual command failed, but at least key authentication worked [19:52] thumper: It apparently uses normal ssh. There might be a way to have it use `juju ssh` as its ssh command, but I don't know how that would work [19:53] I'm not familiar with fabric, either, I just used it as the charm's documentation mentions it as the way to do what I was trying to do. If there is an equivalent way to do it with juju, I'd be more than happy to try that instead [19:55] These functions should really be redone as Juju actions, but that would require work on the charm [19:59] cory_fu, in any case, your suggestion worked, so if you want to add it to the Ask Ubuntu question, I'll check it as the answer [19:59] Done [20:01] \o/ thanks! [20:03] dpm_: What error did you get from the command failure? Anything useful? [20:06] cory_fu, it seems not all of the fabricfile.py commands work. Luckily, the one I'm interested in (manage:collectstatic) does. But here is an example of one that doesn't: http://pastebin.ubuntu.com/13241329/ [20:06] thumper so many wants, so many todos, so little time [20:06] it seems to use ubucon_site instead of the expected gunicorn as the service name [20:06] thumper i know those feels :-| [20:09] man, authorized-keys import. I didn't even know that existed [20:10] dpm_: What does this give you: juju ssh python-django/0 -- ls /etc/init/ubucon_site.conf [20:10] dpm_: Scratch that. This instead: juju ssh ubucon_site/7 -- ls /etc/init/ubucon_site.conf [20:12] cory_fu, there is not such a file. ubucon-site is not a service, it's created using a ubucon-site.yaml config for the python-django charm [20:14] dpm_: The way the charm looks like it works is that it creates an Upstart job conf file in /etc/init based on the name of the deployed service, from the unit name (in your case, ubucon-site/7). So if the site were up and running, and thus could be reloaded, there should be an /etc/init/ubucon-site.conf file on the unit [20:16] Is there a config option that you haven't set for the charm to start the service? [20:16] (thumper might be of more use there) [20:16] I don't really know much about that charm [20:17] cory_fu, the site is up and running, but the charm seems to set up only the gunicorn upstart job as means of reloading the site: http://paste.ubuntu.com/13241388/ [20:17] and http://paste.ubuntu.com/13241402 [20:22] dpm_: Ah, I think the issue is that the Fabric code pre-dates the wsgi / gunicorn change [20:23] aha [20:25] dpm_: You could edit the reload function in fabfile.py and hard-code the service name to "gunicorn"... [20:25] - sudo('service %s reload' % env.sanitized_service_name) [20:25] + sudo('service gunicorn reload') [20:26] yeah, I was toying with the idea :) [20:26] That should be changed in the charm to handle whatever wsgi subordinate was used, but I'm not sure how that would work [20:27] That is way beyond my charm-fu, but for now I'm happy that it's more or less working :) [20:31] Glad we could help [20:32] indeed, thanks :) [22:22] Hi all - anyone able to tell me what happened here? http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/1392/console [22:22] Looks like a problem with the test infrastructure, not the MP.