| wallyworld_ | perrito666: from argentina, the electrons have so much further to go, and they get tred and need at rest in miami | 00:00 |
|---|---|---|
| perrito666 | that must be it, or the fact that the country has only one freaking connection to the outside world | 00:01 |
| perrito666 | it is a shame that when I am in countries with good internet Is always countries where bittorrent is illegal | 00:02 |
| wallyworld_ | it's illegal here too, doesn't stop me | 00:02 |
| perrito666 | wallyworld_: its legal in argentina | 00:03 |
| wallyworld_ | and in holland, it's not illegal to download, only upload | 00:03 |
| perrito666 | wallyworld_: for what I heard in France is "we send you the police" illegal | 00:03 |
| bigjools | bt is illegal??? | 00:03 |
| wallyworld_ | perrito666: you serious??? wtf | 00:03 |
| bigjools | it's illegal to download pirated stuff but not illegal to use | 00:04 |
| perrito666 | bigjools: yeah that is what I meant | 00:04 |
| katco | these countries give bt a 1:1 with pirating? that is rediculous... | 00:12 |
| perrito666 | nono I meant bt for things like movies | 00:14 |
| perrito666 | the fun thing is, I actually have an account in a digital movies service :p I just dont know my creds | 00:14 |
| perrito666 | It comes with my internet+cable subscription | 00:15 |
| bigjools | well there's better places to get this stuff than BT nowadays *cough* | 00:15 |
| * perrito666 sms his wife to get the creds for his service | 00:17 | |
| katco | wallyworld_: does juju have a concept of in-memory services (overloaded term: not juju services, but a SoA service) i could reference? | 00:18 |
| katco | wallyworld_: i want to have only 1 instance of the lease manager running | 00:19 |
| wallyworld_ | katco: we sorta do that using a worker | 00:19 |
| wallyworld_ | the state server starts named workers | 00:19 |
| wallyworld_ | each worker can host a service | 00:20 |
| katco | wallyworld_: is that pattern worth repeating? | 00:20 |
| wallyworld_ | yes, it's what we use right at the moment | 00:20 |
| katco | wallyworld_: cool, ty sir. maas | 00:20 |
| wallyworld_ | np. it fits with current practice, and works | 00:20 |
| bigjools | katco: ping | 00:20 |
| katco | bigjools: hey, how can i help you? | 00:21 |
| bigjools | katco: unping | 00:21 |
| wallyworld_ | the service can be written indeoendent of the worker | 00:21 |
| bigjools | oops :) | 00:21 |
| katco | lol | 00:21 |
| wallyworld_ | the worker glues the service into the state server | 00:21 |
| wallyworld_ | katco: just say MAAS to get him back | 00:21 |
| katco | bigjools: you have a very maas day :) | 00:21 |
| wallyworld_ | lol | 00:21 |
| bigjools | /ignore wallyworld_ | 00:22 |
| katco | wallyworld_: ah ok. b/c the apiserver instantiates a new object for every api call, i need to get a singleton of some sort at init time | 00:22 |
| wallyworld_ | katco: that's the remoting layer | 00:23 |
| katco | wallyworld_: because i think we want the leasing service to handle synchronization in memory | 00:23 |
| wallyworld_ | and yes, i disagree with that implementation. but think of it like a session | 00:23 |
| katco | wallyworld_: right, it's the remoting layer. but at the time the leadership remote layer gets instantiated, it has to know about the single lease service | 00:24 |
| wallyworld_ | the service should be stateless, so it could instantiate a new lease service fascade. or else rely on the fact that a lease service work (only one) has been run | 00:25 |
| wallyworld_ | maybe easier to discuss face-face | 00:26 |
| katco | wallyworld_: since the ctor requires a specific signature, i'm going to use a closure to make it a bit more clear where the lease service reference is coming from | 00:27 |
| katco | wallyworld_: yeah probably, maybe at the stand-up | 00:27 |
| wallyworld_ | ok | 00:27 |
| katco | wallyworld_: or actually i have time now, daughter just being put to bed | 00:27 |
| katco | wallyworld_: if you're free | 00:27 |
| wallyworld_ | sure, let's meet in standup hangout | 00:28 |
| katco | okie doke | 00:28 |
| katco | that sounds maas to me | 00:28 |
| katco | i mean nice. nice to me. | 00:28 |
| bigjools | /ignore katco | 00:33 |
| === arosales_ is now known as arosales | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| perrito666 | ericsnow: ok, I got rid of finish restore :) | 01:20 |
| perrito666 | tomorrow preparerestore | 01:20 |
| perrito666 | but for now sleep | 01:20 |
| ericsnow | perrito666: sweet! | 01:20 |
| perrito666 | its 2am here | 01:20 |
| ericsnow | perrito666: sleep! | 01:21 |
| === kadams54 is now known as kadams54-away | ||
| ericsnow | menn0: could you take one more look at http://reviews.vapour.ws/r/268/? | 02:14 |
| ericsnow | menn0: I've addressed all review feedback | 02:14 |
| ericsnow | menn0: it should be good to go | 02:14 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| menn0 | ericsnow: ok will do. but not for an hour or so. | 02:22 |
| ericsnow | menn0: no worries | 02:22 |
| ericsnow | menn0: I'm probably EOD pretty soon so no hurry | 02:22 |
| menn0 | ericsnow: kk | 02:22 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | fwereade: got a few minutes? | 07:06 |
| === liam_ is now known as Guest91925 | ||
| fwereade | wallyworld, heyhey | 08:13 |
| wallyworld | fwereade: hi, i would love to check a few things regarding the health status spec, but dinner is almost ready, can i ping you soon? | 08:14 |
| fwereade | wallyworld, ofc | 08:14 |
| wallyworld | ta, will get back to you | 08:14 |
| wallyworld | fwereade: ok to talk now? 1:1 hangout | 08:40 |
| fwereade | wallyworld, with you in a minute | 08:42 |
| wallyworld | no hurry | 08:42 |
| fwereade | wallyworld, can you hear me? | 08:54 |
| fwereade | wallyworld, Iguess not | 08:54 |
| fwereade | wallyworld, endpoint: --waiting-for=db | 08:54 |
| wallyworld | no | 08:54 |
| wallyworld | sound died | 08:54 |
| fwereade | wallyworld, relation: --waiting-for=db:3 | 08:54 |
| fwereade | wallyworld, unit: --waiting-for=db:3:mysql/2 | 08:55 |
| fwereade | wallyworld, rejoining | 08:55 |
| jam | fwereade: wallyworld: are you guys in a hangout about the "juju status" doc? (I see editing going on while I'm commenting) | 09:09 |
| fwereade | jam, just finished | 09:09 |
| wallyworld | jam: we were, but fwereade has a sucky connection | 09:09 |
| fwereade | jam, my hangout keeps dying :/ | 09:09 |
| mattyw | morning all | 09:12 |
| voidspace | hey guys, IS have a problem with juju in #is-outage | 09:27 |
| voidspace | this is the error they have https://pastebin.canonical.com/119944/ | 09:28 |
| voidspace | do we still redirect (and throw away) mongo logging? | 09:28 |
| rogpeppe | fwereade: fancy having a look at this, touching on some of what we chatted about yesterday? https://github.com/juju/charm/pull/73 | 09:37 |
| dimitern | anyone available for a review on http://reviews.vapour.ws/r/349/ ? | 09:37 |
| voidspace | dimitern: jam: you ever seen this mongo error (or similar)? | 09:38 |
| voidspace | Wed Nov 5 09:13:37.209 Error: DBClientBase::findN: transport error: 127.0.0.1:37017 ns: admin.$cmd query: { whatsmyuri: 1 } at src/mongo/shell/mongo.js:147 | 09:38 |
| fwereade | rogpeppe, based on the description I have no problem with that | 09:38 |
| dimitern | voidspace, nope :/ | 09:38 |
| jam | voidspace: I have not | 09:38 |
| fwereade | rogpeppe, gonna be a beast to integrate it with core though | 09:39 |
| rogpeppe | fwereade: i don't think so | 09:39 |
| voidspace | dimitern: jam: IS have lots of mongo timeouts on a production server | 09:39 |
| rogpeppe | fwereade: i've actually already made the changes | 09:39 |
| fwereade | rogpeppe, sweet | 09:39 |
| rogpeppe | fwereade: the first step is just to copy the entire repo into juju code (inside github.com/juju/juju/testing/charm-repo | 09:39 |
| rogpeppe | ) | 09:39 |
| fwereade | rogpeppe, heh, that makes it easier then ;p | 09:40 |
| jam | fwereade: wallyworld: "what is the "mroe subt" in the title" ? | 09:40 |
| rogpeppe | fwereade: then change all tests to use testing.Charms rather than charmtesting.Charms | 09:40 |
| voidspace | dimitern: jam: restarting the the jujud-machine-0 service seems to have helped a bit anyway | 09:40 |
| jam | wallyworld: also, can we call the document something other than "Juju Status"? Since that is a thing that we have which is not this ? | 09:40 |
| rogpeppe | fwereade: subsequent changes can trim down the repo and make extra repos where appropriate | 09:40 |
| rogpeppe | fwereade: the salient changes in that PR are right at the end, BTW | 09:40 |
| fwereade | jam, heh, I think it's some mistargeted typing | 09:40 |
| dimitern | voidspace, hmm.. it looks like a heavy load issue | 09:41 |
| fwereade | jam, maybe mine | 09:41 |
| wallyworld | jam: yeah fixed, cursor fail | 09:41 |
| jam | thanks | 09:41 |
| jam | wallyworld: "Juju Charm Status" comes to mind | 09:41 |
| voidspace | dimitern: thanks, they're happy (well, less unhappy) for the moment | 09:42 |
| wallyworld | sure | 09:42 |
| rogpeppe | fwereade: i haven't got all tests compiling yet though - the main obstacle is finding a decent pair of identifiers when importing both github.com/juju/juju/testing and github.com/juju/juju/juju/testing :) | 09:42 |
| * fwereade twitches gently | 09:42 | |
| rogpeppe | perhaps coretesting and jujutesting, but i'm not that happy about that | 09:43 |
| dimitern | jujujujutesting and jujutesting - what's wrong with these :D | 09:43 |
| dimitern | coretesting and corejujutesting | 09:43 |
| dimitern | even better :) | 09:43 |
| rogpeppe | dimitern: "core" isn't really a thing any more | 09:43 |
| dimitern | juE3testing ? | 09:44 |
| rogpeppe | dimitern: it would've worked if it was github.com/juju/juju-core | 09:44 |
| dimitern | rogpeppe, heh, sorry - I'm just happy all my tests pass finally :) | 09:44 |
| rogpeppe | dimitern: cool | 09:44 |
| rogpeppe | dimitern: are commits still blocked on critical bugs, BTW? | 09:45 |
| dimitern | rogpeppe, according to my handy bookmarklet, no: https://bugs.launchpad.net/juju-core/+bugs?field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL | 09:45 |
| * rogpeppe thinks that when the critical bugs are fixed, the 'bot should go through all the PRs it denied because of that, and retry them | 09:45 | |
| rogpeppe | dimitern: thanks | 09:46 |
| rogpeppe | dimitern: ha, i tried to bookmark that, and discovered that not only had i bookmarked it, it was on my bookmarks bar as "juju-core blocks"! | 09:47 |
| dimitern | rogpeppe, hehe, I assume you'r using firefox then | 09:47 |
| rogpeppe | dimitern: nope, chrome | 09:47 |
| dimitern | rogpeppe, ah, sorry chrome has this now as well yeah | 09:48 |
| jam | wallyworld: so I made a bunch of comments, but I hope they feel constructive rather than critical. The only thing I'm actually concerned about is that we poll to find the current status, when to be useful it needs to be more "lively" than that. | 09:49 |
| jam | (my service is down, wtf is wrong, "juju status", nope everything is ok for 5 more minutes until we wake up to check) | 09:50 |
| TheMue | morning | 09:50 |
| jam | morning TheMue | 09:50 |
| wallyworld | jam: i think they are constructive, thank you. i didn't interpret as critical. i'd rather answer many questions and make a better spec. the charm calls status-set in a hook, so i'm not sure of a way other than polling where a status can be communicated, once the charm is up and running | 09:52 |
| jam | fwereade: wallyworld: I'd like william's input here, maybe "juju-run" is the escape hatch? But I do think we need a way that essentially a running application (postgres) can trigger data being sent to the Juju API server. | 09:53 |
| wallyworld | bbiab, dessert time | 09:53 |
| jam | wallyworld: sounds yummy | 09:53 |
| voidspace | dimitern: so, my final conclusion was that testing AssignPrivateIPAddresses with the mock server is not possible (in any useful way) | 09:54 |
| voidspace | dimitern: so I'm mocking it | 09:54 |
| dimitern | voidspace, because of the needed changes to RunInstances ? | 09:55 |
| voidspace | dimitern: no, I got past that | 09:55 |
| voidspace | dimitern: setting a mock server default-vpc as an initial parameter adds a network interface | 09:55 |
| voidspace | dimitern: but with the mock server you can't get it to simulate error conditions | 09:55 |
| dimitern | voidspace, yeah? | 09:55 |
| dimitern | voidspace, for IPLimitReached etc ? | 09:56 |
| voidspace | dimitern: correct, or address already assigned | 09:56 |
| voidspace | dimitern: I've looked through the code | 09:56 |
| voidspace | dimitern: and when it does work, you can't test what it did - because I don't have access to the EC2 instance to fetch the network interface back | 09:57 |
| voidspace | dimitern: and it doesn't show on the Instance which I can reach via the mock server | 09:57 |
| dimitern | voidspace, ok, so for now mocking is fine, and later we can extend the test server in goamz to reply as needed to allow better testing | 09:57 |
| voidspace | dimitern: right | 09:58 |
| jam | voidspace: dimitern: is there a reason to start with mocking rather than start with extending? | 09:59 |
| jam | It feels like if we want to do is have it in the goamz test server | 09:59 |
| jam | then we're doing extra work by also doing it via mocking | 09:59 |
| voidspace | jam: well, we can make the error conditions testable - but with a black box test it still seems hard to test the happy path | 09:59 |
| voidspace | jam: although that maybe just that I haven't found the right "trick" | 10:00 |
| voidspace | jam: what the call to ec2Inst.AssignPrivateIPAddresses should do is add the requested IP to the NIC | 10:00 |
| voidspace | jam: to get the NIC back I need access from the test to an authenticated EC2 instance to fetch the network interface | 10:00 |
| voidspace | jam: and the auth credentials are buried | 10:00 |
| jam | voidspace: doesn't that just mean that it records it enough such that listing it shows the IP? | 10:00 |
| dimitern | jam, voidspace, considering we don't really implement yet the subnet range tracking of IPs, mocking it for now and extending goamz later seems a good step | 10:00 |
| voidspace | jam: "listing it" is the issue | 10:01 |
| jam | voidspace: dimitern: standup | 10:01 |
| jam | didn't mean that to sound quite so much like an order :) | 10:01 |
| voidspace | :-) | 10:01 |
| voidspace | but it is | 10:01 |
| voidspace | ;-) | 10:01 |
| jam | voidspace: would you like to join us in the standup hangout now ? | 10:01 |
| jam | :) | 10:01 |
| fwereade | jam, wallyworld: yeah, I see juju-run as the way the system can feed backinto itself | 10:06 |
| wallyworld | fwereade: isn't juju-run being deprecated for actions? | 10:08 |
| jam | fwereade: wallyworld: is it just that we add that as a discussion point in the spec? Should we try to encourage use of that instead of polling ? | 10:08 |
| fwereade | wallyworld, jam: "juju run" may well be | 10:09 |
| wallyworld | polling is a safety net so to speak | 10:09 |
| fwereade | wallyworld, jam: "juju-run" is not going anywhere | 10:10 |
| jam | wallyworld: sure, but it gives us a much better "what should the polling rate be?" its just a backstop, and the actual event based triggers is via a different mechanism that triggers immediately. | 10:10 |
| jam | fwereade: and fwiw, I don't see "juju run" as an ad hoc do-some-stuff that I need right now, ever going away. | 10:10 |
| fwereade | jam, indeed | 10:11 |
| fwereade | jam, although I would still rather consider it to be a shortcut to invoking an implicit action | 10:11 |
| fwereade | jam, but I know that's some way away | 10:11 |
| fwereade | jam, wallyworld: far more important is how we actually execute juju-run stuff anyway | 10:12 |
| wallyworld | jam: fwereade: given juju-run executes in a context (I think), would it be "juju run status-set busy" or something? | 10:12 |
| fwereade | wallyworld, yeah, that should do it | 10:12 |
| jam | wallyworld: well, to be clear "juju run" is the user/client command | 10:12 |
| fwereade | jam, good point | 10:13 |
| jam | "juju-run" is a binary on the machine that is invoked in response to "juju run" via the API server, etc. | 10:13 |
| jam | that potentially processes on that machine can also use | 10:13 |
| jam | wallyworld: the fact that it is confusing is partly why we should clearly document it :) | 10:13 |
| wallyworld | yes, i've not got a handle on what the charms would do. is there a juju run charm helper? or woud the charm just shell out and run "juju run blah"? | 10:14 |
| jam | wallyworld: there is no ".jenv" file on the machines for "juju" the CLI to use | 10:14 |
| wallyworld | or should i say jujud somthing | 10:14 |
| jam | so you have to use this other thing that is almost-the-same | 10:14 |
| fwereade | wallyworld, "juju-run" | 10:14 |
| fwereade | jam, wallyworld: and fwiw "juju-run" was always meant to be a purely charm-side tool | 10:16 |
| fwereade | jam, wallyworld: "juju run" was an outgrowth of that, and not a *particularly* necessary or helpful one, given the existence of "juju ssh" | 10:17 |
| wallyworld | jam: agree about documenting things from a charmer's perspective, but i see that as subtley different to this requirements doc | 10:17 |
| fwereade | jam, wallyworld: but people seem to like it, however hard it fucks with reproducibility of deployments | 10:17 |
| jam | wallyworld: so the thing is, I see "status" as needing an immediate mode, and part of the doc is describing how status is going to work | 10:17 |
| jam | wallyworld: so if the way to do immediate mode is "use juju-run" then it should be part of the doc (IMO) | 10:17 |
| jam | its not so much telling them how to write their code, but how they can get something done | 10:18 |
| wallyworld | jam: sure, ok. i saw the doc as describing what work needed to be done, and user doc would also come too, but perhaps separately, but i'll add it | 10:18 |
| wallyworld | if nothing else, will make everything unambiguously clear, and make user doc easy | 10:20 |
| rogpeppe | fwereade: any chance of a LGTM on https://github.com/juju/charm/pull/73 ? (we need two reviews) | 10:34 |
| fwereade | rogpeppe, done, sorry, saw the existing one and moved on | 10:34 |
| rogpeppe | fwereade: thanks | 10:35 |
| wallyworld | jam: fwereade: i've added some comments to the status spec, need to do some editing, will revisit tomorrow | 11:14 |
| jam | thanks wallyworld | 11:14 |
| wallyworld | np, thanks for detailed review | 11:15 |
| rogpeppe | fwereade, anyone else: this is the logical follow-on from the charm package change above: https://github.com/juju/juju/pull/1048 | 11:19 |
| rogpeppe | large but mechanical | 11:19 |
| rogpeppe | mattyw: this is relevant for you too | 11:21 |
| mattyw | rogpeppe, thanks very much | 11:21 |
| mattyw | rogpeppe, I'm also ocr today so I guess it's relevant twice :) | 11:21 |
| rogpeppe | mattyw: cool | 11:21 |
| dimitern | mattyw, hey, as OCR would you take a look at http://reviews.vapour.ws/r/349/ please? | 11:54 |
| mattyw | rogpeppe, couple of things from me on https://github.com/juju/juju/pull/1048 | 11:54 |
| rogpeppe | mattyw: ta | 11:54 |
| mattyw | dimitern, don't worry - that is on my list - I started looking but decided I'd need to wake up a bit more first ;) | 11:55 |
| dimitern | mattyw, cheers :) | 11:55 |
| rogpeppe | mattyw: the repo is an exact (cp -r) copy of the repo from the charm.v4 repo. i'd prefer to keep it like that, rather than randomly applying changes at this point, because it's good to keep such a large PR as mechanical as possible IMHO | 11:56 |
| mattyw | rogpeppe, I understand that. If you think those changes are valid can you do them in a follow up - or at least add a bug/ task somewhere so someone else can pick them up | 11:57 |
| rogpeppe | mattyw: hopefully a bunch of the testing charms can be deleted or moved into repos for specific packages | 11:58 |
| rogpeppe | mattyw: are juju-core bugs still being tracked in launchpad? | 11:59 |
| mattyw | rogpeppe, afaik yes | 11:59 |
| natefinch | rogpeppe: yes | 12:04 |
| voidspace | dimitern: http://reviews.vapour.ws/r/351/diff/# | 12:12 |
| voidspace | dimitern: if you have time | 12:12 |
| voidspace | dimitern: bike shedding on error names welcomed | 12:12 |
| rogpeppe | mattyw: responded | 12:13 |
| dimitern | voidspace, already looking :) | 12:13 |
| natefinch | voidspace: I voted for my color | 12:14 |
| rogpeppe | voidspace: FWIW, error values should always be prefixed with "Err" | 12:14 |
| voidspace | rogpeppe: thanks | 12:14 |
| natefinch | rogpeppe: that was the color I preferred as well ;) | 12:14 |
| rogpeppe | voidspace: and aren't capitalised | 12:14 |
| rogpeppe | voidspace: (the error text, that is) | 12:15 |
| voidspace | rogpeppe: ok, cool | 12:15 |
| voidspace | I thought you meant the names weren't capitalised, which seemed odd | 12:15 |
| rogpeppe | voidspace: also, when specific errors are returned, they should be compared with == (or gc.Equals) not DeepEquals | 12:16 |
| voidspace | rogpeppe: cool, I wasn't sure | 12:17 |
| rogpeppe | voidspace: and it's worth comparing with c.Assert(errors.Cause(err), gc.Equals, ErrFoo) so that the errors can be wrapped if desired | 12:17 |
| voidspace | rogpeppe: we won't wrap here as they'll be used by the next level up to construct a user facing error | 12:18 |
| voidspace | rogpeppe: should I / can I use errors.Cause anyway? | 12:18 |
| rogpeppe | voidspace: nonetheless, it's a good general policy - you might wrap inside the implementation itself | 12:18 |
| rogpeppe | voidspace: yeah, i think so | 12:18 |
| voidspace | kk | 12:18 |
| voidspace | changes maded | 12:22 |
| voidspace | *made | 12:22 |
| voidspace | natefinch: I don't like your colour | 12:23 |
| natefinch | voidspace: that's because you put a u in it ;) | 12:23 |
| voidspace | natefinch: which only improves it | 12:23 |
| natefinch | voidspace: but does it improuve it? | 12:24 |
| voidspace | natefinch: only | 12:24 |
| voidspace | natefinch: I mean, if you want consistency in your language it should be culor or even kulor | 12:25 |
| natefinch | voidspace: sounds double plus good | 12:25 |
| voidspace | :-) | 12:25 |
| natefinch | voidspace: not to double up on the paint job, but is "address" really needed in those names? Pretty sure we know we're not talking about intellectual property :) | 12:26 |
| dimitern | voidspace, reviewed | 12:26 |
| voidspace | natefinch: hmmm... I tend to talk about IP addresses and less so IPs | 12:27 |
| voidspace | natefinch: but I don't care overly | 12:27 |
| voidspace | dimitern: thanks | 12:28 |
| voidspace | dimitern: why test with empty address? | 12:28 |
| voidspace | dimitern: we're unlikely to call it with an empty address - and do you want parameter checking inside our implementation | 12:29 |
| voidspace | dimitern: and if we'll rely on ec2 parameter checking, it isn't actually a different case | 12:29 |
| dimitern | voidspace, 1) because it can happen, and the code doesn't seem to handle this; 2) as a reminder if we change the behavior later | 12:29 |
| voidspace | dimitern: we'll get back InvalidParameterValue | 12:29 |
| voidspace | dimitern: which we do handle | 12:29 |
| voidspace | dimitern: which is why I say I don't think that's a different case | 12:30 |
| dimitern | voidspace, hmm, that's true yeah - the test server doesn't handle this, but it will | 12:30 |
| voidspace | dimitern: I can duplicate the test if you think it's important | 12:30 |
| dimitern | voidspace, well, at least add a test case for empty address inside the test for ErrIPAddressUnavailable | 12:31 |
| voidspace | ok | 12:31 |
| dimitern | voidspace, thanks! | 12:33 |
| voidspace | so I have a return nil erroneously in the code - meaning it can't work | 12:36 |
| voidspace | but the tests checking it does work (exercising the unreachable return below) pass! | 12:37 |
| voidspace | and those tests are definitely being run | 12:38 |
| voidspace | ah no | 12:38 |
| voidspace | it's a remnant of old code and the second return is unneeded | 12:38 |
| voidspace | dimitern: rogpeppe: "in two sentence" error messages you wouldn't capitalise the second sentence? | 12:42 |
| rogpeppe | voidspace: for example? | 12:42 |
| voidspace | dimitern: rogpeppe: as in "unexpected AWS response. instance not found" rather than "... Instance not found." | 12:42 |
| rogpeppe | voidspace: we wouldn't usually use a full stop, but a colon | 12:42 |
| voidspace | rogpeppe: that avoids the problem | 12:43 |
| rogpeppe | voidspace: unexpected AWS response: instance not found | 12:43 |
| voidspace | you know your approach is basically sound when all the review comments are about the wording of your error messages ;-) | 12:46 |
| voidspace | (not quite all to be fair) | 12:46 |
| voidspace | natefinch: Errorf without formatting passes go vet fine | 12:47 |
| voidspace | natefinch: I'm happy to switch to errors.New anyway | 12:47 |
| voidspace | natefinch: go vet runs as a pre-push hook | 12:47 |
| voidspace | dimitern: network.NewAddress is worse because I have to pass a Scope | 12:49 |
| voidspace | dimitern: so I replace network.Address{Value:"foo"} with network.NewAddress("foo", network.ScopeUnknown) | 12:50 |
| voidspace | dimitern: which I can do | 12:50 |
| dimitern | voidspace, ah, fair point | 12:53 |
| rogpeppe | mattyw: does PR #1048 look ok to you now? | 12:59 |
| rogpeppe | mattyw: (i'd like to land it soon if possible, before it becomes conflicted) | 13:00 |
| mattyw | rogpeppe, good call, looking again | 13:00 |
| mattyw | rogpeppe, did you rebase it down to 1 commit? | 13:02 |
| rogpeppe | mattyw: yes | 13:02 |
| rogpeppe | mattyw: was that bad? | 13:02 |
| voidspace | dimitern: so I've fixed everything from the reviews except your suggestion to add the ip address and instance id to the error messages | 13:03 |
| voidspace | dimitern: my reasoning was that this information is known to the caller, so they can annotate the error if needed | 13:03 |
| voidspace | dimitern: I'm happy to add it there if you prefer | 13:03 |
| mattyw | rogpeppe, not normally, but it means I have to look through the whole thing again to see what you changed :) | 13:04 |
| mattyw | rogpeppe, seems like it was the package docs and that's it | 13:04 |
| rogpeppe | mattyw: i changed just the comment | 13:04 |
| rogpeppe | mattyw: yeah | 13:04 |
| dimitern | voidspace, my reasoning was - this will end up in the log file at some point, so let's make it comprehensive | 13:04 |
| voidspace | dimitern: ok, I'll add it | 13:04 |
| dimitern | voidspace, thanks! I'll have another look | 13:04 |
| mattyw | rogpeppe, and you raised lp:1389656 | 13:05 |
| rogpeppe | mattyw: yes | 13:05 |
| mattyw | so instead of printing a nice message about my bug number mup decides to leave - trying not to take it personal | 13:06 |
| voidspace | dimitern: done and pushed | 13:07 |
| mattyw | rogpeppe, lgtm, land at your convenience | 13:08 |
| rogpeppe | mattyw: ta! | 13:08 |
| mattyw | ashipika, did you get your prs and reviews sorted? | 13:08 |
| ashipika | mattyw: editing code.. will submit a bit later.. | 13:09 |
| ashipika | mattyw: fwereade had some useful comments.. as always | 13:09 |
| dimitern | voidspace, lgtm | 13:10 |
| voidspace | dimitern: cool | 13:13 |
| voidspace | dimitern: after lunch I'll look at goamz test server | 13:14 |
| dimitern | voidspace, awesome! | 13:14 |
| rogpeppe | i'm presuming that this juju-core test failure is just "one of those things" http://juju-ci.vapour.ws:8080/job/github-merge-juju/1192/console | 13:26 |
| rogpeppe | natefinch: have you seen that failure mode? | 13:26 |
| rogpeppe | fwereade: this is what i'm thinking of for the in-memory charm testing stuff: http://paste.ubuntu.com/8836186/ | 14:14 |
| rogpeppe | fwereade: that would be defined in charm.v4/testing | 14:15 |
| rogpeppe | fwereade: there could be additional constructors if desired, to make charms with more easily specified relations or whatever | 14:16 |
| rogpeppe | fwereade: or additional fields in the CharmSpec struct as desired | 14:16 |
| rogpeppe | bodie_: ^ | 14:23 |
| rogpeppe | can someone please fix the landing 'bot please; i'm seeing "write error: No space left on device" | 14:27 |
| rogpeppe | mgz: ^ | 14:27 |
| rogpeppe | http://juju-ci.vapour.ws:8080/job/github-merge-juju/1194/console | 14:27 |
| natefinch | rogpeppe: sorry was away | 14:34 |
| fwereade | rogpeppe, that works for me I think | 14:38 |
| sinzui | natefinch, perrito666: I don't know how to verify that the win-agents in streams are good. I hoped I could use add-machine to manually provision a windows instance to verify the machine agent was installed and it called home | 14:53 |
| TheMue | dimitern: thanks for explanations | 14:56 |
| ericsnow | perrito666: FYI, I think I've covered your entire restore patch at a high level now :) | 15:04 |
| wwitzel3 | ericsnow: no tosca call today, so standup? :) | 15:05 |
| perrito666 | ericsnow: is findfile landed? I am already using it :p | 15:40 |
| ericsnow | perrito666: working on it | 15:40 |
| natefinch | sinzui: I would hope that add-machine would work | 15:45 |
| sinzui | natefinch, consider that add-machine wants ssh. I happen to have an win image with ssh, but even that failed | 15:46 |
| natefinch | sinzui: ahh hmm yes | 15:49 |
| rogpeppe | fwereade: cool | 15:49 |
| rogpeppe | bodie_: here's what i ended up with: http://paste.ubuntu.com/8837430/ | 15:50 |
| natefinch | sinzui: can you ssh there w/o a password from your machine normally? | 15:50 |
| sinzui | natefinch, yes | 15:51 |
| sinzui | natefinch, the juju env and the win machine are using the same key too | 15:52 |
| natefinch | sinzui: hmm weird | 15:52 |
| rogpeppe | sinzui: the landing bot seems to be broken, if that's under your control | 15:54 |
| bodie_ | rogpeppe++ | 15:56 |
| rogpeppe | bodie_: cool, thanks | 15:56 |
| katco | rick_h_: https://jujucharms.com/solutions, did we lose our count of # deploys? | 15:58 |
| katco | those 0's make me sad :( | 15:59 |
| rick_h_ | katco: yes, it's a new store and we don't have any counts atm. we'll either try to backfill or start new or I'm not sure yet. | 16:00 |
| katco | rick_h_: cool. looks great btw. nice work to you and your team :) | 16:01 |
| rick_h_ | katco: thanks, yea lots of kinks to work out but glad to get it out the door | 16:01 |
| katco | it has that new software smell :) | 16:01 |
| rick_h_ | hah | 16:01 |
| bodie_ | rogpeppe, what I was imagining was CharmSpec as an interface implemented by a set of pre-baked testing charms, or the user can implement by composing requirement functions (must have Actions.yaml for X action, must have config with A and B parameters) that way the user never has to implement these things, they're a toolkit for generating fake charms | 16:06 |
| bodie_ | rogpeppe, but that's probably significantly more work without a lot more reward | 16:07 |
| rogpeppe | bodie_: in a call, will get back to you | 16:07 |
| sinzui | mgz, can you look into the landing bot? | 16:07 |
| TheMue | alexisb: ping, I'm available | 16:11 |
| === liam_ is now known as Guest86958 | ||
| === seelaman` is now known as seelaman | ||
| ericsnow | jam: would you mind taking a look at a couple of mattyw's reviews? http://reviews.vapour.ws/r/342/ and http://reviews.vapour.ws/r/346/ | 16:25 |
| ericsnow | natefinch: I've addressed your comments on http://reviews.vapour.ws/r/343/ | 16:27 |
| mattyw | ericsnow, for the record you can get anyone else to review them as well I think. | 16:30 |
| voidspace | someone refactored the test infrastructure so my build failed | 16:30 |
| voidspace | goddamthem | 16:30 |
| ericsnow | mattyw: yeah | 16:30 |
| ericsnow | mattyw: I realized I had never followed up with a review mentor so I figured I would try it this time :) | 16:31 |
| natefinch | ericsnow: looks good.... though the else in that if statement is spurious :) | 16:32 |
| ericsnow | natefinch: it's visually innocuous while still conveying the right meaning :) | 16:33 |
| ericsnow | natefinch: however, in this case I agree :) | 16:34 |
| ericsnow | natefinch: I could use a switch <0.5 wink> | 16:35 |
| mattyw | fwereade, ping? | 16:44 |
| fwereade | mattyw, pong | 16:44 |
| mattyw | folks - is anyone waiting for me to review code that I promised to do and haven't yet? | 17:06 |
| rogpeppe | bodie_: i think that what i'm suggesting is still compatible with your thoughts there | 17:14 |
| rogpeppe | bodie_: it's straightforward to add new constructors that make a testing.Charm, with whatever higher level specification we think might be useful | 17:15 |
| bodie_ | rogpeppe, agree but maybe the members of CharmSpec shouldn't be exported, is my thought | 17:25 |
| rogpeppe | bodie_: why not? | 17:25 |
| bodie_ | probably a future change | 17:25 |
| rogpeppe | bodie_: i don't see that that's limiting | 17:25 |
| rogpeppe | bodie_: it's just one possible set of constructor arguments for creating a new testing Charm | 17:26 |
| bodie_ | I see, so that would give the package user the ability to use this form and write it by hand | 17:26 |
| bodie_ | then, move toward a more automatic version if needed | 17:26 |
| rogpeppe | bodie_: yes | 17:30 |
| rogpeppe | bodie_: the two forms aren't incompatible with one another | 17:30 |
| rogpeppe | bodie_: the main problem i've just come across (again) is that we can't currently generate a YAML marshaled form of the metadata from a charm.Meta value | 17:31 |
| rogpeppe | bodie_: so if we want to specify relations programmatically (for example) we have a bit of a problem. | 17:32 |
| rogpeppe | bodie_: there are two ways forward here - either implement a proper GetYAML method on *charm.Metadata, or (the cheat's way) just use a different representation when generating charms, then marshal it before reading it | 17:35 |
| rogpeppe | bodie_, fwereade, anyone else: https://github.com/juju/charm/pull/74 | 17:56 |
| bodie_ | rogpeppe, lgtm | 18:04 |
| rogpeppe | bodie_: ta! | 18:04 |
| bodie_ | :) | 18:04 |
| bodie_ | rogpeppe, why can't *charm.Meta be marshaled by yaml? | 18:07 |
| rogpeppe | bodie_: it can, but it doesn't produce anything like a metadaya.yaml file | 18:07 |
| bodie_ | ah | 18:07 |
| bodie_ | maybe that's the problem | 18:08 |
| bodie_ | but I guess you can't just deprecate metadata.yaml | 18:09 |
| bodie_ | er, the current format, anyway | 18:09 |
| rogpeppe | bodie_: indeed, it's about the oldest file format we have | 18:09 |
| rogpeppe | bodie_: it predates the Go version of juju | 18:09 |
| bodie_ | even if you did, you'd still need to have a transformer for the unmarshaled form to the new format | 18:09 |
| rogpeppe | bodie_: yup | 18:09 |
| === natefinch is now known as natefinch-afk | ||
| rogpeppe | bodie_: we actually do marshal the metadata directly into JSON in various places. | 18:10 |
| bodie_ | rogpeppe, so if you use the "cheat's way", then you are really laying the groundwork for that transformer ;) | 18:10 |
| rogpeppe | bodie_: i'm not sure | 18:11 |
| rogpeppe | bodie_: thing is, we'd probably not choose the current data format as a file format by choice, as it has redundancy in various places | 18:11 |
| rogpeppe | bodie_: for instance, relations are keyed by name but the name of the relation is also in the value | 18:12 |
| bodie_ | heh | 18:18 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| voidspace | g'night all | 19:21 |
| === kadams54 is now known as kadams54-away | ||
| === natefinch-afk is now known as natefinch | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| menn0 | wallyworld: here's that PR to separate state-based upgrade steps from API-based upgrade steps. http://reviews.vapour.ws/r/355/ | 21:47 |
| wallyworld | ok, ta, will look soon | 21:48 |
| menn0 | wallyworld: there's still another PR to come which changes how upgrade targets are handled (as discussed in email) | 21:48 |
| wallyworld | ok | 21:48 |
| === jog__ is now known as jog | ||
| === fuzzy is now known as Ponyo | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| sinzui | wallyworld, Its been a bad day. I hope you or someone can give some answers to the speculation and testing I have done in https://bugs.launchpad.net/juju-core/+bug/1389807 | 22:43 |
| mup | Bug #1389807: stable juju cannot bootstrap because it selects the devel stanza in index.json <landscape> <metadata> <regression> <theme-oil> <juju-core:Triaged> <https://launchpad.net/bugs/1389807> | 22:43 |
| wallyworld | sinzui: i'm trying to ramp up now | 22:43 |
| wallyworld | what's the tl;dr? | 22:43 |
| wallyworld | i'm reading the bug report | 22:43 |
| sinzui | comment 4 https://bugs.launchpad.net/juju-core/+bug/1389807/comments/4 | 22:44 |
| wallyworld | sinzui: yes, released needs to be first | 22:44 |
| wallyworld | since in 1.20 there was no discrimination on stream | 22:45 |
| wallyworld | when parsing the index file and choosing a matching stanza | 22:45 |
| sinzui | wallyworld, okay, I am glad you agree with my testing. I will prep for the validation and do you agree we can rewrite the content so that we don't need to wait for beta1? | 22:45 |
| wallyworld | i am pretty sure, yes, 99.9% | 22:46 |
| wallyworld | 1.20/1.18 looked for a matching stanza based on cloud details | 22:46 |
| wallyworld | in there are devel, released,proposed etc - they will all have the same cloud details | 22:47 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | so released needs to go first | 22:47 |
| wallyworld | it seems obvious now | 22:47 |
| wallyworld | in hindsight | 22:48 |
| wallyworld | i think it should be tested though to be 100% sure | 22:48 |
| sinzui | wallyworld, well that pastebin is from a reproduction of a test from Saturday...I failed to notice the switch in the details | 22:48 |
| sinzui | oh... | 22:48 |
| sinzui | wallyworld, actually, I can do something right now. I control the CPCs. I will fix the order and make the CPCs happy | 22:49 |
| wallyworld | ok, i'll continue reading the bug etc to make sure my thoughts are correct, i've only just skimmed so far | 22:49 |
| wallyworld | i need to understand why clouds without a mirror are the ones affected | 22:50 |
| sinzui | wallyworld, yes, please, wait and be sure. My best idea was to stop the release last night and wait to update streams.canonical.com until moew qa team were about | 22:51 |
| wallyworld | sinzui: the bug says private clouds - but private clouds will have their own metadata though, so i need to understand why they are reaching out to streams.canonical.com | 22:52 |
| sinzui | wallyworld, no so. a lot of landscape and oil testing are open, using public streams | 22:53 |
| sinzui | wallyworld, they cannot use the mirror, so the read the first item in index.json | 22:54 |
| wallyworld | yeah, you are right, i was thinking of private clouds behind a firewall | 22:54 |
| sinzui | wallyworld, and I was think that is how stakeholders were testing myself | 22:54 |
| sinzui | s/think/thinking/ | 22:54 |
| wallyworld | sinzui: i fear that putting the released stanza first may not work on ppc | 23:04 |
| wallyworld | that approach relies on json deserialisation and map ordering | 23:05 |
| sinzui | wallyworld, :( | 23:05 |
| wallyworld | it might work, needs to be tested | 23:05 |
| wallyworld | with the compiled ppc binaries | 23:06 |
| wallyworld | i'll keep digging, see if anything else comes to light | 23:06 |
| wallyworld | sinzui: one nuclear option is to use a new name for the index file for 1.21 onwards, so we publish 2 index files | 23:08 |
| sinzui | wallyworld, I like that option | 23:09 |
| wallyworld | 1.21 would look for index2.json and fall back to index.json | 23:09 |
| wallyworld | if index2.jsin wasn't there | 23:09 |
| wallyworld | the nice bit would be that only that 1 extra file is needed | 23:09 |
| sinzui | wallyworld, that would require beta1. I hope ppc testing will let me change the ordering to continue releasing alpha3 | 23:10 |
| wallyworld | yes, it would require a beta 1 | 23:10 |
| wallyworld | sinzui: we will need to do the index2 option anyway, because if as i suspect map ordering is an issue, it will break on amd64 if we ever compile 1.20 with go 1.3 | 23:11 |
| wallyworld | maybe we won't ever do that | 23:11 |
| sinzui | wallyworld, json via js is officially ordered. I wrote the mirror generation with Pythons OrderedDicts to be certain I serialised exactly what I put in it | 23:11 |
| sinzui | I hope go's json is ordered | 23:11 |
| wallyworld | sinzui: I've learnt to never assume anything with Go | 23:12 |
| sinzui | yeah, this issue comes up every other day | 23:12 |
| wallyworld | sinzui: a quick ppc test would be to run validate-tools on ppc using the reordered index | 23:12 |
| * sinzui added env to stilson-6 | 23:13 | |
| menn0 | wallyworld: can we chat about the upgrade steps review? I want to make sure I understand your comments. | 23:14 |
| wallyworld | menn0: sure, but i need to keep an eye on irc | 23:15 |
| wallyworld | https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand | 23:15 |
| sinzui | oops, I just tested aws which is mirrored. ppc likes it BTW | 23:18 |
| wallyworld | \o/ | 23:25 |
| wallyworld | i still fear ppc won't like the non mirrored case | 23:26 |
| sinzui | wallyworld, we are about to find out. I am going to attempt an aws bootstrap first using the true aws location followed by the mirror | 23:28 |
| wallyworld | ok | 23:29 |
| sinzui | wallyworld, I would normally use my streams and mirrors on people.canonical.com, but stilsons cannot see it. It can see aws | 23:30 |
| wallyworld | ah | 23:30 |
| wallyworld | sinzui: regardless, if it works, it is still built on a fragile foundation and it people pull 1.20 source and recompile it may very well break, so i think index2.json will be needed for beta1; this will just buy time till then | 23:31 |
| sinzui | wallyworld, we loose. I my first attempt setting the real location shows that devel was selected even though released is first in index.json | 23:32 |
| wallyworld | yeah, not surprised | 23:32 |
| davecheney | d sorts before r | 23:32 |
| davecheney | :( | 23:32 |
| wallyworld | :-( | 23:32 |
| davecheney | so does alpa | 23:32 |
| davecheney | and beta | 23:32 |
| davecheney | ZEVELOPMENT! | 23:32 |
| wallyworld | davecheney: well, it is json unmarshaling into a mao, then then we iterate the map, so no assumptions can be made at all | 23:33 |
| davecheney | crap | 23:34 |
| wallyworld | sinzui: i can add support for index2.(s)json files to be used, when were you thinking of releasing beta1? | 23:34 |
| === jog__ is now known as jog | ||
| sinzui | wallyworld, officially tomorrow! | 23:35 |
| wallyworld | sinzui: i can have a fix done today | 23:35 |
| sinzui | wallyworld, but I can wait till Friday. Lets not rush. | 23:36 |
| wallyworld | i can do a fix and it can be tested | 23:36 |
| sinzui | wallyworld, davecheney this is the official proof that we ppc wont be happy http://pastebin.ubuntu.com/8842960/ | 23:36 |
| * sinzui adds link the bug | 23:36 | |
| davecheney | sinzui: poop | 23:38 |
| sinzui | wallyworld, I wont release tomorrow because I need to change juju-release-tools. It needs to ensure index.json is preserved for historic juju. | 23:41 |
| wallyworld | sinzui: sure, np. i want to get the fix done asap to give as much time as possible for testing etc | 23:42 |
| sinzui | thank you very much wallyworld. I am going to drink now because it is dinner and I want to feel good that we have a plan | 23:44 |
| wallyworld | sure, enjoy | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!