[08:18] <gnuoy`> jamespage, if you get a moment would you mind taking a look at https://code.launchpad.net/~gnuoy/charms/trusty/keystone/lp1506397/+merge/274856 ?
[11:42] <jamespage> gnuoy`, I think that looks ok - marked ready for review to get osci turning over
[11:42] <gnuoy`> ta
[11:44] <jamespage> gnuoy`, are you happy this does not impact the action managed upgrade path?
[11:49] <gnuoy`> jamespage, no, I will check on that and update the bug
[11:49] <jamespage> gnuoy`, hmm no that will be a problem - the action helper needs to return to set outcomes
[11:59] <gnuoy`> jamespage, got a sec for https://code.launchpad.net/~gnuoy/charms/trusty/neutron-gateway/lp1506046/+merge/274417 and https://code.launchpad.net/~gnuoy/charms/trusty/nova-compute/lp1506046/+merge/274416 ?
[12:00] <jamespage> gnuoy`, +1 +1
[12:00] <gnuoy`> jamespage, thanks
[12:00] <gnuoy`> thanks
[12:02] <jamespage> gnuoy`, https://code.launchpad.net/~james-page/charms/trusty/ceilometer/status-fixes-actions/+merge/274699
[12:02] <jamespage> if you have time
[12:02] <jamespage> ;)
[12:18] <gnuoy`> jamespage, +1
[14:02] <beisner> hi gnuoy` - can we do a c-h sync across all next charms?  i think most have been sync'd recently, but it'd be good to square 'em up and re-test.
[14:03] <gnuoy`> beisner, yep
[14:06] <beisner> gnuoy`, ps thx for the 2 merges
[14:08] <gnuoy`> np
[14:12] <beisner> ddellav, re: ssl spec fails, here's what automated tests are seeing.  is this what you're seeing?  http://paste.ubuntu.com/12861113/
[14:12] <ddellav> beisner, yep, that's exactly it
[14:16] <beisner> ok raised bug @ https://bugs.launchpad.net/charms/+source/keystone/+bug/1507619
[14:16] <mup> Bug #1507619: With SSL, install hook fails: KeyError: 'getpwnam(): name not found: juju_keystone' <openstack> <uosci> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1507619>
[14:16] <beisner> ddellav gnuoy` jamespage coreycb fyi^
[14:19] <coreycb> beisner, thanks I'll look shortly
[14:22] <ddellav> beisner, thanks for checking that out, i wasn't quite sure if it was me or an actual issue. It seems to be present through all of the different openstack versions
[14:24] <beisner> ddellav, autobot sees the same
[14:27] <beisner> thedac, gnuoy` - fyi p-i stable metal spec deploys are failing after switching to the lp:charms/precise/x namespace.
[14:28] <beisner> but precise using trusty/next charms on metal is fine
[14:28] <beisner> updated sheet, linked a job.  also re-running just to confirm.
[14:29] <beisner> so, whatever is broken will apparently be fixed when we push next out to trusty & precise spaces.
[14:29] <gnuoy`> beisner, kk, as we discussed last week I'm happy to leave those as is and limit testing of  lp:charms/precise/x namespace to the upgrade stable to next testing thedac is doing
[14:30] <beisner> gnuoy`, no i think you have a valid point in that the stable precise deploy should use the charms from the precise namespace.
[14:31] <gnuoy`> beisner, but as you say we're testing something which will be fixed in 2-3 days when the sync happens
[14:31] <beisner> gnuoy`, it really just shows that something isn't in sync with stable T -> P
[14:31] <gnuoy`> agreed
[15:00] <Icey> how does a reactive charm call for a hook? I'm trying to debug-hooks on a new reactive charm but have no idea how the hook should be called
[15:00] <Icey> wait, methinks I wasn't finishing the directions
[15:23] <stokachu> Icey: the hooks are exposed through charms.reactive.hook
[18:02] <Icey> how long do charms take to be ingested from LP to jujucharms.com?
[18:07] <stokachu> Icey: i think it runs every 30 minutes?
[18:07] <stokachu> or maybe on the hour
[18:07] <Icey> cool, thanks stokachu
[18:07] <stokachu> Icey: np, lemme know if thats not the case ill get a more concrete answer for you
[18:08] <Icey> that's good enough, I can keep deploying from local: for a while :)
[18:08] <stokachu> cool sounds good :)
[18:12] <rick_h_> Icey: it's about 2hr total atm.
[18:12] <Icey> ok
[18:12] <rick_h_> Icey: to go all the way through the system (both old/new systems)
[18:47] <beisner> jamespage, dosaboy, cholcombe - with uuidgen as fsid, V install hook stops failing.  added comment @ https://bugs.launchpad.net/charms/+source/ceph/+bug/1506287
[18:47] <mup> Bug #1506287: ceph-disk: Error: Device is mounted: /dev/sdb1 (Unable to initialize device: /dev/sdb) <openstack> <uosci> <ceph (Juju Charms Collection):New for james-page> <https://launchpad.net/bugs/1506287>
[18:48] <cholcombe> beisner, this sounds familiar
[18:48] <cholcombe> beisner, sdb is automatically mounted correct?
[19:15] <beisner> cholcombe, indeed familiar, but slightly different:
[19:15] <beisner> with a static fsid uuid, i consistently get fails on Vivid and Wily (systemd), but not on upstart (Precise, Trusty)
[19:16] <beisner> with a unique-ish fsid uuid on every run, Vivid and Wily begin to pass
[19:21] <cholcombe> beisner, i'll peek at the charm and see if i can track down what is going on
[19:22] <beisner> cholcombe, so we appear to be unblocked (still validating with a few more cycles) -- as long as the fsid value changes.
[19:22] <beisner> cholcombe, thx appreciate it
[19:23] <cholcombe> beisner, the charm is prob doing something silly if it sees an existing fsid.  can you quick wipe the disks between tests?
[19:23] <beisner> cholcombe, no, it takes many hours for that wipe to happen.
[19:23] <cholcombe> beisner, ok
[19:24] <beisner> cholcombe, if maas had a quick-wipe feature (maybe i'll raise a feature request bug on that) ... like write 0s to the first X blocks then bail.
[19:24] <cholcombe> beisner, that would be nice ;)
[19:28] <jamespage> cholcombe, systemd will be slurping them in some way
[19:28] <cholcombe> jamespage, i figured but i didn't know for sure
[19:29] <jamespage> well that's my guess
[19:32] <beisner> cholcombe, raised that bug that i've thought about raising on a half-dozen or so previous occasions.  https://bugs.launchpad.net/maas/+bug/1507745
[19:32] <mup> Bug #1507745: feature request:  quick disk erase <ceph> <openstack> <uosci> <MAAS:New> <https://launchpad.net/bugs/1507745>
[19:32] <beisner> nice-to-have
[19:33] <cholcombe> beisner, +1 :)
[19:38] <arosales> man summit.juju.solutions looks really solid
[19:39]  * arosales looking forward to that event
[19:39]  * arosales thinks marcoceppi had something to do with that
[19:42] <beisner> dang, yah.  that looks nice!
[23:33] <Smace> https://jujucharms.com/ => 503 Service Unavailable
[23:33] <Smace> No server is available to handle this request.
[23:34] <Smace> http://juju.ubuntu.com/docs => 503 Service Unavailable
[23:35] <Smace> So it seems it is down. At least for me it is.
[23:35] <Smace> Even without `docs`. http://juju.ubuntu.com/ => 503 Service Unavailable
[23:35] <blahdeblah> Smace: We're working on that right now
[23:36] <Smace> Allright. Sorry for disturbing.
[23:36] <blahdeblah> np
[23:36] <Smace> whois blahdeblah
[23:36] <hloeung> heh
[23:41] <blahdeblah> Smace: EMISSINGSLASH :-)
[23:42]  * Smace hides. :)