=== stub` is now known as stub === frobware_ is now known as frobware [09:12] gnuoy, do you need me to work through the mitaka keystone v3 updates? [09:14] jamespage, yes please. just be carefull, there are two with pending results from full rechecks [09:15] jamespage, oh, actually just one needs us to wait [09:15] gnuoy, I'm assuming you have exercised them with v3 as the amulet tests don't right? [09:22] jamespage, I did, yes. I've marked the spreadsheet as such [09:22] gnuoy, \o/ +1000 thankyou [09:24] gnuoy, ok they all look good - https://review.openstack.org/#/c/306861/ pending full recheck.. [09:25] kk === magicalt1out is now known as magicaltrout [10:21] stub, do you write unit tests for any of juju interfaces on http://interfaces.juju.solutions/ ? [10:22] gnuoy: No. I haven't used them either ;) === JoseeAntonioR is now known as jose === freeflying__ is now known as freeflying === Ursinha_ is now known as Ursinha === cppforlife__ is now known as cppforlife_ [11:32] jamespage, got a sec for https://review.openstack.org/#/c/306861/ ? [11:36] gnuoy, done [11:36] gnuoy, about to clone release notes btw [11:36] thanks [11:36] ok, ta [11:38] gnuoy, just a straight copy from 16.01 for now [11:38] https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/ReleaseNotes1604 [11:47] jamespage, is there a bug for the dashboard upgrade issue you mentioned? [11:47] yes === Guest39780 is now known as CyberJacob === CyberJacob is now known as Guest41374 === Guest41374 is now known as CyberJacob [12:03] rockstar, is https://review.openstack.org/#/c/305896 ready to go? I was wondering how your got your commit message into that state? === mhall119_ is now known as mhall119 === jrwren_ is now known as jrwren === fginther` is now known as fginther [13:38] hi gnuoy, a lil ++debug @ https://code.launchpad.net/~1chb1n/openstack-mojo-specs/fix-git-checkout-stable/+merge/292078 if you will [13:39] ready to land if you're +! [13:39] +1 even ;-) === A-Kaser_ is now known as A-Kaser [13:47] beisner, approved [13:47] gnuoy, thx sir [13:47] np === plars_ is now known as plars [14:15] 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] also, o-c-t bundles updated for precise re: nova no longer neutroning [14:17] kk, thanks [14:17] jamespage: commit message into what state? [14:18] 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] 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] rockstar, re commit message - two change-id's ? [14:28] jamespage: it's two commits squished into one. [14:28] (because openstack) [14:30] rockstar, not sure I understand 'because openstack'? [14:31] 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] rockstar, ok [14:32] rockstar, have you read https://wiki.openstack.org/wiki/GitCommitMessages ? [14:35] jamespage: with respect, it seems that that wiki entry is contradictory to what it wants for gerritt. [14:36] 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] 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] rockstar, sure - tbh I was trying to figure out how you got two change-ids? did you squash two commits together? [14:38] Yeah, that's exactly what happened. [14:39] Breaking the "one logical change per commit" rule. [14:44] Hi cory_fu [14:44] Hello [14:45] I am getting the below error while calling the set_db_details function in my interface [14:45] 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] http://pastebin.ubuntu.com/15914037/ [14:47] has the interface code [15:00] 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] one [15:01] suchvenu: See https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L85 [15:01] 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] 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] ok. [15:03] When my scope is SERVICE, should i always use [15:03] 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] conversation = self.conversation() conversation.remove_state or conversation.set_state always ? [15:03] does self.remove_state and self.set_state also work ? [15:05] Hey! What would be the best course of action to find the provided hooks from interfaces listed on http://interfaces.juju.solutions/ ? [15:05] is it simply to read the code provided in the repo? [15:05] 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] or can you list the hooks somewhere? [15:05] I mean what is the difference between both ways of calling ? [15:06] 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] ok, no issues [15:07] suchvenu: When inside @hook, there is only ever one conversation (for that specific hook) [15:08] 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] 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] BrunoR: have you logged into jujucharms.com yet? [15:11] marcoceppi: ah, mein fehler [15:11] Hi simonklb a well written layer may not write hooks at all. What is your requirement here? [15:11] BrunoR: it's a weird thing, I'll make sure to document it on the site [15:16] mbruzek: I'm currently just getting to know juju - right now I'm looking at setting up a relation with keystone [15:16] I was under the impression that you used interfaces which provided hooks for you to accuire data from other charms [15:16] simonklb: First of all welcome. [15:16] thanks! [15:17] acquire* :) [15:18] simonklb: It might help to read this document: https://jujucharms.com/docs/devel/developer-event-cycle [15:19] ah, so the hooks are usually named in a specific way [15:19] thats good to know! [15:20] I thought it was more arbitrary [15:20] 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] right [15:21] 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] perhaps I should be looking at using the openstack-API layer instead [15:22] 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] 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] simonklb: If you are looking at the traditional charms (non layered) you should not worry about the interfaces.juju.solutions webpage. [15:26] mbruzek: they have this - http://interfaces.juju.solutions/layer/openstack-api/ [15:26] They have it but I don't know if they *use* it for any charms yet. [15:27] ah I see [15:27] heading home for today, thanks for the help! [15:27] I'll probably pop in here from time to time :) [15:27] I heard they are moving that direction but I don't know if they have written any charms that way [15:27] yet [15:27] simonklb: anytime [15:29] simonklb: let me know if you have any other questions when you get home. === Guest15381 is now known as medberry === medberry is now known as med_ === smoser` is now known as smoser [15:55] suchvenu: Did that solve your problem? === scuttle|afk is now known as scuttlemonkey [16:32] cory_fu: I didn;t check it still [16:32] If its GLOBAL scope, then we can directly call self.set_state ? [16:33] I mean only for GLOBAL we can call like that ? [16:36] Only for GLOBAL, yes [16:36] Because GLOBAL scope means that everything shares the same conversation, no matter what [16:39] ok, for SERVICE and UNIT, conversation is required [16:40] I will try and let you know. So in the reactive layer, i should call the set_db_details in a loop === matthelmke is now known as matthelmke-afk === cos1 is now known as c0s [17:36] beisner, gnuoy: https://review.openstack.org/#/c/307076/ ready for review [17:36] jamespage, thx, on it === matthelmke-afk is now known as matthelmke [17:53] 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] Bug #1571782: Trusty-Icehouse neutron-api is failing shared-db-relation-changed for mysql:shared-db

=== cherylj_ is now known as cherylj [18:22] and weeee!: bug 1571789 [18:22] Bug #1571789: install hook failing on Xenial with unmet dependency on mysql-client

[18:22] (pxc: your amulet tests will look at lot different after ODS) [18:25] 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] 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] oh cool - TIL. thx cory_fu. [18:27] So @when x; @when y z; def foo(y, z, x): [18:27] It tripped me up just the other day, in fact === redir is now known as redir_lunch === redir_lunch is now known as redir [19:08] 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] BrunoR: What's the charm store URL? [19:21] 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] 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] 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] But your namespace isn't updated [19:28] The search page is up to date as well: https://jujucharms.com/q/quobyte-registry [19:28] BrunoR: Looks like an issue with namespaces [19:29] Looks like it's affecting ~bigdata-charmers as well [19:30] BrunoR: Please file a bug at https://github.com/CanonicalLtd/jujucharms.com/issues === cos1 is now known as c0s [20:12] beisner, I swear I installed a pxc on xenial this morning... [20:12] jamespage, yah i'm puzzled too. the only thing i can think is an image rev, and a dropped pkg [20:13] ie. remnants of the mysql 5.6 thing === fginther` is now known as fginther [20:20] jamespage, fyi pushed unit test update [20:20] beisner, ack - look shortly [20:21] thx jamespage [20:21] beisner, rockstars lxd stuff is not landing - I suspect that its the double Change-Id [20:21] lolz [20:22] beisner, trying again - https://review.openstack.org/#/c/305896/ === redir is now known as redir_afk [20:56] 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] Bug #1571782: Trusty-Icehouse neutron-api: Table 'quotas' already exists

[20:57] jamespage, sure enough, yesterday, a xenial image had mysql-client-5.6 pkg avail: http://pastebin.ubuntu.com/15920829/ [20:57] gnuoy, http://10.245.162.36:8080/view/Dashboards/view/Mojo/job/mojo_runner_baremetal/623/consoleFull [20:58] 00:14:39.627 2016-04-18 19:18:27 [INFO] cloning git://github.com/openstack/charm-nova-cloud-controller [20:58] fyi ^ and yes indeed, more runs underway. [20:59] any chance on quick C-H review? https://code.launchpad.net/~chris.macnaughton/charm-helpers/use-lsblk-to-check-mount/+merge/292199 [21:01] cholcombe: can I get a community review on ^^ [21:01] icey, i'm on it [21:02] thanks! [21:02] icey, what are your intentions with such a thing? ;-) you wanna resync some things dontchya? [21:02] beisner: I so do! [21:02] the ceph/ceph-osd charms can [21:02] can't do encryption without that [21:02] because C-H was wrong about detecting if something is moutned [21:02] :-D [21:02] icey, is there a blocking bug on our 16.04 release checklist for that? [21:03] no....? [21:03] at this point, i'm only inclined to land things that directly unblock those blockers [21:03] beisner: the charm as it stands today will happily deploy itself to broken :) [21:03] your choice ;) [21:03] ie. this would be a fix to land in next/master after 16.04, then do a stable charm update / backport. [21:03] dood where's your bug? [21:03] what targets/combos are affected? [21:04] uhm, anything hitting infernalis +, so wily+xenial? [21:04] * beisner waits for bug [21:05] it'll solve https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1513009 [21:05] Bug #1513009: With MAAS 1.9a2, lvm disks are not correctly skipped when in-use by ceph disk prepare.

[21:05] beisner, yeah the lvm one is a long standing bug that I wasn't able to fix [21:06] it too stems from is_device_mounted not going deep enough [21:07] https://bugs.launchpad.net/charms/+source/ceph/+bug/1571840 beisner [21:07] Bug #1571840: Ceph will enter an error state when attempting to add a new encrypted block device [21:08] beisner: https://bugs.launchpad.net/charms/+bug/1571842 [21:08] Bug #1571842: ceph-osd error encryption [21:09] * icey EODs [21:11] cholcombe, icey - please bring those all to the daily tomorrow am. === alexlist` is now known as alexlist === scuttlemonkey is now known as scuttle|afk [21:36] jamespage, if you're still around, full pass on pxc @ https://review.openstack.org/#/c/307414/