[00:00] menn0: you have a sec? https://hangouts.google.com/hangouts/_/canonical.com/ian-horatio [00:30] axw or redir or wallyworld: http://reviews.vapour.ws/r/5408/ pls [00:30] menn0: otp, will look soon [00:34] menn0: looking [00:39] redir: thanks [00:54] redir: are you a graduated reviewer yet? [00:54] axw: nope [00:54] IANAGR [00:54] axw: do we have the idea of graduating reviewers, now that we have a checklist? [00:54] anastasiamac: dunno [00:55] axw: for graduating idea to work, each un-graduate reviewer should have a graduated mentor. I don;t think that was followed thru... [00:59] anastasiamac: we used to have achecklist in a spreadsheet, I presume is no longer there [01:00] perrito666: m talking about code review checklist on wiki [01:00] perrito666: gimme a sec to pull up the link.. [01:00] ahh I mixed what you where saying [01:00] perrito666: https://github.com/juju/juju/wiki/Code-Review-Checklists [01:01] anastasiamac: yes, that one is always open [01:17] anastasiamac: do you have time for a review? http://reviews.vapour.ws/r/5407/ [01:17] fairly straight forward [01:17] axw: for u- always :D [01:30] anastasiamac redir: thanks both for the reviews [01:30] axw: it's an awesome addition! thanks for doing it :) [01:51] axw: np [02:11] menn0: I haven't been able to make it through the QA steps as expected. I have to go now [02:11] but I'll look when I get home and fill in details [02:11] no QUIES... i n logs [02:11] bbl [02:13] axw: wallyworld: scream-related http://reviews.vapour.ws/r/5411/ :) [02:13] joy [02:14] wallyworld: this one is the easiest by far :D [02:15] anastasiamac: did you run the QA steps on one of those at least? [02:15] "desired provider" is a bit vague :) [02:16] yes. i'll change to "from the list above" or could just list them in [,,,] [02:16] anastasiamac: as long as a live test has been done, I'm happy [02:19] axw: \o/ i'll double-;triple-check tonight :) don't need it in beta15 anyway \o/ but it will make the diff with anything else I propose so much more manageable :) [02:19] so long as supportedArchitecures() only hits mongo [02:19] before we stored metadata in state, looking up image metadata was expensive [02:19] hence the caching [02:20] wallyworld: ? unrelated... this change only removes cached supported arch collection from provider environ [02:20] exactly [02:20] and hence the caching is now gone [02:20] so if suportedArchitecures() only hits mongo, that's fine [02:20] wallyworld: the problem was that we'd never pick up new arch even if images are updated [02:20] wallyworld: caching was undesired from the start i believe.. it was an oversigh [02:20] nope [02:20] was deliberate [02:21] the expectation was that the providers would have all images defined [02:21] wallyworld: if it was deliberate, it was shooting juju in the leg/foot.. [02:21] and generally they do [02:21] aws, google, all public clouds have images defined [02:22] and the expectation with openstack clouds also is that they are set up with all images in glance [02:23] anastasiamac wallyworld: once we stop query simplestreams, this is all moot. the caching will then be done by the image metadata update worker only [02:23] exactly, that's what i was asking [02:23] stop querying simplestreams from the providers* [02:23] s/asking/confirming [02:23] i just wanted to make sure that the query to mongo was confirmed before we removed the caching [02:23] wallyworld anastasiamac: we're still doing it. I assumed that the "precursor to..." statement in the description referred to that being done as a follow-u [02:23] p [02:24] axw: exactly, so this work is a precursor to stop provider looking ins simple streams.. m expecting the whole lot will end up in one beta without biting anyone... but wanted to break it into separate PRs for ease of review :) [02:24] if we can do it all in one beta cycle that would be desireable [02:24] yay, ty [02:24] :D [02:25] just wanted to be sure that not having the cache escapes [02:25] otherwise performance will regress badly [02:25] s/will/probably [02:26] anastasiamac: maybe you could line up the next one and get a LGTM and land at the same time then? [02:26] anastasiamac: no value in landing this one by itself I think [02:28] redir: really? did you use the debug-log command in the QA steps? [02:33] Bug #1612026 opened: depoloyer/jujuclient broken: show-model flag provided but not defined: -m

[02:35] axw: agreed [02:39] Bug #1612026 changed: depoloyer/jujuclient broken: show-model flag provided but not defined: -m

[02:46] Bug #1612026 opened: depoloyer/jujuclient broken: show-model flag provided but not defined: -m

[03:54] redir: I'm going to merge as I'm pretty sure it's right and I have to positive reviews [03:54] redir: let me know if you really can't repro the QA steps [03:54] menn0: OK, I am back and running through QA one more time cut and paste style [03:55] redir: ok great. [03:55] just waiting for apt-get up* [03:55] seems slow right now [03:55] redir: make sure you're waiting long enough for the migration to finish (check the top of "juju status -m A:foo --format yaml") [03:56] redir: apt-get update always seems a bit slow [03:56] menn0: yeah was doing watch juju status [03:56] but re running to make sure I am on correct branch [03:56] redir: you should set up squid-deb-proxy if you haven't already [03:57] that I did go install ... and not juju install ....(which is in my history so I've definitely done that at some point) [03:57] I should set that up, it sounds like it would be awesome. [03:57] * redir googles [03:57] redir: also for this test using --config enable-os-refresh-upgrade=false and --config enable-os-upgrade=false is totally fine [03:58] redir: I usually use this config when testing stuff locally [03:58] default-series: xenial [03:58] logging-config: "=DEBUG" [03:58] apt-http-proxy: http://10.0.8.1:8888 [03:58] enable-os-refresh-update: true [03:58] enable-os-upgrade: false [03:58] I thought i had that set as defaults in my yaml config [03:58] where the service on 8888 is squid-deb-proxy [03:58] is that on the wiki? [03:58] :) [03:58] probably not [03:59] * menn0 adds that to his todo list [04:00] meh, I'll bug you for details tomorrow afternoon and put it up while I do it. [04:00] menn0: ^^ [04:00] my afternoon [04:00] redir: ok [04:01] Bug #1587993 changed: lxc creation fails, invalid include

[04:03] redir: how's the bootstrap going? [04:03] menn0: on the second one [04:04] redir: another thing you can do is bootstrap multiple controllers in parallel [04:04] redir: that makes a big difference [04:04] with above config... so hopefully much faster [04:04] I'm in cut an paste mode:) [04:04] redir: I didn't put it in the instructions because it complicates things [04:05] no worries [04:06] I just figure I fat fingered something earlier [04:10] ok [04:11] I see no quies [04:11] menn0: ^ [04:11] redir: hmmm ok [04:12] I can try migrating it back to A [04:12] :) [04:12] axw: you around? [04:12] redir: did the migration complete? i.e. juju status -m A:foo now fails, and juju status -m B:foo now works? [04:12] yeah it disappeared from status [04:13] Bug #1469077 changed: Leadership claims, document larger than capped size

[04:13] Bug #1612043 opened: improvement to juju register text [04:13] axw, wallyworld: I have a query re: model config. If I have a clouds.yaml file as shown in this paste and run the bootstrap shown in the paste, I should expect to see ftp-proxy set to the controller value when using 'juju model-config' right? (Or have I misconfigured something): http://pastebin.ubuntu.com/22991841/ [04:14] redir: what does "juju debug-log -m A:controller --replay -T | grep migrationmaster" show? [04:14] veebers: no, you are overriding it [04:15] --config ftp-proxy=ftp://fake.com [04:15] menn0: nada [04:15] natefinch: I am around, what's up? [04:15] redir: nothing at all? [04:15] correct [04:16] veebers: if you juju unset ftp-proxy, it wil revert to the controller value [04:16] axw: saw your comments on that windows bug after I pinged you. Was going to ask about the ResizeDiskError [04:16] redir: ok, what about: juju list-controllers? [04:16] menn0: http://paste.ubuntu.com/22992085/ [04:16] natefinch: I have a patch ready. just need to change the azure provider to set a minimum for the root-disk constraint to 127G [04:16] wallyworld: ah right that's the one. I had in my mind that model overwrites default and controller overwrites model [04:17] natefinch: it seemed that there were other errors after that though [04:17] ah, i see [04:17] menn0: wanna live look for a minute? [04:17] redir: that's probably easier [04:18] axw: I didn't look much further than that... I poked around, but I don't know the azure interface very well [04:18] axw: were there other logs that indicated an error? [04:18] wallyworld: So it's actually, model overwrites controller and controller overwrites default? [04:18] yes, and soon model > region > controller > default [04:18] natefinch: in the portal, if you go to the VM and click on VM Extensions, you can see the output of the script we run on machine startup that effectively does the same thing as cloud-init [04:19] menn0: pm'ed link [04:19] natefinch: there were some errors in there to do with contacting the controller for tools [04:19] axw: ok... yeah, that's the bug I was trying to look into :) [04:20] natefinch: so if you want to repro and get past the root-disk resizing thing, pass "--constraints root-disk=127G" [04:20] axw: I'm surprised it got that far... seemed like the VM failed to even start, but maybe I was misinterpreting the UI [04:20] axw: nice [04:20] natefinch: yes it did fail to start, because of the root disk thing [04:20] natefinch: I mean after you get past that issue, you'll see the other one :) [04:20] oh I see. Ok :) [04:24] wallyworld: cool thanks. Oh and you said the other day that if model and controller values are the same it should say controller in the output? [04:24] yes [04:24] and that is calculated dynamically [04:25] Bug #1612043 changed: improvement to juju register text [04:25] Bug #1469077 opened: Leadership claims, document larger than capped size

[04:26] ah cool, I'll ensure that's tested too. [04:31] Bug #1469077 changed: Leadership claims, document larger than capped size

[04:31] Bug #1612043 opened: improvement to juju register text [04:43] Bug #1612046 opened: inconsistent error text when attempting unauthorised command [04:47] wallyworld: I don't think we should be testing the provisioningState != Succeeded in the provider. That's handled by the Azure SDK. [04:48] axw: yeah, that is true and i agree. i just wanted to be 100% sure by asking [04:49] wallyworld: okey dokey. just bringing it up here in case you wanted to debate :) [04:49] that we didn't need to have a unit test for a failure case where provider didn't succeed [04:49] you can drop, feel free [04:50] wallyworld, axw: When you have a moment could you take a quick shufti at my revised testplan for the config tree and confirm if it's sensible please? https://pastebin.canonical.com/162911/ [04:50] anastasiamac natefinch menn0: http://reviews.vapour.ws/r/5412/ is just over 500 lines, do any of you have a little time to spare for a second review? [04:51] a what now :) [04:51] veebers: sure, give me 5 [04:52] veebers: sounds fine to me [04:53] cool thanks. [04:54] oh axw, can I set a global setting in clouds.yaml, or does it need to be under a clouds -> cloudname -> config stanza? [04:54] veebers: the latter [04:54] axw cool thanks [04:59] axw: I'm a bit knackered, otherwise I'd take a shufti at your review [04:59] natefinch: heh ;p [04:59] natefinch: no worries [05:02] axw: btw, I'm thinking of putting the json tags back on the schema object, if for informational purposes only [05:03] axw: I would imagine that someone wanting to write a schema would go look at this package... even though jsonschema is standard, it's nice to give the standard names here where they'd already be looking [05:03] natefinch: if they're not being used, seems more like misinformation to me. if I come across a type with json tags, I expect that they're used for json un/marshaling [05:03] * axw shrugs [05:04] not terribly fussed [05:04] axw: well... they do indicate the correct json tags for marshaling/unmarshaling. The fact that we ignore them is an implementation detail ;) [05:05] natefinch: I guess it doesn't matter since they can't reasonably be changed anyway [05:05] yep [05:13] Bug #1612048 opened: juju needs a "list-shares" command for a controller === mpontillo_ is now known as mpontillo [05:53] axw: sorry was afk - school pickup. did u get a 2nd review on 5412? [05:54] anastasiamac: no, if you have time I would greatly appreciate it [05:54] axw: looking now \o/ [06:00] wallyworld: what does logout actually do? [06:00] natefinch: logs out of the specified controller, meaning yuo need to login again to do stuff [06:01] wallyworld: so like uncaches whatever credentials? [06:01] it is reflected in list-controllers [06:01] yeah [06:01] ok === sinzui_ is now known as sinzui [06:07] axw: I ended up tweaking the schema struct a bit more to make it more friendly to struct literals, but it's working for marshal/unmarshal now: https://godoc.org/github.com/natefinch/cloudschema [06:08] axw: this let me drop all visible references to go-jsschema, so consumers don't even need to know about it (presuming we add a validation function to this package) [06:08] natefinch: yeah, I was thinking about that. sounds good [06:08] cool. Bedtime for me. [06:09] natefinch: good night [06:12] axw: LGTM and saw that u have already confirmed that u've live-tested :) [06:29] anastasiamac: thank you [06:29] axw: \o/ [06:30] anastasiamac: next time in the code I'll make that number a var. it's a bit magic either way - I'll see if I can think of a better way to do it [06:31] axw: nps - just saw that it was shuffled in couple of places from previous codebase :) was just a note \o/ [06:59] axw: Another clouds.yaml file, if I have a bootstrap arg like in this paste, I should need option B (in the paste) in clouds.yaml right? http://pastebin.ubuntu.com/23001462/ [07:00] veebers: correct [07:00] axw: awesome, thanks :-) [07:01] veebers: assuming you meant shouldn't :) [07:02] axw: oh hah, um. Better asked, which of A or B should work in this example? [07:03] veebers: you don't need either of them [07:03] veebers: (unless you want to use config of course; I think you should just use B) [07:03] veebers: --of course. I don't think we're yet merging config with existing cloud definitions. so if you want to define cloud config, you need an entry in clouds.yaml [07:04] veebers: gtg pick up my daughter, be back in a little while [07:05] axw: To clarify I'm wanting to set a controller config setting (which I do via clouds.yaml as my understanding), using --config for bootstrap will set a model config option right? === frankban|afk is now known as frankban [07:24] veebers: correct. so use B from the example, and add a "cloud:" section as a sibling of "regions:" [07:28] axw: should 'cloud:' contain anything/ [07:29] veebers: gah, I meant "config:" not "cloud:" [07:29] veebers: i.e. with the controller-level attributes in it [07:30] axw: ah right, that makes sense :-) Thanks [07:40] Bug #1612099 opened: mark currently logged in user in "list-users" [07:49] Bug #1612105 opened: juju help usage output

[08:13] Bug #1612110 opened: update README.md to include running godeps

[08:13] Bug #1612112 opened: upgrade-charm should warn when the same version is detected [08:52] fwereade, dimitern: I've just realised I also need to include subnet info in the NetworkConfig I return from the API (if I want it to be complete), which means my mocks and shims need to cover State -> Machine -> LinkLayerDevice -> Address -> Subnet. [08:53] fwereade, dimitern: I feel like this is increasingly impractical - is there a better way of doing it? [08:53] babbageclunk: I don't think that's necessary [08:54] dimitern: Good! :) What should I do instead? [08:54] babbageclunk: having the IP and MAC addresses, along with the provider IDs of the interface and the address will be sufficient I think [08:55] babbageclunk: in fact, I'm OK with changing the definition of ReleaseContainerAddresses not to take []params.NetworkConfig, but a slice of a new, simpler type [08:55] dimitern: Yeah, I was reaching towards something like that too. [08:57] babbageclunk: e.g. params.InterfaceAssignments { InterfaceName, InterfaceProviderID, MACAddress, IPAddress, IPAddressProviderID } [08:57] (not necessarily with these names [08:57] ) [08:58] dimitern: Then I think why include the ip address details? We don't need them at the moment. [08:59] * dimitern *thinks* [08:59] babbageclunk, dimitern: I would say that the db-backed-object style of state is the root problem here [08:59] babbageclunk: we do, if we're going to do IPAM for MAAS as well [08:59] babbageclunk: and it shouldn't be a huge deal to add it [09:00] fwereade: Yeah, I think so too, but I'm worried about trying to change that as part of that work. [09:00] fwereade: s/that/this [09:00] babbageclunk, dimitern: I don't think we need to *change* it so much as just route around it [09:00] fwereade: I tried to make the model inside network/ and extract the bits to store in the db and pass over the api from there [09:01] * dimitern needs to step out to the ironmonger quickly.. [09:02] fwereade: So I could make other methods in state that return LinkLayerDeviceArgs instead of LinkLayerDevices? [09:02] babbageclunk, dimitern: `func (*State) ContainerAddressStuff() *ContainerAddressStuff` with the methods you need, calling down to implementations shared with machine et al, means you need to write and test that... but it also means you can make the apiserver tests much simpler [09:03] babbageclunk, I'm -1 on exposing params stuff from state vs core types [09:03] babbageclunk, I think it's the apiserver's job to convert dependency-free core types into wire representations [09:04] babbageclunk, similarly to how it's state's job to (internally!) convert core types back and forth into db representations [09:04] babbageclunk, making any sense? [09:05] fwereade: So what about moving the {LinkLayerDevice,Address}Args types from state into core and making methods to return them? [09:06] fwereade: And SubnetInfo [09:09] fwereade: Sorry, got the name of the address one wrong - it's LinkLayerDeviceAddress. [09:10] fwereade: Then I think that matches what you're saying - they're just plain old data that the tests can construct, no nasty *States or private ctors. [09:15] fwereade: I think this is what katco was suggesting in a review a while ago but I didn't really understand because I hadn't experienced the full horror of all of these nested shims and mocks. [09:16] * babbageclunk thinks maybe fwereade's popped out to the apothecary? [09:16] * babbageclunk should really visit the barber-surgeon sometime. [09:24] fwereade: Oh, hang on - I'd forgotten that those types already exist in core/description. Can I use those? [09:27] fwereade: Annoyingly they also have private constructors, so what I'd end up returning from the methods in state would be core.description.{LinkLayerDevice,IPAddress,Subnet}Args. [09:30] babbageclunk, sorry -- but, yes, I think what you're saying makes sense [09:31] babbageclunk, I'm not 100% sure whether they're description types, or whether description should be pulling from core/network or something, but it seems like a good start [09:31] babbageclunk, the more things we can represent and communicate as POD the better, I think [09:34] fwereade: Ok - I'm going to start adding the methods to state to return core.description.*Args first - if we want to move those types elsewhere we can do that. Should I go as far as State.Machine(id) -> State.MachineArgs(id) [09:35] ? [09:35] fwereade: There must already be something that converts from eg a state.LinkLayerDevice to a core.description.LinkLayerDevice, right? [09:36] babbageclunk, apart from suspicion re "Args" being a suboptimal name vs "Spec" or "Info" or something, I think that's the right structure [09:36] babbageclunk, I'm sure there is, but I suspect it's hidden away in migration_export [09:37] fwereade: Yeah, the name was putting me off too. [09:37] fwereade: Gah! BDSM languages with their access rules and their enforced interfaces! :) [09:37] babbageclunk, oddly enough I was just fulminating privately about the CharmInfo type we use to add charms but don't ever return from state [09:37] hahaha [09:42] babbageclunk: I was trying to follow along, but getting distracted - please ping me when you have those changes to have a look though [09:58] Bug #1612163 opened: state refcounts should be consolidated

[10:01] fwereade, dimitern: I feel like this might be a boil the ocean solution. [10:02] babbageclunk, if it's too much, you're closer than me and your judgment is probably clearer [10:02] babbageclunk, I'd been hoping we could add a relatively clean/narrow interface to the functionality we need [10:03] babbageclunk, i.e. we don't need to rewrite what exists, just hide it behind something more fit for purpose [10:04] fwereade: team meeting? [10:05] voidspace, thanks [10:10] dimitern: do you have an example /e/n/i for a maas rack controller that defines vlans? I just have one subnet (and one nic) on the rack controller - but can reconfigure if needed (all KVM). [10:12] voidspace: yep, just a sec [10:13] dimitern: sure [10:13] voidspace: http://paste.ubuntu.com/23010779/ here's my 2.0 vmaas [10:14] dimitern: thanks! [11:18] morning [11:20] rick_h_: \o/ [14:01] katco: dimitern ping for standup [14:20] katco: can you take a peek at https://github.com/juju/juju/pull/5978/files please for ui folks? [14:20] rick_h_: sure [14:20] katco: ty [14:23] Bug #1520292 changed: Upgrade from 1.21.3 -> 1.22.8 -> 1.23.3 fails with 'ERROR a hosted environment cannot have a higher version than the server environment: 1.23.3.5 > 1.22.8.1'

[14:26] Bug #1520292 opened: Upgrade from 1.21.3 -> 1.22.8 -> 1.23.3 fails with 'ERROR a hosted environment cannot have a higher version than the server environment: 1.23.3.5 > 1.22.8.1'

[14:26] frankban: hey, left a new comment on http://reviews.vapour.ws/r/5419/ [14:27] katco: sure, I like this new rules actually, good to know [14:35] Bug #1427257 changed: Juju backup doesn't contain .juju files

[14:35] Bug #1520292 changed: Upgrade from 1.21.3 -> 1.22.8 -> 1.23.3 fails with 'ERROR a hosted environment cannot have a higher version than the server environment: 1.23.3.5 > 1.22.8.1'

[14:35] Bug #1545686 changed: Multi-series not backwards compatible

[14:36] katco: updated instructions at http://reviews.vapour.ws/r/5419/ [14:37] frankban: ta, tal [14:37] katco or axw: could you please take a look? [14:37] we'd like to include that in next beta [14:37] frankban: did you publish your changes? [14:38] katco: I just did, sorry [14:38] frankban: np, ty [14:46] frankban: this is great, ty. please also amend your commit message with this information (you can elide the qa portion if you like) [14:48] katco: done [14:49] katco: thanks for the review, shipping it [14:49] frankban: thanks for the change! <3 [15:02] dimitern: Could you take a look at http://reviews.vapour.ws/r/5420/? Should be a quick one! === benji___ is now known as benji [15:17] babbageclunk: looking [15:20] babbageclunk: LGTM [15:20] dimitern: Yay, thanks! [15:21] dimitern: This is the beginning of the end for this bug, I can feel it in me waters. [15:23] :D indded [15:29] morning [15:29] Bug #1466152 changed: [RFE] log locks and other relevant information when jujud receives SIGUSR1

[16:13]