| babbageclunk | wallyworld: should we fallback to release anytime we'd use devel - even if the user has specified devel explicitly? | 02:47 |
|---|---|---|
| wallyworld | babbageclunk: yeah, IMO. develop just indicates level of risk the user wants. | 02:48 |
| babbageclunk | ok | 02:48 |
| wallyworld | we need to behave linke snaps | 02:48 |
| wallyworld | *like | 02:48 |
| babbageclunk | wallyworld: I'm not sure how snaps work in this case | 02:53 |
| wallyworld | babbageclunk: you need to read up on them then :-) | 02:56 |
| babbageclunk | wallyworld: trying - any pointers? The closest I can find is that you can publish to multiple channels when publishing - but that's not the case here is it? | 02:57 |
| wallyworld | no, this isn't about publishing but the user specifying the level of risk they are willing to accept | 02:58 |
| wallyworld | i can try and find some snappy docs | 02:58 |
| babbageclunk | Right, but it seems like you could publish to beta without publishing to edge, and then someone who was on edge wouldn't see that version? | 02:59 |
| babbageclunk | I'm reading the docs on snapcraft.io | 02:59 |
| wallyworld | babbageclunk: they would see a higher version in beta | 03:00 |
| wallyworld | if published there | 03:00 |
| babbageclunk | whoa, there are channel branches? | 03:01 |
| wallyworld | babbageclunk: you always get the highest version - the channel determines how far down you look to see what's available | 03:01 |
| wallyworld | yeah | 03:01 |
| wallyworld | you can create a short lived snap (30 days default) from a branch | 03:01 |
| wallyworld | a feature branch | 03:01 |
| wallyworld | if you want longer you need to pay | 03:02 |
| babbageclunk | https://forum.snapcraft.io/t/channel-terminology-and-policy/551 | 03:03 |
| babbageclunk | Ok, I think I get the fallback between risk levels (modulo the talk about closing which I guess doesn't matter here). | 03:09 |
| wallyworld | babbageclunk: correct, closing is not relevant here | 03:10 |
| babbageclunk | wallyworld: what about the other stream levels (proposed, testing) | 03:10 |
| wallyworld | ignore testing. we don't really use proposed in practice i don't think, but we could sp probably should support it | 03:11 |
| babbageclunk | I think it makes sense for all of them to fallback to released, right? | 03:11 |
| wallyworld | it's almost like testing < develop < proposed < released | 03:11 |
| babbageclunk | But if they all had released after them that would be right? Or should I only have the fallback for develop? | 03:12 |
| babbageclunk | wallyworld: ^ | 03:14 |
| wallyworld | babbageclunk: sorry, on call, so distracted | 03:14 |
| wallyworld | the above order would be analogous to snap channels | 03:14 |
| babbageclunk | wallyworld: okthanks! | 03:20 |
| wallyworld | babbageclunk: sorry, out of meeting now if you still had questions | 04:24 |
| babbageclunk | wallyworld: no, I think I understand - I've made everything follow that fallback, just going through the places that call PreferredStream now to make them do the fallback if they need to. Thanks! | 04:26 |
| wallyworld | babbageclunk: ok, sgtm | 04:29 |
| axw | wallyworld: still at the guessing phase, but I have a suspicion that it's nothing to do with skews now. the logs say that the leadership worker is failing with "not found" and "state changing too quickly; try again soon" | 04:57 |
| axw | wallyworld: from looking at the code, that doesn't make sense... unless there's 2 leadership workers | 04:57 |
| wallyworld | interesting | 04:57 |
| axw | wallyworld: we run a leadership worker *per state* | 04:57 |
| axw | wallyworld: so one might be expiring stuff while the other is extending | 04:58 |
| wallyworld | oh dear | 04:58 |
| axw | wallyworld: I think the best thing to do would be to make it so we run one per model | 04:58 |
| wallyworld | axw: that sounds logical, one per state sounds crazy | 05:01 |
| wallyworld | axw: although i think there's an aspect where maybe there's a controller level doc, rather than per model | 05:03 |
| wallyworld | the clock#singular-controller lease doc | 05:03 |
| axw | wallyworld: I'm just talking about the applications one atm | 05:03 |
| wallyworld | ah ok | 05:03 |
| wallyworld | in that case sounds good to do | 05:04 |
| axw | wallyworld: I think we'd want a per-machine one for singular | 05:04 |
| axw | but I'll leave that for now | 05:04 |
| wallyworld | per controller i think? | 05:06 |
| axw | wallyworld: each controller machine needs to run the worker for failover, that's how the singular workers are implemented | 05:13 |
| axw | they'll each try to claim, but only one will succeed | 05:13 |
| * axw bbs | 05:14 | |
| thumper | wallyworld: https://github.com/juju/names/pull/84 | 05:21 |
| wallyworld | thumper: looking | 05:26 |
| wallyworld | thumper: lgtm | 05:28 |
| === frankban|afk is now known as frankban | ||
| === hazmat_ is now known as hazmat | ||
| === akhavr1 is now known as akhavr | ||
| === frankban is now known as frankban|afk | ||
| axw | wallyworld: I was wrong, when we expire the lease, the other manager will refresh its cache when the txn fails. so :/ | 09:47 |
| axw | still shit, but probably not shit enough to continue trying to untangle everything | 09:47 |
| axw | not sure why it's getting "state changing too quickly errors" though... that refresh should fix it | 09:50 |
| === frankban|afk is now known as frankban | ||
| redir | curl https://s3.amazonaws.com//aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O | 16:42 |
| redir | chmod +x ./awslogs-agent-setup.py | 16:42 |
| redir | jmeta-u./awslogs-agent-setup.py -n -r us-east-1 -c awslogs.confw | 16:43 |
| redir | w | 16:43 |
| redir | whoops | 17:01 |
| redir | somehow I found the shortcut to tell terminator to broadcast to all terminal windows | 17:01 |
| redir | :) | 17:01 |
| redir | glad it wasn't a secret | 17:02 |
| === frankban is now known as frankban|afk | ||
| thumper | wallyworld: I think we should skip the release call again | 21:20 |
| thumper | we know what we are doing | 21:20 |
| wallyworld | ok | 21:32 |
| thumper | wallyworld: https://github.com/juju/juju/pull/7943 | 21:36 |
| wallyworld | ok | 21:36 |
| thumper | wallyworld: I'm confused, got a minute? | 21:38 |
| wallyworld | sure | 21:38 |
| thumper | 1:1 HO | 21:38 |
| wallyworld | thumper: the hamster died, but we had finished | 21:52 |
| thumper | yeah | 21:52 |
| babbageclunk | wallyworld: I've just clicked that environs.Tools.Tools already does fallback between custom source and public source. | 22:41 |
| babbageclunk | wallyworld: implementation wise it's simpler for me if the fallback goes: | 22:41 |
| babbageclunk | custom/devel, public/devel, custom/released, public/released. Is that crazy or alright? | 22:42 |
| wallyworld | babbageclunk: i'd have to re-read the code - i didn't think custom came into it for agent binaries, just image metadata | 22:44 |
| wallyworld | for agent binaries, i thought we just had agent-stream to tweak things | 22:45 |
| babbageclunk | sorry, thinko'd the function name: environs/tools.FindTools | 22:46 |
| babbageclunk | It uses GetMetadataSources which adds one for agent-metadata-url and one for the default public source. | 22:47 |
| wallyworld | we may use custom if agent binaries are sourced from metadata supplies at bootstrap | 22:47 |
| wallyworld | but then it becomes custom > testing > develop > proposed > released | 22:48 |
| babbageclunk | No, custom has streams in it. | 22:49 |
| babbageclunk | So custom/public (and also cloud sources) are orthogonal to stream. | 22:50 |
| hml | babbageclunk: joining us? we miss you | 23:35 |
| hml | :-) | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!