[00:19] <bradm> anyone about?  I'm having issues with getting a juju bootstrap to work, looking at the debug logs its in a loop around trying to ssh in, even though the ssh command it's trying to use it working when I do it manually
[00:20] <sarnold> is there anything in the unit logs?
[00:21] <bradm> well, no, because juju can't seem to talk to the unit
[00:21] <bradm> there's no juju installed, no evidence that juju has done anything to it
[00:21] <sarnold> but you could ssh in manually and look, right?
[00:21] <bradm> this is using juju+maas, so the instance is a physical machine
[00:21] <bradm> sure can
[00:22] <bradm> there's no /var/lib/juju or /var/log/juju on the unit, there's no juju package installed
[00:23] <bradm> oh hang on, the bootstrap node has juju 1.20, but the unit can only see 1.18, that doesn't seem good
[00:23] <sarnold> you've rapidly gone beyond my experience :) but maybe the --upload-tools thing can help?
[00:24] <bradm> maybe, and if I can add the juju stable ppa to the maas preseed as well, might help
[01:05] <bradm> if I create the /var/lib/juju/nonce.txt by hand, everything starts moving forward
[02:18] <ayr-ton> panic: Unexpected <nil> in storage-port: <nil>. Expected float64 or int. When juju status. juju 1.21-alpha1-trusty-amd64
[02:19] <ayr-ton> Someone knows how to fix it?
[03:09] <jose> marcoceppi: hey, I'm having this problem, "Failed to request test // Only charmers can initiate reviews"
[09:04] <Xiaoqian> nobuto: ping
[09:23] <zaargy> does juju autoheal services? if so can someone point me to how it works? thanks
[11:24] <Odd_Bloke> Is there a programmatic way of destroying a service without having to guess when to resolve errors?
[11:24] <Odd_Bloke> By "programmatic" I mean "I'm writing a shell script using the Juju CLI".
[11:25] <Odd_Bloke> Use case is this: I want to spin up a service and if it fails to deploy, remove it completely.
[11:26] <Odd_Bloke> (Such that deploying again won't get an 'already deployed' error)
[11:31] <Odd_Bloke> (Side note: is there documentation of the possible agent states?)
[11:54] <Mmike> Odd_Bloke, can't you destroy your environment and try again?
[12:08] <Odd_Bloke> Mmike: These are ephemeral services which I would expect to be deployed in to an existing environment.
[12:10] <Mmike> Odd_Bloke, from what I can see you can only do 'destroy-machine' with --force option - that would remove all units deployed on that machine
[12:14] <Odd_Bloke> Mmike: Cool, I'll give that a try. Thanks!
[12:14] <Mmike> Odd_Bloke, sure thing - let us know if that worked for you
[12:14] <Odd_Bloke> Will do.
[12:23] <Odd_Bloke> If I change configuration options iwthin hooks, should I expect the changed values to show up in a 'juju get'?
[12:56] <rcj> Odd_Bloke, in my experience, no.  If a unit changes a service config value, that change is not reflected to other units or to the juju CLI/GUI
[12:56] <rcj> I'm having that problem too.
[12:57] <rcj> Is there a way to surface arbitrary data/status from a charm back to the cli?
[12:58] <Odd_Bloke> "juju ssh cat ..."? ¬.¬
[13:11] <Odd_Bloke> Mmike: A first test suggests that blowing away the machine works. :)
[13:31] <lazyPower>  Odd_Blokejuju destroy-machine # --force
[13:31] <lazyPower> then juju destroy-service
[13:34] <Odd_Bloke> Cool, that's working for me.
[14:43] <lazyPower> mwenning: ping
[14:44] <mwenning> lazyPower, pong
[14:44] <lazyPower> I know this is low priority atm, any updates on the dell cluster?
[14:52] <mwenning> lazyPower, dell cluster?
[14:53] <lazyPower> mwenning: apologies for being the master of no context. The Dell OpenManage server charm was pending tests when I left off.  I beleive kent handed this off to you?
[14:56] <mwenning> lazyPower, ah.   yes he did.  Looks like Adam Israel looked at it yesterday and said the charm tests pass cleanly.
[14:57] <mwenning> My TODO list today says to contact you and ask what the next steps are :-)
[14:57] <lazyPower> aisrael: i haven't looked at the charm since kent and I last spoke. the tests that passed cleanly were unit tests I'm assuming?
[15:00] <aisrael> No. Charm proof passed cleanly, but I was unable to run the tests
[15:01] <mwenning> aisrael, why couldn't you run the tests?
[15:04] <lazyPower> mwenning: i'm one of the few people that has access to that lab, and even then i had a heck of a time getting in
[15:04] <aisrael> Looking back through my notes. I see: 2014-09-17 15:33:16 INFO config-changed Starting Systems Management Data Engine:
[15:04] <aisrael> 2014-09-17 15:33:16 INFO config-changed Failed to start because system is not supported
[15:05] <mwenning> lazyPower, aisrael, I see.  OK let me play with it.  aisrael, what system were you using?
[15:06] <aisrael> mwenning: Testing using the local provider under vagrant
[15:07] <lazyPower> aisrael: its not going to run there, as it depends on a specific dell package that gets installed to manage them that has access to control fans, etc.
[15:07] <mwenning> oh.  Don't think OMSA will work there, you probably need real dell hardware
[15:07] <lazyPower> its a hardware level api
[15:07] <lazyPower> yeah, i already went through all of this, which is what sparked the request for the lab
[15:08] <mwenning> Maybe I can log a clearer error message
[15:09] <aisrael> Right, that's what I figured. I meant to re-assign the ticket to you to review, but lp wouldn't let me
[15:17] <lazyPower> aisrael: no worries. I've had this on my recurring todo list for a couple weeks now since we've had a bit of back and forth about it
[16:07] <mwenning> kentb, good morning!
[16:07] <kentb> mwenning: mornin!
[16:07] <mwenning> They are discussing your charm on the internal #juju -
 mwenning: any insight on if this works for other servers or if its limited to an implicit series such as the M R and G (i think)
[16:08] <mwenning> I said it should work on any Dell server that supports OMSA, is this correct?
[16:09] <kentb> correct, so, PowerEdge C is the only line that doesn't work, but, Dell will tell customers that as well.
[16:09] <mwenning> kentb, cool, thx
[16:09] <kentb> mwenning: np.  my pleasure :)
[16:10] <lazyPower> kentb: o/
[16:11] <kentb> o/
[16:12] <mwenning> kentb, thx,  one more step closer...
[16:12] <kentb> yep...it's been a long road on this one.  Thanks for helping out with carrying it to the goal line.
[16:13] <lazyPower> kentb: we're literally feet away from the finish line. I need to evaluate the tests being run and wrap up on teh quorem of implications this has on our CI and its a wrap.
[16:14] <kentb> lazyPower: awesome.  Thanks for all your help and review.
[16:15] <lazyPower> No problem, thanks for being a responsive charm author :)
[16:15] <lazyPower> and leaving me in good hands post-facto. mwenning deserves a beer.
[16:15] <kentb> you are certainly welcome. mwenning does deserve a beer.  Fortunately, he's just down the road from me.
[18:59] <jose> jcastro: updating the Ubuntu on Air! calendar
[19:34] <natefinch> jcastro: got a minute to talk about feature flags?
[20:10] <mbruzek> Does anyone in #juju know what charm can relate to couchdb's "db" relation?
[20:20] <marcoceppi> natefinch: I do
[20:20]  * marcoceppi was off yesterday
[20:20] <natefinch> ahh cool
[20:21] <natefinch> so we had a juju core team lead meeting this morning, and we talked about feature flags for a good proportion of our hour long meeting
[20:21] <marcoceppi> fun!
[20:21] <natefinch> what we decided on was that having a flag per feature was just going to get too unwieldy and too confusing for everyone, so we should just mark charms very simply as "needs juju x.y or higher"
[20:22] <natefinch> and that perhaps this has some drawbacks compared to feature flags, but that they were worth the tradeoff just to make things easier for everyone to understand.
[20:23] <marcoceppi> natefinch: I'm a +1 with needs juju x.y and if the field is ommitted it's a safe to use charm
[20:23] <natefinch> yep
[20:23] <natefinch> cool
[20:23] <marcoceppi> as that begins to land I'll make sure the review docs are cleared up to make sure people using newer features have this in metadata.yaml
[20:24] <natefinch> yep, I'll sync with you so that we make sure the docs and the feature land together
[20:24] <marcoceppi> natefinch: \o.
[20:24] <lazyPower> this is re: healthchecks/actions/etc?
[20:24] <natefinch> ish, yes.  Basically, a way to use features that will be not be backwards compatible with older jujus without totally screwing the older jujus (i.e. deploy and nothing happens)
[20:26] <natefinch> it'll also mean that if you make a new version of a charm and mark it with a minimum juju version, older versions of juju will still use the old charm, and not try to deploy the new one that won't work
[20:26] <natefinch> ..... where new version means one for a newer series
[20:26] <lazyPower> awesome
[20:26] <lazyPower> +1 from me
[20:26] <natefinch> cool
[20:27] <marcoceppi> natefinch: given how much of a proponent jcastro was to this yesterday you may want to double check with him, but I think this should appease him
[20:27] <natefinch> marcoceppi: cool. Yes, I wanted to talk with him about it. Hopefully this will be good enough.  I'll make sure to catch up with him next time he's avaialble.
[20:27] <jcastro> I AM APPEASED!
[20:27] <natefinch> haha
[20:27] <jcastro> natefinch, sorry I didn't respond I just got back
[20:28] <jcastro> Min version seems like the best approach to me
[20:28] <natefinch> jcastro: how I viewed that last message: http://2.bp.blogspot.com/-FFpUo771xbc/UaNn0M9Ap3I/AAAAAAAAAWU/CBNxgExQRfg/s1600/51987-Are-You-Not-Entertained-1a5I.jpeg
[20:29] <natefinch> jcastro: cool
[20:30] <jcastro> min is nice and easy
[20:30] <jcastro> because we can easily search one field
[20:30] <natefinch> yep
[20:30] <natefinch> and there's no magic to figuring it out
[20:30] <jcastro> instead of "ok search for charms which support feature X"
[20:30] <jcastro> then we'd have to have a feature-to-version grid, etc.
[20:31] <natefinch> yup
[20:41] <jcastro> hey marcoceppi
[20:41] <jcastro> you were going to generate a tarball of all the charms for the OBs right?
[20:41] <marcoceppi> hey jcastro
[20:41] <jcastro> so we don't have to wait all day for charm get all iiirc
[20:41] <marcoceppi> jcastro: I do do this, yes
[20:41] <jcastro> link?
[20:41] <marcoceppi> jcastro: http://people.canonical.com/~marco/mirror/juju/charmstore/
[20:42] <marcoceppi> it needs to be refreshed now that I look at it
[20:42] <marcoceppi> unmomento