/srv/irclogs.ubuntu.com/2013/10/03/#juju-dev.txt

rogpeppemgz: reviewed00:09
fwereade_rogpeppe, in case you're there, my unease has crystallized -- how does addressupdater play with containers?00:09
rogpeppefwereade_: it doesn't currently00:09
fwereade_rogpeppe, I guess it doesn't have to yet00:09
rogpeppefwereade_: we have to work out how we're going to do container addressing first00:10
rogpeppefwereade_: in case you missed it, i'm after a review of this, which actually integrates the address updater: https://codereview.appspot.com/14306043/00:11
fwereade_rogpeppe, well, we know that one instance will have at least N addresses that need to be shared amongst the machine and its containers00:11
rogpeppefwereade_: i'm not sure who will be responsible for allocating container addresses00:12
rogpeppefwereade_: whatever happens, there has to be *something* like the address updater at the top level, i think00:15
fwereade_rogpeppe, yeah, I think the trickiness it just going to be passing the extra addresses on to containers00:15
rogpeppefwereade_: yes00:16
fwereade_rogpeppe, and that's orthogonal, so... LGTM00:16
fwereade_rogpeppe, and you reviewed mgz's already, so I'm going to bed :)00:17
fwereade_gn00:17
rogpeppefwereade_: gn00:17
rogpeppe'00:17
thumperfwereade_: you still up?00:18
thumpergeez00:18
thumperrogpeppe: you heading to bed too?00:18
rogpeppethumper: i was hoping i might get the API client address caching done...00:19
thumperrogpeppe: how much does it still have to do?00:19
rogpeppethumper: 1) it needs State.APIAddresses to return addresses from the state server machines rather than from mongo peers00:20
rogpeppethumper: 2) it needs the API login to call State.APIAddresses and return them as the result00:21
rogpeppethumper: 3) it needs some code to actually save the API endpoint returned from the API login00:21
rogpeppethumper: the first two are pretty trivial; the third requires a little more thought but should be easy enough.00:21
rogpeppethumper: all of them can actually be done independently00:22
thumperand before you sleep?00:24
rogpeppethumper: erm, maybe i'm being a little optimistic :-)00:27
rogpeppethumper: i think i'll probably just land the address updater00:27
* thumper nods00:28
rogpeppethumper: it would be nice to change status so that we can actually see the new address info too...00:29
thumper:)00:30
rogpepperight, i am doing No More00:40
rogpeppethumper: g'night00:40
thumpernight00:40
davecheneysinzui: +1 on your change00:41
* rogpeppe just live bootstrapped with an environments.yaml entry that's simply : "envname": {"type": "ec2"}00:46
davecheneyrogpeppe: wowzers00:53
davecheneytalk about simple00:53
davecheneyrogpeppe: what is the next step, bootstrap with no envuronments.yaml and just some flags?00:53
rogpeppedavecheney: it did use the conventional $AWS_ environment vars, so it's a bit of a cheat really00:53
rogpeppedavecheney: i think that would be good, yeah00:54
davecheneyjuju bootstrap -e rog -t ec200:54
davecheneycreates ~/.juju/environments.yaml ?00:54
rogpeppedavecheney: no need00:54
rogpeppedavecheney: creates ~/.juju/environments/rog.jenv00:54
* davecheney twitches00:55
davecheneyprefixing everything with j sounds very 200200:55
davecheney:)00:55
rogpeppedavecheney: look, there was a bikeshed CL specifically for that :-)00:55
rogpeppedavecheney: you didn't weigh in so you're out00:55
rogpeppedavecheney: FWIW i'm not that keen on .jenv either, but it was the only reasonable suggestion00:56
davecheneyrogpeppe: fair enough, my fault for not being involed00:57
davecheneyi'll shut up00:57
rogpeppedavecheney: if you really have a better suggestion, i'm happy to hear it.00:57
rogpeppedavecheney: it can be changed now; not so easily in the future.00:58
davecheneyrogpeppe: ignore my griping, i'm a chicken, not a pig00:58
* rogpeppe duly ignores00:58
rogpepperight, the address updater has landed. i'm going to bed.00:59
rogpeppedavecheney: g'night.00:59
* thumper sighs heavily00:59
thumperwhy is dummy provider so dumb00:59
thumperis there any specific trick I need to know about dummy.Storage()?01:00
rogpeppethumper: what about it?01:00
thumperI have a test hanging forever01:00
thumperinside dummy bootstrap method, I'm trying to call common.SaveState01:00
thumperso it behaves like a real environment01:00
thumperfor some other tests01:00
rogpeppethumper: dummy.Storage shouldn't be doing anything special01:01
thumperbut the test just hangs01:01
thumperhow can I tell where it is hanging?01:01
rogpeppethumper: ^\01:01
rogpeppethumper: i.e. SIGQUIT01:01
thumperok, but it is01:01
rogpeppethumper: that'll give you a stack dump01:01
thumperis there a control key for that?01:01
rogpeppethumper: control-backslash01:01
thumperta01:01
rogpeppethumper: paste the stack trace; i have a suspicion what might be your problem01:02
thumperrogpeppe: http://pastebin.ubuntu.com/6186255/01:02
rogpeppethumper: i think you're probably calling common.SaveState while the mutex is held01:02
thumperrogpeppe: hopefully I waited long enough01:02
thumperah01:03
rogpeppethumper: yup, looks like that's the issue01:03
rogpeppethumper: (see goroutine 52)01:03
* thumper nods01:03
rogpepperight, i really *am* going to bed noew01:03
thumperrogpeppe: that was it, passes now01:06
* thumper runs all the tests again01:07
thumperoh...01:18
thumpertest panci01:18
thumperpanic01:18
* thumper wondered what I did01:18
hatchis there any way I can deploy a charm locally (lxc) from my launchpad branch?01:19
hatchthe branch is lp:~hatch/+junk/hadoop-charm-update01:19
hatchbut it says that is an invalid charm name01:19
thumperhatch: I think you may need to have a copy locally01:24
thumperaxw: I got a test failure with the null provider tests01:25
thumperaxw: may be a timing thing01:25
axwthumper: yeah, rog filed a bug01:25
hatchthumper: yeah that's what it looks like in the docs....thanks for confirming01:25
axwwill look into it shortly01:25
thumperaxw: this one? environSuite.TestEnvironBootstrapStorager01:25
thumperhatch: np01:25
axwthumper: yup01:25
thumperok,01:26
axwhttps://bugs.launchpad.net/bugs/123412501:26
_mup_Bug #1234125: provider/null: sporadic test failure <intermittent-failure> <juju-core:New for axwalk> <https://launchpad.net/bugs/1234125>01:26
* thumper sighs01:26
thumperwhy do core-devs file "New" bugs01:26
thumperit should at least be triaged01:26
thumperstabby stabby01:26
thumperwow01:46
thumperfound out why so many of our bootstrap tests are slow01:47
thumperautomagical upload is now rebuilding jujud every test :)01:47
thumperwhy is it one hour jobs become four hour jobs01:59
sidneithumper: around?02:43
thumpersidnei: kinda02:43
sidneithumper: just wondering if bootstrapping from 1.5.1 just built from trunk this morning it should be picking tools 1.4.1.1 or am i doing something wrong?02:43
sidneiand by 1.4 and 1.5 i meant 1.14 and 1.15 of course02:44
davecheneysidnei: as i understand it from 1.15.x onwards it will only be able to work if it finds an exact tools match02:44
sidneiuhm, so this shouldn't have happened, if that's indeed correct02:45
sidneiunless im missing some branch that was landed recently02:45
thumpersidnei: I'd say it certainly shouldn't be02:45
sidneihttps://pastebin.canonical.com/98419/ fyi02:46
sidneilet me paste that to paste.ubuntu.com02:47
sidneioh, oh. i think i know what the problem is02:47
sidneiyeah, much better now. 'sudo juju bootstrap' was picking /usr/bin/juju obviously.02:48
thumperdavecheney, axw:  https://codereview.appspot.com/14279044/03:08
axwthumper: looking03:08
thumpersidnei: yea, I've picked up `sudo $(which juju) bootstrap' from axw03:09
thumperbefore I'd hardcode the path03:09
sidneiah, nice one03:09
* davecheney looks03:09
thumperit is a beautiful day here03:13
thumperonce my wife is back with kid from the doctor, we are going for a picnic03:13
thumper\o/03:13
=== julian__ is now known as julianwa
davecheneythumper: +1 on that change03:19
thumperand this? https://codereview.appspot.com/1432104303:19
davecheneynope https://codereview.appspot.com/14279044/03:20
davecheneyis there another review ?03:20
thumperyeah, the one I just said :)03:20
axwI think there's a bug for this too03:21
thumperthere is03:21
thumperlinked to the branch03:22
axwah03:22
thumperhttps://bugs.launchpad.net/juju-core/+bug/121677503:22
_mup_Bug #1216775: cmd/juju: local provider doesn't give a clear explanation when lxc is not configured correctly <papercut> <juju-core:Triaged by thumper> <https://launchpad.net/bugs/1216775>03:22
axwthumper: yep, just expected a "Fixed #..."03:22
thumperaxw: I use the bzr --fixes lp:nnn03:22
thumperrather than the lbox thingy I can't remember03:22
axwokey dokey03:22
davecheney22:08 < thumper> davecheney, axw:  https://codereview.appspot.com/14279044/03:24
davecheneythat was the one I reviewed03:24
thumperdavecheney: yeah, I know03:24
thumperdavecheney: and thanks03:24
thumperdavecheney: I was giving you another :)03:24
thumperhelp punished by requesting more help03:24
thumper:)03:24
davecheneycokc03:24
davecheneyfuck the lags is bad here today03:25
davecheney_+103:26
axwthumper: https://codereview.appspot.com/14315044/ if you have the time03:28
* thumper looks03:29
thumperaxw: I don't get this: ( echo $* | grep -q touch ) && head -n 1 > /dev/null03:33
thumpercan you explain?03:33
axwthumper: one sec03:33
axwthumper: actually that's broken03:34
axwthumper: my intention was to only expect input for the second bash, but that's just wrong03:34
axwthumper: PTAL03:49
* thumper had to decode petal03:49
axwsorry, Please Take Another Look :)03:49
thumperI got it, it just took me a while03:50
thumpermy cat is attacking me, she wants food03:50
axwthumper: nps, it can wait03:50
axwthe code.. not the cat03:50
axw:)03:50
thumperhave to teach the cat some time03:50
thumperfark03:51
thumperexec 0<&-03:51
thumpernow that is cryptic03:51
thumpereven with the comment, I don't get it03:51
axwhence the comment ;)03:51
axwheh03:51
axwcan't say I grok the syntax either03:51
thumperaxw: do you have any other null provider things to get done?03:55
axwthumper: nothing for 1.1603:55
davecheneyhelp04:09
thumperdavecheney: whazzup?04:09
davecheneydoes anyone remember the issue for the charm dir being owned by root 0700 ?04:09
thumperno04:09
thumperwell, I don't04:09
davecheneythere must be one04:10
davecheneya few people lost their shit over it04:10
thumperaxw: you're branch failed04:12
* thumper sighs04:13
thumperyour04:13
axwhuh04:13
thumperobviously you aren't a branch04:13
axwI tested that04:13
davecheneythumper: https://bugs.launchpad.net/juju-core/+bug/122608804:13
_mup_Bug #1226088: config-get fails with "open FORCE-VERSION: permission denied" <juju-core:Invalid> <https://launchpad.net/bugs/1226088>04:13
axwheh04:13
davecheneyis a protruberance of this issue04:13
davecheneybut not the core issue04:13
davecheneygot it04:14
davecheneyhttps://bugs.launchpad.net/juju-core/+bug/120528604:14
_mup_Bug #1205286: charm directory permissions now more restrictive <canonical-webops> <juju-core:Won't Fix> <postgresql (Juju Charms Collection):Fix Released> <postgresql-psql (Juju Charms Collection):Fix Released> <https://launchpad.net/bugs/1205286>04:14
* thumper back later04:15
rogpeppemornin' all07:21
fwereade_heya rogpeppe07:36
rogpeppefwereade_: hiya07:36
axw_jam: ping08:35
jamhi rogpeppe fwereade_ and axw_08:36
jamaxw_: what's up?08:36
rogpeppejam: hiya08:36
axw_jam: what do we want the cloud-tools pocket for?08:36
fwereade_jam, heyhey08:39
jamaxw_: it holds backports of tools related stuff. AIUI juju-core itself will be in there, but so will LXC08:47
jamaxw_: I *think* we'll migrate to using Cloud Tools instead of ppa:juju/stable08:48
rogpeppeaxw_: small change to environs/sshstorage - i started commenting on your CL but then realised it was merged; https://codereview.appspot.com/1432704308:48
axw_jam: ah ok. should I bother trying to get this in today? or have we already cut off?08:49
axw_rogpeppe: looking08:49
axw_oh, no comment left08:49
jamthe discussion says cut off, but we can still land it08:49
axw_rogpeppe: is there a problem, or did I already fix it? :)08:49
axw_rogpeppe: I made another fix in a further bzr push, didn't repropose08:50
rogpeppeaxw_: no real problem - just that if there were several lines of output, they wouldn't be joined with newlines08:50
rogpeppeaxw_: ah, if the change wasn't reproposed, i have no idea08:50
axw_rogpeppe: agh, yeah, because I changed to use the scanner08:50
axw_I'll fix in another, thanks08:50
rogpeppeaxw_: that CL fixes it08:51
axw_oh sorry, that's yours08:51
* axw_ looks again08:51
rogpeppeaxw_: yeah08:51
axw_rogpeppe: heh, I did actually split it out into a separate function, but reversed it to keep the EOF bits close together08:53
axw_but... meh, no big deal08:53
rogpeppeaxw_: yeah, i see that; i think the separate function is still worth it though. i think the @EOF is distinctive enough really.08:55
rogpeppeaxw_: i suppose we could pass the @EOF to copyAsBase64 as a "terminator" argument08:56
axw_rogpeppe: I think it's fine, that'd probably be overkill08:56
axw_rogpeppe: lgtm, thanks08:56
rogpeppeaxw_: ta08:57
* fwereade_ breakfast09:03
axw_rogpeppe: anything we can do about this in the short term? https://bugs.launchpad.net/bugs/123453409:09
_mup_Bug #1234534: local provider spams machine 0 log with "localInstance.Addresses not implemented" <juju-core:New> <https://launchpad.net/bugs/1234534>09:09
axw_bbiab - making dinner09:09
jamfwereade_: enjoy your food, but poke for when you get back09:09
rogpeppeaxw_: hmm interesting. i'll investigate.09:10
rogpeppeaxw_: there's a trivial fix09:11
rogpeppeaxw_: just remove that log statement :-)09:11
rogpeppeaxw_: but that leaves a slight problem09:11
rogpeppeaxw_: we shouldn't really be polling for address changes when the address can never change09:12
rogpeppeaxw_: i wonder if Addresses should return ErrUnimplemented; then the polling loop could just not bother anymore09:13
rogpeppefwereade_, dimitern, axw_: trivial CL to add a little bit of logging: https://codereview.appspot.com/1432804309:14
dimiternrogpeppe, looking09:15
dimiternrogpeppe, reviewed09:21
rogpeppedimitern: ta09:21
axw_rogpeppe: would it be bad to just to return an empty list of addresses from the local provider?09:27
rogpeppeaxw_: no, but we don't really want to be contiuously polling those addresses09:28
axw_rogpeppe: ah, it keeps checking if it has an empty list? ok09:28
rogpeppeaxw_: yes - it'll wait for the machine to get an address (currently it polls quite frequently at that stage, once a second)09:28
rogpeppedimitern: you're right about the %#v thing - it was a cop-out09:30
rogpeppedimitern: i'm wondering about a nice printed format for addresses09:30
rogpeppedimitern, mgz: how about something like this: public:12.3.5.6(networkname)09:31
rogpeppedimitern, mgz: where (networkname) is omitted if NetworkName is unset09:31
rogpeppedimitern, mgz: and i'd omitted the address type because it's almost always easily divinable from the contents of the address.09:32
dimiternrogpeppe, that lgtm09:34
rogpeppemgz: i suspect that Address.AddressType could actually be omitted entirely and implemented as a method.09:35
jamdimitern or rogpeppe: https://bugs.launchpad.net/juju-core/+bug/123393609:38
_mup_Bug #1233936: worker/uniter: uniter restarts when relation removed <juju-core:Triaged> <https://launchpad.net/bugs/1233936>09:38
jamIt looks like if you delete a relation09:39
jamthen when the agents see the Changed event09:39
jamthey get an EPERM trying to find out what changed09:39
jam(rather than, say, an ENOTFOUND)09:39
jamespagecan someone spare me some time to debug a juju-core 1.14.1/openstack havana problem I'm seeing?09:39
rogpeppewonderful errors without context09:39
rogpeppejamespage: what's the issue?09:39
jamespagerogpeppe, I can bootstrap an environment OK; but when I deploy services, extra instances are not being provisioned09:40
jamjamespage: does "juju status" tell you anything informative?09:41
jamespage'pending'09:41
jamoften it should give errors for the units you've asked for09:41
jamespageno errors09:41
dimiternjam, seems your analysis of that bug is correct09:41
jamdimitern: I'm pretty sure I know why it is failing, I'm not 100% sure what the correct behavior is09:42
jamespagejam, rogpeppe: I see this in machine-0.log09:42
jamespagehttp://paste.ubuntu.com/6187432/09:42
dimiternjam, the problem is, before we get the relation we can't really decide whether the user is allowed to see it or not09:42
dimiternjam, hence the ErrPerm there09:42
jamdimitern: don't we encode the endopints into the key itself?09:43
dimiternjam, but I guess the correct behavior is, rather than trying to fix the API (which is correct in this case - at least consistent), we should fix the uniter no to die on ErrPerm there09:43
jamso we could check if the agent is one piece of the relation that would-have-existed09:43
rogpeppejamespage: could you paste the whole log please?09:43
rogpeppejamespage: from the look of that last line it looks like it is actually trying to provision an instance09:44
jamjamespage: so given this is "com.canonical.serverstack.serverstack:ubuntu:..." I'm guessing this is a custom data source09:44
dimiternjam, "would-have-existed" for a remote entity (i.e. not our authenticated one), is meaningless, if we get NotFound from state09:44
jamjamespage: it *looks* like it properly finds an image id to launchd09:45
jamcandidate matches for products ["com.ubuntu.cloud:server:12.04:amd64"] are [0xc2004ac500]09:45
jamespagejam: yes - thats the simplestreams sync of data into our testing cloud09:45
jam(pointers don't help but the fact it isn't an empty list is a good sign)09:45
dimiternjam, I mean we can't distinguish between "this is something you should be able to see" and not09:45
jamdimitern: if "unit-0" has been validated, and asks about "relation-unit-0:unit-2" it doesn't seem like a problem to tell it ENOTFOUND09:46
jamespagestatus output - http://paste.ubuntu.com/6187449/09:46
jamdimitern: at least, I thought we changed relation-tags to hold the relation-keys which are crafted based on the unit endpoints involved09:46
dimiternjam, relation tags are exactly as the relation keys in state - no more, no less09:46
dimiternjam, informationwise09:46
jamespagejam, rogpeppe: http://paste.ubuntu.com/6187453/09:46
jamespagemachine-0.log file09:47
jamjamespage: the fact that we produce "openstack user data" should sounds like we are trying to start an instance09:47
jamSo it feels like we are missing the next lines09:47
dimiternjam, and just because unit 0 was validated doesn't mean "have access to any arbitrary service a relation tag might specify" imo09:47
jamdimitern: if it has *unit-0* in the tag09:47
jamthen it has access to relations involving *unit-0&09:47
jamunit-009:47
rogpeppejam: yes, that message is actually produced inside the openstack StartInstance method09:48
jamespagejam: agreed - I see calls to the nova-api for flavors and stuff09:48
dimiternjam, well, I guess, although not entirely convinced it should09:48
jamespagebut nothing related to actually starting an instance!09:48
rogpeppejamespage: i suppose it's possible that the startinstance request is blocking forever09:48
jamdimitern: why would a unit *ever* not have access to a relation involving that unit ?09:48
dimiternjam, if we check the relation tag before trying to get the relation from state and make sure one of the services is the same as our unit's service, then report NotFound instead of ErrPerm09:49
rogpeppejamespage: could you try something for me? kill -QUIT the jujud process09:50
jamjamespage: so, looking at the code09:50
jamthe next thing it does09:50
jamis try to set up a Security Group09:50
jamit is possible you're out of security groups09:50
jambut our error logging is terrible ?09:50
fwereade_jm, heyhey09:50
fwereade_jam ^09:50
jamhey fwereade_09:50
rogpeppejamespage: that *should* produce a stack trace to the log file, showing where everything is09:50
dimiternjam, how critical is this bug?09:51
rogpeppejam: if the StartInstance call fails, the provisioner *does* actually log the error immediately09:51
jamespagerogpeppe, http://paste.ubuntu.com/6187464/09:51
jamdimitern: it really depends, *I* would think that if a relation was deleted then we should fire a charm hook09:51
jamso the charm can clean itself up09:51
jamrogpeppe: but I'm wondering if we are hitting a failure in ensureSecurityGroup09:51
jamwhich I don't see any log messages about09:52
rogpeppejamespage, jam: yes, looks like the StartInstance request is blocked forever09:52
dimiternjam, that's a tall order - not many charms actually use that09:52
jamespagerogpeppe, jam: log from nova api server - http://paste.ubuntu.com/6187468/09:52
jamdimitern: if the appropriate behavior is "deleted relation, nothing happens" then it doesn't matter if the nothing-happens is done by restarting the agent or by just continuing the loop09:52
rogpeppejam: see goroutine 78 in that last paste09:52
dimiternjam, although restarting the agent kinda sucks09:52
dimiternjam, I'll look into it later today then09:53
jamjamespage: it does, indeed, appear to be stalled  in an HTTP request09:53
fwereade_jam, the uniter did itself clean up that relation completely, didn't it?09:53
jamfwereade_: no mention of it in https://bugs.launchpad.net/juju-core/+bug/123393609:53
_mup_Bug #1233936: worker/uniter: uniter restarts when relation removed <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1233936>09:53
fwereade_jam, looks like it's doing it to me09:54
jamfwereade_: however that loop is trying to aggregate f.relationsChanged(ids)09:54
jamfwereade_: if it can't get the id and returns immediately in the "range keys" loop09:54
jamthen it won't call f.relationsChanged09:54
jambecause the Uniter dies before it gets to call that09:54
jamfwereade_: now, I could be completely wrong about where the error is originating, because we don't have any clue but where the error was finally logged09:55
fwereade_jam, it doesn't need to call relationsChanged09:56
jamfwereade_: but if you hit the line 350 because err != nil and err != ENOTFOUND then you won't call f.relationsChanged09:56
jamfwereade_: so, am I wrong in believing that if you delete a relation it should trigger a charm hook ?09:56
fwereade_jam, the hooks have all already run09:56
rogpeppejam: is that the entire nova server log? i'd expect to see something around 09:34 (assuming the clocks are vaguely in sync)09:56
fwereade_jam, relation removal wastriggered by the completion of the last hook essentially09:56
jamrogpeppe: I think you mean jamespage ^^09:56
rogpeppejam: i do - very inconvenient juxtaposition of irc nicks :-)09:57
jamfwereade_: so dave's original bug was that he deleted the relation from the client09:57
jamespagerogpeppe, those where the calls I saw when issued the QUIT09:57
jamjamespage: do you know if nova logs when it starts a request or when it finishes them ?09:57
rogpeppejamespage: ah, i'd like to see what happened around the time the request was issued09:57
jamjamespage: given the "time" field09:57
fwereade_jam, if the filter sees a relation that doesn't exist, the uniter *by definition* has no knowledge of it09:57
jamsounds like when it finishes them09:58
jamjamespage: if something was hung, then you wouldn't have a nova log either09:58
jamespagerogpeppe, full log -http://paste.ubuntu.com/6187481/09:58
jamespagehttp://paste.ubuntu.com/6187481/09:58
fwereade_jam, if the uniter knew about it, it'd be in scope09:58
fwereade_jam, if it's in scope, the relation can't be removed09:58
jamfwereade_: so what does "delete the relation from a client mean" ? just trigger the teardown of the process ?09:59
fwereade_jam, destroy-relation will remove it straight off if no units are in scope; otherwise it sets dying and waits for the last departing unit to remove the relation as it does so10:00
fwereade_jam, it clearly ran the hooks that need to be run before leaving scope10:00
jamespagejam: not sure bout the logging10:00
fwereade_jam, and then the relation was somehow removed10:00
jamespagebut I do see several established connections on the API server from the bootstrap node10:00
fwereade_jam, the overwhelming balance of prob is that the uniter really did leave scope10:00
jamjamespage: .100 is the bootstrap node, right?10:02
jamespageyes10:02
jamfwereade_: so I think it boils down to: we used to get ENOTFOUND and now we get EPERM, is it best to return a nice ENOTFOUND if it looks like the uniter would have had access to that relation if it did exist.10:03
jamfwereade_: I'm still skeptical that rebooting is "just ok"10:03
jamas there is a step that would have happened if it had got ENOTFOUND10:03
jamso, (1) I definitely think this should be fixed, but (2) I'd accept that it isn't Critical10:04
jamfwereade_: but I actually wanted to chat about Uniter.CharmURL when we finish the other priority interrupts :)10:04
fwereade_jam, rebooting is just fine10:04
fwereade_jam, all the local uniter state for that relation is cleaned up before that can happen10:04
fwereade_I think the right thing is for the client to handle ErrPerm explicitly, given that we basically always return perm rather than notfound10:04
jamfwereade_: that seems *very* cavalier to me10:05
jamperhaps a "rebooting is fine in this cause because..."10:05
fwereade_jam, rebooting should not happen, but it doesn't cause any harm10:05
jamfwereade_: hence my "this should be fixed, but isn't Critical"10:06
axw_jam, rogpeppe, dimitern: joining?10:07
axw_mgz:10:07
jamjamespage: so from what I can see we are making an attempt, it is possible that the Openstack server is telling us "too many requests, try again after X seconds" and we will retry up to 3 times for that10:09
jamI would expect that to show up in the nova log, though.10:10
jamespagejam, rogpeppe: thats odd -  the two missing instances just started up10:15
rogpeppejamespage: ha ha10:15
jamespagerogpeppe, yeah - but the lag was massive10:16
rogpeppejamespage: that's probably because killing the agent terminated the requests, then it retried when it restarted10:16
rogpeppejamespage: so i suspect that for some reason those requests were blocked forever - i don't know if its our problem or nova's10:17
rogpeppejamespage: perhaps we should time-limit our requests10:17
jamespagerogpeppe, maybe - I turned off ratelimiting10:17
jamespagethat might be why it started working but I'm uncertain10:18
jamespagelet me test that again10:18
jamrogpeppe: I agree, we've had a bug reported that we would end up with huge amounts of "dead" connections because they never timed out10:20
arosalesfwereade_, thanks for the fix on bug https://bugs.launchpad.net/juju-core/+bug/121778110:24
_mup_Bug #1217781: machine destruction depends on machine agents <cts> <cts-cloud-review> <juju-core:Fix Committed> <https://launchpad.net/bugs/1217781>10:24
jamespagejam, rogpeppe: hmm - so I turned rate-limiting back on and its still fine10:24
jamespageodd10:24
jamjamespage: well we haven't done enough requests yet to cause a problem :)10:24
jamit may not be rate limiting10:25
jambut something in nova that starts a request and never finishes it10:25
jamespageadd-unit -n 16 worked just fine as well10:25
jamespagejam: lots of variables - might be sucky networking on 12.04 precise LXC (the cloud-controller is running in juju managed LXC)10:26
arosalesnatefinch, was the maas bug you were going to look into bug https://bugs.launchpad.net/gomaasapi/+bug/1222671 ?10:33
_mup_Bug #1222671: maas provider must only attempt to stop machines in the allocated state <cts-cloud-review> <Go MAAS API Library:Triaged> <https://launchpad.net/bugs/1222671>10:33
natefincharosales: no, there's a bug about juju going out and finding nodes that are part of a different juju environment and shutting them down10:36
arosalesnatefinch, ok10:38
arosalesnatefinch, added a comment to your merge request10:54
arosaleshttps://code.launchpad.net/~natefinch/juju-core/018-azure-help/+merge/188936/comments/43280210:54
arosalesthe hp cloud trailing "/" is important as that actually breaks config10:55
natefincharosales: you have to do "publish and mail comments" for me to see the comments.10:57
natefincharosales: I saw that bug you filed... is the slash supposed to be there or not?10:57
arosalesnatefinch, sorry I am not following usual core process here :-/10:58
arosalesbut you should see the comment in lp @ https://code.launchpad.net/~natefinch/juju-core/018-azure-help/+merge/18893610:58
arosalesnatefinch, the  trailing slash is supposed to be there for hp.10:59
mrammjam: you said you had two new bugs10:59
natefincharosales: ahh I see.. thanks.10:59
arosalesjam, fwereade_ can we quickly discuss https://bugs.launchpad.net/gomaasapi/+bug/1222671 ?11:00
_mup_Bug #1222671: maas provider must only attempt to stop machines in the allocated state <cts-cloud-review> <Go MAAS API Library:Triaged> <https://launchpad.net/bugs/1222671>11:00
mrammjam: can you target them to 1.15.1?11:00
jammramm: will do: bug #123457711:01
_mup_Bug #1234577: Uniter needs to support ssl-hostname-verification: false <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1234577>11:01
jamand bug #123457611:01
_mup_Bug #1234576: Upgrader needs to support ssl-hostname-verification: false <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1234576>11:01
natefincharosales: changes made from your comments. Thanks for looking.11:04
arosalesnatefinch, thanks11:05
arosalesthanks for getting that in too :-)11:05
jamdimitern: https://bugs.launchpad.net/juju-core/+bug/1233451 you can dupe it to something else if you already had a bug11:05
_mup_Bug #1233451: juju upgrade-juju results in unsupported behavior <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1233451>11:05
arosaleskeeping the help menu up to date that is11:05
natefincharosales: no problem. It bugs me when there aren't good docs on tools.11:06
arosalesnatefinch, yup and a bug UX issue11:11
natefincharosales: I also bugged evilnick and the web guys to make the docs more prominent on juju.ubuntu.com since they're really hard to find even if you know they're there somewhere11:12
mgzI wonder if we could fix bu 1222671 at the juju-core level, it seems a little similar to filtering the result of instances to machines in the building/running state11:12
mgznot sure if the list mass gives us actually has enough to trim out non-allocated machines though11:12
mgzbug 122267111:13
_mup_Bug #1222671: maas provider must only attempt to stop machines in the allocated state <cts-cloud-review> <Go MAAS API Library:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1222671>11:13
arosalesnatefinch, I will also follow up with the web team on that feedback.11:13
natefincharosales: I literally had to do a text search of the front page to convince myself there even was a link to the docs there11:14
arosalesouch11:14
arosalesnatefinch, a user has to go to Resources --> then docs11:15
jammgz: it does say "maas provider" which sounds juju-y,11:15
natefinchdavecheney: I called azure Windows Azure because that's what Microsoft calls it (even though it has nothing to do with windows): http://www.windowsazure.com/en-us/11:15
arosalesnatefinch, that is the correct name branding11:17
rogpeppefwereade_, axw_, mgz, dimitern: here's the fix for that address polling problem: https://codereview.appspot.com/14337043/11:17
dimiternrogpeppe, looking11:18
natefincharosales: Cool.  I just copied what they put on their website, figure they can't get mad at us for that :)11:18
rogpeppedimitern: thanks11:18
jamrogpeppe: it doesn't seem like IsUnimplemented should be a Warning11:20
rogpeppejam: ?11:20
rogpeppejam: oh, i see11:21
jamrogpeppe: https://codereview.appspot.com/14337043/patch/1/100711:21
rogpeppejam: i think it's reasonable to see that single message11:21
jamrogpeppe: on every boot, on etc, I really don't think we want a Warning11:21
rogpeppejam: won't you only see it in the machine agent log file?11:22
jamrogpeppe: it will end up in debug-log11:22
dimiternrogpeppe, reviewed11:22
rogpeppedimitern: ta11:22
jamand every time the agent restarts11:22
jametc11:22
dimiternjam, a little clarification about bug 1234576 ?11:22
_mup_Bug #1234576: Upgrader needs to support ssl-hostname-verification: false <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1234576>11:22
rogpeppejam: ok, i'll make it not log anything in that case11:22
jamrogpeppe: I would be ~ ok if it was INFO/DEBUG but Warning says that you might need to fix something, and this is explicitly unfixable11:22
jamdimitern: Upgrader grabs a Tools URL and then does net/http/Get of that file11:23
rogpeppejam: fair enough11:23
jamwe need a way to have Upgrader realize that EnvironConfig.SSLHostnameVerification() == false11:23
rogpeppedimitern: would you be happier if it was 100 years?11:23
jamdimitern: and then use utils.NonValidatingClient11:23
dimiternrogpeppe, why poll at all in this case?11:24
rogpeppedimitern: because it doesn't complicate the code any more11:24
dimiternjam, so basically the change is in fetchTools in the upgrader worker11:24
rogpeppedimitern: and we don't care if it does11:24
jamdimitern: and some sort of API to get the environ setting into the worker11:24
dimiternrogpeppe, it doesn't seem right11:24
jamdimitern: I was going to change the Tools api to include that bit11:25
jambut fwereade_ asked to make it a separate api call11:25
rogpeppedimitern: because...?11:25
jamI don't really care11:25
dimiternrogpeppe, it feels like we should stop polling and report an error there11:25
dimiternjam, why is the API involved at all here?11:25
rogpeppedimitern: the machine poller has to stay around, unless we refactor most of the logic in that worker11:25
jamdimitern: the Uniter worker doesn't have ENv creds11:25
jamand doesn't have ENvironConfig11:25
jamso it doesn't *know* if ssl-hostname-verification was set or not11:25
rogpeppedimitern: so it might as well just have a very long poll interval, i think11:26
dimiternjam, ah, it's an environ config setting, ok, I get it now11:26
jamdimitern: and essentially the same thing for Uniter downloading a charm11:26
rogpeppedimitern: which fixes this problem without making the code more complex for a case which is going to go away anyway11:26
jamthey don't have access to that config setting11:26
jamand need it in one fashion or another11:26
dimiternrogpeppe, doesn't it feel bad fixing it like that? :)11:26
rogpeppedimitern: no11:26
rogpeppedimitern: :-)11:26
rogpeppedimitern: it feels like a minimally invasive and perfectly sufficient change11:27
dimiternjam, so some call shared by the uniter and upgrader, called SSLHostVerification bool ?11:27
rogpeppedimitern: and when the local provider gets an Addresses implementation, we just need to delete 4 lines of code.11:27
fwereade_jam, dimitern: I think I'm sold on putting the ssl setting in the api calls that return urls11:27
fwereade_jam, dimitern: we can just use the env setting now, and we're free to improve it as jam suggested at our leisure11:27
jamdimitern: right, as mentioned I was going to put it into the existing API that they are already calling, but fwereade_ thought that was more risky11:27
rogpeppefwereade_: that seems good to me11:28
jamfwereade_: makes me happy, though dimitern the Uniter charm one is using a StringsBoolResult11:28
jamwhich is shared with GetP? call11:28
fwereade_jam, dimitern: I thought I just backpedalled on that but Ican't find where I typedit11:28
jamwhich is what I wanted to talk with fwereade_ about earlier11:28
fwereade_jam, dimitern: so: I'm fine putting a DisableSSLHostnameVerification bool into the existing results, I think11:29
dimiternfwereade_, jam, so adding a field to the result of the Tools() upgrader API call (which will make it available to the provisioner as well), and a field to the CharmURL() uniter call11:29
jamdimitern: that was the idea, yeas11:29
jamyes11:29
jamfwereade_: to be clear, the EnvironConfig setting is "SSLHostnameVerification"11:29
fwereade_jam, dimitern: it can always match the env config setting for now, and it's all behind the api so it's possible to be more sophisticated in future11:30
dimiternjam, camel case??11:30
jamdimitern: I mean, inverted true/false11:30
jamthe config setting11:30
jamyou set it to "false" to disable11:30
jamfalse => stop checking certs11:30
rogpeppedimitern: another possibility would be to have EnvironProvider implement a SupportsInstanceAddresses method, then avoid starting the worker at all if that returns false. that's more efficient but much more invasive.11:30
dimiternok11:30
fwereade_jam, dimitern: and definitely not CharmURL11:31
dimiternrogpeppe, but certainly feels more like the right thing to do11:31
dimiternfwereade_, what?11:31
rogpeppedimitern: we'll only want to rip it out again later.11:31
fwereade_jam, dimitern: CharmURL is completely irrelevant AFAICT11:32
fwereade_jam, dimitern: why would we ever change that?11:32
rogpeppedimitern: there's no point in making all the code base more complex for this little temporary hack.11:32
dimiternfwereade_, I don't know, just asking to figure it out what needs changing11:32
dimiternrogpeppe, why temporary? when is it going away?11:32
fwereade_jam, dimitern: we're thinking of CharmArchiveURL11:32
jamrogpeppe: dimitern: for polling, I could see some value in a say 1/hour message indicating that if the IP address were to change, we wouldn't notice11:32
fwereade_jam, dimitern: CharmURL itself is completely different11:33
jamfwereade_: so *shrug* I hadn't finished writing it. But whatever we actually download needs to change.11:33
fwereade_jam, dimitern: obviously :-/11:33
rogpeppedimitern: when the local provider implements Instance.Addresses, which i hope will happen quite soon11:33
fwereade_rogpeppe, you have any idea how to do that?11:33
dimiternrogpeppe, ok, but please bug it and add a TODO about that11:33
dimiternlest we forget later11:34
jamrogpeppe: an infrequent message so when something does happen and the user goes WTF is kind of nice, but I'm happy with what you've done, (though it shouldn't be a Warning)11:34
fwereade_jam, dimitern: so anyway -- the only other thing to be careful about is how a false value for that field will be interpreted, because that's what we'll always get returned from 1.1411:35
jamrogpeppe: and I'm pretty strong on a JFDI to be done :)11:35
jamfwereade_: fair point11:35
jamand one that I would have gotten to, yes11:35
rogpeppefwereade_: well, the local provider implements DNSName and i am presuming that Addresses is going to supplant DNSName completely11:35
jamfwereade_: I think I was leaning towards Disabled11:35
jambut when I saw it just now I thought it should line up11:35
dimiternfwereade_, jam, ok, it seems not CharmURL, but ArchiveURL is the one to patch in the uniter11:35
fwereade_jam, dimitern: so we might need to invert meaning for sanity's sake, but today I fail boolean logic11:35
dimiternfwereade_, right, "false" will mean do verification11:37
dimiternfwereade_, so he field will be called SkipSSLHostnameVerification11:37
dimiternor NoSSLHostnameVerification11:38
fwereade_dimitern, let's call it Disable to match the setting it's mirroring maybe?11:38
rogpeppejam: it would be nice if you didn't get a log message every time it polls actually, although i'm not sure how to do that while preserving useful information.11:39
dimiternfwereade_, ok DisableSSLHostnameVerification in ArchiveURL() and Tools()11:39
jamfwereade_: so it *really* looks like CharmURL from everything I've traced through11:39
fwereade_dimitern, actually I may be on crack, I have no idea11:39
fwereade_jam, CharmURL is "cs:" or "local:"11:39
jamfwereade_: ok, it turns out the object returned which has URL inside it is "live" and have a connection to the API11:39
dimiternjam, fwereade_, uniter.charm.download() uses ArchiveURL()11:40
jamit wasn't very clear that it wasn't just a blob of data11:40
rogpeppejam: we could log only if the message is different, but i suspect that some providers will include a bunch of other stuff in the error message including request ids etc which would make that not work11:40
jamdimitern: well, getArchiveInfo("CharmArchiveURL")11:40
jamdimitern: ah, but the API for it is ArchiveURL11:40
jamgotcha11:40
dimiternyep11:40
jamit is hard to figure out what Charm object I'm looking at11:40
jamacross 3 level11:40
jamlevels11:40
jamor more11:40
fwereade_rogpeppe, AFAICT the local provider Instance is completely fucked11:40
jamas they are all *just called Charm*11:41
fwereade_rogpeppe, and will never work11:41
fwereade_rogpeppe, except for machine 0 :/11:41
rogpeppefwereade_: i didn't look at it too much11:41
rogpeppefwereade_: fucked how, exactly?11:41
jamfwereade_: so in default Precise, you can't find the IP address for the lxc's you started, only the instances themselves can report it back. *however* the 12.04.03 update gives us better LXC tools and lxc-ls *does* give us the info11:42
jamfwereade_: so I don't think we're just-fucked11:42
fwereade_rogpeppe, getAddressForInterface("eth0") to get an address for some other container?11:42
jamfwereade_: ^^ we change to us the lxc-* tools once we can assume we have the updated tools11:42
jamwhich is at least *some* of what we want Cloud-tools archive for11:42
fwereade_jam, indeed, that's cool11:43
fwereade_jam, sooooo11:43
fwereade_jam, rogpeppe: ...we'll need an address updater permachine agent, then?11:43
rogpeppefwereade_: don't they all share the same address space currently?11:43
fwereade_rogpeppe, sure11:44
fwereade_rogpeppe, but getting one's own eth0 is unlikely to help in determining the address of something completely distinct11:44
rogpeppefwereade_: so it's kinda fit for purpose *currently*...11:45
jamrogpeppe: right, william is just remarking that the current implementation will never work to get addresses for another machine, but there are plans to change how we do it11:45
fwereade_rogpeppe, by sheer ridiculous luck, yes, it works in the single situation it's usedbecauseit appens to run on the correct machine11:46
rogpeppefwereade_: i won't argue with that :-)11:47
yolandahi, i'm using juju-deployer to deploy a set of charms, but i find this error : error: cannot get latest charm revision: charm not found in "/home/yolanda/development/canonical-ci": local:precise/postgresql - shouldn't be local:postgresql, not local:precise/postgresql ?11:48
jamyolanda: official charm locations have the series in them11:49
jamlocal repos have a directory with the series11:49
jamso $REPO/precise/postgresql would be the structure that you would do "juju deploy --local --repo $REPO postgresql11:49
jamand jujut 'fills in' the default series (aka precise)11:49
yolandajam, i know it, but i'm asking about juju-deployer, it embeds the precise into it11:50
yolandaif i deploy locally with local:charm works, but juju-deployer is deploying that as local:precise/charm11:50
jamyolanda: you can also "juju deploy precise/postgresql"11:50
jamI think11:50
jamyolanda: I'm pretty sure that is supposed to work11:50
yolandai don't have control about juju deploy commands using juju-deployer wrapper, it's automated11:50
yolandaso my question is about deploying using juju-deployer wrapper, not manually using juju deploy, which works for me11:51
yolandajam ^11:52
fwereade_yolanda, a charm url is not valid without a series11:53
jamyolanda: and I'm saying, that shouldn't be the problem, because both syntaxes are supposed to be valid11:53
fwereade_yolanda, local:postgresql is  shorthand for user input only11:54
fwereade_yolanda, there is no such actual charm as local:postgresql11:54
yolandajam, fwereade, but then juju complains if i use local:precise/postgresql, and works if i use local:postgresql11:54
yolandaas juju-deployer uses first syntax, it gives me error11:54
yolandaif first url is set to be working, what can be stopping to work in my environment?11:54
fwereade_yolanda, so the charm is in $REPO/precise/posgresql, right?11:55
yolandayes11:55
jamyolanda: it isn't something like you changed default series and actually have $REPO/saucy/postgresql locally, right?11:56
yolandajam, no, series is set as precise11:56
yolandaand i have $REPO/precise/postgresql charm there11:56
fwereade_yolanda, and "juju deploy local:precise/postgresql" does not work, while "juju deploy local:postgresql" does?11:57
yolandafwereade_, sorry, tried manually now with local:postgresql and doesn't work also11:57
yolandabut i have the charm in my local repo11:58
fwereade_yolanda, what's the charm name in the metadata?11:58
yolandapostgresql11:58
fwereade_yolanda, if you run with --debug, do you see any "failed to load charm at" warnings?12:01
yolandalet me try it12:01
yolandamm... 2013-10-03 12:01:48 WARNING juju repo.go:341 charm: failed to load charm at "/home/yolanda/development/canonical-ci/precise/postgresql": YAML error: line 6: found a tab character where an intendation space is expected12:02
yolandathat should be a bug in postgres charm?12:02
jamyolanda: looks like12:02
fwereade_yolanda, sounds like12:02
fwereade_:)12:02
yolandai can fix it and do an mp12:03
yolandafwereade. should i raise a bug?12:04
fwereade_yolanda, sorry, against what? it looks like it's a charm problem, but equally juju could probably somehow do better on that front12:05
fwereade_yolanda, local repos are pretty baroque12:05
rogpeppefwereade_: BTW rather my don't-poll fix, why don't i just implement Addresses in the local provider to simply call the existing DNSName method12:06
rogpeppe?12:06
rogpeppes/rather/rather than/12:06
rogpeppefwereade_, mgz, dimitern: can you think of any down sides to the above?12:06
yolandafwereade, well, i was thinking in an MP for postgresql charm, but a bug against juju, to deal with malformed files... what do you think?12:06
mgzrogpeppe: I nearly asked in the standup why not just implement it for local12:07
dimiternrogpeppe, if it works by live testing, why not12:07
mgzthe hard case is containers in another provider, I didn't remember any local catches12:07
rogpeppemgz: i don't know why i didn't think of that, tbh12:07
jamyolanda: if "juju deploy cs:postgresql" works, I would guess there is something other than a bug in the charm itself12:07
rogpepperight, i'll ditch that CL12:07
yolandajam, i branched lp:charms/postgresql, and config.yaml file has tabs instead of spaces, that's right12:08
yolandamaybe it's not the same version as in charmstore?12:08
jamyolanda: I see it here, I think: http://bazaar.launchpad.net/~charmers/charms/precise/postgresql/trunk/view/head:/config.yaml12:09
jamIt looks like someone's editor changed spaces to tabs12:09
jam"helpfully"12:09
yolandado you want me to create the mp?12:10
jamyolanda: and that change is in the very last commit to lp:charms/postgresql12:10
yolandaor are you dealing with that?12:10
fwereade_jam, also looks like whoever committed it didn't try deploying it before doing so12:10
jamfwereade_: yep12:10
fwereade_jam, yolanda: but I imagine the charm store just ignored it because it's invalid12:10
jamfwereade_: stub merged richard's patch, but looks like he accidentally broke it12:10
mgzyolanda: go ahead and fix and propose I'd say12:10
yolandaok12:10
fwereade_jam, ahhh :)12:10
fwereade_yolanda, so an MP against the postgres charm would be great12:11
yolandaok, doing it12:11
jamfwereade_: it looks like the last change from Richard was to clean-up the description for one of the fields12:11
fwereade_yolanda, re juju-core, the idea was that local repos would ignore things that aren't valid charms12:11
jamand, naturally, that breaks everything12:11
jambut was "just a comment fix"12:11
jamso it wasn't tested12:11
fwereade_yolanda, we have had troublein the past in whichone broken charmin a repo prevents anything being deployedfrom that repo12:12
fwereade_jam, heh12:12
yolandafwereade, ideally if these changes can't go into cs, it will be ok, the problem will be only if using some launchpad branch12:13
fwereade_yolanda, so I can't see a clear way forward that fixes your surprise without breaking things much worse12:13
fwereade_yolanda, yeah12:14
jamfwereade_: reporting the warning by default would help :)12:14
jam(there was something that looks like what you requested, but it isn't actually valid)12:14
yolandafwereade, jam: https://code.launchpad.net/~yolanda.robla/charms/precise/postgresql/fix_tabs/+merge/18905712:17
jamyolanda: lgtm, but Stub is the maintainer of that charm12:17
fwereade_jam, there wasn't really anything that actually looked like you wanted though12:18
fwereade_jam, directory name is irrelevant12:18
jamI hopefully poked him in another window12:18
fwereade_jam, hmm, ok, maybe it did, I guess we read the metadat without difficulty12:18
yolandajam, cool, i'll update manually in the meantime12:19
fwereade_jam, actually showing that output by efaultwouldhave been helpful though12:19
jamyolanda: stub says he's landing it now12:19
yolandabut yes, instead of reporting as "charm does not exist", maybe juju deploy could show some error about invalid charm or something like that12:19
fwereade_yolanda, well, juju was 100% accurate, there was no such charm in the repo12:21
fwereade_yolanda, I think that the error is correct, and that just warning about broken charms is the Right Thing to do12:22
fwereade_yolanda, it feels like the worst bit is that the warning got swallowed by default12:22
dimiternjam, 2013-10-03 12:22:39 ERROR juju supercommand.go:282 disabling ssh-hostname-verification is not supported12:22
dimiternjam, how can I test it if I cannot disable it?12:23
jamdimitern: so it should work for openstack, which is the one we care about12:23
yolandafwereade, if you enable debugging you can see it, but if not you aren't aware of the error12:23
jamdimitern: or you could just comment out that config validation failure12:23
dimiternjam, oh, I need to dust out my canonistack permissions12:23
jamif you really want to test on EC212:23
jamdimitern: or hp12:23
jamdimitern: fwiw I tested the previous steps by mv /usr/share/ca-certificates and then running commands12:24
jamotherwise the cert is still valid so it wouldn't fail whether you had that flag or not12:24
fwereade_yolanda, yeah, hiding important messages STM like a juju-core bug, please go ahead12:25
rogpeppeis there any way to get sudo to preserve your existing $PATH ?12:25
fwereade_yolanda, thanks12:25
fwereade_-E12:25
jamrogpeppe: sudo -E ?12:25
rogpeppejam: doesn't preserve $PATH, it seems12:25
dimiternjam, /usr/share/ca-certificates where?12:25
jamrogpeppe: "man sudo" says "ENvironment PATH may be overridden by the security policy"12:26
fwereade_rogpeppe, works for me, anyway12:27
jamrogpeppe: so you could probably remove the Paths line from config if you wanted to avoid that12:27
jambut you can't guarantee it12:27
jamfor $ARBITRARY_USER12:27
dimiternjam, on your machine or ?12:27
jamdimitern: so for "juju bootstrap" I did it on my machine, and then ssh'd into the started machine and did it there to test the line in cloud-init12:27
rogpeppejam: i'm just trying to work out a decent way of using the local provider when you're not using /usr/bin/juju12:28
dimiternjam, ok, so I'll do it on machine 0 once it starts and restart the agent12:28
jamdimitern: but honestly, if you are using utils.NonValidating that is *known* to work properly with non-validating certs.12:28
jamrogpeppe: sure, thumper said earlier "sudo `$(which juju)` bootstrap"12:28
dimiternjam, it's actually utils.GetNonValidatingClient()12:29
jamdimitern: sure12:29
rogpeppejam: that doesn't work12:29
dimiternok12:29
rogpeppejam: i'm doing this currently: x=$PATH sudo -E sh -c 'export PATH=$x; juju bootstrap --debug'12:29
jamdimitern: if you're using the one that the other stuff uses, I've tested that pretty well. You *can* write a test case for it12:29
rogpeppejam: which isn't ideal12:29
jamusing httptest.Server12:29
jamdimitern: I don't have a test for cloud-init specifically, because we don't have any 3rd-party clouds that we have creds to that don't use valid certs12:30
jamdimitern: but I *do* have a bunch of openstack localHTTPSServer tests12:30
jamfor the actual Provider interaction12:30
dimiternjam, well, it seems to work ok12:35
rogpeppedimitern, jam, mgz: alternative fix to the logging spam problem: https://codereview.appspot.com/1433904312:36
rogpeppefwereade_: ^12:36
dimiternrogpeppe, no tests?12:38
rogpeppedimitern: there are no tests for DNSName, (this is a thin wrapper around that), and I don't want to block this on adding appropriate testing to that12:38
dimiternfwereade_, jam, https://codereview.appspot.com/14340043 - fix for bug 1234576 (one of the best ids so far!)12:38
_mup_Bug #1234576: Upgrader needs to support ssl-hostname-verification: false <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1234576>12:38
rogpeppedimitern: i raised a bug12:38
dimiternrogpeppe, ok, please live test it at least12:39
rogpeppedimitern: i have12:39
rogpeppedimitern: at least, i've verified that we don't get the log spam - there's no externally visible way currently to see the output of Addresses.12:39
dimiternrogpeppe, reviewed12:40
dimiternrogpeppe, why?12:40
rogpeppedimitern: because nothing uses it yet12:40
dimiternrogpeppe, can't you log what addresses you get and compare them?12:41
dimiternrogpeppe, not as part of the code, just for testing12:41
rogpeppedimitern: we could write a test that does that, yes12:41
rogpeppedimitern: and the addressupdater code tests that12:41
rogpeppedimitern: but you can't see what Addresses are attached to a machine by looking at juju status, for example12:42
dimiternrogpeppe, I meant simply adding a log.Errorf("Addresses returns: %v", addresses) and bootstrapping a local environment12:42
dimiternrogpeppe, and use lxc-ls or something to get the container addresses?12:42
mgzdimitern: we run into the precise problem with that12:44
mgzlxc-ls is useless on precise12:45
rogpeppedimitern: we're talking about two statements here. i believe that they work, and it doesn't actually matter if they don't. we need more testing in this area, but i don't think it matters at this moment.12:45
dimiternrogpeppe, are you running precise?12:45
rogpeppedimitern: no12:45
dimiternrogpeppe, ok then12:46
mgzah, you didn't mean doing that in the code?12:46
mgzread through the conversation a bit too fast :)12:46
dimiternI simply meant as a local live test12:46
dimiternbut whatever12:46
dimiternseeing is better than believing alone12:47
yolandafwereade, jam: https://bugs.launchpad.net/juju-core/+bug/123468712:47
_mup_Bug #1234687: juju is hiding bugs in charms <juju-core:New> <https://launchpad.net/bugs/1234687>12:47
natefinchmgz, rogpeppe, fwereade_, jam:  anyone want to finish up the review Dave started?  Just docs, but I'd like them in asap: https://codereview.appspot.com/14207048/12:47
mgznatefinch: if no one beats me to it, I'll look after doing various code cleanup things on my branch12:52
natefinchmgz: thanks12:53
rogpeppenatefinch: any particular reason you added the extra newline before the Doc text in addmachine.go ?12:53
rogpeppenatefinch: ha, it looks like it's stripped anyway12:54
natefinchrogpeppe: it makes the text in-code more clear not to have it indented due to the variable assignment, and they produce the same output anyway... I'm trying to keep all the doc formatting the same12:54
natefinchrogpeppe: yep12:54
fwereade_rogpeppe, I am confused by https://codereview.appspot.com/14339043/12:56
rogpeppefwereade_: go on12:57
fwereade_rogpeppe, didn't we agree that local.Instance.DNSName isno good unless it's run on the relevant instance?12:57
jamdimitern: so one test we *could* add is to set up the local dummy service with an HTTPS Server and assert that the Upgrader is able to find the tools, do you think that is worthwhile?12:57
rogpeppefwereade_: well, Addresses is in exactly the same boat12:57
fwereade_rogpeppe, I would*much* rather have the notimplemented hack than poke bad data into state12:57
rogpeppefwereade_: and it's never called for real12:58
rogpeppefwereade_: the bad data is already in state12:58
fwereade_rogpeppe, how did it get there?12:58
rogpeppefwereade_: by calling Instance.DNSName, no?12:58
dimiternjam, seems extreme12:58
fwereade_rogpeppe, when did that go into state?12:58
jamdimitern: well it is the only thing that we actually care about12:59
jamyou don't ever test that the boolean we return is actually acted upon12:59
fwereade_rogpeppe, the only addresses we have hitherto stored (that I am aware of) have come from code running on the instances in question, as part of uniter setup12:59
dimiternjam, I have no idea how to do that12:59
rogpeppefwereade_: good point, but... how is Addresses any different from DNSName ?13:00
rogpeppefwereade_: the result of Addresses isn't going into the state either13:00
rogpeppefwereade_: .... is it?13:00
fwereade_rogpeppe, huh? isn't that precisely what addressupdater does?13:00
rogpeppefwereade_: ha, i see13:00
jamdimitern: so in the interests of getting 1.15.1 out the door, I think we should probably just land it, have you implement the next one, land it, and then come back to fill in the tests13:01
rogpeppefwereade_: erm, aren't things using the result of instance.DNSName currently to decide where to connect to?13:01
jamdimitern: but http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/provider/openstack/local_test.go#L705 is what I set up for the Openstack HTTPS tests13:01
fwereade_rogpeppe, yeah, but by sheer luck the only things that do are running somewhere where Instance.DNSName happens to be correct13:01
rogpeppefwereade_: i don't really mind storing the DNSName results in state - it's not as if they're permanent13:02
fwereade_rogpeppe, they are *wrong*, and they will fuck everything up13:02
rogpeppefwereade_: any time we upgrade to make a better implementation, the addresses stored in state will change appropriately13:02
fwereade_rogpeppe, asking a unit for its addresses asks the machine first13:02
fwereade_rogpeppe, if you put bad data into machines, units start reporting the wrong addresses13:03
dimiternjam, sgtm, will have a look after landing these two13:03
rogpeppefwereade_: hmm, so if there's no machine address, the uniter uses an EnvironProvider method to find the address of itself?13:04
fwereade_rogpeppe, yeah13:04
fwereade_rogpeppe, well, the unit always does that13:04
fwereade_rogpeppe, but machine addresses are the canonical location13:04
fwereade_rogpeppe, we just can't yet drop the unit address lookup13:05
fwereade_rogpeppe, precisely because we can't get good addresses for the machines in all cases13:05
rogpeppefwereade_: does that mean the address updater cannot work in the local provider?13:05
fwereade_rogpeppe, I thought you already knew that, and that was the reasoning behind the notimplemented thing :)13:05
fwereade_rogpeppe, until we can use a new lxc-ls everywhere, yes13:06
rogpeppefwereade_: ah, i see - i hadn't realised that was the blocker13:06
mgzgah, right we do need a working lxc-ls for the local provider13:07
rogpeppefwereade_: in which case,  there's https://codereview.appspot.com/14337043/ instead13:07
fwereade_rogpeppe, that LGTM if it's really hard to abort the loop vs polling once per year13:09
rogpeppefwereade_: it would have to duplicate a lot of the loop's logic (reading on Dying, sending on died, reading on changed, exiting when dead); i don't really see the advantage of doing it.13:11
rogpeppefwereade_: unless, as i said above, we added some method to EnvironProvider, but that has tentacles and seems way overkill for killing a few log messages.13:11
jamdimitern: step one LGTM13:12
fwereade_rogpeppe, were it not for the tentacles, that would be my favoured solution13:12
fwereade_rogpeppe, but I'm looking for mr right now, not mr right ;p13:13
jamfwereade_: but the tentacles are the tasty part :)13:13
fwereade_jam, I have a sudden recollection of laura over summer... playing peter pan with cuddly toys... "and cthooley can be tinkerbell"13:15
fwereade_(my stepmother had a cuddly cthulu)13:15
mgzthat's pretty ace13:16
fwereade_I thought so :)13:16
dimiternjam, thanks13:19
rogpeppefwereade_: i had a sudden thought that if it found an unimplemented error, it could kill the whole worker (ensuring it doesn't restart), but it's not that straightforward to do, sadly.13:22
fwereade_rogpeppe, ah, not to worry13:23
fwereade_rogpeppe, maybe a short comment explaining why it's necessary would be a good idea though13:23
rogpeppefwereade_: i'm adding one13:23
fwereade_rogpeppe, cheers13:24
rogpeppeit wouldn't be *too* hard (just make a special error that is recognised by worker.Runner that says "i really want to quit without taking anything else down or being restarted"), but not for now.13:24
fwereade_rogpeppe, agreed13:25
dimiternjam, added bug 1234715 for that13:26
_mup_Bug #1234715: Verify SSLHostnameVerification: false behavior with a test (upgrader, uniter) <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1234715>13:26
rogpeppedimitern, fwereade_: landin13:32
rogpeppeg13:32
dimiternrogpeppe, the "no log spam" thing?13:33
rogpeppedimitern: yeah13:33
dimiternrogpeppe, sweet13:33
rogpeppedimitern: i changed unimplementedError to notImplementedError13:33
rogpeppedimitern: and added a comment about the 1y thing13:34
dimiternrogpeppe, great, thanks13:34
dimiternjam, fwereade_ this is the fix for bug 1234577 https://codereview.appspot.com/1433704413:34
_mup_Bug #1234577: Uniter needs to support ssl-hostname-verification: false <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1234577>13:34
rogpeppefwereade_: i don't know if you saw last night, but i succeeded in bootstrapping a live ec2 environment with a environments.yaml entry that was just "myenv": {"type": "ec2"}13:35
rogpeppefwereade_: which is quite cool13:35
dimiternrogpeppe, you have your AWS_* env vars set then13:36
rogpeppedimitern: yeah, it needed them of course13:36
fwereade_rogpeppe, nice, I did that too, it was very satisfying :)13:36
jamdimitern: reviewed LGTM14:00
mattywfwereade_, I'm hoping to point you in the direction of a merge proposal later for the id stuff (just the api and owner-get tool) would I be able to grab you today to talk about the next stage (user creation and deletion)14:04
mattyw(I appreciate you're busy at the moment)14:05
fwereade_mattyw, I have 20 mins until my next meeting and had had not much expectation of accomplishing other things in the interim, so that's perfect  :)14:10
fwereade_mattyw, otherwise sometime later should also be fine14:10
mattywfwereade_, if now's good I'm ready to listen :)14:11
fwereade_mattyw, I think there's an intermediate step14:12
fwereade_mattyw, in which we explicitly set the admin user on the services she creates14:12
mgzrogpeppe: don't know if you want to re-stamp the default vpc branch before I land, have made the changes you suggested14:13
fwereade_mattyw, taking care to keep the services which don't have that field still working14:13
fwereade_mattyw, at the state level, that involves adding a param to AddService14:14
fwereade_mattyw, and at the apiserver level it involves extracting the entity tag from the connection and passing it into AddService14:14
fwereade_mattyw, shouldn't otherwise hit the API at all I think14:15
dimiternjam, cheers14:15
mattywfwereade_, so that would mean that any service that gets deployed would have the admin-user set as the owner of that service?14:15
mattywand no change to the command line args14:15
fwereade_mattyw, yeah, that'd be the effect14:15
mattywfwereade_, and again - we'd just hardcode the user - so we'd add a oarameter to addservice - but we'd also pass a hardcoded "user-admin" to it?14:17
fwereade_mattyw, the api server knows who's connected to it14:20
fwereade_mattyw, you can get the tag from ... uh, somewhere14:20
fwereade_mattyw, so while there's only one user still it *will* always be user-admin14:21
fwereade_mattyw, but it sets us up to do the right thing transparently when there are more users14:21
fwereade_mattyw, adding users is easy, and deleting them is a bit more interesting, but I think that's something we can ignore for a little bit longer14:22
fwereade_mattyw, sorry, popping out for a quick cig before 4:3014:23
fwereade_mgz, rogpeppe, natefinch, dimitern: are your https://launchpad.net/juju-core/+milestone/1.15.1 bugs up to date?14:30
fwereade_and would someone please take a look at axw's https://codereview.appspot.com/14329043/ and, if it checks out, land it for him please? (unless he's actively here?)14:31
mgzfwereade_: yes, but I'm about to bot-propose mine now, so the bot will change status shortly14:32
mgzcan also pick up that cl if needed14:33
dimiternfwereade_, yeah, except I'm not doing the upgrade one for now, until I land the other 2 fixes14:34
dimiternand the bot is not being helpful14:34
mgzdimitern: what's up with the bot?14:36
mgzI'm just about to poke14:36
dimiternmgz, it seems the random test failures have increased14:37
dimiternmgz, and the variety of the packages that fails as well14:37
rogpeppehmm, the error you now get when destroying an already-destroyed environment is not great: http://paste.ubuntu.com/6188368/14:41
natefinchwow, that's bad14:42
fwereade_mramm, call is full14:44
mramm:(14:44
mrammsinzui: hey, is this in progress bug completed? https://bugs.launchpad.net/juju-core/+bug/123445615:09
_mup_Bug #1234456: release-public-tools.bash must be hacked to work with debs <juju-core:In Progress by sinzui> <https://launchpad.net/bugs/1234456>15:09
dimiternmgz, did you update bot's goamz?15:12
mgzdimitern: I did15:12
mgzwas the only poke I made in that case15:13
dimiternok15:13
mgzbut I can try and help you with other things15:13
sinzuimramm, I need to land it15:13
sinzuioh, and it didn't land15:13
mrammok15:13
mgzso, 1.15.1 is going to be from r194X, right? when the last bit we want gets landed today?15:14
mgzsinzui: can you link me the release notes doc so I can add a note?15:15
sinzuimgz, https://docs.google.com/a/canonical.com/document/d/1o8YsLrQuadB1gbd5veJ3cpN_r2uozKwwTmIh1RmOVHM/edit#heading=h.h7wry0fbg19715:16
mgzsinzui: ta!15:17
sinzuimgz, can you give me a clue to resolve this error: http://pastebin.ubuntu.com/6188547/15:25
mgzsinzui: to land things on juju core, we just mark the mp approved and the bot looks for that15:26
sinzuimgz, I think it is https://code.launchpad.net/~sinzui/juju-core/release-public-tools-with-streams/+merge/18896615:26
mgzaaron's lp:rvsubmit is a pretty bzr plugin to make it easy15:27
mgzsinzui: +add a commit message15:27
sinzuidoh!, I get hate mail from the lander we created for charmworld. I assumed it did the same15:27
mgzyes, it's very confusing needing to use `lbox propose` but needing to NOT use `lbox submit`15:28
dimiternwell, the first 2 times maybe, but then you just forget about lbox submit15:28
dimiternfwereade_, ping15:30
mgzdimitern: till you then need to land something on goamz or the like, and rediscover it :)15:31
dimiternmgz, yeah, although we can bring goamz under the bot as well :P15:31
fwereade_dimitern, pong15:32
dimiternfwereade_, re bug 123345115:33
_mup_Bug #1233451: juju upgrade-juju results in unsupported behavior <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1233451>15:33
dimiternfwereade_, is this for today as well?15:33
dimiternfwereade_, (i.e. 1.15.1)15:33
fwereade_dimitern, I had not thought it was, I was a little surprised to see it there15:36
fwereade_dimitern, it's only necessary if we have to do 1.20 before 2.015:37
dimiternfwereade_, yeah, because I definitely won't manage for today with it15:37
fwereade_dimitern, and certainly shouldn't block today, indeed15:37
fwereade_dimitern, I guess take it off the milestone15:37
dimiternfwereade_, done15:38
rogpeppethese kinda of sporadic failures are worrying; i have no idea what's going on here: https://code.launchpad.net/~rogpeppe/juju-core/436-addressupdater-log/+merge/189012/comments/432808/+download15:43
fwereade_rogpeppe, the bright side I suppose is that the suite eventually recovers from the dirty socket problems15:50
* fwereade_ has to go out for a while -- would mgz, rogpeppe, dimitern, natefinch look after the remaining 1.15.1 bugs please?16:04
rogpeppefwereade_: yeah, i'm still live verifying stuff16:05
natefinchfwereade_: sure thing16:05
fwereade_thanks guys16:06
natefinchrogpeppe or mgz:  if one of you can check out my docs changes, I can land them to get that one off the list: https://codereview.appspot.com/14207048/16:06
mgznatefinch: right, really doing that now16:06
rogpeppenatefinch: sorry, i got diverted while looking at them16:06
dimiternsinzui, https://bugs.launchpad.net/juju-core/+bug/1234456 fix has landed, right?16:10
_mup_Bug #1234456: release-public-tools.bash must be hacked to work with debs <juju-core:In Progress by sinzui> <https://launchpad.net/bugs/1234456>16:10
sinzuidimitern, yes16:10
dimiternsinzui, ok, marked as Fix Committed16:10
sinzuioh, sorry, I thought gobot could do that16:10
dimiternlbox does weird things sometimes, like changing milestones around16:10
dimiternsinzui, it used to but it stopped a while ago I think16:11
mgznatefinch: see review16:13
natefinchmgz: initial newlines are stripped automatically already... it just makes the code cleaner when you have it all smashed up against the left side of the window.  And I ordered the providers alphabetically on Dave's suggestion... it seems more fair and an easier rule to follow.16:15
mgzfair enough16:16
natefinchmgz: I'll make those removals though, thanks.16:16
dimiternapproving axw's fix for bug 123412716:17
_mup_Bug #1234127: juju should enable cloud-tools pocket for Precise <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1234127>16:17
dimiternthat's the last one for 1.15.1 after nate's16:17
rogpeppemgz: reviewed16:19
mgzrogpeppe: thank you. natefinch ^16:20
rogpeppemgz: ta16:20
rogpeppenatefinch: thanks for doing that - it's really good to make docs more consistent16:20
natefinchrogpeppe: np.  Happy to put my little bit of OCD to good use :)16:20
natefinchrogpeppe: thanks for the review16:21
natefinchso glad sublime text has alt-q to wrap the current paragraph to the column ruler.... it even preserves indents and line prefixes so you can use it on stuff that's commented out16:24
hazmatarosales, so what's been missing in the azure provider affinity group discussion, is what changed from when it when worked well for other regions in 1.14.116:31
arosaleshazmat, the defaults were East16:33
arosalesand the tools were in east16:33
arosalesso not affinity issues16:33
arosalesissue is when you try to deploy in West16:33
hazmatarosales, hmm.. ic, thanks16:34
rogpeppefwereade_: i'm wondering about the behaviour of juju when you try to use (not bootstrap or sync-tools) an environment that has no associated info. at the moment you'll get a config error if the environments.yaml file omits some prepare-time attributes, such as admin-secret.16:38
rogpeppefwereade_: i'm thinking that it there's no associated info and creating a new Environ directly from environments.yaml fails, that we should just return an "environment does not exist" error.16:39
rogpeppefwereade_: or perhaps "environment has not been created"16:40
rogpeppefwereade_: and that when everyone has .jenv files, we can just fail when there's no associated info, with the same error16:40
arosaleshazmat, I don't know if it is a juju thing that is setting the affinity group or Azure16:43
arosaleshazmat, I found this http://michaelwasham.com/2012/08/07/http-error-message-the-location-or-affinity-group-east-us-specified-for-source-image/16:44
arosalesbut juju is only reading the public tools which I wouldn't think would cause an affinity group set, but I don't know.  That is the main question16:44
arosalesthe juju tool read does happen first,16:44
hazmatarosales, interesting that link does suggest a solution16:45
arosaleshazmat, basically upload tools to the same region you deploy in, or are you reading something different there?16:45
hazmatalthough exactly where the issue is not entirely clear either without further investingation16:45
arosaleshazmat, it also may be that my juju control bucket for storage is in east when I try to deploy in west . . .16:46
hazmatarosales, i'll try digging deeper over the weekend if no else has gotten to it. i did have azure working with last week.16:47
hazmatarosales, the azure provider does a very good job of cleaning up after itself16:47
hazmatarosales, at the cost of being synchronous, including its tool bucket.16:47
arosaleshazmat, it does but it takes some time.16:47
arosaleshazmat, there is a new api for delete that we should work in some time.16:48
hazmatarosales, its hard to avoid given the api.. to kill the vnet, it has to wait on instance kills, etc. although ideally its doing that in parallel with a wait for the group (for instance stop).16:48
arosaleshazmat, yup and I think msft tried to clean that code up.16:49
hazmatarosales, did i read that right? msft cleaned up juju code? will wonders never cease.16:53
natefinchrogpeppe, mgz, fwereade_, dimitern: just landed my  docs branch (well, set to approved, waiting for the bot).  Gotta run out for a doctor's appointment, but I'll be back later in the day.16:54
mgzI'm going to be around but only with one eye here for the evening16:57
sinzuirogpeppe, I see GhostRevisionHasNoRevno errir in gnuflag. I think you have the power to fix it: http://pastebin.ubuntu.com/6188999/17:23
rogpeppesinzui: interesting17:24
* rogpeppe doesn't know about ghost revisions17:24
sinzuiyeah, I haven't seen a ghost issue in years17:24
sinzuiI don't know the details, I think abentley, jam, and mgz do though17:25
rogpeppesinzui:17:26
rogpeppebzr fetch-ghosts17:26
rogpeppebzr: ERROR: unknown command "fetch-ghosts"17:26
abentleyrogpeppe: it's from bzrtools.17:26
* sinzui is updating the make tarball script to honour dependencies.tsv17:27
rogpeppeabentley: thanks17:28
rogpeppesinzui: how can i tell if i've fixed the issue?17:28
sinzuirogpeppe, this is how I found the issue17:30
sinzuibzr checkout --lightweight -r 12 lp:gnuflag gnuflag17:30
rogpeppesinzui: i just tried that actually - it still failed17:30
sinzui:/17:30
rogpeppesinzui: i'll try the second suggestion17:30
rogpeppesinzui, abentley: nope. nothing doing. i've tried all the combinations i can think of17:38
rogpeppesinzui: the bzr push always says "No new revisions or tags to push"17:38
rogpeppesinzui: which i presume means it's not making any changes17:39
sinzuihmm. this is tricky17:39
rogpeppesinzui: should fetch ghosts, then make a blank commit and try again?17:39
rogpeppes/should/should i/17:39
sinzuipush --overwrite says there is nothing to do?17:39
rogpeppesinzui: yes17:39
sinzuiI don't think fetch will help17:39
sinzuiI can change the release tarball script to not use lightwieght checkouts. I think that will unblock me17:40
rogpeppesinzui: if i knew what the issue was, i could probably do something about it17:40
sinzuiabentley, ^ do you think the project's repo is corrupt?17:40
rogpeppesinzui: i could erase most of the history of the branch, i suppose, by rewinding it and applying a patch, and push --overwriting.17:41
sinzuirogpeppe, me too.17:41
sinzuime looks at branch again17:41
rogpeppesinzui: i don't really want to lose the repo history though - it's quite useful sometimes17:42
sinzuirogpeppe, I agree.17:42
sinzuirogpeppe, I see from https://code.launchpad.net/~gnuflag/gnuflag/trunk that the branch we would normally use as the nase of the stack is actually stacked on the original branch17:43
sinzui^ abentley could this issue a manefestation of stacking and will `bzr reconfigure --unstacked` address the issue17:44
* sinzui pulls the branch and tries17:44
rogpeppesinzui: apologies for my ignorance. what's a stacked branch?17:44
sinzuirogpeppe, lp:~gophers/gnuflag/trunk17:45
rogpeppesinzui: that's the trunk branch, yes?17:45
rogpeppesinzui: what does it mean for it to be "stacked"?17:45
abentleysinzui: No, the problem is that bzr doesn't normally push ghost revisions.  That's why you need to use the fetch-ghosts command, not "pull" or "push".17:45
sinzuirogpeppe, stacking is a disappointing space optimisation used by Lp. the true trunk branch (yours) does not have all its revisions, so bzr will pull the remaining revs from ~gophers. Shared repos are better...but Lp doesn't know about them17:46
rogpeppesinzui: so the true trunk branch isn't lp:~gophers/gnuflag/trunk ?17:47
sinzuiactually it is...17:48
sinzuirogpeppe, the project thinks ~gnuflag/gnuflag/trunk is the current focus of development. It will stack all new branches on that, so that all new branches will be based on true trunk. But true trunk doesn't have all its revisions, most are in lp:~gophers/gnuflag/trunk. This probably happened when the branches were switched17:50
sinzuiThis is one of many disappointing "features" of stacking17:51
rogpeppesinzui: ah, i hadn't twigged to ~gnuflag vs ~gophers distinction17:51
rogpeppes/ to / the /17:51
rogpeppesinzui: well, if you work out a way of fixing it, let me know what to type and i'll type it :-)17:52
sinzuiokay.17:52
* rogpeppe has definitely reached eod18:00
rogpeppeg'night all18:00
abentleysinzui: If you manually stack ~gnuflag/gnuflag/trunk on ~gophers/gnuflag/trunk, that should fix it.  And if it does, I would expect it would stay fixed after reconfigure --unstacked.18:29
sinzuiabentley, I will try that18:30
abentleysinzui: Stacking uses the database ids of branches, so renaming branches should not break stacking.18:30
sinzuiI just realised that -r revno is broken in this case, but -r revid works18:32
abentleysinzui: I have scripted out basically the whole process of setting up for lxc.  Now setting it up on juju-gui-qa.  I love watching when scripts Just Work.19:10
sinzuime too abentley19:12
thumpermorning19:47
thumpermorning natefinch19:48
natefinchthumper: morning19:48
thumperI was just looking at the 1.15.1 milestone19:48
thumperand the only non-fix committed bug is the azure help19:48
thumperhow's that going?19:48
natefinchthumper: it's committed... the bot just seems to not want to land it19:48
thumper?!19:49
natefinchthumper: https://code.launchpad.net/~natefinch/juju-core/018-azure-help/+merge/18893619:49
natefinch*shrug*19:49
* thumper looks19:49
thumpernatefinch: you need to set the commit message :)19:49
natefinchsonofa19:49
thumperheh19:49
natefinchwhy can't it just take the description? :/19:49
thumperthere is a long and sorded history19:50
thumpermy answer to that is this:19:50
thumperthe description is what you write to help the reviewer, explaining the changes, what why and how19:50
thumperthe commit message is what the change is19:50
natefinchFair enough19:50
thumperthey have different audiences19:50
thumperhowever, most people in the team just copy the description19:51
thumperI often edit it19:51
natefinchdo I have to poke it in and out of approved, or will the bot notice the change to the commit message?19:51
natefinchThe commit message thing would bug me a lot less if the bot would just email me that I forgot the commit message, instead of silently failing to do anything19:52
thumperthe bot will notice19:56
* natefinch thinks that line sounds ominous19:59
natefinchI have the root-disk constraint working on  EC2, just need to get it to actually report back the correct disk size (currently it just hard codes the 8G default)20:01
thumperhmm..20:01
thumperthe bot failed20:01
thumperbut because it couldn't create a directory20:01
* thumper kicks it into approved again20:02
natefinchI can retry... though not being able to create a directory doesn't sound like something that's likely to work a second time either20:02
natefinchyeah, cool20:02
thumperit could be a random clash20:03
thumperif not, someone needs to log into the machine and clear out the /tmp dir20:03
thumperfrom all the gocheck temp dirs20:03
thumperI have a feeling that some are left behind if there are issues with teardown20:03
natefinchug20:03
* thumper nods20:03
thumperyeah20:03
thumperI have about 10 in my /tmp dir20:04
natefinchI gotta run my daughter to a doctor's appointment, but I'll be back on after for a bit.20:04
thumperack20:04
=== natefinch is now known as natefinch-afk
thumperfwereade_, mgz: anyone know where to landing bot instructions are?20:22
thumperneed to clean out the tmp dir20:22
thumperbot is failing20:22
=== _mup__ is now known as _mup_
thumperfwereade_: if you are around, I'd love to chat and rant21:39
natefinch-afkthumper: how goes?23:06
=== natefinch-afk is now known as natefinch
=== natefinch is now known as natefinch-bedtim
=== natefinch-bedtim is now known as natefinch-bed

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