[00:00] *so [00:00] wallyworld: I look forward to cleaning that up. the code in the area pissed me off last time I made changes there. [00:00] :) [00:01] lol [00:01] good to clean up shit which pissed you off [00:01] Eschatological refactoring, interesting [00:02] menn0: the thing to bear in mind is that we filled a 32GB root partition with repeated charm deploy/model removal for a few users on a few models [00:02] so if we see a pathway to fix that then good [00:02] this is a step in the right direction [00:02] "Eschatological" is a fancy word [00:02] wallyworld: well with will's improvements and the removal of the cache we should be good then [00:03] menn0: i'll believe it when i see it - this is a very large whack a mole i fear [00:03] It's not so weird in Spanish [00:03] i don't even know what it means, will need to look it up [00:05] Wallyworld https://en.m.wikipedia.org/wiki/Scatology [00:05] Apparently in english they use different words in Spanish is the same word for all meanings [00:05] oh i know what that word means [00:06] didn't recognise the one starting with "e" [00:06] So yes we share a word for shit and religion aren't we cool [00:06] same thing :-) [00:07] wallyworld: i'll do some checks on disk usage with some large bundles after all the changes are in and see [00:07] sgtm, ty [00:08] perrito666: apparently a fetish for some ppl according to that reference [00:29] thumper, wallyworld you guys around [00:29] I am [00:29] depends who's asking :-) [00:29] can you join a quick HO? [00:29] :) [00:29] suppose so [00:30] meet you in a-team [00:30] ack [00:38] Bug #1623275 opened: neutron-gateway juju-agent lost forever [00:47] axw: review done [00:47] phew [00:56] menn0: so just to make sure u r having fun, here is the simple scream one as promised - http://reviews.vapour.ws/r/5674/ [00:57] axw: wallyworld: if u r feeling exceptionally generous ^^ [00:57] bbiab [00:57] i'll take a peek in a bit [00:57] menn0: i tried to have logically grouped commits for the ease of perusing :) [01:08] menn0: and another 1-liner :) http://reviews.vapour.ws/r/5675/ [01:10] menn0: TYVM === mup_ is now known as mup [01:20] anastasiamac: i've got a few jobs to do but I'll get to those soon [01:27] wallyworld: ship it [01:27] awesome, ty [01:34] menn0: sure thing! tyvm ;) [01:45] wallyworld, menn0: big but boring http://reviews.vapour.ws/r/5676/ [01:46] thumper: like you :-) [01:46] oh you so funny [01:48] thumper menn0: re http://reviews.vapour.ws/r/5676/, why no access levels in core/description? do we not migrate access? [01:49] axw: we do, but as string values [01:49] not special Access type [01:49] core description is all about being able to describe the model for export [01:49] not a generic "stick it here" type package [01:50] specific small packages for specific things is good [01:50] thumper: but access *is* part of the description of a model? [01:50] it is an attribute of users, sure [01:50] that is still there [01:50] but the type for Access should live elsewhere [01:54] thumper: I don't see why. If you have access there in core/description, but as a string, you're just making it stringly typed. It would be nice to retain some type safety in the core description - this will matter if we start using core/description for more than just exporting [01:55] axw: i'll make that api change for cloud tags, ok? [01:55] wallyworld: yes, thank you [01:56] * wallyworld gets food first [01:56] wallyworld: probably need to let mhilton know [01:56] axw: yeah, jeff is all set to make his upstream changes sod tomorrow [01:56] cool [01:57] axw: core/description needs to be able to handle old and new format values, if we tie types in there, we could limit our ability to do this easily [01:57] I just don't think it is the right place for that [01:57] yes we need some business object tier [01:57] but I've become increasingly sure that core/description isn't it [01:58] thumper: fair enough then. perhaps "core description" is not the best name for it then - that implies to me that it's *the* canonical representation [01:58] I actaully want to move core description out of juju/juju [02:01] ugh... [02:01] I now have two branches that I know will conflict [02:01] * thumper waits for the first to land [02:04] menn0: pong [02:05] menn0, wallyworld: saw your comments on the review [02:05] menn0, wallyworld: the main reason to keep track of how the value was constructed is so that error messages make sense. otherwise you get something like this: [02:06] juju deploy --constraints=cpu-cores=3 --constraints=cpu-cores=4 [02:06] ERROR: bad 'cores' constraint: already set [02:07] isn't that a corner case though? [02:07] there's a lot of ways validation can fail [02:08] and they all specify the value that failed, which won't be in the list of things you set [02:08] I agree, it's a lot of complication. I almost didn't do it. [02:08] hmm, i see your point. i wonder what others think [02:10] sorry otp, almost done [02:11] My other option was to print out a deprecation warning at the beginning, but that gets clunky fast, if we do any more of these aliases. [02:12] Warning: the "cpu-cores" constraint is deprecated in favor of "cores"... etc [02:13] natefinch: that's the approach we have taken for config attributes and is one i like [02:14] lets the code stay simple, the majority of cases works nicely without cruft, but does alert the user to change what they type [02:14] and it's not like there will be 100s of deprecations [02:15] wallyworld, natefinch: i'd prefer the deprecation warning too [02:16] ok... undo undo undo :) Simpler is better, I agree. [02:16] natefinch: sorry :) [02:17] menn0: nah, it's the right call. I was doing that, but then I was halfway to just having the right error message anyway, so I kept going. Except of course, I wasn't really half way, I was like 10% of the way, I just didn't realize it yet :) [02:18] wallyworld: I don't suppose you'll have any bandwidth for a second review on my branch today? [02:19] axw: just for you [02:19] wallyworld: thanks. no rush, any time later on [02:19] going to look at credentials now [02:19] axw: ok, will do it real soon [02:29] menn0, wallyworld: one question - I noticed HardwareCharacteristics has cpu-cores.... it wasn't specified in the bug, but I presume we want to make that match the constraint [02:31] natefinch: i think so [02:33] natefinch: good catch. yes, that should probably match [02:35] wallyworld: btw the reason I wasn't going to change the field name on the struct is merely to keep the change smaller. The name of the field is still close enough to the name it is serialized as, that I don't think it's worth the churn. [02:35] wallyworld: re http://reviews.vapour.ws/r/5674/: I *think* what anastasiamac's doing is going in the right direction. ImageMetadata.Stream shouldn't really be there, because it's not actually part of the simplestreams format at that level [02:35] i can go either way [02:36] wallyworld: moving it up to the "resolve info" feels more natural to me, because it's meta-metadata === blahdeblah is now known as blahdeblah-lunch [02:36] axw: ok, i need to look at it again [02:37] axw: the issue is that resolve info is about a location/source of metadata. not necessarilty the stream from which is came [02:37] but maybe in practice there's 1:1 [02:40] wallyworld anastasiamac: hrm, I think it's only 1:1 because of this: https://github.com/juju/juju/blob/master/environs/simplestreams/simplestreams.go#L640 [02:41] wallyworld anastasiamac: that looks to me like we're picking an arbitrary stream, when multiple are specified. is that right? [02:41] axw: well, source and stream are 1:1 [02:41] so things will only work properly if you do a lookup with one stream. which I think we always do anyway [02:41] axw: what we are picking here is only location out of potentially many matches [02:42] axw: right, from memory, the assumption was that index files would only contain one product stream. and we currently rely on that. but it's not guaranteed [02:42] relationship between source and stream is still 1:1 if you look at products files... stream is defined on content id which there is only one of per file [02:42] locations are not 1:1 with stream [02:42] in the model [02:42] and yet now we would be hard coding that faulty assumption [02:42] maybe not in the model but m looking at the actual files we have in simple streams... streams are on content id and there is only one content id [02:43] that's the way they have chosen to make the files currently, but it can be different [02:43] and if it changes we will break [02:43] wallyworld: pla point me to a file which has n=more than one content-id [02:43] please* [02:43] ah right, because we have a different URL for daily [02:43] i'd have to go digging to find one [02:43] we used to have them [02:44] we may have moved on to differentiating using url [02:44] i just fear that we are making assumptions based on an implementation artifact, not the true streams model [02:44] wallyworld anastasiamac: the other option would be to have GetMetadata return a map, keyed on stream [02:45] m looking at code and data. how is it hard-coding worng assumption?! [02:45] data does things one possible way, not the only way [02:45] anastasiamac: the point is that index.json *could* have multiple product IDs [02:45] anastasiamac: it works now because they only have one. but that can change [02:46] may not change, but if it does we will break [02:48] axw: sure. but m getting stream from a content id of selected product [02:48] here's one http://streams.canonical.com/juju/tools/streams/v1/index2.json [02:49] wallyworld: that's index file. m talking about product files [02:49] content id of product [02:49] the content ID is in the index as well. that's where we start [02:50] that content id is notnecessarily the one we match on, we also look in products files [02:51] this is why in simplestreams.go, l987 in my PR, function getLatestMetadataWithFormat deals with content id of the selected block [02:51] i can't find one at the moment [02:51] happy to ho if it's easier for u [02:51] wallyworld: i don't hink there is one [02:52] anastasiamac: IndexReference.GetProductsPath does filter on product IDs in the index [02:52] there may not be currently [02:52] u can have more than on product block (and content id) on index file but nor in product file [02:52] anastasiamac: and that's where we're doing the "Pick arbitrary match" [02:52] wallyworld anastasiamac: the current code would be broken with multiple products in an index too, except if we specify a stream in the constraints [02:53] yes, that will get u a block of products, the method that i refered to, has htis under one metadaat and I work with content id in this metadata [02:53] that is true [02:53] i think we always pass in a stream [02:53] an issue for me is the mixing of concerns [02:53] resolve info and stream [02:54] anastasiamac: you only have one metadata *because* of that "Pick arbitrary match" [02:54] wallyworld, menn0: oh, weird... https://github.com/juju/juju/blob/master/instance/instance.go#L63 yaml and json names differ [02:54] currently stream is not at the right level, stream is a product concern (product can have many items) [02:54] we do not have abstraction for products only resolve info and items [02:54] the stream on item is a denormalisation from memory [02:55] it never worked because stream was never pulled from product [02:55] anastasiamac: IMO, the best thing to do would be to have GetMetadata return a map of stream->[]metadata [02:55] natefinch: you found the deliberate typo we left in there :-) [02:55] natefinch: ick... I think using dashes is better [02:55] and remove environs/imagemetadata.ImageMetadata.Stream [02:55] natefinch: but do we want to break people scripts? [02:55] people's [02:56] axw: that'd b bigger change. [02:56] it would be but it corrects the code [02:56] i'll abandon my approach, re-target the bug to 2.1 and someone more keen on getting simplestreams sorted can fix it the *right* way [02:56] why not just fix it for rc1? [02:56] we have 2 days [02:57] well, 1.5 :-) [02:57] sure, ian. fix it [02:57] i have a long todo list today sadly [02:58] menn0, wallyworld: actually ... I don't think we use that for output: hardware: arch=amd64 cpu-cores=2 cpu-power=550 mem=1800M root-disk=10240M availability-zone=us-east1-b [02:58] menn0, wallyworld: there's a String() method that does the single line output [02:58] that sounds right [02:58] so we may be saved from ourselves [02:58] natefinch: I wonder why those tags are there... if they're not used then they should go [03:01] menn0: the package's tests still pass if I comment them out... I'll do a biggest test run later [03:03] natefinch: ok [03:03] natefinch: maybe they were used once but aren't any more [03:04] menn0: could be === blahdeblah-lunch is now known as blahdeblah [04:14] damn frameworks [04:16] Just realized, when there's an error parsing flags, the error is printed out and we never get to the Run function, so I can't print stuff out there to give context to the error from the flag. [04:24] * natefinch is gonna have to do something heinous [04:46] wallyworld: so in `juju model-defaults aws/us-east-1 --reset ftp-proxy` would it always be aws/us-east-1 or might it also be just the region `juju model-defaults us-east-1 --reset ftp-proxy`? [04:46] axw: srtrictly speaking, the client.ModelInfo() and client.ModelUserInfo() calls should not be returning params structs. But nothing in juju calls then so I'm not sure if it's worth changing? http://reviews.vapour.ws/r/5677/ [04:46] redir: we need to cater for just the region [04:47] hence the need to use the cloud api [04:47] to get the valid regions etc [04:47] wallyworld: the spec shows the cloud and region [04:48] redir: it may do, but not exlicitly also showing just the region is an oversight [04:49] unless i am mistaken [04:49] for the single controller case it is not needed [04:49] and there will always be a current controller [04:49] so there's always a current default cloud [04:49] we don't want to make the user type stuff unnecessarily [04:49] right [04:50] Bug #1623324 opened: Support for subnets in MAAS created after juju is boostraped <4010> [04:53] wallyworld: if there's no caller, should we just delete the client side code? [04:55] axw: hmm, yeah good point [04:55] i'll double check [04:57] axw: yeah, i can't see anywhere [05:01] thumper: you still going to delete list-shares and tweak the list-users command? [05:09] wallyworld: I'll do it in one go [05:09] yes, I'll do that one [05:10] thumper: no problem. i was asking because there is an api on the api/client facade which can be deleted one yourwork is done, the ModeluserInfo() one [05:10] i am removing the ModelInfo() one [05:10] no, because we'll probably still use it [05:10] ok, maybe it can be moved [05:11] i have a goal to one day remove the client facade entirely :-) [05:14] axw: are you looking at fixing the provisioner so it doesn't do everything one at a time? [05:15] I think we should seriously look into that as a solution [05:15] I'm looking at another bug (bug 1611111) which it would help fix [05:15] Bug #1611111: Model still exists for a while after running destroy-model

[05:48] thumper: not atm [05:48] looking at azure creds changes now [05:49] wallyworld: that "azure bootstrap experience" card is for creds, I'm moving back to in progress [05:49] "speed up azure provider" is for current work [05:54] ah sorry, misread [06:26] Bug #1623324 changed: Support for subnets in MAAS created after juju is boostraped <4010> === frankban|afk is now known as frankban [07:31] wallyworld: do you have an azure account? [07:32] axw: i do, it was a trial, i think it has expired but i can look to reactivate [07:32] wallyworld: no worries, can probably just use the CI account [07:32] good point [07:32] wallyworld: I've got a toy app that authenticates interactively and then creates a service principal [07:33] just need to make sure it works when I'm using a different AD tenant [07:33] axw: oh nice ok [07:33] we can try with CI creds I guess [07:35] wallyworld: ah hm, there are no CI creds published for azure (apart from service principal) [07:36] oh [07:40] axw: ping; based on your experience of azure is there anything we can or should be doing regarding DNS? [07:42] frobware: I don't recall what the requirements are from charmers around DNS, so hard to say [07:42] frobware: can you fill me in? [07:42] axw: i think my observations are more general though. I'm surprised that, given the machine's name, you cannot DNS resolve it. [07:43] axw: for example, on AWS I get `ip-A-B-C-D'. The resolver in /etc/resolv.conf can happily resolve the name. [07:43] frobware: well, you can resolve using nslookup. it's just that dig doesn't seem to use the search from resolv.conf by default [07:43] axw: I just don't see that on the images launched on axure [07:44] axw: ah, ok... let me take another look. [07:44] frobware: try "dig machine-0 +search" [07:45] axw: I wonder if the safest thing for us to do is rely on the results of getent(1). [07:45] axw: the domain name you get on Azure aspires to hungarian notation. :p [07:46] frobware: well, they did invent it :) sorry, I'm not familiar with getent [07:46] axw: getent allows you to make queries against database entries in /etc/nsswitch.conf [07:46] axw: so passwd, or hosts, or dns, or ... [07:47] axw: e.g., getent passwd $USER [08:01] menn0: I'll be a couple mins late [08:01] axw: no probs [09:37] babbageclunk: hey, this has been raised in priority, can you take a look and see if anything jumps out? the error message sucks and we need to use errors.NotSupportedf() properly, but I wonder why it doesn't detect MAAS 2.0 properly? [09:37] bug 1623184 [09:37] Bug #1623184: ERROR MAAS version 1.9 or more recent is required not supported [09:38] wallyworld: Sure, I'm looking now [09:38] ty, you may see it and know straight away maybe :-) [09:39] i attempted to leave a comment that made sense after looking at the code [10:35] wallyworld: I think it's a bad endpoint url [10:36] babbageclunk: makes sense. we should probably deal with that a bit better, print a more useful message [10:36] wallyworld: Yeah, that's what I was thinking. [10:38] wallyworld: bit tricky to distinguish between getting getting 404s because the URL's wrong or because none of the versions we support are supported, though. Thinking. [10:38] babbageclunk: yeah, i was having the same thought [10:38] there must be some validity check on the base part of the url or something [10:39] some http get that we can do to check [10:39] that works for both 1.9 and later [10:39] and if that fails, then bad url [10:39] wallyworld: ok, I'll try to find something like that. [10:39] as well as static checks on the url itself [10:40] just a thought, you may come up with something better [10:40] wallyworld: I'm reluctant to look inside the url [10:40] wallyworld: babbageclunk: there isn't a single endpoint we can check for both versions [10:41] bollocks, i guess we'll need to try both [10:41] wallyworld: babbageclunk: the official maas response when we requested that was we needed to check the 2.0 endpoint and if it wasn't there we were on 1.9 [10:41] wallyworld: babbageclunk: if we get an invalid response from both endpoints we should know we're incorrectly configured [10:41] right, but in this case, we got a false 1.9 error [10:41] wallyworld: babbageclunk: and provide a better error message [10:41] correct [10:41] instead of the current misleading one [10:41] yes [10:42] cool [10:42] a single endpoint telling us the version would be much better though :-/ [10:42] yeah :-( [10:45] voidspace, wallyworld: ok, so that's really just changing the error message in getCapabilities to say that the endpoint's wrong. [10:45] babbageclunk: sounds like it [10:45] sweet [10:45] babbageclunk: and also fixing the bad use of NotSupportedf [10:45] for the 1.9 case [10:45] wallyworld: yeah, already done that :) [10:45] \o/ [11:50] Someone give the github -> reviewboard bot a kick? [11:54] wallyworld, voidspace: review plz? http://reviews.vapour.ws/r/5680/ [11:56] sure [12:01] babbageclunk: +1 with a suggestion [12:03] babbageclunk: :LGTM [12:03] babbageclunk: I'm agnostic on wallyworld's suggestion. There are times when it could be helpful, but there's no requirement that the MAAS api needs to be exposed at an endpoint ending with /MAAS [12:04] ok [12:04] babbageclunk: wallyworld: so there are times when it won't be helpful (probably not hurtful though - so +0 I guess) [12:04] ignore me then :-) [12:04] hah [12:36] wtf happened to master? there's some code referring to status.StatusBlocked, which doesn't exist any more === carlosm_ is now known as udac [12:39] frobware: would whatever you're trying to do with DNS on azure be avoided by just encoding the IP in the hostname, like on ec2? ip-n-n-n-n [12:39] frobware: i.e. so you can map between them without having to use DNS at all [12:50] axw: the reverse is still the problem. the big data charms (hadoop et al) want forward and reverse lookup. They are currently fudging their way around things. [12:50] axw: http://sujee.net/2012/03/08/getting-dns-right-for-hadoop-hbase-clusters/#.V9lHpGQrLDE [12:51] axw: we can do ip-A-B-C-D, the trouble is nothing has an answer for who-is A.B.C.D. [12:52] frobware: I thought that was what the NSS plugin was for? [12:52] axw: I'm sure babbageclunk made a change around status [12:52] frobware: yeah he did, somehow api/deployer is still referring to StatusBlocked. *shrug* [12:52] axw: right. the plugin will parse names of the format `juju-ip-A-B-C-D'. You get back A.B.C.D. Hadoop says, wtf is A.B.C.D and there is no answer. [12:53] axw: the plugin cannot be authoritative for arbitrary IP addresses, largely because of the order in /etc/nsswitch.conf. [12:53] frobware: ah, ok [12:53] I thought it always went through that [12:54] axw: the plugin get 'A.B.C.D' and I have no idea whether that was oringally an juju-ip- form, or something like archive.ubuntu.com... [12:54] axw: the plugin (desperately) wants to avoid state [12:54] righto, makes sense [12:55] axw: it does go through the plugin. Well, kind-of. I haven't implemented getaddrinfo for ^ reasons. [12:56] * axw nods [13:00] axw - maybe someone landed something that was in flight when my rename branch merged? [13:02] babbageclunk: the other change came from wallyworld, but it was landed by the bot. bot should stop that from happening. weird :/ [13:02] I'll investigate more tomorrow [13:02] oops, what have i done [13:03] oh, bloody merge conflict :-( [13:03] how did that get through [13:06] wallyworld: not your fault. bot weirdness [13:06] am fixing now. [13:06] there was a merge conflict [13:06] but i must have missed a couple [13:06] I think it must have been queued while mine was building, then mine passed, yours started, then mine was merged. [13:07] Then yours passed and was merged - it didn't conflict at the textual level. [13:07] Maybe? [13:08] Still pretty weird [13:09] yeah, we were making conflicting changes and it all sort of just landed together [13:11] babbageclunk: here is the fix, trivial http://reviews.vapour.ws/r/5681/ [13:11] LGTM! [13:13] ta! [13:15] wallyworld: sorry, I was grabbing lunch when you and voidspace were discussing the URL - you're alright with me leaving the message the way it is? [13:15] yeah [13:15] i dropped it [13:15] cool thanks! [13:15] was just a thought [13:15] to try and guide the user to the solution [13:15] if it's an obvious fix [13:28] wallyworld: You made me feel bad for the users. What do you think of this message? "Couldn't get MAAS version - check the endpoint is correct (it normally ends with /MAAS)" [13:29] wallyworld: suggestions to crispen it up welcomed! [13:30] trying to hedge a bit with "normally", but it seems a bit wishy-washy. [13:30] rick_h_: just grabbing coffee, be a few mins late to 1:1 (if you're around) [13:33] babbageclunk: lol. maybe even "could not connect to MAAS controller...." [13:33] the user doesn't need to be told exacrly what it is trying to do [13:33] Yeah, true [13:33] just what it is trying to connect to [13:34] And we prefer "Could not" to "couldn't" ? [13:34] i prefer not using a contraction but ymmv [13:34] also [13:35] if you are going to say normally ends with /MAAS, you'd want to check that it didn;t first [13:35] Yes, I'm doing that (in some code you can't see) [13:35] and you'd also attempt to parse the url to tell them it was malformed if that's what the issue is [13:36] I think that'll happen already (checking now). [13:37] ERROR Get httpoo://192.168.150.2/api/1.0/version/: unsupported protocol scheme "httpoo" [13:37] ok [13:38] I think we're at numberwang [13:41] rick_h_: sorry about that, managed to accidentally shutdown my system [13:41] rick_h_: I'm around if you are [13:46] babbageclunk: "cannot determine MAAS version ..." === benji__ is now known as benji [13:56] voidspace: sorry, I cancelled because I'm still on west coast [13:56] voidspace: coming up on 7am here [13:56] rick_h_: I thought that was likely to be the case - I didn't get a cancellation though, was still on my calendar [13:56] rick_h_: ah well :-) [13:56] rick_h_: morning o/ [13:57] frobware: I like wallyworld's reasoning that the user probably doesn't need to know exactly what we're trying to do when we couldn't connect to the controller. [13:58] babbageclunk: so "determine" was less specific. [13:59] Oh, I think determine's better than get, but not as good as "couldn't connect to MAAS controller". [14:01] natefinch: ping for standup [15:08] can someone explain the relationship between cloudconfig and cloudconfig/cloudinit? I'm working on bug 1475260 and have a fix that works, but I'm not sure where it should go. [15:08] Bug #1475260: instances cannot resolve their own hostname

[15:12] babbageclunk: ping; hostnames and ^ bug: are you testing on maas? [15:13] frobware: no, on lxd - I think the userdata for maas is generated in some completely different way? And it seems like the maas dns ensures that the hostnames are resolvable, right? [15:19] babbageclunk: right - I was just running some tests... not sure we want managed_etc_hosts [15:19] frobware: On maas? [15:19] babbageclunk: possibly anywhere... give me a few mins [15:19] ok [15:20] babbageclunk: btw, cloud-init for containers is in juju/cloudconfig/containerinit [15:21] frobware: Is that for LXDs inside maas/aws/other provider hosts? [15:21] frobware: as distinct from the lxd provider? [15:22] babbageclunk: that's for LXD's inside a cloud/maas host [15:22] babbageclunk: make sense? [15:22] frobware: yup, I think so. Although I'm not sure what I should do in that case. [15:35] babbageclunk: so my concerns is that you end up with: "127.0.1.1 vmtest.home vmtest" in /etc/hosts [15:35] babbageclunk: and that we start handing out 127.0.1.1 [15:36] alexisb: hey, just FYI - whatever bug had been causing my computer to take forever to get make the login screen work is evidently magically fixed (or I happened to twiddle the right config to avoid it sometime in the last few months) [15:36]