| sinzui | guess who types rm -r in his home directory | 00:50 |
|---|---|---|
| sinzui | axw, I have no notes, but I recall I wanted to ask how you did a full i386 test run | 00:51 |
| sinzui | 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:53 |
| wallyworld_ | sinzui: afaik, we hard coded the arch in arch.go to i386 | 00:56 |
| wallyworld_ | so it was faked | 00:56 |
| sinzui | wallyworld_, okay | 00:58 |
| sinzui | wallyworld_, is there an env setting to extend the timeouts in the test suite | 00:58 |
| axw | sinzui: one time I actually ran with i386 on canonistack | 00:58 |
| axw | sinzui: after all my changes I only ran locally with arch faked to i386 | 00:59 |
| wallyworld_ | sinzui: you use command line arg to test | 00:59 |
| sinzui | axw okay that works I have a sleve there | 00:59 |
| wallyworld_ | test.timeout of something | 00:59 |
| sinzui | thank you wallyworld_ | 01:00 |
| wallyworld_ | -timeout is the raw go test arg | 01:00 |
| sinzui | I think canonistack my be viable, even though I have tried to not use it | 01:00 |
| wallyworld_ | i think you need test.timeout if used with gocheck, can't recall exactly without trying | 01:00 |
| sinzui | wallyworld_, thank you | 01:00 |
| sinzui | anyway I need to rebuild my computer. I don't think I will accomplish much tomorrow. | 01:01 |
| wallyworld_ | sinzui: np. here's the syntax: "go test -gocheck.v -test.timeout=xxxxms" | 01:01 |
| wallyworld_ | if you use gocheck | 01:01 |
| * sinzui pastebin's that | 01:02 | |
| wallyworld_ | sinzui: did we need to schedule a chat about jenkins lander for core? | 01:02 |
| sinzui | wallyworld_, not just yet. I don't have time to start since I still need to get ppc tested every rev | 01:03 |
| wallyworld_ | ok, np | 01:03 |
| sinzui | and the script that would build ppc64 packages just emptied my home directory | 01:04 |
| wallyworld_ | sinzui: if you like, you can give us epermission to set up a job in your jenkins and we can experiment | 01:04 |
| wallyworld_ | oh no! | 01:04 |
| sinzui | At least I know the script wont fill up the stilson disk space again. | 01:04 |
| wallyworld_ | did you have backups? | 01:04 |
| sinzui | Looks like I have one from 4 days ago | 01:04 |
| wallyworld_ | better than nothing, but still :-( :-( | 01:05 |
| wallyworld_ | sorry to hear that | 01:05 |
| sinzui | I don't backup my work or hacking dirs. I need to rebuild my repos | 01:05 |
| wallyworld_ | 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 |
| sinzui | wallyworld_, sure | 01:09 |
| wallyworld_ | not sure how far we'll get | 01:09 |
| wallyworld_ | but still, having more potential resources to help would be positive | 01:10 |
| wallyworld_ | not that i'm in *any* hurry to leav lp | 01:10 |
| wallyworld_ | git makes me sad the more i learn about it | 01:10 |
| wallyworld_ | br is so much nicer | 01:10 |
| wallyworld_ | bzr | 01:10 |
| wallyworld_ | 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:27 |
| axw | wallyworld_: I can take a look at TestEnsureAdminUser | 01:28 |
| wallyworld_ | ok, ta | 01:28 |
| wallyworld_ | that test has been failing a lot | 01:28 |
| axw | wallyworld_: how'd you go with the PRs to joyent? | 01:29 |
| wallyworld_ | axw: we now have a committment that they will look at them in the next day or so | 01:30 |
| axw | cool | 01:30 |
| wallyworld_ | so, i'm budgetting for eow by the time it goes around | 01:30 |
| davecheney | tiny change https://codereview.appspot.com/100580045/ | 01:51 |
| perrito666 | davecheney: lgtm, if the readme file is in that directory :) | 02:35 |
| menn0 | review please: https://codereview.appspot.com/92520043/ (new "user" supercommand) | 03:05 |
| jimmiebtlr | Is it best to always post here when a new codereview is up? | 03:48 |
| jimmiebtlr | A proposal for a bug fix | 03:49 |
| davecheney | jimmiebtlr: seems to work well to get people to look at it if it is urgent | 03:56 |
| davecheney | any members of juju-core will get an email that the code review is reday | 03:56 |
| davecheney | actually, they'll get a lot of mail | 03:56 |
| jimmiebtlr | Nothing urgent | 03:57 |
| jimmiebtlr | low priority bug, just getting a feel for committing fixes | 03:58 |
| davecheney | jimmiebtlr: i haven't seen anyting coming through email | 03:59 |
| davecheney | do you have a link to the code review ? | 03:59 |
| jimmiebtlr | https://codereview.appspot.com/98410043/ | 03:59 |
| davecheney | jimmiebtlr: toptip: | 04:00 |
| davecheney | lbox propose -bug=1313793 to link the review to the bug | 04:00 |
| davecheney | you can do this now | 04:00 |
| davecheney | and it will do the linkage | 04:00 |
| jimmiebtlr | that returned an error "User does not have sufficient permission to edit the bug task milestone" | 04:02 |
| davecheney | jam: wallyworld_ can you fix this ? | 04:10 |
| wallyworld_ | hmmm, maybe. but we don't want to open permissions to change any milestone | 04:10 |
| wallyworld_ | might be that lbox needs looking at to see what it is trying to do | 04:11 |
| wallyworld_ | i wonder if it can be linked via the lp gui | 04:12 |
| jimmiebtlr | Are you referring to the codereview being linked to the bug, or the branch being linked to the bug? | 04:14 |
| wallyworld_ | branch -> bug | 04:17 |
| wallyworld_ | the code review will then pick up the link | 04:18 |
| jimmiebtlr | I linked the branch and the bug via the lp gui several days ago | 04:19 |
| jimmiebtlr | or related it anyway | 04:20 |
| wallyworld_ | hmm, ok. looks like it all went through ok in any case | 04:25 |
| wallyworld_ | i suspect an issue with the lbox code trying to do something unexpected/unneeded but can't be sure without digging into it | 04:26 |
| jimmiebtlr | thanks for the help, I'm off | 04:29 |
| davecheney | protip: if you want to do a proposal, but aren't sure what the total diff will look like | 05:39 |
| davecheney | you can use the lbox -wip flag to get a proposal and not mail it | 05:39 |
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| jcw4 | yay for protip | 06:16 |
| jcw4 | what about bzr missing? | 06:16 |
| jcw4 | 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:21 |
| jcw4 | fwereade, mgz ? ^^ | 06:22 |
| davecheney | Technically, this is a 503 error and has been caused by our database being temporarily offline. | 06:24 |
| davecheney | sad trombone | 06:24 |
| davecheney | jcw4: just do lbox propose | 06:24 |
| davecheney | again | 06:24 |
| davecheney | jcw4: you are always proposing a branch, not a patch | 06:25 |
| davecheney | so propose will always roll up your commits | 06:25 |
| davecheney | so | 06:25 |
| davecheney | bzr commit -m '...'; | 06:25 |
| davecheney | until you are happy | 06:25 |
| davecheney | then lbox propose to ask people to take another look | 06:25 |
| jcw4 | davecheney: cool, tx! | 06:25 |
| jcw4 | mgz, fwereade updated the MR: https://codereview.appspot.com/98260043/ | 06:30 |
| * jcw4 is off to bed... early morning meeting at 1400 UTC | 06:31 | |
| jcw4 | :) | 06:31 |
| === Beret- is now known as Beret | ||
| voidspace | morning all | 08:03 |
| fwereade | voidspace, heyhey | 08:05 |
| TheMue | morning from a sunny veranda too ;) | 08:08 |
| voidspace | we just had the most incredible downpour of rain and thunder for about half an hour | 08:09 |
| voidspace | and now we're back to sun | 08:09 |
| fwereade | we even had some rain here yesterday | 08:10 |
| === vladk|offline is now known as vladk | ||
| jam | morning voidspace | 08:25 |
| jam | 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 | |
| jam | Its independent of my other API changes. | 08:26 |
| fwereade | jam, sorry, I'll take a look when I get back | 08:26 |
| jam | fwereade: np, no rush | 08:26 |
| jam | dimitern: you're welcome to look at ^^ as well, it is part of my changing of Facades to be versioned. | 08:27 |
| jam | not directly related, but a necessary precursor to unifying how Facades are created. | 08:27 |
| dimitern | jam, will look in a bit, thanks | 08:27 |
| voidspace | dimitern: morning | 08:46 |
| voidspace | jam: morning to you too | 08:46 |
| dimitern | hey voidspace! | 08:47 |
| voidspace | dimitern: how's life? | 08:48 |
| dimitern | voidspace, not bad at all :) i wish the weather was so good | 08:49 |
| dimitern | voidspace, how was the grand canyon? | 08:49 |
| voidspace | dimitern: the grand canyon was spectacular, really amazing | 08:49 |
| voidspace | dimitern: I posted my pictures of our shooting expedition and the grand canyon on flickr | 08:50 |
| dimitern | voidspace, nice, I'll check them out | 08:50 |
| voidspace | dimitern: https://www.flickr.com/photos/mfoord/sets/ | 08:50 |
| voidspace | dimitern: I didn't get a picture of us both together at the shooting, shame :-/ | 08:50 |
| dimitern | voidspace, I still haven't got to posting some pictures yet | 08:50 |
| voidspace | dimitern: it was awesome though, one of the highlights of the trip for me | 08:50 |
| dimitern | voidspace, yeah, but the photos otherwise kick ass ;) | 08:51 |
| voidspace | dimitern: hehe, yep - and the videos | 08:51 |
| dimitern | voidspace, indeed | 08:53 |
| dimitern | voidspace, next time - shotguns ;) | 08:53 |
| voidspace | dimitern: hehe, fair enough :-) | 08:54 |
| voidspace | I've shot a shotgun before, clay pigeon shooting (once). I was getting the hang of it too. | 08:54 |
| voidspace | all the guns we shot were fun. | 08:54 |
| dimitern | yep, unexpectedly for me, it *was* fun | 08:56 |
| perrito666 | morning | 09:24 |
| voidspace | perrito666: morning | 09:25 |
| jam | 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 |
| dimitern | jam, looking | 09:46 |
| jam | dimitern: did you look at the earlier patch? I didn't see a comment from you | 09:46 |
| dimitern | jam, no, sorry got caught up deep in goamz stuff | 09:47 |
| jam | np, just figured you might want to look at that first | 09:47 |
| dimitern | jam, LGTM, i'm looking at the prereq now | 09:48 |
| TheMue | 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:48 |
| jam | TheMue: do you have specific questions for me, or you just want me to audit the whole doc? | 09:49 |
| mattyw | 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 <juju-core:New> <https://launchpad.net/bugs/1321212> | 09:49 |
| TheMue | jam: a quick audit of the whole doc. I think everything is now clean and the open questions have been discussed yesterday. | 09:50 |
| jam | 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 |
| dimitern | jam, the prereq LGTM as well | 09:51 |
| jam | 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 |
| jam | I would *guess* that this isn't because of ensure-availability, but because of First Login issues | 09:52 |
| jam | mattyw: you could also try "juju status --debug" to see what addresses it is trying to connect to | 09:52 |
| jam | 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 |
| mattyw | jam, ok thanks - I "sort of" remember that stuff, I'll take another look | 09:53 |
| === vladk is now known as vladk|offline | ||
| voidspace | brb, grabbing coffee | 09:59 |
| voidspace | jam: doesn't look like natefinch is around yet | 10:03 |
| jam | voidspace: yeah, I'm a bit surprised he picked that early for him, but when he comes around we'll chat | 10:03 |
| voidspace | jam: cool :-) | 10:04 |
| voidspace | question about our watcher architecture | 10:11 |
| voidspace | suppose a client has a watcher on something (say environ-config changes for example) | 10:11 |
| voidspace | and three changes occur before the client makes a "Next" request | 10:11 |
| voidspace | will the subsequent two "Next" requests return *immediately*, or will the next "Next" wait for *another* change? | 10:12 |
| voidspace | does the apiserver maintain a queue of changes for watchers? | 10:12 |
| jam | voidspace: they get collapsed, I believe the Watcher collapse interval is 5s | 10:13 |
| jam | so if there are 3 changes within 5s, then you only get 1 Next() event | 10:14 |
| voidspace | jam: ok | 10:14 |
| voidspace | 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:14 |
| jam | 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 |
| voidspace | right - so they're collapsed all the time, but also "close" events are collapsed automatically anyway | 10:15 |
| voidspace | so the watchers have a minimum granularity of 5 seconds | 10:15 |
| voidspace | thanks | 10:16 |
| mattyw | jam, have you got a moment? | 10:29 |
| jam | mattyw: what's up? | 10:29 |
| mattyw | jam, tasdomas and I are working on adding output to ensure-availability so it prints what it's doing | 10:30 |
| jam | sure | 10:31 |
| mattyw | 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:31 |
| mattyw | 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 |
| mattyw | nate suggested we could ask you these kind of questions in his absense - just wondered if you had an opinion? | 10:32 |
| jam | mattyw: looking into it | 10:34 |
| jam | 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 |
| jam | rather, we should probably just expose lists of machine-tags | 10:35 |
| jam | mattyw: so I'm thinking we shouldn't just make that type exposed, but create a new params.EnsureAvailabilityResult (Intent, Actions, ... ?) | 10:36 |
| mattyw | jam, the apiserver was going to convert this type into a Results type anyway | 10:36 |
| === vladk|offline is now known as vladk | ||
| jam | 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:38 |
| jam | however, we have precedent for state could just return the polished up params.EnsureAvailabilityResults itself | 10:39 |
| jam | and then we don't have to expose raw Machine entities to apiserver/client code. | 10:39 |
| jam | we *can* do it with that layering | 10:39 |
| jam | 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:40 |
| jam | the API talks in terms of Tags | 10:41 |
| jam | the internals talk in terms of Ids | 10:41 |
| jam | time for an AddMachinesV3 :) | 10:41 |
| mattyw | jam, I like the idea of the params.params.EnsureAvailabilityResults | 10:42 |
| dimitern | jam, standup? | 10:45 |
| jam | dimitern: yeah, brt | 10:45 |
| jam | voidspace: looks like natefinch didn't make it online before his wife's dentist appointment | 11:20 |
| jam | I have to work on my son's homework in a bit, but I can chat with you after that. | 11:20 |
| TheMue | lunchtime, ended exactly when my wife called ;) | 11:36 |
| === vladk is now known as vladk|offline | ||
| voidspace | jam: ok | 11:40 |
| voidspace | jam: if you're not around we can postpone appropriately | 11:41 |
| voidspace | jam: don't hang around on my behalf | 11:41 |
| perrito666 | fwereade: hey, I am implementing what we spoke yesteday, about ServerInstances, the get/set methods you suggested should operate against Storage right? | 11:55 |
| fwereade | perrito666, not necessarily | 11:55 |
| fwereade | perrito666, we want them to be Environ method | 11:55 |
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| fwereade | perrito666, but we also need a common implementation that most environs can use to implement them | 11:56 |
| === vladk|offline is now known as vladk | ||
| fwereade | perrito666, and that would take a storage and keep working the same as before | 11:56 |
| fwereade | perrito666, the important thing really is that those Environ interface methods *not* metion storage | 11:56 |
| fwereade | perrito666, am I sounding sane? | 11:56 |
| perrito666 | fwereade: most of the time | 11:57 |
| fwereade | perrito666, how about in the last 2 minutes? | 11:57 |
| perrito666 | sane enough :) tx | 11:57 |
| fwereade | perrito666, cool :) | 11:57 |
| perrito666 | what still bothers me a bit is that everywhere seems to be implying that the current storage Should already have that info | 11:58 |
| * perrito666 looks the rain outside and smiles on his non commuting job | 11:59 | |
| fwereade | perrito666, that is still true | 12:01 |
| fwereade | perrito666, which is why almost everything should use that method | 12:01 |
| wwitzel3 | hello | 12:01 |
| fwereade | perrito666, pretty sure that manual and local will be different to some degree, though | 12:02 |
| perrito666 | fwereade: expected | 12:02 |
| fwereade | perrito666, and more to the point, we will soon have to deal with some cloud that *doesn't* have storage | 12:02 |
| perrito666 | fwereade: I see | 12:03 |
| fwereade | perrito666, (also, wallyworld_ is moving storage into gridfs soon as well -- so we'll be dropping storage from Environ anyway) | 12:03 |
| perrito666 | ok then, I should assume storage is not there for my new methods and then do everything use those | 12:04 |
| voidspace | lunch | 12:06 |
| fwereade | perrito666, yeah, all the implementations will use storage, but the interface shouldn't mention it | 12:14 |
| * 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:15 | |
| ahasenack | 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 |
| ahasenack | https://bugs.launchpad.net/juju-core/+bug/1321009 | 12:21 |
| _mup_ | Bug #1321009: juju-metadata doesn't produce content that bootstrap can use <landscape> <juju-core:New> <https://launchpad.net/bugs/1321009> | 12:21 |
| wallyworld_ | 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 |
| wallyworld_ | ... Panic: command failed: bzr add | 13:12 |
| wallyworld_ | (PC=0x4143E6) | 13:12 |
| wallyworld_ | i haven't seen that before | 13:12 |
| wallyworld_ | looks like it's external to juju? | 13:12 |
| wallyworld_ | the PC=xxxx is from the br add output | 13:13 |
| wallyworld_ | bzr | 13:13 |
| wallyworld_ | 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 |
| sinzui | wallyworld_, :( I see this hack is still in place when CI prepares | 13:13 |
| sinzui | bzr whoami 'J. Random Hacker <jrandom@example.org>' | 13:13 |
| wallyworld_ | that jrandom doesn't look like it comes from juju | 13:14 |
| ahasenack | wallyworld_: ok, will try, thanks | 13:18 |
| === cory_fu2 is now known as cory_fu | ||
| dimitern | niemeyer, hey | 13:33 |
| niemeyer | dimitern: Hey hey | 13:33 |
| dimitern | niemeyer, I have a small review for you if you can spare 10m - https://codereview.appspot.com/98430044/ (for goamz) | 13:34 |
| dimitern | jam, vladk, fwereade, ^^ another review appreciated | 13:34 |
| ahasenack | wallyworld_: same problem, let me paste | 13:35 |
| niemeyer | dimitern: Not exactly a *small* review, but will surely look :) | 13:35 |
| dimitern | niemeyer, :) thanks | 13:35 |
| ahasenack | wallyworld_: http://pastebin.ubuntu.com/7492988/ | 13:35 |
| niemeyer | dimitern: At a glance, it's easy to tell the code is under-covered by tests | 13:36 |
| niemeyer | dimitern: Maybe that's okay, given that the fake server itself is meant to be the test | 13:36 |
| niemeyer | dimitern: (how far do we test the test) | 13:36 |
| dimitern | niemeyer, I've included the most important parts for juju in the tests | 13:37 |
| niemeyer | dimitern: Why do we have the rest of the logic in the fake server if it's not relevant? | 13:46 |
| dimitern | niemeyer, which logic? | 13:49 |
| niemeyer | dimitern: You said you've included the most important parts for juju in the tests | 13:50 |
| dimitern | niemeyer, yes - that is the assumption in juju that all instances have 1 nic after launching | 13:52 |
| niemeyer | dimitern: Not sure about how that reflects into the above points | 13:55 |
| perrito666 | voidspace: wwitzel3 could anyone of you jump into the moonstone channel? I am trying to set up my hangout | 13:56 |
| dimitern | niemeyer, well, i've always assumed the test server should (when possible) mimic ec2 as close as possible | 13:56 |
| voidspace | perrito666: ok | 13:57 |
| dimitern | niemeyer, what do you think needs more test coverage? | 13:57 |
| niemeyer | 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 |
| niemeyer | dimitern: then you said something along the lines of "what matters for juju is tested" | 13:59 |
| niemeyer | dimitern: and my question was "why do we have anything that does not matter for juju in there"? | 13:59 |
| dimitern | niemeyer, ok, let's backtrack a bit, sorry | 14:00 |
| dimitern | 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 |
| mbruzek | Hi guys I am seeing an SSLError from deployer when I try to run some amulet tests. http://pastebin.ubuntu.com/7493011/ | 14:01 |
| hazmat | mbruzek, update your version of jujuclient | 14:01 |
| dimitern | niemeyer, the code it almost the same in both cases | 14:01 |
| dimitern | niemeyer, and the tests indeed cover those 2 cases - the implementation is actually longer than the tests need to be I think | 14:02 |
| mbruzek | hazmat, python-jujuclient is already the newest version. | 14:02 |
| hazmat | mbruzek, are you pulling things from pypi or from packages? | 14:03 |
| dimitern | 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 |
| hazmat | 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:03 |
| dimitern | niemeyer, or a test that creates 2 NICs | 14:04 |
| hazmat | mbruzek, what version? | 14:04 |
| hazmat | mbruzek, pip -U python-jujuclient | 14:04 |
| hazmat | to upgrade | 14:04 |
| mbruzek | hazmat no such option: -U | 14:04 |
| dimitern | 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:04 |
| mbruzek | hazmat it looks like 0.17.5 is the version I have | 14:05 |
| mbruzek | $ pip freeze | grep jujuclient | 14:05 |
| mbruzek | jujuclient==0.17.5 | 14:05 |
| niemeyer | dimitern: I somewhat doubt that, given the sheer volume of logic in the code which is not represented in the tests | 14:05 |
| hazmat | mbruzek, can we move this to #eco | 14:05 |
| niemeyer | dimitern: But as I said, I'm won't argue much.. this is test code being tested | 14:05 |
| niemeyer | I won't | 14:06 |
| === hatch__ is now known as hatch | ||
| dimitern | niemeyer, yes, it is test code | 14:06 |
| dimitern | niemeyer, but I'll be happy to add more tests if you have something particular in mind | 14:06 |
| niemeyer | dimitern: I have everything there in mind :) | 14:07 |
| dimitern | niemeyer, :) | 14:08 |
| niemeyer | dimitern: Lots of these lines are unchecked | 14:08 |
| niemeyer | dimitern: I'm not going to go over the trouble of telling you every single one | 14:08 |
| niemeyer | dimitern: If you really care, you might go over the diff and check yourself | 14:08 |
| dimitern | niemeyer, I'll look some more into it, thanks | 14:09 |
| jcw4 | thanks fwereade | 14:16 |
| bodie_ | fwereade, wasn't sure if there was any more you wanted to add, but everyone dropped off :) | 14:16 |
| jcw4 | wrt. Txn loop: you had sent me some example code which I subsequently misplaced.... | 14:17 |
| fwereade | jcw4, bodie_: I'd be keen to talk about txn loops -- mgz, not sure if you've delved deeply there before? | 14:17 |
| fwereade | 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 |
| jcw4 | fwereade: +1 | 14:17 |
| bodie_ | 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:17 |
| jcw4 | fwereade: https://codereview.appspot.com/98260043/ | 14:18 |
| fwereade | jcw4, bodie_, mgz: a live chat might be worthwhile then, I'll find the comment I did for perrito666 | 14:18 |
| perrito666 | voidspace: apparently https://bugs.launchpad.net/ubuntu/+source/linux/+bug/950490 | 14:18 |
| _mup_ | Bug #950490: External microphone does not work on Zenbook UX31 <amd64> <apport-bug> <precise> <verification-done-precise> <linux (Ubuntu):Fix Released by diwic> <linux (Ubuntu Precise):Fix Released> <https://launchpad.net/bugs/950490> | 14:18 |
| voidspace | perrito666: ah, so it maybe Ubuntu's fault | 14:19 |
| perrito666 | alsa, actually | 14:19 |
| dimitern | fwereade, do you have some time for a goamz review? https://codereview.appspot.com/98430044/ | 14:19 |
| voidspace | perrito666: I have a similar issue - when you have any alternative audio input source the "line in" is no longer available to select | 14:19 |
| dannf | how can i specify a constraint in a bundle? | 14:31 |
| dimitern | niemeyer, In any case, I'd appreciate your review | 14:34 |
| niemeyer | dimitern: Have been doing it since | 14:34 |
| niemeyer | dimitern: The "10 minutes" :) | 14:34 |
| dimitern | niemeyer, thanks! :) | 14:35 |
| niemeyer | dimitern: https://codereview.appspot.com/98430044/ | 14:39 |
| dimitern | niemeyer, cheers! | 14:39 |
| === Ursinha is now known as Ursinha-afk | ||
| niemeyer | dimitern: np, please let me know how you feel about these | 14:42 |
| dimitern | niemeyer, will do | 14:44 |
| === Ursinha-afk is now known as Ursinha | ||
| === vladk is now known as vladk|offline | ||
| bac | marcoceppi: super trivial charm-tools review at https://codereview.appspot.com/98390047 when you have time | 15:09 |
| marcoceppi | bac: thanks! | 15:12 |
| jam | 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:39 |
| * fwereade cheers | 15:40 | |
| dimitern | niemeyer, updated https://codereview.appspot.com/98430044/ with most of your suggestions, and added some replies | 15:42 |
| * dimitern reached EOD | 15:43 | |
| tasdomas | hi | 15:54 |
| tasdomas | I am getting a test failure in cmd/juju/machine_test.go:253 | 15:56 |
| tasdomas | (on trunk) : http://paste.ubuntu.com/7493538/ | 15:57 |
| jcw4 | fwereade: 6pm too late to discuss txn loop? | 16:01 |
| fwereade | jcw4, that's fine | 16:01 |
| fwereade | jcw4, was that link remotely relevant, or missing too much context? | 16:02 |
| jcw4 | fwereade: I reviewed and looks interesting.. one question | 16:02 |
| jcw4 | fwereade: should I build the ops in the loop? | 16:02 |
| jcw4 | fwereade: I assume so | 16:02 |
| jcw4 | fwereade: generate the Id outside the loop but everything else inside? | 16:02 |
| fwereade | jcw4, yeah, exactly | 16:03 |
| jcw4 | fwereade: and is there a specific reason for 3 iterations? | 16:03 |
| fwereade | jcw4, it may not *always* be necessary to do so, but it's generally the right thing to do | 16:03 |
| jcw4 | fwereade: k | 16:03 |
| fwereade | jcw4, none whatsoever | 16:03 |
| jcw4 | fwereade: ok... Shall I start with 3? | 16:03 |
| fwereade | jcw4, some use 5; some use fewer because we can guarantee that >2 implies something wrong | 16:03 |
| fwereade | jcw4, sgtm | 16:03 |
| jcw4 | fwereade: makes sense | 16:04 |
| fwereade | jcw4, at some point I'll probably get round to a generalised txn build/run/backoff-retry thing | 16:04 |
| jcw4 | fwereade: ok. also, if the txn completes successfully we just break out of the loop right? | 16:05 |
| fwereade | jcw4, better yet, if err != txn.ErrAborted { return err } | 16:05 |
| fwereade | jcw4, that covers both success and surprising failures like dropped connection | 16:05 |
| jcw4 | fwereade I see. so on success err will be nil therefore we return nil error | 16:06 |
| fwereade | jcw4, yeah | 16:06 |
| jcw4 | fwereade: and if its anything else but ErrAborted we return the suprising error | 16:06 |
| jcw4 | fwereade: and if the failure is ErrAborted we just try again | 16:06 |
| jcw4 | k | 16:06 |
| fwereade | jcw4, yeah, just try to build a fresh txn against whatever state needs to be updated | 16:07 |
| fwereade | jcw4, in your case, check the unit's life again | 16:07 |
| jcw4 | fwereade: until we finish the loop, and if we get there we return ErrAborted? | 16:07 |
| jcw4 | fwereade: ok | 16:07 |
| fwereade | jcw4, fall out of the loop and return ErrExcessiveContention | 16:07 |
| jcw4 | fwereade: perfect | 16:07 |
| fwereade | jcw4, although what that *really* means in every case I have yet seen is "some programmer ballsed things up" | 16:08 |
| fwereade | jcw4, one detail | 16:08 |
| jcw4 | fwereade: hehe | 16:08 |
| fwereade | jcw4, you'll want to clone the unit rather than Refresh() it in the loop | 16:08 |
| fwereade | jcw4, we prefer not to update fields whose update isn't implies by the op you're running | 16:09 |
| jcw4 | fwereade: hmm. Okay | 16:09 |
| fwereade | 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 |
| fwereade | jcw4, (although if you SetFoo you do expect foo to be set) | 16:09 |
| jcw4 | 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 |
| bodie_ | fwereade, jcw4, I'm worrying about the technique I'm using to validate the actions.yaml as valid json-schema | 16:10 |
| bodie_ | right now, our actions.yaml is relatively simple, as specified in the MR | 16:11 |
| fwereade | jcw4, the funcs are defined in export_test.go -- SetTransactionHooks et al | 16:11 |
| jcw4 | fwereade: right. tx! | 16:11 |
| bodie_ | 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 |
| bodie_ | which isn't present in my actions.yaml | 16:11 |
| fwereade | jcw4, searching for Hooks in the state package should get yu plenty of examples | 16:12 |
| jcw4 | fwereade: +1 | 16:12 |
| fwereade | bodie_, hmm, can you get it to fail at all? :) | 16:12 |
| bodie_ | 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 |
| bodie_ | or, perhaps simply loading a k/v map as a jsonschemadoc isn't sufficient to validate it | 16:12 |
| fwereade | bodie_, the examples on json-schema.org don't necessarily include that | 16:13 |
| bodie_ | http://json-schema.org/latest/json-schema-core.html#anchor23 | 16:13 |
| bodie_ | good point | 16:13 |
| bodie_ | in that case, I don't understand the use of "MUST" in this spec ;) | 16:14 |
| fwereade | bodie_, "MUST if you feel like it ehh who cares" | 16:14 |
| bodie_ | MUST be optional | 16:14 |
| bodie_ | :/ | 16:14 |
| bodie_ | AH | 16:15 |
| bodie_ | ah* I misread it | 16:15 |
| bodie_ | IF it exists, it must be at the root; it is "RECOMMENDED" that schema authors include this keyword | 16:16 |
| bodie_ | need to beef my reading comprehension. Go is making me lazy.... | 16:16 |
| fwereade | bodie_, ah cool | 16:16 |
| bodie_ | order matters in short-circuit evaluation of English clauses... | 16:17 |
| bodie_ | I guess I'm having a hard time thinking of valid YAML that isn't also valid JSON-Schema | 16:17 |
| fwereade | bodie_, stick a $schema key in *not* at the root :) | 16:19 |
| bodie_ | good one | 16:19 |
| fwereade | tasdomas, yeah, that's clearly a real problem, good that you can repro | 16:22 |
| * fwereade beholds the horror that is cmd/jujud and sighs heavily | 16:24 | |
| jcw4 | fwereade :) | 16:24 |
| tasdomas | fwereade, if there's anything I can do to help resolve this, let me know - I'd be glad to help | 16:24 |
| jcw4 | fwereade: *how* do I clone a unit? | 16:24 |
| tasdomas | also, lbox propose gives me this error: error: Failed to update merge proposal log: Server returned 401 and body: (<BranchMergeProposal at 0x2af0e8f83850>, 'description', 'launchpad.Edit') - no idea, what's it about, though. | 16:24 |
| jcw4 | fwereade: st.Unit(id) /?? | 16:25 |
| fwereade | jcw4, that's probably the easiest way, yeah | 16:25 |
| jcw4 | fwereade: tx | 16:25 |
| fwereade | tasdomas, sorry, that bit doesn't ring a bell | 16:26 |
| jcw4 | tasdomas: isn't 401 forbidden? | 16:26 |
| jcw4 | tasdomas: maybe some auth issue? | 16:26 |
| fwereade | tasdomas, I can explain what the problem is but I kinda want to check with wallyworld_ to see if there's some reason it's like that | 16:26 |
| jcw4 | tasdomas: Unauthorized (not forbidden) | 16:27 |
| mgz | tasdomas: mat be worth deleting your launchpad login cookie bits and going through the auth in browser bit again | 16:29 |
| tasdomas | mgz, jcw4 - thanks for the advice, solved the issue (had not granted lbox the proper permission level) | 16:30 |
| mgz | tasdomas: rm ~/.lpad_oauth | 16:30 |
| mgz | tasdomas: ah yes, that one... selecting anything other than "change everything" is a bear trap | 16:31 |
| mgz | these days launchpad lets the app say what access it wants, lpad probably need updating | 16:31 |
| jcw4 | tasdomas: cool | 16:31 |
| === vladk|offline is now known as vladk | ||
| fwereade | tasdomas, you can "fix" it by moving the setupContainerSupport call up just after the `runner := newRunner(...` line | 16:34 |
| mgz | I say these days, 2010... <http://jameswestby.net/weblog/tech/16-Improving-the-usability-of-launchpadlib-using-code.html> | 16:34 |
| fwereade | tasdomas, I would probably LGTM that if you proposed that alone | 16:34 |
| tasdomas | fwereade, great - will do | 16:35 |
| fwereade | tasdomas, but... that whole method is evidently all screwed up | 16:35 |
| fwereade | tasdomas, if I suddenly figure out why that's a terrible idea, I apologise | 16:35 |
| tasdomas | fwereade, no problem - at least you've pointed my in some direction, I'll go take a look at it | 16:35 |
| * perrito666 starts doing ddd before going crazy | 16:42 | |
| * fwereade approves | 16:42 | |
| voidspace | yay, they're retiring canonicaladmin!!! | 16:48 |
| voidspace | awesome | 16:49 |
| mgz | voidspace: not quite, does expenses still | 16:49 |
| voidspace | mgz: ah, well not too bad I guess | 16:49 |
| voidspace | which reminds me, I haven't done my expenses for vegas yet | 16:49 |
| mattyw | voidspace, tasdomas and I were have that exact conversation just now | 16:51 |
| voidspace | heh | 17:09 |
| voidspace | EOD folks | 17:23 |
| voidspace | g'night | 17:23 |
| wwitzel3 | voidspace: see ya | 17:23 |
| perrito666 | fwereade: I am trying to write a watcher for instance id changes but I am not sure what to watch | 17:39 |
| perrito666 | brb | 17:39 |
| fwereade | perrito666, I think the existing API-addresses watcher should be sufficient to inform you of any changes to the set of state servers; then you can just look up the instances on the state server machines, I think | 17:41 |
| === vladk is now known as vladk|offline | ||
| fwereade | perrito666, btw, you're writing a new API, so please don't just use the same name for the watch method -- you can use the same state method to start the watch, but make the API name reflect its purpose not its implementation | 17:48 |
| jcw4 | fwereade: what kind of action would disrupt a transaction that's adding an action to the state.actions collection? | 17:50 |
| fwereade | jcw4, I can't think of anything; you should probably just check for unit dead | 17:51 |
| fwereade | jcw4, you've already got a unique id | 17:51 |
| jcw4 | fwereade: yep, but I want to write a failing test first | 17:51 |
| fwereade | jcw4, so it should be impossible for the DocMissing to fire | 17:51 |
| jcw4 | so something that would perturb the transaction :) | 17:52 |
| fwereade | jcw4, ok, so set a txn hook that makes the unit Dead in its Before | 17:52 |
| jcw4 | fwereade: doh~! tx!! | 17:52 |
| fwereade | jcw4, you'll want to call preventUnitDestroyRemove() before you Destroy, otherwise it'll fast-forward straight through to removed (which you'll also want to test, but you can't make it Dead unless you do that, Destroy, EnsureDead | 17:53 |
| jcw4 | fwereade: ah.. ok. I already did the Destroy / EnsureDead for another test, but didn't call preventUnitDestroyRemove() first... | 17:54 |
| jcw4 | test seemed to work as I expected though... prolly just lucky | 17:54 |
| fwereade | jcw4, I'm sure it *was* a valid test, just not the one you thought you were writing ;) | 17:55 |
| jcw4 | lol | 17:55 |
| perrito666 | fwereade: I was going for WatchAPIInstances not sure if that is what you meant with the naming | 18:12 |
| jcastro | http://askubuntu.com/questions/448444/juju-security-model-issues | 18:18 |
| jcastro | Can someone from core check out that question? I've tacked a bonus 200 point bounty! | 18:19 |
| sinzui | perrito666, the ha-backup-restore test is queued. I can enable it when you land. | 18:21 |
| natefinch | jcastro: I can answer it, but they might not like the answer :) | 18:22 |
| jcastro | that's fine | 18:22 |
| jcastro | natefinch, towards the end of the answer encourage him to post to the list if he wants to follow up | 18:22 |
| natefinch | ahh good idea | 18:23 |
| jcastro | It'd be interesting to get real details on what he's planning on doing, etc. | 18:23 |
| fwereade | perrito666, let's say WatchStateServerInstances? | 18:26 |
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| natefinch | jcastro: responded, btw | 18:43 |
| === vladk|offline is now known as vladk | ||
| jcw4 | using mgo txn.Assert... how can I see which Assertion failed? | 19:38 |
| jcw4 | mgo seems to only return ErrAbort if something fails | 19:38 |
| natefinch | sorry, no idea | 19:44 |
| fwereade | jcw4, you can't | 19:45 |
| fwereade | jcw4, that's one of the big reasons for the loop structure | 19:45 |
| fwereade | jcw4, go back to the top, start building txn again, checking for sanity against latest known state | 19:45 |
| fwereade | jcw4, assuming your in-memory checks map correctly to your assertions, you'll fail out appropriately | 19:46 |
| jcw4 | Boom | 19:46 |
| jcw4 | I see now | 19:46 |
| jcw4 | :) | 19:46 |
| fwereade | jcw4, sweet | 19:47 |
| jcw4 | with enough repetition even granite will crack | 19:47 |
| fwereade | jcw4, not at all, you have taken less instruction than most -- it's really not a familiar way of working for almost anyone | 19:48 |
| mbruzek | Hello juju-devs, I am running juju local, and all my systems are in "pending" state. I remember a similar problem when I had an incomplete image. Can someone refresh my memory where juju stores the local images? | 19:48 |
| jcw4 | fwereade: thx... I'm loving the 'go' way of thinking, so this has been a fun project | 19:49 |
| fwereade | jcw4, awesome | 19:49 |
| fwereade | mbruzek, I will poke around but might have to go in a sec, someone else who knows for sure should certainly answer if they can | 19:49 |
| mbruzek | http://pastebin.ubuntu.com/7494454/ | 19:50 |
| mbruzek | That is the symptom, all my machines are in pending. | 19:50 |
| mbruzek | I am looking in /var/lib/containers/ but I don't know what I am looking for. | 19:51 |
| natefinch | mbruzek: check ps -A | grep lxc - sometimes my lxc gets stuck and there will be a half dozen lxc processes started but not doing anything... I end up having to reboot to fix it. | 19:51 |
| fwereade | mbruzek, it's /var/lib/juju/containers FWIW | 19:52 |
| mbruzek | natefinch, I see nothing when running ps -A | grep lxc | 19:52 |
| fwereade | mbruzek, it might be worth checking the logs for "juju.container.lxc" messages | 19:53 |
| mbruzek | fwereade, the logs in ~/.juju/local/log/ have no such messages, | 19:55 |
| mbruzek | I screwed something up here, I can tell | 19:55 |
| fwereade | mbruzek, well, it might have been us | 19:56 |
| fwereade | mbruzek, how about "provisioner" messages? | 19:56 |
| mbruzek | It was running earlier today | 19:56 |
| mbruzek | /var/log/juju-mbruzek-local$ grep provisioner * | 19:57 |
| mbruzek | all-machines.log:machine-0: 2014-05-20 19:44:16 INFO juju.worker.singular singular.go:101 starting "environ-provisioner" | 19:57 |
| mbruzek | all-machines.log:machine-0: 2014-05-20 19:44:16 INFO juju.worker runner.go:260 start "environ-provisioner" | 19:57 |
| fwereade | mbruzek, hmm, this exact environment was running before? or the "same" one, but destroyed and recreated? | 19:57 |
| fwereade | brb | 19:58 |
| mbruzek | I destroyed the environment a few times today. Had to control+C out of a bootstrap at one point. | 19:58 |
| mbruzek | probably should not have done that (I realize) | 19:58 |
| mbruzek | All looks well when I destroy-environment and bootstrap | 20:01 |
| mbruzek | http://pastebin.ubuntu.com/7494490/ | 20:01 |
| natefinch | yeah, we try to handle control-C, but it's still not always 100% | 20:02 |
| mbruzek | But when I try to deploy all machines stay in pending state and I get no unit logs. | 20:02 |
| mbruzek | fwereade, When you get back it is the "same" environment destroyed and recreated. | 20:07 |
| natefinch | mbruzek: what does sudo lxc-ls tell you? | 20:08 |
| mbruzek | I just destroyed the environment again natefinch, sudo lxc-ls reports nothing. | 20:09 |
| mbruzek | would you like me to bootstrap and run it again? | 20:09 |
| natefinch | mbruzek: bootstrap, add a machine, wait 30 seconds, then run sudo lxc-ls | 20:10 |
| mbruzek | natefinch, http://pastebin.ubuntu.com/7494534/ | 20:12 |
| mbruzek | Still nothing when I run a second sudo lxc-ls --fancy | 20:13 |
| natefinch | mbruzek: yeah, something's wonky, should look more like this: http://pastebin.ubuntu.com/7494535/ | 20:13 |
| mbruzek | How do I ask juju to re-download the image files? | 20:14 |
| natefinch | mbruzek: they should be in /var/lib/juju/containers if they're not there.... lemme check, I'm not 100% sure | 20:16 |
| mbruzek | I see directories at that location juju-precise-template juju-trusty-template mbruzek-local-machine-1 | 20:16 |
| mbruzek | they contain clout-init lxc.conf, container.log and console.log no binary image. | 20:17 |
| natefinch | mbruzek: same here | 20:23 |
| mbruzek | How about your lock directory? | 20:23 |
| mbruzek | root@workhorse:/var/lib/juju/locks# ls | 20:23 |
| mbruzek | juju-precise-template | 20:23 |
| natefinch | no locks for me | 20:28 |
| mbruzek | I still have the lock when I have destroyed the environment. | 20:28 |
| natefinch | mbruzek: try rebooting. I know it's wacky, but it helps a lot of the time (unless you've already tried that) | 20:29 |
| mbruzek | Can I safely remove the /var/lib/juju/locks/juju-precise-template when the system is destroyed? | 20:29 |
| mbruzek | natefinch, I have not rebooted, seems a bit windows-ish, but I am not against doing that. As long as you are back here when I get back! | 20:30 |
| natefinch | mbruzek: I have no idea. My knowledge of lxc is pretty limited, unfortunately. | 20:30 |
| natefinch | I'll be here for another half hour | 20:31 |
| mbruzek | let me try removing the directory under locks so mine looks like yours firt | 20:31 |
| mbruzek | first | 20:31 |
| sinzui | natefinch, I don't understand this bug. I don't think it is about virtual private clouds https://bugs.launchpad.net/juju-core/+bug/1321442 | 20:32 |
| _mup_ | Bug #1321442: Juju does not support EC2 with no default VPC <juju-core:New> <https://launchpad.net/bugs/1321442> | 20:32 |
| mbruzek | natefinch, fwereade deleting /var/lib/juju/locks/juju-precise-template looks like has done the trick. | 20:35 |
| mbruzek | I am able to get machines started now, and charms deployed! | 20:36 |
| natefinch | sinzui: we definitely don't require VPC | 20:36 |
| natefinch | mbruzek: awesome | 20:36 |
| mbruzek | natefinch, Thanks for hanging in there with me. | 20:36 |
| natefinch | mbruzek: no problem... I've been there | 20:36 |
| mbruzek | I am sure fwereade would have too if he did not have to go. | 20:37 |
| natefinch | mbruzek: seems like our cleanup code probably needs a little more attention to make sure we don't get that lock file stuck there | 20:37 |
| mbruzek | yes that would be something to check. | 20:37 |
| natefinch | mbruzek: yeah, it's 9:30pm his time, sorta understandable | 20:37 |
| mbruzek | Yes, well thanks for both of you walking me through it. I am not blocked any longer. | 20:38 |
| natefinch | awesome | 20:39 |
| bodie_ | if a charm's actions.yaml has no params defined for an action, should its Params be nil or empty? | 21:15 |
| bodie_ | s/its/the Action's/ | 21:15 |
| bodie_ | I'm assuming empty, but I want to make sure | 21:15 |
| waigani | anyone know how to resolve a ghost in the ancestry of a bzr branch? (I feel like I'm playing a fantasy game) | 21:20 |
| waigani | Could not determine revno for {jesse.meek@canonical.com-20140519235723-weky2oyq7yc20kqc} because its ancestry shows a ghost at {tarmac-20140413170514-ii8w6q2fht3eiizi} | 21:20 |
| wwitzel3 | EOD for me | 21:22 |
| jcw4 | bodie_: I vote for empty | 21:24 |
| waigani | cya wwitzel3 | 21:26 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| wallyworld_ | fwereade: did you have any followup comments to my followup comments to your comments? :-) | 21:29 |
| jcw4 | wallyworld_: fwereade will probably followup with you on that ... | 21:32 |
| wallyworld_ | :-) | 21:32 |
| sinzui | wallyworld_, I would like your help triaging bug 1320794 | 21:44 |
| _mup_ | Bug #1320794: After bootstrapping an OpenStack environment, juju tries to connect to the internal IP <addressability> <landscape> <openstack-provider> <juju-core:New> <https://launchpad.net/bugs/1320794> | 21:44 |
| wallyworld_ | sinzui: ok, one sec otp | 21:44 |
| === vladk is now known as vladk|offline | ||
| sinzui | wallyworld_, I understand juju avoids public ips for internal communication, and that it (1.18.x) doesn't understand multiple networks. I think the issue may be fixed in 1.19.x and possibly related to bug 1283866 | 21:45 |
| _mup_ | Bug #1283866: Openstack (>=grizzly) instanses can't accept floating IPs <addressability> <api> <days> <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1283866> | 21:45 |
| wallyworld_ | sinzui: in 1.19 (and possibly later 1.18 releases), work was done to make juju smarter about using the right network. it may be that the above bugs are the result of issues with the implementation. i'll talk to martin about it and update the bugs accordingly | 22:03 |
| sinzui | fab. Thank you wallyworld_ | 22:03 |
| wallyworld_ | sinzui: we need to talk about ppc, can i meet with you this time tomorrow, or about 30 minutes earlier? | 22:04 |
| sinzui | sure | 22:04 |
| wallyworld_ | ok, i'll ping you | 22:04 |
| * sinzui talked with dave and alexisb last hour about it | 22:05 | |
| wallyworld_ | yeah, i just got asked to get involved | 22:05 |
| sinzui | wallyworld_, sure ping me when you are ready, caffeinated, and waring cozy slippers | 22:05 |
| wallyworld_ | will do | 22:06 |
| wallyworld_ | sinzui: also, i'm at a loss about the bzr failures, i'll need to talk to john or someone to try and understand why it's ding like that | 22:06 |
| wallyworld_ | dying | 22:06 |
| sinzui | wallyworld_, I just verified the new CI build scripts will build PPC debs and tools for testing each time we test a revision. I will put this change into operation tomorrow | 22:06 |
| wallyworld_ | oh great. that's one of the things i wanted to talk abot | 22:07 |
| sinzui | wallyworld_, I was pondering python version and bzr | 22:07 |
| wallyworld_ | did that change? | 22:07 |
| sinzui | wallyworld_, I don't know. I am not firing on all cylinders. I deleted my home directory last night; I am still numb. | 22:08 |
| wallyworld_ | :-( | 22:08 |
| wallyworld_ | leave it with me, we can catch up about it tomorrow | 22:08 |
| wallyworld_ | sinzui: i find a large glass of red helps in such situations :-) | 22:09 |
| sinzui | Anne bought me cider :) | 22:10 |
| wallyworld_ | \o/ | 22:10 |
| * wallyworld_ bbiab | 22:10 | |
| perrito666 | hello night shift | 22:53 |
| rick_h_ | wallyworld_: ping when you get back | 22:54 |
| davecheney | lucky(~/src/launchpad.net/juju-core/state) % go test | 23:49 |
| davecheney | 2014-05-20 23:46:31 INFO juju.testing mgo.go:453 reset successfully reset admin password | 23:49 |
| davecheney | 2014-05-20 23:47:02 INFO juju.testing mgo.go:453 reset successfully reset admin password | 23:49 |
| davecheney | 2014-05-20 23:47:25 INFO juju.testing mgo.go:453 reset successfully reset admin password | 23:49 |
| davecheney | OK: 455 passed | 23:49 |
| davecheney | ^ something leaking out the the tests | 23:49 |
| davecheney | PASS | 23:49 |
| davecheney | ok launchpad.net/juju-core/state 125.341s | 23:49 |
| davecheney | i didn't used to leak this output | 23:49 |
| wallyworld_ | rick_h_: g'day | 23:51 |
| rick_h_ | wallyworld_: hey man, got time to catch up at some point tonight/today? | 23:52 |
| wallyworld_ | sure, now? | 23:52 |
| rick_h_ | wallyworld_: sure | 23:52 |
| wallyworld_ | i'll start a hangout | 23:52 |
| wallyworld_ | https://plus.google.com/hangouts/_/gwwgzrr4og3azmmxmywivftyxua?hl=en | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!