| mup | Bug #1490789 opened: [juju authorised-keys add] cannot specify a key file <juju-core:New> <https://launchpad.net/bugs/1490789> | 01:47 |
|---|---|---|
| wallyworld | thumper: what's you fav flag design? | 02:20 |
| * thumper looks for a copy | 02:21 | |
| anastasiamac | wallyworld: with stripes?... | 02:21 |
| wallyworld | they've narrowed down to 4 | 02:21 |
| thumper | http://www.stuff.co.nz/national/71624100/live-final-four-nz-flag-designs-unveiled | 02:21 |
| thumper | top left | 02:21 |
| thumper | black and blue | 02:21 |
| thumper | second favourit is bottom right | 02:21 |
| wallyworld | mee too | 02:21 |
| thumper | red and blue | 02:22 |
| wallyworld | i would have preferred soutern cross on all back and white | 02:22 |
| mwhudson | obviously they should have chosen http://fm.cnbc.com/applications/cnbc.com/resources/img/editorial/2015/05/15/102682735-3127-flag.530x298.png?v=1431699254 | 02:22 |
| wallyworld | i wish we would change ours :-( | 02:22 |
| thumper | someone did a variant of the top left with the black and blue inverted | 02:22 |
| thumper | mwhudson: :) | 02:23 |
| mwhudson | or nyan kiwi | 02:23 |
| mwhudson | https://www.govt.nz/browse/engaging-with-government/the-nz-flag-your-chance-to-decide/gallery/design/2811 | 02:23 |
| anastasiamac | i like monochromatic fern | 02:23 |
| thumper | mwhudson: I actually like the new design (top left one) | 02:23 |
| mwhudson | thumper: it's ok i guess | 02:23 |
| mwhudson | not a subject i am really capable of getting excited over :-) | 02:23 |
| mwhudson | i don't like the way the fern is drawn i think, although i'm not sure what is wrong | 02:24 |
| mwhudson | too chunky maybe | 02:24 |
| thumper | personally I'm in favour of changing the flag, but I believe that the government is trying to hide a lot of shit by saying, "hey look over there, new flag" | 02:24 |
| mwhudson | yeah definitly | 02:24 |
| mwhudson | wallyworld: your country's politics is pretty surreal at the moment | 02:25 |
| wallyworld | indeed :-( | 02:25 |
| wallyworld | nz has their shit together on so many things | 02:25 |
| wallyworld | we are a basket case | 02:25 |
| thumper | pfft | 02:26 |
| thumper | I don't follow ozzie politics much | 02:27 |
| thumper | but I'm not sure I'd say NZ has their shit together | 02:27 |
| thumper | although to be honest | 02:27 |
| thumper | pretty much any country I look at more than superficailly seems screwed in some way | 02:27 |
| thumper | why does humanity suck so much? | 02:27 |
| anastasiamac | thumper: careful - u r aproaching wisdom | 02:27 |
| anastasiamac | *pp | 02:28 |
| thumper | I'll go back to being superficial | 02:28 |
| davechen1y | thumper: http://reviews.vapour.ws/r/2474/ | 05:08 |
| davechen1y | got all the kinks out of it now | 05:08 |
| thumper | davechen1y: lgtm, if you mark the last issue resolved, then you have the shipit from axw | 05:18 |
| * thumper heads off to code craft | 05:18 | |
| davechen1y | ta | 05:18 |
| davechen1y | fixed | 05:18 |
| wallyworld | axw: school pickupt ime, if you get a chance maybe you could look at https://github.com/juju/juju/pull/3168 for me? otherwise i'll ping one of the emerald guys later | 06:02 |
| axw | wallyworld: sure | 06:02 |
| wallyworld | ty, i'll look at yours when i get back | 06:02 |
| wallyworld | jam: hiya, do you think the resources spec is ready to distribute more widely? maybe take another look and get back to me? | 07:47 |
| axw | wallyworld: if you have time, would you mind reviewing http://reviews.vapour.ws/r/2530/diff/# also? it's a prereq of the other one | 08:13 |
| wallyworld | sure | 08:13 |
| wallyworld | axw: have to go to dinner, will finish review in a bit | 08:17 |
| axw | wallyworld: no worries, it can wait till tomorrow | 08:17 |
| axw | or OCR, whichever comes first | 08:17 |
| mup | Bug #1490075 changed: juju use lxcbr0 rather than juju-r0 <juju-core:Invalid> <https://launchpad.net/bugs/1490075> | 08:27 |
| mup | Bug #1490865 opened: destroy-environment on an unbootstrapped MAAS environment can release all my nodes <juju-core:New> <https://launchpad.net/bugs/1490865> | 08:27 |
| wallyworld | axw: reviewed, one main concern to consider | 08:46 |
| axw | wallyworld: thanks | 08:47 |
| wallyworld | np | 08:47 |
| === akhavr1 is now known as akhavr | ||
| axw | wallyworld: if you're still there, please see my replies before I merge | 09:00 |
| wallyworld | sure | 09:01 |
| wallyworld | axw: with the order of operations - we ran into the issue with service status. the status was retrieved first and then the service wasn't there | 09:02 |
| wallyworld | i'm included to prefer the parent doc exist first | 09:02 |
| wallyworld | the megawatcher was the component affected | 09:03 |
| wallyworld | it was watching status and then got into trouble when it tried to get the service | 09:03 |
| axw | wallyworld: then we need to do it for all other entities too. machine, unit, etc. I'm pretty sure we don't want status docs floating around if the entity we create them doesn't get created though. | 09:03 |
| wallyworld | my suggestion is to create the entity doc first | 09:04 |
| wallyworld | hence status won't be floating around | 09:04 |
| axw | wallyworld: in which case you can find the entity and not the status... | 09:04 |
| wallyworld | correct | 09:04 |
| wallyworld | but that is think is the lesser of 2 evils | 09:04 |
| wallyworld | as we found with megawatcher | 09:04 |
| wallyworld | consider the case of watching the status - we get notified there's a status update and then find no parent doc | 09:05 |
| wallyworld | that i think is a more common case | 09:05 |
| wallyworld | or at least it has bitten us that way | 09:05 |
| axw | wallyworld: I think we should just make the megawatcher resilient to that, rather than making *everything* else prone to errors due to missing prereq docs | 09:06 |
| wallyworld | i'm surpirsed unit machine etc are the "wrong" way | 09:06 |
| wallyworld | i would argue the parent entity is the prereq :-) | 09:06 |
| wallyworld | you can't have an arm without a body | 09:06 |
| wallyworld | in any case, the megawatchr was made resiliant before the root cause was found | 09:07 |
| wallyworld | i guess if unit, machine etc are one way, then we could be consistent | 09:07 |
| wallyworld | but i disagree with the order nonetheless | 09:08 |
| axw | wallyworld: ok, so, say I did make this change, and a failure occurs part way through creating a filesystem and we get a filesystem but no status. we restart, find we have the filesystem, then proceed to try to provision... update status and the agent will explode because the status doc is missing | 09:08 |
| axw | wallyworld: this is one example, there will be many more. how would we deal with that? | 09:09 |
| wallyworld | yeah, there's failure modes in either case :-( | 09:09 |
| wallyworld | leave it as i guess | 09:09 |
| axw | my point is that status->parent is pretty well secluded to the megawatcher | 09:09 |
| fwereade | wallyworld, the motivation for the current approach is that "if you have an X, you should be able to find X's data, and you should be able to treat lack of X data as a guarantee of lack of X" | 09:09 |
| wallyworld | at least it wil be consistent | 09:09 |
| wallyworld | fwereade: but if you have X's data, you should be able to find X | 09:10 |
| wallyworld | as we found out with megawatchr and service status | 09:10 |
| wallyworld | if I have an arm, i should be able to find the body it's attached to | 09:11 |
| fwereade | wallyworld, right, and if we had atomic/isolated txns we could do that, but we don't | 09:11 |
| wallyworld | indeed :-( | 09:11 |
| fwereade | wallyworld, neither a body without an arm nor an arm without a body make much sense | 09:11 |
| wallyworld | fwereade: so service status i think was or is inverted in order then | 09:11 |
| wallyworld | to remove the megawatchr race | 09:12 |
| fwereade | wallyworld, it *should* come into existence before the service, and be removed afterwards | 09:12 |
| wallyworld | a body without an arm makes more sense | 09:12 |
| wallyworld | a tyre without a car makes less sense than a car without a tyre | 09:13 |
| wallyworld | but if we are to be consistent, then i'll defer to the current practice | 09:13 |
| wallyworld | i just with mgo were Atomic :-( | 09:14 |
| wallyworld | wish | 09:14 |
| fwereade | wallyworld, right, but I will go insane if all the state code I write means I have to figure out what a missing satellite doc means | 09:14 |
| wallyworld | and i could argue the other way too :-) | 09:14 |
| wallyworld | but, i'll defer to the current implementation for most things | 09:14 |
| wallyworld | at least we have a shared understanding that there's a potential issue | 09:15 |
| fwereade | wallyworld, yeah, in a greenfield scenario we could have an interesting discussion about which way hurts less | 09:15 |
| wallyworld | axw: so ship it as it | 09:15 |
| wallyworld | is | 09:15 |
| fwereade | wallyworld, I *would* point out that the megawatcher is not an especially sane piece of code, though, and "it's hard to make it work with the megawatcher" is not a very strong argument against a given practice | 09:17 |
| fwereade | wallyworld, http://thecodelesscode.com/case/97 :) | 09:17 |
| wallyworld | fwereade: with megawatcher, i was refering more to the order of acess used | 09:18 |
| wallyworld | which i think is a alid use case | 09:18 |
| fwereade | wallyworld, an approach that wasn't sickeningly codependent with the storage details would work fine | 09:18 |
| fwereade | wallyworld, the existence of an X implies the existence of all X's satellite data | 09:18 |
| fwereade | wallyworld, so you *watch for Xs* and then pick up the rest of their data when you need it | 09:19 |
| wallyworld | fwereade: we are mmoving to mongo 3.0 (or planning to) and that has proper acid under the covers, so we will get there soon enough :-) | 09:19 |
| fwereade | wallyworld, right, all we have to do is rewrite the storage backend again, it'll be easy | 09:19 |
| wallyworld | yeah :-D | 09:20 |
| axw | hoho | 09:20 |
| wallyworld | i should have said "soon" | 09:20 |
| wallyworld | a guy can dream | 09:20 |
| wallyworld | one day Hallie Berry will return my calls | 09:20 |
| fwereade | wallyworld, I know, and you're not as wrong as I'm making out :) | 09:20 |
| fwereade | wallyworld, it'll certainly be *easier* | 09:20 |
| wallyworld | indeed | 09:21 |
| fwereade | wallyworld, and the uncommitted state stuff will hopefully help there | 09:21 |
| wallyworld | yes | 09:21 |
| fwereade | wallyworld, did you get a chance to read that wiki doc btw? | 09:21 |
| wallyworld | fwereade: i wish :-( on my todo list, will get there torrow | 09:22 |
| wallyworld | or tonight after a drink | 09:22 |
| fwereade | wallyworld, no worries, but I think we can probably have interesting discussions about it | 09:22 |
| wallyworld | fwereade: if nothing else, i plan on drinking way too much with you in seattle and talking there :-D | 09:23 |
| fwereade | wallyworld, sgtm :) | 09:23 |
| thomnico | hello all (I'm new to go and dev in juju please be gentle) | 10:57 |
| thomnico | I would like to get a config parameter in juju/container/image.go | 10:58 |
| thomnico | like http-proxy for expl.. | 10:58 |
| thomnico | can someone provide me an example of that ?? I got lost with the config / environ etc.. options | 10:59 |
| mup | Bug #1490947 opened: Unable to add manually provisioned machine previously destroyed <juju-core:New> <https://launchpad.net/bugs/1490947> | 11:55 |
| perrito666 | cherylj: congratulations :) | 12:39 |
| perrito666 | katco: why would you cancel tanzanite standup? | 13:27 |
| katco | perrito666: eh? | 13:27 |
| perrito666 | I just got an email from gcal stating that you cancelled tanzanite standup, forever | 13:28 |
| katco | perrito666: uh... can't be a coincidence, i'm trying to get kmail to work with my calendar. i hope it's not doing something completely stupid | 13:28 |
| katco | perrito666: i just refreshed my canonical calendar... | 13:29 |
| perrito666 | well, seems kmail got fun | 13:29 |
| perrito666 | katco: trying the new kde? | 13:29 |
| katco | perrito666: no, i use i3 | 13:30 |
| mgz | perrito666: you died... ;_; | 13:30 |
| katco | perrito666: trying kmail because i can't find a good linux mail client. and i especially can't find one that supports caldav. looks like kmail is not an exception >.< | 13:31 |
| mup | Bug #1490977 opened: juju run moves errored units state to pending <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1490977> | 13:31 |
| TheMue | katco: I now simply use inbox in a browser, at least for our canonical mail | 13:32 |
| katco | TheMue: i have 3 inboxes to manage... don't like keeping 3 tabs open 24/7 | 13:33 |
| TheMue | katco: my standard mailer can't be told here *cough* *cough* Apple Mail *cough* | 13:33 |
| TheMue | katco: yeah, multi account is always nice. once tried thunderbird and quickly shrugged | 13:35 |
| katco | TheMue: Thunderbird is terribly slow for me | 13:35 |
| TheMue | katco: I had troubles with the UI, not very intuitive | 13:36 |
| katco | TheMue: kmail is working ok. pretty speedy, but UI is not intuitive in some places. | 13:38 |
| cherylj | thanks, perrito666 :) | 13:39 |
| TheMue | cherylj: also from my side | 13:40 |
| cherylj | thanks, TheMue :) | 13:41 |
| anastasiamac | katco: u did not like tanzanite standup?... at all?... :( | 13:44 |
| katco | anastasiamac: i'm sorry :( see above chat... my calendar software decided to be stupid | 13:51 |
| perrito666 | katco: i3? why you hate eye candy so much? :p | 13:52 |
| katco | perrito666: i love eye candy :) i love tiling more | 13:52 |
| anastasiamac | katco: seen and m sympathic but will have fun in the morning :D it's almost midnight | 13:52 |
| katco | anastasiamac: haha ok... go to bed! | 13:53 |
| anastasiamac | katco: :D but... but... it's the best time to work - everyone else is finally in bed | 13:53 |
| katco | lol | 13:53 |
| perrito666 | anastasiamac: amen | 13:54 |
| perrito666 | but if you husband is anything like my wife you will eventually hear a "wtf are you doing typing in the middle of the night" | 13:54 |
| anastasiamac | perrito666: he is in IT as well... he is typing in his office too now :) | 13:55 |
| perrito666 | anastasiamac: glorious | 13:55 |
| perrito666 | the good thing about night habits is that they get you things if your SO is not a night person | 13:55 |
| perrito666 | last thing I heard is "would you please get a new kindle with light? your bedside light is not letting me sleep" | 13:56 |
| anastasiamac | perrito666: :D better new kindle than separate rooms :) | 13:57 |
| perrito666 | anastasiamac: well the only other room of the house is my office :p | 13:57 |
| perrito666 | new house got an office at the oposite end of the bedroom so I can be noisy late | 13:58 |
| anastasiamac | perrito666: that's something to look forward to :D | 13:58 |
| perrito666 | who has rb and github superpowers? | 14:01 |
| perrito666 | I need to close a couple of prs | 14:01 |
| mgz | bogdanteleaga: looks like juju/testing was broken by the last commit on mgo.v2 | 14:18 |
| mgz | bogdanteleaga: two ways forward, fix that properly, or add a dependencies.tsv for juju/testing that specifies a working revision of mgo.v2 | 14:19 |
| bogdanteleaga | mgz: well, we can't set deps.tsv separately afaik, I think we can just wait for an upstream fix since this isn't that much of a priority now | 14:39 |
| mgz | bogdanteleaga: I am doing it now. | 14:39 |
| mgz | we just need a dependencies.tsv file specific for juju/testing | 14:40 |
| mgz | like a subset of the juju/juju one | 14:40 |
| mgz | bogdanteleaga: done it, works | 14:47 |
| mgz | bogdanteleaga: I'll get my branhc review'd and land | 14:47 |
| bogdanteleaga | mgz: hmm, this still doesn't seem like a good approach tho | 14:48 |
| bogdanteleaga | mgz: it does solve this problem, but it feels really sketchy to have different dependencies for the juju/* stuff that's not core | 14:49 |
| mgz | well, it would be nice if the tip of all branches a project depends on never breaks | 14:49 |
| mgz | but that's what happens to us in practice | 14:49 |
| bogdanteleaga | :) | 14:49 |
| bogdanteleaga | wait don't we already use the deps.tsv from core? | 14:50 |
| bogdanteleaga | I think that's what's getting me confused | 14:50 |
| mgz | ony juju/juju does, the other projects at least pretend at being independant | 14:50 |
| bogdanteleaga | oh, so the rest build with tip | 14:50 |
| bogdanteleaga | ok | 14:50 |
| bogdanteleaga | then it definitely makes sense | 14:50 |
| bogdanteleaga | if you could find a way to make it pull the core one it would be great | 14:51 |
| mgz | the problem with just using the core one is we actually don't want to pull in the mountains of stuff that does | 14:52 |
| mgz | and we still have the issue that changes on another branch can break us, if juju/juju deps get updated | 14:52 |
| ericsnow | katco: are we still targeting 1.25 for #1478156 | 14:53 |
| mup | Bug #1478156: tabular format does not give enough details about machine provisioning errors <charmers> <juju-core:Triaged> <https://launchpad.net/bugs/1478156> | 14:53 |
| * marcoceppi hopes | 14:53 | |
| ericsnow | :) | 14:54 |
| katco | ericsnow: nope; feature freeze for 1.25.0 has passed. 1.25.1 | 14:57 |
| ericsnow | katco: right, I meant 1.25 :) | 14:57 |
| katco | ericsnow: just updated the bug | 14:57 |
| ericsnow | katco: thanks | 14:57 |
| katco | ericsnow: ty for asking | 14:57 |
| bogdanteleaga | mgz: well yeah, if they try to be independent it does make sense to have different ones | 14:58 |
| bogdanteleaga | mgz: you could just take what you need from core tho | 14:58 |
| natefinch | mgz: have you talked to gustavo about the mgo breakage? | 15:00 |
| mgz | natefinch: I commented on the mp that broke the test suite | 15:02 |
| mgz | natefinch: https://github.com/go-mgo/mgo/issues/153 if you are curious | 15:12 |
| natefinch | mgz: thanks. | 15:15 |
| mgz | bogdanteleaga: merged | 15:22 |
| natefinch | niemeyer3: have you seen the update about our tests failing because of that IPv4-only change to mgo? ^^ | 15:23 |
| niemeyer3 | natefinch: Have you seen the update on the update? :) | 15:24 |
| bogdanteleaga | mgz: yay thanks | 15:25 |
| natefinch | niemeyer3: have now. Thanks! :) | 15:25 |
| natefinch | mgz: ^ | 15:25 |
| niemeyer3 | np, sorry for the trouble | 15:26 |
| natefinch | mgz: sounds like we can avoid putting a dependencies.tsv in juju/testing, which would be my preference | 15:27 |
| mgz | natefinch: I got around it by just putting it in the job | 15:27 |
| mgz | natefinch: we're going to have to have one for charm though I think | 15:28 |
| natefinch | mgz: more than one dependencies.tsv in a build is asking for trouble. | 15:28 |
| mgz | yup, but I think the projects can just ignore any in their dependencies | 15:30 |
| bogdanteleaga | can somebody close https://github.com/juju/juju/pull/2951? | 15:34 |
| bogdanteleaga | I pulled it in another PR to update dependencies and run gofmt | 15:34 |
| natefinch | mgz: not really a fan of packages having their own dependencies.tsv ... why is charm going to need it? Just for mgo? | 15:35 |
| bogdanteleaga | also http://reviews.vapour.ws/r/2534/ and http://reviews.vapour.ws/r/2533/. They're closed on github but reviewboard didn't pick it up | 15:35 |
| mgz | natefinch: charm has various vN branches, the tips of which are not compatible with the tips of all the branches they use | 15:38 |
| mgz | natefinch: http://paste.ubuntu.com/12246351/ | 15:39 |
| natefinch | mgz: why not? it should be referencing only things which are stable and/or using gopkg.in for versioning... otherwise we're doing something wrong. | 15:40 |
| natefinch | mgz: that looks like we're doing something wrong :/ | 15:41 |
| katco | ericsnow: wwitzel3: natefinch: has anyone updated the wpm spec yet? | 16:30 |
| ericsnow | katco: I haven't | 16:30 |
| ericsnow | katco: I'll do it now | 16:30 |
| katco | ericsnow: ty | 16:30 |
| wwitzel3 | thanks ericsnow :) | 16:42 |
| * ericsnow cringes every time he sees "whit has quit" | 16:48 | |
| lazyPower | Are any core devs that are familiar with proxy settings available to help troubleshoot an issue w/ an orangebox in #juju? kwmonroe and I are starting to come up dry as this is one of those grey areas we dont tread in much | 18:11 |
| ericsnow | katco: did we settle on what "juju status" is supposed to report for workloads? just a count? IDs only? | 18:15 |
| katco | ericsnow: no, just that it would be a 1-line representation | 18:15 |
| ericsnow | katco: k | 18:15 |
| ericsnow | katco: 1 line per workload or 1 line per unit? | 18:22 |
| katco | ericsnow: 1 per workload, right? because it's workload status, not unit status | 18:23 |
| ericsnow | katco: k | 18:23 |
| katco | ericsnow: lmk when you're finished | 18:43 |
| ericsnow | katco: k | 18:43 |
| perrito666 | mgz: still around? | 18:45 |
| ericsnow | katco, natefinch, wwitzel3: could you double-check my updates to the spec? in particular check my changes relative to status | 19:08 |
| wwitzel3 | ericsnow: ok, I'll give it a read | 19:21 |
| katco | ericsnow: i'm tal, but i'd like wwitzel3 to look at it as well since he had a hand in drafting it | 19:21 |
| ericsnow | wwitzel3, katco: thanks | 19:23 |
| katco | ericsnow: in the yaml, do we really need the top-level workloads key? | 19:24 |
| ericsnow | katco: probably not | 19:26 |
| katco | wwitzel3: here | 19:26 |
| katco | wwitzel3: https://docs.google.com/document/d/1PcRQXaerlsACro4y1y5LWD-uvhfHya2CkOcoljyFyCU/edit#heading=h.hvw0kpxrzscu | 19:26 |
| natefinch | ericsnow, katco: keep in mind that the yaml has to be produced by code, which has to handle collisions etc. The reason we have components:workloads:<workload> is because components is a map of all the component names (so you don't have colisions between component names and other stuff in that part of the status), and then workloads as the component name to keep the workload data separate from other component data | 19:31 |
| natefinch | ericsnow, katco: Although... I guess if we're switching this to juju ps, then all of that is irrelevant | 19:32 |
| ericsnow | natefinch: we're not switching all of it | 19:32 |
| wwitzel3 | we aren't? | 19:33 |
| natefinch | ericsnow: oh, I thought we were totally yanking workloads out of status | 19:33 |
| ericsnow | natefinch: if we are then it certainly is simpler :) | 19:33 |
| wwitzel3 | ericsnow: it looks good to me, but I was always under the impression that all status stuff was moving under ps | 19:44 |
| ericsnow | wwitzel3: that's fine with me :) | 19:45 |
| katco | ericsnow: wwitzel3: i can go with that | 19:46 |
| ericsnow | katco, wwitzel3: I'll update the spec | 19:46 |
| natefinch | ericsnow: do we plan on supporting executable plugins in production in the future? | 20:28 |
| ericsnow | natefinch: no immediate plans, but I'm hopeful | 20:28 |
| mup | Bug #1491132 opened: Failing ec2 tests <juju-core:New> <https://launchpad.net/bugs/1491132> | 20:29 |
| natefinch | ericsnow: should we change the name of the doc? | 20:39 |
| ericsnow | natefinch: nice catch :) | 20:40 |
| ericsnow | natefinch: done | 20:40 |
| natefinch | If you call 72 point font a nice catch, sure ;) | 20:40 |
| natefinch | ericsnow: should we remove all references to plugins for now?. I think communication on that point has been rather clear and decisive... which doesn't mean we can't bark up that tree another day. | 20:43 |
| ericsnow | natefinch: I thought I had moved all those references down to an "open questions" section | 20:44 |
| natefinch | ericsnow: ahh, yes, sorry, the section title had scrolled off the top of the screen :D | 20:45 |
| natefinch | ericsnow: there are some comments that still use the word plugin though | 20:45 |
| ericsnow | natefinch: I did not edit any comments (nor planned on doing so) | 20:46 |
| natefinch | ericsnow: *nod*, just trying to avoid any misunderstanding due to the use of "old" terminology. | 20:48 |
| ericsnow | natefinch: np | 20:49 |
| === cory_fu is now known as cory_out | ||
| menn0 | thumper: here's the PR that was almost done: http://reviews.vapour.ws/r/2552/ | 22:03 |
| * thumper finally gets to look at email | 23:04 | |
| wallyworld | axw: anastasiamac: perrito666: our standup event is gone for some reason, i'll create a new one | 23:16 |
| perrito666 | yes please | 23:16 |
| axw | wallyworld: katco cancelled it... accident I guess | 23:16 |
| wallyworld | created | 23:17 |
| * wallyworld makes a note to cancel katco's meetings in revenge | 23:18 | |
| axw | hehe | 23:18 |
| wallyworld | axw: can you get in? | 23:20 |
| katco | axw: wallyworld: hey i'm so sorry... i tried to refresh my calendars in kmail and for some unknown reason it cancelled the tanzanite standup. i have no earthly idea why | 23:38 |
| wallyworld | katco: sure, it was all google's fault | 23:38 |
| katco | wallyworld: kmail! | 23:38 |
| katco | wallyworld: didn't we just talk yesterday about how they all suck? ;p | 23:38 |
| wallyworld | katco: yes we did | 23:45 |
| wallyworld | perrito666: re: rpc and json marshalling of nested map | 23:46 |
| wallyworld | see bug 1486254 | 23:46 |
| mup | Bug #1486254: Raw Go errors reported to users <jes> <ui> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1486254> | 23:46 |
| wallyworld | the last comment | 23:46 |
| wallyworld | looks like there's some potential overlap there | 23:46 |
| wallyworld | perrito666: you may want to just deal with simple maps initially | 23:47 |
| perrito666 | wallyworld: key=string/int ? | 23:47 |
| wallyworld | perrito666: yeah, that status data was i think only intended to be simple string->string | 23:48 |
| wallyworld | of string->primitive type | 23:48 |
| wallyworld | or | 23:48 |
| perrito666 | well that is there then, going with that :) | 23:48 |
| wallyworld | yep | 23:48 |
| wallyworld | no need to over complicate it | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
