| babbageclunk | Ugh, environs imports api? | 00:21 |
|---|---|---|
| babbageclunk | But *I* want params to import environs! <pouts> | 00:23 |
| * babbageclunk pouts more. | 00:24 | |
| babbageclunk | thumper: ^ this seems wrong - environs shouldn't depend on api, right? | 00:25 |
| axw | babbageclunk: it shouldn't, but nor should params depend on environs | 00:27 |
| axw | IIRC environs depends on api because of api.Info | 00:27 |
| babbageclunk | axw: Why not? It depends on network. | 00:28 |
| axw | babbageclunk: it probably shouldn't | 00:28 |
| axw | babbageclunk: but mostly because environs has a complex mess of dependencies itself | 00:28 |
| babbageclunk | axw: Darn, my solution was going to be to move ProviderSpaceInfo into network. | 00:28 |
| axw | babbageclunk: params should be more or less self contained, we've just been lazy about it | 00:28 |
| axw | babbageclunk: what should be done is to have a separate struct in params specifically for de/serialisation | 00:29 |
| axw | babbageclunk: in a magical faraway time we hope to move the api code outside of core | 00:30 |
| axw | depending on more stuff in tree would make that more difficult | 00:30 |
| babbageclunk | axw: Hmm, I want to have a sensible place for conversion between params.RemoteSpace and environ.ProviderSpaceInfo. I can just have it in apiserver/application for now, but I'm going to need it in other facades. | 00:30 |
| babbageclunk | axw: I guess apiserver/common then? | 00:30 |
| babbageclunk | axw: But yeah, I see your point about pulling params out. | 00:31 |
| axw | babbageclunk: yeah, that's what we've done in the past | 00:31 |
| babbageclunk | axw: ok, thanks | 00:31 |
| thumper | yeah... some of those lower level things are ick | 00:32 |
| axw | veebers balloons: a third-party contributor has added support for openSUSE Leap as a new series ("opensuseleap"). how hard would it be to add it to the agents built in streams.canonical.com? | 00:33 |
| veebers | axw: hmm, I'm not sure, balloons ? ^^ | 00:36 |
| veebers | axw: I take it the agents are built elsewhere (i.e. not us) | 00:37 |
| axw | veebers: nobody is building it yet, I'm thinking it would be built by us | 00:37 |
| veebers | axw: I think it should be reasonably do-able, maybe straight forward even. Would like balloons opinion though before I promise anything ;-) | 00:41 |
| axw | babbageclunk: standup | 01:00 |
| babbageclunk | axw: sorry! | 01:00 |
| balloons | axw, the agents aren't generic? | 01:04 |
| balloons | axw, I imagine it would use the same agents; so it's simply a matter of us publishing them | 01:06 |
| axw | balloons: yeah, should be the same code as the other linux distros - I think we just need to update simplestreams? | 01:23 |
| balloons | axw, yes. I agree with veebers, very doable | 01:24 |
| axw | cool | 01:24 |
| axw | balloons: eventually we should also have a test or two for it, but that should probably wait until after the overhaul :) | 01:25 |
| balloons | axw, that's a question to ask back -- I guess we'll just use a cloud machine with opensuse, but which image, etc. Recommendations on a machine to run tests are welcome | 01:27 |
| axw | balloons: I don't know the answer to that yet. I guess on AWS, with updated image metadata. it's also possible to use LXD by modifying the image from linuxcontainers.org | 01:28 |
| axw | hml: reviewed | 01:36 |
| hml | axw: thx! | 01:36 |
| axw | hml: also I added to the release notes: " * MAAS 2.x block storage now works correctly with physical disks, when MAAS reports the WWN unique identifier (lp:1677001)." -- do you think that's sufficient? | 01:36 |
| axw | oh, I can add the one about SSH/bootstrap too. that's a big one | 01:37 |
| hml | axw: is it easy to descibe “now works correctly”? | 01:37 |
| axw | hml: yeah, a bit vague :) well it never worked at all before. I'll see if I can come up with something | 01:37 |
| axw | I guess just drop "correctly" | 01:38 |
| hml | axw: that helps. | 01:38 |
| hml | axw: how’s this for the ssh/bootrap: SSH Keys of the bootstrap host are now verified before bootstrap, reducing opportunities for MITM attacks (lp:1579593) | 02:09 |
| axw | hml: that sounds great, thank you | 02:09 |
| axw | hml: s/reducing/eliminating/ | 02:10 |
| hml | axw: eliminating the opportunity for an MITM attack? | 02:10 |
| axw | hml: yeah that sounds good | 02:11 |
| balloons | axw, hml, thumper, wallyworld, menn0, et la. We've lost our jenkins due to AWS hardware failure. It's unrecoverable. We're working on restoring from backup now, but CI will be offline until it's fixed. I expect at least another hour of downtime | 02:22 |
| thumper | hazaah | 02:23 |
| hml | balloons: no fun. | 02:23 |
| axw | balloons: oh my :( | 02:23 |
| menn0 | balloons: weeee | 02:24 |
| balloons | good fun eh? Turns our veebers, burton and I were kind of bored.. nothing to do clearly, so we needed some good fun | 02:24 |
| veebers | ^_^ | 02:25 |
| hml | g’night all | 02:31 |
| balloons | things appear to be largely settled all, ci runs are happening again. we;re monitoring | 03:43 |
| menn0 | balloons: nice work | 03:50 |
| babbageclunk | axw: Do you know what Space.IsPublic is for? | 04:00 |
| menn0 | babbageclunk: I just dig some digging and it looks like the command line always passes public=true | 04:04 |
| menn0 | babbageclunk: jam might be able to shed some more light but it seems like an unused concept | 04:04 |
| jam | I will do no such thing. :) | 04:04 |
| babbageclunk | menn0: Huh, so it doesn't do anything at the moment? | 04:04 |
| babbageclunk | jam: lol | 04:05 |
| jam | ouch balloons, nice recovery | 04:05 |
| babbageclunk | menn0: ha, looking in the discoverspaces worker it always creates them with false. | 04:06 |
| menn0 | awesome :/ | 04:12 |
| thumper | heh | 04:15 |
| thumper | FFS | 04:15 |
| * thumper is composing a looooong email | 04:16 | |
| babbageclunk | axw: I've just had an annoying thought - at the moment I'm getting the subnets in the space from the provider. Should I be getting them from state instead? | 04:16 |
| babbageclunk | axw: in which case, the provider attributes we're getting are really for the network, not the space, aren't they? :/ | 04:17 |
| axw | babbageclunk: sorry was out. sorry, not really following. what's wrong with getting subnets from the provider? | 04:34 |
| babbageclunk | axw: From that answer, nothing I guess - is the provider the authoritative source for that info then? | 04:36 |
| axw | babbageclunk: I think so? I'm not really sure - better ask jam | 04:36 |
| axw | babbageclunk: it may be that users can add them in manually too? | 04:37 |
| babbageclunk | axw: They can, but I think in that case we go back to the provider for extra information (like CIDR if it was added by providerid, or the inverse), so it seems like this is fine. | 04:38 |
| babbageclunk | I think I meant vice versa there. | 04:39 |
| babbageclunk | phew, just a crisis of confidence then. | 04:39 |
| axw | babbageclunk: sounds fine to me, but I don't really know for sure | 04:40 |
| babbageclunk | jam, what do you think? ^ | 04:41 |
| jam | babbageclunk: so, Public vs Private, AIUI, doesn't do anything today | 04:42 |
| jam | and is probably vestigle | 04:42 |
| jam | vestigal ? | 04:42 |
| jam | vesti-whatever | 04:42 |
| babbageclunk | vestigial | 04:42 |
| jam | :) | 04:42 |
| babbageclunk | ha | 04:43 |
| jam | babbageclunk: as for the rest... there are a couple of thoughts | 04:43 |
| jam | 1) In one very real sense, the Provider is authoritative for what subnets actually exist | 04:43 |
| * babbageclunk braces for impact | 04:43 | |
| jam | 2) In MAAS, the Provider is also authoritative for what Spaces exist | 04:43 |
| jam | (we can't create machines that have access to spaces that MAAS does not know about) | 04:44 |
| jam | 3) In other providers, Juju *has* to be authoritative about Spaces as a collection of subnets, because Providers don't aggregate subnets in that way | 04:44 |
| jam | unless we start tagging subnets by what space Juju thinks they are in. | 04:44 |
| jam | then you get into distributed controllers trying to manage tags on shared subnets, which is probably where we will go, but is messy | 04:44 |
| jam | babbageclunk: the other potential complicating factor is that we *might* need to track subnets that are not part of our model (other subnets for other models, etc) | 04:46 |
| jam | MAAS certainly lets you create spaces/subnets that are not managed by itelf | 04:46 |
| jam | itself | 04:46 |
| jam | and we'll likely have things like ingress/egress rules to subnets that are not ones we can actually put machines in. | 04:46 |
| thumper | veebers, balloons: the 5211 test run, how many of those results are real? | 04:46 |
| jam | I guess that was 4) | 04:46 |
| thumper | if it is all, then we have some serious problems | 04:47 |
| babbageclunk | hmm, so that makes Environ.ProviderSpaceInfo a bit hard to implement then (unless we start doing subnet tagging, which sounds nontrivial) | 04:47 |
| jam | babbageclunk: ProviderSpaceInfo is probably only valid for MAAS, and we have a field about ProviderHasDiscoverableSpaces | 04:47 |
| jam | let me check the actual boolean | 04:47 |
| jam | babbageclunk: SupportsSpaceDiscovery() | 04:48 |
| babbageclunk | jam: So the process should use ProviderSpaceInfo if the provider supports space discovery, but use the subnets from the space in state otherwise (since for other providers that's the only place that knows about the grouping)? | 04:52 |
| * veebers looks | 04:52 | |
| veebers | thumper: the proxy-* and deploy-* (where not joyent) are unknown. I can confirm them after dinner tonight (have this meeting coming up now) | 04:54 |
| babbageclunk | jam: I think the structure we have stores the right information, I just might need to get the information from different places if the provider doesn't know about spaces. | 04:54 |
| thumper | axw: I see that you marked bug 1677001 fix committed | 04:54 |
| mup | Bug #1677001: Storage remains in pending state <sts> <juju:Fix Committed by axwalk> <juju 2.0:Won't Fix> <juju 2.1:Won't Fix> <https://launchpad.net/bugs/1677001> | 04:54 |
| axw | thumper: yup | 04:54 |
| thumper | is the the Juju half of 1674148 ? | 04:54 |
| thumper | it seems weird that there were two bugs | 04:54 |
| * axw looking | 04:54 | |
| jam | babbageclunk: you and wpk should make sure to sync, as he's been looking to tweak some of this as well. But we should use Space Discovery to map what the Provider has into State objects | 04:54 |
| thumper | bug 1674148 | 04:54 |
| mup | Bug #1674148: hook for storage: storage already attached - Juju using already mounted disk <cdo-qa-blocker> <stable-blocker> <uosci> <juju:Confirmed> <MAAS:Fix Released by blake-rouse> <https://launchpad.net/bugs/1674148> | 04:54 |
| thumper | for mup | 04:54 |
| jam | and then everything uses State Objects from there out | 04:54 |
| babbageclunk | jam: So in that case maybe we should extend spaces in state to have the extra information we'd need to compare them across models. (I think this was what axw was pushing for a long time ago, d'oh.) | 04:56 |
| veebers | thumper: FYI just a quick look now (re-doing some jobs to rule out infra issues) a handful of those tests have passed since that run | 04:56 |
| babbageclunk | jam: Ok, I'll get in contact with wpk. | 04:56 |
| veebers | so re-running will give us a better picture | 04:56 |
| axw | thumper: I'm having trouble understanding andres' reply. so not sure yet, I'll try and dig into that after the travel call. | 04:56 |
| thumper | axw: thanks | 04:57 |
| veebers | thumper: ok, so can't promise anything but I've re-kicked the unexpected failed tests. Seeing the history of the re-kicked tests they should pass (unless the issue was fixed inbetween those builds) | 05:02 |
| menn0 | wallyworld: ping? | 05:21 |
| babbageclunk | menn0: He's on a swap day today | 05:21 |
| menn0 | babbageclunk: ah right | 05:21 |
| menn0 | i'll use email then | 05:21 |
| babbageclunk | (which isn't to say he won't be around) | 05:21 |
| axw | thumper: AFAICT, they're separate issues. one was due to MAAS mapping block devices in a way we're not expecting, and the other is due to us not extracting the right block device details from the MAAS response, even when they're mapped correctly | 05:37 |
| axw | thumper: I'm not sure if there's any issues remaining - I'll ask Ante | 05:37 |
| thumper | ok | 05:37 |
| thumper | cheers | 05:37 |
| * thumper is done for today | 05:37 | |
| rogpeppe | axw, wallyworld: hiya, i'm after a review of these PRs if you have a moment at some point https://github.com/juju/juju/pull/7327 https://github.com/juju/juju/pull/7324 | 05:55 |
| axw | rogpeppe: okey dokey, will look shortly | 06:13 |
| rogpeppe | axw: tyvm | 06:13 |
| rogpeppe | axw: BTW, what is the "grant" CI job that fails so often? | 06:13 |
| axw | rogpeppe: not sure. I think to do with grant/revoke permissions? | 06:14 |
| rogpeppe | axw: i'm getting more failures than successes with it, which seems a bit counterproductive | 06:14 |
| axw | rogpeppe: I believe the QA team are looking into it | 06:15 |
| rogpeppe | axw: cool | 06:15 |
| rogpeppe | axw: do we have a QA team now? | 06:15 |
| axw | rogpeppe: yes: balloons, veebers, and burton-aus | 06:16 |
| rogpeppe | axw: ah, good to know which people, thanks | 06:16 |
| axw | rogpeppe: LGTM, and thanks for tidying up - much nicer | 06:32 |
| rogpeppe | axw: np, ta! | 06:33 |
| rogpeppe | axw: i'm really glad to finally see the back of PrepareEndpointsForCaching | 06:33 |
| rogpeppe | axw: i actually did most of that PR back in October and only just had reason to finally get it landed | 06:34 |
| === frankban|afk is now known as frankban | ||
| wpk | hm, do we really need DiscoverSpaces API? It seems redundant for Spaces API, it's only used by discoverspaces worker (and it can just as easily use spaces API) | 10:18 |
| wpk | jam: ^^^ | 10:18 |
| jam | wpk: DiscoverSpaces is a worker/agent API, vs Spaces is a Client API | 12:03 |
| jam | I'd rather we not conflate them. | 12:03 |
| jam | wpk: generally workers are meshed with a corresponding API that makes it clearer what surface interaction we have | 12:05 |
| wpk | ok | 12:08 |
| wpk | so WatchSpacesSyncSettings should be in discoverspaces, ResyncSpaces in spaces? | 12:08 |
| wpk | ok, I see it's even guaranteed at the top level | 12:22 |
| jam | wpk: yes | 12:58 |
| === mup_ is now known as mup | ||
| === frankban is now known as frankban|afk | ||
| mup | Bug #1690166 opened: Juju add-machine CentOS failed with "no tools found" <juju-core:New> <https://launchpad.net/bugs/1690166> | 15:27 |
| mup | Bug #1690166 changed: Juju add-machine CentOS failed with "no tools found" <juju-core:New> <https://launchpad.net/bugs/1690166> | 15:33 |
| mup | Bug #1690166 opened: Juju add-machine CentOS failed with "no tools found" <juju-core:New> <https://launchpad.net/bugs/1690166> | 15:36 |
| rogpeppe | i brushed off my old branch for giving access to juju API information, tired of refactoring it every time I want to use it. anyone wanna give it a review? https://github.com/juju/juju/pull/7331 | 17:52 |
| zeestrat | Hey, is there anything I can do to help y'all reproduce/fix https://bugs.launchpad.net/juju/+bug/1680392 ? (It is still tagged with the wrong milestone btw) | 18:36 |
| mup | Bug #1680392: Model migration fails on large model <juju:New for thumper> <https://launchpad.net/bugs/1680392> | 18:36 |
| === frankban|afk is now known as frankban | ||
| arosales | Hello, is there a arch docc that describes communication between Juju and MAAS to provision services? | 19:58 |
| arosales | axw: ^ any thoughts or recommendations? | 20:37 |
| * arosales didn't see thumper around | 20:37 | |
| babbageclunk | wallyworld: ping? | 22:13 |
| wallyworld | yo | 22:13 |
| babbageclunk | wallyworld: got time for a hangout? | 22:13 |
| wallyworld | sure | 22:14 |
| babbageclunk | wallyworld: on 1:1? | 22:14 |
| wallyworld | ok | 22:14 |
| === frankban is now known as frankban|afk | ||
| hml | wallyworld: 1 line PR: https://github.com/juju/juju/pull/7333 :-) easy review? | 23:28 |
| wallyworld | sure | 23:28 |
| wallyworld | lgtm | 23:29 |
| hml | thx | 23:31 |
| thumper | wallyworld: who has most experience reviewing providers at the moment? | 23:31 |
| thumper | wallyworld: I need someone to glance over some code and see if it is going in the right direction' | 23:31 |
| thumper | doesn't have to be a full review, because the code isn't ready | 23:32 |
| wallyworld | andrew would be the best choice right now | 23:32 |
| thumper | but more they want to know if what they have is a good start or not | 23:32 |
| thumper | wallyworld: when does axw turn up? | 23:32 |
| wallyworld | real soon | 23:32 |
| axw | thumper: I'm on | 23:32 |
| thumper | axw: hey | 23:32 |
| thumper | wallyworld, axw: if you could both join https://hangouts.google.com/hangouts/_/canonical.com/provider-x briefly, that'd be swell | 23:33 |
| axw | arosales: hey again :) I'm not aware of any docs. | 23:33 |
| axw | ok | 23:33 |
| arosales | axw: thanks for the reply and info | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!