[00:50] guess who types rm -r in his home directory [00:51] axw, I have no notes, but I recall I wanted to ask how you did a full i386 test run [00:53] axw I saw timeouts in the CI runs. I am sure you fixed the tools issue. I may need to procure bare metal or try running the tests in an lxc in a m1.large amd64 [00:56] sinzui: afaik, we hard coded the arch in arch.go to i386 [00:56] so it was faked [00:58] wallyworld_, okay [00:58] wallyworld_, is there an env setting to extend the timeouts in the test suite [00:58] sinzui: one time I actually ran with i386 on canonistack [00:59] sinzui: after all my changes I only ran locally with arch faked to i386 [00:59] sinzui: you use command line arg to test [00:59] axw okay that works I have a sleve there [00:59] test.timeout of something [01:00] thank you wallyworld_ [01:00] -timeout is the raw go test arg [01:00] I think canonistack my be viable, even though I have tried to not use it [01:00] i think you need test.timeout if used with gocheck, can't recall exactly without trying [01:00] wallyworld_, thank you [01:01] anyway I need to rebuild my computer. I don't think I will accomplish much tomorrow. [01:01] sinzui: np. here's the syntax: "go test -gocheck.v -test.timeout=xxxxms" [01:01] if you use gocheck [01:02] * sinzui pastebin's that [01:02] sinzui: did we need to schedule a chat about jenkins lander for core? [01:03] wallyworld_, not just yet. I don't have time to start since I still need to get ppc tested every rev [01:03] ok, np [01:04] and the script that would build ppc64 packages just emptied my home directory [01:04] sinzui: if you like, you can give us epermission to set up a job in your jenkins and we can experiment [01:04] oh no! [01:04] At least I know the script wont fill up the stilson disk space again. [01:04] did you have backups? [01:04] Looks like I have one from 4 days ago [01:05] better than nothing, but still :-( :-( [01:05] sorry to hear that [01:05] I don't backup my work or hacking dirs. I need to rebuild my repos [01:09] sinzui: would letting giving us permission to create a new jenkins job on your instance be viable? we could then experiment and get the lander working [01:09] wallyworld_, sure [01:09] not sure how far we'll get [01:10] but still, having more potential resources to help would be positive [01:10] not that i'm in *any* hurry to leav lp [01:10] git makes me sad the more i learn about it [01:10] br is so much nicer [01:10] bzr [01:27] axw: morning, i didn't hear back from martin about how he got on looking at the TestEnsureAdminUser failure and he also hasn't assigned himself to the card. so in terms of stuff todo, there's that plus figuring out what's going on with juju on utopic. did you have any preference? [01:28] wallyworld_: I can take a look at TestEnsureAdminUser [01:28] ok, ta [01:28] that test has been failing a lot [01:29] wallyworld_: how'd you go with the PRs to joyent? [01:30] axw: we now have a committment that they will look at them in the next day or so [01:30] cool [01:30] so, i'm budgetting for eow by the time it goes around [01:51] tiny change https://codereview.appspot.com/100580045/ [02:35] davecheney: lgtm, if the readme file is in that directory :) [03:05] review please: https://codereview.appspot.com/92520043/ (new "user" supercommand) [03:48] Is it best to always post here when a new codereview is up? [03:49] A proposal for a bug fix [03:56] jimmiebtlr: seems to work well to get people to look at it if it is urgent [03:56] any members of juju-core will get an email that the code review is reday [03:56] actually, they'll get a lot of mail [03:57] Nothing urgent [03:58] low priority bug, just getting a feel for committing fixes [03:59] jimmiebtlr: i haven't seen anyting coming through email [03:59] do you have a link to the code review ? [03:59] https://codereview.appspot.com/98410043/ [04:00] jimmiebtlr: toptip: [04:00] lbox propose -bug=1313793 to link the review to the bug [04:00] you can do this now [04:00] and it will do the linkage [04:02] that returned an error "User does not have sufficient permission to edit the bug task milestone" [04:10] jam: wallyworld_ can you fix this ? [04:10] hmmm, maybe. but we don't want to open permissions to change any milestone [04:11] might be that lbox needs looking at to see what it is trying to do [04:12] i wonder if it can be linked via the lp gui [04:14] Are you referring to the codereview being linked to the bug, or the branch being linked to the bug? [04:17] branch -> bug [04:18] the code review will then pick up the link [04:19] I linked the branch and the bug via the lp gui several days ago [04:20] or related it anyway [04:25] hmm, ok. looks like it all went through ok in any case [04:26] i suspect an issue with the lbox code trying to do something unexpected/unneeded but can't be sure without digging into it [04:29] thanks for the help, I'm off [05:39] protip: if you want to do a proposal, but aren't sure what the total diff will look like [05:39] you can use the lbox -wip flag to get a proposal and not mail it === vladk|offline is now known as vladk === vladk is now known as vladk|offline [06:16] yay for protip [06:16] what about bzr missing? [06:21] if I do an lbox propose, and then get feedback and make changes, should I do another lbox propose to propose the updated changes? [06:22] fwereade, mgz ? ^^ [06:24] Technically, this is a 503 error and has been caused by our database being temporarily offline. [06:24] sad trombone [06:24] jcw4: just do lbox propose [06:24] again [06:25] jcw4: you are always proposing a branch, not a patch [06:25] so propose will always roll up your commits [06:25] so [06:25] bzr commit -m '...'; [06:25] until you are happy [06:25] then lbox propose to ask people to take another look [06:25] davecheney: cool, tx! [06:30] mgz, fwereade updated the MR: https://codereview.appspot.com/98260043/ [06:31] * jcw4 is off to bed... early morning meeting at 1400 UTC [06:31] :) === Beret- is now known as Beret [08:03] morning all [08:05] voidspace, heyhey [08:08] morning from a sunny veranda too ;) [08:09] we just had the most incredible downpour of rain and thunder for about half an hour [08:09] and now we're back to sun [08:10] we even had some rain here yesterday === vladk|offline is now known as vladk [08:25] morning voidspace [08:26] fwereade: https://codereview.appspot.com/93500044 is changing Resource to allowed named resources, and changing Pinger to use that functionality. [08:26] * fwereade bbiab [08:26] Its independent of my other API changes. [08:26] jam, sorry, I'll take a look when I get back [08:26] fwereade: np, no rush [08:27] dimitern: you're welcome to look at ^^ as well, it is part of my changing of Facades to be versioned. [08:27] not directly related, but a necessary precursor to unifying how Facades are created. [08:27] jam, will look in a bit, thanks [08:46] dimitern: morning [08:46] jam: morning to you too [08:47] hey voidspace! [08:48] dimitern: how's life? [08:49] voidspace, not bad at all :) i wish the weather was so good [08:49] voidspace, how was the grand canyon? [08:49] dimitern: the grand canyon was spectacular, really amazing [08:50] dimitern: I posted my pictures of our shooting expedition and the grand canyon on flickr [08:50] voidspace, nice, I'll check them out [08:50] dimitern: https://www.flickr.com/photos/mfoord/sets/ [08:50] dimitern: I didn't get a picture of us both together at the shooting, shame :-/ [08:50] voidspace, I still haven't got to posting some pictures yet [08:50] dimitern: it was awesome though, one of the highlights of the trip for me [08:51] voidspace, yeah, but the photos otherwise kick ass ;) [08:51] dimitern: hehe, yep - and the videos [08:53] voidspace, indeed [08:53] voidspace, next time - shotguns ;) [08:54] dimitern: hehe, fair enough :-) [08:54] I've shot a shotgun before, clay pigeon shooting (once). I was getting the hang of it too. [08:54] all the guns we shot were fun. [08:56] yep, unexpectedly for me, it *was* fun [09:24] morning [09:25] perrito666: morning [09:46] dimitern: fwereade: A followup which uses a Named StringResource to register "dataDir" so that Client's Facade constructor looks like all the other Facades: https://codereview.appspot.com/99410043 [09:46] jam, looking [09:46] dimitern: did you look at the earlier patch? I didn't see a comment from you [09:47] jam, no, sorry got caught up deep in goamz stuff [09:47] np, just figured you might want to look at that first [09:48] jam, LGTM, i'm looking at the prereq now [09:48] jam: I’m mostly happy with the document now, so I would like you to take another look. I’ll start with the table now. [09:49] TheMue: do you have specific questions for me, or you just want me to audit the whole doc? [09:49] morning folks - does this look odd or normal: https://bugs.launchpad.net/juju-core/+bug/1321212 [09:49] <_mup_> Bug #1321212: Odd behaviour when using ensure-availability [09:50] jam: a quick audit of the whole doc. I think everything is now clean and the open questions have been discussed yesterday. [09:51] mattyw: try running "juju bootstrap" and then "juju status" and then a loop of "juju status". You can check what the first line in ~/.juju/environments/$ENV.jenv says are the API servers. [09:51] jam, the prereq LGTM as well [09:52] There *was* a bug that it was getting all the possible API server endpoints listed (and one of those is MachineLocal's 127.0.0.1) which is obviously not an address we want to store in clients [09:52] I would *guess* that this isn't because of ensure-availability, but because of First Login issues [09:52] mattyw: you could also try "juju status --debug" to see what addresses it is trying to connect to [09:53] the really weird part is that 127.0.0.1:37017 looks like it is fallback code (we should never usually try to connect to 37017 which is the DB port) [09:53] jam, ok thanks - I "sort of" remember that stuff, I'll take another look === vladk is now known as vladk|offline [09:59] brb, grabbing coffee [10:03] jam: doesn't look like natefinch is around yet [10:03] voidspace: yeah, I'm a bit surprised he picked that early for him, but when he comes around we'll chat [10:04] jam: cool :-) [10:11] question about our watcher architecture [10:11] suppose a client has a watcher on something (say environ-config changes for example) [10:11] and three changes occur before the client makes a "Next" request [10:12] will the subsequent two "Next" requests return *immediately*, or will the next "Next" wait for *another* change? [10:12] does the apiserver maintain a queue of changes for watchers? [10:13] voidspace: they get collapsed, I believe the Watcher collapse interval is 5s [10:14] so if there are 3 changes within 5s, then you only get 1 Next() event [10:14] jam: ok [10:14] what if there are 3 events each 5 seconds apart, and *then* the client makes a Next call - are they all collapsed too? Or is the collapse interval a *maximum* of five seconds. [10:15] voidspace: I'm pretty sure we don't maintain a "you have X events ready" we just have "something has changed" so a single bit [10:15] right - so they're collapsed all the time, but also "close" events are collapsed automatically anyway [10:15] so the watchers have a minimum granularity of 5 seconds [10:16] thanks [10:29] jam, have you got a moment? [10:29] mattyw: what's up? [10:30] jam, tasdomas and I are working on adding output to ensure-availability so it prints what it's doing [10:31] sure [10:31] at the moment we're changing the ensureavailbilityintent struct (addmachine.go:616) to be exported, but we'd have to make all of the values in it exported as well [10:32] but that seems a bit odd since you don't really want to be able to change any of the values within ensureavailbilityintent one at a time [10:32] nate suggested we could ask you these kind of questions in his absense - just wondered if you had an opinion? [10:34] mattyw: looking into it [10:35] mattyw: so from what I see, there is just 4 lists of Machines that we are operating on, but we don't want to actually have the Machine objects themselves in the API [10:35] rather, we should probably just expose lists of machine-tags [10:36] mattyw: so I'm thinking we shouldn't just make that type exposed, but create a new params.EnsureAvailabilityResult (Intent, Actions, ... ?) [10:36] jam, the apiserver was going to convert this type into a Results type anyway === vladk|offline is now known as vladk [10:38] mattyw: so... exposing the attributes is fine, they are all intended as Readonly anyway, and actually changing them doesn't have any actual effect. [10:39] however, we have precedent for state could just return the polished up params.EnsureAvailabilityResults itself [10:39] and then we don't have to expose raw Machine entities to apiserver/client code. [10:39] we *can* do it with that layering [10:40] certainly the AddMachine api works in real Machine objects and then wraps the data into returning the Id(), though *really* *really* AddMachine should be returning Tags not Ids [10:41] the API talks in terms of Tags [10:41] the internals talk in terms of Ids [10:41] time for an AddMachinesV3 :) [10:42] jam, I like the idea of the params.params.EnsureAvailabilityResults [10:45] jam, standup? [10:45] dimitern: yeah, brt [11:20] voidspace: looks like natefinch didn't make it online before his wife's dentist appointment [11:20] I have to work on my son's homework in a bit, but I can chat with you after that. [11:36] lunchtime, ended exactly when my wife called ;) === vladk is now known as vladk|offline [11:40] jam: ok [11:41] jam: if you're not around we can postpone appropriately [11:41] jam: don't hang around on my behalf [11:55] fwereade: hey, I am implementing what we spoke yesteday, about ServerInstances, the get/set methods you suggested should operate against Storage right? [11:55] perrito666, not necessarily [11:55] perrito666, we want them to be Environ method === vladk|offline is now known as vladk === vladk is now known as vladk|offline [11:56] perrito666, but we also need a common implementation that most environs can use to implement them === vladk|offline is now known as vladk [11:56] perrito666, and that would take a storage and keep working the same as before [11:56] perrito666, the important thing really is that those Environ interface methods *not* metion storage [11:56] perrito666, am I sounding sane? [11:57] fwereade: most of the time [11:57] perrito666, how about in the last 2 minutes? [11:57] sane enough :) tx [11:57] perrito666, cool :) [11:58] what still bothers me a bit is that everywhere seems to be implying that the current storage Should already have that info [11:59] * perrito666 looks the rain outside and smiles on his non commuting job [12:01] perrito666, that is still true [12:01] perrito666, which is why almost everything should use that method [12:01] hello [12:02] perrito666, pretty sure that manual and local will be different to some degree, though [12:02] fwereade: expected [12:02] perrito666, and more to the point, we will soon have to deal with some cloud that *doesn't* have storage [12:03] fwereade: I see [12:03] perrito666, (also, wallyworld_ is moving storage into gridfs soon as well -- so we'll be dropping storage from Environ anyway) [12:04] ok then, I should assume storage is not there for my new methods and then do everything use those [12:06] lunch [12:14] perrito666, yeah, all the implementations will use storage, but the interface shouldn't mention it [12:15] * fwereade should have known the "JoinedRelations" API method was a bad idea, because it should now be "RelationsInScope" [12:15] * fwereade kicks himself a couple of times [12:15] * fwereade can't wait for the versioned API [12:21] hi, can someone see what's wrong with the simplestreams in this bug, it was produced by juju's 1.19.2 metadata command, and can't bootstrap [12:21] https://bugs.launchpad.net/juju-core/+bug/1321009 [12:21] <_mup_> Bug #1321009: juju-metadata doesn't produce content that bootstrap can use

[13:12] sinzui: hi, the failing trusy tests can't run bzr, i have no idea why off hand, bzr add results in an error [13:12] ... Panic: command failed: bzr add [13:12] (PC=0x4143E6) [13:12] i haven't seen that before [13:12] looks like it's external to juju? [13:13] the PC=xxxx is from the br add output [13:13] bzr [13:13] ahasenack: i commented on your bug - i think you just need to delete your old jenv file and/or first destroy your existing environment [13:13] wallyworld_, :( I see this hack is still in place when CI prepares [13:13] bzr whoami 'J. Random Hacker ' [13:14] that jrandom doesn't look like it comes from juju [13:18] wallyworld_: ok, will try, thanks === cory_fu2 is now known as cory_fu [13:33] niemeyer, hey [13:33] dimitern: Hey hey [13:34] niemeyer, I have a small review for you if you can spare 10m - https://codereview.appspot.com/98430044/ (for goamz) [13:34] jam, vladk, fwereade, ^^ another review appreciated [13:35] wallyworld_: same problem, let me paste [13:35] dimitern: Not exactly a *small* review, but will surely look :) [13:35] niemeyer, :) thanks [13:35] wallyworld_: http://pastebin.ubuntu.com/7492988/ [13:36] dimitern: At a glance, it's easy to tell the code is under-covered by tests [13:36] dimitern: Maybe that's okay, given that the fake server itself is meant to be the test [13:36] dimitern: (how far do we test the test) [13:37] niemeyer, I've included the most important parts for juju in the tests [13:46] dimitern: Why do we have the rest of the logic in the fake server if it's not relevant? [13:49] niemeyer, which logic? [13:50] dimitern: You said you've included the most important parts for juju in the tests [13:52] niemeyer, yes - that is the assumption in juju that all instances have 1 nic after launching [13:55] dimitern: Not sure about how that reflects into the above points [13:56] voidspace: wwitzel3 could anyone of you jump into the moonstone channel? I am trying to set up my hangout [13:56] niemeyer, well, i've always assumed the test server should (when possible) mimic ec2 as close as possible [13:57] perrito666: ok [13:57] niemeyer, what do you think needs more test coverage? [13:59] dimitern: I'm mainly wondering about what you were saying.. I said there's certainly a good portion of untested logic in the server, given how extensive the code is and how slim the tests are [13:59] dimitern: then you said something along the lines of "what matters for juju is tested" [13:59] dimitern: and my question was "why do we have anything that does not matter for juju in there"? [14:00] niemeyer, ok, let's backtrack a bit, sorry [14:01] niemeyer, imho it doesn't make sense to implement "create a default network interface when none given in RunInstances" and not do "create/use network interfaces if specified in RunInstances" [14:01] Hi guys I am seeing an SSLError from deployer when I try to run some amulet tests. http://pastebin.ubuntu.com/7493011/ [14:01] mbruzek, update your version of jujuclient [14:01] niemeyer, the code it almost the same in both cases [14:02] niemeyer, and the tests indeed cover those 2 cases - the implementation is actually longer than the tests need to be I think [14:02] hazmat, python-jujuclient is already the newest version. [14:03] mbruzek, are you pulling things from pypi or from packages? [14:03] niemeyer, there are very few changes in behavior not really tested - like "ensure you can't launch more than 1 instance when you specify an existing NIC ID" [14:03] mbruzek, if you pull from packages it should be fine, but if you start mixing in some from both there's a python-websocket default behavior change in ssl cert verification that needs a corresponding version change. [14:04] niemeyer, or a test that creates 2 NICs [14:04] mbruzek, what version? [14:04] mbruzek, pip -U python-jujuclient [14:04] to upgrade [14:04] hazmat no such option: -U [14:04] niemeyer, on the same instance, but it is supported, I can add a second RunNetworkInterface item to RunInstances and it will do/test that [14:05] hazmat it looks like 0.17.5 is the version I have [14:05] $ pip freeze | grep jujuclient [14:05] jujuclient==0.17.5 [14:05] dimitern: I somewhat doubt that, given the sheer volume of logic in the code which is not represented in the tests [14:05] mbruzek, can we move this to #eco [14:05] dimitern: But as I said, I'm won't argue much.. this is test code being tested [14:06] I won't === hatch__ is now known as hatch [14:06] niemeyer, yes, it is test code [14:06] niemeyer, but I'll be happy to add more tests if you have something particular in mind [14:07] dimitern: I have everything there in mind :) [14:08] niemeyer, :) [14:08] dimitern: Lots of these lines are unchecked [14:08] dimitern: I'm not going to go over the trouble of telling you every single one [14:08] dimitern: If you really care, you might go over the diff and check yourself [14:09] niemeyer, I'll look some more into it, thanks [14:16] thanks fwereade [14:16] fwereade, wasn't sure if there was any more you wanted to add, but everyone dropped off :) [14:17] wrt. Txn loop: you had sent me some example code which I subsequently misplaced.... [14:17] jcw4, bodie_: I'd be keen to talk about txn loops -- mgz, not sure if you've delved deeply there before? [14:17] jcw4, heh, no worries, I'll look that up again -- or, tell you what, I'll do a quick comment on your CL if you send me the link again [14:17] fwereade: +1 [14:17] my only knowledge is that it's a technique essentially for pipelining State's database queries and upserts through a single port of authority [14:18] fwereade: https://codereview.appspot.com/98260043/ [14:18] jcw4, bodie_, mgz: a live chat might be worthwhile then, I'll find the comment I did for perrito666 [14:18] voidspace: apparently https://bugs.launchpad.net/ubuntu/+source/linux/+bug/950490 [14:18] <_mup_> Bug #950490: External microphone does not work on Zenbook UX31

[14:19] perrito666: ah, so it maybe Ubuntu's fault [14:19] alsa, actually [14:19] fwereade, do you have some time for a goamz review? https://codereview.appspot.com/98430044/ [14:19] perrito666: I have a similar issue - when you have any alternative audio input source the "line in" is no longer available to select [14:31] how can i specify a constraint in a bundle? [14:34] niemeyer, In any case, I'd appreciate your review [14:34] dimitern: Have been doing it since [14:34] dimitern: The "10 minutes" :) [14:35] niemeyer, thanks! :) [14:39] dimitern: https://codereview.appspot.com/98430044/ [14:39] niemeyer, cheers! === Ursinha is now known as Ursinha-afk [14:42] dimitern: np, please let me know how you feel about these [14:44] niemeyer, will do === Ursinha-afk is now known as Ursinha === vladk is now known as vladk|offline [15:09] marcoceppi: super trivial charm-tools review at https://codereview.appspot.com/98390047 when you have time [15:12] bac: thanks! [15:39] fwereade: yay, Client and Pinger are now no longer special in "api-use-register-standard-facade" so now everything is *just* another Facade with a similar factory. [15:40] * fwereade cheers [15:42] niemeyer, updated https://codereview.appspot.com/98430044/ with most of your suggestions, and added some replies [15:43] * dimitern reached EOD [15:54] hi [15:56] I am getting a test failure in cmd/juju/machine_test.go:253 [15:57] (on trunk) : http://paste.ubuntu.com/7493538/ [16:01] fwereade: 6pm too late to discuss txn loop? [16:01] jcw4, that's fine [16:02] jcw4, was that link remotely relevant, or missing too much context? [16:02] fwereade: I reviewed and looks interesting.. one question [16:02] fwereade: should I build the ops in the loop? [16:02] fwereade: I assume so [16:02] fwereade: generate the Id outside the loop but everything else inside? [16:03] jcw4, yeah, exactly [16:03] fwereade: and is there a specific reason for 3 iterations? [16:03] jcw4, it may not *always* be necessary to do so, but it's generally the right thing to do [16:03] fwereade: k [16:03] jcw4, none whatsoever [16:03] fwereade: ok... Shall I start with 3? [16:03] jcw4, some use 5; some use fewer because we can guarantee that >2 implies something wrong [16:03] jcw4, sgtm [16:04] fwereade: makes sense [16:04] jcw4, at some point I'll probably get round to a generalised txn build/run/backoff-retry thing [16:05] fwereade: ok. also, if the txn completes successfully we just break out of the loop right? [16:05] jcw4, better yet, if err != txn.ErrAborted { return err } [16:05] jcw4, that covers both success and surprising failures like dropped connection [16:06] fwereade I see. so on success err will be nil therefore we return nil error [16:06] jcw4, yeah [16:06] fwereade: and if its anything else but ErrAborted we return the suprising error [16:06] fwereade: and if the failure is ErrAborted we just try again [16:06] k [16:07] jcw4, yeah, just try to build a fresh txn against whatever state needs to be updated [16:07] jcw4, in your case, check the unit's life again [16:07] fwereade: until we finish the loop, and if we get there we return ErrAborted? [16:07] fwereade: ok [16:07] jcw4, fall out of the loop and return ErrExcessiveContention [16:07] fwereade: perfect [16:08] jcw4, although what that *really* means in every case I have yet seen is "some programmer ballsed things up" [16:08] jcw4, one detail [16:08] fwereade: hehe [16:08] jcw4, you'll want to clone the unit rather than Refresh() it in the loop [16:09] jcw4, we prefer not to update fields whose update isn't implies by the op you're running [16:09] fwereade: hmm. Okay [16:09] jcw4, ie you should be able to call a bunch of methods in a row and not have to worry about in-memory state changing underneath you [16:09] jcw4, (although if you SetFoo you do expect foo to be set) [16:10] fwereade: I think I get it. I should be able to code this part up fairly quickly... I forget where the example of how to test txn loop stuff was though [16:10] fwereade, jcw4, I'm worrying about the technique I'm using to validate the actions.yaml as valid json-schema [16:11] right now, our actions.yaml is relatively simple, as specified in the MR [16:11] jcw4, the funcs are defined in export_test.go -- SetTransactionHooks et al [16:11] fwereade: right. tx! [16:11] it appears to parse as valid json-schema, but i'm looking at the json-schema spec right now and, among other things it requires a root level key of $schema [16:11] which isn't present in my actions.yaml [16:12] jcw4, searching for Hooks in the state package should get yu plenty of examples [16:12] fwereade: +1 [16:12] bodie_, hmm, can you get it to fail at all? :) [16:12] it could be that it's returning an empty json-schema, and i'm not checking for that. i guess that's the point i need to dig down to [16:12] or, perhaps simply loading a k/v map as a jsonschemadoc isn't sufficient to validate it [16:13] bodie_, the examples on json-schema.org don't necessarily include that [16:13] http://json-schema.org/latest/json-schema-core.html#anchor23 [16:13] good point [16:14] in that case, I don't understand the use of "MUST" in this spec ;) [16:14] bodie_, "MUST if you feel like it ehh who cares" [16:14] MUST be optional [16:14] :/ [16:15] AH [16:15] ah* I misread it [16:16] IF it exists, it must be at the root; it is "RECOMMENDED" that schema authors include this keyword [16:16] need to beef my reading comprehension. Go is making me lazy.... [16:16] bodie_, ah cool [16:17] order matters in short-circuit evaluation of English clauses... [16:17] I guess I'm having a hard time thinking of valid YAML that isn't also valid JSON-Schema [16:19] bodie_, stick a $schema key in *not* at the root :) [16:19] good one [16:22] tasdomas, yeah, that's clearly a real problem, good that you can repro [16:24] * fwereade beholds the horror that is cmd/jujud and sighs heavily [16:24]