/srv/irclogs.ubuntu.com/2013/08/27/#juju-dev.txt

=== weblife is now known as web-brandon
axwthumper: what's your stance  on things like ctx/txn?00:43
thumperaxw: I strongly prefer what uncle Bob calls "Unse Pronounceable Names"01:44
thumperpersonally I use context01:45
thumperand prefer transaction01:45
axwthumper: ok. my reasoning is that, for things like ctx, the translation to context is automatic (for me)01:45
axwso I pronounce it "context"01:46
thumperbut the point is, you need to translate01:46
thumperthere is a cognitive process there01:46
thumperthat takes ctx, and makes context01:46
axwnot consciously01:46
thumperbut it is there01:46
thumperwhen I see it, I still see "see tee ex"01:46
davecheneysure, so is translating source code into your native language01:46
davecheneyi think it's a very minimal cost01:46
davecheneyand we're trained to do it very effectively01:46
thumperdavecheney: but writing code is all about people reading it01:46
axwif it's not the same for everyone that's fair enough01:46
thumperaxw: I agree that some don't have that01:47
thumperbut do you have a problem reading "context" as a variable?01:47
thumperdavecheney: computers are easier to train01:47
axwthumper: only when it means the source line > 80 chars, or becomes a series of ugly lines01:47
* davecheney is sad that we can't apply common sense here01:48
thumperaxw: I agree, in which case the logic should be simplified01:48
thumpercomputers are good at optimising01:48
thumperdavecheney: common sense isn't as common as we'd hope01:48
thumperaxw: I remember writing some code one, it was c++01:49
thumperwhere I managed to use a single for_each function01:49
axwthumper: btw I'm not advocating ctx necessarily, just playing devil's advocate01:49
thumperin the end though, I rewrote it with a normal for loop that took two or three more lines01:49
thumperbecause it was more readable01:49
thumperone of my favourite programming mantras is:01:49
thumperjust because you can, doesn't mean you should01:50
thumperhowever, smart C++ programmers would have been able to see what my extremely clever function was doing01:50
thumperbut it wasn't obvious01:50
thumperI'd go for obvious over clever every time01:50
thumperhowever, I feel that there are some on our team that prefer clever01:51
axwthumper: agreed. I used to fall into the clever code trap, but try hard to steer away from it now. It doesn't scale well in teams, and I tend to forget what my code is meant to do01:51
thumperagreed01:51
* axw remembers in horror at his former colleagues' naming conventions01:52
axwor lack thereof01:53
axwbasically all the variables would be the first letter of the variable's compound word type01:53
axwvar atp AggregateTableProvider01:53
axwfun times01:53
thumperhaha01:58
axwbbl, lunch01:59
=== jtv2 is now known as jtv
bigjoolsthumper: txn reads perfectly well! :)02:24
bigjoolsthumper: however when I see ctx my mind pronounces it as "cuntox"02:25
thumperheh02:25
bigjoolsblame big kev ...02:25
thumperwell, everyone is different02:25
bigjoolsyeah02:25
bigjoolswhich is precisely why you are right02:25
thumperthe idea is to code for the majority02:25
kvtpoking through the state pkg, and noticing some odd items a couple of the docs have counts, like serviceDoc has relation count, relations have unitcount.. is that just an optimization vs querying those?03:03
thumperkvt: probably03:49
davecheneybigjools: ping04:26
bigjoolsdavecheney: hail04:27
* thumper read that as 'fail'04:28
thumperperhaps I have too much on my mind04:28
bigjoolsunderstandable04:28
thumperjam: I've added Dubai to my clock city list so I can know what time it is there.04:55
jamthumper: :)04:56
thumperjam: so you are 8 hours out from me04:56
thumperjam: got time for a quick hangout?04:56
jamthumper: right. I'm right at the end of your day, I believe. though it depends whether I wake up and poke around before officially "starting".04:56
jamsure04:56
* thumper starts one04:56
thumperhttps://plus.google.com/hangouts/_/f16d2fd28ebc5923a5ceb1a2e1ffc57f5b152404?hl=en04:57
thumperjam: ^^04:57
jamthumper: trying to connect, it rings on my phone where I don't want to connect04:58
jamand isn't loading on the desktop where I do04:58
thumperhaha :(04:58
thumperhmm..04:58
thumperjam: did you want to set one up04:58
thumper?04:58
jamlet me make sure I'm signed into all of my accounts quickly04:59
jamthumper: I'll call you back, it is just getting stuck at "joining video call".05:00
thumperkk05:01
jamcalling you05:02
jamhttps://plus.google.com/hangouts/_/f16d2fd28ebc5923a5ceb1a2e1ffc57f5b15240405:02
jamthumper: ^^05:02
jamI really don't prefer the "calling" style of hangout, vs just creating one and having people join it.05:02
thumpernight people05:41
=== tasdomas_afk is now known as tasdomas
davecheneybigjools: 16:19 < kurt_> davecheney: do you know this error? error: cannot create bootstrap state file: gomaasapi: got error back from server: 400 BAD REQUEST06:21
davecheneyany ideas ?06:21
bigjoolsdavecheney: yes, maas was not accepting empty files.  There's an SRU about to go out for it06:22
bigjoolsif desperate, use the daily PPA06:22
davecheneyok, will tell 'em06:24
axwbigjools: did you see my comment on the gwacl/vhd bug?06:37
bigjoolsaxw: from this morning?06:37
bigjoolsif so yes, and I replied06:38
axwoh06:38
axw(yes)06:38
axwbigjools: thanks. didn't get an update - I thought it would auto-subscribe me06:40
davecheneyaxw: hang on, you are upset because LP _didn't_ spam you ?06:42
davecheneyyou'll quickly change your tune06:43
bigjoolshaha06:48
bigjoolsmost of the spam I get is because stupid people stupidly do stupid team nesting in teams that have stupid subscriptions06:49
bigjoolsthis is why I left ~uju as soon as I could06:49
bigjools~juju even06:49
davecheneyyes, that guy in china who subscribes me to bugs with the intel chipset06:49
davecheneyWTF06:49
jamallenap: poke about https://code.launchpad.net/~allenap/juju-core/makefile-stuff/+merge/181113  I commented on it, but haven't heard a response from you yet.06:53
jamaxw: is there a reason https://code.launchpad.net/~axwalk/juju-core/testing-mgo-nounixsocket/+merge/181218 isn't landed?06:54
axwjam: nope, I just forgot to. thanks - I'll do it now06:55
jamaxw: I was guessing so. I'm just going through activereviews and cleaning it out.06:56
axwjam: looks like the bot's /tmp is full of gocheck dirs07:13
axware you able to clean that?07:13
jamaxw: if you're able to see it, you're able to clean it, but I'll do it07:13
axwI can see it because my MP failed07:13
axwtests failed, because /tmp/gocheck-blah exists07:13
axwjam: gocheck doesn't set a seed for rand when it generates the temp dirs07:14
rogpeppemornin' all07:39
jammorning rogpeppe07:54
rogpeppejam: hiya07:54
jamrogpeppe: I have a couple more CLI API patches up that would appreciate a quick review.08:01
rogpeppejam: ok, will have a look08:01
jamhttps://codereview.appspot.com/12744052/08:01
jamand08:01
jamhttps://codereview.appspot.com/12744053/08:02
rogpeppejam: BTW we can work around the int64 vs float64 thing if we want to, but given that the API is accessed from javascript, I'm not entirely sure we should.08:04
jamrogpeppe: right. My concern is if someone out there is getting their settings as YAML and then parsing it into a struct that requires an int.08:05
jamWe do have a "type" object in that struct, though.08:05
jamSo the other option is that GetConfig/SetConfig start understanding the actual content of those messages08:05
jambut I'd like to just punt on all that :)08:06
jamrogpeppe: gustavo mentioned we can change the decode function to "UseNumber" but I'm not sure what that actually changes? If it doesn't have a decimal you get an int64?08:07
jamIt uses arbitrary precision integers?08:07
rogpeppejam: you can change it to get any type you want - one possibility is just to use a string.08:09
jamrogpeppe: I tracked it down, it is "json.Number" which is actually a string, and then you "Number.Float64()"08:10
jamit still wouldn't let us use DeepEquals easily08:10
jambut it would let us get what we want later on.08:10
jamBut if we have to do that step08:10
jamwe can int64(floatValue)08:10
TheMuejam: thx for review. setting an option to nil means unsetting it, so that the default is valid. and setting an option to "" will not be translated to nil anymore (as before). so for string options "" is a valid value while it's an error for other ones (like in pyjuju).08:10
jamand it just matters when you have > 40bits of precision in your int7408:10
jamint08:10
jamTheMue: right that is where I thought we were going: Allow "" to be a valid setting, and use nil to indicate you want a default value. So your patch fits that just fine.08:11
rogpeppejam: exactly08:11
rogpeppejam: and that might actually be a problem08:11
TheMuejam: yep08:12
jamrogpeppe: you mean losing precision on ints?08:12
rogpeppejam: yes08:12
rogpeppejam: we might be causing subtle breakage in existing charm usage08:12
jamrogpeppe: float64 has exact precision up to ~52 bits so it only matters if someone enters 2**61+1 that they care about that +108:13
rogpeppejam: yes08:13
rogpeppejam: but that still might be important08:13
rogpeppejam: for instance someone might be storing bytes in there or something08:13
jamrogpeppe: don't store bytes in a number type08:14
jamI think that is a fine statement08:14
jamwe have strings08:14
rogpeppejam: indeed08:14
jamand base6408:14
rogpeppejam: but it's still a possible issue08:14
jamrogpeppe: I would be willing to take a patch that changed "juju set" to notice that you might lose precision and warn you08:14
jamrogpeppe: I'm happy to deal with it when someone shows it is an actual problem.08:14
rogpeppejam: tbh i think it's ok to just say we only cope with 52 bits of precision08:15
jamrogpeppe: I feel the same way.08:15
rogpeppejam: in fact, we *could* deprecate the "int" type entirely08:15
jamwhich is why I JFDI with float()08:15
rogpeppejam: +108:15
rogpeppejam: those two CLs reference the same MP08:36
rogpeppejam: i think i just reviewed the one without the prereq08:36
rogpeppejam: so it proabably counts as a review of both :-)08:37
jamrogpeppe: yeah, I meant https://codereview.appspot.com/12943045/08:50
jamrogpeppe: so for Client object. What fwereade_ really wanted is to avoid exposing "Environ" to the CLI code as much as we can (because we shouldn't need stuff like provider creds for almost everything we do).08:51
rogpeppejam: yeah, that seems reasonable08:51
jamrogpeppe: beyond that, there isn't much that api.State provides CLI above "api.State.Client()".08:51
rogpeppejam: agreed08:52
jamso I'd like to start with restricting it to just Client, and see if we can make it with that08:52
rogpeppejam: i think that sounds fine too08:52
jambut I'm happy to fix the comment08:52
jamrogpeppe: ah, back to you. IT turns out that multiple Close of api.State actually isn't ok08:52
jamunderneath api.State.Close() just calls rpc.Conn.Close()08:53
jamwhich returns: errors.New("already closing")08:53
jamrogpeppe: should multiple Close calls be an error?08:53
rogpeppejam: it's not clear08:53
jamrogpeppe: we had a test that state.State.Close() can be called multiple times (though like I copied, it didn't actually check the err return :)08:54
rogpeppejam: on network connections, i think the second close will return an error08:54
jamyou can add that, and it passes08:54
jamit fails for api.State.Close()08:54
rogpeppejam: we could make rpc.Conn.Close return nil if it's already closing08:56
jamrogpeppe: that would be my preference, but you wrote it and I wanted to check what your reasoning was08:56
rogpeppejam: i think i was principally following the original logic of net/rpc08:57
rogpeppejam: which returns an error in that case08:57
rogpeppejam: (if in doubt i followed net/rpc's conventions)08:58
jamrogpeppe: right: http://golang.org/src/pkg/net/rpc/client.go?s=7213:7248#L26208:58
jamthough it returns a typed error08:58
jamwhich we could suppress at a higher level if we wanted.08:58
rogpeppejam: that's true. but it's a typed error that actually means two possible things08:58
rogpeppejam: 1) you just closed it; 2) the server shut down on you08:59
jamrogpeppe: sure, though if I'm calling Close() and that happened to be shutdown by the remote side, that doesn't sound like an error08:59
jamso I don't know if you need to distinguish between the two cases in this path09:00
jamin *my* opinion, Close() is one of those idempotent functions that you can call multiple times to make sure resources were cleaned up09:00
jamrogpeppe: if you agree, I'm happy to change rpc.Conn and assert it higher in the stack.09:00
rogpeppejam: I think that sounds reasonable (presumably you mean "lower in the stack"?)09:02
jamrogpeppe: well I mean assert it across the stack09:02
jamso we assert api.Client.Close and APIConn.Close() and api.State.Close and rpc.Conn.Close()09:02
jamThey happen to be implemented in terms of eachother, but it is nice to have the statement "Close() is idempotent at the various levels"09:03
rogpeppejam: what's APIConn ?09:03
jamrogpeppe: juju.APIConn09:04
rogpeppejam: oh doh!09:04
jamContains an api.State and api.Environ09:04
jamrogpeppe: mirroring juju.Conn09:04
rogpeppejam: yes, that all seems reasonable09:04
jambut *probably* going away09:04
jamI didn't want to be ripping it out at this point, but we have api.Client() where functionality that needs a place like juju.Conn can go, there doesn't seem much point in having both, and we *don't* want most CLI things to need an object that has Environ on it.09:04
rogpeppejam: yes, i think it will probably go away, though there are one or two lingering bits09:05
jamrogpeppe: hopefully most of it involves moving things into the API :)09:05
rogpeppejam: yeah, i'm very much +1 on putting everything behind api.Client09:05
rogpeppejam: it wasn't possible before, because we couldn't mix logic that involved both Environ and State in a State method.09:06
jamrogpeppe: out of curiousity, why is rpc.Conn defined in "server.go" rather than "client.go" ?09:08
rogpeppejam: it could be either09:08
rogpeppejam: it's both the server and the client side09:08
rogpeppejam: it could have been in a separate file, i guess, but i don't think it's a big issue09:09
rogpeppemgz: morning!09:10
mgzqmorning!09:10
jamrogpeppe: no, it just wasn't where I was looking for it when dealing with connection on the client side. And the word "Conn" exists all over the place in our source code. :)09:11
jammgz: morning09:11
rogpeppejam: you should really use better tooling :-)09:11
jamrogpeppe: we should use better names09:11
rogpeppejam: rpc.Conn seems just fine to me09:11
rogpeppejam: it's unambiguous09:12
jamrogpeppe: except for net/rpc/Conn09:12
rogpeppejam: they're both connections09:12
jamrogpeppe: but they both use "rpc.Conn" and are entirely different code.09:12
jameven if they are "similar"09:12
rogpeppejam: ah, sorry, thought you were referring to net.Conn vs rpc.Conn09:13
jamrogpeppe: there may not actually be a net/rpc/Conn, but punning 'rpc' with a stdlib package is also not great naming.09:14
rogpeppejam: in a large s/w environment, there are always going to be duplicate names. the package name spacing means that it's possible to reliably and quickly find the actually definition for any given name09:14
rogpeppejam: and there are tools that integrate with your editor that makes that easy to do09:14
rogpeppejam: (assuming you use emacs or vim :-])09:15
rogpeppes/actually/actual/09:15
rogpeppejam: do you think that all our names should be globally unique?09:17
jamrogpeppe: I'm not sure about globally unique, but avoiding repeated 10 times would be nice09:18
jameg State09:18
jamConn09:18
jamand Client09:18
rogpeppejam: i think that that's actually a benefit - those names are well known concepts, and they're unambiguous when used in context (rpc.Conn vs net.Conn; uniter.State vs machiner.State, etc)09:20
rogpeppejam: i guess it comes down to the "no needless repetition" thing09:20
rogpeppejam: which is a conventional approach in Go09:20
rogpeppejam: but does have some down sides, as you point out09:20
jamrogpeppe: I *do* like not having var foobar foo.FooBar  = new foo.FooBar(fooing the bars)09:21
rogpeppejam: but you prefer foo.FooBar to foo.Bar ?09:21
jamrogpeppe: I like it being really easy to translate "foo := SomethingReturningAFoo()" into what Foo that is returning.09:22
jamand using "tools that are already installed on my system" rather than having to dig up "nostandard but useful tools" from 3rd parties.09:23
rogpeppejam: presumably if it's foo.NewBar(), that's fairly obvious09:23
jamrogpeppe: except it is "rpc.Conn" and that is actually net/rpc/Conn or foo/bar/baz/rpc/Conn09:25
jamrogpeppe: so I have to look up what "foo" is actually being imported here.09:25
rogpeppejam: it's true that package identifiers aren't unique (we use "testing" many times, for example)09:26
jamrogpeppe: and it is a source of confusion occasionaly.09:26
rogpeppejam: yeah, it can be. but hopefully in situations where ambiguity might be a problem, we rename the identifiers appropriately.09:27
=== tasdomas is now known as tasdomas_afk
rogpeppejam: we only use net/rpc in one place in our tree, for example09:27
=== tasdomas_afk is now known as tasdomas
jamrogpeppe: so there is "it is unambiguous when you've paged in enough context" and there is "it is unambiguous when you read 3 lines of code"09:27
rogpeppejam: personally, i think it's reasonable to assume some contextual knowledge. but that might be just me.09:29
rogpeppejam: and i have to say that when browsing code i'm not familiar with, i use godef a lot09:29
jamrogpeppe: in a team of 10+ having people look at code that they aren't as familiar with it is *useful* albeit not *required* to minimize the need for contextual knowledge.09:29
jamrogpeppe: it is a goal (generally) to code is such a way that it is understandable to people who aren't as intelligent as myself (especially since *I* will not remember everything in 1 month either :)09:31
rogpeppejam: i totally agree with that09:31
rogpeppejam: but i don't think that the redundant naming helps greatly there09:31
rogpeppejam: in general, i find external Go code (using similar naming conventions to our current ones) is quite easy to browse and understand09:32
rogpeppejam: but again, i do use godef (and godoc.org) a lot09:33
jamrogpeppe: one thing I would *really* like for godoc, is if you could click the Bar in "func Something() Bar)" and have it take you to the definition.09:33
rogpeppejam: i think it does that, doesn't it?09:34
rogpeppejam: yeah, it does09:34
rogpeppejam: it linkifies all type names09:35
jamrogpeppe: not in the one-line overview, and the "func Something" doesn't give you the arguments or the return type, but if you keep drilling down until you get to the grey-box with more stuff that does eventually get there.09:35
rogpeppejam: i might be looking at a different godoc.org to you09:36
rogpeppejam: in the one i'm looking at, it's two clicks09:36
rogpeppejam: (one to click on the one line overview, which takes you to the actual description, then another to click on the type name)09:38
jamrogpeppe: and a bit of visual searching to find the right thing, but with practice not too bad. I'm not sure if it used to do that, or if the specific layout of the page made it hard for *me* to see it.09:38
rogpeppejam: it's quite possible. and the site does change - it might not have been so good in the past.09:39
jamI think I would also like to see the overview of functions for a Struct when you go to the structs definition (like there is in the top level index).09:39
jamAFAIK there isn't a way to jump to the place in the index09:40
jamand the index mixes09:40
jamthings that return Foo09:40
jamwith methods on Foo itself09:40
jameg, http://godoc.org/net/rpc has Client09:40
jamwhich has functions returning a Client09:40
jamand functions on Client09:40
jambut no concise "these are the methods on Client"09:40
rogpeppejam: yeah, it tries to classify factory funcs09:40
jamI don't mind them being nearby09:40
jambut it would be useful to have a simple "here are the methods" section09:40
rogpeppejam: that's the overview, i guess09:41
jamin my head it would exist here: http://godoc.org/net/rpc#Client09:41
jamrogpeppe: they aren't visually distinct from the "here are factory functions"09:41
jamthey are slightly different09:41
rogpeppejam: yeah, you have to look for the (client *Client)09:41
rogpeppejam: if you can think of a nice way of visually distinguishing them, i'm sure they'd be open to suggestions09:42
rogpeppejam: it's not something that had occurred to me09:42
jamrogpeppe: Are all of the tests for "state/api/*" code over in state/apiserver?09:43
jamI don't see any _test.go files in state/api09:43
jamwhich is.. a bit surprising09:43
jam(I realize you sort of need apiserver in order to test api code, but I would expect to find api tests in the api package)09:44
jamrogpeppe: which might be why I put the APIClient.Close test in juju/*09:44
jam(I'm only *just now* remembering that I saw some api.Client tests in apiserver a few days ago)09:44
jamrogpeppe: as in, I don't have an immediately obvious place to put new tests that api.State.Close() and api.Client.Close() are idempotent.09:45
jamrogpeppe: so how do you find where there would be tests for api.State?09:45
jamrogpeppe: having a unique name instead of State09:45
jamwould make that pretty obvious (i would think)09:46
jamso references of X not definitions of X09:46
jamand some of those references might be in the package itself09:46
rogpeppejam: my original scheme for testing API functionality was to put all tests in the client.09:47
jamrogpeppe: there are no tests that I see in state/api/*, and there is no state/api/client/ directory09:48
jamrogpeppe: is it just that they were moved elsewhere?09:48
jamrogpeppe: also, no tests for state/api.State object that I can immediately find09:48
* rogpeppe goes to look09:49
rogpeppejam: the tests that are now in state/apiserver/client did originally live in state/api, i believe09:50
rogpeppejam: yeah, that seems to be the case. they should really be in state/api/client, i think09:52
jamrogpeppe: I'll file a techdebt bug, but not fix it right now.09:52
rogpeppejam: sgtm09:53
rogpeppejam: FWIW, i still think that testing all API stuff through the client makes sense, as there's so little actual logic in the RPC layer.09:54
rogpeppejam: and the way things are, we've got vast swathes of almost-but-not-quite identical tests at each layer09:54
rogpeppejam: i guess the main reason we can't do that is that we decided to expose stuff in the API server that we don't make available in the client.;09:55
jamrogpeppe: which I've already run into, though it was in the "and this isn't tested" category AFAICT09:56
jamAddUnit supported ToMachineSpec but that wasn't exposed in api.Client09:56
rogpeppejam: ha, yes09:57
rogpeppejam: i have difficulty keeping track of what our test coverage is in this area09:57
rogpeppejam: because the tests are so overlapping09:57
jamrogpeppe: so where do you think tests about api.State are today? (where should I add a test that calling api.State.Close() multiple times doesn't give an error)09:58
rogpeppejam: i think that tests on api.State should live with the other tests on api.State.09:58
rogpeppejam: it seems that that's currently (but wrongly) in state/apiserver/client09:58
rogpeppejam: so i'd add it to those, to be moved over at some later date09:59
fwereade_rogpeppe, I was taking a casual look at Prepare... there's a 3.5 second sleep in jujud/machine.go10:00
rogpeppefwereade_: yes, i've removed that since.10:00
rogpeppefwereade_: but not re-proposed the branch10:00
rogpeppefwereade_: (that was me trying to reproduce a saw-it-once-only test failure)10:00
fwereade_rogpeppe, :)10:01
fwereade_rogpeppe, seems fine to me, go ahead and land it, if anything turns out to be a problem for the followup work we'll find out soon enough10:05
rogpeppefwereade_: i'm pretty sure it was nothing to do with my changes10:05
jamfwereade_: did you have anything to add to the float64() vs int64() discussion about the  ServiceGet() api?10:09
fwereade_jam, I'm fine accepting the json precision restrictions (well, I don't like it, but I don't think it's worth the effort of fixing)10:11
jamfwereade_: well *JSON* supports arbitrary precision integers AFAICT10:12
jamgolang json.Unmarshal defaults to float64 though you can tweak it to return "type Number string"10:12
jambut that would make testing it harder rather than easier AFAICT10:12
fwereade_jam, shall we just call it a bug and move on?10:13
fwereade_jam, unless you judge it simple enough to make it Right rightnow10:14
jamfwereade_: my personal feeling is that 'juju get' will return similar-enough types that it probably isn't a problem, and I'm willing to deal with it when charms themselves really do need it10:15
fwereade_jam, seconded10:15
jamfwereade_: and I would say the test should be in state/api, except there are 0 tests in there :)10:15
jamwhich is what I was just chatting about with roger10:15
fwereade_jam, but let's document it as a bug regardless so it's easier to hunt it down and figure it out when it *does* happen10:15
rogpeppejam: presumably we have a potential issue even if we do use int64 because python would (presumably) use arbitrary-precision ints when needed10:16
jamfwereade_: bug #121728210:16
_mup_Bug #1217282: api.Client tests should be in state/api not state/apiserver/client/ <tech-debt> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1217282>10:16
fwereade_jam, oh bollocks, they're all in apiserver10:16
jamfwereade_: as yet I haven't actually found direct tests of api.State either.10:16
jamrog mentions they might be in state/apiserver/client/* but I haven't actually found a suite that is focused on the api.State object.10:17
fwereade_jam, oh yay10:17
natefinchjam: I sent an email that got blocked by the message size limit on juju-dev.... the autoreply I got said it was awaiting moderator approval... are there actual moderators that might approve it, or should I just recreate it?10:18
jamnatefinch: I am not one of the moderators. Gustavo might be, but it is probably easier to just resubmit.10:18
jamI believe you can reject the existing message yourself.10:18
natefinchjam: yeah.... bah.  40k limit? What is this, 1998? :)10:19
jammorning evilnickveitch10:23
jamI don't remember you having the "evil" goatee, though.10:23
evilnickveitchjam, hey! My facial hair is in a constant state of flux to confuse my enemies10:23
TheMuefwereade_: in https://codereview.appspot.com/12752044/diff/8001/cmd/juju/get_test.go you made a comment regarding "default" in "juju get"10:25
rogpeppejam: i'd like to see tests in state/api focused on the functionality that's in that package. you're right, tests for api.State itself seem to have vanished. i'm pretty sure i wrote some originally.10:26
TheMuefwereade_: could you explain your thoughts a bit more?10:26
TheMuefwereade_: i haven't touched the logic of get here, only moved. but i could handle it in a third CL.10:27
rogpeppehas anyone seen this when testing?10:27
rogpeppePANIC: machine_test.go:58: MachineSuite.TearDownTest10:27
rogpeppe... Panic: unauthorized db:presence ns:presence.presence.beings lock type:0 client:127.0.0.1 (PC=0x414321)10:27
fwereade_TheMue, saying "the value is nil, and that's the default" is redundant/meaningless because a nil value is only possible when there's no default set10:27
fwereade_TheMue, so a trivial CL stripping "default: true" out of settings where the value is nil would be cool10:28
TheMuefwereade_: ok, will do10:28
fwereade_bbiab10:28
jamnatefinch: you have https://code.launchpad.net/~natefinch/juju-core/005-azure-address/+merge/181117 still pending though it has my approval. just poking for you to think about landing it.10:33
natefinchjam: thanks, meant to talk to you about that. It's LGTM pending live tests, but the values aren't actually used anywhere in the branches, so I sorta can't live test10:34
jamnatefinch: I meant "test against Azure"10:34
davecheneynatefinch: nice work in the win32 installer10:34
jamas in actually running it live10:34
davecheneyi hope you get some feedback10:35
davecheneybut given the self selection population in the channel10:35
davecheneyplease don't take it too hard if you don't get a lot of feedback10:35
natefinchdavecheney: my message got caught by the size limit on the mailing list, so no one but mods have seen it I suspect :)10:35
natefinchjam:  I guess I can insert some temporary code to call instance.Addresses[]... my point was that nothing calls that method in the branch I'm on10:36
natefinchat least as far as I could tell10:37
davecheneynatefinch: i saw it10:38
=== andre____ is now known as andrew_w_deane
davecheneyi am not a nod10:38
davecheneymod10:38
natefinchdavecheney: oh, ok, so maybe it was let through and there wasn't a message back to me about it... and since I don't think I get my own messages from the list... makes it hard to tell what's going on.10:39
davecheneynatefinch: you do10:40
davecheneybut gmail doesn't show them too you10:40
natefinchdavecheney: oohh... ok, that could be it10:40
davecheneyyou can also check the listserv directlu10:40
natefinchAhh yeah, I always forget I can do that10:41
natefinchwell, good.10:42
* TheMue => lunchtime10:58
jamnatefinch: talking about the windows installer. should we just make a 32 bit one and not worry about it? juju-the-client won't ever really benefit from >4GB addressable space. Though I realize go itself works better in 64-bit because of how it does virtual adress10:59
jamaddressing10:59
jamjuju-the-client isn't long lived enough to really matter.10:59
jamwhen we get to 'jujud-the-daemon' we'll want to focus more on 64-bit10:59
natefinchjam: yeah, that's probably a good point. There's very little benefit from 64 bit as you said. And 32 bit is more portable, which is a lot more valuable11:00
jam(I originally started in 64-bit, and then went to 32-bit when we had C dependencies, because 64-bit mingw wasn't very good, and was thinking to switch back but maybe we just want to stay 32-bit for juju-the-client for now)11:00
davecheneydoes anyone know where cloud-init writes the original text of the user data ?11:05
mgzdave, sec11:10
davecheneyi can never find the bugger11:10
mgz/var/lib/cloud/instance/user-data.txt11:11
davecheneymgz: ta muchly11:11
davecheneybloody hell, cloud-init has everything that opens and shuts11:11
davecheneyoh shit, its base64 encoded11:11
davecheneywell, that is one terminal i wont be using again11:11
natefinchlol11:12
mgzdave : in the same folder are the decoded bits11:12
davecheneymgz: last time I c&p something blindly from you11:13
mgzI included not cat :)11:13
natefinchit's like the CLI equivalent of rick rolling :)11:15
fwereade_guys, I'm afraid I won't make the standup, and I'll probably be working somewhat interrupted hours all week -- it emerges that the flat is actually literally falling apart and I need to find somewhere to live :/11:20
natefinchfwereade_: wow, damn11:21
fwereade_yeah, it kinda sucks11:21
natefinchfwereade_: yeah, I can see how that could be less than optimal11:21
TheMuefwereade_: iiirks, wishing you luck11:23
natefinchfwereade_: yeah, good luck, definitely. That's a crappy situation to be in.  Do you own the flat, or are you renting?11:24
jamnatefinch: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 standup11:33
jamfwereade_: ^^11:33
rogpeppemramm: standout, if you want to11:34
rogpeppestandup even11:34
mgzstandover11:34
jamstandarounder11:35
davecheneystand to the right11:38
davecheneyhttps://bugs.launchpad.net/juju-core/+bug/1202163/comments/411:49
_mup_Bug #1202163: openstack provider should have config option to ignore invalid certs <juju-core:Triaged> <https://launchpad.net/bugs/1202163>11:49
davecheneyjpds needs love on this one11:49
mgzthat's sadly not as easy to do in gojuju as it was in pyjuju11:54
davecheneymgz: could we make it always on ?11:55
davecheneymgz: sorry, was jumping to the soluont11:55
mgzas in, never check certs?11:55
davecheneyyes11:55
davecheneyi know how to create a client that doens't check certs11:55
mgzthat seems like a bad thing from a security perspective :)11:56
davecheneymgz: sure11:56
davecheneyis the issue in passing down the 'please don't check' flag11:56
davecheneyor implementing ' please don't check '11:56
mgzpassing through to all the points that use an endpoint seems like the hard part11:57
davecheneymgz: what if it was at a per environment level ?11:57
mgzI'm just assuming go has a flag in the http library somewhere for not checking certs11:58
davecheneyyup11:58
mgzdavecheney: so, what happens in pyjuju, is we have the silly er... ssh-hostname-verify or something env config variable11:58
davecheneyyup11:58
mgzthat used to default to false, but got switched to true for openstack11:58
mgzand that gets used but the openstack provider client,11:59
* davecheney remembers ssh-hostname-verify11:59
mgz*and* also the curl for looking up the instance id on machine startup11:59
davecheneycocking nora12:00
mgzwe should be able to do roughly that for gojuju... but we use the swift container for many more things, like tools,12:00
mgzand without checking, I'm not totally certain all the places where we might access provider storage we actually have the environment config12:01
mgzbecause some of that is now initiated from each machine, whereas it used to all be from the provisioner12:02
davecheneyi guess the 'just turn it off everywhere' option is not acceptable ?12:03
mgzgiven the elling that made us flip the default for python, I think not12:04
jamdavecheney: I would think the self-signed cert thing is High + papercut vs Critical12:04
mgz*yelling12:04
jamCritical == block the next release until fixed12:04
davecheneyjam: feel free to change it12:04
jamdavecheney: just running it by you rather than having an edit war on LP :)12:04
davecheneyjam: don't care12:04
jamnatefinch: I sent what is hopefully a point-by-point discussion about the installer. Mostly it seems like "good enough for now".12:05
natefinchjam: thanks, the feedback is very much appreciated12:05
jamI'll check with Mramm if it is appropriate to upload it to juju-core proper today.12:05
jamat least, if he shows up to my 1:1 this morning.12:06
mrammjam: seems reasonable to upload it12:06
natefinchmgz: I moved my cards around so they're up to date. I'll poke the red squad about azure creds so  I can do a sanity check on the azure code and land that today12:09
mgzace, and added an intaller one, great12:10
=== natefinch is now known as natefinch-afk
natefinch-afkgoing to be in and out some today, kids stuff.12:18
davecheneyTheMue: https://docs.google.com/a/canonical.com/document/d/1aEvcmxSJaj1i9zNjGy48yKF-SPlTFwW-NiKfoO_Ygo4/edit12:30
davecheneycould you please document juju unset in the release notes12:30
davecheneyta12:30
TheMuedavecheney: yep, will do12:30
jamnatefinch-afk: quick comment, we probably won't release 1.13.2 as a windows installer because of the known bug against azure with public tools. (fixed in trunk)12:33
davecheneyalso, 1.13.3 is coming at the end of the week12:34
jamdavecheney: right, so we'll probably wait for 1.13.3 to do a public -setup.exe12:34
davecheneyjam: and then we get to have the discusion about 1.14 again :)12:34
jamdavecheney: to be fair we have chatted about it a few times now :)12:35
natefinch-afkdavecheney: gotcha12:37
davecheneyjam: next time's the charm12:37
wallyworldfwereade_: hiya, if you have time, would be great if you could look at this to ensure it matches our discussions. i hope to land it tomorrow so i can progress the simplestreams stuff with andrew https://codereview.appspot.com/1327804312:57
jamTheMue: in talking with mramm he mentioned you'd likely be interested in being at the doc sprint on Friday. Is that still true?12:58
jamI can add you to the invite list so you get a reminder.12:59
jamhey wallyworld, how's your day been?12:59
wallyworldbusy :-)13:00
wallyworldi know understand how horrible and hard charms are to write :-(13:00
wallyworldwe so need to fix that13:00
wallyworldthe mental model is difficult and there are so many ways to subtley shoot yourself in the foot13:01
davecheneywarning: juju may contain traces of footgun13:01
wallyworldtraces = copious quantities13:01
TheMuejam: i'm interested in supporting the documentation, yes. i only have some troubles on this friday as i would have to leave at about 8pm local time.13:02
jamTheMue: I don't think you are expected to be there the whole time13:02
jambut if you can be there during your work day that is still a great advantage.13:02
TheMuejam: yep, absolutely no prob. sounds fine to me13:03
* rogpeppe goes for lunch13:25
TheMuehmmmpf14:45
TheMuemy software does not like me. first two missed tests i forgot but now a panic on the bot while i have a never seen failing test (but no panic) here. *sigh*14:52
TheMueand now it passes again.14:54
TheMuefu..15:07
TheMuerunning the failing suite isolated it works, but with go test ./... it fails15:07
mgzthat is not uncommon15:08
TheMuemgz: but also not nice15:14
fwereade_TheMue, added a couple of comments to your review15:19
TheMuefwereade_: thx15:20
TheMuefwereade_: who's best to contact in the GUI team?15:21
* TheMue has to leave, bank appointment15:41
=== tasdomas is now known as tasdomas_afk
hazmatfwereade_, the relationcount, unitcount on respective states (service, and relation) are primarily used for txn condition guards ?16:01
natefinch-afkarosales, mgz: either of you guys know how to set up juju with azure? I don't see anything on juju.ubuntu.com16:09
mgznot really, but you can just read the comment in the source/autogenerated config16:11
mgzprovider/azure/config.go16:12
natefinch-afkmgz: cool, thanks16:12
natefinch-afkman, the SSO for azure is buggy. It only works if I log in from particular websites16:14
natefinch-afkevidently I should "contact your admin and report the following error: 80045C17"16:15
=== weblife is now known as web-brandon
rogpeppehmm, how is it possible that provider.StartInstance and provider.StartBootstrapInstance have gone in without any tests?18:03
jamespageanyone from the juju team care to join the 'deliverying juju 2.0 into saucy' session?18:04
jamespagerogpeppe, fwereade_, mramm ^^18:04
rogpeppejamespage: if that's happening now, i'm afraid i'm just reaching end of day, so can't without domestic consequences...18:05
jamespagemgz, ^^18:06
=== natefinch-afk is now known as natefinch
rogpeppeif anyone fancies a largish but pretty mechanical code review: https://codereview.appspot.com/1326904518:43
rogpeppenatefinch: ^18:43
rogpeppeand with that, i *must* leave!18:43
rogpeppeg'night all18:43
natefinchrogpeppe: I'll take a look.  Gnight18:44
kvtsurprising number of tests work on osx (+ mongodb w/ ssl) nice18:47
natefinchkvt: that's awesome. not entirely surprising, but it would be great if we could get all the tests passing on OSX.  Ideally, we'd be able to run the tests on any platform juju supports.18:50
hazmatnatefinch, there are a couple of lxc tests that make it barf18:56
hazmatthe mongodb manual compilation  for ssl was a bit unfortunate/time consuming, required some patching of scons config files.18:57
natefinchhazmat: yeah. lxc is kind of a problem child for cross compatibility.   Still, if we can isolate that with OS compilation restrictions, that's ok.18:57
* kvt nods18:58
kvtkvt == hazmat + osx ;-)18:58
thumpermorning21:02
thumperfwereade_: you around?21:02
fwereade_thumper, heyhey21:02
thumperfwereade_: got time for a chat21:02
thumper?21:02
fwereade_thumper, sure, just a mo, would you start one please?21:02
thumpersure21:03
bigjoolshullo22:54
thumperhi bigjools23:00
bigjoolshey man23:01
mrammthumper: bigjools: hey all23:18
bigjoolsg'day mramm23:18
thumperhi mramm23:18
davecheneyaxw: hey23:19
davecheneyoff da phone23:19
davecheneygonna check out of my room and i'll see you in mitchel23:19
axwdavecheney: okey dokey. I'm down there now23:19
axwdavecheney: they took the wifi off when I mentioned we had a meeting room23:19
davecheneyfuckers23:20
axwdavecheney: ?23:20
axwdavecheney: I mean they didn't charge me23:20
mrammdavecheney: that is good at least23:21
davecheneyoh right23:21
davecheneyi thought they *turned it off*23:21
axwhah :)  no sorry23:21
axwhey mramm, how's it going?23:22
mrammaxw: pretty good23:22
mrammbusy with all kinds of stuff for the other teams the last couple of weeks23:22
mrammseems like juju core land is running pretty well23:22
axwcool :)23:23
sidneimramm: if i can get one bug in your prioritization radar, it'd be https://bugs.launchpad.net/juju-core/+bug/1190985 it's biting us madly :/23:41
_mup_Bug #1190985: Confusing update-charm and deploy -u behavior <juju-core:Triaged> <https://launchpad.net/bugs/1190985>23:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!