[06:56] <Merlijn_S> Hi! Anyone here has experience with charm compose?
[11:38] <apuimedo> lazypower: gnuoy`: jamespag`: https://code.launchpad.net/~celebdor/charm-helpers/midonet/+merge/273678
[11:39] <apuimedo> IIUC I have to get this merged and then sync it to the development branches of the Openstack charms
[11:39] <apuimedo> then send the necessary patches for those, right?
[12:18] <mattyw> beisner, ping?
[12:35] <jamespag`> apuimedo, yah - looking now
[12:37] <jamespag`> apuimedo, lgtm - landed
[12:39] <apuimedo> thanks!
[12:40] <apuimedo> jamespag`: much appreciated ;-)
[12:58] <apuimedo> jamespag`: gnuoy`: lp:~openstack-charmers/charms/trusty/nova-cloud-controller/next /charm-helpers-hooks.yaml points to lp:charm-helpers branch
[12:59] <apuimedo> how am I supposed to make the sync?
[12:59] <apuimedo> I guess I can't just change /charm-helpers-hooks.yaml to the
[12:59] <apuimedo> nevermind...
[13:00] <apuimedo> I should look closer, it is already there :P
[13:01] <apuimedo> so I'll do a `make sync`
[13:10] <jamespag`> apuimedo, you got it
[13:10] <apuimedo> it's sad because I had already done it
[13:10] <apuimedo> I for some reason thought there was a lp:charm-helpers/next for a second
[13:17] <beisner> mattyw, pong
[13:20] <mattyw> beisner, hey ther, just regarding the mongodb review
[13:20] <mattyw> beisner, I decided to move most of the common code in dump and restore into a python file - that way I can make some proper unit tests out of it
[13:20] <mattyw> beisner, just wanted to check you were ok with that approach
[13:20] <beisner> mattyw, yep, even better imho :)
[13:27] <beisner> mattyw, marcoceppi aisrael ^ ?
[13:36] <aisrael> mattyw: I think that's fine, as long as you're not symlinking to it. More testing is always better.
[14:09] <beisner> coreycb, on a landing streak i see - thanks for that.  fyi, i've raised this re: the unrelated fails in n-c-c and n-c, and will be looking at adding api checks ahead of the gimme-an-instance tests.  bug 1503701
[14:09] <mup> Bug #1503701: amulet test for new instance needs resilience <amulet> <openstack> <uosci> <nova-cloud-controller (Juju Charms Collection):New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1503701>
[14:14] <beisner> coreycb, and for n-g - bug 1503706
[14:14] <mup> Bug #1503706: amulet test for create network needs resilience <amulet> <openstack> <uosci> <neutron-gateway (Juju Charms Collection):New> <https://launchpad.net/bugs/1503706>
[14:21] <coreycb> beisner, ok.  are those fixes needed for the current amulet failures?
[14:22] <beisner> coreycb, they're races
[14:23] <beisner> coreycb, under load, the overcloud isn't quiesced, and the tests blindly say:  create an instance;  or create a network.
[14:23] <coreycb> beisner, btw reviewing your mps got me wondering if we can figure out a way to have some global files in c-h or wherever our code lands after c-h (e.g Makefile, tests/00-setup, etc)
[14:23] <beisner> coreycb, ie we have passing tests at the same revs
[14:24] <beisner> coreycb, yeah ditto.  there are a couple of exceptions, where os api client isn't in helpers, but only in the local tests.  ceilometer / ceilometer-agent are two.
[14:25] <beisner> beisner, the tests.yaml file will still need to be present for bundletester to parse, so i'm not sure we have a c-h way out of maintaining that.
[14:25] <beisner> coreycb, definitely wanna centralize that somehow though
[14:26] <coreycb> beisner, do you need a hand with those bug fixes?
[14:28] <beisner> coreycb, i think a check-wait-loop-timeout api check just ahead of the create-stuff.  much like this:
[14:28] <beisner> http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/openstack/amulet/utils.py#L485
[14:29] <beisner> nova and neutron need that sort of love
[14:29] <beisner> i've not started into it, but yeah if you've got  cycles and want to tackle that, that'd be awesome
[14:30] <beisner> instead of waiting on an object's status, we need to try/except and api connection and query.
[14:31] <coreycb> beisner, lemme know the priority, cause yeah that cycles thing :)
[14:32] <beisner> coreycb, atm it's just a nagging race, but as you saw in that batch, causes false failures, which causes us to re-run and tie up a test slave for another 2hrs.  and we may still have a race false/fail even with that.
[14:33] <beisner> coreycb, it's a priority from my perspective, because of that (tying up test resources 2 or 3 times to eek out a solid run).
[14:34] <coreycb> beisner, ok
[14:43] <jamespage> thedac, gnuoy`:
[14:43] <jamespage> https://code.launchpad.net/~james-page/charms/trusty/ceph/status/+merge/273635
[14:43] <jamespage> and
[14:43] <jamespage> https://code.launchpad.net/~james-page/charms/trusty/ceph-osd/status/+merge/273634
[14:43] <thedac> jamespage: great. I'll take a look today
[14:44] <thedac> \o/
[14:44] <jamespage> thedac, I've tested them out - they work OK
[14:44] <thedac> cool
[14:44] <jamespage> thedac, the only bit that's missing is the device detection in ceph
[14:44] <jamespage> I'll work on that today - but feedback appreicated
[14:44]  * thedac nods
[14:45] <jamespage> beisner, hey - can we get dnspython installed on the unit testing envs for osci:
[14:45] <jamespage> http://paste.ubuntu.com/12702241/
[14:46] <beisner> jamespage, oo yuck the unit test is trying to apt-get install something?
[14:46] <jamespage> beisner, well the charm-helper is trying to install dnspython cause it can't import it
[14:46] <jamespage> its on of the try: import: catch: install re-import things
[14:51] <beisner> jamespage, jenkins@juju-osci-machine-7:~$ apt-cache policy python-dns
[14:51] <beisner> python-dns:
[14:51] <beisner>   Installed: 2.3.6-3
[14:51] <beisner> somethine else must be amiss
[14:52] <jamespage> beisner: python-dnspython
[14:55] <beisner> jamespage, ok now, reran, passing results @
[14:55] <beisner> https://code.launchpad.net/~james-page/charms/trusty/ceph-osd/status/+merge/273634
[14:55] <beisner> https://code.launchpad.net/~james-page/charms/trusty/ceph/status/+merge/273635
[14:55] <jamespage> beisner, awesome
[14:55] <jamespage> thanks
[14:56] <beisner> jamespage, yw
[14:56] <jamespage> beisner, probably cause we've not really got unit tests in the ceph charms this popped up when I wrote some :-)
[14:56] <jamespage> when does cholcombe typically appear?  want to ensure I'm not stepping on his toes with my status proposals.
[14:57] <beisner> jamespage, yeah, osd had 0.  so, yay!
[14:57] <jamespage> beisner, my new tests are surgical - but made me feel better...
[15:20] <apuimedo> jamespage: for the nova-cloud-controller changes
[15:20] <apuimedo> when proposing for merging
[15:21] <apuimedo> I should taget the branch: lp:~openstack-charmers/charms/trusty/nova-cloud-controller/next and put you as a reviewer, right?
[15:21] <apuimedo> I'm getting a message
[15:22] <apuimedo> jamespage: http://paste.ubuntu.com/12705281/
[15:22] <apuimedo> I'm getting the same for gnuoy`
[15:30] <Merlijn_S_> Quick question: the charmhelpers.core.host.chownr function doesn't chown the supplied dir itself, only its children. Is this intentional? Seems strange to me..
[15:35] <mattyw> beisner, marcoceppi I've updated the mongodb actions suggestions https://code.launchpad.net/~mattyw/charms/trusty/mongodb/mongodb-backup/+merge/273544
[15:45] <apuimedo> jamespage: gnuoy`: coreycb: why is nova-compute/next charm-helpers-hooks.yaml pointing to lp:~hopem/charm-helpers/add-rbd-cache-config-support ?
[15:45] <apuimedo> shouldn't lp:~hopem/charm-helpers/add-rbd-cache-config-support have proposed a merge againts lp:charm-helpers and then nova-compute/next keep pointing to lp:charm-helpers?
[15:45] <gnuoy`> apuimedo, a mistake, should lp:charm-helpers
[15:46] <apuimedo> gnuoy`: so... Can I fix it and send it with my merge request?
[15:46] <gnuoy`> apuimedo, I'll fix it it was probably my error at review time
[15:47] <apuimedo> gnuoy`: ok, I wait for that to sync and put my changes
[15:47] <apuimedo> gnuoy`: did you see my question above about the target branch for nova-cloud-controller and the message I get from launchpad?
[15:48] <gnuoy`> apuimedo, otp, but will look
[15:49] <mattyw> marcoceppi, does UOSCI need updating with a charmhelps that supports the latest action functions? http://paste.ubuntu.com/12705419/
[15:50] <gnuoy`> apuimedo, charm-helpers-hooks.yaml should be fixed
[15:50] <gnuoy`> apuimedo, yes, targey lp:~openstack-charmers/charms/trusty/nova-cloud-controller/next
[15:51] <apuimedo> gnuoy`: it asks me if I want to nominate you
[15:52] <apuimedo> as you don't currently have the permission to view branches
[15:52] <apuimedo> (sounds like launchpad malfunction to me)
[15:52] <gnuoy`> apuimedo, does it? I'd suggest not nominating anyone then it lands on the review queue for all to see
[15:52] <apuimedo> ok
[15:53] <apuimedo> gnuoy`: jamespage: so here you go https://code.launchpad.net/~celebdor/charms/trusty/nova-cloud-controller/midonet/+merge/273717
[15:56] <beisner> mattyw, it's actually failing because the unit test (as non-root) is attempting to apt install a pkg.
[15:57] <beisner> mattyw, generally speaking, unit tests shouldn't actually "do" things to the host running the tests.  this looks like a case where you'll need to prep a venv in the makefile ahead of the tests running.
[15:57] <mattyw> beisner, yeah  it only does that if it can't import the action_get function. It's messy but that seems to be the accepted way of doing that kind of thing
[15:57] <mattyw> beisner, ah - good call
[15:58] <beisner> ie. satisfy dependencies before the test is fired
[15:58] <mattyw> beisner, what about on a unit - we'd need to make sure the deps were up to date there as well?
[16:02] <beisner> mattw - so in this charm (and all of the openstack charms), the necessary bits from charmhelpers are sync'd into hooks/charmhelpers.
[16:02] <beisner> mattyw, `make sync`
[16:03] <beisner> that of course has pros/cons
[16:04] <mattyw> beisner, that only works in the hooks directory - I could have a similar one in the actions directory as well?
[16:05] <beisner> mattyw, true.  which i believe is why in the swift charm, hooks/charmhelpers moved to lib/ so both actions/ and hooks/ could consume.  but that's more symlink foo!
[16:06] <mattyw> beisner, I could do an extra sync location for actions - and add a TODO ;)
[16:08] <beisner> mattyw, i'll defer to the primary maintainers of the mongodb charm on that (and all of this really).   there is how-we-do-it-now vs. how-we-would-like-to-see-it-done.   i can tell ya all about how we do it now ;-)
[16:10] <mattyw> beisner, which charm was that?
[16:10] <beisner> mattyw, swift-proxy and swift-storage ('next' dev branches), which will be part of the 15.10 openstack charm release
[16:11] <beisner> https://code.launchpad.net/~openstack-charmers/charms/trusty/swift-proxy/next
[16:11] <beisner> https://code.launchpad.net/~openstack-charmers/charms/trusty/swift-storage/next
[16:11] <mattyw> beisner, perfect thanks - I was looking the current ones
[16:12] <beisner> mattyw, so something will have to be either duplicated or symlinked, or pip installed.  each of the approaches have pros/cons
[16:13] <mattyw> beisner, I'll go with symlink and wait for comments
[16:15] <mattyw> beisner, done, let's see what trouble that causes ;)
[16:25] <coreycb> gnuoy`, I pushed a new keystone version for action-managed upgrades, after a slight scare.  somehow I overwrote my branch on lp without using --overwrite, but luckily enough lp has history.
[16:48] <beisner> fyi gnuoy`, dosaboy - wrt the n-c-c amulet test fails;  known race opportunity [ that's my positive spin thedac ;-) ] ... raised @ bug 1503701 -- unrelated to your proposed changes.
[16:48] <mup> Bug #1503701: amulet test for new instance needs resilience <amulet> <openstack> <uosci> <nova-cloud-controller (Juju Charms Collection):New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1503701>
[16:48] <thedac> haha
[16:51] <mattyw> beisner, thanks! great idea, sensible diff size now
[16:51] <beisner> mattyw, woot!  still violates the antisymlink thing, but so does the rest of the charm.
[16:52] <mattyw> beisner, rules are meant to be broken ;)
[16:52] <beisner> mattyw, so are symlinks
[16:52] <beisner> ba da bing
[16:53] <mattyw> beisner, I'd be happy with haing to sync locations - but I'm also happy to go with majority verdict :)
[19:09] <apuimedo> lazypower: ping
[19:14] <apuimedo> mbruzek: ping
[19:14] <mbruzek> apuimedo: Hello!
[19:15] <apuimedo> mbruzek: Ahoj
[19:15] <apuimedo> how's it going?
[19:15] <mbruzek> apuimedo: I am doing well.  And you?
[19:15] <apuimedo> I got some amulet failure when syncing up the charm helpers
[19:15] <apuimedo> and putting some template change
[19:15] <apuimedo> http://paste.ubuntu.com/12706944/
[19:16] <apuimedo> do you think it could be a flaky test of that the charm was not ready for the sync?
[19:20] <tvansteenburgh> looks like whatever server the novaclient is pointing at is broken, or was
[19:20] <tvansteenburgh> i don't know anything about this though
[19:21] <tvansteenburgh> beisner, jamespage ^
[19:21] <beisner> mbruzek, apuimedo - that looks like n-c-c.  if so, it is a race in the test, working on it now actually.   bug 1503701   tldr: the deployed test cloud wasn't completely open for business at the moment the create instance routine fired off.
[19:21] <mup> Bug #1503701: amulet test for new instance needs resilience <amulet> <openstack> <uosci> <nova-cloud-controller (Juju Charms Collection):New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1503701>
[19:21] <apuimedo> beisner: oh, thanks. I didn't know about this issue
[19:22] <apuimedo> beisner: could you retrigger the test for the merge proposal once you fix it, then?
[19:22] <beisner> just started seeing it.  it generally happens when the rest of the undercloud has elevated load.
[19:22] <beisner> apuimedo, you would have to rebase, after finish, propose, and get the test updates landed.
[19:22] <beisner> s/after/after i/
[19:23] <apuimedo> beisner: I'll have to check how to rebase in bzr. I'm still fighting with it and wishing I had git :P
[19:24] <beisner> apuimedo, i plan to have a proposal up tomorrow
[19:24] <apuimedo> beisner: do you have some estimation for the bug fix?
[19:24] <apuimedo> ah, good
[19:25] <mbruzek> apuimedo: beisner is the expert on osci but if you have any amulet questions I can help
[19:25] <apuimedo> mbruzek: perfect, thanks ;-)
[19:25] <apuimedo> beisner: what's your tz, so I can tell when to ping you about future osci issues
[19:26] <beisner> apuimedo, us central time
[19:26]  * beisner goes to find lunch
[19:26] <apuimedo> cool
[19:27] <apuimedo> beisner: bon appetit
[19:29] <mbruzek> apuimedo: You can ping me for osci problems too, I just might have to consult with beisner for the tougher ones
[19:29] <apuimedo> ok
[19:29] <apuimedo> mbruzek: thanks!
[23:14] <apuimedo> beisner: the issue also happened with  nova-compute/next http://paste.ubuntu.com/12709505/
[23:45] <beisner> apuimedo, yep, that bug is listed for both n-c and n-c-c
[23:45] <apuimedo> cool
[23:46] <apuimedo> ;-)
[23:57] <george_e> Is it still necessary to bundle "charmhelpers" with a charm? (I'm specifically thinking of Precise here.)
[23:58] <george_e> Or is there a better way?