[09:12] <jamespage> gnuoy, do you need me to work through the mitaka keystone v3 updates?
[09:14] <gnuoy> jamespage, yes please. just be carefull, there are two with pending results from full rechecks
[09:15] <gnuoy> jamespage, oh, actually just one needs us to wait
[09:15] <jamespage> gnuoy, I'm assuming you have exercised them with v3 as the amulet tests don't right?
[09:22] <gnuoy> jamespage, I did, yes. I've marked the spreadsheet as such
[09:22] <jamespage> gnuoy, \o/ +1000 thankyou
[09:24] <jamespage> gnuoy, ok they all look good - https://review.openstack.org/#/c/306861/ pending full recheck..
[09:25] <gnuoy> kk
[10:21] <gnuoy> stub, do you write unit tests for any of juju interfaces on http://interfaces.juju.solutions/ ?
[10:22] <stub> gnuoy: No. I haven't used them either ;)
[11:32] <gnuoy> jamespage, got a sec for https://review.openstack.org/#/c/306861/ ?
[11:36] <jamespage> gnuoy, done
[11:36] <jamespage> gnuoy, about to clone release notes btw
[11:36] <gnuoy> thanks
[11:36] <gnuoy> ok, ta
[11:38] <jamespage> gnuoy, just a straight copy from 16.01 for now
[11:38] <jamespage> https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/ReleaseNotes1604
[11:47] <gnuoy> jamespage, is there a bug for the dashboard upgrade issue you mentioned?
[11:47] <jamespage> yes
[12:03] <jamespage> rockstar, is https://review.openstack.org/#/c/305896 ready to go? I was wondering how your got your commit message into that state?
[13:38] <beisner> hi gnuoy, a lil ++debug @ https://code.launchpad.net/~1chb1n/openstack-mojo-specs/fix-git-checkout-stable/+merge/292078 if you will
[13:39] <beisner> ready to land if you're +!
[13:39] <beisner> +1 even ;-)
[13:47] <gnuoy> beisner, approved
[13:47] <beisner> gnuoy, thx sir
[13:47] <gnuoy> np
[14:15] <beisner> gnuoy, fyi, i'm going to merge your os-mojo precise bundle update then follow up with another mp for some other things.  thx for IDing the issue :)
[14:16] <beisner> also, o-c-t bundles updated for precise re: nova no longer neutroning
[14:17] <gnuoy> kk, thanks
[14:17] <rockstar> jamespage: commit message into what state?
[14:18] <rockstar> jamespage: it is ready to go, but requires a dependent o-c-t branch which I apparently never pushed on Friday, but thought I had. It's up for review now.
[14:25] <gQuigs> can we close (or mark incomplete) all the bugs in pyjuju - I always end up looking https://bugs.launchpad.net/juju  instead of juju-core
[14:27] <jamespage> rockstar, re commit message - two change-id's ?
[14:28] <rockstar> jamespage: it's two commits squished into one.
[14:28] <rockstar> (because openstack)
[14:30] <jamespage> rockstar, not sure I understand 'because openstack'?
[14:31] <rockstar> jamespage: they like you to squish your patch into a single commit. I don't much care for that workflow, but that's the way they want it.
[14:31] <jamespage> rockstar, ok
[14:32] <jamespage> rockstar, have you read https://wiki.openstack.org/wiki/GitCommitMessages ?
[14:35] <rockstar> jamespage: with respect, it seems that that wiki entry is contradictory to what it wants for gerritt.
[14:36] <jamespage> rockstar, all I've really been looking for across other reviews is a decent summary title, some details of what and why the change, closure of bugs and the Change-Id...
[14:38] <rockstar> jamespage: I can remove the other Change-Id when I rebase, if that helps. I've just been leaving whatever it gives me.
[14:38] <jamespage> rockstar, sure - tbh I was trying to figure out how you got two change-ids?  did you squash two commits together?
[14:38] <rockstar> Yeah, that's exactly what happened.
[14:39] <rockstar> Breaking the "one logical change per commit" rule.
[14:44] <suchvenu> Hi cory_fu
[14:44] <cory_fu> Hello
[14:45] <suchvenu> I am getting the below error while calling the set_db_details function in my interface
[14:45] <suchvenu> 2016-04-18 14:37:02 INFO config-changed   File "/usr/local/lib/python3.4/dist-packages/charms/reactive/relations.py", line 256, in conversation 2016-04-18 14:37:02 INFO config-changed     raise ValueError('Unable to determine default scope: no current hook or global scope') 2016-04-18 14:37:02 INFO config-changed ValueError: Unable to determine default scope: no current hook or global scope
[14:46] <suchvenu> http://pastebin.ubuntu.com/15914037/
[14:47] <suchvenu> has the interface code
[15:00] <cory_fu> suchvenu: That error means that your relation is scope SERVICE or UNIT and you are not looping over a list of conversations.  Remember that your db2 charm could have any number of consumers asking for a database at a given time.  Your charm code should have a for loop over each consumer and then do the set up and call set_db_details for each one, passing which consumer in as a param which is given to self.conversation(consumer) to pick up the right
[15:00] <cory_fu> one
[15:01] <cory_fu> suchvenu: See https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L85
[15:01] <mbruzek> bdx: I know this is a deep "call back" but regarding the tls layer you mentioned a desire for a provides/requires relation. I created an issue against the repository and was hoping you could comment on that https://github.com/mbruzek/interface-tls/issues/3
[15:01] <cory_fu> suchvenu: And the pastebin I sent you in the email (http://pastebin.ubuntu.com/15851388/) is slightly wrong.  Line 7 should include $service right before $db_name
[15:02] <suchvenu> ok.
[15:03] <suchvenu> When my scope is SERVICE, should i always use
[15:03] <mbruzek> bdx: I just want to make sure I captured your request properly and if you have any more information to please add it.
[15:03] <suchvenu>  conversation = self.conversation()         conversation.remove_state or conversation.set_state  always ?
[15:03] <suchvenu> does self.remove_state and self.set_state also work ?
[15:05] <simonklb> Hey! What would be the best course of action to find the provided hooks from interfaces listed on http://interfaces.juju.solutions/ ?
[15:05] <simonklb> is it simply to read the code provided in the repo?
[15:05] <cory_fu> suchvenu: You must always use the conversation, but also have to give it an argument unless you're in a @hook decorated method.  So, set_db_details would need to use: conv = self.conversation(consumer)
[15:05] <simonklb> or can you list the hooks somewhere?
[15:05] <suchvenu> I mean what is the difference between both ways of calling ?
[15:06] <cory_fu> suchvenu: Sorry, I'm going to be a few minutes for a meeting right now.  Should be done in ~ 15 min, but I may be slow to respond until then
[15:06] <suchvenu> ok, no issues
[15:07] <cory_fu> suchvenu: When inside @hook, there is only ever one conversation (for that specific hook)
[15:08] <cory_fu> And you don't know ahead of time what it is, so you just have to use self.conversation() (with no arg) to have it figure it out from the @hook
[15:10] <BrunoR> marcoceppi: charm push does not work for me, also charm login raise an error, but in Ubuntu-SSO webconsole charm shows up as application?
[15:10] <marcoceppi> BrunoR: have you logged into jujucharms.com yet?
[15:11] <BrunoR> marcoceppi: ah, mein fehler
[15:11] <mbruzek> Hi simonklb a well written layer may not write hooks at all.  What is your requirement here?
[15:11] <marcoceppi> BrunoR: it's a weird thing, I'll make sure to document it on the site
[15:16] <simonklb> mbruzek: I'm currently just getting to know juju - right now I'm looking at setting up a relation with keystone
[15:16] <simonklb> I was under the impression that you used interfaces which provided hooks for you to accuire data from other charms
[15:16] <mbruzek> simonklb: First of all welcome.
[15:16] <simonklb> thanks!
[15:17] <simonklb> acquire* :)
[15:18] <mbruzek> simonklb: It might help to read this document: https://jujucharms.com/docs/devel/developer-event-cycle
[15:19] <simonklb> ah, so the hooks are usually named in a specific way
[15:19] <simonklb> thats good to know!
[15:20] <simonklb> I thought it was more arbitrary
[15:20] <mbruzek> simonklb: To answer your question directly any method decorated by the @hook decorator would signify a hook. So you could search the code for @hook.
[15:20] <simonklb> right
[15:21] <mbruzek> simonklb: However with well written reactive layers we have found less of a need to use @hook decorators and rely only on states to make writing layers more natural
[15:22] <simonklb> perhaps I should be looking at using the openstack-API layer instead
[15:22] <simonklb> but it felt a bit of an overkill including rabbitmq and mysql when the only thing I really need is to talk to the nova api
[15:25] <mbruzek> simonklb: I don't know if the openstack team has rewritten nova or keystone in layers yet. You may have to look at the traditional hooks in the mean time.
[15:26] <mbruzek> simonklb: If you are looking at the traditional charms (non layered) you should not worry about the interfaces.juju.solutions webpage.
[15:26] <simonklb> mbruzek: they have this - http://interfaces.juju.solutions/layer/openstack-api/
[15:26] <mbruzek> They have it but I don't know if they *use* it for any charms yet.
[15:27] <simonklb> ah I see
[15:27] <simonklb> heading home for today, thanks for the help!
[15:27] <simonklb> I'll probably pop in here from time to time :)
[15:27] <mbruzek> I heard they are moving that direction but I don't know if they have written any charms that way
[15:27] <mbruzek> yet
[15:27] <mbruzek> simonklb: anytime
[15:29] <mbruzek> simonklb: let me know if you have any other questions when you get home.
[15:55] <cory_fu> suchvenu: Did that solve your problem?
[16:32] <suchvenu> cory_fu: I didn;t check it still
[16:32] <suchvenu> If its GLOBAL scope, then we can directly call self.set_state ?
[16:33] <suchvenu> I mean only for GLOBAL we can call like that ?
[16:36] <cory_fu> Only for GLOBAL, yes
[16:36] <cory_fu> Because GLOBAL scope means that everything shares the same conversation, no matter what
[16:39] <suchvenu> ok, for SERVICE and UNIT, conversation is required
[16:40] <suchvenu> I will try and let you know. So in the reactive layer, i should call the set_db_details in a loop
[17:36] <jamespage> beisner, gnuoy: https://review.openstack.org/#/c/307076/ ready for review
[17:36] <beisner> jamespage, thx, on it
[17:53] <beisner> gnuoy, jamespage (fyi cholcombe ) - got a new one.  bug 1571782 (n-api db migration fail) ... complicating the other t-i one we were drilling down (blocked on block  device detection).
[17:53] <mup> Bug #1571782: Trusty-Icehouse neutron-api is failing shared-db-relation-changed for mysql:shared-db <uosci> <neutron-api (Juju Charms Collection):New> <https://launchpad.net/bugs/1571782>
[18:22] <beisner> and weeee!:  bug 1571789
[18:22] <mup> Bug #1571789: install hook failing on Xenial with unmet dependency on mysql-client <uosci> <percona-cluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1571789>
[18:22] <beisner> (pxc: your amulet tests will look at lot different after ODS)
[18:25] <kwmonroe> cory_fu: when i have relation decorators "@when x; @when y; def foo(x, y)", what's the order of foo() params?  it seems to be (y, x) which is odd to me.
[18:27] <cory_fu> kwmonroe: It follows Python decorator ordering which is a bit odd.  Basically, decorators are processed inside-out (a.k.a. bottom up) and then the args are processed left-to-right.
[18:27] <kwmonroe> oh cool - TIL.  thx cory_fu.
[18:27] <cory_fu> So @when x; @when y z; def foo(y, z, x):
[18:27] <cory_fu> It tripped me up just the other day, in fact
[19:08] <BrunoR> after charm push and publish, the named store still shows the old revision of my charm. is there a step which I overlooked?
[19:17] <cory_fu> BrunoR: What's the charm store URL?
[19:21] <cory_fu> BrunoR: You might need to set the acl, or if you're referring to a promulgated charm then it requires a charmer and another step for promulgation
[19:22] <BrunoR> cory_fu: https://jujucharms.com/u/3-bruno/ , e.g. the quobyte-registry charm is linked in revision 2, I would expect revision 4
[19:27] <cory_fu> BrunoR: Hrm.  That's odd.  https://jujucharms.com/u/3-bruno/quobyte-registry/ points to 4 and everything looks fine in `charm show cs:~3-bruno/trusty/quobyte-registry id published perm`
[19:27] <cory_fu> But your namespace isn't updated
[19:28] <cory_fu> The search page is up to date as well: https://jujucharms.com/q/quobyte-registry
[19:28] <cory_fu> BrunoR: Looks like an issue with namespaces
[19:29] <cory_fu> Looks like it's affecting ~bigdata-charmers as well
[19:30] <cory_fu> BrunoR: Please file a bug at https://github.com/CanonicalLtd/jujucharms.com/issues
[20:12] <jamespage> beisner, I swear I installed a pxc on xenial this morning...
[20:12] <beisner> jamespage, yah i'm puzzled too.  the only thing i can think is an image rev, and a dropped pkg
[20:13] <beisner> ie. remnants of the mysql 5.6 thing
[20:20] <beisner> jamespage, fyi pushed unit test update
[20:20] <jamespage> beisner, ack - look shortly
[20:21] <beisner> thx jamespage
[20:21] <jamespage> beisner, rockstars lxd stuff is not landing - I suspect that its the double Change-Id
[20:21] <beisner> lolz
[20:22] <jamespage> beisner, trying again - https://review.openstack.org/#/c/305896/
[20:56] <gnuoy> beisner, my gut feel for Bug #1571782 is that you've somehow got an old version of nova-cloud-controller charm. If you hit it again can you attatch the /var/log/juju/* logs from neutron-api and nova-cloud-controller please?
[20:56] <mup> Bug #1571782: Trusty-Icehouse neutron-api: Table 'quotas' already exists <uosci> <neutron-api (Juju Charms Collection):New> <https://launchpad.net/bugs/1571782>
[20:57] <beisner> jamespage, sure enough, yesterday, a xenial image had mysql-client-5.6 pkg avail:  http://pastebin.ubuntu.com/15920829/
[20:57] <beisner> gnuoy, http://10.245.162.36:8080/view/Dashboards/view/Mojo/job/mojo_runner_baremetal/623/consoleFull
[20:58] <beisner> 00:14:39.627 2016-04-18 19:18:27 [INFO] cloning git://github.com/openstack/charm-nova-cloud-controller
[20:58] <beisner> fyi ^ and yes indeed, more runs underway.
[20:59] <icey> any chance on  quick C-H review? https://code.launchpad.net/~chris.macnaughton/charm-helpers/use-lsblk-to-check-mount/+merge/292199
[21:01] <icey> cholcombe: can I get a community review on ^^
[21:01] <cholcombe> icey, i'm on it
[21:02] <icey> thanks!
[21:02] <beisner> icey, what are your intentions with such a thing?  ;-)   you wanna resync some things dontchya?
[21:02] <icey> beisner: I so do!
[21:02] <icey> the ceph/ceph-osd charms can
[21:02] <icey> can't do encryption without that
[21:02] <icey> because C-H was wrong about detecting if something is moutned
[21:02] <icey> :-D
[21:02] <beisner> icey, is there a blocking bug on our 16.04 release checklist for that?
[21:03] <icey> no....?
[21:03] <beisner> at this point, i'm only inclined to land things that directly unblock those blockers
[21:03] <icey> beisner: the charm as it stands today will happily deploy itself to broken :)
[21:03] <icey> your choice ;)
[21:03] <beisner> ie.  this would be a fix to land in next/master after 16.04, then do a stable charm update / backport.
[21:03] <beisner> dood where's your bug?
[21:03] <beisner> what targets/combos are affected?
[21:04] <icey> uhm, anything hitting infernalis +, so wily+xenial?
[21:04]  * beisner waits for bug
[21:05] <icey> it'll solve https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1513009
[21:05] <mup> Bug #1513009: With MAAS 1.9a2, lvm disks are not correctly skipped when in-use by ceph disk prepare. <cloud-install-failure> <landscape> <ceph (Juju Charms Collection):Triaged by xfactor973> <ceph-osd (Juju Charms Collection):Triaged by xfactor973> <https://launchpad.net/bugs/1513009>
[21:05] <cholcombe> beisner, yeah the lvm one is a long standing bug that I wasn't able to fix
[21:06] <cholcombe> it too stems from is_device_mounted not going deep enough
[21:07] <icey> https://bugs.launchpad.net/charms/+source/ceph/+bug/1571840 beisner
[21:07] <mup> Bug #1571840: Ceph will enter an error state when attempting to add a new encrypted block device <ceph (Juju Charms Collection):New> <https://launchpad.net/bugs/1571840>
[21:08] <icey> beisner: https://bugs.launchpad.net/charms/+bug/1571842
[21:08] <mup> Bug #1571842: ceph-osd error encryption <Juju Charms Collection:New> <https://launchpad.net/bugs/1571842>
[21:09]  * icey EODs
[21:11] <beisner> cholcombe, icey - please bring those all to the daily tomorrow am.
[21:36] <beisner> jamespage, if you're still around, full pass on pxc @ https://review.openstack.org/#/c/307414/