[00:19] 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] is there anything in the unit logs? [00:21] well, no, because juju can't seem to talk to the unit [00:21] there's no juju installed, no evidence that juju has done anything to it [00:21] but you could ssh in manually and look, right? [00:21] this is using juju+maas, so the instance is a physical machine [00:21] sure can [00:22] there's no /var/lib/juju or /var/log/juju on the unit, there's no juju package installed [00:23] 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] you've rapidly gone beyond my experience :) but maybe the --upload-tools thing can help? [00:24] maybe, and if I can add the juju stable ppa to the maas preseed as well, might help [01:05] if I create the /var/lib/juju/nonce.txt by hand, everything starts moving forward === fuzzy is now known as Fuzai === Fuzai is now known as Ponyo [02:18] panic: Unexpected in storage-port: . Expected float64 or int. When juju status. juju 1.21-alpha1-trusty-amd64 [02:19] Someone knows how to fix it? [03:09] marcoceppi: hey, I'm having this problem, "Failed to request test // Only charmers can initiate reviews" === uru_ is now known as urulama === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [09:04] nobuto: ping [09:23] does juju autoheal services? if so can someone point me to how it works? thanks === fabrice is now known as fabrice|lunch [11:24] Is there a programmatic way of destroying a service without having to guess when to resolve errors? [11:24] By "programmatic" I mean "I'm writing a shell script using the Juju CLI". [11:25] Use case is this: I want to spin up a service and if it fails to deploy, remove it completely. [11:26] (Such that deploying again won't get an 'already deployed' error) [11:31] (Side note: is there documentation of the possible agent states?) [11:54] Odd_Bloke, can't you destroy your environment and try again? === psivaa_ is now known as psivaa [12:08] Mmike: These are ephemeral services which I would expect to be deployed in to an existing environment. [12:10] 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] Mmike: Cool, I'll give that a try. Thanks! [12:14] Odd_Bloke, sure thing - let us know if that worked for you [12:14] Will do. [12:23] If I change configuration options iwthin hooks, should I expect the changed values to show up in a 'juju get'? === fabrice|lunch is now known as fabrice [12:56] 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] I'm having that problem too. [12:57] Is there a way to surface arbitrary data/status from a charm back to the cli? [12:58] "juju ssh cat ..."? ¬.¬ [13:11] Mmike: A first test suggests that blowing away the machine works. :) [13:31] Odd_Blokejuju destroy-machine # --force [13:31] then juju destroy-service [13:34] Cool, that's working for me. === kentb-out is now known as kentb [14:43] mwenning: ping [14:44] lazyPower, pong [14:44] I know this is low priority atm, any updates on the dell cluster? [14:52] lazyPower, dell cluster? [14:53] 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] lazyPower, ah. yes he did. Looks like Adam Israel looked at it yesterday and said the charm tests pass cleanly. [14:57] My TODO list today says to contact you and ask what the next steps are :-) [14:57] 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] No. Charm proof passed cleanly, but I was unable to run the tests [15:01] aisrael, why couldn't you run the tests? [15:04] 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] Looking back through my notes. I see: 2014-09-17 15:33:16 INFO config-changed Starting Systems Management Data Engine: [15:04] 2014-09-17 15:33:16 INFO config-changed Failed to start because system is not supported [15:05] lazyPower, aisrael, I see. OK let me play with it. aisrael, what system were you using? [15:06] mwenning: Testing using the local provider under vagrant [15:07] 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] oh. Don't think OMSA will work there, you probably need real dell hardware [15:07] its a hardware level api [15:07] yeah, i already went through all of this, which is what sparked the request for the lab [15:08] Maybe I can log a clearer error message [15:09] 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] 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 === wedgwood1 is now known as wedgwood === fabrice is now known as fabrice|familyti === victorp_ is now known as victorp [16:07] kentb, good morning! [16:07] mwenning: mornin! [16:07] They are discussing your charm on the internal #juju - [16:08] 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] I said it should work on any Dell server that supports OMSA, is this correct? [16:09] correct, so, PowerEdge C is the only line that doesn't work, but, Dell will tell customers that as well. [16:09] kentb, cool, thx [16:09] mwenning: np. my pleasure :) [16:10] kentb: o/ === fabrice is now known as fabrice|family [16:11] o/ [16:12] kentb, thx, one more step closer... [16:12] yep...it's been a long road on this one. Thanks for helping out with carrying it to the goal line. [16:13] 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] lazyPower: awesome. Thanks for all your help and review. [16:15] No problem, thanks for being a responsive charm author :) [16:15] and leaving me in good hands post-facto. mwenning deserves a beer. [16:15] you are certainly welcome. mwenning does deserve a beer. Fortunately, he's just down the road from me. === kentb is now known as kentb-afk === CyberJacob|Away is now known as CyberJacob === kentb-afk is now known as kentb === kwmonroe is now known as kwmonroe_ === kwmonroe_ is now known as kwmonroe === roadmr is now known as roadmr_afk [18:59] jcastro: updating the Ubuntu on Air! calendar [19:34] jcastro: got a minute to talk about feature flags? === roadmr_afk is now known as roadmr [20:10] Does anyone in #juju know what charm can relate to couchdb's "db" relation? === urulama is now known as urulama-afk [20:20] natefinch: I do [20:20] * marcoceppi was off yesterday [20:20] ahh cool [20:21] 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] fun! [20:21] 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] 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] 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] yep [20:23] cool [20:23] 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] yep, I'll sync with you so that we make sure the docs and the feature land together [20:24] natefinch: \o. [20:24] this is re: healthchecks/actions/etc? [20:24] 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] 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] ..... where new version means one for a newer series [20:26] awesome [20:26] +1 from me [20:26] cool [20:27] 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] 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] I AM APPEASED! [20:27] haha [20:27] natefinch, sorry I didn't respond I just got back [20:28] Min version seems like the best approach to me [20:28] 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] jcastro: cool [20:30] min is nice and easy [20:30] because we can easily search one field [20:30] yep [20:30] and there's no magic to figuring it out [20:30] instead of "ok search for charms which support feature X" [20:30] then we'd have to have a feature-to-version grid, etc. [20:31] yup [20:41] hey marcoceppi [20:41] you were going to generate a tarball of all the charms for the OBs right? [20:41] hey jcastro [20:41] so we don't have to wait all day for charm get all iiirc [20:41] jcastro: I do do this, yes [20:41] link? [20:41] jcastro: http://people.canonical.com/~marco/mirror/juju/charmstore/ [20:42] it needs to be refreshed now that I look at it [20:42] unmomento === tdc_ is now known as tdc === kwmonroe_3tac is now known as kwmonroe === CyberJacob is now known as CyberJacob|Away