[00:11] wallyworld_: want to have a quick catch up chat? [00:11] thumper: sure, meet in our 1:1 [00:11] k === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [01:42] anyone? http://reviews.vapour.ws/r/676/ [02:04] wallyworld_: just want some clarification on the change. AllowsSecureConnection indicates that there's a CA private key on the state servers, which allows them to generate valid certificates. without it, the certs may not have valid addresses and so the LXC code will not be told to fetch images from the API server [02:04] instead it'll go directly to the external source [02:04] is that right? [02:05] axw: yes, correct [02:29] thumper: looking [02:38] thumper: done [02:38] ta [02:39] thumper: got a sec to chat? [02:39] rick_h_: sure, why not [02:39] :) [02:40] thumper: [02:40] https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 [02:43] rick_h_: you've stopped moving and making noise === negronjl is now known as negronjl-afk [03:03] thumper: if you have a moment, here's a small, simple review http://reviews.vapour.ws/r/677/ [03:04] wallyworld_: ship it [03:04] ty [03:34] wallyworld_: is there an example somewhere in a test (and real code) of checking for the existance of tools for a particular version? [03:34] wallyworld_: I think the upgrade-juju command does it somewhere [03:34] thumper: you mean seeing if the tarball exists? [03:35] wallyworld_: well how about I tell you what I want to do [03:35] ok [03:35] wallyworld_: and you can tell me the easiest way to do it? [03:35] when someone says "create-environment" we want the version to default to the client version, but they should be able to specify a version to use when creating [03:36] the api server needs to check for tool availability [03:36] for created environments, we can't really support upload-tools [03:36] nor do I think we should [03:36] thumper: i could be wrong, but i thought we were heading towards enforcing the same version as the client is used [03:37] also, we need to make sure the requested version is <= current version of the server [03:37] wallyworld_: for bootstrap yes [03:37] since we have run into incompatibility issues even with minor version differences [03:37] wallyworld_: for 'juju create-environment' not necessarily [03:37] ok [03:37] anyway [03:37] the client's juju version may well be different to the api server they are connecting to [03:37] so we need to pass an agent-version through [03:38] the api server then needs to check against its version, and also for tool availability [03:38] so two things: [03:38] best way to have the apiserver check [03:38] and [03:38] best way to test it (i.e. fake the tools that it thinks are available) [03:39] so there's an apiserver ToolsFinder from memory [03:40] i'll need to dig to find some examples, give me a sec [03:43] thumper: if you look at line 53 in apiserver/client/machineconfig.go, you can see how you can set up to ask the tools finder for tools either matching a specific version, or major/minor match [03:45] wallyworld_: fyi I have updated https://github.com/juju/charm/pull/77, I just need to get fwereade to PTAL since he already started reviewing [03:45] in terms of testing, i think there's some stuff in apiserver/common/tools_test.go [03:45] wallyworld_: thanks [03:45] axw: sure, ty, sounds good [03:46] thumper: have a look, and if you need some more info, let me know; i think i've given you what you need, but ask if nt [03:46] cheers [03:46] my kids are starting to go ferel [03:46] ferrel? [03:46] anyway, screaming and fighting [03:46] will ferrel? [03:46] they haven't gotten out today [03:47] feral [03:47] the dog has i bet [03:47] nope [03:47] well, not for a walk [03:47] she would be feral also then [03:48] hmm... [03:48] series... [03:49] I don't have a series... [03:49] actually I have a default-series [03:50] hmm... seems I can leave it blank [04:25] wallyworld_: is there an easy way to get a list of all the tools available? [04:26] thumper: from memory, pass in a search params with major = minor = -1, and empty arch, series etc [04:26] hmm... [04:26] but you'd normally want to filter on arch, series [04:26] or arch at least [04:26] well, when we create an environment, we don't have an arch [04:26] as we aren't actually creating any machines [04:27] there's no current use case apart from possibly sync tools where you need a "find all tools" [04:27] however we do want to use to know that there are some tools available [04:27] so... situation is: [04:27] user says create-environment --version x.y.z [04:27] we check and go "hmm, no tools for that version, but we do have [a,b,c,d]" [04:28] yeah, the api doesn't work like that. you currently ask for version x.y.z and get that or nothing [04:28] hmm... [04:28] bugger [04:28] or you can ask for all tools matching major/minor version [04:29] of with -1 for major, minor, you get everything [04:29] or [04:29] and you then need to iterate the list of tools you get back to see if the version you want is there [04:30] * thumper hmmmms [04:30] I'm going to think about it over night and come back to it. [04:30] cheers [04:30] ok [04:30] we can improve the api if needed [04:31] it fits current use cases [04:34] * thumper nods [04:34] night all [05:56] jam: when discussing storage, did you and sabdfl talk about fallback at all? the updated spec doesn't really work with fallback in mind at all AFAICT. e.g. if you specify --storage, the spec says the pool used is the default pool, rather than any pool that will satisfy [07:53] axw: sorry about the delay, are you still around? [07:54] jam: hiya, yes, I am [07:57] axw: so I believe the "default" source in MaaS was local disk (block devices coming from loop mounts, non-specified sizes just coming from /) [08:00] jam: ok. so we're back to no notion of degrading; the user just has to be explicit if they want something better than loop-back, and if that fails then they need to try again with something else? [08:00] *automatic degrading [08:00] axw: I believe the spec mentioned being able to change the default source for an environment, but otherwise yes [08:01] jam: thanks [08:01] axw: I hope you had good holidays [08:01] welcome back [08:02] jam: pretty relaxing, thanks. and you? [08:02] axw: quite nice. Got to go visit family in Germany. And while we didn't get proper snow, it was at least cold for new years :) [08:02] I guess that isn't how you feel about NY [08:02] ah nice :) [08:02] not in the slightest ;) [08:03] I've been in the pool every day for at least the last week [08:03] axw: I remember martin pool mentioning that to him Christmas was Mai Tai's on the beach [08:03] we just had a barbecue with all the family round ours [08:18] wallyworld_: I have just updated http://reviews.vapour.ws/r/589/ again, removing Minimum and Preferred. The top-level Size is minimum, and Count is just required - there's no reason for anything to over deliver on count [08:18] sure, will look [08:21] wallyworld_: do you know if your change has fixed the regression? it's not clear to me from the CI dashboard [08:21] axw: yes, the previously failing local deployment CI tests pass; there's still a joyent failure though which is separate i think as all the local tests were failing before [08:22] wallyworld_: can we flip it to released, or do you want to wait for QA to verify? [08:23] axw: i just checked, the CI tests are almost finished again for a 2nd commit, the joynet local precise tests are pending. let's wait a bit longer to see how those pan out [08:23] ah ok [08:23] cool [08:23] i'm not sure if we're supposed to flip the bug status ourselves [08:24] or wait for the reporter to do it [08:24] never mind, I can wait [08:45] hi fwereade, I hope you enjoyed your break [08:45] jam, heyhey [08:46] jam, yes, thank you, it was quite disconcertingly peaceful -- and yourself? [08:54] fwereade: pretty good for me. We went to Germany to spend time with relatives for the new year. Got to be properly cold for NY (well 5 on NY, but it did get below zero in Germany) [08:56] fwereade: g'day. we missed our 1:1 earlier. can we do it a bit later [08:56] morning all [08:56] morning [08:56] wallyworld_, oops, so we did, I haven't quite adjusted to a proper timetable [08:56] np, i need to cook and eat dinner etc, can i ping you when i'm ready? [10:01] voidspace, jam? standup time [10:01] dimitern: omw [10:01] in fact, here [10:05] dimitern: you still there? [10:11] TheMue, jam, voidspace: dimitern's internets have fallen over, he's working on it [10:12] fwereade: thx for info [10:33] fwereade: let me know when you're free to chat? [10:33] wallyworld_, cleaner's in here at the moment, maybe 10 mins or something? [10:33] fwereade: sure, np [10:41] fwereade: would you PTAL at https://github.com/juju/charm/pull/77 ? I think/hope your previous concerns should be allayed [10:45] axw, cool, will do [11:13] jam: "NodeGroup is the internal name for a cluster." [11:14] dimitern: jam: it looks like a nodegroup-interface represents a network interface [11:14] A NodeGroupInterface is identified by the uuid for its NodeGroup, and the name of the network interface it represents: “eth0” for example. [11:14] voidspace: that sounds an awful lot like it would be the actual network interface for a machine. Maybe it is the Node Group controller's interface? [11:15] A NodeGroupInterface is a network interface attached to a cluster controller, with its network properties. [11:20] I've asked some questions on #maas [11:20] No reply yet [11:24] morning [11:25] jam: dimitern: an in-between approach (not too much work) is for the provider layer to choose whether it allocates or whether it lets the provider allocate [11:25] jam: dimitern: so with maas we use "dynamic allocation" and with ec2 we use static allocation [11:25] jam: dimitern: then we can move ec2 to dynamic allocation later if we want [11:28] Our current strategy picks an unused address and attempts to allocate that. This returns an error or nil (for success). [11:28] We could let the provider implementation of AllocateAddress return a *different* address if it successfully allocates one [11:28] allowing it to ignore the requested address if it wants to - which the MaaS implementation always would [11:29] slightly janky but flexible [11:29] perrito666: morning === ashipika is now known as ashipika|food [12:04] voidspace, jam, TheMue, sorry guys I was away till now - first network issues, then the heating stopped.. [12:04] dimitern: heya, welcome back [12:04] dimitern: oh, no heating is hard [12:05] dimitern: even harder than no network, hmmmm, or ... *justKidding* [12:06] dimitern: hey, hi [12:06] dimitern: did you see my questions/comments above or should I repeat them? [12:06] :D [12:06] I can see the one about nodegroup-interfaces being NICs [12:06] dimitern: right [12:07] NICs on the cluster controller [12:07] dimitern: is that what we want - will they correspond directly (one-to-one) with networks? [12:07] dimitern: or should I switch to a hybrid approach (which I like but is admittedly slightly janky)? [12:09] voidspace, AIUI networks are created when you add a NGI [12:09] dimitern: so, there always should be the one-to-one correspondence we need [12:09] voidspace, but you can create them manually as well, so this tells me they *might* sometimes not match 100%, but for a definite answer we should consult the maas guys or the source [12:10] I've asked questions on #maas [12:10] no answer yet [12:10] I will proceed assuming they will match [12:10] and will tweak appropriately if needed - or start again with a different approach... [12:10] depending on the answer... [12:11] voidspace, just a sec [12:11] voidspace, it occurred to me there could be valid cases where networks != NGIs [12:11] voidspace, NGI == networks only for those maas is supposed to manage dhcp, dns, or both [12:12] really? [12:12] ah, maybe [12:12] just checking what mine is [12:13] they seem to correspond and I *thought* I didn't have maas managing dhcp or dns, but I might be wrong [12:13] voidspace, it seems logical - otherwise (for non-managed - i.e. vlans, etc.) [12:13] voidspace, sorry, that should've been - for non-managed there's not point in having a NGI associated with the network [12:14] maas is managing dhcp and dns for my cluster [12:15] voidspace, but in any case we *only* care about dhcp-managed networks for the address allocation logic [12:15] dimitern: so we *can't* assume a correspondence, which means (as far as I can tell) that we can't always know the static range of the subnet [12:15] dimitern: ah right, so it doesn't matter - we can *ignore* networks where we don't have this information [12:15] dimitern: so it's one-to-one where we care [12:16] voidspace, that's correct I think and it is reasonable - if maas is not managing dhcp/static ips for that net using the net's corresponding NGI then we don't care [12:16] yeah I think so [12:16] dimitern: cool, thanks [12:17] voidspace, I do have a few unmanaged vlans on my maas [12:17] voidspace, and despite being unmanaged (by maas) I can still use them for instance selection and then configure them (presumably) myself after maas gives me the node [12:18] right, but you wouldn't expect juju to be able to use them [12:18] as they require manual configuration [12:18] not for allocating addresses via the maas api, no :) [12:18] cool, good enough [12:18] but for constrains - yes [12:19] ah, so you'll want Subnets to still return those networks just with nil for the AllocatableIPLow/High [12:19] meaning "no allocatable addresses" [12:19] I think so [12:20] so I won't ignore them then [12:20] right, I'm going on lunch [12:20] cheers [12:20] :) [13:13] is there anything like distcc for go? === fuzzy_ is now known as Fuzai [15:00] ericsnow, perrito666: having some hangout issues [15:01] hangout is love [15:02] wwitzel3: ericsnow helps if we push this one hour? [15:04] perrito666, wwitzel3: fine with me [15:05] ok, lets push it so wwitzel3 can solve his issue without hurrying [15:05] perrito666: it is solved [15:05] wow you are good [15:05] but if you need to push it, that's fine :) [15:05] nah, I am here anyway === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [15:37] dimitern: ping [15:38] voidspace, pong [16:05] wwitzel3, ping [16:05] dimitern: ping [16:06] dimitern: philosophical question [16:06] dimitern: we've called the maas nodegroups api endpoint and got a list of nodegroups (uuids) [16:06] dimitern: we now need to make a series of calls, fetching the nodegroup interfaces for each nodegroup [16:06] dimitern: and pulling out of that the ip, static_range_low and static_range_high for each interface [16:07] voidspace, yeah [16:07] dimitern: an individual call to fetch interfaces for a nodegroup can fail, as can pulling out the details from the result [16:07] dimitern: in the presence of an error should we log and continue (my current approach) or error out? [16:07] dimitern: the downside of logging and continuing is that even if *every call* errors we don't fail - we just return an empty map [16:08] dimitern: the downside of erroring out is that the whole call would fail just for one missing bit of information [16:08] dimitern: e.g. nodegroup deleted between fetching the list of nodegroups and querying the interfaces [16:08] as I said, my current approach is to log (as a Warning) and continue [16:09] voidspace, +1 on logging definitely [16:10] voidspace, but deciding whether to error out entirely or not at the end should be: [16:11] voidspace, if we gathered enough information, despite some errors -> ok, otherwise ... hmmm possibly wrap and return the (most important?) errors [16:11] niemeyer, hey [16:11] dimitern: Heya [16:11] but knowing what's "enough" information or not is difficult :-) [16:12] if we fail to get the information, the result will be that we decide no networks have allocatable IP addresses [16:12] niemeyer, any plans for fix for that issue with gopkg.in not supporting branches like "v2-dev" (I'll try to find the issue #..) [16:12] which is perhaps an odd error to end up with when it's a transient connection failure [16:12] I'll think about it [16:12] alexisb: pong [16:13] hey there wwitzel3 [16:13] can you please join #server [16:13] voidspace, we can have a chat tomorrow perhaps? it's getting late and harder for me to not being stupid :) [16:13] dimitern: ok mate, you go [16:13] dimitern: speak tomorrow [16:13] dimitern: I've got more stuff to do now [16:13] dimitern: Yeah, I'll work on gopkg.in this week [16:14] it's an annoying little decision [16:14] dimitern: There are a couple of things to improve there [16:14] dimitern: the trick is to pick the "less wrong" answer... [16:14] dimitern: The source code linking is also coming [16:14] voidspace, cheers, I'm sure you'll find a nice way to solve it :) [16:14] niemeyer, nice! [16:15] niemeyer, but now it seems you can't import "gopkg.in/amz.v2-dev/ec2" - perhaps I should rename that branch to v2? [16:15] niemeyer, until the changes happen? [16:16] dimitern: Please don't do that.. let me fix the problem [16:16] niemeyer, ok, no problem - I wanted to ask first [16:16] dimitern: For the time being, just do a "git clone" locally to the right location [16:16] niemeyer, yeah, that'll work [16:16] (gopkg.in/amz.v2-dev/ec2) [16:17] niemeyer, thanks! [16:17] dimitern: Labeling as v2 would be advertised as a new major available [16:17] dimitern: which means you should not change it further [16:17] dimitern: in incompatible ways [16:17] dimitern: Or is that what you intend to do in fact? [16:18] niemeyer, yeah, fair point [16:18] niemeyer, no, I intend for it to be stable at least for a while :) [16:18] dimitern: Clarifying the question: do you have further breaking changes to do on v2-dev soon? [16:19] niemeyer, I have 2-3 PRs queued up which add new API methods, but don't break (hopefully) existing ones [16:19] dimitern: Well, so you can just rename it [16:20] dimitern: The point of -dev is to prevent people from using it while in a heavy development period, readying for the release [16:20] dimitern: It sounds like what you want is to release it [16:20] niemeyer, yeah, fair point [16:21] niemeyer, although it's safer to do a few more changes first as I need them anyway, and rename it once v2 is more or less stable [16:21] and juju needs to use v2 [16:23] niemeyer, we should have a call some time this week, if you don't mina and have the time to discuss the other goamz topics - contributors, merging the other forks, etc. [16:24] dimitern: Sounds good, but "stability in this case" is not "won't change", but "won't change in incompatible ways" [16:24] dimitern: Of course [16:24] dimitern: Will be a pleasure [16:24] niemeyer, right, cheers! [16:26] niemeyer, which of the coming days works for you? perhaps ~1h or less - also at what time? [16:28] dimitern: I suppose now is too late for you, right? [16:28] dimitern: I mean, at this time, different day [16:28] niemeyer, yeah, tomorrow about this time is better for me - should I sent and invite then? [16:29] dimitern: +1 [16:29] dimitern: Oh, wait [16:29] niemeyer, yeah? [16:29] dimitern: I have a 30mins slot at this time [16:30] dimitern: Feel free to start 30 mins earlier, or reduce the slot [16:30] niemeyer, ok, so let's say 16 UTC tomorrow for 1h? [16:30] dimitern: Sounds good [16:31] niemeyer, thanks, I'll send an invite then === negronjl-afk is now known as negronjl [17:09] wwitzel3: ericsnow any volunteers to answer that last email? [17:09] that was fast :p [17:12] wwitzel3, you when the prize for fastest status reporting :) [17:12] alexisb: we still need to verify that networking is not required (only 1(?) existing provider implements it) [17:12] alexisb: not sure I want the prize .. lol [17:14] ericsnow, same with storage? [17:15] alexisb: they all (or nearly) have storage implemented, but only because it was required for juju up until recently (yay axw) [17:16] ah ok ericsnow [17:17] so ericsnow, wwitzel3 what do you guys need from me to help answer what is needed for storage and network support? [17:18] alexisb: the question came up as we jumped back in yesterday and I figured we'd just ask dimitern [17:19] (looks like I missed him though) [17:20] alexisb: I do think if we still want the networking stuff now it could wait until after we land the GCE provider [17:20] alexisb: as to storage, I'm pretty confident we don't need it; I'll follow up with axw tonight [17:21] ericsnow: wwitzel3 alexisb I have a decent overlap with dimitern do you need me to tackle him and ask him something? [17:22] perrito666: feel free to ask him if networking needs to be implemented for the GCE provider (basically none of the other providers have it) [17:27] ericsnow: patch is merged, I am going to try a manual fix that smoser suggested for testing purposes [17:27] wwitzel3: great! [17:33] ericsnow: we have a regression [17:34] wwitzel3: :( [17:34] ericsnow: with the root disk stuff in instance.go [17:34] wwitzel3: k [17:34] ericsnow: http://paste.ubuntu.com/9683253/ [17:35] wwitzel3: want to jump into the hangout? [17:35] ericsnow: yep === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None === kadams54 is now known as kadams54-away [18:18] is there a list for the possible agentconfig keys?= [18:34] g'night all [18:34] nn voidspace [18:34] o/ === makyo_ is now known as Makyo [18:38] katco: I was really fearing that was a longer pr :p given the extensive description [18:38] perrito666: lol glad to disappoint in that regard :) [18:38] perrito666: i like to provide helpful commit messages if i can remember [18:40] * katco goes to fix lunch === kadams54 is now known as kadams54-away [20:37] cherylj: got a few minutes now? [20:38] thumper: yes [20:41] niemeyer: hey, you around? [20:58] thumper: Here [21:09] cmars: ping [21:10] thumper, pong === kadams54-away is now known as kadams54 [21:10] cmars: 'tis our weekly chat time [21:10] thumper, ah right. joining [21:15] fwereade: ping, 2015 style. === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [21:34] alexisb: you free for our QA meeting? [21:34] wallyworld_, no I have a conflict today [21:35] ok === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [22:46] wallyworld_: just reviewed http://reviews.vapour.ws/r/678/ [22:46] wallyworld_: just a few questions [22:46] \o/ tyvm [22:47] having breakfast, will look soon [22:48] wallyworld_, thumper: there's PR with fixes for the cloudsigma provider up for review. is anyone sheparding that work or should I review it? [22:49] menn0: I think there is someone sheparding it, but I don't recall who [22:49] ditto [22:49] jam? [22:49] wayne maybe [22:50] i'll ask them [22:50] menn0: thumper its wayne [22:50] perrito666: ta [22:50] perrito666: thanks [22:50] * menn0 is glad to dodgy that large review [22:50] * perrito666 returned from EOD mode just for that, bye folks [22:50] dodge even [22:50] perrito666: good night === kadams54 is now known as kadams54-away