| alexisb | anastasiamac, ping | 00:37 |
|---|---|---|
| alexisb | if you are around we can hope on the release standup | 00:37 |
| anastasiamac | alexisb: tyvm! see u there | 00:38 |
| veebers | axw: to clarify for myself, you want to get this landed for the coming release right? https://github.com/juju/juju/pull/5877 | 01:15 |
| wallyworld | veebers: technically, we are down to critical fixes only. if we get a good CI run, maybe this could land then and we could use it if CI passes, but have the fallback of a good run with all criticals fixed | 01:18 |
| veebers | wallyworld: right, I'm checking so I know the timeline expectations for getting this in. i.e. if I ping about it tomorrow mornings standup it'll probably be to late to be included in the release. But sounds like that's ok? | 01:21 |
| wallyworld | veebers: yeah, i think they want to start the release their thursday, so too late | 01:21 |
| wallyworld | we have stuff queued up to land post beta | 01:21 |
| veebers | wallyworld: cool. I'll get it sorted today/tomorrow | 01:22 |
| wallyworld | sounds good, ty | 01:22 |
| axw | veebers wallyworld: yeah it doesn't have to go into this release, it's just been dragging on for a while now, and needs to get sorted | 01:23 |
| axw | veebers wallyworld: sooner we address the better, because it's a change for users to adapt to. we may need to iterate on syntax based on feedback | 01:24 |
| wallyworld | yep | 01:24 |
| veebers | ack | 01:24 |
| wallyworld | axw: we can do a snap :-) | 01:24 |
| axw | wallyworld: true :) | 01:25 |
| wallyworld | well, as soon as I get a bit more sorted out | 01:25 |
| veebers | axw: re: http://bazaar.launchpad.net/~axwalk/juju-ci-tools/cli-model-owner/revision/1523/utility.py can you give an example of what model_name being passed in would look like and what the expected return output would be. I'll branch that and get unit tests written and propose it etc. | 01:25 |
| axw | veebers: e.g., "admin@local/default" | 01:26 |
| axw | or just "admin/default" | 01:26 |
| axw | veebers: and thanks | 01:27 |
| veebers | nw | 01:27 |
| axw | anastasiamac: can http://reviews.vapour.ws/r/5341/ be closed? | 01:32 |
| anastasiamac | axw: yes. let's :) I'll re-PR when ready :) | 01:33 |
| axw | thanks | 01:33 |
| anastasiamac | axw: done | 01:33 |
| wallyworld | axw: does the diff for "environs: update API for hosted models" include the work from the dependent PR. I think it does? So easiest to review once that other PR lands and it can be rebased? | 01:40 |
| axw | wallyworld: it does, but the RB diff should just show the delta | 01:40 |
| wallyworld | really? even if proposed against master? ok | 01:41 |
| axw | wallyworld: yeah, you can do that with "rbt post -r <RB review ID> --parent <parent git branch>" | 01:41 |
| perrito666 | mm, what was the way to tell mongo to ve Trace level verbose? | 01:41 |
| perrito666 | s/mongo/juju | 01:42 |
| wallyworld | axw: nice. where does RB review ID come from? that implies you propose via github PR, and the issue that post with the newly created id? | 01:43 |
| axw | wallyworld: yes that's I do. create the PR, the bot creates the RB review (ID is just the number in the URL), then you pass that to the tool | 01:43 |
| wallyworld | axw: and the initial step is to branch off the upstream branch right? instead of branching off master | 01:44 |
| anastasiamac | axw: i do not want to continue crossing swords on this review. Could u plz double-check outstanding issues so that we can progress its landing? http://reviews.vapour.ws/r/5360/ | 01:45 |
| perrito666 | is the all team meeting happening? I somehow presume that its the exact same group of people than the standup | 01:51 |
| anastasiamac | perrito666: m all for team meeting. there are some updates around bug and release mgmt that can b communicated better. there is criteria stuff that i'd love to talk about :) | 01:52 |
| anastasiamac | perrito666: and there is always nice dueling to witness | 01:52 |
| anastasiamac | perrito666: also would love to touch base re: review process | 01:52 |
| anastasiamac | perrito666: oc, i might b dreaming and noone will join me again.. in which case, I'll just tlak to myself ;) | 01:53 |
| axw | anastasiamac: I don't really think splitting that test is worthwhile. it's one of the cases where I think a table-driven test would be fine | 01:59 |
| anastasiamac | axw: as an OCR, m happy to go with ur opinion | 01:59 |
| anastasiamac | axw: thumper: menn0:perrito666: team meeting | 02:02 |
| anastasiamac | natefinch: ^^ | 02:02 |
| axw | wallyworld: I think we should stop showing bootstrap-config in "show-controller" by default (maybe not at all?) what do you think? | 02:36 |
| axw | wallyworld: now that bootstrap config contains all the defaults, it's taking up a lot of screen space | 02:36 |
| wallyworld | axw: yeah, not much point. what we *should* show is controller config | 02:37 |
| axw | wallyworld: hmm is that going to be dynamic? will we have commnads to update it? | 02:38 |
| wallyworld | axw: so far, it is mongo port, api port which are static, plus numa setting, which i guess could be dynamic. and there is already a bespoke get-controller-config command. so yeah, just remove bootstrap config i reckon | 02:40 |
| axw | wallyworld: ah I thought you meant inherited config. okey dokey | 02:40 |
| wallyworld | s/remove/not show | 02:40 |
| wallyworld | axw: there's a juju model-defaults to show inherited config | 02:40 |
| axw | wallyworld: think it's worth having a flag to show? I'm not sure it was even asked for, I think I just added it there | 02:41 |
| wallyworld | i wouldn't add to the complexity by even having a flag - just not show IMO. people don't really need to see it and it's only there for kill-controller and restore -b | 02:41 |
| axw | wallyworld: cool, SGMT | 02:41 |
| axw | SGTM* | 02:41 |
| axw | wallyworld: btw I've just bootstrapped AWS with region, access-key and secret-key removed from model config | 02:42 |
| axw | finally got there | 02:42 |
| wallyworld | \o/ ^ 100 | 02:42 |
| wallyworld | awesome sauce | 02:42 |
| wallyworld | that deserves a beer or two | 02:43 |
| axw | wallyworld: should be able to drop region from restricted config and add a model in another region now too, I'll try that at the same time | 02:43 |
| wallyworld | whohoo | 02:43 |
| wallyworld | assuming networking is set up so the model can talk to the controller | 02:44 |
| wallyworld | not sure what's involved there | 02:44 |
| wallyworld | may need to specify a vpc id? | 02:44 |
| axw | wallyworld: it works because it goes over the internet | 02:44 |
| axw | public IPs | 02:44 |
| * axw tests | 02:44 | |
| wallyworld | ah right. we should look to fix it so it doesn't have to, or document how to at least | 02:45 |
| axw | wallyworld: why? | 02:45 |
| axw | wallyworld: traffic cost? | 02:46 |
| wallyworld | yep, plus efficency | 02:46 |
| wallyworld | maybe port exposing / security groups would prevent it also if it is external traffic? | 02:46 |
| axw | wallyworld: I'd like to think that AWS knows how to route those addresses efficiently. don't know about the cost side | 02:46 |
| wallyworld | not sure that AWS does that sort of short circuiting | 02:47 |
| wallyworld | could be wrong | 02:47 |
| axw | wallyworld: anyway, I now have a controller in AWS with machines in two regions :) | 02:47 |
| wallyworld | awesome :-) | 02:47 |
| * axw goes to make a cup of tea to celebrate | 02:47 | |
| wallyworld | but IMO we need clear guidelines on how to set up | 02:47 |
| wallyworld | add some rum to the tea | 02:48 |
| axw | wallyworld: what do you mean? there's no setup. just bootstrap, then add-model --region=foo | 02:48 |
| wallyworld | networking | 02:48 |
| wallyworld | how to avoid external traffic etc | 02:48 |
| wallyworld | will be provider specific | 02:48 |
| axw | wallyworld: ok. yes, if/when we change that to not go over hte internet | 02:49 |
| wallyworld | maybe we guide them to a suitable space set up etc | 02:49 |
| veebers | wallyworld: re: log forwarding, just adding a model wouldn't be enough to get that models logs forwarded to the controller right? It'll need to do some <action> for that to trigger a forward? | 03:33 |
| veebers | (this is in response to an email from you from a wee while ago) | 03:34 |
| wallyworld | veebers: i think log forwarding needs to be enabled on the controller model, and then yeah the hosted model needs to log somethong | 03:35 |
| veebers | wallyworld: I have the basic forwarding stuff (i.e. controller forwards it's logs). What action would generate a log from the model that would be forwarded? | 03:36 |
| wallyworld | veebers: just the act of adding the model - it will log worker startup etc | 03:37 |
| veebers | wallyworld: interesting. I'm not seeing that forwarded but I might be doing something wrong. I'll continue digging | 03:38 |
| wallyworld | you see the controller model logs ok though? | 03:38 |
| wallyworld | just not hosted model logs | 03:38 |
| veebers | wallyworld: correct | 03:39 |
| wallyworld | hmmm, it may be that it's only enabled for the controller, i'd need to check | 03:39 |
| wallyworld | give me a few minutes | 03:39 |
| veebers | wallyworld: awesome, cheers | 03:39 |
| thumper | menn0: http://reviews.vapour.ws/r/5369/ | 03:46 |
| wallyworld | axw: doing a rb post, what username/password did you use? | 03:55 |
| wallyworld | since i normally sign into rb using github sso | 03:56 |
| menn0 | wallyworld: you use oauth with rbt too | 03:57 |
| menn0 | wallyworld: see the bottom of reviewboard.md in docs/contributing | 03:57 |
| menn0 | docs/contributions | 03:58 |
| wallyworld | menn0: ta | 03:58 |
| menn0 | thumper: looking | 03:58 |
| menn0 | thumper: review done | 04:09 |
| thumper | menn0: ta | 04:09 |
| menn0 | thumper: did you try reproducing using enable-ha? | 04:09 |
| thumper | menn0: I did, wasn't able to reproduce | 04:09 |
| thumper | menn0: btw, are you taking the piss? | 04:10 |
| menn0 | thumper: I guess it's somewhat timing dependent | 04:10 |
| thumper | "errorCoder" ? | 04:10 |
| menn0 | thumper: slightly :) | 04:10 |
| menn0 | thumper: only because I knew it would annoy you :) | 04:10 |
| * thumper slaps menn0 | 04:10 | |
| menn0 | thumper: you can drop it :) | 04:11 |
| thumper | I did :) | 04:11 |
| thumper | menn0: can't really have the server tell the client to retry without parsing the error types... | 04:12 |
| * thumper thinks | 04:12 | |
| thumper | let me look a bit more | 04:12 |
| wallyworld | veebers: the log forwarder will get it's logs to send what whatever we record in state for debug log | 04:27 |
| wallyworld | menn0: does debug log include logs for hosted models? | 04:27 |
| menn0 | wallyworld: yes, but only for the machines and units in the model | 04:28 |
| wallyworld | menn0: so not controller actions like starting workers etc | 04:28 |
| menn0 | wallyworld: any controller level activity (API requests and workers specific to the model in the controller) is still logged against the controller model | 04:28 |
| menn0 | wallyworld: I have a plan to fix this. | 04:28 |
| menn0 | wallyworld: thumper's recent work on loggo is part of that | 04:29 |
| wallyworld | menn0: no worries, veebers was testing log forwarder and wanted to know what to expect | 04:29 |
| menn0 | kk | 04:29 |
| wallyworld | for hosted models | 04:29 |
| wallyworld | veebers: so you'll need to deploy something to see activity | 04:29 |
| veebers | wallyworld: ok makes sense. Thank you | 04:31 |
| wallyworld | np, hope it tests ok | 04:31 |
| veebers | wallyworld: ah, I did try deploying something while poking around but maybe looks like it gets logged once the deloy is done? at any rate that helps, should be easy enough to test | 04:34 |
| wallyworld | ok, let me know | 04:34 |
| veebers | will do | 04:35 |
| mup | Bug #1609643 opened: provider/...: make use of Environ.Create to create environ-wide resources like security groups <juju-core:Triaged> <https://launchpad.net/bugs/1609643> | 05:35 |
| === frankban|afk is now known as frankban | ||
| rogpeppe | fwereade_: you around? | 08:58 |
| rogpeppe | fwereade_: just wondering if there's a good reason why the mock clock interface doesn't define the NewTimer method | 09:00 |
| dimitern | rick_h_: ping | 09:07 |
| dimitern | rick_h_: I was thinking to JFDI https://github.com/juju/juju/pull/5922, since there are only 2 blockers, both Fix Committed - any concerns? | 09:09 |
| fwereade_ | rogpeppe, I think I did it that way to begin with but was unbothered by a PR that made things slightly cleaner by separating them, but memory is a little fuzzy | 09:17 |
| rogpeppe | fwereade_: it's just awkward if you need to use it with something that actually wants to use Reset | 09:18 |
| rogpeppe | fwereade_: for example, we're implementing an apiserver pinger and it would be nice to use the mock clock stuff | 09:19 |
| rogpeppe | fwereade_: but it's awkward if you can't have Reset | 09:19 |
| rogpeppe | fwereade_: i wondered if there was some "that's gonna be hard to do" reason for the omission or just that it was more convenient at the time. | 09:20 |
| rogpeppe | fwereade_: one other thing: testing.Timer is exported, as is testing.Timer.Id. any particular reason for that? | 09:21 |
| fwereade_ | rogpeppe, I'm pretty sure, thinking further, that the only reason we don't have NewTimer is because we didn't need it yet | 09:24 |
| rogpeppe | fwereade_: ah, ok | 09:24 |
| fwereade_ | rogpeppe, sorry, I was confused with the AfterFunc stuff, which was the reason Timer was added | 09:24 |
| fwereade_ | rogpeppe, (for whatever reason I've never found Timer very helpful myself, but I have no real objections to it, please go ahead and add it if it would be useful to you) | 09:27 |
| rogpeppe | fwereade_: ok, cool. it means that normal idiomatic timer code can be easily changed to use mock clocks. | 09:28 |
| rogpeppe | fwereade_: i'm going to unexport testing.Timer too, if that sgty | 09:29 |
| * dimitern decides to use JFDI | 09:30 | |
| babbageclunk | dimitern: It's pretty early in the morning for rick_h_, I think. | 09:31 |
| dimitern | babbageclunk: true, thought I wasn't sure if he's back home.. | 09:32 |
| dimitern | babbageclunk: btw which version of emacs are you on? | 09:32 |
| babbageclunk | dimitern: oh, good point. | 09:32 |
| babbageclunk | dimitern: 24.5.1 apparently | 09:32 |
| dimitern | babbageclunk: from the archive or ppa? | 09:33 |
| babbageclunk | dimitern: archive. | 09:33 |
| dimitern | babbageclunk: ok, thanks - I'm on 25.1.50.3 built from tip a while ago | 09:34 |
| dimitern | /me, inspired by ivoks-vim snap is snapping emacs ;) | 09:34 |
| rogpeppe | fwereade_: BTW i think the AfterFunc implementation is subtly wrong - i don't think it would work correctly in this scenario: https://play.golang.org/p/X82i5TjzYD | 09:35 |
| babbageclunk | dimitern: nice. | 09:35 |
| ejat | https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1609707 | 09:37 |
| mup | Bug #1609707: lxc in Power8 System <lxc (Ubuntu):New> <https://launchpad.net/bugs/1609707> | 09:38 |
| babbageclunk | ejat: Hi, did you mean to post that in juju-dev? | 09:39 |
| ejat | babbageclunk: sorry mistakenly | 09:39 |
| dimitern | ejat: https://linuxcontainers.org/lxd/getting-started-cli/ - have you tried enabling trusty-backports and installing from there? | 09:39 |
| ejat | thanks dimitern ... its help | 09:42 |
| dimitern | ejat: if it worked, please comment on the bug ;) | 09:42 |
| ejat | yeah .. might be closing the bugs as well | 09:43 |
| babbageclunk | fwereade_, fwereade__, dimitern: can we do a hangout to talk about axw's comments on http://reviews.vapour.ws/r/5365/? | 09:43 |
| dimitern | babbageclunk: sure, let me have a look first though.. | 09:43 |
| babbageclunk | actually, axw, are you around too? | 09:43 |
| * babbageclunk keeps forgetting Perth's in a very different timezone from NZ. | 09:44 | |
| fwereade__ | babbageclunk, they're all basically the same place, right? ;p | 09:44 |
| dimitern | babbageclunk: are you now in NZ? | 09:44 |
| fwereade__ | babbageclunk, (yes, ofc) | 09:44 |
| fwereade__ | babbageclunk, where? | 09:45 |
| ejat | dimitern: in 14.04 lts cant use juju .. but if im trying to use all-in-one installer gets error | 09:45 |
| ejat | s/juju/conjure | 09:46 |
| dimitern | ejat: I'd suggest asking in #ubuntu-server for conjure-up, folks here are not that familiar with it; also have you checked http://conjure-up.io/ ? | 09:48 |
| dimitern | babbageclunk, fwereade__: ok, I can do a HO now if it works for you as well | 09:50 |
| babbageclunk | dimitern: No, I'm still in the uk, but I kind of lump axw and other Aussies into the NZ timezone in my head. | 10:00 |
| dimitern | babbageclunk: ah :) | 10:00 |
| dimitern | babbageclunk: you have a review btw | 10:00 |
| babbageclunk | Sorry, was afk - shall we meet in standup? | 10:00 |
| dimitern | babbageclunk: let's do it | 10:00 |
| anastasiamac | babbageclunk: omg! how could u? Just kidding :) Brisbane (Ian and I) are 2 hrs behind NZ and Andrew is 2hrs behind us... and it's 7pm for axw :) but who really looks at time here? :D | 11:06 |
| babbageclunk | anastasiamac: I mean, I realise that thinking of a huge continent all being in the same timezone as a couple of islands three hours flight away is wrong, I just can't convince my brain of it. ;) | 11:09 |
| anastasiamac | babbageclunk: yeah :) time zones are great \o/ for eg, russia has fun fluctuating between having 9 and 11 time zones https://en.wikipedia.org/wiki/Time_in_Russia | 11:16 |
| rogpeppe | fwereade__: WIP (I want some tests) but this is my suggestion for updates to the Clock implementation: https://github.com/juju/testing/pull/108 | 11:59 |
| fwereade__ | rogpeppe, thanks | 11:59 |
| rogpeppe | fwereade__: ah, just remembered that it needs to fire notifyAlarm on reset. | 12:00 |
| fwereade__ | rogpeppe, very nice, but I can't help but think it needs tests | 12:08 |
| fwereade__ | probably did from the beginning really | 12:08 |
| * fwereade__ hangs head in shame | 12:08 | |
| rogpeppe | fwereade__: i totally agree | 12:08 |
| rogpeppe | fwereade__: that's why i labelled it as WIP in the PR descr | 12:08 |
| rogpeppe | fwereade__: just thought you might want to look initially | 12:09 |
| rogpeppe | fwereade__: i think this fixes a few bugs too | 12:09 |
| fwereade__ | rogpeppe, yeah, much appreciated | 12:09 |
| fwereade__ | rogpeppe, indeed | 12:09 |
| fwereade__ | rogpeppe, the urge to LGTM without looking further was strong | 12:09 |
| rogpeppe | fwereade__: unfortunately we also need to change juju-core to use the testing.Clock rather than juju/testing.Clock too | 12:10 |
| fwereade__ | rogpeppe, dammit | 12:11 |
| rogpeppe | fwereade__: and juju/clock itself needs updating to change the interface | 12:11 |
| * fwereade__ envies google's single-giant-repo more every day | 12:12 | |
| rick_h_ | dimitern: looks like you're all set | 12:36 |
| dimitern | rick_h_: yep | 12:37 |
| dimitern | rick_h_: it was a low risk change anyway I guess :) | 12:37 |
| rick_h_ | dimitern: if you get a sec can you peek at https://askubuntu.com/questions/808011/how-to-specify-what-maas-interface-juju-should-use | 12:38 |
| rick_h_ | dimitern: if you know of a way in 1.25 to do that? | 12:38 |
| dimitern | rick_h_: I've looked at it, and almost answered but got distracted | 12:38 |
| rick_h_ | dimitern: ah cool ty | 12:38 |
| fwereade__ | oh poo | 12:48 |
| fwereade__ | babbageclunk, I have a migrations problem and could use an interlocutor, do you have a moment? | 12:49 |
| === redelmann is now known as rudi|wfh | ||
| === rudi|wfh is now known as rudi_wfh | ||
| === rudi_wfh is now known as rudi|wfh | ||
| mup | Bug #1609407 changed: remoteFunctionalSuite.TestUsingTCP no such network interface <blocker> <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1609407> | 12:51 |
| * fwereade__ will soliloquize; anyone interested should chime in | 12:59 | |
| fwereade__ | I'm adding refcounts to charms; they're contributed by units and applications | 13:00 |
| fwereade__ | we already have a very similar mechanism: *settings* refcounts, which are similarly contributed by apps and units | 13:00 |
| fwereade__ | and the underlying mechanism will work just fine if we use the charm globalKey for those refcounts directly, rather than appname#charm | 13:02 |
| fwereade__ | but (1) we migrate settingsrefcounts, which is suspicious, because it's an implementation detail entirely derived from other app and unit state | 13:03 |
| fwereade__ | (heh, (2) is not really important, assuming we check that unit charm urls match their apps', will check whether we do) | 13:05 |
| fwereade__ | ...ok, I cannot convince myself that it is definitely correct | 13:10 |
| fwereade__ | so, (2), the settingsrefs migration has potential problems | 13:11 |
| fwereade__ | and in combination I am reasonably sure that we should simply *not* be representing the refcounts directly in the serialized model, but should be reconstructing them on import | 13:12 |
| mbruzek | Do we have any documentation on how the charm store and charm commands work with macaroons and the ubuntu sso? I have a partner of ours having trouble with the commands and I wanted to point them at some documentation about the process. | 13:17 |
| rick_h_ | natefinch: I'm getting https://pastebin.canonical.com/162328/ trying to use my own build of juju, anything there look familiar e.g. "you did X wrong clearly"? | 13:37 |
| rick_h_ | natefinch: tried it on two different providers and 4 bootstraps all fail with some # of "after # attempts" | 13:37 |
| === cory_fu-vac is now known as cory_fu | ||
| dimitern | sinzui: hey, I've noticed you changed the milestone on bug 1609343 to beta15, but I forgot to set it to fix committed earlier today, and put the milestone back to beta14 | 13:45 |
| mup | Bug #1609343: [aws; beta13] Juju can pick subnets from the wrong VPC with spaces constraints specified <ec2-provider> <usability> <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1609343> | 13:45 |
| dimitern | since we don't have beta14 out | 13:45 |
| sinzui | dimitern: put it back to beta15. your commit is too new | 13:46 |
| dimitern | sinzui: ok then | 13:47 |
| babbageclunk | fwereade__: back, sorry - I think I follow. What you're saying makes sense to me, and is simpler than having a system where the refcounts are set manually separately on import. | 13:47 |
| dimitern | sinzui: done - I thought you're preparing to release b14 and pushing unfinished bugs forward | 13:48 |
| sinzui | dimitern: I am the best revision to release is from yesterday. your change is still being tested and has new kinds of failures | 13:48 |
| babbageclunk | fwereade__: you could have them still be serialised in the export and then check the serialised ones against the final ones after import? | 13:49 |
| fwereade__ | babbageclunk, well, we *do* have to set them manually on import, one way or another | 13:49 |
| dimitern | sinzui: I've checked the reports but nothing seemed remotely relevant to the fix itself | 13:50 |
| sinzui | dimitern: I am not saying your change made the failures. we are seeing new kinds of failures from many possible sources http://reports.vapour.ws/releases/4207 | 13:50 |
| fwereade__ | babbageclunk, we have to write the code either way | 13:50 |
| fwereade__ | babbageclunk, I'm not really sure which will be easier to get wrong | 13:50 |
| babbageclunk | fwereade__: Right, but ordinarily they'll be maintained as units and apps refer to them. | 13:50 |
| fwereade__ | babbageclunk, (incidentally, is there some code I'm missing that prevents us from trying to export if any charm upgrade is in progress? I feel like it should exist but couldn't find it in a quick scan) | 13:51 |
| fwereade__ | babbageclunk, indeed | 13:51 |
| babbageclunk | fwereade__: Don't know, sorry. | 13:51 |
| fwereade__ | babbageclunk, hm, I might actually be able to push it all below the layer that migration happens at | 13:52 |
| babbageclunk | fwereade__: Right, so then the refcounts are maintained as you restore apps and units? | 13:52 |
| fwereade__ | babbageclunk, yeah | 13:52 |
| babbageclunk | fwereade__: So the serialised refcount could be treated as a check after import. | 13:55 |
| babbageclunk | fwereade__: (That could cause problems if the point of the dummp and restore was to upgrade to a version that counted refs differently.) | 13:56 |
| fwereade__ | babbageclunk, I think I'd still rather it be a calculated property rather than an independent variable | 13:56 |
| fwereade__ | babbageclunk, and, yeah, it really *does* feel like an implementation detail | 13:56 |
| fwereade__ | babbageclunk, the only reason we're refcounting is because it's the only technique we've found applicable at this level | 13:56 |
| babbageclunk | fwereade__: presumably this is just a performance optimisation? Can you always recalculate it from the apps and units? | 13:57 |
| babbageclunk | fwereade__: Or is there some kind of cross-model consideration? | 13:59 |
| rick_h_ | fwereade__: natefinch dimitern ping for standup | 14:01 |
| perrito666 | rogpeppe: ping? | 14:02 |
| fwereade__ | babbageclunk, the refcounting is basically just for integrity | 14:06 |
| fwereade__ | babbageclunk, am I misunderstanding? | 14:07 |
| babbageclunk | fwereade__: The refcount prevents you from deleting something because there are other things referring to it - you could instead go and count all of the things that refer to it, right? I might be misunderstanding also. | 14:09 |
| natefinch | fwereade__: github.com/juju/schema.Checker has a "path" argument to Coerce that isn't documented at all. What is that for? https://godoc.org/github.com/juju/schema#Checker | 14:12 |
| fwereade__ | babbageclunk, yeah, exactly -- they're relevant only for the txn level | 14:13 |
| fwereade__ | natefinch, constructing useful descriptions of where you are in a nested structure | 14:13 |
| fwereade__ | natefinch, coerce failed at config.foo.bar[baz]: not an int | 14:13 |
| fwereade__ | natefinch, can't remember anything about how it actually works | 14:13 |
| natefinch | fwereade__: k | 14:14 |
| natefinch | fwereade__: related - Coerce for a FieldMap expects an interface that is a map of <something> to interface... where something can be a string or something with a String() method (possible due to reflection). Does anyone actually use the stringer form? Do we need to keep that code around? It makes the implementation a lot messier. | 14:15 |
| fwereade__ | natefinch, I don't know, I'm afraid | 14:16 |
| fwereade__ | natefinch, I am having difficulty imagining how that would work without stabbing you in the back on the regular | 14:17 |
| natefinch | fwereade__: indeed | 14:19 |
| natefinch | fwereade__: I sorta need to make a new version of the library anyway, maybe that's the best way to "fix" it. | 14:19 |
| fwereade__ | natefinch, if we're having to go that far, should we be dropping coerce and building something up with gojsonschema? | 14:20 |
| mup | Bug # changed: 1457575, 1552948, 1566801, 1568845, 1570096, 1575676, 1579010, 1588095, 1599503, 1600054, 1602034, 1602054, 1602716, 1604644, 1604931, 1605050, 1607557 | 14:21 |
| natefinch | fwereade__: the change to schema is actually backwards compatible... it's adding a notion of dependencies between attributes... here's the PR: http://reviews.vapour.ws/r/5364/ | 14:22 |
| natefinch | fwereade__: so.. I don't know. Personally, I'd prefer to use a standard, but I'm afraid that switching to gojsonschema might be a bigger change than we really want to make right now | 14:23 |
| fwereade__ | natefinch, is there a strong benefit to dependencies vs subdocs? is {foo-bar: x, foo-baz: y} is really a win over {foo: {bar: x, baz: y}}? | 14:24 |
| natefinch | fwereade__: No. I hadn't thought about using a subdoc for it | 14:24 |
| fwereade__ | natefinch, worth considering | 14:25 |
| fwereade__ | natefinch, that said we have no shortage of things in the first form already | 14:25 |
| fwereade__ | natefinch, however, if we *are* making changes, that might stremline things a bit | 14:26 |
| natefinch | fwereade__: not sure if that cleans things up or not. The main use case right now is openstack authentication. Either you have SSO or username/password, in the latter case, you need to specify username and password, in the former, you don't. | 14:27 |
| fwereade__ | natefinch, yeah, I see, even if there's an "auth" subdoc you still need the switch | 14:28 |
| fwereade__ | natefinch, or, hold on | 14:29 |
| fwereade__ | natefinch, wouldn't you do that with, uh, `schema.Any(ssoChecker{}, userpassChecker{})` or something? | 14:30 |
| fwereade__ | natefinch, but *that* only works on a subdoc | 14:31 |
| fwereade__ | natefinch, even so, {auth: {sso: blah}} and {auth: {user: foo, pass: bar}} is nicer than having auth-sso/auth-user/auth-pass all at the top level | 14:32 |
| fwereade__ | natefinch, and it feels more in tune with the schema package | 14:35 |
| fwereade__ | natefinch, even if that is a bit tautological | 14:35 |
| natefinch | fwereade__: this library is soooo confusing... yes, that would work | 14:36 |
| natefinch | fwereade__: though I don't know how to translate that to something you can define with environschema | 14:37 |
| fwereade__ | natefinch, can an Attr just have an optional Checker field? | 14:41 |
| natefinch | fwereade__: not really.. Attr is just a serialization schema... you can't really put an arbitrary piece of code in there | 14:43 |
| fwereade__ | natefinch, ...then the path of least resistance maybe starts to look like a Schema field with some jsonschema in there? | 14:45 |
| mup | Bug #1609818 opened: WorkerSuite.TestDelayedUpdateError timeout no more updates for you <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609818> | 14:45 |
| natefinch | fwereade__: the path of least resistance is to use the code that I've already written :) | 14:45 |
| fwereade__ | natefinch, might be a local maximum... it feels like schema is a fairly significant source of friction here | 14:47 |
| natefinch | fwereade__: that may be fair | 14:50 |
| mup | Bug #1609879 opened: juju2 says to destroy-model --force when using --keep-broken <juju-core:New> <https://launchpad.net/bugs/1609879> | 16:39 |
| babbageclunk | fwereade__: a state.LinkLayerDevice has (potentially) multiple addresses associated with it, but params.NetworkConfig (and network.InterfaceInfo) have only one address... | 16:41 |
| babbageclunk | fwereade__: Should I pick an address or have multiple interface infos coming back? | 16:41 |
| babbageclunk | fwereade__: (Might be more for dimitern but he's not around.) | 16:42 |
| * babbageclunk will re-ask tomorrow. | 16:45 | |
| mup | Bug #1609893 opened: juju status returns ERROR not logged in <juju-core:New> <https://launchpad.net/bugs/1609893> | 16:51 |
| === frankban is now known as frankban|afk | ||
| mup | Bug #1609893 changed: juju status returns ERROR not logged in <juju-core:New> <https://launchpad.net/bugs/1609893> | 16:57 |
| rick_h_ | natefinch: katco or all other people smarter than me, trying to use my juju build I get a failed bootstrap, but damn if everything doesn't seem to work out per logs/etc. https://pastebin.canonical.com/162345/plain/ | 17:00 |
| rick_h_ | I'm really open to ideas from folks that know more. | 17:00 |
| natefinch | rick_h_: looking | 17:01 |
| tvansteenburgh | hey core folks, i have a websocket client connected to a juju api server, but i don't know which version of juju i'm connected to. what's the easiest way to determine that? | 17:01 |
| katco | rick_h_: try turning on tracing and --debug while bootstrapping? | 17:01 |
| rick_h_ | katco: that is with --debug | 17:02 |
| katco | rick_h_: i see: "/home/rharding/src/juju/bin/juju bootstrap --upload-tools --keep-broken test" ? | 17:02 |
| rick_h_ | katco: ah sorry, I pasted from a previous run | 17:03 |
| katco | rick_h_: ah | 17:03 |
| katco | rick_h_: is it possible to set the log level to trace at bootstrap time? | 17:03 |
| rick_h_ | katco: will look for my next run | 17:03 |
| natefinch | tvansteenburgh: hmm.. AFAIK we don't have a dedicated "version" endpoint (which is a shame). I think the GUI has some heinous hacks to figure it out, but not entirely sure. | 17:05 |
| tvansteenburgh | natefinch: i was afraid that was the answer :/ | 17:05 |
| mup | Bug #1609893 opened: juju status returns ERROR not logged in <juju-core:New> <https://launchpad.net/bugs/1609893> | 17:09 |
| mup | Bug #1609896 opened: Race in github.com/juju/juju/rpc/server <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609896> | 17:18 |
| mup | Bug #1609910 opened: Juju API lacks version endpoint <juju-core:New> <https://launchpad.net/bugs/1609910> | 17:49 |
| mup | Bug #1609910 changed: Juju API lacks version endpoint <juju-core:New> <https://launchpad.net/bugs/1609910> | 17:52 |
| natefinch | rick_h_: got some time to talk? I got some feedback from william on my pr that needs discussion | 17:53 |
| natefinch | fwereade__: I presume you're long gone? | 17:53 |
| rick_h_ | natefinch: I've got a call in 7 if we can do it in there | 17:54 |
| rick_h_ | natefinch: https://hangouts.google.com/hangouts/_/canonical.com/rick?authuser=1 | 17:54 |
| natefinch | sure | 17:54 |
| mup | Bug #1609910 opened: Juju API lacks version endpoint <juju-core:New> <https://launchpad.net/bugs/1609910> | 17:58 |
| natefinch | gah... gojsonschema has almost zero documentation. | 18:42 |
| katco | any juju architecture guru types around? fwereade__? | 19:46 |
| niedbalski | We are trying out beta14 and found this serious problem: http://pastebin.ubuntu.com/22225558/ | 20:55 |
| niedbalski | sinzui, alexisb ^^ is this expected? | 20:55 |
| sinzui | niedbalski: officiall we don't support that | 20:55 |
| sinzui | niedbalski: We don't even test uprades since juju is breaking behavious | 20:56 |
| niedbalski | sinzui, ok. So it might be a required to bootstrap this env again? | 20:57 |
| sinzui | niedbalski: yes :/ | 20:57 |
| niedbalski | sinzui, ok | 20:57 |
| mgz | niedbalski: yup, 'fraid so, we don't do upgrades between betas | 20:57 |
| === natefinch is now known as natefinch-afk | ||
| thumper | snow day here, kids all at home | 21:03 |
| thumper | barely 2cm of snow and the city shuts down | 21:03 |
| niedbalski | mgz, sinzui thanks guys. | 21:06 |
| mup | Bug #1609980 opened: Juju does not give a clear error when unable to create a loop device on lxd <lxd> <storage> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1609980> | 21:07 |
| === petevg is now known as petevg_vacation | ||
| === petevg_vacation is now known as petevg_afk | ||
| === petevg_afk is now known as petevg_vacation | ||
| mup | Bug #1609994 opened: Race in github.com/juju/loggo global <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609994> | 21:43 |
| mup | Bug #1609994 changed: Race in github.com/juju/loggo global <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609994> | 21:49 |
| perrito666 | now, this is new: /home/hduran/Develop/golang/go1.6.2/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory | 22:01 |
| mup | Bug #1609994 opened: Race in github.com/juju/loggo global <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged by thumper> <https://launchpad.net/bugs/1609994> | 22:01 |
| thumper | menn0: http://reviews.vapour.ws/r/5376/ | 22:05 |
| menn0 | thumper: looking | 22:05 |
| thumper | menn0: 1:1 ? | 22:07 |
| menn0 | thumper: ok | 22:07 |
| thumper | wallyworld, menn0: http://reviews.vapour.ws/r/5377/ | 22:26 |
| wallyworld | thumper: +1 | 22:27 |
| thumper | landing | 22:28 |
| thumper | seems we have no on call reviewer today | 22:36 |
| thumper | http://reviews.vapour.ws/r/5345/diff/# | 22:36 |
| thumper | menn0: http://reviews.vapour.ws/r/5369/diff/# updated to use 1500ms max dealy as discussed | 22:37 |
| menn0 | thumper: looking | 22:40 |
| menn0 | thumper: it just occurred to me that the tests could be simpler if instead of injecting a Clock, retry.Call was injected | 22:43 |
| menn0 | thumper: that way you just need to check that retry.Call is given the right args | 22:43 |
| menn0 | thumper: and the tests aren't checking retry.Call's behaviour | 22:43 |
| menn0 | thumper: not saying you need to change it, but just an idea for future work like this | 22:44 |
| * thumper nods | 22:44 | |
| thumper | that's a thought | 22:44 |
| menn0 | thumper: ship it | 22:44 |
| menn0 | thumper: does that loggo race really need to be a blocker? | 22:45 |
| menn0 | master was open when I submitted a PR but by the time it ran it was blocked again | 22:46 |
| mgz | now that's what I call a race | 22:49 |
| menn0 | mgz: haha | 22:58 |
| menn0 | thumper: I just realised that MM ids have an nice (unintentional) property: they're globally unique across all controllers (because of the was sequences are migrated) | 22:59 |
| wallyworld | menn0: when the PR lands. we'll remove the blocker tag. a race in a 3rd party lib should not stop 15 people from landing work | 23:10 |
| menn0 | wallyworld: +1 | 23:10 |
| wallyworld | menn0: the PR to update deps just got an intermittent error, i resubmitted, hopefully will land this time | 23:11 |
| mup | Bug #1610007 opened: Juju 2.0-beta14: AllWatcher deltas on unclean model do not report proper application state <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1610007> | 23:19 |
| mup | Bug #1610012 opened: can't migrate a model off a controller twice <migration> <juju-core:New for menno.smits> <https://launchpad.net/bugs/1610012> | 23:52 |
| thumper | um... | 23:55 |
| thumper | I don't think that is a bug | 23:55 |
| thumper | ok, the heading is confusing | 23:56 |
| mup | Bug #1610012 changed: can't migrate a model off a controller twice <migration> <juju-core:New for menno.smits> <https://launchpad.net/bugs/1610012> | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!