| mup | Bug #1536425 opened: Juju metadata cannot make streams with 1.x and 2.x agents <metadata> <regression> <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1536425> | 01:29 |
|---|---|---|
| mup | Bug #1536426 opened: Juju metadata cannot make streams with 1.x and 2.x agents <metadata> <regression> <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1536426> | 01:29 |
| thumper | davecheney: what is the simplest way to create a copy of []string? | 01:40 |
| thumper | is it: target := source[:] | 01:40 |
| thumper | ? | 01:40 |
| thumper | or do you go: | 01:40 |
| thumper | target := make([]string, len(source)) | 01:40 |
| thumper | copy(target, source) | 01:40 |
| thumper | seems that the first is good enough | 01:42 |
| === rharper` is now known as rharper | ||
| davecheney | thumper: do you want to copy the string header value, or the contents of the string | 02:11 |
| davecheney | the former is easy, just assign | 02:11 |
| davecheney | the latter requires a copy if you want the backing array of the source and copy to be different | 02:11 |
| thumper | I want a change in source to not change target | 02:11 |
| davecheney | then you need to copy the contents of the slice | 02:21 |
| thumper | davecheney: the [:] makes a copy right? | 02:43 |
| thumper | davecheney: on another take... guess what? | 02:43 |
| thumper | fslock is fubared | 02:43 |
| thumper | menn0 is annotating a bug | 02:43 |
| natefinch-afk | thumper: [x:y] is the slicing operator, which never copies the backing array | 02:44 |
| === natefinch-afk is now known as natefinch | ||
| thumper | natefinch: http://play.golang.org/p/TJlPFkr9wD | 02:44 |
| thumper | natefinch: hmm... | 02:44 |
| * thumper pokes | 02:44 | |
| thumper | ok, figured it out | 02:45 |
| natefinch | append makes you a new backing array there | 02:45 |
| thumper | yeah, figured that bit out | 02:47 |
| thumper | ta | 02:47 |
| davecheney | [:] copies the struct value, which still points to the same backing array | 02:48 |
| davecheney | var s []string | 02:48 |
| davecheney | x := s[:] | 02:48 |
| davecheney | isthe same as | 02:48 |
| davecheney | x := x | 02:48 |
| thumper | oh wallyworld | 02:48 |
| davecheney | x := s | 02:48 |
| wallyworld | yo | 02:49 |
| thumper | wallyworld: I have a master blocker to give you | 02:49 |
| wallyworld | oh joy | 02:49 |
| thumper | because I'm busy with model migrations :) | 02:49 |
| wallyworld | sigh, i'm busy too :-( | 02:49 |
| menn0 | thumper, wallyworld: https://bugs.launchpad.net/juju-core/+bug/1536378 | 02:49 |
| mup | Bug #1536378: resolver loop error in maas-1_8-OS-deployer test <juju-core:Incomplete> <juju-core machine-dep-engine:Triaged> <https://launchpad.net/bugs/1536378> | 02:50 |
| menn0 | updating the bug with new info now | 02:50 |
| thumper | wallyworld: I know, everyone is busy | 02:50 |
| thumper | but I've been given the "go away" sign for my door | 02:50 |
| thumper | davecheney: surprise surprise the alive stuff in fslock doesn't work | 02:51 |
| wallyworld | remind me to "thank" alexis | 02:51 |
| thumper | wallyworld: she did give you the choice remember | 02:51 |
| wallyworld | choice of wot? | 02:51 |
| thumper | me or axw_ | 02:51 |
| axw_ | ? | 02:52 |
| wallyworld | to do the model migrations work i think he means | 02:52 |
| thumper | axw_: it was who was going to work on model migrations | 02:52 |
| axw_ | ah, I had no idea :) | 02:52 |
| wallyworld | we were going to do CMR | 02:53 |
| thumper | yeah, wallyworld sheltered you | 02:53 |
| * axw_ retreats back into cave | 02:53 | |
| wallyworld | that was before CMR go pulled | 02:53 |
| thumper | like a good manager | 02:53 |
| === axw_ is now known as axw | ||
| * rick_h_ hands out umbrellas to everyone | 02:53 | |
| davecheney | thumper: i think I just won some kind of bet | 02:53 |
| davecheney | thumper: will you let me rip it out now ? | 02:53 |
| thumper | I was happy to have it ripped out before | 02:54 |
| thumper | who wanted it kept? | 02:54 |
| thumper | I forget | 02:54 |
| davecheney | thumper: you did | 02:54 |
| axw | there was some concern about shared filesystems I think? | 02:54 |
| davecheney | well, we put it to juju-dev and htere was the usual round of non committal 'well, maybe we need it' | 02:54 |
| axw | we don't even need to worry about that when we do XDG properly | 02:55 |
| davecheney | combined with the usual bike shedding on how one _could_ implement that feature | 02:55 |
| axw | davecheney: I seem to recall a twitter poll... ;) | 02:56 |
| davecheney | indeed | 02:56 |
| thumper | ugh | 02:56 |
| thumper | fark | 02:56 |
| thumper | I'd like to see it replaced with something else that works on windows / linux / maxos | 02:57 |
| thumper | that unlocks if the process dies | 02:57 |
| thumper | I don't care about the underlying implementation | 02:57 |
| davecheney | I can do that 100% reliably on linux | 02:57 |
| natefinch | I can do that 100% reliably on windows | 02:57 |
| thumper | create some interface that we can hide behind | 02:57 |
| davecheney | osx would have to be a tcp socket listneing on localhost | 02:58 |
| thumper | that has both lock, and lockWithTimeout | 02:58 |
| davecheney | lock is just lockWithTimeout(MAXINT) | 02:58 |
| wallyworld | np | 02:59 |
| thumper | davecheney: JFDI | 03:00 |
| mup | Bug # opened: 1536445, 1536446, 1536447, 1536448 | 03:05 |
| davecheney | kk | 03:06 |
| davecheney | thumper: https://bugs.launchpad.net/juju-core/+bug/1465317/comments/12 | 03:08 |
| mup | Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series <osx> <packaging> <wily> <windows> <juju-core:Triaged> <juju-core 1.24:Won't Fix> <juju-core 1.25:Triaged by dave-cheney> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1465317> | 03:08 |
| natefinch | 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:10 |
| davecheney | natefinch: yeah, i think so too | 03:11 |
| davecheney | i think it's reasonably safe to add an "unknown" series | 03:11 |
| natefinch | I agree | 03:11 |
| natefinch | 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:12 |
| thumper | I'd rather we keep it zany | 03:14 |
| thumper | and just not find tools etc | 03:14 |
| natefinch | exactly | 03:15 |
| natefinch | ...until tools appear, and then it just magically works | 03:15 |
| natefinch | and we stop getting these bugs every time a new ubuntu or windows or osx version comes out | 03:17 |
| davecheney | thumper: we can do that for linux | 03:18 |
| davecheney | but for windows and OSX there is no tool to map their internel release name to a name | 03:18 |
| davecheney | what is the series of OSX 10.20.0 ? | 03:19 |
| davecheney | maybe we just say "10.20.0" | 03:19 |
| davecheney | it won't match any tools | 03:19 |
| davecheney | but you cannot bootstrap to OSX, so that's not a big deal | 03:19 |
| menn0 | wallyworld, thumper, davecheney: bug 1536378 updated | 03:19 |
| mup | Bug #1536378: fslock staleness checks are broken <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1536378> | 03:19 |
| menn0 | now creating another bug with all the other stuff that's broken in fslock | 03:20 |
| wallyworld | menn0: so is that a second blocker? | 03:21 |
| menn0 | wallyworld: the others are less likely to be hit, probably not worth blocking for | 03:22 |
| wallyworld | menn0: oh, reading the comment in the maas blocker implicates fslock? | 03:22 |
| natefinch | 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 |
| menn0 | wallyworld: yep I believe the fslock bug is the reason for the MAAS CI test failure | 03:23 |
| menn0 | wallyworld: I'm amazed that not more is broken | 03:23 |
| wallyworld | so thumper introduces a bug and flocks it off to me \0/ i owe him a beer | 03:24 |
| wallyworld | actually i take it back, someone else introduced the bug, not thumper. damn, can't blame him now | 03:33 |
| davecheney | oh dear | 03:51 |
| davecheney | juju still has two different types of file lock | 03:51 |
| davecheney | juju/utils/fslock, and juju/juju/utils/filelock | 03:51 |
| davecheney | fsutils.Lock calls lock.clean before starting to lock the lock | 03:53 |
| davecheney | fsutils.LockWithTimeout does not call lock.clean | 03:53 |
| davecheney | one of those is wrong | 03:53 |
| davecheney | i cannot tell which | 03:53 |
| natefinch | and this is why man invented the coin toss | 03:56 |
| natefinch | ....also unit tests | 03:56 |
| davecheney | logger.Warningf("breaking configstore lock, lock dir: %s", filepath.Join(dir, lockName)) | 04:00 |
| davecheney | logger.Warningf(" lock holder message: %s", lock.Message()) | 04:00 |
| davecheney | multi line logging ? srsly | 04:00 |
| natefinch | rofl | 04:00 |
| wallyworld | menn0_: with logging to mongo, do we still need logsink.log? | 04:01 |
| wallyworld | davecheney: are you fixing the blocker? i was going to start looking but don't want to double up | 04:02 |
| davecheney | yup, i'm looking at the lock type | 04:03 |
| * davecheney scrubs for surgeery | 04:03 | |
| wallyworld | awesome, ty | 04:03 |
| thumper | wallyworld: yes | 04:05 |
| thumper | wallyworld: logsink.log is the file that we use if mongo goes awol | 04:06 |
| wallyworld | thumper: makes sense, ty. i have a branch with rsyslog all removed | 04:06 |
| menn0_ | wallyworld: logsink.log was created as part of the logging to mongo | 04:06 |
| thumper | \o/ | 04:06 |
| * thumper is done for the day | 04:06 | |
| wallyworld | later | 04:06 |
| menn0_ | 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 |
| menn0_ | davecheney: all the current complexity and bugs are because it's doing it wrong | 04:08 |
| menn0_ | davecheney, wallyworld: bug 1536378 describes the other fslock issues discovered today | 04:09 |
| mup | Bug #1536378: fslock staleness checks are broken <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1536378> | 04:09 |
| menn0_ | davecheney, wallyworld: sorry bug 1536461 | 04:09 |
| mup | Bug #1536461: fslock bugs <juju-core:New> <https://launchpad.net/bugs/1536461> | 04:09 |
| wallyworld | awesome, more bugs \o/ | 04:09 |
| wallyworld | menn0_: i see a bunch of work was done to fslock since it was originally written - obviously not well reviewed | 04:10 |
| mup | Bug #1536461 opened: fslock bugs <juju-core:New> <https://launchpad.net/bugs/1536461> | 04:12 |
| === menn0_ is now known as menn0 | ||
| === menn0 is now known as menn0_ | ||
| davecheney | menn0_: wallyworld thumper, minimal fix https://github.com/juju/utils/pull/190 | 04:25 |
| wallyworld | awesome | 04:25 |
| menn0_ | 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 |
| mup | Bug #1536461: fslock bugs <juju-core:Triaged> <https://launchpad.net/bugs/1536461> | 04:26 |
| menn0_ | davecheney: as long as that race is there, the loop might be necessary | 04:27 |
| davecheney | menn0_: there are lots and lots of problems in that type | 04:27 |
| menn0_ | davecheney: agreed | 04:27 |
| davecheney | for example, Lock calls clean which does the isAlive/BreakLock dance | 04:27 |
| davecheney | LockWithTimeout does not call clean | 04:27 |
| davecheney | which looks like an oversight | 04:28 |
| davecheney | the "if your pid matche the pid of the lock" is also a bug | 04:28 |
| menn0_ | davecheney: yes, that's one of the problems I mention in bug 1536461 (you should look there) | 04:28 |
| mup | Bug #1536461: fslock bugs <juju-core:Triaged> <https://launchpad.net/bugs/1536461> | 04:28 |
| wallyworld | davecheney: i made a comment, not sure if you agree | 04:29 |
| menn0_ | davecheney: I'm not sure that the "if PID == lock.PID" is necessarily wrong | 04:29 |
| menn0_ | davecheney: this function is about deciding if the PID which owns the lock is alive | 04:29 |
| davecheney | if two workers inside the same process are relying on this lcok to stop them walking over each other | 04:29 |
| davecheney | it is | 04:30 |
| davecheney | we probably don't have that code path today | 04:30 |
| davecheney | but it's just a matter of time | 04:30 |
| menn0_ | davecheney: not about whether the the lock is held | 04:30 |
| davecheney | the logic of "make lock, then lock it" is insane | 04:30 |
| davecheney | you sholdn't be able to create a lock unless you hold it | 04:30 |
| menn0_ | davecheney: isAlive is about whether a process is alive and keeping the current lock "held" | 04:30 |
| menn0_ | davecheney: yep I agree with that | 04:31 |
| davecheney | menn0_: I added a long rebuttle why I think retring is pretty pointless | 04:51 |
| === menn0_ is now known as menn0-afk | ||
| davecheney | wallyworld: http://reviews.vapour.ws/r/3585/ | 05:06 |
| davecheney | any more comments | 05:06 |
| wallyworld | looking | 05:06 |
| davecheney | ta | 05:06 |
| wallyworld | davecheney: reviewed, but if we close the current blocker there should be a bug opened for the proper fix | 05:12 |
| davecheney | wallyworld: menn0 has created a placholder bug listing all the probles | 05:17 |
| davecheney | wallyworld: 1536461 | 05:17 |
| wallyworld | ok, ty | 05:17 |
| wallyworld | i was just concerned this specific bug would be closed for the quick fix and not followed up | 05:17 |
| wallyworld | as part of a longer term fix | 05:17 |
| davecheney | wallyworld: yup, a long term fix is to stop using pid files on disk | 05:19 |
| davecheney | which is my plan | 05:19 |
| wallyworld | indeed | 05:19 |
| davecheney | wallyworld: can you please re review | 05:46 |
| davecheney | i got scared and rolled back most of my change | 05:46 |
| wallyworld | ok | 05:46 |
| davecheney | now the patch just loops like the logic originally did | 05:46 |
| davecheney | but actually loops | 05:46 |
| davecheney | i think this is the safer change | 05:46 |
| wallyworld | yep, +1 | 05:48 |
| wallyworld | that was my main issue with the first changes | 05:48 |
| axw | wallyworld: https://github.com/juju/juju/pull/4162 -- refactored credentials types, added list-credentials | 05:56 |
| wallyworld | yay | 05:56 |
| wallyworld | axw: will look in about 15 | 05:56 |
| axw | wallyworld: next will be extending providers to return schemas, need to tidy that up. probably will be a big one | 05:56 |
| axw | wallyworld: thanks, no great rush | 05:56 |
| davecheney | wallyworld: CI bot is fucked up, it cannot tell time anymore | 05:56 |
| davecheney | http://paste.ubuntu.com/14588528/ | 05:56 |
| wallyworld | sigh | 05:57 |
| davecheney | tried twice in a row | 05:57 |
| wallyworld | we'll have to try again i guess and let curtis know | 05:58 |
| mup | Bug #1536477 opened: utils/debugstatus: test failure <juju-core:New> <https://launchpad.net/bugs/1536477> | 06:09 |
| axw | wallyworld: so we're definitely removing the old azure from 2.0? | 06:13 |
| wallyworld | axw: yep | 06:13 |
| axw | wallyworld: if so, I'm going to do that now, because it'll make my job easier in the cloud credentials branch | 06:13 |
| axw | k | 06:13 |
| wallyworld | axw: we're supporting 1.25 for 2 years | 06:14 |
| axw | wallyworld: *nods* | 06:14 |
| axw | wallyworld: hmm, CI probably isn't ready for it though | 06:15 |
| mup | Bug #1536477 changed: utils/debugstatus: test failure <juju-core:New> <https://launchpad.net/bugs/1536477> | 06:15 |
| axw | I'll just put it up for review anyway, then land when CI is ready | 06:15 |
| mup | Bug #1536477 opened: utils/debugstatus: test failure <juju-core:New> <https://launchpad.net/bugs/1536477> | 06:18 |
| wallyworld | axw: yes, i am having conversations about CI for the api rename branch. i've added that to the list of topics. | 06:28 |
| axw | wallyworld: ta | 06:28 |
| davecheney | wallyworld: https://github.com/juju/juju/pull/4163 | 06:35 |
| davecheney | fix to juju/juju | 06:35 |
| wallyworld | ok | 06:35 |
| anastasiamac | the whole of juju/juju? | 06:35 |
| wallyworld | if only | 06:36 |
| wallyworld | lgtm | 06:36 |
| mup | Bug #1536480 opened: Disallow deploying multiple units to the same container by default <juju-core:New> <https://launchpad.net/bugs/1536480> | 06:39 |
| wallyworld | axw: reviewed, have to head to soccer in about 45 minutes, will look again when i get back if not before | 07:07 |
| axw | wallyworld: ok ta | 07:07 |
| axw | wallyworld: addressed some but not all comments, PTAL when you can | 07:37 |
| wallyworld | sure | 07:37 |
| wallyworld | axw: responded | 07:43 |
| axw | wallyworld: PTAL | 07:53 |
| wallyworld | ok | 07:54 |
| wallyworld | axw: done, ty. now off to soccer | 08:01 |
| axw | wallyworld: later, enjoy | 08:01 |
| Muntaner | hello to everyone...I have a problem with a bootstrap, is this the right channel? | 09:14 |
| Muntaner | 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:28 |
| TheMue | Muntaner: maybe you better ask on #juju. here it's more development of juju | 09:39 |
| Muntaner | ok TheMue, sorry : ) | 09:48 |
| TheMue | Muntaner: yw, no need to excuse. is only a hint. | 09:49 |
| voidspace | jam: stdup? | 10:03 |
| voidspace | dooferlad: frobware: small PR http://reviews.vapour.ws/r/3590/ | 10:03 |
| === Odd_Blok1 is now known as Odd_Bloke | ||
| mup | Bug #1536587 opened: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap <bootstrap> <network> <juju-core:New> <https://launchpad.net/bugs/1536587> | 11:33 |
| mup | Bug #1536587 changed: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap <bootstrap> <network> <juju-core:New> <https://launchpad.net/bugs/1536587> | 11:39 |
| mup | Bug #1536587 opened: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap <bootstrap> <network> <juju-core:New> <https://launchpad.net/bugs/1536587> | 11:42 |
| mup | Bug #1536587 changed: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap <bootstrap> <network> <juju-core:New> <https://launchpad.net/bugs/1536587> | 11:45 |
| mup | Bug #1536587 opened: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap <bootstrap> <network> <juju-core:New> <https://launchpad.net/bugs/1536587> | 11:48 |
| rogpeppe | any fancy a review of a new (to juju/utils) URL utility function? https://github.com/juju/utils/pull/191 | 11:52 |
| mgz | I'll bite. | 11:54 |
| rogpeppe | mgz: ta! | 11:55 |
| rogpeppe | 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 |
| mgz | hm, there's nothing actually urly about this | 11:56 |
| rogpeppe | mgz: urls are an obtuse thing! | 11:56 |
| mgz | doesn't do anything with schemes | 11:56 |
| rogpeppe | mgz: URL paths | 11:57 |
| rogpeppe | mgz: still part of URLs | 11:57 |
| rogpeppe | mgz: the RFC is definitely pertinent here | 11:58 |
| mgz | rogpeppe: this is basically os.path.relpath though | 11:59 |
| rogpeppe | mgz: yeah, except for it's URL-specific | 11:59 |
| rogpeppe | mgz: os.path.relpath wouldn't work here | 11:59 |
| mgz | I'm not seeing any case where it actually differs | 12:00 |
| rogpeppe | mgz: os.path.relpath doesn't treat trailing slashes as significant | 12:00 |
| mgz | I mean, that's not a reason we don't need this, if go doesn't have it | 12:00 |
| mgz | aha, yeah, that is true | 12:00 |
| mgz | which if these tests cover that... | 12:01 |
| mgz | rogpeppe: does it ever make sense for base to not start with a / ? | 12:04 |
| rogpeppe | mgz: not in the use case that we've been using it for, but it's possible | 12:05 |
| mgz | also both have to be normalised already (as in, not contain .././) | 12:05 |
| rogpeppe | mgz: yeah, that's true. perhaps i should normalise them with path.Clean | 12:06 |
| mgz | asserting both are abs paths seems good for the moment | 12:06 |
| mgz | rogpeppe: lgtm | 12:09 |
| rogpeppe | mgz: thanks | 12:09 |
| rogpeppe | mgz: tbh i don't know of any http muxers that allow .. or . in the middle of paths. | 12:10 |
| rogpeppe | mgz: although... actually i think http.ServeMux returns a redirect if the path isn't clean, which kinda avoids the issue | 12:10 |
| mgz | I think just stating the obvious in the function doc comment should be fine | 12:13 |
| mgz | there are few cases in code where you'll actually deal with non-normalised paths and they tend to be obvious | 12:14 |
| rogpeppe | mgz: yeah | 12:15 |
| frobware | 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 |
| voidspace | frobware: looking | 12:24 |
| voidspace | frobware: your unique option filtering, is that tested? | 12:31 |
| frobware | voidspace, since I posted I'm going to revert that change. | 12:32 |
| voidspace | frobware: unique_options should really be a set not a list | 12:32 |
| voidspace | frobware: hah | 12:32 |
| frobware | voidspace, set doesn't guarantee original order. | 12:32 |
| voidspace | frobware: true enough | 12:32 |
| frobware | voidspace, I could switch to ordered set. | 12:32 |
| frobware | voidspace, but I know recall why I started making it unique and that should be a separate change. | 12:33 |
| voidspace | frobware: ok | 12:34 |
| frobware | 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 |
| voidspace | frobware: for small "sets" a list is fine | 12:34 |
| voidspace | for long lists testing membership is slow | 12:34 |
| frobware | voidspace, I want fewer changes to the original /e/n/i as possible. | 12:34 |
| frobware | voidspace, makes it clear what buthering "we" did | 12:34 |
| voidspace | frobware: good call | 12:34 |
| frobware | voidspace, understood the perf. call, but we're dealing with < 10 entries in general. | 12:35 |
| frobware | voidspace, of all the things... I don't think we have a performance problem. :) | 12:35 |
| voidspace | :-) | 12:37 |
| voidspace | frobware: is the new diff ready for review? | 12:38 |
| frobware | voidspace, yep. pushed. | 12:38 |
| voidspace | frobware: LGTM | 12:41 |
| frobware | voidspace, thx | 12:41 |
| perrito666 | axw: wait, are we droping $JUJU_HOME? | 12:58 |
| frobware | mgz, ping | 13:35 |
| perrito666 | wow testing is too different from the version we are using, anyone knows why? | 13:36 |
| mgz | frobware: hey | 13:36 |
| frobware | 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:37 |
| mgz | frobware: I can get it queued today | 13:38 |
| frobware | mgz, great. thanks. | 13:38 |
| mgz | we're still suffering from shortage of maas capacity | 13:39 |
| sinzui | 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:51 |
| mgz | sinzui: will have a look | 13:53 |
| beisner | sinzui, mgz, maas trusty daily image woes. #maas @ c | 14:16 |
| sinzui | :/ | 14:16 |
| sinzui | thank you beisner | 14:16 |
| beisner | sinzui, yw i think ;-) | 14:17 |
| perrito666 | jam: ? | 14:19 |
| jam | perrito666: ? | 14:19 |
| natefinch | it's a punctuation fight! Go!! | 14:19 |
| perrito666 | I have a doubt (2 actually) regarding juju2 supporting xdg | 14:20 |
| perrito666 | natefinch: please, I have stuff like ¿ | 14:20 |
| perrito666 | jam: are we dropping JUJU_HOME ? | 14:20 |
| jam | I would think that JUJU_HOME supersedes any other setting | 14:21 |
| sinzui | mgz: Can you review https://code.launchpad.net/~sinzui/juju-ci-tools/unit-test-install-deps/+merge/283450 | 14:21 |
| perrito666 | jam: I thought so too, but axw made a few comments in my PR which made me doubt | 14:21 |
| jam | link? | 14:21 |
| perrito666 | the second is regarding XDG_DATA_HOME are we honoring that? | 14:22 |
| perrito666 | jam: the second is regarding XDG_DATA_HOME are we honoring that | 14:22 |
| jam | 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 |
| jam | given .local/share | 14:23 |
| jam | which matches /usr/share, right? | 14:23 |
| perrito666 | jam: well it is a bit of a blurry concept I think, I have seen people not be consistent on that one | 14:24 |
| perrito666 | that is why I did a straight replace | 14:24 |
| jam | so, *today* I don't believe we consume anything from /usr/share | 14:24 |
| perrito666 | but if we are going to deem certain things as "data" there is more thought to be put into this | 14:24 |
| jam | the closest we have is /usr/lib/juju/ where we put things like mongo | 14:24 |
| jam | but I don't think we have any plans to read that out of a users home dir | 14:24 |
| jam | I'd think we'd just support XDG_CONFIG_HOME for this | 14:25 |
| perrito666 | works for me | 14:26 |
| perrito666 | jam: tx for your help | 14:30 |
| jam | perrito666: happy to | 14:30 |
| natefinch | anyone have ideas on how I can store (and more importantly) update a map[string]string in mongo? | 14:38 |
| perrito666 | natefinch: you just do it? | 14:38 |
| natefinch | perrito666: update is the tricky one.. is there an operation to just update a single entry in a map in the DB? | 14:39 |
| perrito666 | natefinch: you seem to be confusing mongo with a serious db :p | 14:39 |
| natefinch | perrito666: heh | 14:39 |
| natefinch | perrito666: I'm trying to avoid having to read the map out and then write it back | 14:39 |
| perrito666 | nope, you are doomed to it | 14:40 |
| perrito666 | and in the middle the incertitude of race conditions :p | 14:40 |
| natefinch | pleh | 14:40 |
| perrito666 | jokes apart, I dont think there is a db that allows you to do a partial update of a piece of data | 14:40 |
| perrito666 | your smalles unit is a doc's field and you want to make a change smaller than that | 14:41 |
| natefinch | perrito666: I just didn't know if there was some mongo hackery, since a map is just like an object, if I could do foo["bar"] = "baz" | 14:41 |
| natefinch | perrito666: looks like you can do it, so like {$set: {"foo.bar": "baz"} } | 14:45 |
| perrito666 | what? :\ | 14:46 |
| perrito666 | that surprises me | 14:46 |
| natefinch | the map is really an "embedded document" in the field | 14:47 |
| perrito666 | can you do that with other types? | 14:47 |
| perrito666 | natefinch: ah, I would not expect maps to be treated as documents | 14:47 |
| natefinch | perrito666: in mongo (and json) map == object/document | 14:48 |
| perrito666 | natefinch: I am curious on how we are serializing de-serializing that | 14:48 |
| natefinch | perrito666: that's what I'm trying to figure out... probably map[string]interface{} | 14:49 |
| perrito666 | that whole process deppends a lot on us being nice people :p | 14:50 |
| natefinch | ericsnow: it occurs to me, we have no unique id for a resource :/ | 14:58 |
| natefinch | ericsnow: the unique id is service/resourceName/resourceRevision ... and revision is either the revision or the timestamp, depending on the type of resource :/ | 14:59 |
| perrito666 | remove all the things that say "remove in 2.0" is a feeling equivalent to peeling the film of a new screen | 15:07 |
| frobware | cherylj, ping | 15:29 |
| cherylj | hey frobware, what's up | 15:30 |
| frobware | cherylj, I think I deleted the wrong meeting - or it's disappeared from my cal. Are we meeting now? | 15:30 |
| cherylj | frobware: nope, in 30 minutes | 15:30 |
| cherylj | frobware: but given your email, we can postpone / cancel if you're swamped | 15:31 |
| frobware | cherylj, ah. got it. sorry for the noise. coffee is wearing off. | 15:31 |
| katco | perrito666: must be enjoyable | 15:31 |
| katco | perrito666: glad you have the honor | 15:31 |
| frobware | cherylj, can we? I have stuff for 1.25 and maas-spaces pending, plus other stuff... | 15:32 |
| cherylj | frobware: yeah, no prob. I can cancel and send some comments / ideas in an email | 15:32 |
| frobware | cherylj, also need to reflect on the nature and timing as I mentioned via email | 15:32 |
| frobware | cherylj, any thoughts on when a 1.25.4 would be? I was starting to look at #1532167 again. | 15:41 |
| mup | Bug #1532167: maas bridge script handles VLAN NICs incorrectly <addressability> <maas-provider> <network> <juju-core:Triaged> <juju-core 1.25:Triaged by frobware> <https://launchpad.net/bugs/1532167> | 15:41 |
| cherylj | frobware: ha, that bug just came up in the cross team call. | 15:41 |
| frobware | cherylj, not terribly surprised... | 15:42 |
| cherylj | frobware: I'm going to say 2 - 4 weeks, to be realistic | 15:42 |
| frobware | cherylj, ok. I'm asking because we have way better support for bond, vlans, vlans on bond in maas-spaces (in the bridge script). so trying to decide whether patching what's in 1.25 or taking wholesale changes from maas-spaces might be better. | 15:43 |
| frobware | cherylj, can they work without a fix for 2-4 weeks? | 15:44 |
| frobware | cherylj, tentatively sometime next week | 15:52 |
| beisner | o/ frobware, thanks again for all your work on the ifaces fun. much appreciated. | 15:56 |
| frobware | beisner, np. it's great we have a better understanding of how it all plumbs together now. | 15:56 |
| === abentley_ is now known as abentley | ||
| lazypower | cherylj how long until 2.0-alpha1 lands in the -dev ppa? | 16:20 |
| lazypower | cherylj i ask as i just encountered a bug that says it was 1.25 fix-released, but it doesnt appear to be in practice: http://pad.lv/1512371 | 16:20 |
| cherylj | lazypower: should be very soon. sinzui ^^ ? | 16:20 |
| lazypower | so i just had the develooer upgrade to 1.26-alpha3, this will be jarring if they get a shiny 2.0-alpha1 later today :P | 16:21 |
| cherylj | lazypower: which 1.25 were you using? | 16:22 |
| sinzui | lazypower: that bug is fixed in the proposed juju. We are waiting for confirmation juju just works before completing the release. | 16:22 |
| cherylj | lazypower: that bug isn't fixed in any stable 1.25. The versions which have that fix are still in proposed | 16:22 |
| lazypower | ah ok | 16:22 |
| lazypower | well, here's to have immediate external testing to 2.0 when it lands | 16:23 |
| * lazypower cheers | 16:23 | |
| cherylj | :) | 16:23 |
| lazypower | i have a meeting with them in 30, i'll put a little bug in their ear they're going to be on 2.0 in the next day or so. | 16:23 |
| lazypower | should we encounter critical punches, i can have them revert to the proposed ppa and that should get themb ack in stable w/ a maas 1.9 fix? | 16:24 |
| cherylj | lazypower: yeah. 1.25.3 was just put into proposed, and that has a lot of maas networking fixes | 16:24 |
| lazypower | ok, bueno. Thanks for the background info | 16:24 |
| cherylj | lazypower: let me know if they run into issues with 2.0. I'd love to hear feedback | 16:25 |
| lazypower | will do | 16:28 |
| natefinch | ericsnow: is it too evil if I just reuse SetResource and pass it an ID that already has the unit tag embedded in it? | 16:48 |
| ericsnow | natefinch: borderline evil :) | 16:48 |
| natefinch | ericsnow: ahh, better: I can add a possibly-empty unit field to set-resource | 16:49 |
| natefinch | ericsnow: that way I don't have to encode the ID outside the DB code | 16:49 |
| ericsnow | natefinch: there's enough distinction that it may be better to at least have 2 separate methods that call the same underlying (unexported) method | 16:49 |
| natefinch | ericsnow: yeah, ok... I was trying to be lazy... too lazy in this case, you're right :) | 16:50 |
| ericsnow | natefinch: :) | 16:50 |
| natefinch | man I hate that Tags have a String() string and an Id() string .... which one am I supposed to use when? Why are there two string representations? | 17:13 |
| natefinch | ericsnow: why do we pass the id and the resource itself separately to persist.SetResource? Wouldn't it be better to just pass the resource and let the function take the id from the name on the resource? | 17:17 |
| ericsnow | natefinch: not sure | 17:19 |
| natefinch | ericsnow: removing it would prevent people from doing evil things like I was planning to do ;) | 17:19 |
| ericsnow | natefinch: re: tags, use Tag.Id() (and I'd recommend passing that ID around rather than the tag) | 17:19 |
| natefinch | gah, I hate passing around raw strings. Then you never know what they're really supposed to be, and so you have to traverse back up the tree to figure out what string is actually being set... | 17:20 |
| voidspace | frobware: that's sneaking assigning that card to me... | 17:20 |
| natefinch | if it's always the results of a UnitTag.Id().. why not just pass the UnitTag? | 17:21 |
| natefinch | otherwise, you're just encoding way high up in the stack what the DB id format is | 17:21 |
| frobware | voidspace, sorry, was on a mission to ensure the iteration was fully loaded... | 17:21 |
| frobware | voidspace, want to chat about it? | 17:21 |
| frobware | voidspace, it was really because post your monster merge I wanted to keep an eye out for any fallout | 17:22 |
| ericsnow | natefinch: tags are a wire format type (my understanding), not suitable for use outside the API | 17:22 |
| ericsnow | natefinch: regarding that "id" parameter, I expect it is an artifact of copying (or at least following the example of) the equivalent code from payloads | 17:24 |
| natefinch | ericsnow: I'll think about submitting a separate patch to strip it out, but not that important right now | 17:25 |
| ericsnow | natefinch: in that case the payload ID wasn't derived from the payload name (or any other info) | 17:25 |
| mup | Bug #1536728 opened: Juju's MAAS bridging script needs to de-duplicate dns-* iface options <maas-provider> <network> <juju-core:New for frobware> <https://launchpad.net/bugs/1536728> | 17:25 |
| ericsnow | natefinch: see payload/state/unit.go (Track) | 17:26 |
| ericsnow | natefinch: yeah, that should be fine since we are just using the resource name for the ID | 17:26 |
| natefinch | ericsnow: I generally frown on anyone way outside the DB layer deciding what the ID for the item in the DB should be. | 17:27 |
| voidspace | frobware: fallout, as in it might start passing? :-) | 17:27 |
| frobware | voidspace, ping me when it does. :-D | 17:27 |
| ericsnow | natefinch: the ID (in the case of payloads) is determined by state | 17:27 |
| voidspace | frobware: I need to get the "api shut off" done on maas-spaces, then I can take a look at it | 17:27 |
| ericsnow | natefinch: that is not the same thing as the doc ID (which is contained strictly within the persistence layer) | 17:28 |
| frobware | voidspace, yep fine. again, I just didn't want the CI build to pass through the cracks. | 17:28 |
| voidspace | frobware: sure :-) | 17:28 |
| voidspace | frobware: just finished checking the differences between master and maas-spaces for potential missing stuff | 17:29 |
| frobware | voidspace, golden? ;) | 17:29 |
| voidspace | frobware: a *lot* of files renamed on master, and a lot of new files on maas-spaces | 17:29 |
| voidspace | frobware: nothing problematic though (I'm pretty sure) | 17:29 |
| frobware | voidspace, great. thanks for the due diligence. | 17:30 |
| voidspace | frobware: looking at default gateway on the new NetworkInterfaces implementation too | 17:30 |
| voidspace | as that doesn't exist on master and the fix there on applies to the legacy version | 17:30 |
| voidspace | frobware: ah, however the new one does set a GatewayAddress | 17:31 |
| mup | Bug #1536728 changed: Juju's MAAS bridging script needs to de-duplicate dns-* iface options <maas-provider> <network> <juju-core:New for frobware> <https://launchpad.net/bugs/1536728> | 17:31 |
| voidspace | frobware: yep the new one takes it from the interface subnet | 17:32 |
| voidspace | so that's cool | 17:33 |
| voidspace | done and dusted | 17:33 |
| mup | Bug #1536728 opened: Juju's MAAS bridging script needs to de-duplicate dns-* iface options <maas-provider> <network> <juju-core:New for frobware> <https://launchpad.net/bugs/1536728> | 17:34 |
| frobware | voidspace, great | 17:35 |
| voidspace | frobware: as an experiment I just did another merge of master | 17:36 |
| voidspace | frobware: there are conflicts in bridgescript_test.go | 17:36 |
| voidspace | frobware: want me to resolve and push so we can track master | 17:36 |
| voidspace | ? | 17:36 |
| frobware | voidspace, so how did that happen? In your branch? or mine which merged sometime earlier? | 17:37 |
| voidspace | frobware: I did a fresh checkout of maas-spaces and merged upstream/master into it | 17:38 |
| frobware | voidspace, does it look the conflicts came from this https://bugs.launchpad.net/juju-core/+bug/1534795 | 17:38 |
| mup | Bug #1534795: unit loses network connectivity during bootstrap: juju 1.25.2 + maas 1.9 <maas-provider> <uosci> <juju-core:Fix Released by frobware> <juju-core 1.25:Fix Released by frobware> <https://launchpad.net/bugs/1534795> | 17:38 |
| voidspace | frobware: is there a linked github branch? | 17:39 |
| voidspace | frobware: HEAD has a new "pre-up" in one of the tests | 17:40 |
| frobware | voidspace, https://bugs.launchpad.net/juju-core/+bug/1534795/comments/12 | 17:40 |
| mup | Bug #1534795: unit loses network connectivity during bootstrap: juju 1.25.2 + maas 1.9 <maas-provider> <uosci> <juju-core:Fix Released by frobware> <juju-core 1.25:Fix Released by frobware> <https://launchpad.net/bugs/1534795> | 17:40 |
| voidspace | frobware: cool, thanks - looking | 17:40 |
| voidspace | frobware: yes | 17:41 |
| voidspace | frobware: do you want to resolve it? Would only take a minute and there's already quite a bunch of changes on master we should pull in | 17:41 |
| frobware | voidspace, swamped. and need to leave in 19 mins... | 17:42 |
| voidspace | frobware: ok | 17:42 |
| frobware | voidspace, can do this AM tomorrow if it helps. | 17:42 |
| voidspace | frobware: on maas-spaces runScript takes a new isBond parameter - and I'm not sure what that should be on the new test from master | 17:43 |
| voidspace | probably false though | 17:43 |
| voidspace | frobware: I'll try and resolve, if I get bogged down I'll abandon | 17:44 |
| frobware | voidspace, at first blush I would say that's the wrong way round. | 17:44 |
| frobware | voidspace, the isBond should only be relevant on master and 1.25. | 17:44 |
| voidspace | you might be right | 17:44 |
| voidspace | frobware: multiple conflicts in the test scripts themselves, and my head is too tired to work them out | 17:46 |
| voidspace | it can wait until tomorrow morning I think | 17:46 |
| voidspace | natefinch: ping | 17:46 |
| natefinch | voidspace: pong | 17:46 |
| voidspace | natefinch: asking in case you know... | 17:47 |
| voidspace | natefinch: the API is switched off during bootstrap until a certain point | 17:47 |
| voidspace | natefinch: I need to ensure that the API remains off until a worker (that fires on bootstrap) has ccompleted | 17:47 |
| voidspace | natefinch: do you know where I would find the API switching on/off code? | 17:48 |
| voidspace | or the machinery/mechanism we use to do that | 17:48 |
| voidspace | if not I will go spelunking in cmd/jujud | 17:48 |
| natefinch | voidspace: I don't know specifically, but I would start looking at cmd/jujud/agent/machine.go, since that's where all the workers are, and some of them are specified as API workers, which require the API to be on... hopefully you could work backward to figure out where the API gets turned on | 17:50 |
| voidspace | natefinch: that's a good clue, thanks | 17:50 |
| natefinch | voidspace: there's an APIWorker method that is probably what you want to look at... i.e. what starts that worker | 17:51 |
| voidspace | natefinch: cool | 17:51 |
| natefinch | voidspace: so maybe I do know where to look, after all ;) | 17:52 |
| voidspace | natefinch: you usually do :-) | 17:52 |
| voidspace | natefinch: appreciated | 17:52 |
| arosales | hello, I recall a developer environments.yam key for GCE to use a specific image, but I don't remember the exact key | 18:29 |
| arosales | do that sound familiar to anyone? | 18:29 |
| cherylj | arosales: I thought there used to be something like that for ec2, but hasn't been there for a while | 18:34 |
| arosales | hm, I thought I saw one for azure and ice . . . | 18:37 |
| arosales | s/ice/azure | 18:38 |
| natefinch | pretty lonely in this juju core team meeting all by myself | 19:03 |
| perrito666 | natefinch: I believe that last night meeting was a replacement for this one | 19:05 |
| arosales | is "force-image-name" still recognized by azure? | 19:05 |
| natefinch | perrito666: ahh | 19:05 |
| natefinch | arosales: for the legacy azure provider, yes | 19:07 |
| natefinch | arosales: I don't know how that might relate to the new azure provider | 19:07 |
| arosales | natefinch: thanks, do you know if a similar option is available for GCE? | 19:08 |
| arosales | or AWS? | 19:08 |
| natefinch | arosales: definitely not for GCE | 19:12 |
| natefinch | arosales: not for aws either | 19:13 |
| arosales | natefinch: ok, thanks | 19:13 |
| natefinch | arosales: it's something we've wanted to implement for forever, it just never was a high enough priority (and none of the devs were annoyed enough to just do it themselves) | 19:15 |
| arosales | natefinch: understood, thanks for the info | 19:15 |
| natefinch | ericsnow: you know something should be a function not a method when..... id := Persistence{}.resourceID("spam", serviceID, "") | 19:34 |
| ericsnow | natefinch: likely another artifact from payloads | 19:35 |
| katco | natefinch: meeting running long, have to cancel | 19:50 |
| natefinch | katco: ok | 19:50 |
| natefinch | ericsnow: how's the get resource stuff going? | 19:56 |
| ericsnow | natefinch: slow (still not feeling great) | 19:57 |
| natefinch | ericsnow: understandable | 19:58 |
| natefinch | ericsnow: anything I can do to help? My code is like 10% dependent on your branch. | 20:02 |
| ericsnow | natefinch: not a ton (mostly a lot of mechanical cleanup) | 20:03 |
| natefinch | ericsnow: fair enough | 20:04 |
| katco | ericsnow: going to cancel our 1:1 as well; we're both not feeling great | 20:51 |
| ericsnow | katco: k | 20:51 |
| katco | ericsnow: natefinch: sorry bout that | 20:51 |
| perrito666 | katco: ericsnow you can get together and drink chicken soup during the standup | 20:52 |
| perrito666 | *1:1 | 20:52 |
| katco | perrito666: i need to find a vegetarian replacement for chicken soup | 20:52 |
| perrito666 | katco: I am pretty sure that those powder based chicken soups are far from any chicken :p | 20:53 |
| katco | lol | 20:53 |
| perrito666 | sometime ago I bought soy hot dog sausage, surprisingly good | 20:54 |
| katco | perrito666: i have discovered that the key to being vegetarian is not trying to find meat replacements, but to just cook delicious meals that just don't call for meat | 20:55 |
| perrito666 | which makes you think how much of the flavour on the original ones is influenced by the actual ingredients | 20:55 |
| perrito666 | sure thing, I cook a lot without meat in summer and that is good | 20:56 |
| natefinch | yeah, you can get a long way with just salt, oil, onions, garlic, and peppers of various sorts. | 20:56 |
| natefinch | and spices of course | 20:56 |
| menn0-afk | cherylj: I just check a recent failure of the MASS OS deployer CI job for master and I also see the the hook execution lock being incorrectly broken there | 21:11 |
| menn0-afk | cherylj: the following run (with the fix I think) passed | 21:11 |
| menn0-afk | davecheney: ^ | 21:11 |
| === menn0-afk is now known as menn0 | ||
| === urulama is now known as urulama__ | ||
| perrito666 | menn0: morning, could you re-review the xdg branch? | 21:13 |
| menn0 | perrito666: I will. I may not be able to do it for a couple of hours though. is that ok? | 21:13 |
| menn0 | perrito666: FWIW I had a quick look yesterday and it looked good | 21:13 |
| menn0 | perrito666: I'll look more closely today. | 21:14 |
| perrito666 | menn0: no hurry at all | 21:14 |
| perrito666 | menn0: I am eod | 21:14 |
| menn0 | perrito666: ok cool. I'll review it before your next working day. | 21:14 |
| cherylj | menn0: This test run of master doesn't have davecheney's fixes in it: http://reports.vapour.ws/releases/3529 | 21:14 |
| perrito666 | menn0: tx | 21:15 |
| cherylj | menn0: is that the one you were looking at? | 21:15 |
| menn0 | cherylj: yep that's one | 21:15 |
| menn0 | cherylj: it got lucky then :) | 21:15 |
| cherylj | menn0: yeah :) Are you rebasing machine-dep-engine? | 21:15 |
| menn0 | yep... about to hit merge on it | 21:16 |
| * thumper puts his head down to work | 21:18 | |
| menn0 | cherylj: http://juju-ci.vapour.ws:8080/job/github-merge-juju/6057/ | 21:19 |
| === menn0 is now known as menno-afk | ||
| natefinch | ericsnow: ahh, hmm... seems like stub implementations should not be calling errors.Trace on the errors they return.. it obscures whether or not we're returning the correct error | 21:30 |
| ericsnow | natefinch: use errors.Cause() | 21:30 |
| natefinch | ericsnow: but then I can't tell if my code is incorrectly wrapping the error, or if it's just the stub doing that | 21:31 |
| cherylj | hey perrito666, I opened bug 1536792 to reference in the 2.0-alpha1 release notes as a "known issue". I know you committed fixes after the revision we're going to release. Was there other work needed to address that issue in the various providers? | 21:31 |
| mup | Bug #1536792: Some providers release wrong resources when destroying hosted models <juju-core:Fix Committed> <https://launchpad.net/bugs/1536792> | 21:31 |
| perrito666 | cherylj: I actually am tasked with opening bugs for the changes I committed so we track them | 21:32 |
| natefinch | ericsnow: for example, my function should just pass through the error... but I can't test that it does that, because the stub is wrapping the error I give it. | 21:32 |
| cherylj | perrito666: we can just use that one bug and describe which providers release what resources | 21:32 |
| cherylj | perrito666: I opened it now for you since we're very very close to actually releasing alpha1 :) | 21:32 |
| natefinch | ericsnow: if I call errors.Cause, I can't tell if I'm just unwrapping what the stub wrapped, or if I'm also unwrapping what my code (incorrectly) wrapped | 21:33 |
| cherylj | perrito666: and I want to make sure it's included in the release notes. | 21:33 |
| ericsnow | natefinch: then perhaps use a stub that doesn't trace errors? | 21:33 |
| perrito666 | cherylj: great, is a comment the best way to note which are the providers ? | 21:33 |
| perrito666 | we should have provider tags | 21:34 |
| cherylj | perrito666: you can do that, or modify the original description. | 21:34 |
| natefinch | ericsnow: just seems like a general good practice - don't wrap errors in stubs. but yes, in this instance, I can make a different stub that doesn't wrap | 21:34 |
| perrito666 | oh, look at that, I have prmissions | 21:34 |
| perrito666 | there you go | 21:36 |
| perrito666 | EOD, cheers all | 21:36 |
| cherylj | thanks, perrito666! | 21:39 |
| natefinch | ericsnow: https://i.imgflip.com/xr6ig.jpg | 21:39 |
| cherylj | natefinch: lol! | 21:40 |
| natefinch | :D | 21:40 |
| natefinch | cherylj: perrito666 suggested I turn it into a meme to soften the blow :) | 21:42 |
| cherylj | I like it | 21:42 |
| natefinch | from now on I'm giving all my bad news via memes | 21:43 |
| cherylj | natefinch is GGG: https://imgflip.com/i/xr9f3 | 21:44 |
| mup | Bug #1536792 opened: Some providers release wrong resources when destroying hosted models <juju-core:Fix Committed> <https://launchpad.net/bugs/1536792> | 21:44 |
| natefinch | cherylj: http://goo.gl/MMZ2eq | 21:45 |
| cherylj | ha | 21:45 |
| cherylj | so rcj doesn't follow memes much, so I often make a reference to one and he stares at me blankly. | 21:46 |
| cherylj | or says something like "is that a meme" thing? | 21:46 |
| cherylj | Sometimes it's like I'm married to a member of AARP | 21:46 |
| natefinch | rofl | 21:46 |
| mup | Bug #1536792 changed: Some providers release wrong resources when destroying hosted models <juju-core:Fix Committed> <https://launchpad.net/bugs/1536792> | 21:47 |
| natefinch | my wife said "on fleek" the other day, and I had no idea what she was talking about. | 21:48 |
| cherylj | oh that's new to me | 21:48 |
| cherylj | I'm so out of touch! | 21:48 |
| cherylj | imgur you have failed me! | 21:49 |
| natefinch | my wife loves Biden memes, so it came up from this: http://napturalnicole.com/wp-content/uploads/2015/01/IMG_6731.jpg | 21:49 |
| cherylj | haha! | 21:50 |
| mup | Bug #1536792 opened: Some providers release wrong resources when destroying hosted models <juju-core:Fix Committed> <https://launchpad.net/bugs/1536792> | 21:50 |
| natefinch | evidently it means "on point" as in "really well done" | 21:50 |
| cherylj | can I get a review? http://reviews.vapour.ws/r/3599/ | 21:51 |
| cherylj | natefinch: I googled it | 21:51 |
| natefinch | cherylj: me too :) | 21:51 |
| natefinch | cherylj: I'm wondering if an equally valid, perhaps more correct fix for the failing test is to simply delete that line | 21:57 |
| natefinch | cherylj: or at least, don't check the content type | 21:57 |
| mwhudson | is anyone working on the fact that github.com/juju/juju/cmd/jujud/agent fails intermittently with go 1.5? | 22:00 |
| === natefinch is now known as natefinch-afk | ||
| cherylj | natefinch-afk: I'm not convinced that removing the check is correct. I think we *do* want to make sure that the correct content type is generated, but should accept that the correct type can be either javascript or x-javascript | 22:02 |
| bdx | core, dev: Are there plans for storage using openstack provider? | 22:04 |
| cherylj | natefinch-afk: the content type is generated by the code being exercised, so I think it's a valid thing to check. It can just vary based on centos vs. ubuntu | 22:05 |
| cherylj | bdx, we do support storage for openstack: https://jujucharms.com/docs/devel/storage | 22:08 |
| cherylj | bdx: is that what you're looking for? | 22:09 |
| bdx | cherylj: yea | 22:09 |
| bdx | cherylj: I'm not sure you sent the correct link ... | 22:10 |
| cherylj | bdx: maybe I misunderstood what you're looking for? | 22:10 |
| bdx | cherylj: can you point out where the openstack provider portion is in that link .... oooh ... I found it .. "The OpenStack/Cinder provider does not currently have any configuration." | 22:12 |
| cherylj | bdx: yeah, there's no openstack specific storage configuration yet | 22:13 |
| bdx | cherylj: ok, should I feature request it? do you know if its on the roadmap? | 22:14 |
| cherylj | bdx: do you know specifically what you'd like to be able to specify about storage on openstack? | 22:15 |
| bdx | cherylj: availability_zone, type, size | 22:19 |
| cherylj | bdx: yeah, you can open a bug to request those config options and I'll add it to our list of requests we track | 22:20 |
| bdx | cherylj: thats awesome! thanks! | 22:20 |
| bdx | arosales:^^ | 22:20 |
| bdx | cherylj: https://bugs.launchpad.net/juju-core/+bug/1536819 | 22:47 |
| mup | Bug #1536819: Feature Request: Storage support for openstack provider <juju-core:New> <https://launchpad.net/bugs/1536819> | 22:47 |
| cherylj | thanks, bdx. I'll add it to our listing here: https://github.com/juju/juju/wiki/Feature-Requests | 22:49 |
| mup | Bug #1536819 opened: Feature Request: Storage support for openstack provider <juju-core:New> <https://launchpad.net/bugs/1536819> | 22:50 |
| arosales | got another xenial question :-) | 22:52 |
| arosales | I feel like it should be possible to bootstrap a xenial model and services if I set default-series to xenial, image-stream to daily and agent-stream to devel | 22:53 |
| arosales | but I get unable to find matching tools :-/ | 22:54 |
| arosales | http://paste.ubuntu.com/14593295/ | 22:54 |
| arosales | against aws | 22:54 |
| arosales | is it because my desktop has to be Xenial as well? | 22:54 |
| arosales | bdx: ya the juju-core folks rocks. thanks cherylj | 22:55 |
| arosales | bdx: seem very reasonable as we tackle storage in openstack which gets a lot of usage :-) | 22:56 |
| davecheney | menno-afk: sweet | 22:59 |
| arosales | --upload-tools also ends the same way: http://paste.ubuntu.com/14593344/ | 23:01 |
| arosales | its seems like it should work, but wanted to get folks thoughts here on it. | 23:02 |
| wallyworld | axw: perrito666: standup? | 23:20 |
| === menno-afk is now known as menn0 | ||
| mup | Bug #1536838 opened: state/lease: package in wrong location <juju-core:New> <https://launchpad.net/bugs/1536838> | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
