=== scuttlemonkey is now known as scuttle|afk [09:11] and charmers around? I could do with a review of https://code.launchpad.net/~james-page/charm-helpers/liberty-versioning/+merge/264998 [12:19] marcoceppi: are there any py3 compatible rules/guidelines/points for charmhelpers? (is it even a thing?), #askingforafriend [12:25] wesleymason: first of all \o/ on duckduckgo [12:26] :D [12:26] wesleymason: I'm not sure I understand the question, charmhelpers should be py2/py3 compat if that's what you're asking [12:26] marcoceppi: yes, partially, but also is there anything that needs to be considered (e.g. any bits that won't work) [12:27] wesleymason: not that I'm aware of, if you come across any issues though, let me know [12:27] marcoceppi: hi, it's a bit strange it doesn't say so in HACKING for example though [12:27] wesleymason: The tests get run against both py2 and py3, and whenever someone breaks py3 I bitch about it and fix it. [12:28] stub: cool [12:28] wesleymason: the biggest headache is subprocess.check_call and friends, which returns bytes by default and charms like to call a lot. [12:28] eurgh [12:29] wesleymason: easy peasy, just remember to add 'universal_newlines=True' on every call. [12:29] pedronis: sadly that hacking doc hasn't been updated in over 300 revisions :\ if you have text taht would fit better in there lmk or submit a patch! [12:29] stub: 🙌 [12:29] stub: have you played much with tox? [12:29] (╯°□°）╯︵ ʃʃɐɔ‾ʞɔǝɥɔ [12:30] marcoceppi: No, but it would be what I would first look at if I needed something like buildout/tox/etc. [12:31] stub: I think we're going to add it to charm-helpers instead of what currently performs the unittests. So far it's been added to a number of other tools and it's a very nice interface [12:32] marcoceppi: yup. Talk to barry on the internal chans or the guys in #launchpad-dev if you want - I think they might know the gory details. [13:30] jamespage, I had to re-run amulet tests again due to a timeout on the undercloud (i guess?) but everything is green now. Take a look when you get a chance and let me know: https://code.launchpad.net/~ddellav/charms/trusty/glance/upgrade-action/+merge/265592 === xwwt is now known as xwwt-afk === scuttle|afk is now known as scuttlemonkey [16:52] can you not upgrade a local charm with a local charm? It's giving me an error that local:trusty/mycharm is an invalid charm name [16:52] er service name [16:53] hatch: you can upgrade a local charm with a local charm [16:53] do you have $JUJU_REPOSITORY set? [16:53] yeah I literally just changed `deploy` to `upgrade-charm --force` [16:54] ah [16:54] you dont need local:foo/bar with upgrade charm [16:54] just the name of the service is fine [16:54] juju upgrade-charm --force bar [16:54] juju will do the source resolution for you since it has a local: reference listed in the output [16:55] you can verify w/ juju status [16:55] ahh there we go [16:55] quite an odd failure case [16:56] i dont think its an odd failure. upgrade-charm depends on a service directive. suppose you deployed 2 services, same charm, different names [16:56] and you only want to upgrade a single service, not both [16:56] hatch: pah, you should consider yourself lucky. Using local charms is getting easier. Back in the day it was seriously difficult :P [16:56] ^ [16:57] lazyPower ahh I suppose that makes sense [16:58] hatch: you know about dhx and it's syncing abilities right? (automagical syncing of locally editted charm to deployed environment) [16:58] hatch: context sensitivity is arguably one of the nicer things about juju :) [16:58] lazyPower but the error messages are real poor [16:58] sparkiegeek: have you tried sync-watch? where it works in reverse. Edit locally - force push remotely [16:59] hatch: a bug would go a long way [16:59] lazyPower: ah, yeah that's the one I meant [16:59] I had a typo in my metadata.yaml, so it gave me an error about that and then said it couldn't find the charm lol [16:59] juju sync-watch? [17:01] lazyPower I don't think this upgrade charm is actually working [17:01] hatch: https://github.com/juju/plugins/pull/53 [17:01] hatch: what appears to be the behavior? [17:01] it's uploading the code, but not re-running the install hook [17:01] is it not supposed to re-run the install hook if there is no config-changed? [17:01] do you have a hook trapped on the unit? and i dont think upgrade-charm implicitly calls the install hook [17:01] it calls upgrade-charm => config-changed [17:03] ohh yesterday marcoceppi said that it called the install hook if there was no upgrade-charm [17:03] marcoceppi: upgrade-charm calls the install hook? wat? [17:03] I mean, it kind of makes sense [17:03] hatch: it may, but i'm not aware of that. i defer to the answerer [17:04] the install hook is the place that would install deps [17:04] which may change between versions [17:04] ehhh [17:04] i dont know that i agree with that [17:04] lazyPower well it's not calling mine [17:04] lazyPower you don't install sysdeps in the install hook? [17:04] i mean if you want that behavior, implicitly call install from your upgrade-charm [17:04] otherwise, why does it make sense to implicitly call it? [17:06] hatch: i'm going to grab a bite to eat. be back in 10 to 15. [17:06] but, one thing before i go [17:06] you should have at bare minimum seen it call config-changed [17:06] lazyPower sure np [17:06] if upgrade-charm didn't call config-changed, something is either trapped, in error state, or broken [17:06] ok lemme check that out [17:08] lazyPower I can confirm that config-changed was not called, the unit is in the install hook failed state from previous runs but I thought that --force should 'just do it' [17:12] hatch: --force only force upgrades the charm code [17:13] if your unit is in failure state, you still need to resolve --retry [17:14] lazyPower ohh...that'll teach me to assume === xwwt-afk is now known as xwwt [17:18] lazyPower so if a hook is in an error state and you try and upgrade it without --force it won't copy the files for any unit? [17:18] it will upgrade the charm, but it queues, and the upgraded code wont land until that upgrade-charm cycle is reached [17:18] the --force kind of stealth bombs the upgraded hook code in place [17:20] so you would end up in a state where some units have the upgraded code but the ones with hook errors won't? [17:21] hatch: they will eventually reach consistency, as that upgrade-charm hook is queued [17:21] but correct. the units in error state will be in halted execution state [17:21] so the ones that are not in error will continue to cycle as you would expect [17:21] right, but the admin would have to resolve all hook errors first? [17:22] yep [17:24] lazyPower ok and is there a way to force resolve all errors? When the install hook fails you have to resolve all the next hooks to get it into a functional state [17:25] just juju resolved or juju resolved --retry [17:26] oh ok so I'll have to run `juju resolved` three times if the install hook fails [17:45] mbruzek: marcoceppi - if either of you have a moment, this was a priority fix that just got proposed for the store - https://code.launchpad.net/~kubernetes/charms/trusty/etcd/trunk/+merge/267696 [17:46] lazyPower: you need better bzr foo [17:46] ? [17:46] <<< TREE >>> MERGE-SOURCE [17:46] You have merge conflict messages in the readme. [17:47] i dont even know where that came from [17:47] it was not a merge [17:47] * lazyPower eyeballs the github repository [17:47] * mbruzek coughs 'vendor' [17:47] mbruzek: you're welcome to contribute if you dislike how it works :) [17:47] You are right. [17:48] This isn't in the local copy [17:48] i dont know where that came from [17:48] and worse yet, its a whitespace collision [17:49] IBM has problems with spaces and tabs too don't feel bad [17:49] mbruzek: feeling spunky today huh? [17:50] mbruzek: doesn't exist in the repo either [17:50] http://bazaar.launchpad.net/~kubernetes/charms/trusty/etcd/trunk/view/head:/README.md [17:51] lazyPower: I was going off the diff in the merge propsal [17:51] the readme diverged from the store charm and whats in ~kubernetes [17:52] How would that happen? [17:52] Is he charm store touching a file? [17:52] mbruzek: you broke it w/ rev 15 [17:52] http://bazaar.launchpad.net/~charmers/charms/trusty/etcd/trunk/revision/15 [17:52] made changes to the push copy @ the store that dont reflect whats in ~kubernetes [17:53] arigato obama san [17:53] also since we're in here [17:53] we have a typo. "Man"-tainers [17:53] :D [17:54] yeah I noticed that too. My change was to clean up the promulgated namespace [17:54] mbruzek: @_@ you make my life difficult [17:55] The Force is strong with this one [17:55] i'm fixing it tho [17:55] 1 sec [17:57] mbruzek: rev 17 should have that backported fix [17:57] mbruzek: ploz stop diverging our namespace <3 [17:57] do proper merges and this wouldn't happen. [17:57] :) [19:15] lazyPower are there any restrictions for hook scripts accessing other files? They run as root correct? [19:15] correct, its run as root. [19:16] odd....the script can't access the file, says it doesn't exist, but when I run it manually as root it works [19:17] lazyPower and `juju run` executes the files in the hook context based from their directory? [19:17] hatch: juju run `whoami && pwd` [19:18] oh...it's running it as the cli user [19:18] :) [19:18] wait nm heh [19:19] depends on if you're running it at --unit --service level [19:19] lazyPower so hooks are executed from the hooks dir or from the charm dir? [19:19] juju run is giving me the charm dir [19:20] from $CHARM_DIR [19:20] ahhhh [19:20] damn [19:20] ok that's why it's not working [19:23] thanks again lazyPower [19:23] cheers :) [20:27] hi juju team, is there a way to set --keep-broken after bootstrap? === scuttlemonkey is now known as scuttle|afk [23:46] i'm confused. juju bugs are tracked on github but juju-core bugs are tracked on launchpad? [23:47] and what's the difference between these two "projects"?