| === scuttlemonkey is now known as scuttle|afk | ||
| jamespage | and charmers around? I could do with a review of https://code.launchpad.net/~james-page/charm-helpers/liberty-versioning/+merge/264998 | 09:11 |
|---|---|---|
| wesleymason | marcoceppi: are there any py3 compatible rules/guidelines/points for charmhelpers? (is it even a thing?), #askingforafriend | 12:19 |
| marcoceppi | wesleymason: first of all \o/ on duckduckgo | 12:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| stub | marcoceppi: No, but it would be what I would first look at if I needed something like buildout/tox/etc. | 12:30 |
| 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:31 |
| 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. | 12:32 |
| 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 | 13:30 |
| === xwwt is now known as xwwt-afk | ||
| === scuttle|afk is now known as scuttlemonkey | ||
| 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:52 |
| 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:53 |
| 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:54 |
| lazyPower | you can verify w/ juju status | 16:55 |
| hatch | ahh there we go | 16:55 |
| hatch | quite an odd failure case | 16:55 |
| 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:56 |
| hatch | lazyPower ahh I suppose that makes sense | 16:57 |
| 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:58 |
| 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? | 16:59 |
| 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:01 |
| 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:03 |
| 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:04 |
| 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:06 |
| 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:08 |
| lazyPower | hatch: --force only force upgrades the charm code | 17:12 |
| lazyPower | if your unit is in failure state, you still need to resolve --retry | 17:13 |
| hatch | lazyPower ohh...that'll teach me to assume | 17:14 |
| === xwwt-afk is now known as xwwt | ||
| 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:18 |
| 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:20 |
| 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:21 |
| lazyPower | yep | 17:22 |
| 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:24 |
| lazyPower | just juju resolved or juju resolved --retry | 17:25 |
| hatch | oh ok so I'll have to run `juju resolved` three times if the install hook fails | 17:26 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| mbruzek | IBM has problems with spaces and tabs too don't feel bad | 17:49 |
| lazyPower | mbruzek: feeling spunky today huh? | 17:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| mbruzek | The Force is strong with this one | 17:55 |
| lazyPower | i'm fixing it tho | 17:55 |
| lazyPower | 1 sec | 17:55 |
| 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 | :) | 17:57 |
| 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:15 |
| 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:16 |
| 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:17 |
| hatch | oh...it's running it as the cli user | 19:18 |
| lazyPower | :) | 19:18 |
| hatch | wait nm heh | 19:18 |
| 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:19 |
| lazyPower | from $CHARM_DIR | 19:20 |
| hatch | ahhhh | 19:20 |
| hatch | damn | 19:20 |
| hatch | ok that's why it's not working | 19:20 |
| hatch | thanks again lazyPower | 19:23 |
| lazyPower | cheers :) | 19:23 |
| mwenning | hi juju team, is there a way to set --keep-broken after bootstrap? | 20:27 |
| === scuttlemonkey is now known as scuttle|afk | ||
| pmatulis | i'm confused. juju bugs are tracked on github but juju-core bugs are tracked on launchpad? | 23:46 |
| pmatulis | and what's the difference between these two "projects"? | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!