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:19 |
---|---|---|
sarnold | is there anything in the unit logs? | 00:20 |
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:21 |
bradm | there's no /var/lib/juju or /var/log/juju on the unit, there's no juju package installed | 00:22 |
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:23 |
bradm | maybe, and if I can add the juju stable ppa to the maas preseed as well, might help | 00:24 |
bradm | if I create the /var/lib/juju/nonce.txt by hand, everything starts moving forward | 01:05 |
=== fuzzy is now known as Fuzai | ||
=== Fuzai is now known as Ponyo | ||
ayr-ton | panic: Unexpected <nil> in storage-port: <nil>. Expected float64 or int. When juju status. juju 1.21-alpha1-trusty-amd64 | 02:18 |
ayr-ton | Someone knows how to fix it? | 02:19 |
jose | marcoceppi: hey, I'm having this problem, "Failed to request test // Only charmers can initiate reviews" | 03:09 |
=== uru_ is now known as urulama | ||
=== CyberJacob|Away is now known as CyberJacob | ||
=== CyberJacob is now known as CyberJacob|Away | ||
Xiaoqian | nobuto: ping | 09:04 |
zaargy | does juju autoheal services? if so can someone point me to how it works? thanks | 09:23 |
=== fabrice is now known as fabrice|lunch | ||
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:24 |
Odd_Bloke | Use case is this: I want to spin up a service and if it fails to deploy, remove it completely. | 11:25 |
Odd_Bloke | (Such that deploying again won't get an 'already deployed' error) | 11:26 |
Odd_Bloke | (Side note: is there documentation of the possible agent states?) | 11:31 |
Mmike | Odd_Bloke, can't you destroy your environment and try again? | 11:54 |
=== psivaa_ is now known as psivaa | ||
Odd_Bloke | Mmike: These are ephemeral services which I would expect to be deployed in to an existing environment. | 12:08 |
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:10 |
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:14 |
Odd_Bloke | If I change configuration options iwthin hooks, should I expect the changed values to show up in a 'juju get'? | 12:23 |
=== fabrice|lunch is now known as fabrice | ||
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:56 |
rcj | Is there a way to surface arbitrary data/status from a charm back to the cli? | 12:57 |
Odd_Bloke | "juju ssh cat ..."? ¬.¬ | 12:58 |
Odd_Bloke | Mmike: A first test suggests that blowing away the machine works. :) | 13:11 |
lazyPower | Odd_Blokejuju destroy-machine # --force | 13:31 |
lazyPower | then juju destroy-service | 13:31 |
Odd_Bloke | Cool, that's working for me. | 13:34 |
=== kentb-out is now known as kentb | ||
lazyPower | mwenning: ping | 14:43 |
mwenning | lazyPower, pong | 14:44 |
lazyPower | I know this is low priority atm, any updates on the dell cluster? | 14:44 |
mwenning | lazyPower, dell cluster? | 14:52 |
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:53 |
mwenning | lazyPower, ah. yes he did. Looks like Adam Israel looked at it yesterday and said the charm tests pass cleanly. | 14:56 |
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? | 14:57 |
aisrael | No. Charm proof passed cleanly, but I was unable to run the tests | 15:00 |
mwenning | aisrael, why couldn't you run the tests? | 15:01 |
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:04 |
mwenning | lazyPower, aisrael, I see. OK let me play with it. aisrael, what system were you using? | 15:05 |
aisrael | mwenning: Testing using the local provider under vagrant | 15:06 |
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:07 |
mwenning | Maybe I can log a clearer error message | 15:08 |
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:09 |
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 | 15:17 |
=== wedgwood1 is now known as wedgwood | ||
=== fabrice is now known as fabrice|familyti | ||
=== victorp_ is now known as victorp | ||
mwenning | kentb, good morning! | 16:07 |
kentb | mwenning: mornin! | 16:07 |
mwenning | They are discussing your charm on the internal #juju - | 16:07 |
mwenning | <lazyPower> 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:08 |
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:09 |
lazyPower | kentb: o/ | 16:10 |
=== fabrice is now known as fabrice|family | ||
kentb | o/ | 16:11 |
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:12 |
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:13 |
kentb | lazyPower: awesome. Thanks for all your help and review. | 16:14 |
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. | 16:15 |
=== 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 | ||
jose | jcastro: updating the Ubuntu on Air! calendar | 18:59 |
natefinch | jcastro: got a minute to talk about feature flags? | 19:34 |
=== roadmr_afk is now known as roadmr | ||
mbruzek | Does anyone in #juju know what charm can relate to couchdb's "db" relation? | 20:10 |
=== urulama is now known as urulama-afk | ||
marcoceppi | natefinch: I do | 20:20 |
* marcoceppi was off yesterday | 20:20 | |
natefinch | ahh cool | 20:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:26 |
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:27 |
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:28 |
natefinch | jcastro: cool | 20:29 |
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:30 |
natefinch | yup | 20:31 |
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:41 |
marcoceppi | it needs to be refreshed now that I look at it | 20:42 |
marcoceppi | unmomento | 20:42 |
=== tdc_ is now known as tdc | ||
=== kwmonroe_3tac is now known as kwmonroe | ||
=== CyberJacob is now known as CyberJacob|Away |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!