| thumper | waigani: just user IMO | 00:20 |
|---|---|---|
| thumper | waigani: because all users are local | 00:20 |
| waigani | thumper: ok | 00:20 |
| davecheney | thumper: waigani menn0 https://github.com/juju/juju/pull/653 | 00:34 |
| davecheney | if you have a chance | 00:34 |
| davecheney | this is what we discussed on the call | 00:34 |
| menn0 | davecheney: sorry, I haven't had a chance to look yet | 00:35 |
| davecheney | s'ok | 00:38 |
| davecheney | no that urgent, but not that complex either | 00:38 |
| menn0 | davecheney: done | 00:39 |
| davecheney | thanks | 00:39 |
| davecheney | re gofmt | 00:39 |
| davecheney | that's sort of how it comes | 00:39 |
| davecheney | and i'm moving those packages to the top level so that will change the ordering again | 00:39 |
| davecheney | menn0: you were right about gofmt | 00:46 |
| davecheney | fixed | 00:46 |
| davecheney | thumper: the state/api{,server} -> / change is coming next | 00:48 |
| thumper | davecheney: kk, awesome | 00:48 |
| davecheney | thanks mongo, http://paste.ubuntu.com/8211128/ | 00:55 |
| thumper | ugh... | 01:01 |
| * thumper is starting to really hate the juju/juju/juju package | 01:01 | |
| davecheney | back in the day j/j/juju was supposed to be "the" way of connecting to state | 01:01 |
| davecheney | but now we have | 01:01 |
| davecheney | state/api | 01:01 |
| davecheney | and agent/ | 01:01 |
| davecheney | i guess all good things come in threes | 01:01 |
| * thumper nods | 01:01 | |
| thumper | j/j/juju needs to die IMO | 01:02 |
| davecheney | i'm the man for that job | 01:02 |
| thumper | unfortunately I can't kill the method right now | 01:02 |
| thumper | as restore plugin has decided to use it | 01:02 |
| thumper | everywhere else is just tests | 01:02 |
| thumper | for the method I'm looking at | 01:02 |
| thumper | juju.NewAPIState(environ, api.DialOpts{}) | 01:02 |
| davecheney | hmm | 01:05 |
| davecheney | there is OpenAPIState in another package | 01:05 |
| davecheney | probably few of them | 01:05 |
| davecheney | and testing/OpenAPIAs | 01:05 |
| thumper | colour me unsurprised | 01:05 |
| davecheney | I am daves complete lack of surprise | 01:05 |
| * thumper needs to find some time to write the LXC talk he is giving in about 4.5 hours | 01:06 | |
| davecheney | glwt | 01:06 |
| davecheney | thumper: http://godoc.org/github.com/davecheney/graphpkg | 01:11 |
| davecheney | just updated this a little | 01:11 |
| davecheney | so I can see the lay of the land | 01:12 |
| davecheney | you can also use godoc to get a graph of the packages | 01:12 |
| davecheney | but I don't trust it to be up to date | 01:12 |
| davecheney | and dot went to 100% | 01:13 |
| davecheney | :( | 01:13 |
| davecheney | not a good sign | 01:13 |
| davecheney | wallyworld_: I think we have more new flaky test | 01:15 |
| davecheney | http://paste.ubuntu.com/8211272/ | 01:15 |
| wallyworld_ | davecheney: known issue, already in the doc | 01:16 |
| davecheney | cool | 01:16 |
| davecheney | thanks for confirming | 01:16 |
| wallyworld_ | np | 01:16 |
| davecheney | i haven't seen that one before | 01:16 |
| wallyworld_ | you're lucky | 01:16 |
| davecheney | i'm not sure if that means Ineed to look more, or less | 01:16 |
| wallyworld_ | sadly we have a few of those common ones | 01:16 |
| wallyworld_ | but once it's fixed, a several breakages will go away | 01:17 |
| davecheney | it's an odd one | 01:17 |
| davecheney | it's happening in test tear down | 01:17 |
| davecheney | btw, I love the open source community | 01:17 |
| davecheney | https://github.com/davecheney/gmx/issues/2 | 01:17 |
| davecheney | such people skills | 01:17 |
| wallyworld_ | yup, it also can happen elsewhere i think, but teardown is most common | 01:17 |
| wallyworld_ | lol | 01:18 |
| davecheney | i'm a tool | 01:19 |
| wallyworld_ | davecheney: in Launchpad, the various build recipe APIs were wrong for a while because I couldn't spell | 01:19 |
| davecheney | who can't spell gauge | 01:19 |
| wallyworld_ | i thought it was recipie | 01:19 |
| davecheney | wallyworld_: how many i's are there in recipippie ? | 01:19 |
| wallyworld_ | not enough | 01:19 |
| wallyworld_ | imo | 01:19 |
| davecheney | wallyworld_: you're not alone, i have a hard time remembering that recipe isn't spelled, recepit | 01:19 |
| davecheney | fuck | 01:20 |
| davecheney | recepit | 01:20 |
| wallyworld_ | i just can't spell in general | 01:20 |
| davecheney | damn it | 01:20 |
| davecheney | i really cannot spell that word | 01:20 |
| davecheney | or any other that is slightly like it | 01:20 |
| davecheney | without the red underscore I am worthless | 01:20 |
| wallyworld_ | dyslexic much | 01:20 |
| wallyworld_ | me too | 01:20 |
| wallyworld_ | axw: well, i have done my friday test fix early this week - stupid mega watcher test race bit me trying to land some code | 01:21 |
| axw | wallyworld_: okey dokey, | 01:22 |
| davecheney | https://github.com/juju/juju/pull/655 | 01:22 |
| davecheney | truly enormouse, entirely mechanical change | 01:22 |
| axw | wallyworld_: I think I'm going to do tools catalogue & storage in one | 01:23 |
| axw | probably not much bigger of a PR in the end | 01:23 |
| wallyworld_ | whatever is easiest :-) | 01:23 |
| wallyworld_ | i don't mind big pr's sometimes | 01:23 |
| davecheney | wallyworld_: https://github.com/juju/juju/pull/655/files | 01:23 |
| axw | I don't think it'll be all that big, we'll see | 01:24 |
| wallyworld_ | 600 files!! | 01:24 |
| davecheney | 600 files changed, +600 lines, -600 lines :( | 01:24 |
| wallyworld_ | davecheney: so just a package move | 01:24 |
| davecheney | sed baby, sed | 01:24 |
| davecheney | yup | 01:24 |
| davecheney | hopefully uncontentious | 01:24 |
| wallyworld_ | yup | 01:24 |
| davecheney | people i talk to think putting the api at the top level makes sense | 01:25 |
| davecheney | i'm +/- on having both api and apiserver at the top level | 01:25 |
| davecheney | i rememver back in the day there was something like | 01:25 |
| davecheney | api/apiserver | 01:25 |
| davecheney | or apisever/api | 01:25 |
| davecheney | but that sounds no better | 01:25 |
| axw | davecheney: IMO we should move api out of this repo altogether at some point | 01:26 |
| davecheney | axw: +1 << 32 | 01:26 |
| axw | have language-specific API repos | 01:26 |
| davecheney | yes, that was part of the reason for monving api/params to apiserver/params | 01:26 |
| axw | cool. | 01:26 |
| davecheney | i'd be keen to see the api (client) move it it's own repo | 01:27 |
| davecheney | but I don't think it is urgent | 01:27 |
| davecheney | ie, it doesn't justify your time to setup another repo and top level build job | 01:27 |
| axw | agreed | 01:27 |
| menn0 | davecheney: FWIW the gofmt comment was waigani's, not mine | 01:43 |
| waigani | prefixed with "super minor point" gofmt -s -d says it should come after | 01:44 |
| davecheney | menn0: right | 02:11 |
| davecheney | sorry | 02:11 |
| davecheney | anyway, it's fixed now | 02:11 |
| thumper | (╯°□°)╯︵ ┻━┻ | 02:19 |
| davecheney | that's the ticket | 02:19 |
| davecheney | thumper: waigani the current state of play http://godoc.org/github.com/juju/juju/state?import-graph | 02:46 |
| waigani | hey that's really cool | 02:47 |
| davecheney | hit hide(all) to hide the std lib pacakges | 02:47 |
| thumper | davecheney: can you generate that but only look at "github.com/juju/juju" ? | 02:47 |
| davecheney | that will make it a bit simpler | 02:47 |
| davecheney | thumper: do you mean the juju/juju package | 02:48 |
| davecheney | or juju/juju/... | 02:48 |
| davecheney | thumper: https://github.com/davecheney/juju/compare/juju:master...davecheney:188-state-clone-state-serving-info?expand=1 | 02:50 |
| davecheney | not ready for review yet | 02:50 |
| davecheney | I think I can reduce the delta a bit more | 02:50 |
| davecheney | but we're still going to have three copies of params.StateServingInfo after this change | 02:50 |
| davecheney | there are also a lot of things which now depend directly on state | 02:53 |
| davecheney | which is not good either | 02:53 |
| wwitzel3 | thumper: ping | 02:55 |
| thumper | wwitzel3: hey | 02:56 |
| thumper | whazzup? | 02:56 |
| wwitzel3 | hey, you have a second for a quick hangout, I have some questions about some juju run stuff I've been working on. | 02:57 |
| thumper | sure | 02:59 |
| wwitzel3 | thumper: I'll go to the Oynx standup one | 02:59 |
| thumper | ack | 02:59 |
| davecheney | all: juju/mongo is a helper package for setting up and managing mongo servers, right ? | 03:04 |
| thumper | fixed it: ┬─┬ ノ( ゜-゜ノ) | 03:06 |
| hazmat | so much awesome.. http://vimeo.com/95066828 | 03:06 |
| hazmat | comedy value and distributed systems | 03:06 |
| wwitzel3 | thumper: looking at state/apiserver/client/run.go .. the client.Run method, it calls ParallelExecute which calls ssh.ExecuteCommandOnMachine | 03:51 |
| thumper | wwitzel3: yeah, that is how the api server calls out to the machines that it needs to call | 03:51 |
| thumper | wwitzel3: it calls the 'juju-run' command on the other side | 03:51 |
| wwitzel3 | thumper: ahh, ok | 03:52 |
| wallyworld_ | jam: i have an api version question if you're around | 04:17 |
| thumper | waigani: hmm... | 04:40 |
| * thumper thinks of expedience | 04:40 | |
| thumper | vs learning | 04:40 |
| thumper | bugge | 04:40 |
| thumper | r | 04:40 |
| thumper | waigani: the issue I'm having is that you have done things exactly as they have been done before | 04:41 |
| thumper | the problem is that they way they were done before is kinda crap | 04:41 |
| waigani | haha | 04:41 |
| waigani | well, let's do it right | 04:41 |
| thumper | sure? | 04:41 |
| waigani | ugh .. no but your call | 04:41 |
| * thumper takes a quick look to determine the amount of work | 04:42 | |
| waigani | hangout? | 04:42 |
| thumper | sure | 04:43 |
| thumper | waigani: use the standup one | 04:43 |
| === Ursinha is now known as Ursinha-afk | ||
| axw | hazmat: if you haven't already, you should read his columns too. hilarious and educational | 06:11 |
| === urulama-afk is now known as urulama | ||
| mattyw | morning all | 07:37 |
| voidspace | back and I have internet.... | 08:04 |
| voidspace | currently provided by a 30metre ethernet cable slung into next door... | 08:04 |
| TheMue | morning | 08:11 |
| TheMue | voidspace: hehe, welcome back. troubles with provider switch at least almost solved? | 08:12 |
| voidspace | well, that's 330mb of updates done | 09:15 |
| mattyw | voidspace, have EE given you a better date than 2 weeks? | 09:25 |
| dimitern | mattyw, since you're the OCR along with myself, would you mind taking a look at this trivial fix? https://github.com/juju/juju/pull/659 | 09:48 |
| mattyw | dimitern, looking | 09:49 |
| mattyw | dimitern, done | 09:52 |
| mattyw | dimitern, and thanks for pointing it out, the branch I'll be landing soon had some loggers I needed to rename | 09:53 |
| dimitern | mattyw, cheers! | 09:55 |
| dimitern | mattyw, mail sent\ | 10:00 |
| dimitern | jam, can you take a look at https://github.com/juju/juju/pull/659 as well please? | 10:10 |
| jam | dimitern: heya. want to fill me in on what you and markS talked about? | 10:20 |
| jam | wallyworld_: /wave | 10:20 |
| wallyworld_ | jam: hi there, just otp, will ping soon | 10:20 |
| jam | dimitern: so on https://github.com/juju/juju/pull/659 I'm wondering if we want to change the logging path, since if anyone was filtering theyd have to change their scripts | 10:21 |
| jam | dimitern: review | 10:22 |
| jam | reviewd | 10:22 |
| dimitern | jam, you mean the prefixes? | 10:27 |
| jam | dimitern: the logging prefixes, yes | 10:27 |
| jam | but it seems better in the new place anyway | 10:27 |
| dimitern | jam, yeah, and I've sent a mail to juju-dev, just in case someone complains, we can deal with it | 10:28 |
| dimitern | jam, thanks, I'll merge it then | 10:28 |
| hazmat | axw, those are precious.. thanks "A systems programmer will know what to do when society breaks down, because the systems programmer already lives in a world without law." | 10:33 |
| hazmat | although the nosql bane line in the presentation takes the cake for me. bane voice. "let your reads and writes choose their own destiny." :-) | 10:35 |
| hazmat | jam, did you have a chance to try the rudder charm or look at the readme. | 10:37 |
| jam | hazmat: I looked through the readme, but I haven't played with it | 10:38 |
| jam | its essentially just creating a tunneling network just like you would get installing openvswitch etc on each node | 10:38 |
| axw | hazmat: :) | 10:39 |
| hazmat | jam, in a nutshell, but its all coordinating the subnet split to host map without central point of failure and it works in environments that are gre hostile (azure). | 10:40 |
| hazmat | and you don't really need openvswitch to do the point to point gre tunneling. | 10:41 |
| menn0 | fwereade: the UpgradeInfo work is finally up for review. https://github.com/juju/juju/pull/660 | 10:42 |
| jam | dimitern: standup? | 10:46 |
| dimitern | jam, omw, sorry | 10:47 |
| perrito666 | morning | 10:52 |
| fwereade | menn0, thanks, there is a small chance I will get to it today... | 11:19 |
| menn0 | fwereade: it probably needs someone else to have a look as well given that we're the authors | 11:20 |
| menn0 | fwereade: but it would be good to get your feedback on the change I made since you last looked at it | 11:20 |
| * perrito666 discovers new levels of heartburn | 11:22 | |
| wallyworld_ | jam: hi, got time for a question? | 11:29 |
| jam | wallyworld_: so I'm on the phone now myself, I'm happy to chat in IRC a bit | 11:31 |
| wallyworld_ | sure | 11:31 |
| mattyw | perrito666, morning | 11:45 |
| perrito666 | mattyw: morning | 11:45 |
| jam | wallyworld_: so what's your question? | 11:45 |
| mattyw | perrito666, I managed to get that auth fails bug again this morning - but I wasn't looking for it when it happens :| | 11:45 |
| davecheney | dimitern: thanks for fixing my fuckup | 11:45 |
| davecheney | it never occred to me about the logger names | 11:45 |
| jam1 | voidspace: http://paste.ubuntu.com/8214743/ | 11:45 |
| davecheney | please consider my suggestion in reply | 11:45 |
| davecheney | i think we can make the default case of the logger less of a footgun | 11:46 |
| jam | davecheney: what is the call stack for top level var inits? | 11:46 |
| mattyw | mgz, am I being hated again? https://github.com/juju/juju/pull/562 | 11:46 |
| perrito666 | mattyw: I presume you cannot make it happen willingly right? | 11:46 |
| davecheney | jam it will have the package name in it | 11:46 |
| davecheney | all package level vars are initalised by a faux init() function | 11:47 |
| davecheney | bascically one per file | 11:47 |
| davecheney | that is created by the compiler for you | 11:47 |
| davecheney | hang on | 11:47 |
| davecheney | i'll prove it | 11:47 |
| mattyw | perrito666, well I've tried running just a subset of the tests that should show the error and I've got through hundreds of runs with no error. But I've seen it a couple of times during a make check | 11:47 |
| wallyworld_ | jam: so, i have a client api call that i can add params to. when run against older juju, the new params will be ignored. but i'd rather have the client detect what version of the api is running server side and warn the user. it's the EnsureAvailability() api call on client. can we up that one api call to version 2? or does it have to be done at the facade level? | 11:48 |
| perrito666 | mattyw: I have the theory that under a decent load on the testing machine you should be able to triggerit | 11:48 |
| davecheney | jam: http://paste.ubuntu.com/8214777/ | 11:48 |
| dimitern | davecheney, no worries :) | 11:49 |
| jam | wallyworld_: api versioning is at the Facade level, and I would like us to bump the version if we change anything, even if it is "technically compatible" | 11:49 |
| wallyworld_ | ok, sad that the client facade is sooooo big | 11:49 |
| mfoord | jam: back on freenode - rejoining hangout | 11:49 |
| mfoord | jam: calling Remove on a replicaset is likely to cause primary renegotiation | 11:50 |
| mfoord | jam: (I would expect) | 11:50 |
| hazmat | davecheney, you heading out early on the sprint to hit go eu? | 11:50 |
| mfoord | jam: which is why it would be slow | 11:50 |
| jam | wallyworld_: agreed. would it be easier to move EnsureAvailability to a locally clustered API and version *that* one ? | 11:50 |
| davecheney | hazmat: negative | 11:50 |
| wallyworld_ | jam: is the version gets bumped to V2, how will a caller know what methods may be incompatible or not? they won't. | 11:50 |
| davecheney | hazmat: people couldn't get their shit sorted in time | 11:50 |
| davecheney | so I couldn't change my flights | 11:50 |
| jam | wallyworld_: they know only about the ones that they are using. So we will still expose v0 for clients that don't know about v2 | 11:51 |
| davecheney | i'm going to dotGo only | 11:51 |
| jam | wallyworld_: but no, we don't have WADL sort of thing so that you can programattically say "oh, v2 is exactly like v0 except for here" | 11:51 |
| hazmat | davecheney, ugh. bummer. i was thinking of coming in for the day from brussels just to check it out. | 11:51 |
| davecheney | hazmat: i wouldn't say no | 11:51 |
| wallyworld_ | jam: i could introduce a new facade. it makes sense that all apis on a facade should be bumped together | 11:51 |
| davecheney | i'm going to be in paris from the 9th til the 12th | 11:51 |
| jam | wallyworld_: you've already been part of the great Client breakup | 11:52 |
| jam | Keyserver et al | 11:52 |
| wallyworld_ | jam: yes indeed, i was going to use the same technique | 11:52 |
| jam | wallyworld_: just to mention, that all new facades should start at V1, as v0 is intended to be the version that was in 1.18 | 11:53 |
| wallyworld_ | jam: is there sample code that shows how to set up a new api version? point me where to look? | 11:53 |
| wallyworld_ | i guess there's a version number registered somewhere | 11:54 |
| jam | wallyworld_: so just creating a new one is easy | 11:54 |
| jam | the line of Register() | 11:54 |
| jam | takes a 1 instead of a 0 | 11:54 |
| wallyworld_ | ok, ta | 11:54 |
| jam | wallyworld_: the client side code needs to check what the supported version of the API is, and then fall back to the Client facade if it can't get to the new facade | 11:55 |
| wallyworld_ | how do it do that? in this case it doesn't matter as the new fascade will be there or not, but in general? | 11:55 |
| jam1 | wallyworld_: Facade.BestAPIVersion() | 11:58 |
| wallyworld_ | thanks | 11:58 |
| voidspace | jam: I think I'm back again, lost the hangout though *sigh* - really sorry | 11:59 |
| jam | :) | 11:59 |
| jam | TheMue: can you help wallyworld_ find the right API docs to figure out how to properly introduce a new Facade version? | 12:01 |
| wallyworld_ | jam: TheMue: in standup, will check back soon | 12:01 |
| jam | I feel like we've documented all this, but I'm not finding the docs in our source tere. | 12:01 |
| jam | tree. | 12:01 |
| jam | wallyworld_: so there is a bit of "must be careful" here, I believe, which maybe we can make better. But for a Facade that didn't exist in 1.18, then "BestAPIVersion()" should return 0, which we "know" didn't exist, so your client code can tell that it should use the other facade. | 12:03 |
| jam | It is also possible that the new client layer could do the transition without the cmd/juju stuff caring. | 12:04 |
| jam | so we would have api/statemanagement/statemanagement.go | 12:04 |
| jam | and that would embed a FacadeCaller for your new StateManagement facade | 12:04 |
| jam | and it could have EnsureAvailability() on it | 12:04 |
| jam | which internally would check | 12:04 |
| jam | if self.BestAPIVersion() == 0 { // switch to old interface: | 12:05 |
| TheMue | wallyworld_: back from lunch, ping me when available too | 12:07 |
| mfoord | jam: I don't have the wireless router connected at all now, and my connection is via a switch | 12:07 |
| jam | but you're still only either or? | 12:07 |
| jam | mfoord: either IRC or Hangout, but never both... :) | 12:10 |
| voidspace | jam: it still looks like my connection is being broken every minute | 12:12 |
| voidspace | jam: I've emailed you | 12:12 |
| voidspace | jam: I can browse and use email fine but both freenode and hangouts hate me | 12:13 |
| voidspace | jam: I *have* to get IRC working as a very minimum | 12:13 |
| jam | voidspace: yeah | 12:13 |
| jam | I emailed you | 12:13 |
| jam | good luck sorting it out | 12:13 |
| jam | I'm close to EOD anyway | 12:13 |
| jam | voidspace: it seems to be calling c.stopNow() which is fundamentally calling runtime.Goexit() | 12:15 |
| jam | which certainly seems like it should be exiting ungracefully | 12:15 |
| jam | voidspace: ah, goexit is just this goroutine | 12:16 |
| voidspace | jam: looking at the traceback | 12:16 |
| jam | eg, kill this thread, not kill this process | 12:16 |
| voidspace | jam: so Remove didn't used to be an attemptLoop - but that was unreliable too because Remove *needs* to be an attemptLoop (for the same reason that the other operations do) | 12:17 |
| voidspace | jam: we probably don't want Remove to be in a defer | 12:17 |
| jam | voidspace: it doesn't help the traceback that we defer a func() that calls a function that takes a func() | 12:17 |
| voidspace | right... | 12:17 |
| voidspace | jam: we could just not defer those removes and do them at the end, that would simplify | 12:18 |
| voidspace | jam: that function isn't used outside of those two tests I don't think - so it shouldn't matter (?) if a test fails and we don't call remove | 12:19 |
| jam | voidspace: I wonder if we want to Remove at all | 12:19 |
| voidspace | we'll clean up the replicaset anyway | 12:19 |
| jam | I would think changing the test to just nuke everything would be cleaner | 12:19 |
| voidspace | jam: well, it is "assertAddRemoveSet" | 12:19 |
| jam | voidspace: so *those* Remove calls are just "cleanup what I set up" | 12:19 |
| jam | because they are in defer | 12:19 |
| jam | there is a call on line 241 | 12:19 |
| voidspace | they are, but the test name implies we want to test that Remove works | 12:19 |
| jam | that is the actual testing of Remove working | 12:19 |
| voidspace | ah | 12:20 |
| wallyworld_ | TheMue: hi. i can read the code to see how to bump up an api version, or are there docs i can read? | 12:20 |
| jam | that may also be the flakiness | 12:20 |
| jam | voidspace: if we get an error, and the replicaset is in a bad state | 12:20 |
| jam | and then we hammer it with "remove them one by one" | 12:20 |
| jam | while I'm destroying some of them | 12:20 |
| jam | I imagine it isn't happy with that | 12:20 |
| voidspace | the tests setup a new replicaset every time - so perhaps we don't need those defered removes at all | 12:21 |
| voidspace | as we call Destroy immediately after | 12:21 |
| jam | voidspace: The only reason we *might* is if we wanted to not have to set up the Root to be shared between tests or something like that | 12:21 |
| jam | but I have the feeling, we're better off *for the replicaset tests* to start and return to scratch each time | 12:21 |
| jam | I know we share the DB between tests when we can, just calling Drop Databases in TestTearDown | 12:22 |
| jam | but I don't think we need to do that here. | 12:22 |
| TheMue | wallyworld_: do you know jams doc on Google? | 12:23 |
| voidspace | jam: TearDownTest calls root.Destroy() | 12:23 |
| voidspace | jam: and in the IPV6 suite we explicitly call Destroy ourselves | 12:23 |
| wallyworld_ | TheMue: i don't think so. i may have got an email at one point but can't recall now | 12:23 |
| jam | TheMue: probably not. as the goal was to get them somewhere in the source tree/on juju.ubuntu.com and I think those never got finished | 12:24 |
| voidspace | jam: so I don't think that's a concern | 12:24 |
| jam | voidspace: right, so that is just the root, but yeah, we should just be clearer that we call Instance.Destroy() on everything and not try to Remove them down the stack | 12:24 |
| jam | because cleaning up a Mongo Cluster by removing one, killing it, removing one, killing it | 12:24 |
| jam | is likely to just cause us more pain that we need to be testing. | 12:24 |
| TheMue | jam, wallyworld_: ah, ok. a part of it is here: https://github.com/TheMue/juju/blob/api-implementation-guide/doc/design/juju-api-implementation-guide.md | 12:25 |
| voidspace | jam: we also defer the Destroy on the members | 12:25 |
| wallyworld_ | TheMue: thanks, will read that | 12:25 |
| TheMue | jam: I only wait to get my current experiences with new facades into it too | 12:25 |
| TheMue | wallyworld_: I'm currently writing some code helping to test the client side when the server side not yet has the newest version | 12:26 |
| wallyworld_ | ok, sounds good | 12:26 |
| jam | TheMue: sure, so just share it as we can, and we should get it published soon. better to have something for reference. | 12:26 |
| TheMue | jam: yep | 12:27 |
| jam | even if it isn't 100% complete, as long as it isn't *incorrect* | 12:27 |
| wallyworld_ | jam: i need to be able to run ensure-availability with a placement directive to have a specified machine become a state server, not just any old new one. the guys are happy to pass in either a machine number or maas name (like in --to for add-unit). This will require either converting a HostUnits machine to a ManageEnvirons machine, since add-machine creates HostUnits machine, or 2. adding an option to add-machine to create a | 12:38 |
| wallyworld_ | ManageEnvirons machine which does not participate until activated. pros and cons to both. maybe there's a 3rd option. i think 1 may be most flexible. update machine jobs in state; a watcher in machine agent notices, updates agent conf to record the manageenviron job, then restarts machine agent. but i'm not fully across all of the HA mechanics so i'm not sure what else needs to be done. do you have any thoughts or should i ask nate | 12:38 |
| wallyworld_ | or william? | 12:38 |
| jam | wallyworld_: what has never been clear from a MaaS guys is why they need to add-machine first | 12:39 |
| jam | I realize they want to control locations | 12:39 |
| wallyworld_ | jam: this is landscape guys | 12:40 |
| jam | and maybe there is a problem that they need to specify 2 machines | 12:40 |
| jam | wallyworld_: sure, but its on MaaS | 12:40 |
| wallyworld_ | yes, >1 will be needed | 12:40 |
| wallyworld_ | --to foo,bar | 12:40 |
| katco | wallyworld_: hey regarding https://github.com/juju/juju/pull/630/files#r16968425 | 12:40 |
| wallyworld_ | they want this machine right here to be the state server, not any other one | 12:40 |
| jam | voidspace: lost you again ? | 12:40 |
| katco | wallyworld_: will the updated config be persisted to environments.yaml making the change permanent? | 12:41 |
| jam | wallyworld_: sure, I'm just wonderign why we need to "add-machine" first | 12:41 |
| jam | can't we just "juju ensure-availability --??? maas-name:A,maas-name:B" | 12:41 |
| wallyworld_ | katco: it will get written to jenv, becoming permanent | 12:41 |
| katco | wallyworld_: ahh ok. ty | 12:41 |
| wallyworld_ | jam: we could i guess, but that will be a bit of work, since we won't have run cloud init to set stuff up | 12:42 |
| jam | wallyworld_: ? | 12:42 |
| jam | wallyworld_: the point is that we can have ensure-availability still allocating machines, just give them the knob to say what machine | 12:43 |
| wallyworld_ | add-machine boots a machine and runs cloud init to set up the tools, agent config etc. if we don't do that and ensure-availability to an arbitrary machine, that machine still has to then be set up to run juju | 12:44 |
| jam | wallyworld_: presumably they had a knob available on "add-machine" so that they could decide what that exact machine was | 12:44 |
| jam | and couldn't we supply it on ensure-availability? | 12:44 |
| wallyworld_ | ah, i think the add-machine knob was to specify ssh: | 12:44 |
| wallyworld_ | that would take an existing machine and put juju on it | 12:45 |
| wallyworld_ | so i guess if we did juju ensure-availability --to maas-name:A,maas-name:B then that would have to ssh in and set up juju | 12:46 |
| jam | wallyworld_: the idea is that they are manually provisioning with ssh? | 12:47 |
| jam | "juju add-machine ssh:foo@bar" / | 12:47 |
| jam | I thought they were just doing "juju add-machine" but with maas-name | 12:47 |
| jam | to pick an explicit machine to proviison | 12:47 |
| jam | provision | 12:47 |
| wallyworld_ | they want to use whatever they use with add-unit | 12:47 |
| wallyworld_ | add-unit --to blah | 12:47 |
| jam | wallyworld_: add-unit or add-machine ? | 12:47 |
| wallyworld_ | same syntax as for add-unit | 12:47 |
| jam | wallyworld_: AFAIK you can't add-unit to a manually provisioned machine | 12:48 |
| wallyworld_ | so a machine number or mass name, right? | 12:48 |
| jam | wallyworld_: right, but that just requests a machine from the Provisioner, which lets us set up everything in cloud-init. | 12:48 |
| jam | wallyworld_: now... I *hope* all of the EnsureMongoServer stuff has gotten done correctly so we can create a state server late | 12:48 |
| jam | rather than only at cloud-init time. | 12:48 |
| jam | So I'd be *happy* if "juju ensure-availability --to 1" worked correctly. But For what they're doing what they need is | 12:49 |
| jam | "juju ensure-availability --to maas-name:A" | 12:49 |
| wallyworld_ | how does mass-name placement directive work then? does that assume a virgin maas machine? | 12:49 |
| jam | not "juju ensure-availability --to 1" (I think) | 12:49 |
| jam | wallyworld_: like tags | 12:49 |
| jam | wallyworld_: each machine just has a unique name | 12:49 |
| wallyworld_ | with tags, that assumes that a maas machine is not running, but tagged in maas, and so is then booted with cloud init etc? | 12:50 |
| jam | wallyworld_: right, same with maas-name | 12:50 |
| jam | maas-name is a Provisioning constraint (placement directive) | 12:50 |
| jam | give me a machine that fits this description | 12:51 |
| jam | which happens to uniquely address one machine ever | 12:51 |
| wallyworld_ | ok, so "juju ensure-availability --to maas-name:A" would be like add-machine but setting it up to run a state server etc | 12:51 |
| jam | wallyworld_: so... I'd like "juju ensure-availability --to 1,2" to work. But I'd really like to understand what Landscape is trying to do, as I feel that them doing "juju add-machine" first is actually bad practice | 12:51 |
| wallyworld_ | rather than host units | 12:51 |
| jam | wallyworld_: (I think everything still gets host units, but it would also get JobManageEnviron) | 12:52 |
| wallyworld_ | yep | 12:52 |
| wallyworld_ | i think we can tell them what best practice is | 12:52 |
| wallyworld_ | i think not using add-machine is the right way to go | 12:52 |
| jam | wallyworld_: I certainly understand their desire to say "ensure-availability and put it exactly here" | 12:53 |
| jam | And we want to definitely support that case. | 12:53 |
| jam | And ideally we could turn a machine into a proper state server late. | 12:53 |
| jam | You'd have to try it/check with nate to see if it might work today | 12:53 |
| jam | because we *shouldn't* be setting all that stuff in cloud-init now | 12:54 |
| jam | but doing it as part of EnsureMongoServer | 12:54 |
| mattyw | mgz, ping? | 12:54 |
| wallyworld_ | that sounds right | 12:54 |
| * fwereade has a doctor's appointment and may be gone for the rest of the afternoon, but will be back in the evening sometime | 12:56 | |
| wallyworld_ | fwereade: just ask him to warm his hands first | 12:56 |
| wallyworld_ | and use gloves | 12:56 |
| mattyw | wallyworld_, are you able to help solve problems with the landing bot? | 13:00 |
| mattyw | wallyworld_, my branch isn't being picked up https://github.com/juju/juju/pull/562 | 13:00 |
| wallyworld_ | mattyw: i may not have login credentials to jenkins handy, i'll have a look | 13:01 |
| mattyw | wallyworld_, thanks | 13:02 |
| voidspace | jam: ping | 13:10 |
| jam | voidspace: / | 13:10 |
| voidspace | I'm here for now... | 13:10 |
| jam | voidspace: sure, I'm just in the next meeting now | 13:10 |
| voidspace | jam: ah, ok | 13:10 |
| voidspace | I'm getting 12mbp downstream but can't connect to google hangouts | 13:11 |
| jam | voidspace: I'm usually EOD now, but I have a meeting with markr today | 13:11 |
| voidspace | jam: I'll create a PR with those extra Removes removed | 13:11 |
| voidspace | and look at GetStatus | 13:11 |
| jam | sounds good, just test it a bit as well | 13:11 |
| voidspace | ok | 13:11 |
| wallyworld_ | mattyw: i can't seem to ssh in to the slave to look, you'll have to ask mgz sorry | 13:12 |
| jam | voidspace: well maybe if you stopped streaming 12mbps of youtube videos your google hangouts would be more stable :) | 13:21 |
| hazmat | does api server returning non json results ring a bell to anyone.. (1.20.5-1.20.6) https://bugs.launchpad.net/juju-deployer/+bug/1364375 | 13:23 |
| mup | Bug #1364375: TypeError: expected string or buffer <oil> <juju-deployer:New> <https://launchpad.net/bugs/1364375> | 13:23 |
| jam | wwitzel3: ping about cloud-sigma reviews | 13:35 |
| jam | I know you mentioned you've been doing some, but I'm wondering if I'm missing the comments somewhere | 13:35 |
| mattyw | sinzui, ping? | 13:42 |
| sinzui | hi mattyw | 13:43 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1348477 | ||
| wwitzel3 | jam: no, you aren't missing them, I've only got my comments published for two of the PRs. I will get them published for #173 and #172 today. | 13:50 |
| === Ursinha-afk is now known as Ursinha | ||
| jam | wwitzel3: how are you managing to delay publishing them, writing them somewhere else? | 13:56 |
| wwitzel3 | jam: yeah, I've been doing most of the review locally since i'm trying to use the amazon and azure provider as examples. | 13:57 |
| wwitzel3 | jam: then I just take then and add them all to github at the same time | 13:57 |
| ericsnow | natefinch, perrito666, wwitzel3: standup? | 14:01 |
| wwitzel3 | jam: I'm still feeling like I'm not reviewing this correctly though. I feel like there is some bigger picture I am supposed to be aware of, but I'm just reviewing usage and ensuring common idioms. | 14:02 |
| wwitzel3 | jam: yeah, my notes for 172 are done, I will publish those right after standup and you can take a look. | 14:03 |
| perrito666 | here | 14:04 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1348477 1364410 | ||
| natefinch | ericsnow, wwitzel3, perrito666: trying to join... google is defying me | 14:07 |
| natefinch | ericsnow, wwitzel3, perrito666: chrome has been a bitch since it updated this morning. | 14:07 |
| perrito666 | natefinch: different browser? | 14:08 |
| cmars | sinzui, i'm going to take a look at LP: #1348477, since I'm already set up with access to a power machine | 14:20 |
| mup | Bug #1348477: userAuthenticatorSuite.TearDown failure <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged by cmars> <https://launchpad.net/bugs/1348477> | 14:20 |
| cmars | would latest master branch be a good place to start? | 14:20 |
| sinzui | thank you cmars...i think mattyw was saw it | 14:20 |
| mattyw | sinzui, we're going to work together | 14:21 |
| mattyw | sinzui, for moral support | 14:21 |
| dimitern | mattyw, perrito666, natefinch, what's that windows PR that needs reviewing? | 14:26 |
| mattyw | dimitern, which one? | 14:27 |
| dimitern | mattyw, something about logging? not sure.. | 14:27 |
| dimitern | mattyw, alexisb asked me to take a look as OCR | 14:27 |
| mattyw | dimitern, #652? | 14:27 |
| dimitern | mattyw, could be - looking | 14:27 |
| wwitzel3 | jam: also I just realized that my client review ended up on the environinstance review. Guess that is a problem with doing them offline and then adding them. | 14:32 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1348477 1364410 1364438 | ||
| === hatch__ is now known as hatch | ||
| voidspace | wwitzel3: ping | 15:12 |
| wwitzel3 | voidspace: pong | 15:13 |
| katco | evilnick: i understand you're the guy to talk to regarding juju documentation! please see https://github.com/juju/docs/pull/155 :) | 15:17 |
| voidspace | No wonder this test was passing every time no matter what I did to it | 15:45 |
| voidspace | "OK: 0 passed" | 15:45 |
| voidspace | gocheck takes a regex pattern not a glob... | 15:45 |
| evilnick | katco, okay! thanks! | 16:16 |
| evilnick | katco, that all sounds very terrifying, thanks | 16:24 |
| katco | evilnick: lol | 16:24 |
| katco | evilnick: the evil you know... etc. :) | 16:24 |
| evilnick | katco, *I* am the evil I know. But yeah. I might have to put some sort of warning for those of a nervous disposition on those docs | 16:25 |
| katco | evilnick: https://github.com/juju/juju/pull/630/files#diff-7f2ac2b013ef527684140a73c9773b54R110 | 16:26 |
| evilnick | katco :) | 16:27 |
| katco | evilnick: halloween isn't far away either. we could do a special on juju and "how the repear harvests" ;) | 16:28 |
| mattyw | perrito666, ping? | 16:53 |
| === urulama is now known as urulama-afk | ||
| perrito666 | mattyw: pong | 16:54 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1348477 1364410 1364438 1359837 | ||
| natefinch | ericsnow: can we move our 1:1 back another half hour? I just got back and need to do a few things first | 17:32 |
| ericsnow | natefinch: sure | 17:32 |
| mattyw | wwitzel3, ping? | 17:47 |
| wwitzel3 | mattyw: pong | 17:50 |
| mattyw | wwitzel3, I'm not sure how much you know about the presence watcher. I want to know if there's a reason why it uses mgo.Collection rather than taking a session and opening/closing it as needed | 17:51 |
| mattyw | wwitzel3, actually - I just noticed it does session.copy | 17:53 |
| wwitzel3 | mattyw: ok, I was going to say no I don't know why, so my response wasn't going to be very helpful | 17:55 |
| mattyw | wwitzel3, ok no problem | 17:55 |
| wwitzel3 | mattyw: yeah, that ping method copies the session, no sure why specifically | 17:55 |
| wwitzel3 | mattyw: actually looks like the prepare method does as well, maybe others | 17:56 |
| mattyw | wwitzel3, looks like a few of them | 17:56 |
| wwitzel3 | mattyw: yeah looks like most of them do | 17:56 |
| mattyw | wwitzel3, I'm looking into https://bugs.launchpad.net/juju-core/+bug/1348477 with cmars and it appears that it's the presence watcher that is returning the error in some cases | 17:56 |
| mup | Bug #1348477: userAuthenticatorSuite.TearDown failure <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged by cmars> <https://launchpad.net/bugs/1348477> | 17:56 |
| wwitzel3 | mattyw: ahh, interesting | 17:59 |
| ericsnow | natefinch: ready? | 18:00 |
| natefinch | ericsnow: yep | 18:01 |
| evilnick | katco, well, I think we have the trick sorted. not sure about the treat. | 18:01 |
| cmars | i'm having a gccgo toolchain issue on ppc64el and opened a bug, https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1364562 | 18:48 |
| mup | Bug #1364562: Intermittent go test crashes on ppc64el <gccgo-go (Ubuntu):New> <https://launchpad.net/bugs/1364562> | 18:48 |
| cmars | anyone experienced this? where should I look for support (if any is available)? | 18:49 |
| alexisb | cmars, I always start with dave cheney | 18:53 |
| alexisb | cmars, do you know if this is a known gcc-go toolchain issue? | 18:53 |
| alexisb | there are a few out there we seem to always hit | 18:54 |
| cmars | alexisb, will try to find out | 18:54 |
| alexisb | cmars, this one seems to come up a lot: | 18:54 |
| alexisb | https://bugs.launchpad.net/ubuntu/+source/gccgo-4.9/+bug/1362906 | 18:54 |
| mup | Bug #1362906: internal compiler error: in comparison, at go/gofrontend/expressions.cc:6508 <gcc-4.9 (Ubuntu):Fix Released> <gccgo-4.9 (Ubuntu):Invalid> <gcc-4.9 (Ubuntu | 18:54 |
| mup | Trusty):Invalid> <gccgo-4.9 (Ubuntu Trusty):Confirmed> <gcc-4.9 (Ubuntu Utopic):Fix Released> <gccgo-4.9 (Ubuntu Utopic):Invalid> <https://launchpad.net/bugs/1362906> | 18:54 |
| cmars | alexisb, yep, that one bit us last week. this one's weird, its as if the 'go test' command itself has the issue | 18:55 |
| alexisb | ok | 18:55 |
| cmars | davecheney, good morning, I have a gccgo question for you | 20:04 |
| cmars | i keep seeing these nil pointer refs and segfaults on ppc64el, https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1364562 | 20:05 |
| mup | Bug #1364562: Intermittent go test crashes on ppc64el <gccgo-go (Ubuntu):New> <https://launchpad.net/bugs/1364562> | 20:05 |
| cmars | known issue? any advice? | 20:05 |
| davecheney | cmars: sorry mate | 20:20 |
| davecheney | had to cloes that bug | 20:20 |
| davecheney | i dunno where you got that compiler from but it's to old | 20:20 |
| cmars | davecheney, what should I use then? | 20:20 |
| davecheney | cmars: can I ask a different question | 20:21 |
| davecheney | how did you hit this bug ? | 20:21 |
| cmars | mattyw and I were pairing on reviews, and it was raised by QA | 20:22 |
| cmars | we were looking at https://bugs.launchpad.net/juju-core/+bug/1348477 | 20:22 |
| mup | Bug #1348477: userAuthenticatorSuite.TearDown failure <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged by cmars> <https://launchpad.net/bugs/1348477> | 20:22 |
| cmars | so i apt-get install gccgo-go, rsync over a snapshot of master (because no github access in the lab) and then go test is falling all over the place | 20:23 |
| davecheney | cmars: yes that is because the compiler fix has not landed in main | 20:24 |
| cmars | ack | 20:24 |
| davecheney | i wish I could explain why | 20:24 |
| davecheney | just stear clear of gccgo bugs | 20:24 |
| davecheney | they need special care and attention to repro | 20:24 |
| davecheney | that bug isn't ppc64 related | 20:24 |
| davecheney | take the ppc tag off it | 20:24 |
| davecheney | yup, all those failures are the "known failures" that wallyworld_ is tracing | 20:25 |
| davecheney | tracking | 20:25 |
| cmars | ah, oh | 20:25 |
| cmars | ok | 20:25 |
| hazmat | gsamfira, ping | 20:46 |
| gsamfira | hazmat: pong | 20:46 |
| hazmat | gsamfira, sweet | 20:47 |
| hazmat | gsamfira, i was wondering about maybe getting juju to work on debian.. and figured your the right person to ask ;-) | 20:47 |
| davecheney | cmars: thanks for fixing the tag on that bug | 20:47 |
| davecheney | as you saw, it's one of our known failures, which ian logged on the 25th of july | 20:47 |
| gsamfira | debian should be easy :). All you need to fix up is the userdata :) | 20:48 |
| gsamfira | the rest is almost identical | 20:48 |
| davecheney | i can't speak for sinzui but I think there is a general agreement that those bugs are not build blockers | 20:48 |
| davecheney | for whatever value of living with broken windows you choose | 20:48 |
| gsamfira | hazmat: namely, making sure that you add proper repos before doing the apt-get install bits | 20:48 |
| hazmat | gsamfira, juju has a few hardcodes around the distro series detections bits | 20:49 |
| gsamfira | hazmat: and of course creating the repos for the bits you need :) | 20:49 |
| hazmat | gsamfira, nothing really needed re repos afaics, package names are all the same | 20:49 |
| gsamfira | hazmat: yes. Correct. But that should be easy to code. If it was easy for windows, debian should be 20 mins work :). Look in version/osversion.go | 20:50 |
| hazmat | gsamfira, i thought you might have already done the basics around centos | 20:50 |
| hazmat | windows is different enough that its a separate path through alot of the base, where as linux variants remove distro assumptions | 20:50 |
| gsamfira | hazmat: not yet. Merging the windows support took longer then expected. | 20:50 |
| gsamfira | hazmat: off the top of my head, for os detection: https://github.com/juju/juju/blob/master/version/supportedseries.go#L28 | 20:51 |
| gsamfira | osversion_linux.go should work for debian as well | 20:52 |
| hazmat | gsamfira, aha.. yeah. thats what i wanted | 20:52 |
| hazmat | thanks | 20:52 |
| * hazmat hacks | 20:52 | |
| gsamfira | hazmat: you are welcome. I remember juju having to add a few repos on older versions of ubuntu to get up to date packages | 20:53 |
| sinzui | davecheney, which bugs? | 20:53 |
| hazmat | gsamfira, yeah.. only on precise.. for mongo | 20:53 |
| gsamfira | also, for MaaS you need to enable debian as a supported OS | 20:53 |
| davecheney | sinzui: the list that wallyworld_ is curating | 20:53 |
| gsamfira | hazmat: talk to Blake Rouse, or Andreas about any plans to do so | 20:53 |
| hazmat | gsamfira, yeah.. they have user uploaded images in maas now.. its basically a masquerade there | 20:53 |
| davecheney | sinzui: https://docs.google.com/a/canonical.com/document/d/1k6o9yBzlJeRdaSuH3ZgPcdhL7SzhS2Ws7wDKSN99fAU/edit | 20:54 |
| hazmat | well maas 1.7 | 20:54 |
| davecheney | look ma, not on LP :) | 20:54 |
| hazmat | gsamfira, targeting gce atm though not maas, but yeah.. i had this discussion with them as well ;-) | 20:54 |
| gsamfira | hazmat: awesome :D | 20:54 |
| sinzui | davecheney, right, they are not release blockers. I am happy to defer them to a future release to deliver goodness to people sooner | 20:54 |
| gsamfira | hazmat: debian should be quick and easy to add | 20:54 |
| gsamfira | hazmat: centos will require a bit of abstraction on package management, and an updated cloud-init package. | 20:55 |
| gsamfira | hazmat: they still have an outdated package from the paleolithic | 20:55 |
| sinzui | davecheney, But I am happy to discuss the essential definition of 1.21.0 If stakeholders wont use it because they want something on that list...I think we will require the issue to be resilved | 20:55 |
| hazmat | gsamfira, i'm trying with manual provider to get started | 20:56 |
| hazmat | skip the cloud init bits.. | 20:56 |
| davecheney | sinzui: cool | 20:57 |
| gsamfira | hazmat: https://github.com/juju/juju/blob/master/version/supportedseries.go#L17 and https://github.com/juju/juju/blob/master/version/supportedseries.go#L75 might interest you as well | 20:57 |
| davecheney | i don't want to be part of that discussion | 20:57 |
| davecheney | only trying to help cmars | 20:57 |
| gsamfira | happy hacking :D | 20:57 |
| gsamfira | hazmat: looking forward to seeing debian work :D | 20:58 |
| hazmat | interesting... | 21:05 |
| menn0 | _thumper_, waigani: morning | 21:05 |
| hazmat | juju upgrade juju -> error message can't upload charm http://pastebin.ubuntu.com/8218255/ silly | 21:06 |
| hazmat | argh.. cpu-checker | 21:09 |
| hazmat | so not needed.. its line two lines of shell script to check for kvm support in /proc/cpuinfo output | 21:09 |
| hazmat | its like | 21:09 |
| alexisb | hazmat, ping | 21:10 |
| mbruzek | Hello juju-dev I am having a tools problem with 1.20.6 and I was hoping someone could have a look at the bug https://bugs.launchpad.net/juju-core/+bug/1364631 | 21:33 |
| mup | Bug #1364631: juju fails to find matching tools <juju-core:New> <https://launchpad.net/bugs/1364631> | 21:33 |
| mbruzek | It may _look_ like a dupe of https://bugs.launchpad.net/juju-core/+bug/1309805 but I do not believe it is. | 21:33 |
| mup | Bug #1309805: LXC / Local provider machines do not boot without default-series <config> <local-provider> <lxc> <juju-core:Fix Released by jose> <https://launchpad.net/bugs/1309805> | 21:33 |
| sinzui | mbruzek, I doubt the issue relates to the bug. What is your tools-metadata-url set to? Are you are a private network? | 21:39 |
| sinzui | mbruzek, There was a subtle change to the rules for locating tools in 1.20.6. The command line didn't change to prevent regressions, but the rules certainly are different | 21:39 |
| mbruzek | sinzui, I have no tools-metadata-url set in environments.yaml for local and not on a private network this is my laptop | 21:39 |
| sinzui | mbruzek, very interesting, do you see the trusty precise tools being uploaded when you first bootstrap? | 21:40 |
| mbruzek | sinzui, I do I also have a pastebin of the bootstrap with --debug | 21:40 |
| mbruzek | http://paste.ubuntu.com/8218239/ | 21:41 |
| sinzui | mbruzek, thanks I was going to ask about that. So bootstrap confirms the tools were uploaded and the metadata was generated | 21:42 |
| sinzui | mbruzek, is it the deployments that didn't find tools? | 21:43 |
| mbruzek | sinzui, it looks to me like the tools are found and downloaded, but never found by the machines. I can not deploy cs:precise/ubuntu | 21:44 |
| sinzui | mbruzek, We need the cloud-init-output.log from machine-1 | 21:45 |
| mbruzek | sinzui, sure, looking for that now... | 21:46 |
| sinzui | mbruzek, I did this today but lost the command to copy that file from the container to $HOME to read it before it is destroyed | 21:47 |
| mbruzek | /home/mbruzek/.juju/local/cloud-init-output.log | 21:48 |
| mbruzek | Is that the one you are looking for? | 21:48 |
| sinzui | no | 21:48 |
| sinzui | mbruzek, we need to log from the actual container that failed, not your localhost (state-server) | 21:50 |
| sinzui | mbruzek, I did something like this today after I saw the status of a container say there was an error | 21:50 |
| sinzui | sudo cp /var/lib/lxc/jenkins-local-precise-utopic-amd64-machine-1/rootfs/var/log/cloud-init-output.log ./ | 21:50 |
| mbruzek | sinzui, I can not juju ssh to those machines to get it. | 21:50 |
| sinzui | mbruzek, you can always ssh to the machines juju created even when jujud isn't installed. juju provisions with your keys so you just ssh to the ip address | 21:51 |
| mbruzek | sinzui, The machines do not have an IP address they are in a pending state | 21:52 |
| sinzui | mbruzek, sudo lxc-ls --fancy will always show the truth | 21:56 |
| sinzui | mbruzek, juju often claims it cannot create machines/containers because the jujud didn't report...but lots of things happen before jujud is downloaded as a tool | 21:57 |
| mbruzek | http://pastebin.ubuntu.com/8218539/ | 21:57 |
| sinzui | mbruzek, that isn't a tools error. you cannot get a tools error without a machine. what is juju status showing? | 21:58 |
| mbruzek | sinzui, http://pastebin.ubuntu.com/8218548/ | 21:59 |
| mbruzek | juju status is reporting "no matching tools available" | 21:59 |
| sinzui | mbruzek, I award you a gold star for finding a awesome cryptic bug | 22:00 |
| * mbruzek bows | 22:01 | |
| sinzui | mbruzek, you are on trusty deploying a precise charm right? | 22:01 |
| _thumper_ | o/ | 22:01 |
| mbruzek | sinzui, yes. | 22:01 |
| === _thumper_ is now known as thumper | ||
| mbruzek | sinzui, you can see that I tried to deploy precise first and then trusty. | 22:01 |
| sinzui | mbruzek, did you set default-series in environments.yaml? | 22:02 |
| mbruzek | It *was* set when I reported the bug, but I suspected that was an issue so I removed default-series for this particular bootstrap | 22:02 |
| mbruzek | sinzui, I will add it again but charms will not deploy | 22:03 |
| sinzui | mbruzek, I am just looking for differences between my own setup. I am trusty with default-series of trusty | 22:03 |
| waigani | thumper: the Action field in ModifyUsersStruct, where are we using that? | 22:04 |
| mbruzek | sinzui, I am setting default-series, do you want me to set it to trusty or precise? | 22:04 |
| sinzui | mbruzek, trusty | 22:04 |
| thumper | waigani: we should be using that in the server side, check that the action = 'add' and error if it doesn't with 'unknown action' | 22:04 |
| thumper | waigani: the idea being that we'll implement 'remove' | 22:05 |
| waigani | thumper: but isn't the action determined by the function called: ShareEnvironment would always add a user, so what value does the check have in there? | 22:06 |
| thumper | waigani: the current client api will always add to the server api | 22:07 |
| thumper | waigani: we will add another client api that calls the same server api with a different action | 22:07 |
| thumper | the server api stays the same | 22:07 |
| thumper | but gains another action | 22:07 |
| thumper | does that make sense? | 22:07 |
| mbruzek | sinzui, http://pastebin.ubuntu.com/8218617/ | 22:08 |
| waigani | thumper: what do the cmds look like? | 22:08 |
| thumper | what commands? | 22:08 |
| thumper | juju ? | 22:08 |
| thumper | we haven't decided yet | 22:08 |
| waigani | e.g. juju share add user@pro | 22:08 |
| thumper | no | 22:08 |
| thumper | juju share user@pro user2@pro | 22:08 |
| thumper | perhaps... | 22:08 |
| thumper | juju share --remove user@pro | 22:08 |
| waigani | ah | 22:08 |
| thumper | default is to share with someone | 22:09 |
| thumper | but we need to allow removal | 22:09 |
| waigani | so that is why we need the actions | 22:09 |
| thumper | yes | 22:09 |
| waigani | got it | 22:09 |
| thumper | there will be two different client api calls | 22:09 |
| thumper | or... | 22:09 |
| thumper | maybe later, one call | 22:09 |
| thumper | with an action option | 22:09 |
| thumper | but the server needs to support the action | 22:10 |
| thumper | as that is the bit that shouldn't change | 22:10 |
| waigani | should I make the actions consts and where should they live? | 22:10 |
| thumper | apiserver code | 22:10 |
| waigani | ok | 22:10 |
| thumper | with the params | 22:10 |
| waigani | right | 22:10 |
| thumper | consts are preferred but not essential | 22:10 |
| waigani | iotas ? | 22:11 |
| thumper | cmars: around? | 22:11 |
| thumper | no, strings | 22:11 |
| waigani | ok | 22:11 |
| thumper | "add", "remove" | 22:11 |
| thumper | better for understanding the wire protocol | 22:11 |
| cmars | thumper, here | 22:11 |
| waigani | makes sense, going over the wire | 22:11 |
| thumper | cmars: are we meeting today? | 22:11 |
| cmars | thumper, we are. thought it was monday, sorry | 22:12 |
| thumper | :) | 22:12 |
| sinzui | mbruzek, I am trying juju sync-tools to change the tools in the env, if that works, then we know something more | 22:14 |
| sinzui | mbruzek, oh! | 22:14 |
| mbruzek | sinzui, ? | 22:15 |
| sinzui | before you try sync-tools, pastebin a copy of ~/.juju/local/storage/tools/streams/v1/com.ubuntu.juju\:released\:tools.json | 22:15 |
| sinzui | mbruzek, this is mine: http://pastebin.ubuntu.com/8218656/ | 22:16 |
| sinzui | mbruzek, sync-tools is not fast :( It will pull down about 8 tools for precise and trusty | 22:17 |
| mbruzek | http://paste.ubuntu.com/8218657/ | 22:18 |
| sinzui | mbruzek, that looks fine to me | 22:18 |
| mbruzek | sinzui, Looking at the diff of those 2, looks very similar to me. | 22:19 |
| wallyworld_ | sinzui: mbruzek: i haven't read all the backscroll in detail. 1. you have found a tools bug? 2. if you want to juju ssh into a local provider lxc instance, you need to use sudo ssh or else you get a permission denied error | 22:22 |
| sinzui | wallyworld_, I just updated the bug https://bugs.launchpad.net/juju-core/+bug/1364631 | 22:23 |
| mup | Bug #1364631: juju fails to find matching tools <deploy> <local-provider> <lxc> <juju-core:New> <https://launchpad.net/bugs/1364631> | 22:23 |
| mbruzek | wallyworld_, I don't think my lxc instances are coming up. | 22:23 |
| mbruzek | sinzui, thanks for the update | 22:24 |
| mbruzek | wallyworld_, I believe I have found a tools related bug. I can not deploy and it looks to be tool related. | 22:24 |
| sinzui | mbruzek, It took me 15 minutes to sync-tools. I forgot that it would download utopic too. I wonder if matching tools were found after you had the non .1 versions | 22:25 |
| mbruzek | sinzui, I have not yet synced would you like me to? | 22:25 |
| wallyworld_ | sinzui: mbruzek: i can retest with 1.20 trunk, but last time i tried it last week, there were no issues that i know of. so i'm sad if there's a new problm :-( | 22:25 |
| sinzui | mbruzek, Lp is timing out. I am trying to set the bug to 1.21-alpha1 with a suggestion to backport to 1.20.7 | 22:25 |
| wallyworld_ | sinzui: mbruzek: there is a potential issue in trunk because of aria2 not being found - that is going to be reverted | 22:26 |
| wallyworld_ | that issue will cause the lxc container to come up but tools copy into the container to fail | 22:26 |
| sinzui | wallyworld_, I have been using 1.20.6 all day, and I cannot reproduce it myself. I even did this same kind of deployment this morning | 22:27 |
| wallyworld_ | :-( that will make it hard to fix | 22:27 |
| sinzui | wallyworld_, failure to download tools means we get a machine and a nice log. | 22:27 |
| wallyworld_ | so we will need all the logs from /var/lib/juju/containers | 22:27 |
| wallyworld_ | let's get these attached to the bug if possible | 22:28 |
| sinzui | mbruzek, does this show anything interesting about deploy: juju debug-log -l ERROR --replay | 22:29 |
| sinzui | mbruzek, or just attach the .juju/local/log/all-machines.log to the bug | 22:29 |
| mbruzek | OK. | 22:29 |
| wallyworld_ | and the /var/lib/juju/containers logs | 22:30 |
| wallyworld_ | ^^^^ these are important as they container cloud init data | 22:30 |
| wallyworld_ | contain | 22:30 |
| sinzui | wallyworld_, there is no cloud init because there were not tools selected | 22:30 |
| mbruzek | wallyworld_, that path contains 4 directories, which files do you want from there? | 22:30 |
| sinzui | wallyworld_, sudo lxc-ls --fancy shows no containers being created | 22:31 |
| wallyworld_ | mbruzek: all of them if possible, in tar.gz | 22:31 |
| mbruzek | http://pastebin.ubuntu.com/8218736/ | 22:31 |
| wallyworld_ | sinzui: oh, ok. so it's failing really early | 22:31 |
| sinzui | wallyworld_, mbruzek /var/lib/juju/containers The four containers are the new and old template containers I think | 22:31 |
| wallyworld_ | mbruzek: ok, just the ones with lxc | 22:31 |
| wallyworld_ | the ones without are the old directories and can be deleted | 22:32 |
| mbruzek | wallyworld_, uploaded to https://bugs.launchpad.net/juju-core/+bug/1364631 | 22:36 |
| mup | Bug #1364631: juju fails to find matching tools <deploy> <local-provider> <lxc> <juju-core:Triaged> <https://launchpad.net/bugs/1364631> | 22:36 |
| wallyworld_ | mbruzek: ty. can you also include all-machines.log | 22:36 |
| mbruzek | wallyworld_, on it | 22:36 |
| wallyworld_ | ty | 22:36 |
| mbruzek | done. | 22:37 |
| mbruzek | sinzui, your command shows only 2 lines | 22:40 |
| mbruzek | machine-0: 2014-09-02 22:05:47 ERROR juju.worker runner.go:218 exited "api": unable to connect to "wss://localhost:17070/" | 22:40 |
| mbruzek | machine-0: 2014-09-02 22:06:20 ERROR juju.provisioner provisioner_task.go:418 cannot find tools for machine "1": no matching tools available | 22:40 |
| sinzui | mbruzek, and that one extra line is the difference from me. | 22:42 |
| mbruzek | sinzui, you mentioned that you saw this problem earlier today? | 22:42 |
| sinzui | mbruzek, no, I have never seen this problem | 22:43 |
| sinzui | I have done deployments exactly like yours today without incident | 22:43 |
| wallyworld_ | mbruzek: can you please upload your ~/.juju/local/storage/tools ? | 22:44 |
| wallyworld_ | so we can see what tools and metadata were generated at bootstrap | 22:45 |
| sinzui | wallyworld_, it is in the pastbin I added to the bug | 22:47 |
| wallyworld_ | ok, ta, looking | 22:47 |
| sinzui | wallyworld_, mbruzek , but I didn't ask to confirm the tools were there and readable. We just verified http://paste.ubuntu.com/8218657/ | 22:48 |
| mbruzek | looking | 22:48 |
| mbruzek | everything looks readable by mbruzek | 22:50 |
| wallyworld_ | mbruzek: sinzui: that pastebin is the products file, if there the index file also? | 22:50 |
| wallyworld_ | it's the index file that appears to be the problem | 22:50 |
| mbruzek | $ ls -l streams/v1/ | 22:51 |
| mbruzek | total 8 | 22:51 |
| mbruzek | -rw------- 1 mbruzek mbruzek 1671 Sep 2 17:05 com.ubuntu.juju:released:tools.json | 22:51 |
| mbruzek | -rw------- 1 mbruzek mbruzek 498 Sep 2 17:05 index.json | 22:51 |
| mbruzek | wallyworld_, do you need to see index.json? | 22:51 |
| wallyworld_ | yup | 22:51 |
| wallyworld_ | that's what the error message in machines.og refers to | 22:51 |
| mbruzek | http://paste.ubuntu.com/8218852/ | 22:52 |
| wallyworld_ | hmmm, looks ok | 22:52 |
| mbruzek | wait | 22:52 |
| mbruzek | fetchData failed for "http://10.0.3.1:8040/tools/streams/v1/index.sjson": file "tools/streams/v1/index.sjson" not found | 22:53 |
| mbruzek | the file is named index.json | 22:53 |
| mbruzek | typo? | 22:53 |
| mbruzek | or is that just a different file? | 22:54 |
| wallyworld_ | mbruzek: no, it first looks for the sjosn version | 22:56 |
| wallyworld_ | so that's ok | 22:56 |
| mbruzek | OK | 22:56 |
| wallyworld_ | mbruzek: can get fetch http://10.0.3.1:8040/tools/streams/v1/index.json ? | 22:56 |
| wallyworld_ | subst localhost for 10.0.3.1 | 22:57 |
| wallyworld_ | the sjson is signed json metadata | 22:57 |
| mbruzek | $ wget https://localhost:8040/tools/streams/v1/index.json | 22:58 |
| mbruzek | --2014-09-02 17:57:47-- https://localhost:8040/tools/streams/v1/index.json | 22:58 |
| mbruzek | Resolving localhost (localhost)... 127.0.0.1 | 22:58 |
| mbruzek | Connecting to localhost (localhost)|127.0.0.1|:8040... failed: Connection refused. | 22:58 |
| wallyworld_ | we use signed json on the official simplestreams website | 22:58 |
| wallyworld_ | do you still have your local provider running? | 22:58 |
| wallyworld_ | or have you destoyed it? | 22:58 |
| mbruzek | still running | 22:58 |
| wallyworld_ | hmm, maybe you need to leave the 10.0.3.1 | 22:58 |
| wallyworld_ | i'm just curious as to what data is actually served up | 22:59 |
| wallyworld_ | just to rule out it is not providing different data to what we think | 22:59 |
| sinzui | wallyworld_, mbruzek NO ONE NEEDS sjson, None of us have keys to sign it | 23:00 |
| sinzui | only streams.canonical.com gets signed metadata | 23:01 |
| wallyworld_ | yep | 23:01 |
| mbruzek | wallyworld_, leaving 10.0.3.1 worked | 23:01 |
| mbruzek | http://paste.ubuntu.com/8218897/ | 23:01 |
| sinzui | mbruzek, I thought you were on local host | 23:02 |
| wallyworld_ | mbruzek: there's the problem | 23:02 |
| mbruzek | why does it say ppc64? | 23:02 |
| wallyworld_ | exactly | 23:02 |
| mbruzek | sinzui, I AM on the local provider on my intel laptop | 23:02 |
| wallyworld_ | it's generating tools metadata for ppc64 | 23:02 |
| sinzui | mbruzek, your bug gets more awesome by the hour | 23:02 |
| wallyworld_ | mbruzek: your local laptop isn't ppc64 is it? :-) | 23:03 |
| mbruzek | no it is not | 23:03 |
| wallyworld_ | not that i think it is | 23:03 |
| mbruzek | what would cause the arch to be incorrect. | 23:04 |
| mbruzek | ? | 23:04 |
| wallyworld_ | well, now we know why it can't find tools, just have to fogure out how the fark it's generating ppc64 metadata | 23:04 |
| wallyworld_ | don't know right now, i'll do a little digging in the code | 23:04 |
| mbruzek | wallyworld_, OK. | 23:05 |
| sinzui | wallyworld_, mbruzek is one of the few people who can develop on ppc64, Is there a backdoor to select arch that mbruzek could have tripped in his shell env? | 23:05 |
| sinzui | mbruzek, I if you run sync-tools, then return in 30 minutes, you will have every tool and I suspect you can deploy. | 23:06 |
| wallyworld_ | something is making juju think it needs ppc64 tools | 23:07 |
| mbruzek | wallyworld_, do you want me to do that? Will that provide anything useful for your debug? | 23:07 |
| wallyworld_ | not straight away | 23:07 |
| mbruzek | sinzui, I dumped my env vars and grepped for ppc | 23:07 |
| wallyworld_ | let me first check to see how juju gets the arch it thinks it needs | 23:08 |
| sinzui | well I think uname -p says what we expect to be selected | 23:08 |
| mbruzek | $ uname -p | 23:08 |
| mbruzek | x86_64 | 23:08 |
| wallyworld_ | yes, that's what i think too, but something else must be happening | 23:08 |
| wallyworld_ | i can't think of why it then writes ppc64 | 23:08 |
| wallyworld_ | mbruzek: when possible, i'd love to see a copy of the output when you "juju bootstrap --debug --show-log" | 23:19 |
| wallyworld_ | that will contain the info needed to delve deeper into this | 23:19 |
| wallyworld_ | to see where the tools are getting generated | 23:19 |
| wallyworld_ | mbruzek: also a listing of the ~/.juju/local/storage/tools/releases directory | 23:22 |
| mbruzek | mbruzek@workhorse:~/.juju/local/storage/tools/releases$ ls -l | 23:23 |
| mbruzek | total 16008 | 23:23 |
| mbruzek | -rw------- 1 mbruzek mbruzek 8195954 Sep 2 17:05 juju-1.20.6.1-precise-amd64.tgz | 23:23 |
| mbruzek | -rw------- 1 mbruzek mbruzek 8195954 Sep 2 17:05 juju-1.20.6.1-trusty-amd64.tgz | 23:23 |
| mbruzek | Let me destroy the environment and get that for you | 23:24 |
| mbruzek | http://paste.ubuntu.com/8219045/ | 23:26 |
| wallyworld_ | thank you | 23:27 |
| mbruzek | ~$ juju bootstrap --debug --show-log -e local 2>&1 | tee juju_bootstrap_4.txt | 23:27 |
| mbruzek | That is how I ran it | 23:27 |
| wallyworld_ | mbruzek: that log appears to show everything is correct at first glance, ie amd64 tools metadata, nt ppc64 | 23:28 |
| wallyworld_ | what does the index.json file contain now? | 23:29 |
| wallyworld_ | since this looks perfectly as expected: | 23:34 |
| wallyworld_ | 2014-09-02 23:25:37 DEBUG juju.environs.simplestreams simplestreams.go:367 read metadata index at "file:///home/mbruzek/.juju/local/storage/tools/streams/v1/index.json" | 23:34 |
| wallyworld_ | 2014-09-02 23:25:37 DEBUG juju.environs.simplestreams simplestreams.go:534 candidate matches for products ["com.ubuntu.juju:14.04:amd64"] are [{Tue, 02 Sep 2014 18:25:36 -0500 products:1.0 content-download [] streams/v1/com.ubuntu.juju:released:tools.json [com.ubuntu.juju:12.04:amd64 com.ubuntu.juju:14.04:amd64]}] | 23:34 |
| wallyworld_ | 2014-09-02 23:25:37 DEBUG juju.environs.simplestreams simplestreams.go:847 finding products at path "streams/v1/com.ubuntu.juju:released:tools.json" | 23:34 |
| wallyworld_ | 2014-09-02 23:25:37 DEBUG juju.environs.simplestreams simplestreams.go:885 metadata: &{map[com.ubuntu.juju:12.04:amd64:{ 1.20.6.1 amd64 map[20140902:0xc21000a360]} com.ubuntu.juju:14.04:amd64:{ 1.20.6.1 amd64 map[20140902:0xc21000a660]}] map[] Tue, 02 Sep 2014 18:25:36 -0500 products:1.0 com.ubuntu.juju:released:tools } | 23:34 |
| wallyworld_ | 2014-09-02 23:25:37 INFO juju.environs.bootstrap bootstrap.go:58 newest version: 1.20.6.1 | 23:34 |
| wallyworld_ | 2014-09-02 23:25:37 INFO juju.environs.bootstrap bootstrap.go:86 picked bootstrap tools version: 1.20.6.1 | 23:34 |
| mbruzek | wallyworld_, the wget gives me ppc64. | 23:37 |
| mbruzek | "com.ubuntu.juju:12.04:ppc64", | 23:37 |
| mbruzek | "com.ubuntu.juju:14.04:ppc64" | 23:37 |
| wallyworld_ | wtf | 23:37 |
| mbruzek | I don't know! | 23:37 |
| wallyworld_ | the content of the file on disk? | 23:38 |
| wallyworld_ | says ppc64? | 23:38 |
| mbruzek | give me location again? | 23:38 |
| wallyworld_ | "file:///home/mbruzek/.juju/local/storage/tools/streams/v1/index.json | 23:38 |
| mbruzek | "com.ubuntu.juju:12.04:amd64", | 23:38 |
| mbruzek | "com.ubuntu.juju:14.04:amd64" | 23:38 |
| mbruzek | this is a mystery ! | 23:39 |
| wallyworld_ | yes | 23:39 |
| mbruzek | Where is it getting ppc64. | 23:39 |
| wallyworld_ | so if you wget from http://10.0.3.1/.... you get ppc64 | 23:39 |
| mbruzek | yes | 23:39 |
| davecheney | mbruzek: netstat -anp | 23:40 |
| davecheney | who is listening on 10.0.3.1 | 23:40 |
| mbruzek | oh crap | 23:40 |
| mbruzek | sinzui, was right. | 23:40 |
| wallyworld_ | what did he say? | 23:41 |
| mbruzek | I am running sshuttle -r ubuntu@stilson-01 10.0.3.0/24 so I can see the local systems on the power machine stilson-01 | 23:41 |
| davecheney | bad ida | 23:41 |
| davecheney | idea | 23:41 |
| wallyworld_ | lol | 23:42 |
| davecheney | especially on that range | 23:42 |
| wallyworld_ | well that explains a lot | 23:42 |
| wallyworld_ | i was beginning to worry | 23:42 |
| mbruzek | Doh! | 23:42 |
| mbruzek | I am sorry | 23:42 |
| wallyworld_ | no problemo | 23:42 |
| wallyworld_ | glad we found the problem | 23:42 |
| davecheney | so, has this fixed all the problems ? | 23:43 |
| davecheney | or just some of them ? | 23:43 |
| mbruzek | bootstrapping. | 23:43 |
| wallyworld_ | what is "all the problems"? | 23:43 |
| davecheney | wallyworld_: all the ones mbruzek reported to me earlier | 23:43 |
| davecheney | with tools selection being screwed | 23:43 |
| wallyworld_ | yes, i think this will fix all that | 23:44 |
| davecheney | good | 23:44 |
| wallyworld_ | i hope anyway | 23:44 |
| davecheney | i hope everyone learnt a valuable lesson :) | 23:44 |
| mbruzek | sorry guys | 23:44 |
| davecheney | np | 23:44 |
| wallyworld_ | no need to apologise :-) | 23:44 |
| davecheney | we found the problem | 23:44 |
| wallyworld_ | we introduce enough bugs of our own :-) | 23:45 |
| davecheney | mbruzek: your pennence is to write up what happened | 23:45 |
| davecheney | and forward it to anyone who is using sshuttle | 23:45 |
| mbruzek | yes sir | 23:45 |
| mbruzek | I can confirm that the system bootstraps now, and I can deploy both precise and trusty ubuntu charms. | 23:46 |
| wallyworld_ | \o/ | 23:49 |
| davecheney | alexisb: i've finished my review of the gccgo4.9 bugs | 23:49 |
| davecheney | please see my email for details | 23:50 |
| menn0 | anyone able to review this? https://github.com/juju/juju/pull/660 | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!