[09:07] <sparkiegeek> hi, if I SetAnnotations with a Tag pointing at unit X and then juju destroy-unit X, it seems the annotation "survives". Is that expected?
[09:08] <sparkiegeek> my expectation was that the annotation would die along with the unit
[09:08] <sparkiegeek> but it seems immortal :)
[09:39] <dimitern> sparkiegeek, annotations are kept in a separate mongo collection, but it should be indeed removed when the unit is destroyed
[09:39] <dimitern> sparkiegeek, there's code for that, and if the unit's not in state anymore this is a bug worth reporting
[09:41] <sparkiegeek> dimitern: what do you mean by  "unit's not in state"?
[09:42] <dimitern> sparkiegeek, i mean can you access the unit somehow or it reports not found?
[09:42] <dimitern> (does it show up somewhere, perhaps with an error in status?)
[09:43] <sparkiegeek> dimitern: doesn't show anywhere. I'll file a bug?
[09:45] <dimitern> sparkiegeek, thanks!
[09:58] <sparkiegeek> dimitern: https://bugs.launchpad.net/juju-core/+bug/1276976 for reference
[09:58] <_mup_> Bug #1276976: Juju annotations are immortal <landscape> <juju-core:New> <https://launchpad.net/bugs/1276976>
[09:58] <dimitern> sparkiegeek, cheers :)
[10:05] <mgz> rogpeppe: (and anyone else around) weekly standup?
[10:05] <rogpeppe> mgz: thanks
[10:25] <mattyw> rogpeppe, would you have a moment now or later to discuss the api and juju destroy-environment?
[10:25] <rogpeppe> in a call right now, but in a little bit, sure
[10:25] <rogpeppe> mattyw: ^
[10:26] <mattyw> rogpeppe, ok cool
[10:26] <mattyw> rogpeppe, thanks
[10:43] <rogpeppe> mattyw: just finished
[10:43] <rogpeppe> mattyw: hangout?
[11:23] <rogpeppe> mgz, dimitern, natefinch: review of these fixes to juju restore would be appreciated: https://codereview.appspot.com/60580043
[11:23] <mgz> rogpeppe: sure
[11:23] <dimitern> rogpeppe, looking
[11:23] <rogpeppe> mgz, dimitern: thanks
[11:24] <rogpeppe> mgz, dimitern: i just verified it live, BTW
[11:27] <dimitern> rogpeppe, reviewed
[11:27] <dimitern> rogpeppe, can you look at this? https://codereview.appspot.com/59620043/
[11:27] <rogpeppe> dimitern: thanks, will do
[11:31] <rogpeppe> dimitern: i don't quite understand how TestInstanceInfo ever passed
[11:32] <rogpeppe> dimitern: was a branch pushed without running the tests, do you think?
[11:32] <dimitern> rogpeppe, there's some trickery with initially setting the dns name
[11:32] <dimitern> rogpeppe, that's likely yes
[11:33] <rogpeppe> dimitern: ah yes, looks like i am the culprit, oops
[11:34] <dimitern> rogpeppe, ;)
[11:34] <rogpeppe> dimitern: LGTM, and i'd suggest that you could submit it now, as it fixes trunk
[11:37] <dimitern> rogpeppe, I don't have rights to submit it
[11:37] <rogpeppe> dimitern: ok, i could probably do that
[11:38] <dimitern> rogpeppe, wait!
[11:38] <dimitern> rogpeppe, won't that screw up my whole pipeline?
[11:38] <rogpeppe> dimitern: how so?
[11:38] <dimitern> rogpeppe, well, this is the first CL, and the others depend on it
[11:38] <dimitern> rogpeppe, if you land it how can i land the rest?
[11:39] <dimitern> rogpeppe, hmm.. I suppose we can set it to Merged once you land it
[11:39] <rogpeppe> dimitern: are you using bzr pipelines?
[11:39] <dimitern> rogpeppe, and ohh.. there's no bot to check the order, so it should be fine
[11:39] <rogpeppe> dimitern: yeah, i don't think there should be a problem
[11:39] <dimitern> rogpeppe, yep, they are indispensable!
[11:40] <dimitern> rogpeppe, esp. with the case of goamz where the trunk rarely changes, so I can line up a whole bunch of related pipes and don't care about making it too long and having to merge trunk all the way
[11:41] <rogpeppe> dimitern: yeah
=== marcoceppi_ is now known as marcoceppi
[13:49] <adeuring> could somebody please have a look here: https://codereview.appspot.com/60630043
[14:05] <natefinch> adeuring: reviewed
[14:10] <adeuring> natefinch: thanks
[14:12] <natefinch> adeuring: np
[14:25] <dimitern> rogpeppe, https://codereview.appspot.com/60620043 - last CL so far, if you can take a look
[14:25] <dimitern> mgz, ^^
[14:26] <rogpeppe> dimitern: looking
[14:27] <dimitern> rogpeppe, mgz, also I'd appreciate one last look at the previous CLs, after I changed the live tests to be more resilient: https://codereview.appspot.com/49930045/  https://codereview.appspot.com/54690048/  https://codereview.appspot.com/54570048/
[14:27] <dimitern> rogpeppe, cheers!
[14:27] <mgz> dimitern: I'll go through the series again now
[14:27] <dimitern> mgz, thanks
[16:09] <dimitern> mgz, rogpeppe, final one, I promise :) - it's simpler than the rest https://codereview.appspot.com/54210047/
[16:13] <mgz> dimitern: :)
[16:43] <marcoceppi> can anyone answer questions about juju set-env and ssh keys?
[16:43] <dimitern> marcoceppi, there's an authorized keys plugin to manage ssh keys now
[16:43] <marcoceppi> dimitern: ohohoh! link?
[16:44] <dimitern> marcoceppi, sorry, it's not a plugin, it's a command: juju authorized-keys
[16:44] <marcoceppi> dimitern: amazing, thank you
[16:45] <dimitern> marcoceppi, http://paste.ubuntu.com/6886194/
[18:37] <rogpeppe> 		notify: make(chan struct{}, 1),
[18:38] <rogpeppe> 	}
[18:38] <rogpeppe> natefinch: any chance you could propose utils/voyeur as its own CL? i've got a test suite i quite want to use it in
[18:38] <natefinch> rogpeppe: sure
[18:38] <rogpeppe> natefinch: oh yes, you wanted another chat about stuff, didn't you
[18:39] <rogpeppe> natefinch: have you got a moment now?
[18:39] <natefinch> rogpeppe: yeah
[18:39] <rogpeppe> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[20:24] <hazmat> anybody know why we install bridge-utils?
[20:24] <hazmat> for every machine
[20:25] <natefinch> hazmat: I believe to support networking between lxc containers
[20:26] <hazmat> natefinch, seems like a bug then.. we should only be installing it when we're using lxc containers.. like we do for lxc itself
[20:26] <natefinch> hazmat: we install lxc only after you request deploying an lxc container to a machine?
[20:27] <hazmat> natefinch, yes.. else its just waste of time/space
[20:27] <natefinch> hazmat:  true.  Then, yes, probably it's a bug, unless there's some other use that we need it for.  Not really my area of expertise.  I know there was some work being done about supporting multiple networks, no idea if that might have something to do with it.
[20:29] <hazmat> hmm.. looks like the log for 2297 (committed yesterday) has it
[20:29] <hazmat> maas-specific hack
[20:30] <hazmat> seems like that should only be installed if provider == maas
[20:32] <natefinch> hazmat: ahh yeah, the commit message says why it's always installed when lxc isn't... but still should only be done if we're on maas.
[21:52] <rogpeppe> hazmat: yeah, that's my fault
[21:52] <rogpeppe> hazmat: but it isn't necessarily a maas-specific hack
[21:53] <rogpeppe> hatch: (except for the fact that networking between lxc containers only works under maas currently)
[21:53] <rogpeppe> hazmat: ^
[23:46] <ahasenack> guys, any idea what's up with this error on 1.16.5? I'm getting it frequently now, to the point I can't bootstrap
[23:46] <ahasenack> WARNING failed to write bootstrap-verify file: cannot make S3 control bucket: A conflicting conditional operation is currently in progress against this resource. Please try again.
[23:46] <ahasenack> I trashed all jenv files i could find, then changed my control bucket name, and still can't bootstrap
[23:46] <ahasenack> this is aws on us-west-2