[01:29] Bug #1536425 opened: Juju metadata cannot make streams with 1.x and 2.x agents

[01:29] Bug #1536426 opened: Juju metadata cannot make streams with 1.x and 2.x agents

[01:40] davecheney: what is the simplest way to create a copy of []string? [01:40] is it: target := source[:] [01:40] ? [01:40] or do you go: [01:40] target := make([]string, len(source)) [01:40] copy(target, source) [01:42] seems that the first is good enough === rharper` is now known as rharper [02:11] thumper: do you want to copy the string header value, or the contents of the string [02:11] the former is easy, just assign [02:11] the latter requires a copy if you want the backing array of the source and copy to be different [02:11] I want a change in source to not change target [02:21] then you need to copy the contents of the slice [02:43] davecheney: the [:] makes a copy right? [02:43] davecheney: on another take... guess what? [02:43] fslock is fubared [02:43] menn0 is annotating a bug [02:44] thumper: [x:y] is the slicing operator, which never copies the backing array === natefinch-afk is now known as natefinch [02:44] natefinch: http://play.golang.org/p/TJlPFkr9wD [02:44] natefinch: hmm... [02:44] * thumper pokes [02:45] ok, figured it out [02:45] append makes you a new backing array there [02:47] yeah, figured that bit out [02:47] ta [02:48] [:] copies the struct value, which still points to the same backing array [02:48] var s []string [02:48] x := s[:] [02:48] isthe same as [02:48] x := x [02:48] oh wallyworld [02:48] x := s [02:49] yo [02:49] wallyworld: I have a master blocker to give you [02:49] oh joy [02:49] because I'm busy with model migrations :) [02:49] sigh, i'm busy too :-( [02:49] thumper, wallyworld: https://bugs.launchpad.net/juju-core/+bug/1536378 [02:50] Bug #1536378: resolver loop error in maas-1_8-OS-deployer test

[02:50] updating the bug with new info now [02:50] wallyworld: I know, everyone is busy [02:50] but I've been given the "go away" sign for my door [02:51] davecheney: surprise surprise the alive stuff in fslock doesn't work [02:51] remind me to "thank" alexis [02:51] wallyworld: she did give you the choice remember [02:51] choice of wot? [02:51] me or axw_ [02:52] ? [02:52] to do the model migrations work i think he means [02:52] axw_: it was who was going to work on model migrations [02:52] ah, I had no idea :) [02:53] we were going to do CMR [02:53] yeah, wallyworld sheltered you [02:53] * axw_ retreats back into cave [02:53] that was before CMR go pulled [02:53] like a good manager === axw_ is now known as axw [02:53] * rick_h_ hands out umbrellas to everyone [02:53] thumper: i think I just won some kind of bet [02:53] thumper: will you let me rip it out now ? [02:54] I was happy to have it ripped out before [02:54] who wanted it kept? [02:54] I forget [02:54] thumper: you did [02:54] there was some concern about shared filesystems I think? [02:54] well, we put it to juju-dev and htere was the usual round of non committal 'well, maybe we need it' [02:55] we don't even need to worry about that when we do XDG properly [02:55] combined with the usual bike shedding on how one _could_ implement that feature [02:56] davecheney: I seem to recall a twitter poll... ;) [02:56] indeed [02:56] ugh [02:56] fark [02:57] I'd like to see it replaced with something else that works on windows / linux / maxos [02:57] that unlocks if the process dies [02:57] I don't care about the underlying implementation [02:57] I can do that 100% reliably on linux [02:57] I can do that 100% reliably on windows [02:57] create some interface that we can hide behind [02:58] osx would have to be a tcp socket listneing on localhost [02:58] that has both lock, and lockWithTimeout [02:58] lock is just lockWithTimeout(MAXINT) [02:59] np [03:00] davecheney: JFDI [03:05] Bug # opened: 1536445, 1536446, 1536447, 1536448 [03:06] kk [03:08] thumper: https://bugs.launchpad.net/juju-core/+bug/1465317/comments/12 [03:08] Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series

[03:10] davecheney: I was looking into that code in Oakland, since I was factoring out the version stuff to live outside of juju/juju for use by the charm repo (for MinJujuVersion). IIRC, the places where we actually care that a series is "known" or not are very limited... and usually it would be fine to fail later (e.g. when we can't find a matching tools stream). [03:11] natefinch: yeah, i think so too [03:11] i think it's reasonably safe to add an "unknown" series [03:11] I agree [03:12] as long as it's really unknown... if it's Zany Zebra and it's just not in our list, if it still comes across as "zany", then I think that's ok. if zany gets turned into unknown, then we're basically back where we started. [03:14] I'd rather we keep it zany [03:14] and just not find tools etc [03:15] exactly [03:15] ...until tools appear, and then it just magically works [03:17] and we stop getting these bugs every time a new ubuntu or windows or osx version comes out [03:18] thumper: we can do that for linux [03:18] but for windows and OSX there is no tool to map their internel release name to a name [03:19] what is the series of OSX 10.20.0 ? [03:19] maybe we just say "10.20.0" [03:19] it won't match any tools [03:19] but you cannot bootstrap to OSX, so that's not a big deal [03:19] wallyworld, thumper, davecheney: bug 1536378 updated [03:19] Bug #1536378: fslock staleness checks are broken

[03:20] now creating another bug with all the other stuff that's broken in fslock [03:21] menn0: so is that a second blocker? [03:22] wallyworld: the others are less likely to be hit, probably not worth blocking for [03:22] menn0: oh, reading the comment in the maas blocker implicates fslock? [03:23] davecheney: we actually get a string name for windows... I guess we just thought it was too long, so we made a map to shorter names... nothing says we couldn't change that and just use the real name for the tools.. it's not like they're something a user should ever see. [03:23] wallyworld: yep I believe the fslock bug is the reason for the MAAS CI test failure [03:23] wallyworld: I'm amazed that not more is broken [03:24] so thumper introduces a bug and flocks it off to me \0/ i owe him a beer [03:33] actually i take it back, someone else introduced the bug, not thumper. damn, can't blame him now [03:51] oh dear [03:51] juju still has two different types of file lock [03:51] juju/utils/fslock, and juju/juju/utils/filelock [03:53] fsutils.Lock calls lock.clean before starting to lock the lock [03:53] fsutils.LockWithTimeout does not call lock.clean [03:53] one of those is wrong [03:53] i cannot tell which [03:56] and this is why man invented the coin toss [03:56] ....also unit tests [04:00] logger.Warningf("breaking configstore lock, lock dir: %s", filepath.Join(dir, lockName)) [04:00] logger.Warningf(" lock holder message: %s", lock.Message()) [04:00] multi line logging ? srsly [04:00] rofl [04:01] menn0_: with logging to mongo, do we still need logsink.log? [04:02] davecheney: are you fixing the blocker? i was going to start looking but don't want to double up [04:03] yup, i'm looking at the lock type [04:03] * davecheney scrubs for surgeery [04:03] awesome, ty [04:05] wallyworld: yes [04:06] wallyworld: logsink.log is the file that we use if mongo goes awol [04:06] thumper: makes sense, ty. i have a branch with rsyslog all removed [04:06] wallyworld: logsink.log was created as part of the logging to mongo [04:06] \o/ [04:06] * thumper is done for the day [04:06] later [04:08] davecheney: i'm not sure what you're thinking but I wonder if now is the time to change fslock to use OS primitives for locking (as already discussed on juju-dev) instead of the current mess [04:08] davecheney: all the current complexity and bugs are because it's doing it wrong [04:09] davecheney, wallyworld: bug 1536378 describes the other fslock issues discovered today [04:09] Bug #1536378: fslock staleness checks are broken

[04:09] davecheney, wallyworld: sorry bug 1536461 [04:09] Bug #1536461: fslock bugs [04:09] awesome, more bugs \o/ [04:10] menn0_: i see a bunch of work was done to fslock since it was originally written - obviously not well reviewed [04:12] Bug #1536461 opened: fslock bugs === menn0_ is now known as menn0 === menn0 is now known as menn0_ [04:25] menn0_: wallyworld thumper, minimal fix https://github.com/juju/utils/pull/190 [04:25] awesome [04:26] davecheney: I think the retry loop might have been a way to paper over the race created by the RemoveAll in NewLock (see bug 1536461) [04:26] Bug #1536461: fslock bugs [04:27] davecheney: as long as that race is there, the loop might be necessary [04:27] menn0_: there are lots and lots of problems in that type [04:27] davecheney: agreed [04:27] for example, Lock calls clean which does the isAlive/BreakLock dance [04:27] LockWithTimeout does not call clean [04:28] which looks like an oversight [04:28] the "if your pid matche the pid of the lock" is also a bug [04:28] davecheney: yes, that's one of the problems I mention in bug 1536461 (you should look there) [04:28] Bug #1536461: fslock bugs [04:29] davecheney: i made a comment, not sure if you agree [04:29] davecheney: I'm not sure that the "if PID == lock.PID" is necessarily wrong [04:29] davecheney: this function is about deciding if the PID which owns the lock is alive [04:29] if two workers inside the same process are relying on this lcok to stop them walking over each other [04:30] it is [04:30] we probably don't have that code path today [04:30] but it's just a matter of time [04:30] davecheney: not about whether the the lock is held [04:30] the logic of "make lock, then lock it" is insane [04:30] you sholdn't be able to create a lock unless you hold it [04:30] davecheney: isAlive is about whether a process is alive and keeping the current lock "held" [04:31] davecheney: yep I agree with that [04:51] menn0_: I added a long rebuttle why I think retring is pretty pointless === menn0_ is now known as menn0-afk [05:06] wallyworld: http://reviews.vapour.ws/r/3585/ [05:06] any more comments [05:06] looking [05:06] ta [05:12] davecheney: reviewed, but if we close the current blocker there should be a bug opened for the proper fix [05:17] wallyworld: menn0 has created a placholder bug listing all the probles [05:17] wallyworld: 1536461 [05:17] ok, ty [05:17] i was just concerned this specific bug would be closed for the quick fix and not followed up [05:17] as part of a longer term fix [05:19] wallyworld: yup, a long term fix is to stop using pid files on disk [05:19] which is my plan [05:19] indeed [05:46] wallyworld: can you please re review [05:46] i got scared and rolled back most of my change [05:46] ok [05:46] now the patch just loops like the logic originally did [05:46] but actually loops [05:46] i think this is the safer change [05:48] yep, +1 [05:48] that was my main issue with the first changes [05:56] wallyworld: https://github.com/juju/juju/pull/4162 -- refactored credentials types, added list-credentials [05:56] yay [05:56] axw: will look in about 15 [05:56] wallyworld: next will be extending providers to return schemas, need to tidy that up. probably will be a big one [05:56] wallyworld: thanks, no great rush [05:56] wallyworld: CI bot is fucked up, it cannot tell time anymore [05:56] http://paste.ubuntu.com/14588528/ [05:57] sigh [05:57] tried twice in a row [05:58] we'll have to try again i guess and let curtis know [06:09] Bug #1536477 opened: utils/debugstatus: test failure [06:13] wallyworld: so we're definitely removing the old azure from 2.0? [06:13] axw: yep [06:13] wallyworld: if so, I'm going to do that now, because it'll make my job easier in the cloud credentials branch [06:13] k [06:14] axw: we're supporting 1.25 for 2 years [06:14] wallyworld: *nods* [06:15] wallyworld: hmm, CI probably isn't ready for it though [06:15] Bug #1536477 changed: utils/debugstatus: test failure [06:15] I'll just put it up for review anyway, then land when CI is ready [06:18] Bug #1536477 opened: utils/debugstatus: test failure [06:28] axw: yes, i am having conversations about CI for the api rename branch. i've added that to the list of topics. [06:28] wallyworld: ta [06:35] wallyworld: https://github.com/juju/juju/pull/4163 [06:35] fix to juju/juju [06:35] ok [06:35] the whole of juju/juju? [06:36] if only [06:36] lgtm [06:39] Bug #1536480 opened: Disallow deploying multiple units to the same container by default [07:07] axw: reviewed, have to head to soccer in about 45 minutes, will look again when i get back if not before [07:07] wallyworld: ok ta [07:37] wallyworld: addressed some but not all comments, PTAL when you can [07:37] sure [07:43] axw: responded [07:53] wallyworld: PTAL [07:54] ok [08:01] axw: done, ty. now off to soccer [08:01] wallyworld: later, enjoy [09:14] hello to everyone...I have a problem with a bootstrap, is this the right channel? [09:28] I'm trying to bootstrap juju with two maas machines, that actually are two VM into VMWare... I installed the Maas controller on another machine, and the bootstrap seems to go well, it installs the OS cloud into the first of the two machines but when it comes to MongoDB replica stuff, it fails. I have under my hands the logs that I see in this situation [09:39] Muntaner: maybe you better ask on #juju. here it's more development of juju [09:48] ok TheMue, sorry : ) [09:49] Muntaner: yw, no need to excuse. is only a hint. [10:03] jam: stdup? [10:03] dooferlad: frobware: small PR http://reviews.vapour.ws/r/3590/ === Odd_Blok1 is now known as Odd_Bloke [11:33] Bug #1536587 opened: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap

[11:39] Bug #1536587 changed: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap

[11:42] Bug #1536587 opened: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap

[11:45] Bug #1536587 changed: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap

[11:48] Bug #1536587 opened: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap

[11:52] any fancy a review of a new (to juju/utils) URL utility function? https://github.com/juju/utils/pull/191 [11:54] I'll bite. [11:55] mgz: ta! [11:56] mgz: if you can think of any unusual corner cases that aren't covered in the test table, i'd like to know [11:56] hm, there's nothing actually urly about this [11:56] mgz: urls are an obtuse thing! [11:56] doesn't do anything with schemes [11:57] mgz: URL paths [11:57] mgz: still part of URLs [11:58] mgz: the RFC is definitely pertinent here [11:59] rogpeppe: this is basically os.path.relpath though [11:59] mgz: yeah, except for it's URL-specific [11:59] mgz: os.path.relpath wouldn't work here [12:00] I'm not seeing any case where it actually differs [12:00] mgz: os.path.relpath doesn't treat trailing slashes as significant [12:00] I mean, that's not a reason we don't need this, if go doesn't have it [12:00] aha, yeah, that is true [12:01] which if these tests cover that... [12:04] rogpeppe: does it ever make sense for base to not start with a / ? [12:05] mgz: not in the use case that we've been using it for, but it's possible [12:05] also both have to be normalised already (as in, not contain .././) [12:06] mgz: yeah, that's true. perhaps i should normalise them with path.Clean [12:06] asserting both are abs paths seems good for the moment [12:09] rogpeppe: lgtm [12:09] mgz: thanks [12:10] mgz: tbh i don't know of any http muxers that allow .. or . in the middle of paths. [12:10] mgz: although... actually i think http.ServeMux returns a redirect if the path isn't clean, which kinda avoids the issue [12:13] I think just stating the obvious in the function doc comment should be fine [12:14] there are few cases in code where you'll actually deal with non-normalised paths and they tend to be obvious [12:15] mgz: yeah [12:24] voidspace, dooferlad: can we take another pass through this - http://reviews.vapour.ws/r/3570/. I've only just got back to it... [12:24] frobware: looking [12:31] frobware: your unique option filtering, is that tested? [12:32] voidspace, since I posted I'm going to revert that change. [12:32] frobware: unique_options should really be a set not a list [12:32] frobware: hah [12:32] voidspace, set doesn't guarantee original order. [12:32] frobware: true enough [12:32] voidspace, I could switch to ordered set. [12:33] voidspace, but I know recall why I started making it unique and that should be a separate change. [12:34] frobware: ok [12:34] voidspace, in my experiments yesterday with dns-nameserver we need to collapse duplicate entries to a single line, so this is not appropriate. [12:34] frobware: for small "sets" a list is fine [12:34] for long lists testing membership is slow [12:34] voidspace, I want fewer changes to the original /e/n/i as possible. [12:34] voidspace, makes it clear what buthering "we" did [12:34] frobware: good call [12:35] voidspace, understood the perf. call, but we're dealing with < 10 entries in general. [12:35] voidspace, of all the things... I don't think we have a performance problem. :) [12:37] :-) [12:38] frobware: is the new diff ready for review? [12:38] voidspace, yep. pushed. [12:41] frobware: LGTM [12:41] voidspace, thx [12:58] axw: wait, are we droping $JUJU_HOME? [13:35] mgz, ping [13:36] wow testing is too different from the version we are using, anyone knows why? [13:36] frobware: hey [13:37] mgz, so we monster merged master into maas-spaces and I was looking when maas-spaces was last blessed which turns out to be ~39 days ago. Is and will maas-spaces be tested in CI? Do we have to do anything to trigger this, et al? Would really like to ensure our merge into maas-spaces will eventually get back into a blessed stated so we can merge into master. [13:38] frobware: I can get it queued today [13:38] mgz, great. thanks. [13:39] we're still suffering from shortage of maas capacity [13:51] mgz: mass 1.9 is ill. Nodes are not coming up. Releasing the held nodes and restarting did not fix the issue. I need more coffee before I can fix this [13:53] sinzui: will have a look [14:16] sinzui, mgz, maas trusty daily image woes. #maas @ c [14:16] :/ [14:16] thank you beisner [14:17] sinzui, yw i think ;-) [14:19] jam: ? [14:19] perrito666: ? [14:19] it's a punctuation fight! Go!! [14:20] I have a doubt (2 actually) regarding juju2 supporting xdg [14:20] natefinch: please, I have stuff like ¿ [14:20] jam: are we dropping JUJU_HOME ? [14:21] I would think that JUJU_HOME supersedes any other setting [14:21] mgz: Can you review https://code.launchpad.net/~sinzui/juju-ci-tools/unit-test-install-deps/+merge/283450 [14:21] jam: I thought so too, but axw made a few comments in my PR which made me doubt [14:21] link? [14:22] the second is regarding XDG_DATA_HOME are we honoring that? [14:22] jam: the second is regarding XDG_DATA_HOME are we honoring that [14:23] perrito666: I don't think we have the concept of a set of DATA files. Isn't that usually things for local installs of resources that you consume? [14:23] given .local/share [14:23] which matches /usr/share, right? [14:24] jam: well it is a bit of a blurry concept I think, I have seen people not be consistent on that one [14:24] that is why I did a straight replace [14:24] so, *today* I don't believe we consume anything from /usr/share [14:24] but if we are going to deem certain things as "data" there is more thought to be put into this [14:24] the closest we have is /usr/lib/juju/ where we put things like mongo [14:24] but I don't think we have any plans to read that out of a users home dir [14:25] I'd think we'd just support XDG_CONFIG_HOME for this [14:26] works for me [14:30] jam: tx for your help [14:30] perrito666: happy to [14:38] anyone have ideas on how I can store (and more importantly) update a map[string]string in mongo? [14:38] natefinch: you just do it? [14:39]