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