[00:03] <thumper> wallyworld_: https://plus.google.com/hangouts/_/76cpj15en6ms7kb8jr9r3fvhco?hl=en
[01:28] <axw> eh wtf
[01:28] <axw> I had a dupe of the standup in my calendar and deleted one, now calendar says I'm not coming to the other one
[01:29] <davecheney> axw: https://codereview.appspot.com/61560045/
[01:29] <axw> davecheney: about to go to standup, will look a bit later
[01:30] <davecheney> ta
[02:03]  * axw wonders if he can justify going to gophercon as well
[02:05] <axw> thumper: https://codereview.appspot.com/49640050/
[02:09] <thumper> axw: canonical has 10 entrances due to sponsorship
[02:09] <thumper> axw: could always see if you could acquire one of those
[02:10] <axw> ooer
[02:10] <axw> who do I ask?
[02:17] <thumper> axw: um... not sure actually
[02:18] <thumper> axw: mramm to start I guess
[02:18] <axw> ok
[02:20] <thumper> ah bugger
[02:20] <thumper> package review
[02:20]  * thumper kicks it again
[02:20] <thumper> perhaps one day soon again
[02:21] <thumper> although I think it is important, especially with waigani needing to learn stuff
[02:21] <thumper> we should definitely get back into it
[02:21] <thumper> however today, I have to take a daughter to the physio
[03:56] <thumper> WTF?
[03:56] <thumper> bootstrapping local provider fails with trunk
[03:57] <thumper> and it didn't delete the .jenv
[03:58] <thumper> and destroy environment failed
[03:58] <thumper> as did with --force
[04:37] <axw> thumper: figure out what's breaking? I'm just testing a fix for azure, I can look after that
[04:56] <davecheney> axw: thanks for the review
[04:56] <axw> davecheney: nps
[05:03] <axw> wallyworld_: a real quick one please, fixes at least one of the critical azure bugs. https://codereview.appspot.com/51300044/
[05:04] <wallyworld_> sure
[05:04] <wallyworld_> axw: oh shit that looks like my fault
[05:04] <axw> yeah, it's easy to do.. the defaults stuff is pretty confusing IMO
[05:06] <wallyworld_> the whole config stuff is confusing
[05:16] <thumper> axw: yeah, it was my code in cloudinit causing it to break
[05:16] <thumper> but it should have been able to remove it, but it didn't
[05:16] <axw> mk
[05:39] <davecheney> axw: doesn't look like the bot is running
[05:40] <axw> hm yeah mine hasn't landed either. I don't have access
[05:40] <axw> thumper: can you please poke the bot?
[06:47] <axw> wallyworld_: hey, can you please poke the bot?
[06:47] <wallyworld_> sure
[06:47] <axw> once it's moved, I'll see if I can get poking privileges...
[06:49] <wallyworld_> yeah, will be different infrastructure
[08:58] <rogpeppe1> mornin' all
[08:58] <axw> dimitern: heya. just saw your comment. I don't understand how the preferences file gets picked up by apt-get? runcmds run after apt-get installs packages?
[08:58] <axw> morning rogpeppe1
[08:58] <rogpeppe1> axw: hiya
[08:58] <dimitern> morning all
[08:59] <dimitern> axw, in sshinit I made it so that it gets called immediately after add-apt-repo
[08:59] <axw> dimitern: yep that bit works, but sshinit is only used for bootstrap
[08:59] <axw> (and add-machine ssh)
[09:00] <dimitern> axw, so both add-machine and bootstrap manual will work, don't you agree?
[09:01] <axw> dimitern: I don't, because they're doing things at different times. For add-machine, cloud-init runs apt-get update, apt-get upgrade, apt-get install XXX, then finally it'll write the preferences file
[09:01] <axw> so I can't see how the pinning takes effect for non-bootstrap machines
[09:02] <dimitern> axw, can you point me to the code you're referring to that executes runcmd after any packages were installed?
[09:03] <axw> dimitern: it's in cloud-init itself. I'll have a rummage in my downloads..
[09:04] <dimitern> axw, so, looking at cloudinit/sshinit/configure.go - we have addPackageCommands very early, before the runcmds are executed
[09:05] <axw> dimitern: yes, this is meant to mimic cloud-init
[09:05] <dimitern> axw, and in case we have an apt source with prefs, we do add-apt-repository, and then immediately it installs the prefs file
[09:05] <dimitern> axw, (in addPackageCommands)
[09:05] <axw> yes I get that - just ignore sshinit
[09:06] <axw> it is not used for add-machine
[09:06] <axw> bootstrap is fine
[09:06] <dimitern> axw, ok, so going back to environs/cloudinit/ then?
[09:06] <axw> yes
[09:07] <axw> and what happens when you provision a non-bootstrap machine
[09:07] <dimitern> axw, in ConfigureJuju we have several AddPackage commands before getting to MaybeAddCloudArchiveCloudTools
[09:07] <dimitern> axw, but that's fine, because none of these packages are affected by the bug - they're in main, not in cloud-tools
[09:07] <dimitern> axw, the only problematic package is mongodb-server
[09:08] <axw> dimitern: ok. if we don't care if we get other things from cloud-tools that's fine
[09:09] <dimitern> axw, yep, sorry if i wasn't clear
[09:09] <axw> no worries
[09:09] <dimitern> axw, only mongodb-server and only on precise needs to be installed from cloud-tools pocket
[09:09] <axw> dimitern: if you don't mind I will move it up into environs/cloudinit though, as a bootcmd
[09:09] <axw> when I have nothing better to do :)
[09:10] <dimitern> axw, i don't mind at all, but please live test it ;)
[09:10] <axw> yes definitely
[09:10] <dimitern> axw, now there's a slight imperfection (two actually) - the prefs file is created twice
[09:10] <axw> how's that?
[09:11] <dimitern> axw, due to the addfile call - both after adding the repo and when all the rest runcmds are run, but the contents are the same
[09:11] <axw> ah right
[09:11] <dimitern> axw, and the second issue is the duplication of logic in sshinit, but adding a boot cmd should fix both
[09:12] <dimitern> mgz, hey
[09:13] <axw> rogpeppe: did you get anywhere with reporting bootstrap errors back to the user?
[09:13] <axw> or if you've shelved it, is there something I can pick up?
[09:13] <rogpeppe> axw: no, i didn't
[09:14] <dimitern> axw, i had some issues trying out manual bootstrapping on an existing saucy VM
[09:14] <rogpeppe> axw: i had an idea as to how i might do it, but the sprint got in the way and then i haven't got back to it, i'm afraid
[09:14] <axw> rogpeppe: nps
[09:14] <axw> thanks
[09:14] <axw> dimitern: what's issues?
[09:14] <axw> what*
[09:14] <dimitern> axw, it seems it tries to use ubuntu@ even if I set bootstrap-user to something else; and doesn't get very far
[09:15] <axw> dimitern: it will first try to use ubuntu@ tosee if it has already set up the ubuntu user. it *should* then use bootstrap-user to initialise the ubuntu user
[09:15]  * axw checks that this works on his machine still
[09:15] <dimitern> axw, I had to actually create an ubuntu user and authorize my ssh key so i can login passwordless, but it still insisted on asking for password in sudo
[09:17] <dimitern> axw, although, it might be all moot, because some time down the road i realized i was using sudo juju bootstrap, and that was getting /usr/bin/juju, i.e. 1.16.5 from the ppa
[09:17] <axw> hrm, seems it's broken
[09:17] <axw> you shouldn't be using sudo for manual
[09:17] <dimitern> but once i started using trunk it went fine, except for one small thing
[09:17] <dimitern> yeah, i know - i was just lazy and relying on bash history :)
[09:18] <axw> ok
[09:18] <dimitern> the small thing is I get "storage-auth-key" expected string, got "" after I did destroy-environment, and then status
[09:19] <axw> hrm
[09:19] <dimitern> let me try again
[09:19] <axw> sounds like prepare failed
[09:19] <axw> dimitern: it is broken on trunk tho
[09:19] <dimitern> axw, what is?
[09:19] <axw> dimitern: I started getting rid of BootstrapStorager, and broke it in the process. will see if I can fix it now
[09:20] <dimitern> axw, ah, ok
[09:20] <axw> initialising the ubuntu user
[09:21] <axw> dimitern: in the mean time, if you enable passwordless sudo for unbuntu, you should be good to go
[09:21] <dimitern> axw, yep, that's how I finally made it
[09:22] <dimitern> axw, is it normal to get "manual:" instance names in a manual env? when I used add-machine the instance name was "manual:<IP>"
[09:23] <axw> dimitern: just for the bootstrap node
[09:24] <dimitern> axw, but since you can't start more instances..
[09:24] <dimitern> axw, i successfully deployed stuff on 0, but deploying without --to gets me phantom machines and some errors later on in status
[09:25] <axw> dimitern: yeah, I've got a branch up for review that disallows add-machine (except ssh:...)
[09:25] <axw> the "Wire up prechecker" one
[09:25] <axw> it's back from the dead
[09:26] <dimitern> axw, perhaps any commands that could result in an environs.StartInstance call should be disallowed
[09:26] <axw> dimitern: yes, that's what will happen
[09:26] <dimitern> axw, sweet!
[09:27] <axw> dimitern: also, you won't be allowed to create contains on providers that don't support it
[09:27] <axw> containers*
[09:28] <dimitern> axw, ah! that reminds me - i've encountered an issue while live testing in ec2 yesterday - the lxc provisioner kept dying because lxc is not supported
[09:29]  * dimitern should make a habit of saving odd errors and stuff like that for easier reporting later
[09:29] <axw> had you tried adding a container?
[09:30] <dimitern> nope
[09:30] <dimitern> it's no use - nothing can access it yet
[09:30] <axw> yeah, just wondering why it would be doing that
[09:31] <dimitern> i did in previous tests, they deploy ok, but can't relate to each other
[09:33] <dimitern> mgz, so i can see bug 1241674 you fixed is released in 1.17.1, and bug 1188126 is still in progress?
[09:33] <_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1241674>
[09:33] <_mup_> Bug #1188126: Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured <canonistack> <cts-cloud-review> <openstack-provider> <serverstack> <pyjuju:Triaged> <juju-core:Triaged by gz> <https://launchpad.net/bugs/1188126>
[09:50] <dimitern> adeuring, hey, are you working on bug 1276462 ?
[09:50] <_mup_> Bug #1276462: add a JUJU_TESTING environment variable for stats=0 on charm store interactions <juju-core:In Progress by adeuring> <https://launchpad.net/bugs/1276462>
[09:50] <adeuring> dimitern: yes
[09:51] <dimitern> adeuring, but there's no MP yet?
[09:52] <adeuring> dimitern: not yet ready -- i'm still learning the code base, so I#m not that fast
[09:52] <dimitern> adeuring, ok, just checking, thanks
[10:47] <dimitern> mgz, standup?
[11:56] <dimitern> niemeyer, thanks for replying - i understand you've been busy lately, didn't mean to bug you unnecessarily :)
[12:00] <niemeyer> dimitern: Heya
[12:01] <dimitern> niemeyer, welcome back!
[12:02] <niemeyer> dimitern: Thanks.. sorry for taking longer than I wish
[12:02] <dimitern> niemeyer, no problem
[14:11] <sinzui> jamespage, maybe I was confused about packaging for the 1.16.6 release. Since trusty is leaping to 1.17.x, should I release 1.16.6 though the stable ppa only?
[14:11] <jamespage> sinzui, yes
[14:11] <jamespage> sounds good to me
[14:14] <sinzui> thank you jamespage
[14:14] <jamespage> sinzui, I started work on the .5 SRU for saucy last week - I'll hold off until .6 is done as well
[14:15] <sinzui> understood
[14:28] <niemeyer> dimitern: ping
[14:28] <dimitern> niemeyer, hey
[14:28] <niemeyer> dimitern: Heya
[14:29] <niemeyer> dimitern: We have a small inconsistency being introduced which would be nice to brainstorm on
[14:29] <niemeyer> dimitern: Nowdays we have ec2.RunInstances
[14:29] <niemeyer> Nowadays
[14:30] <niemeyer> dimitern: This type is used as an options structure when calling EC2.RunInstances
[14:30] <dimitern> niemeyer, yes?
[14:30] <niemeyer> dimitern: The network support is now adding NetworkInterfaceOptions, and NetworkInterfaceSpec
[14:30] <niemeyer> dimitern: Which is not quite great
[14:31] <dimitern> niemeyer, yeah, it was bugging me a bit
[14:31] <niemeyer> dimitern: They're both very specific to a given context
[14:31] <niemeyer> dimitern: although their names say nothing about that context
[14:31] <dimitern> niemeyer, they are
[14:31] <niemeyer> dimitern: What will we have next? NetworkInterfaceStuff? :)
[14:31] <dimitern> niemeyer, i'm open to suggestions on naming :)
[14:32] <niemeyer> dimitern: Following the lead of RunInstances, NetworkInterfaceOptions should probably be called CreateNetworkInterface
[14:32] <dimitern> niemeyer, ok and NetworkInterfaceSpec - NetworkInterfaceOptions?
[14:34] <niemeyer> dimitern: What's the difference between the two?
[14:34] <niemeyer> dimitern: In terms of data
[14:34] <dimitern> niemeyer, just a sec
[14:35] <dimitern> niemeyer, so the *Spec is used only in RunInstances, because it can specify either a new or an existing NIC (Id empty or not)
[14:35] <niemeyer> dimitern: In terms of data
[14:36] <niemeyer> dimitern: It looks like they are exactly the same, except for two fields.. and one of these fields runs every other field irrelevant
[14:36] <dimitern> niemeyer, in RunInstances you can specify more things (and different ones) than in CreateNIC
[14:37] <dimitern> niemeyer, DeviceIndex and DeleteOnTermination do not apply for CreateNIC
[14:38] <dimitern> niemeyer, and security groups are specified only by id, not name or id
[14:38] <niemeyer> dimitern: Right.. what is device index about?
[14:38] <dimitern> niemeyer, where to "mount" the NIC
[14:38] <dimitern> niemeyer, eth0, 1, ..
[14:41] <niemeyer> dimitern: I'm tempted to suggest RunNetworkInterface
[14:41] <dimitern> niemeyer, sgtm
[14:41] <niemeyer> dimitern: It's not great, but I cannot come up with anything nice that would fit in a tweet :)
[14:42] <dimitern> niemeyer, indeed :)
[14:42] <dimitern> niemeyer, so i'll s/NetworkInterfaceOptions/CreateNetworkInterface/ and in the next branch s/NetworkInterfaceSpec/RunNetworkInterface/
[14:43] <niemeyer> dimitern: Thanks
[14:50] <dimitern> mgz, ping
[14:53] <dimitern> niemeyer, I've just noticed in https://codereview.appspot.com/54570048/ there are similar *Status constants - do you want them removed like in the vpc prereq?
[14:54] <dimitern> niemeyer, I can do it in the RunInstances CL, because I've just submitted the NICs one
[15:01] <axw__> sinzui: not sure if this classifies as critical or not, but manual provider is buggered on trunk -- https://bugs.launchpad.net/juju-core/+bug/1279259
[15:01] <_mup_> Bug #1279259: manual: bootstrap fails if ubuntu user is not initialised <manual-provider> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1279259>
[15:02] <axw__> I'm working on it now, but haven't marked it against 1.17.3 in case you want to release without the fix
[15:10] <dimitern> natefinch, are you around for a review of https://codereview.appspot.com/60620043/ ?
[15:14] <sinzui> axw__, I think it is critical. I think we are two weeks away from having a manual provisioning env that is tested with every revision merged
[15:16] <axw__> sinzui: ok, will try to get it fixed tomorrow. thanks
[15:17] <dimitern> niemeyer, ..or you think it's ok to leave them as they are?
[15:19] <natefinch> dimitern: yeah
[15:19] <dimitern> natefinch, ta!
[15:23] <mattyw> rogpeppe, afternoon - do you have a moment?
[15:23] <rogpeppe> mattyw: hiya
[15:23] <rogpeppe> mattyw: yeah, i do
[16:06] <niemeyer> dimitern: Hmm
[16:07] <dimitern> natefinch, review poke
[16:09] <niemeyer> dimitern: INdeed, it's the same issue
[16:09] <niemeyer> dimitern: and we can already see the mentioned issue surfacing
[16:09] <dimitern> niemeyer, ok then, I'll remove the constants before I submit the next CL
[16:09] <niemeyer> dimitern: ec2.AvailableState, and ec2.AvailableStatus
[16:10] <dimitern> niemeyer, AvailableState is gone now
[16:10] <niemeyer> dimitern: Right, I mean that the motivation I provided to not do that is real
[16:11] <niemeyer> dimitern: Either we put context in their name, or we drop them.. I suggest dropping until we have a better idea of how/when to use them
[16:11] <dimitern> niemeyer, noted, will drop them
[16:13] <dimitern> niemeyer, and apart from that only one CL left - yay! :)
[16:15] <rogpeppe> dimitern: can you tell me something about the intended use of juju.apiState.cachedInfo ?
[16:16] <dimitern> rogpeppe, that's where the api info creds are cached for the CLI
[16:17] <rogpeppe> dimitern: ah, i see where it's initialised now
[16:17] <rogpeppe> dimitern: it seems a weird place to stash that
[16:17] <rogpeppe> dimitern: apiState is supposed to be an ultra-thin wrapper around state
[16:17] <rogpeppe> dimitern: not a place to store arbitrary runtime context
[16:18] <dimitern> rogpeppe, if that was the intent, it wasn't well documented :)
[16:19] <rogpeppe> dimitern: sorry, i thought this comment was reasonably clear.
[16:19] <rogpeppe> // apiState wraps an api.State, redefining its Close method
[16:19] <rogpeppe> // so we can abuse it for testing purposes.
[16:19] <dimitern> rogpeppe, also, you're the reviewer on this change btw ;) r2209
[16:19] <rogpeppe> dimitern: i'm sure we need something like this - i was just a bit surprised :-)
[16:20] <rogpeppe> dimitern: memory shmemory :-)
[16:22] <dimitern> rogpeppe, hehe
[16:22] <natefinch> dimitern: sorry, got sidetracked by the kids for a bit.  Review is pretty much done
[16:32] <dimitern> natefinch, thanks!
[17:19] <dimitern> niemeyer, thanks for all the reviews!
[17:19] <niemeyer> dimitern: np, thanks for pushing these change
[17:19] <niemeyer> s
[17:20] <dimitern> niemeyer, there might be more to come, but these should suffice for now
[17:39] <dimitern> g'night all!
[18:39] <rogpeppe> natefinch: largest CL ever? https://codereview.appspot.com/62230043 :-)
[19:02] <hatch> do people use the GUI with maas?
[19:06] <marcoceppi> hatch: I do/have
[19:06] <hatch> marcoceppi thanks :)
[19:11] <natefinch> rogpeppe: lol, nice
[20:33] <marcoceppi> natefinch: is juju ipv6 safe?
[20:34] <natefinch> marcoceppi: I believe so, but I don't know that I've actually tried it.  I know there's code for IPv6 in there, though.,
[20:38] <rogpeppe1> marcoceppi: i think it's somewhat unlikely
[20:38] <rogpeppe1> marcoceppi: for example, i think we often assume we can make a valid host/port combo by simply appending ":port"
[20:39] <marcoceppi> rogpeppe1: you mean within charms, or within the juju core?
[20:39] <rogpeppe1> marcoceppi: the latter
[20:40] <rogpeppe1> marcoceppi: it *might* be ok, but it hasn't been verified
[20:40] <marcoceppi> ah, yeah, it'd need to be encapsulated within []
[20:41] <rogpeppe1> marcoceppi: yup
[20:41] <natefinch> marcoceppi: I certainly wouldn't count on it without some heavy testing.
[20:42] <marcoceppi> thanks
[20:58] <thumper> o/ marcoceppi
[20:58] <marcoceppi> thumper: \o/
[20:58] <thumper> marcoceppi: if juju isn't ipv6 safe we damn well ought to make it so
[20:58] <thumper> I'd like charms to be able to ask for an ipv6 address
[21:00] <thumper> hey marcoceppi, are you wanting my incredibly hacked up github webhook charm?
[21:04] <thumper> natefinch: are you currently working on any of the 1.17.3 or 1.18.0 bugs?
[21:06] <natefinch> thumper: I just started looking into the mongo location bug, but haven't gotten far with it
[21:06] <thumper> ok
[21:08] <rick_h_> thumper: hey, got a sec? I hear you're the guy to talk to about getting multiple local envs working in lxc land?
[21:09] <thumper> rick_h_: yes
[21:09] <rick_h_> thumper: I hear there's 3ish tricks to make it work?
[21:09] <thumper> rick_h_: it works
[21:09] <rick_h_> thumper: in trunk? in 1.17.3 I get an error on the mongo port not being available
[21:09] <rick_h_> errr 1.17.2
[21:09] <thumper> rick_h_: you just need to make sure that you have different ports for mongo, api, storage
[21:09] <rick_h_> ok, yea I've got different ports for the api/storage but didn't know what key to use for mongod
[21:10] <rick_h_> I didn't see any docs around it for the env.yaml
[21:10] <thumper> rick_h_: here is my config for a local that will run with a default local. http://pastebin.ubuntu.com/6922215/
[21:11] <rick_h_> thumper: thanks, looking
[21:11] <rick_h_> ah, state-port I don't have
[21:12] <rick_h_> thanks thumper, I'll try that out.
[21:38] <natefinch> I think I could save myself a lot of frustration if I just did  ln -s /usr /user
[21:42] <natefinch> I love it when comments just outright lie.
[21:42] <natefinch> / This is a variable only to support unit testing.
[21:42] <natefinch> var mongodPath = "/usr/bin/mongod"
[21:42] <natefinch> (is then used in production code)
[21:43] <marcoceppi> thumper: yes please, I heard I should know more about it
[21:43] <thumper> marcoceppi: ok, will send, but you have to realize it is demo-ware :-)
[21:43] <marcoceppi> that's fine!
[21:45] <natefinch> thumper: where does the new mongod live in trusty?
[21:45] <sinzui> natefinch, It was true when the test was written :) Well I assume test-driven development...otherwise it is a malicious lie
[21:45] <thumper> natefinch: *shrug*
[21:46] <thumper> natefinch: do you mean the juju-db package one?
[21:46] <natefinch> thumper: yeah
[21:46] <thumper> natefinch: that is somewhere special
[21:46] <thumper> probably need to look in the package itself
[21:46] <thumper> I do know that it isn't in th path
[21:46] <natefinch> sinzui: heh, yeah.  I assume someone put it there for a test,and then someone else came along, needed a path for mongo, and said "hey, there's one already defined" and used it.
[21:46] <sinzui> natefinch, I had the path, and getting it again
[21:47]  * sinzui keeps switching between version of juju and deps
[21:48] <sinzui> natefinch, /usr/lib/juju/bin/mongod
[21:49] <natefinch> sinzui: thanks
[21:50] <sinzui> natefinch, this is all that juju-mongodb added to /usr/lib/juju
[21:50] <sinzui> http://pastebin.ubuntu.com/6922408/
[21:53] <davecheney> can the bot owner please update distinfo on that bot host
[21:53] <davecheney> I can't land my change because the os runnong on that machine doesn't know about trusty
[22:21] <davecheney> thumper: pong
[22:21] <thumper> davecheney: did I ping you?
[22:21] <davecheney> thumper: do you have access to the bot ?
[22:22] <thumper> davecheney: yeah...
[22:22] <thumper> what do you need?
[22:22] <davecheney> can you do a `apt-get update && apt-get install distro-info`
[22:22] <davecheney> so that the bot knows about trusty
[22:22]  * thumper goes to try
[22:22] <davecheney> thank you
[22:23] <thumper> davecheney: it says it is already at the latest revision
[22:25] <thumper> davecheney: however that doesn't list trusty
[22:26] <thumper> davecheney: how do we update the source for it?
[22:26] <davecheney> oh dear
[22:27] <davecheney> thumper: shoulnd't need to
[22:27] <davecheney> we publish distro-info's for all supported releases
[22:27] <davecheney> is the bot running quantal ?
[22:27] <thumper> --devel still doesn't list it
[22:27] <thumper> bot is running precise
[22:27] <thumper> lists up to saucy
[22:27] <thumper> so...
[22:27] <thumper> something there is all fubared
[22:27] <davecheney> try --all
[22:28] <thumper> did
[22:28] <thumper> no trusty
[22:28] <davecheney> maybe juju shouldn't depend on this pacakge
[22:28] <thumper> heh
[22:28] <davecheney> this isn't the first time it's let us down
[22:28] <thumper> blame someone, anyone else
[22:29] <thumper> can't be our fault
[22:29] <davecheney> we had the same bullshit in August when Saucy came out
[22:29] <wallyworld> sinzui: hey. is bug # 1247175 really a block for 1.18? can't we just use the release notes to tell people to update any scripts rather than having to develop/test code which will be removed next release?
[22:29] <_mup_> Bug #1247175: juju sync-tools does not support --destination <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1247175>
[22:29] <thumper> who updates this?
[22:29] <thumper> wallyworld: hey
[22:29] <wallyworld> o/
[22:29] <thumper> wallyworld: I have a proposal that adds an upgrade script
[22:29] <thumper> wallyworld: needs agent.Config in the upgrade context
[22:29] <wallyworld> ok
[22:29] <wallyworld> will add it
[22:29] <thumper> my branch adds it
[22:29] <thumper> :-)
[22:29] <thumper> take a look
[22:29] <wallyworld> rightio
[22:30] <sinzui> wallyworld, How do we get people to read the release notes and update their scripts when apt-put it there
[22:30] <davecheney> sinzui: put clues in the release notes
[22:30] <davecheney> to install the package users must answer 5 questions drawn from the release notes
[22:31] <davecheney> it's like copy protection in the 80's
[22:31] <sinzui> wallyworld, I think the win users are the only one who know there are release notes because they are downloading the client from the milestone page
[22:31] <wallyworld> sinzui: ok, i'll add the code to support --destination with a deprecation warning
[22:33] <wallyworld> thumper: i'm seriously considering having each major.minor version have its own sub package under juju-core/upgrades
[22:33] <wallyworld> otherwise that top level package will bloat
[22:33] <thumper> wallyworld: I have no strong feelings either way
[22:33] <thumper> +1 to avoiding bloat
[22:34] <thumper> subpackage sounds fine
[22:34] <thumper> wallyworld: this one is important because I fucked up: https://code.launchpad.net/~thumper/juju-core/fix-provider-query-in-machine-env-worker/+merge/205864
[22:34] <wallyworld> ok, will look at that one too
[22:34] <thumper> wallyworld: and this one is the one with the upgrade https://code.launchpad.net/~thumper/juju-core/juju-run-on-machine-with-no-units/+merge/206050
[22:34] <wallyworld> yeah already found that one
[22:35]  * thumper goes to file a bug for the fuckup
[22:37] <sinzui> davecheney, we could have a dot-file for each juju version in the user HOME. when juju runs and doesn't find the dot-file, it shows the user the release notes and will not do anything unit the user agrees to save the file.
[22:38] <davecheney> sinzui: like the thing that sudo does
[22:39] <sinzui> \o/ home brew accepted juju 1.16.6. I can close the release log
[22:40] <thumper> \o/
[22:42] <wallyworld> thumper: i was imagining description would be short, able to be used in logging. look like i need to add a Name field
[22:42] <thumper> wallyworld: yeah, ok
[22:43] <thumper> wallyworld: I was wanting it to be nice and long and descriptive :-)
[22:43] <wallyworld> not sure who would see it
[22:43] <thumper> maybe it doesn't need to be there
[22:43] <wallyworld> i'dd do it as a code comment
[22:43] <thumper> and instead becomes a "docstring" on the function
[22:43] <wallyworld> and keep the desc short
[22:43] <thumper> I'm happy either way
[22:43] <thumper> wan't sure what was needed
[22:44] <thumper> since we are in a brave new world
[22:44] <wallyworld> it's really for devs what you have done i think
[22:44] <wallyworld> yeah
[22:44] <thumper> I'm happy to change it
[22:44] <wallyworld> so +1 to doc string :-)
[22:44] <wallyworld> thanks :-)
[22:44] <wallyworld> i'll update the Description attr doc string also
[22:44] <thumper> kk
[22:44] <wallyworld> so people know to keep it short
[22:44] <thumper> yep
[22:49] <wallyworld> thumper: i has upgradeOperation as a base struct for UpgradeStep implementations. if you want to introduce upgradeStep instead, which I think is fine, can you remove upgradeOperations?
[22:49] <wallyworld> s/s//
[22:51] <thumper> I assumed that you would have one soon, but I needed something for the branch
[22:51] <thumper> happy to wait until you've landed something and update it
[22:51] <thumper> or merge in as a dependency
[22:51] <wallyworld> if yours is ready first, you can land it and i'll deal with it
[22:51] <thumper> kk
[22:52] <wallyworld> thumper: we are missing a test for the actual business logic
[22:52] <wallyworld> that does the upgrade
[22:52] <wallyworld> especially a test to ensure it is idempotent
[22:52] <thumper> yeah...
[22:52] <wallyworld> i think all upgrade steps should have explicit idempotent tests
[22:52] <thumper> was wonderinga bout that
[22:52] <thumper> I have problems though
[22:52] <thumper> as I don't have an ubuntu user
[22:52] <wallyworld> and we should reject when reviewing if they don't
[22:53] <wallyworld> mock
[22:53] <thumper> so how do we write a test for that
[22:53] <thumper> hmm...
[22:53] <wallyworld> don't hard code /home/ubuntu
[22:53] <wallyworld> use the juju helper func
[22:53] <wallyworld> to convert ~/ubuntu
[22:53] <wallyworld> that way you can test with a fake /home/ubuntu
[22:54] <thumper> hmm... o...k...
[22:54] <thumper> will try to write something
[22:54] <wallyworld> do you know the function i mean?
[22:54] <thumper> no
[22:54] <thumper> but I can grep :)
[22:54] <wallyworld> it's in utils, let me check
[22:56] <wallyworld> i think it's UserHomeDir
[22:57] <wallyworld> but your test needs to have set up a fake home
[22:57] <wallyworld> can't quite recall exactly without digging a bit
[22:57] <thumper> kk
[22:58] <wallyworld> MakeEmptyFakeHomeWithoutJuju