thumper | wallyworld_: https://plus.google.com/hangouts/_/76cpj15en6ms7kb8jr9r3fvhco?hl=en | 00:03 |
---|---|---|
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:28 |
davecheney | axw: https://codereview.appspot.com/61560045/ | 01:29 |
axw | davecheney: about to go to standup, will look a bit later | 01:29 |
davecheney | ta | 01:30 |
* axw wonders if he can justify going to gophercon as well | 02:03 | |
axw | thumper: https://codereview.appspot.com/49640050/ | 02:05 |
thumper | axw: canonical has 10 entrances due to sponsorship | 02:09 |
thumper | axw: could always see if you could acquire one of those | 02:09 |
axw | ooer | 02:10 |
axw | who do I ask? | 02:10 |
thumper | axw: um... not sure actually | 02:17 |
thumper | axw: mramm to start I guess | 02:18 |
axw | ok | 02:18 |
thumper | ah bugger | 02:20 |
thumper | package review | 02:20 |
* thumper kicks it again | 02:20 | |
thumper | perhaps one day soon again | 02:20 |
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 | 02:21 |
=== thumper is now known as thumper-afk | ||
=== thumper-afk is now known as thumper | ||
thumper | WTF? | 03:56 |
thumper | bootstrapping local provider fails with trunk | 03:56 |
thumper | and it didn't delete the .jenv | 03:57 |
thumper | and destroy environment failed | 03:58 |
=== mwhudson is now known as zz_mwhudson | ||
thumper | as did with --force | 03:58 |
axw | thumper: figure out what's breaking? I'm just testing a fix for azure, I can look after that | 04:37 |
davecheney | axw: thanks for the review | 04:56 |
axw | davecheney: nps | 04:56 |
axw | wallyworld_: a real quick one please, fixes at least one of the critical azure bugs. https://codereview.appspot.com/51300044/ | 05:03 |
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:04 |
wallyworld_ | the whole config stuff is confusing | 05:06 |
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:16 |
davecheney | axw: doesn't look like the bot is running | 05:39 |
axw | hm yeah mine hasn't landed either. I don't have access | 05:40 |
axw | thumper: can you please poke the bot? | 05:40 |
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:47 |
wallyworld_ | yeah, will be different infrastructure | 06:49 |
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 |
=== rogpeppe1 is now known as rogpeppe | ||
dimitern | morning all | 08:58 |
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) | 08:59 |
dimitern | axw, so both add-machine and bootstrap manual will work, don't you agree? | 09:00 |
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:01 |
dimitern | axw, can you point me to the code you're referring to that executes runcmd after any packages were installed? | 09:02 |
axw | dimitern: it's in cloud-init itself. I'll have a rummage in my downloads.. | 09:03 |
dimitern | axw, so, looking at cloudinit/sshinit/configure.go - we have addPackageCommands very early, before the runcmds are executed | 09:04 |
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:05 |
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:06 |
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:07 |
axw | dimitern: ok. if we don't care if we get other things from cloud-tools that's fine | 09:08 |
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:09 |
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:10 |
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:11 |
dimitern | mgz, hey | 09:12 |
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:13 |
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:14 |
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:15 |
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:17 |
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:18 |
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:19 |
dimitern | axw, ah, ok | 09:20 |
axw | initialising the ubuntu user | 09:20 |
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:21 |
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:22 |
axw | dimitern: just for the bootstrap node | 09:23 |
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:24 |
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:25 |
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:26 |
axw | dimitern: also, you won't be allowed to create contains on providers that don't support it | 09:27 |
axw | containers* | 09:27 |
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:28 |
* 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:29 |
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:30 |
dimitern | i did in previous tests, they deploy ok, but can't relate to each other | 09:31 |
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:33 |
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:50 |
dimitern | adeuring, but there's no MP yet? | 09:51 |
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 | 09:52 |
dimitern | mgz, standup? | 10:47 |
dimitern | niemeyer, thanks for replying - i understand you've been busy lately, didn't mean to bug you unnecessarily :) | 11:56 |
niemeyer | dimitern: Heya | 12:00 |
dimitern | niemeyer, welcome back! | 12:01 |
niemeyer | dimitern: Thanks.. sorry for taking longer than I wish | 12:02 |
dimitern | niemeyer, no problem | 12:02 |
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:11 |
sinzui | thank you jamespage | 14:14 |
=== frankban_ is now known as frankban | ||
jamespage | sinzui, I started work on the .5 SRU for saucy last week - I'll hold off until .6 is done as well | 14:14 |
sinzui | understood | 14:15 |
niemeyer | dimitern: ping | 14:28 |
dimitern | niemeyer, hey | 14:28 |
niemeyer | dimitern: Heya | 14:28 |
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:29 |
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:30 |
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:31 |
niemeyer | dimitern: Following the lead of RunInstances, NetworkInterfaceOptions should probably be called CreateNetworkInterface | 14:32 |
dimitern | niemeyer, ok and NetworkInterfaceSpec - NetworkInterfaceOptions? | 14:32 |
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:34 |
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:35 |
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:36 |
dimitern | niemeyer, DeviceIndex and DeleteOnTermination do not apply for CreateNIC | 14:37 |
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:38 |
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:41 |
dimitern | niemeyer, indeed :) | 14:42 |
dimitern | niemeyer, so i'll s/NetworkInterfaceOptions/CreateNetworkInterface/ and in the next branch s/NetworkInterfaceSpec/RunNetworkInterface/ | 14:42 |
niemeyer | dimitern: Thanks | 14:43 |
dimitern | mgz, ping | 14:50 |
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:53 |
dimitern | niemeyer, I can do it in the RunInstances CL, because I've just submitted the NICs one | 14:54 |
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:01 |
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:02 |
dimitern | natefinch, are you around for a review of https://codereview.appspot.com/60620043/ ? | 15:10 |
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:14 |
axw__ | sinzui: ok, will try to get it fixed tomorrow. thanks | 15:16 |
dimitern | niemeyer, ..or you think it's ok to leave them as they are? | 15:17 |
natefinch | dimitern: yeah | 15:19 |
dimitern | natefinch, ta! | 15:19 |
mattyw | rogpeppe, afternoon - do you have a moment? | 15:23 |
rogpeppe | mattyw: hiya | 15:23 |
rogpeppe | mattyw: yeah, i do | 15:23 |
=== luca__ is now known as luca | ||
=== hatch___ is now known as hatch | ||
niemeyer | dimitern: Hmm | 16:06 |
dimitern | natefinch, review poke | 16:07 |
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:09 |
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:10 |
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:11 |
dimitern | niemeyer, and apart from that only one CL left - yay! :) | 16:13 |
rogpeppe | dimitern: can you tell me something about the intended use of juju.apiState.cachedInfo ? | 16:15 |
dimitern | rogpeppe, that's where the api info creds are cached for the CLI | 16:16 |
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:17 |
dimitern | rogpeppe, if that was the intent, it wasn't well documented :) | 16:18 |
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:19 |
rogpeppe | dimitern: memory shmemory :-) | 16:20 |
dimitern | rogpeppe, hehe | 16:22 |
natefinch | dimitern: sorry, got sidetracked by the kids for a bit. Review is pretty much done | 16:22 |
dimitern | natefinch, thanks! | 16:32 |
dimitern | niemeyer, thanks for all the reviews! | 17:19 |
niemeyer | dimitern: np, thanks for pushing these change | 17:19 |
niemeyer | s | 17:19 |
dimitern | niemeyer, there might be more to come, but these should suffice for now | 17:20 |
dimitern | g'night all! | 17:39 |
rogpeppe | natefinch: largest CL ever? https://codereview.appspot.com/62230043 :-) | 18:39 |
hatch | do people use the GUI with maas? | 19:02 |
marcoceppi | hatch: I do/have | 19:06 |
hatch | marcoceppi thanks :) | 19:06 |
natefinch | rogpeppe: lol, nice | 19:11 |
=== zz_mwhudson is now known as mwhudson | ||
marcoceppi | natefinch: is juju ipv6 safe? | 20:33 |
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:34 |
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:38 |
marcoceppi | rogpeppe1: you mean within charms, or within the juju core? | 20:39 |
rogpeppe1 | marcoceppi: the latter | 20:39 |
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:40 |
rogpeppe1 | marcoceppi: yup | 20:41 |
natefinch | marcoceppi: I certainly wouldn't count on it without some heavy testing. | 20:41 |
marcoceppi | thanks | 20:42 |
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 | 20:58 |
thumper | hey marcoceppi, are you wanting my incredibly hacked up github webhook charm? | 21:00 |
thumper | natefinch: are you currently working on any of the 1.17.3 or 1.18.0 bugs? | 21:04 |
natefinch | thumper: I just started looking into the mongo location bug, but haven't gotten far with it | 21:06 |
thumper | ok | 21:06 |
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:08 |
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:09 |
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:10 |
rick_h_ | thumper: thanks, looking | 21:11 |
rick_h_ | ah, state-port I don't have | 21:11 |
rick_h_ | thanks thumper, I'll try that out. | 21:12 |
natefinch | I think I could save myself a lot of frustration if I just did ln -s /usr /user | 21:38 |
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:42 |
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:43 |
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:45 |
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:46 |
* sinzui keeps switching between version of juju and deps | 21:47 | |
sinzui | natefinch, /usr/lib/juju/bin/mongod | 21:48 |
natefinch | sinzui: thanks | 21:49 |
sinzui | natefinch, this is all that juju-mongodb added to /usr/lib/juju | 21:50 |
sinzui | http://pastebin.ubuntu.com/6922408/ | 21:50 |
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 | 21:53 |
davecheney | thumper: pong | 22:21 |
thumper | davecheney: did I ping you? | 22:21 |
davecheney | thumper: do you have access to the bot ? | 22:21 |
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:22 |
thumper | davecheney: it says it is already at the latest revision | 22:23 |
thumper | davecheney: however that doesn't list trusty | 22:25 |
thumper | davecheney: how do we update the source for it? | 22:26 |
davecheney | oh dear | 22:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:33 |
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:34 |
* thumper goes to file a bug for the fuckup | 22:35 | |
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:37 |
davecheney | sinzui: like the thing that sudo does | 22:38 |
sinzui | \o/ home brew accepted juju 1.16.6. I can close the release log | 22:39 |
thumper | \o/ | 22:40 |
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:42 |
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:43 |
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:44 |
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:49 |
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:51 |
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:52 |
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:53 |
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:54 |
wallyworld | i think it's UserHomeDir | 22:56 |
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:57 |
wallyworld | MakeEmptyFakeHomeWithoutJuju | 22:58 |
=== thumper is now known as thumper-lunch |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!