[00:24] <miken> How can I check and kill a debug-hooks session running on a unit? (Seems someone has run and left a debug-hooks session open, but they've gone to bed :) ).
[00:24] <miken> I can `juju run --unit myservice/1 ls` fine, but myservice/0 times out.
=== natefinch-afk is now known as natefinch
=== natefinch_ is now known as nateinch
=== nateinch is now known as natefinch
=== zz_CyberJacob is now known as CyberJacob
=== CyberJacob is now known as zz_CyberJacob
=== mgz is now known as _mgz
[09:11] <jamespage> dosaboy, hey - I provided some feedback on your cinder fix for multi-host cinder
[09:12] <jamespage> dosaboy, i think we need to bake the intelligence into the sub, with a default assumption of statefull until all subs provide that flag
[09:29] <dosaboy> jamespage: agreed
[09:29] <jamespage> dosaboy, lemme work up an alternative - I have cycles right now
[09:29] <dosaboy> jamespage: still do the parsing on cinder side tho right?
[09:30] <dosaboy> jamespage: was thinking we could even look at a Juju action to tidy up existing volumes that would be affected by this
[09:31] <dosaboy> jamespage: fyi i'm updating cinder side to incorporate getting statenes from rel
[09:31] <dosaboy> stateness
[09:32] <jamespage> dosaboy, ok - I put up a cinder-ceph branch to work with that hopefully
[09:33] <jamespage> dosaboy, but maybe it should be 'stateless' rather than stateful - what do you think?
[09:34] <dosaboy> jamespage: yeah stateless=False as a default
[09:34] <jamespage> dosaboy, ok updated
[09:40] <dosaboy> jamespage: tbh it would make coding this somewhat easier if the statness was declared within the json
[09:40] <dosaboy> but that would require a charmhelpers change
[09:41] <dosaboy> i'll see what i can do
[09:41] <dosaboy> actually is not a problem after all
[09:59] <blahdeblah> jose: ping - when you're around, can I ask a few questions about your precise postfix charm?
[11:18] <dosaboy> jamespage: https://code.launchpad.net/~hopem/charms/trusty/cinder/lp1493931/+merge/270658
[11:19] <dosaboy> r4r
[11:19] <dosaboy> i've deployed, seems to work well
[12:51] <jamespage> dosaboy, they look ok but lets wait for amulet tests as well please
[12:51] <jamespage> we broke some yesterday by mistake
[13:57] <beisner> jamespage, gnuoy, coreycb, thedac - fyi - a handful of os-charms that still have the deprecating "categories" metadata.yaml bit will now be failing charm proof (lint).  ie. charm-tools is no longer just informing on that.  ;-)
[13:58] <beisner> so, as we all touch each next charm, let's double-check metadata.yaml as a drive-by fix.
[13:58] <gnuoy> yeah, I think that might stop them being ingested into the charmstore come stable release time
[14:00] <lazypower> yep
[14:00] <lazypower> proof errors actively prevent ingestion
[14:06] <sparkiegeek> a warning is not an error though :/ (charm proof categories vs. tags is a warning)
[14:06] <lazypower> sparkiegeek, anything above I: is treated as an error for the store.
[14:07] <sparkiegeek> lazypower: weird. So you're saying Warnings are really Errors? Why not report them as such?
[14:07] <lazypower> marcoceppi, ^
[14:07] <lazypower> sparkiegeek, we're having a policy re-review at the charmer summit and I'll broach that topic on your behalf.
[14:07] <sparkiegeek> lazypower: ta
[14:07] <lazypower> I think we should treat warns as policy changes that will affect you in the near term
[14:07] <sparkiegeek> my expectation is that a W can evolve into an E over time
[14:07] <sparkiegeek> right
[14:08] <lazypower> so its like last call before your charm is treated as bogus
[14:08] <sparkiegeek> sure, that WFM
[14:08] <lazypower> otherwise, i agree. Warn's being treated as errors, there's no transitional phase. You have I: and does not compute. its binary according to the store, and thats not cool.
[14:08]  * lazypower does the angry policy dance
[14:10] <beisner> sparkiegeek, lazypower - right.  but a W:  does exit non-zero, and that's what i'm watching for in automation.
[14:11] <lazypower> beisner, as do all the tools. There's room for improvement there I think. its a bit misleading to label it was a W when its going to cause a hard stop.
[14:11] <sparkiegeek> beisner: the behaviour is consistent in that "charm proof" will exit non-zero but I don't like linters exiting non-zero for Warnings (it's not really a Warning if it's non-zero it's a hard Error)
[14:14] <beisner> sparkiegeek, yeah we've always just charm proofed along with lint, rather than having a separate test for just charm proof.   at any rate, it's now a blocker, and it's an easy fix.
[14:17] <pmatulis> re 'upgrade-juju --version',  ① how to get a list of available versions and ② what logic is used to pick a version?
[15:07] <jose> blahdeblah: sure
=== _mgz is now known as mgz
[18:01] <cholcombe> i think i remember hearing that you could post your github charms to the charm store.  Is that true?
[18:08] <marcoceppi> cholcombe: kind of, the juju is growing a juju store publish command
[18:08] <marcoceppi> cholcombe: but that's not landed yet
[18:08] <cholcombe> oh ok cool
[18:08] <cholcombe> thanks marcoceppi
[18:20]  * rick_h_ goes back to writing more juju publish spec stuff so the team can do the next steps
[18:37] <bdx> core, dev: Is openstack-dashboard installed at the system level or in a venv?
[18:38] <bdx> As far as I can tell it is installed at the system level
[18:39] <bdx> I am having issues installing the panels for designate
[18:40] <bdx> lots of errors, that all seem to point to openstack_dashboard.settings not being able to be imported
[18:40] <bdx> by the designatedashboard package that is installed at the system level
[18:42] <rick_h_> bdx: so you have more info on what charm you're using and what you're using to get horizon?
[18:43] <bdx> rick_h_: I'm using openstack-dashboard-16
[18:44] <bdx> rick_h_: I am deploying openstack-dashboard to lxc containers in my env
[18:44] <rick_h_> bdx: just out of the box with the deb it comes iwth?
[18:44] <bdx> rick_h_: yes
[18:44] <rick_h_> bdx: cool, we found that if you used the debs the python path was the system but if you used from git it used a virtualenv and fought some of that
[18:44] <rick_h_> bdx: but it sounds like your issue is a bit different.
[18:45] <rick_h_> bdx: but we were using git to test out aginst horizon's latest tip from git
[18:46] <bdx> rick_h_: gotcha.....yeah I'm not specifying any tips from git...
[18:47] <rick_h_> bdx: sorry, yea that was the only thing I could think of off the top of my head
[18:47] <bdx> designate will be included in liberty yea?
[18:48] <bdx> we should look at adding a config in openstack-dashboard to optionally include the designate panels yea?
[18:48] <rick_h_> bdx: not sure, we were only worried with our own integration.
[18:48] <rick_h_> bdx: as a subordinate and such
[18:48] <rick_h_> bdx: so haven't checked out designate
[18:49] <bdx> rick_h_: It would be better to have it as a subordinate rather than including it in openstack-dashboard?
=== zz_CyberJacob is now known as CyberJacob
[18:51] <rick_h_> bdx: hmm, I don't manage the dashboard but I would think so. I'd check with the openstack team. They're mostly UK based and EOD. However, I'd think that the charm would be the default horizon ootb and then you'd add on extra dashboards via either relation or even a subordinate.
[18:52] <rick_h_> bdx: but don't quote me on that. It's just how we're approaching it for one chunk of work.
[18:53] <bdx> rick_h_: I see. Is there a better chanel to contact the openstack-dashboard team on?
[18:54] <rick_h_> and "we" here isn't the team managing the openstack stuff. However, there's a PR for a new subordinate relation for dashboards: https://code.launchpad.net/~bac/charms/trusty/openstack-dashboard/dashboard-plugin/+merge/270177 and https://code.launchpad.net/~saviq/charms/trusty/openstack-dashboard/simplify-settings
[18:54] <rick_h_> bdx: so I think it's becoming a pattern
[18:55] <rick_h_> bdx: this channel usually works, but in EU TZ it works best for them.
[18:55] <bdx> rick_h_: totally. thanks man!
[18:56] <rick_h_> bdx: yea, sorry I don't have a thorough fix for you.
[19:01] <bdx> its coo
=== CyberJacob is now known as zz_CyberJacob
=== zz_CyberJacob is now known as CyberJacob
=== urulama is now known as urulama__
=== natefinch is now known as natefinch-afk
[21:21] <bbaqar> Does anyone know what is the optimal value of worker multiplier in neutron-api charm?
=== CyberJacob is now known as zz_CyberJacob
[22:03] <mwenning> hi guys -  I'm trying to deploy a bundle that references some local charms (ceph for one) - I get  Service:  ceph has neither charm url or branch specified
[22:04] <mwenning> Yes I have set $JUJU_REPOSITORY to point to my charms dir.  Any ideas?
[22:05] <lazypower> mwenning, it will say that and typically still deploy the charm. can you pastebin the error for me?
=== zz_CyberJacob is now known as CyberJacob
[22:08] <mwenning> lazypower, I will next time.  I need some test data so I deployed it by hand.  A possible tweak is that I also used the --bootstrap option
[22:11] <lazypower> mwenning, is this with deployer or quickstart?
[22:11] <mwenning> lazypower, juju-deployer
[22:12] <lazypower> ah, yeah - something went awry there then. deployer should have deployed. lmk if you run into it again and have a break to debug
[22:13] <mwenning> lazypower, my last incantation was 'juju-deployer --config=ceph_bundle.yaml --bootstrap -L --debug
[22:13] <mwenning> ceph_bundle.yaml was exported from juju-gui from a previous manual deployment
[22:15] <lazypower> none of that would have caused an issue that i can see
=== CyberJacob is now known as zz_CyberJacob