| hazmat | davecheney, false | 00:05 |
|---|---|---|
| hazmat | tags are project specific | 00:05 |
| hazmat | albeit guess work | 00:05 |
| davecheney | hazmat: hmm, i found a way I can search across projects via tag | 00:06 |
| davecheney | go to the main page of lp | 00:07 |
| davecheney | search for your tag there | 00:07 |
| davecheney | sort of works | 00:07 |
| wallyworld_ | projects can have official tags defined to remove the guesswork. you get auto completion and stuff like that then | 00:07 |
| davecheney | i'm trying to build a report for PM who need to know how much work is left on a project | 00:10 |
| davecheney | whenever I see them maintaing their own list in a google doc | 00:10 |
| davecheney | I cry inside | 00:10 |
| wallyworld_ | wonder why they do that | 00:14 |
| davecheney | launchpad is hard, let's go shopping | 00:16 |
| wallyworld_ | davecheney: launchpad is not that hard when a) you know how to use it b) you use it for which it was intended | 00:18 |
| davecheney | sorry, i missed the <sarcasm /> tag | 00:18 |
| wallyworld_ | ah :-) | 00:18 |
| wallyworld_ | there's also a Canonical developed project tracking tool they could have used | 00:19 |
| wallyworld_ | can't recall the url right now | 00:19 |
| wallyworld_ | thumper: do you know why it's proposed to change managerConfig from a struct to a map? | 00:20 |
| thumper | yes | 00:20 |
| thumper | I'll review that one | 00:20 |
| thumper | it is part of the policy stuff | 00:20 |
| thumper | a pre-req refactoring to make it easier | 00:21 |
| wallyworld_ | ok | 00:21 |
| thumper | will also be using it for the fast-lxc clone mechanism | 00:21 |
| wallyworld_ | thumper: also, here's a fix for local provider upgrader bounce https://codereview.appspot.com/69690043 | 00:21 |
| thumper | also, side note | 00:21 |
| thumper | I have a physio appt at 2pm | 00:21 |
| thumper | may not be back for the standup | 00:21 |
| wallyworld_ | ok, we can delay it | 00:21 |
| thumper | either that or do it without me :-) | 00:22 |
| * thumper doesn't feel that special | 00:22 | |
| thumper | we can see though | 00:22 |
| wallyworld_ | could do, we did it last week | 00:22 |
| wallyworld_ | just didn't want you to miss out :-) | 00:22 |
| thumper | :) | 00:23 |
| thumper | the description on that branch doesn't indiate that it fixes the local provider upgrade stuff | 00:23 |
| wallyworld_ | thumper: cause it describes the root cause issue | 00:25 |
| thumper | kk | 00:25 |
| wallyworld_ | which is DesiredTools() failed | 00:25 |
| wallyworld_ | may have had more impact that just local provider | 00:25 |
| wallyworld_ | i tested local provider by hand and it fixed the issue | 00:26 |
| wallyworld_ | i want to run a 1.16 to 1.18 upgrade test also to check the lock dir and system key stuff gets sorted out properly | 00:27 |
| thumper | kk | 00:28 |
| wallyworld_ | thumper: do you think we can finally re-purpose --verbose for 1.18? or wait till 1.20? it's been deprecated for ages now. needs to happen before 2.0 though. | 00:32 |
| thumper | a problem we have is that we don't get verbose feedback from the api... | 00:33 |
| thumper | general output would be "calling api foo" | 00:33 |
| thumper | some result | 00:33 |
| thumper | not sure how good verbose will be there... | 00:33 |
| thumper | however, I think we should change it RSN | 00:33 |
| wallyworld_ | we can use to log request response and stuff like that perhaps | 00:33 |
| wallyworld_ | we can think of something to use it for | 00:34 |
| wallyworld_ | but yeah, the change needs to happen | 00:34 |
| wallyworld_ | we can always improve the verbose output | 00:34 |
| wallyworld_ | over time | 00:34 |
| === _mup__ is now known as _mup_ | ||
| === _mup__ is now known as _mup_ | ||
| wallyworld_ | sigh, bot hung again. stabby, stabby | 00:55 |
| wallyworld_ | wow, bot is soooo slooooow today | 00:58 |
| axw | wallyworld_: is there any reason not to include *state.State in the upgrade Context for state servers? | 01:03 |
| axw | (it would be nil for non-state servers) | 01:03 |
| wallyworld_ | um | 01:03 |
| wallyworld_ | guess not | 01:03 |
| wallyworld_ | i was thinking it best to go via api | 01:03 |
| axw | the reason I ask is if there's not one, I have to add an API that will only ever be used for upgrades | 01:04 |
| axw | (updating syslog port) | 01:04 |
| wallyworld_ | i see | 01:04 |
| wallyworld_ | there's pros and cons both ways i guess | 01:05 |
| axw | I | 01:06 |
| wallyworld_ | i think it could work out ok to do it | 01:06 |
| axw | I will propose adding it for now, we can reassess later if it's a bad idea | 01:06 |
| axw | wallyworld_: technically you can get it already through the agent.Config... but it'd probably be better to not open again | 01:07 |
| wallyworld_ | yeah, prefer not to open a 2nd one | 01:08 |
| wallyworld_ | axw: tim will be late for standup - physio. he said we could do it without him but i don't mind waiting till he gets back | 01:25 |
| axw | wallyworld_: no worries, let's wait | 01:25 |
| === jcsackett_ is now known as jcsackett | ||
| waigani_ | _thumper_, axw, wallyworld_ standup? | 01:34 |
| axw | waigani_: waiting for thumper to return | 01:34 |
| waigani_ | ah sorry just saw above | 01:34 |
| * _thumper_ is back | 01:38 | |
| === _thumper_ is now known as thumper | ||
| axw | wallyworld_, waigani_ let's do it | 01:40 |
| thumper | davecheney: I managed to run gocheck tests with gccgo... what is the problem you are seeing? | 02:22 |
| * thumper wanders into the kitchen to make that coffee now that the machine is hot | 02:22 | |
| davecheney | thumper: last time I tried they don't pass on any arch | 02:53 |
| * davecheney goes to find the bug report | 02:53 | |
| davecheney | https://bugs.launchpad.net/gocheck/+bug/1250253 | 02:53 |
| _mup_ | Bug #1250253: many tests fail with gccgo <gccgo> <ppc64el> <Gocheck:New> <juju-core:Triaged by dave-cheney> <https://launchpad.net/bugs/1250253> | 02:53 |
| davecheney | thumper: gocheck tests don't appear to pass with golang-go either | 02:54 |
| thumper | ah... | 02:54 |
| * thumper sadface | 02:54 | |
| davecheney | it fails really badly under gccgo | 02:55 |
| davecheney | because gccgo has a different format for stack traces | 02:55 |
| * thumper is looking at bug 1276909 | 02:56 | |
| _mup_ | Bug #1276909: error detecting hardware characteristics: unrecognised architecture: aarch64 <arm64> <hs-arm64> <patch> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1276909> | 02:56 |
| thumper | davecheney: yeah I noticed that too | 02:56 |
| thumper | wallyworld_: any idea why hpcloud metadata simplestream search is just "amd64" and "arm" while ec2 is "amd64", "i386" and "arm" ? | 02:57 |
| wallyworld_ | thumper: i'd guess that hp cloud doesn't have i386 images? | 02:57 |
| thumper | any idea if it has arm64 images? | 02:57 |
| wallyworld_ | no idea | 02:57 |
| thumper | wallyworld_: if we searched for them and they aren | 02:57 |
| * thumper sighs | 02:58 | |
| thumper | and they aren't there, should be fine though right? | 02:58 |
| wallyworld_ | yeah, will be fine | 02:58 |
| davecheney | wallyworld_: can you do something like nova list-images [sic] against HP cloud ? | 02:58 |
| wallyworld_ | i think so yes | 02:58 |
| wallyworld_ | let me check | 02:58 |
| wallyworld_ | i only see 64 bit | 02:59 |
| thumper | wallyworld_: I'm just applying patches from the bug mentioned above | 03:07 |
| thumper | and I hit my repetition threshold | 03:07 |
| thumper | was wondering if we could refactor and combine known architectures | 03:07 |
| wallyworld_ | sure, whatever works :-) | 03:07 |
| wallyworld_ | not all providers support all arches | 03:08 |
| thumper | sure | 03:08 |
| thumper | but we can ask for what we know about though right? | 03:08 |
| wallyworld_ | i would think so | 03:08 |
| davecheney | ok launchpad.net/juju-core/cmd/jujud 578.049s | 03:12 |
| davecheney | mmm, speedy | 03:12 |
| davecheney | 12 more seconds and test watchdog would have nixed it | 03:13 |
| wallyworld_ | axw__: i think i might need a state reference in the upgrade context also - well, it will make it easier anyway | 03:20 |
| axw__ | wallyworld_: I started doing it, but it's a pain in the arse to to get the state.State object where the upgrader is created... | 03:21 |
| axw__ | I can go back to it if you need it though | 03:21 |
| wallyworld_ | hmmmm | 03:21 |
| === axw__ is now known as axw | ||
| wallyworld_ | what i need to do is delete some obsolete config entries | 03:21 |
| wallyworld_ | and EnvironmentSet() is only on clients | 03:22 |
| axw | wallyworld_: ok, I will just do it | 03:22 |
| wallyworld_ | but only when on a state server, right? | 03:22 |
| axw | I figured I'd leave it till it was needed by someone else, so there we go :) | 03:22 |
| axw | yep | 03:22 |
| wallyworld_ | i wonder if it really is the right thing to do | 03:23 |
| thumper | wallyworld_: bot still fubared? | 03:23 |
| wallyworld_ | or if we should just do it via an api endpoint | 03:23 |
| wallyworld_ | yep :-( | 03:23 |
| * thumper sighs | 03:23 | |
| wallyworld_ | it just keeps restarting my mp | 03:23 |
| axw | wallyworld_: seems to me that the state server shouldn't need to go through the API. | 03:23 |
| wallyworld_ | cause it can't get enough cpu cycles to run the tests in time | 03:24 |
| davecheney | thumper: did errgo move to juju/errgo ? | 03:24 |
| wallyworld_ | axw: yeah, i can see that argument, although there are worker on the state server that do go via the api | 03:24 |
| davecheney | or am i smoking cheap crack ? | 03:24 |
| thumper | davecheney: no, juju/errgo is rog's one | 03:25 |
| thumper | davecheney: errgo/errgo will die | 03:25 |
| wallyworld_ | i think all workers should, but for one off upgrade tasks... | 03:25 |
| davecheney | thumper: i noticed that some packages in juju-core still pull the latter | 03:25 |
| thumper | aye, they should change | 03:25 |
| davecheney | m'kay | 03:26 |
| davecheney | just fiddling with my spreadsheet | 03:26 |
| thumper | davecheney: yes it does give me hives | 03:39 |
| davecheney | well, i'm going to double down and s/arm64/ppc64/ | 03:41 |
| thumper | davecheney: thought you might, but shouldn't it be ppc64le? | 03:45 |
| axw | el? (to match dpkg arch?) | 03:45 |
| thumper | yeah | 03:45 |
| davecheney | thumper: it's ppc64 for the same reason that it's arm64, not aarch64 | 03:47 |
| davecheney | i really hope there is no requirement to handle the aliasing | 03:47 |
| davecheney | thumper: oh man, I think this is going to be harder | 03:50 |
| davecheney | actually no | 03:50 |
| davecheney | ignore | 03:50 |
| davecheney | oh, who was saying that they couldn't bootstrap 386 images on hp cloud | 03:54 |
| davecheney | https://codereview.appspot.com/69850043/diff/1/provider/openstack/provider.go?column_width=80 | 03:54 |
| davecheney | ^ there is your answer | 03:54 |
| axw_ | wallyworld_: sorry, took me a little while to figure out a cleanish way to do it, CL incoming now | 04:22 |
| wallyworld_ | axw_: awesome, thanks. i've got my branch ready to go as soon as your lands | 04:22 |
| thumper | is anything landing? | 04:27 |
| wallyworld_ | thumper: i've upped the timeout to 45 minutes to see if that is enough | 04:29 |
| thumper | kk | 04:29 |
| wallyworld_ | axw_: you you have the shiteveld link? | 04:29 |
| axw_ | wallyworld_: still uploading, will let you know | 04:30 |
| wallyworld_ | ok | 04:30 |
| axw_ | wallyworld_: https://codereview.appspot.com/69890043/ | 04:34 |
| wallyworld_ | looking | 04:34 |
| davecheney | surely this one is fixed https://bugs.launchpad.net/juju-core/+bug/1240260 | 04:38 |
| _mup_ | Bug #1240260: juju bootstrap does not honor https_proxy in environment when fetching tools <amd64> <apport-bug> <cts-cloud-review> <saucy> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1240260> | 04:38 |
| wallyworld_ | davecheney: i'm pretty sure that's now fixed with tim's recent proxy changes | 04:44 |
| wallyworld_ | axw_: reviewed, but there are missing tests | 04:45 |
| axw_ | okey dokey | 04:46 |
| wallyworld_ | i'm doing the same get config, set config dance in my branch also | 04:46 |
| davecheney | wallyworld_: wanna close it and we'll pretend it never happened | 04:46 |
| axw_ | ok | 04:46 |
| axw_ | (to ian) | 04:47 |
| wallyworld_ | davecheney: i think it can be closed yeah | 04:47 |
| axw_ | wallyworld_: I need to have lunch, so won't have it done for a little while yet | 04:48 |
| wallyworld_ | no proble, i can still merge your branch | 04:48 |
| wallyworld_ | problem | 04:48 |
| axw_ | wallyworld_: what do you mean "machine agent upgrade in cmd/jujud/upgrade_test.go" ? | 04:49 |
| axw_ | you mean something that tests whether state.State is available? | 04:49 |
| wallyworld_ | axw_: in cmd.jujud, there's tests which set up an env, start machine agent, and check that the upgrades are done | 04:50 |
| wallyworld_ | you just need to add somes lines to (wallyworld checks method name) | 04:50 |
| wallyworld_ | assertStateServerUpgrades | 04:50 |
| axw_ | ah I see | 04:51 |
| axw_ | thanks | 04:51 |
| wallyworld_ | np. also a unit test for the rsyslog upgrade method itself | 04:51 |
| wallyworld_ | in rsyslogupgrade_test.go | 04:51 |
| axw_ | yep got it | 04:51 |
| axw_ | wallyworld_: I didn't actually record a.st, so ... bear that in mind when you merge :) | 05:00 |
| axw_ | I just live tested and it blew up | 05:00 |
| wallyworld_ | i'm just running the test now :-) | 05:00 |
| axw_ | so, these upgrade tests are going to install rsyslog-gnutls on the test machine aren't they... I'd better fix that | 05:02 |
| wallyworld_ | um yeah :-) | 05:03 |
| wallyworld_ | i think we have stubs for apt for testing | 05:03 |
| wallyworld_ | somehwere in utils | 05:03 |
| axw_ | yep | 05:03 |
| * axw_ crosses fingers and restarts | 06:08 | |
| axw | oh joy, compiz is crashing | 06:17 |
| wallyworld_ | \o/ | 06:18 |
| rogpeppe | mornin' all | 08:31 |
| fwereade | rogpeppe, heyhey | 08:42 |
| rogpeppe | fwereade: hiya | 08:42 |
| fwereade | rogpeppe, guess what I forgot to do in the zip package? | 08:42 |
| rogpeppe | fwereade: what was that then? | 08:43 |
| fwereade | rogpeppe, close the files I write to :/ | 08:43 |
| rogpeppe | fwereade: doh! | 08:43 |
| * rogpeppe feels stupid for missing that | 08:43 | |
| fwereade | rogpeppe, I was totally baffled by ETXTBSY for a disturbingly long time | 08:43 |
| rogpeppe | fwereade: good thing you got that really | 08:43 |
| rogpeppe | fwereade: otherwise we'd just have had a leak | 08:44 |
| fwereade | rogpeppe, yeah, absolutely | 08:44 |
| dimitern | fwereade, rogpeppe, wallyworld_ , standup? | 10:45 |
| ev_ | hi guys. Anyone know who's responsible for uploading the partner os images to HP Cloud's glance? | 11:27 |
| ev_ | they're still using Ubuntu 12.04.2 on region-a.geo-1 | 11:28 |
| fwereade | ev_, I think you'll want to talk to utlemming about that | 11:32 |
| ev_ | thanks | 11:34 |
| dimitern | fwereade, i've added a few bits, but all in all the document lgtm | 11:58 |
| fwereade | dimitern, great, tyvm | 12:04 |
| cjohnston | rogpeppe: any updates on the api watcher issue at all? | 12:14 |
| rogpeppe | cjohnston: i'm sorry, i've been trying to make progress on HA, so haven't been spending much time on bugs recently. | 12:15 |
| cjohnston | ack | 12:15 |
| cjohnston | is that node 0 HA? | 12:16 |
| rogpeppe | cjohnston: yes | 12:16 |
| cjohnston | very cool | 12:17 |
| rogpeppe | cjohnston: hopefully :-) | 12:17 |
| === BradCrittenden is now known as bac | ||
| mattyw | is anyone available to help me work out what's going wrong with one of my cmd/juju tests? | 14:20 |
| rogpeppe | lunch | 14:22 |
| rogpeppe | mattyw: will have a look later if you haven't solved the issue | 14:23 |
| mattyw | rogpeppe, if you could spare 10 minutes I'd appreciate it - I'm sure I'm being an idiot somewhere - but I'd love to know where :) | 14:24 |
| mattyw | rogpeppe, I have a meeting in 30 mins so there's no hurry - enjoy your lunch | 14:24 |
| sinzui | mgz, rogpeppe Do either of you have a few minutes to review https://codereview.appspot.com/70100043 | 15:10 |
| adeuring | TheMue: could you please have a look here: https://codereview.appspot.com/68000045 ? | 15:11 |
| TheMue | adeuring: yep *click* | 15:11 |
| mgz | sinzui: sure thing | 15:11 |
| mgz | sinzui: lgtm | 15:12 |
| sinzui | oh bugger. mgz, I see this MP that makes me think I should wait an hour for CI to bless. Is lander stuck? https://code.launchpad.net/~wallyworld/juju-core/unitupgrader-desired-tools/+merge/208710 | 15:12 |
| mgz | sinzui: yeah, the bot is kinda screwed | 15:12 |
| mgz | I can, if needed, manually land things | 15:13 |
| mgz | it's had load of >3 all day, for no obvious reason | 15:13 |
| sinzui | mgz, I don't want to rush things. I am assuming that CI will bless the revision if it merges. | 15:14 |
| mgz | pretty sure nothing will land unless I bash something hard | 15:18 |
| mgz | the current one has been going... very slowly... since 9:30 this morning | 15:19 |
| sinzui | wow | 15:19 |
| sinzui | mgz, this is canonistack? | 15:19 |
| mgz | yep. | 15:20 |
| mgz | lcy02 | 15:20 |
| sinzui | It is dying. | 15:20 |
| jcastro | Do we have docs for writing your own provider? | 15:20 |
| sinzui | We just moved juju-ci off of it | 15:20 |
| mgz | I've not seen any "this is totally screwed" annoncement yet, but it does seem that way | 15:20 |
| sinzui | mgz ^ I recommend setting up the lander in another cloud. | 15:21 |
| mgz | jcastro: we have a branch from fwereade with docs and a template provider | 15:21 |
| mgz | it's somewhat out of date with trunk, but is a good start for a capable coder | 15:21 |
| fwereade | jcastro, mgz: sorry, I never actually landed that, roger had some good comments that I never addressed | 15:21 |
| sinzui | mgz We saw performance degradation and nova lost two machines, and was shuting other down | 15:21 |
| fwereade | jcastro, mgz: it's what the joyent provider started out as | 15:21 |
| jcastro | ok so for the docs I'll just say "contact us" for now | 15:22 |
| mgz | sinzui: that's more than an end-of-fraiday task, and jam wants to move us to a jenkins thing anyway | 15:22 |
| mgz | jcastro: I can forward you a mail I sent with the details | 15:22 |
| jcastro | I am renaming the null->manual in the docs, and I wanted to say something like "obviouslly adding machines by hand is not ideal, if you're a provider and want to natively support juju go here." | 15:22 |
| mgz | ...actually, you were probably cced on it | 15:22 |
| sinzui | mgz, understood. We have stood up enough CIs that it is a could of hours for us to move | 15:22 |
| jcastro | ok, I just wanted something for 1.18, this is Good Enough | 15:23 |
| jcastro | we should at some point have a proper page though | 15:23 |
| mgz | jcastro: yeah, see the "Juju on Digital Ocean" mail from 2014-02-04 | 15:23 |
| * jcastro nods | 15:23 | |
| mgz | links william's branch | 15:24 |
| TheMue | adeuring: done | 15:36 |
| adeuring | Thethanks! | 15:37 |
| adeuring | TheMue: Thanks | 15:37 |
| * rogpeppe is back after a rather extended lunchtime think'n'stomp. | 16:21 | |
| natefinch | Damn, I bought an external battery for my laptop for the flight, and none of the adapters fits my plug :/ | 16:29 |
| rogpeppe | natefinch: something that would have been worth verifying in advance, i guess :-) | 16:36 |
| rogpeppe | mattyw: what's the problem, then? | 16:36 |
| natefinch | rogpeppe: heh yeah. I guess I'll have to run to radioshack and see if they have an adapter from the "big" dell plug to the mini one my laptop has | 16:37 |
| mattyw | rogpeppe, quick hangout? | 16:37 |
| rogpeppe | mattyw: sure | 16:37 |
| natefinch | man, I wish there was a way to expose functionality in *other* packages during test. Can't tell you how much easier that would make so many tests, and how many "this is only public for testing, please don't change" we could remove. | 16:51 |
| natefinch | rogpeppe: is there a trick we're missing to do this? Sort of a way for a package to say "hey, here's some stuff you might want to mock out during tests" that other packages could then twiddle with, but only during testing? | 16:53 |
| rogpeppe | natefinch: nope | 16:56 |
| rogpeppe | fwereade: ping | 16:56 |
| natefinch | rogpeppe: dang. I thought that was the case, but was hoping I was wrong | 16:58 |
| fwereade | rogpeppe, pong | 17:08 |
| rogpeppe | fwereade: i was just in a call with mattyw, and thought i should run an idea past you | 17:14 |
| rogpeppe | fwereade: matty's problem was that in his Cmd implementation, he was doing a store.ReadInfo(c.EnvName) | 17:14 |
| rogpeppe | fwereade: but c.EnvName can be blank | 17:14 |
| rogpeppe | fwereade: because it can be specified as a default in environments.yaml, which isn't read by then | 17:15 |
| rogpeppe | fwereade: so my suggestion was that we can make EnvCommandBase read environments.yaml in that case, so c.EnvName will always be non-empty when possible | 17:15 |
| rogpeppe | fwereade: which means we could lose the "" special case in a fair few places | 17:16 |
| rogpeppe | fwereade: and it means it's easier for people to write plugins too (and easier to move away from environments.yaml when the time comes) | 17:17 |
| fwereade | rogpeppe, don't we have a standard set of fallbacks? ie the JUJU_ENV, wherever juju switch stores, etc | 17:18 |
| fwereade | rogpeppe, but yeah, it certainly seems like a good idea to do all that logic OAOO and expose it nicely for these situations | 17:19 |
| rogpeppe | fwereade: yeah, most of them are already dealt with by EnvCommandBase | 17:19 |
| fwereade | rogpeppe, and start requiring actual env names at all lower levels | 17:19 |
| rogpeppe | fwereade: except the default-from-environments.yaml case | 17:19 |
| fwereade | rogpeppe, cool, if it's just a matter of extracting a method from there then all the better | 17:19 |
| fwereade | rogpeppe, bah | 17:19 |
| fwereade | rogpeppe, probably still worth the ickiness of reading envs.yaml twice to put that logic in one place and drop the ""->default stuff inside environs | 17:20 |
| rogpeppe | fwereade: that was my thought too | 17:20 |
| fwereade | rogpeppe, done and done, then :) | 17:20 |
| rogpeppe | fwereade: i think the best thing is just to put the logic inside getDefaultEnvironment, and possibly make it ignore any error if it fails to read the environments.yaml file. | 17:21 |
| rogpeppe | fwereade: although the latter is more arguable | 17:22 |
| rogpeppe | fwereade: but AFAICS the worst that can happen is that we get an empty default | 17:23 |
| fwereade | rogpeppe, yeah, "no environment specified" doesn't seem unreasonable | 17:26 |
| fwereade | rogpeppe, I guess we ultimately want to fall back to "the only jenv that exists" if *nothing* else is specified (and there is only one) | 17:27 |
| rogpeppe | fwereade: i'm not sure about that | 17:27 |
| rogpeppe | fwereade: i think juju switch works pretty well in general | 17:28 |
| rogpeppe | fwereade: (much as i wasn't keen on the idea to start with :-]) | 17:28 |
| fwereade | rogpeppe, eh, it's arguable I guess | 17:28 |
| fwereade | rogpeppe, putting the existing logic in one place is enough of a win for me :) | 17:28 |
| rogpeppe | fwereade: if i've just deleted an environment, i don't really want it to suddenly switch to another environment just because it's the only one left | 17:29 |
| rogpeppe | fwereade: yeah | 17:29 |
| fwereade | rogpeppe, yeah, fair point -- you'd probably have that earlier env switched in, but I agree you might not, and the impact of a surprising change could be significant | 17:30 |
| rogpeppe | fwereade: actually, a possibly better idea is to change EnvName to be a method that returns (string, error) | 17:30 |
| fwereade | rogpeppe, +1 | 17:30 |
| rogpeppe | fwereade: it's more invasive, unfortunatly | 17:30 |
| rogpeppe | fwereade: but probably worth it | 17:30 |
| rogpeppe | mattyw: could you do that, please? | 17:31 |
| rogpeppe | fwereade: actually, another, possibly slightly less invasive option is to add an Init method to EnvCommandBase | 17:33 |
| rogpeppe | fwereade: and leave the EnvName field as it is | 17:33 |
| rogpeppe | fwereade: that actually feels more in keeping with the other command stuff | 17:33 |
| rogpeppe | mattyw: pending fwereade's reply, i think that's a nicer option | 17:35 |
| rogpeppe | fwereade: one other thing: there's an import cycle if EnvCommandBase calls environs, because environs indirectly uses juju-core/cmd | 17:38 |
| rogpeppe | fwereade: cmd has always seemed to me to be a somewhat dubious place to have EnvCommandBase, tbh | 17:38 |
| rogpeppe | fwereade: i think maybe it could live in its own package, along with other environment-related cmd stuff | 17:40 |
| fwereade | rogpeppe, +1 to that as well, thanks | 17:40 |
| rogpeppe | fwereade: like... wtf is IsMachineOrNewContainer doing in cmd ? | 17:40 |
| fwereade | rogpeppe, sounds like "loitering with intent" to me | 17:41 |
| rogpeppe | fwereade: i gave it a sharp word | 17:41 |
| fwereade | rogpeppe, IIRC is is subtly misnamed as well | 17:41 |
| fwereade | rogpeppe, ah no maybe it's accurately named but insane | 17:41 |
| fwereade | rogpeppe, we ought to be either detecting an explicit machine name or dispatching a placement directive to a (pseudo-)provider | 17:42 |
| sinzui | I suspect that the bug fix that wallyworld_ has for machine agents is broader that local-provider. my 1.17.4 release from trusty cannot bootstrap precise | 17:42 |
| rogpeppe | fwereade: anyway, it's only used in two places, and should probably be in cmd/juju until more widespread | 17:43 |
| rogpeppe | fwereade: how about juju-core/cmd/juju/envcmd as a package name for EnvCommandBase? | 17:44 |
| rogpeppe | fwereade: cmd/envcmd is also a possibility, i guess | 17:44 |
| dimitern | i'd appreciate if someone takes a look at my agent conf 1.18 CL https://codereview.appspot.com/70010045 | 17:44 |
| dimitern | it was truly painful to merge all trunk changes | 17:45 |
| rogpeppe | fwereade: except that would pollute the cmd/* name space | 17:45 |
| rogpeppe | dimitern: you've still got some .THIS files in there | 17:45 |
| dimitern | rogpeppe, man! seriously.. :/ I'll repropose | 17:46 |
| dimitern | it's good they're only 2 and both are now gone | 17:47 |
| dimitern | rogpeppe, updated | 17:52 |
| rogpeppe | dimitern: thanks | 17:52 |
| natefinch | rogpeppe, mgz, fwereade: anyone know why gocheck would suddenly not be able to create temporary directories? Panic: Couldn't create temporary directory /tmp/gocheck-5577006791947779410/1: mkdir /tmp/gocheck-5577006791947779410/1: no such file or directory (PC=0x413FC6) | 18:20 |
| rogpeppe | natefinch: how many directories have you got in /tmp? | 18:21 |
| natefinch | rogpeppe: one | 18:21 |
| rogpeppe | natefinch: does this happen every time? | 18:21 |
| mgz | mystery | 18:22 |
| natefinch | rogpeppe: currently, yes. Let me try removing this mkdir and see if another one elsewhere succeeds, maybe I'm hitting some weird race condition somehow | 18:23 |
| natefinch | rogpeppe: it seems to not fail in other packages I test | 18:24 |
| natefinch | rogpeppe: nevermind, I see what I did... misunderstanding of what os.TempDir returns.... looks like I was actually deleting /tmp in one of my tests | 18:27 |
| rogpeppe | natefinch: oops :- | 18:27 |
| rogpeppe | ) | 18:27 |
| rogpeppe | natefinch: good thing it wasn't $HOME, eh? | 18:27 |
| natefinch | rogpeppe: ahh yeah. I've done that before too, though not in code, just by being in the wrong place when I did rm -rf * | 18:28 |
| natefinch | ....and this is why man invented offsite backups. | 18:29 |
| sinzui | natefinch, when I see this | 18:33 |
| sinzui | Starting MongoDB server (juju-db) | 18:33 |
| sinzui | is this mongodb-server and juju-mongodb? | 18:34 |
| natefinch | sinzui: that's the mongod upstart service that juju creates when it installs itself. | 18:35 |
| sinzui | natefinch, and since mongodb-server is the only thing juju knows how to install, we know it is mongodb-server | 18:37 |
| sinzui | natefinch, fwereade, jam1, This bug aborted the 1.17.4 release. https://bugs.launchpad.net/juju-core/+bug/1286279 | 18:53 |
| _mup_ | Bug #1286279: juju 1.17.4 trusty client cannot bootstrap 1.17.x precise <precise> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1286279> | 18:53 |
| * sinzui needs to think about how to not let 1.17.4 get into the hands of ubuntu trusty users | 18:53 | |
| * rogpeppe is done for the week | 18:54 | |
| rogpeppe | g'night all | 18:55 |
| mgz | night rog | 18:56 |
| mgz | see you next week! | 18:56 |
| rogpeppe | mgz: yeah! | 19:01 |
| natefinch | rogpeppe: see you next week :) | 19:03 |
| sinzui | natefinch, Do you have any insights into this bug. https://bugs.launchpad.net/juju-core/+bug/1286279 | 21:37 |
| _mup_ | Bug #1286279: juju-mongodb breaks 1.17.4 trusty client bootstrap in CPC <bootstrap> <mongodb> <precise> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1286279> | 21:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!