| axw | wallyworld: I put it on the calendar already, but just reminding you: I'm away this coming Fri-Mon | 01:53 |
|---|---|---|
| axw | babbageclunk: do you have time to be a second reviewer for https://github.com/juju/juju/pull/7984? | 02:03 |
| babbageclunk | axw: sure | 02:04 |
| babbageclunk | axw: net line reduction automatic approval | 02:04 |
| axw | :) | 02:05 |
| babbageclunk | I mean, ok, I'll actually read it | 02:05 |
| axw | wallyworld: what version of Juju was the relation bug found in? beta1? I'm failing to repro with wordpress-mysql. just noticed bug says mediawiki, will try that - can't see why it'd matter tho | 03:33 |
| thumper | https://github.com/juju/juju/pull/7987 fixes constraints handling with bundle deployment. | 03:39 |
| wallyworld | axw: i tested in tip of develop last week. found it by remove-relation <id> from the offering model, and then add-relation again from the consuming model | 03:39 |
| wallyworld | axw: i'll try and repro | 03:40 |
| axw | wallyworld: ah, I just removed it from the consuming model. I'll try that way | 03:41 |
| babbageclunk | wallyworld: one of the migration test failures looked like a timeout, the other one looks like a genuine problem - we require a model type when importing a model, but older versions don't set one when exporting. | 03:41 |
| wallyworld | ah | 03:41 |
| wallyworld | i guess default to IAAS | 03:41 |
| babbageclunk | creating a bug now | 03:41 |
| babbageclunk | yu[ | 03:41 |
| babbageclunk | p | 03:41 |
| veebers | babbageclunk: I don't think it's a timeout as the whole test is about 15 minutes, timeout is 50m. That being said I'm unsure why that log just stops | 03:41 |
| wallyworld | veebers: you're back! | 03:42 |
| babbageclunk | veebers: hmm | 03:42 |
| veebers | wallyworld: hey o/ aye I am, first day back today :-) | 03:42 |
| axw | wallyworld: seems to be some other bug though. I removed relation between hosted mysql and wordpress. something caused wordpress unit to restart, and now it's in an error loop complaining about the relation directory being non-empty | 03:42 |
| wallyworld | interesting. i wonder how mediawiki behaves | 03:43 |
| veebers | babbageclunk: let me have another quick look at those logs | 03:43 |
| wallyworld | thumper: lgtm | 03:45 |
| axw | wallyworld: remove-relation on the offering side didn't trigger anything. I'll look into the other thing I found | 03:46 |
| wallyworld | righto, i'll try and reproduce | 03:46 |
| axw | I mean didn't trigger any errors... re-adding relation just worked | 03:46 |
| wallyworld | axw: you tested with lxd? | 03:46 |
| axw | wallyworld: yep | 03:47 |
| axw | wallyworld: and now the remote relation worker seems to have stopped working: ERROR juju.worker exited "mysql": watching status for offer: verification failed: macaroon not found in storage | 03:52 |
| axw | "juju offers" shows no relation, though the client thinks it has related | 03:52 |
| wallyworld | axw: hmmm, looks like macaroon has got cleaned up on offer side but we are not minting a new one | 03:53 |
| wallyworld | axw: i have a meeting now but will debug a bit when i am free | 04:00 |
| axw | wallyworld: sure. I'll keep digging | 04:00 |
| thumper | wallyworld: there in a minute | 04:01 |
| axw | so if I remove the remote app from the consuming side, and then re-relate, it fixes it up | 04:02 |
| wallyworld | axw: that would be because that causes a RegisterRelation which mints a new macaroon | 04:05 |
| axw | wallyworld: the remote relation worker should be re-registering if the relation was removed. I suppose the worker isn't tidying up properly. will look more after lunch | 04:08 |
| wallyworld | axw: yeah, i'll look between meetings if i get time | 04:09 |
| babbageclunk | axw: fixing this - https://bugs.launchpad.net/juju/+bug/1728486 | 04:30 |
| mup | Bug #1728486: migration: allow model type to be blank when importing <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1728486> | 04:30 |
| babbageclunk | axw: I should obviously make the reading side accept blank. | 04:30 |
| babbageclunk | axw: Do you think I should make sure the exporting side also sets model type? | 04:31 |
| babbageclunk | axw: I think the intention was that the 2.2 branch would export models as v3, so type would be set automatically. | 04:32 |
| axw | babbageclunk: sorry just looking at the code, one minute | 04:32 |
| babbageclunk | axw: but the description dependency was updated in 2.2 for some unrelated change and now it emits v4 models, but with blank type. | 04:33 |
| babbageclunk | axw: thanks | 04:33 |
| axw | babbageclunk: ugh, that's unfortunate. yes I think the exporter should be required to set the model type for v4 | 04:35 |
| axw | babbageclunk: reading side shouldn't have needed to accept blank, but obviously will now | 04:35 |
| babbageclunk | axw: do you think I should set the default in description or in migration_export.go? | 04:36 |
| axw | babbageclunk: I think migration_export.go, I think description should be relatively dumb - not making choices, just checking the choices you made are correct | 04:38 |
| babbageclunk | axw: cool, thanks! | 04:39 |
| thumper | later peeps | 05:13 |
| * thumper EODs | 05:13 | |
| wallyworld | jam: did you forget to add a video call? | 05:29 |
| jam | wallyworld: I did, but I just added "caas" | 05:30 |
| jam | I will brt, need to use a restroom | 05:30 |
| === frankban|afk is now known as frankban | ||
| axw | wallyworld: the unitcount refcounting on relations for local vs. remote units looks dodgy. we never increment for remote units, but we sometimes decrement for remote | 07:36 |
| axw | that might explain the "permission denied" error I saw | 07:36 |
| axw | wallyworld: I think we should be maintaining relation.unitcount for both local and remote units. i.e. unitcount == number of units in scope, at all times | 08:41 |
| axw | wallyworld: otherwise you can remove the relation without taking units out of scope | 08:41 |
| axw | wallyworld: why does having a time-before caveat stop things from working? you should still get a verification error? | 13:52 |
| mup | Bug #1726945 changed: [2.3] consume feature hard to manage <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1726945> | 15:23 |
| mup | Bug #1726945 opened: [2.3] consume feature hard to manage <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1726945> | 15:29 |
| mup | Bug #1726945 changed: [2.3] consume feature hard to manage <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1726945> | 15:39 |
| === frankban is now known as frankban|afk | ||
| bdx | heyyyyy | 21:12 |
| bdx | I've got this model in a crazy stuck state on 2.3-beta2.5 | 21:12 |
| bdx | lol | 21:12 |
| bdx | 2.3-beta2.1 | 21:12 |
| bdx | whoops | 21:13 |
| bdx | ha | 21:13 |
| bdx | not sure if anyone wants to take a gander | 21:13 |
| bdx | http://paste.ubuntu.com/25854148/ | 21:13 |
| bdx | I can't get the units es-lxd-test/{0,1} to go away | 21:14 |
| bdx | I mean, its not really a big deal to me | 21:14 |
| bdx | but, possibly its a difficult situation to repro | 21:14 |
| bdx | and someone might want to hop in and take what they need | 21:15 |
| bdx | I'll leave it up for the next day or so | 21:15 |
| bdx | if anyone wants to take a closer look, ping me | 21:15 |
| bdx | I'll create a bug anyway | 21:15 |
| bdx | well, not that tough | 21:17 |
| bdx | https://bugs.launchpad.net/juju/+bug/1728721 | 21:19 |
| mup | Bug #1728721: units stuck in model after failed deploy <juju:New> <https://launchpad.net/bugs/1728721> | 21:19 |
| hml | bdx: do you have a build number for your juju 2.3-beta2.1? | 21:29 |
| bdx | hml: its whats in the beta snap channel | 21:33 |
| bdx | rev: 2640 | 21:33 |
| hml | bdx: ty | 21:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!