| bigjools | wallyworld_: haha I see you're fixing the http bug in the other providers then | 00:12 |
|---|---|---|
| wallyworld_ | yeah | 00:14 |
| wallyworld_ | bigjools: turns out the goamz lib sets Close = true | 00:23 |
| bigjools | fancy that | 00:23 |
| thumper | rogpeppe1: don't suppose you are still around? | 00:41 |
| wallyworld_ | bigjools: what's the process for landing gomaasapi changes? looks like landing bot is not set up for that project. do i need to merge to trunk manually? | 01:02 |
| bigjools | it should be owned by the bot I thought | 01:02 |
| bigjools | hmmm maybe it's still running in the qa lab | 01:02 |
| wallyworld_ | doesn't appear to be | 01:02 |
| bigjools | yes I think it's a bot in the lab | 01:02 |
| bigjools | needs to be migrated | 01:02 |
| wallyworld_ | bigjools: can you land it for me then? | 01:03 |
| wallyworld_ | https://code.launchpad.net/~wallyworld/gomaasapi/fix-request-eof/+merge/191537 | 01:03 |
| bigjools | just set it approved | 01:03 |
| wallyworld_ | ah ok | 01:03 |
| thumper | bigjools: I wonder if it still works since I changed the owner... | 01:06 |
| bigjools | yeah :) | 01:06 |
| thumper | wallyworld_: if that doesn't work, merge and push to trunk directly | 01:06 |
| thumper | \o/ | 01:06 |
| wallyworld_ | alright | 01:06 |
| wallyworld_ | bigjools: ffs :-( can you please add me to ~maas-maintainers | 01:10 |
| bigjools | how';s that gonna help? | 01:10 |
| wallyworld_ | There was a problem validating some authors of the branch. Authors must be either one of the listed Launchpad users, or a member of one of the listed teams on Launchpad. | 01:11 |
| wallyworld_ | Persons or Teams: | 01:11 |
| wallyworld_ | maas-maintainers | 01:11 |
| bigjools | oh ffs | 01:11 |
| bigjools | let me see if I can remove that | 01:11 |
| wallyworld_ | ta | 01:11 |
| bigjools | oh fuck sake this is all fucked | 01:12 |
| bigjools | wallyworld_: merge manually | 01:12 |
| wallyworld_ | ok | 01:12 |
| bigjools | it's using jenkins tests on quantal and raring ffs | 01:12 |
| wallyworld_ | \o/ | 01:12 |
| axw | thumper: did I break the local provider with the bootstrap storager changes? | 01:20 |
| * thumper nods | 01:20 | |
| axw | sorry :( | 01:20 |
| thumper | or it could have been the prepare work | 01:20 |
| * axw looks closer | 01:20 | |
| thumper | not sure exactly where the problem lies | 01:20 |
| axw | mk | 01:20 |
| thumper | axw: it's fixed now | 01:20 |
| axw | I didn't think it was broken, it's optional | 01:20 |
| thumper | neither did I | 01:20 |
| thumper | something changed in bootstrap, so it tried to do some stuff earlier | 01:21 |
| thumper | I do remember changing some bootstrap stuff | 01:21 |
| thumper | too | 01:21 |
| axw | ok. I'll have a dig, I'd like to know why it broke | 01:21 |
| thumper | it'd be ironic if I broke it :) | 01:21 |
| axw | hehe | 01:21 |
| thumper | you know what... | 01:22 |
| thumper | I think I may have been me | 01:22 |
| thumper | with an early fail if already bootstrapped | 01:22 |
| thumper | heh | 01:22 |
| axw | ahhh | 01:22 |
| axw | that makes sense | 01:22 |
| thumper | it does the check after the enable bootstrap storage | 01:23 |
| thumper | although I thought I did that before my other lxc fixes | 01:23 |
| * thumper shrugs | 01:23 | |
| thumper | the log file indicates other stuff happening around prepare | 01:23 |
| axw | well anyway, it makes sense to have an EnableBootstrapStorage for local too | 01:24 |
| thumper | it does | 01:24 |
| axw | sorry, I didn't think to add it before | 01:25 |
| thumper | found out that lxc is broken right now with precise anyway | 01:25 |
| thumper | so we can't really use it | 01:25 |
| axw | :( | 01:25 |
| thumper | some other bug | 01:25 |
| thumper | leaving apt in a bad state | 01:25 |
| thumper | charm install hooks fail | 01:25 |
| thumper | anyway | 01:25 |
| thumper | I'm supposed to be looking at a problem for gary around the all watcher | 01:26 |
| thumper | so I'll have to fire up lots of machines in ec2 | 01:26 |
| davecheney | thumper: or containers ? | 01:27 |
| thumper | davecheney: or containers what? | 01:28 |
| davecheney | for gary's allwacher problem ? | 01:29 |
| sidnei | davecheney: lxc is broken because of a procps update that landed in precise-updates | 01:30 |
| davecheney | *sadface* | 01:31 |
| * thumper nods | 01:31 | |
| thumper | davecheney, axw: I know that in C++ you should never modify a map while you are iterating over it, how does go handle this? | 01:50 |
| axw | thumper: iirc it's not completely specified. I'll have to look it up | 01:51 |
| thumper | in C++ it can segfault | 01:51 |
| thumper | normally considered bad form modifying a container you are iterating | 01:51 |
| thumper | although can be done if careful | 01:52 |
| axw | yeah I'm all too familiar with those bugs ;) | 01:52 |
| thumper | the C++ language is very careful about what invalidates iterators | 01:52 |
| axw | spent many hours debugging other people's ugly C++, not to mention my own | 01:52 |
| thumper | I'm just looking inside the multiwatcher code | 01:52 |
| thumper | where it is responding to things | 01:52 |
| thumper | under load when there are likely to be multiple requests pending | 01:53 |
| thumper | the code iterates over the response map, and deletes things from the map as it is iterating | 01:53 |
| axw | thumper: "The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next. If map entries that have not yet been reached are removed during iteration, the corresponding iteration values will not be produced. If map entries are created during iteration, that entry may be produced during the iteration or may be skipped. The choice may vary for each entry created and from one iteration to the next | 01:53 |
| axw | . If the map is nil, the number of iterations is 0." | 01:53 |
| thumper | it just raises my suspiciions | 01:53 |
| axw | ignore the first sentence | 01:53 |
| axw | that's just saying iteration order is random | 01:53 |
| thumper | hmm... | 01:54 |
| thumper | what if you remove the current element? | 01:54 |
| axw | yeah, that's the "not fully specified" bit | 01:54 |
| axw | I can look it up in the runtime, but that won't help if it's not specified | 01:55 |
| * thumper nods | 01:55 | |
| thumper | we are keeping a map of singlely linked lists | 01:56 |
| thumper | it has been forever since I've had to manage that myself | 01:56 |
| * thumper considers a race condition | 01:59 | |
| thumper | arg... gotta go get a child | 02:02 |
| thumper | back | 02:10 |
| thumper | I have a horrible feeling about this | 02:20 |
| axw | ? | 02:21 |
| davecheney | ? | 02:22 |
| thumper | hmm... | 03:10 |
| thumper | can't seem to reproduce the problem | 03:10 |
| wallyworld_ | bigjools: pretty please https://code.launchpad.net/~wallyworld/gwacl/fix-request-eof/+merge/191545 | 03:27 |
| bigjools | wallyworld_: done | 03:37 |
| wallyworld_ | ta | 03:37 |
| * thumper gets back to look at wallyworld_'s branches | 03:54 | |
| wallyworld_ | \o/ | 03:55 |
| thumper | wallyworld_: hangout? | 03:55 |
| wallyworld_ | ok | 03:55 |
| thumper | https://plus.google.com/hangouts/_/7912539c41441cc8e5dc4021f78f9c48c48c9e69?hl=en | 03:56 |
| wallyworld_ | thumper: https://codereview.appspot.com/14769043 | 04:39 |
| bigjools | huh, nothing on ubuntu.com front page about the release ... | 05:28 |
| wallyworld_ | i'm too scared to try it | 05:30 |
| davecheney | bigjools: release is tomorrow | 05:54 |
| bigjools | davecheney: no it's today... | 05:56 |
| davecheney | stilll yesterday in the states, | 05:57 |
| davecheney | barely today in the UK | 05:57 |
| bigjools | meh | 05:57 |
| bigjools | anyway there's normally a countdown and at least *some* mention of it | 05:57 |
| davecheney | good point | 05:59 |
| rogpeppe1 | mornin' all | 07:30 |
| rogpeppe1 | thumper, axw: it's fine (and well defined) to remove the current element of a map when iterating over it | 07:31 |
| axw | rogpeppe1: morning. well defined where? | 07:31 |
| rogpeppe1 | axw: "If map entries that have not yet been reached are removed during iteration, the corresponding iteration values will not be produced." | 07:32 |
| rogpeppe1 | axw: i.e. yes, it's ok to remove an entry, and no, you won't see that entry again | 07:32 |
| rogpeppe1 | axw: nowhere does it say you cannot delete an entry from a map during iteration | 07:33 |
| axw | rogpeppe1: not saying something you can't do something is not the same as saying you can do it :) | 07:33 |
| axw | rogpeppe1: not really sure how that sentence says you can safely remove the current element either | 07:34 |
| axw | it's talking about past elements | 07:34 |
| rogpeppe1 | axw: in the spec, not saying you can't do something *is* equivalent to saying you can do it | 07:34 |
| rogpeppe1 | axw: and i know from past discussions that that is indeed the case here | 07:35 |
| axw | rogpeppe1: that sounds slightly scary from an implementer's perspective, but okay :) | 07:36 |
| rogpeppe1 | axw: i'm actually a bit surprised if even you don't know this - some stronger wording in the spec is perhaps called for, although ISTR that's been pushed back on in golang-dev before this | 07:36 |
| axw | rogpeppe1: I know it works, I just didn't know if it was guaranteed in the spec | 07:36 |
| rogpeppe1 | axw: basically the spec says (unqualified) "The built-in function delete removes the element with key k from a map m." | 07:37 |
| rogpeppe1 | axw: the fact that it's unqualified means you can do it anywhere (memory model permitting of course) | 07:37 |
| rogpeppe1 | axw: otherwise you'd need loads of qualifiers everywhere | 07:38 |
| rogpeppe1 | axw: however... this is indeed an unusual property in this case and could probably do with an additional sentence. | 07:38 |
| rogpeppe1 | axw: i should have said: in the spec, not saying you can't do something *is* equivalent to saying you can do it *if* there's something *saying* you can do it | 07:39 |
| axw | rogpeppe1: the fact that this has come up on golang-nuts (and in this channel ;)) before adds merit to that | 07:39 |
| axw | rogpeppe1: you may be interested to know, I started to rewrite parts of llgo to use adonovan's ssa package | 07:43 |
| axw | should be a bit more robust now :) | 07:43 |
| axw | well, when it's working. I'll have to stop warping the definition of interfaces to get it to work | 07:44 |
| rogpeppe1 | axw: cool! | 07:47 |
| rogpeppe1 | axw: how were you warping the definition of interfaces? | 07:47 |
| axw | rogpeppe1: llgo represents them as {runtime-type, value, method1, method2, ...} | 07:47 |
| axw | ugly hack | 07:48 |
| axw | should be done inside the runtime | 07:48 |
| axw | rogpeppe1: when you have a moment, can you please look at this: https://bugs.launchpad.net/juju-core/+bug/1239550 | 07:48 |
| _mup_ | Bug #1239550: juju should warn if .jenv doesn't match environments.yaml <config> <tech-debt> <ui> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1239550> | 07:48 |
| axw | well actually, the summary says it all | 07:49 |
| axw | rogpeppe1: bigjools and I were debugging and issue where he'd changed the oath token in his environments.yaml, but it wasn't taking effect | 07:49 |
| TheMue | morning | 07:49 |
| axw | turns out he'd already prepared, and then changed it | 07:49 |
| axw | morning TheMue | 07:50 |
| TheMue | axw: hiya | 07:50 |
| axw | rogpeppe1: that aside, it's a bigger problem for the null provider, which doesn't implement destroy-environment (yet) | 07:59 |
| wallyworld_ | rogpeppe1: i've landed 2 branches; i have 2 more to go to fix the http issue https://codereview.appspot.com/14769043/ https://codereview.appspot.com/14668044/ | 08:18 |
| rogpeppe1 | wallyworld_: did you see my response on https://codereview.appspot.com/14769043/ ? | 09:38 |
| rogpeppe1 | wallyworld_: i think it's possible to be much less invasive with this fix | 09:38 |
| rogpeppe1 | axw: sorry, only just saw your remark above | 09:39 |
| axw | rogpeppe1: nps | 09:39 |
| rogpeppe1 | axw: in general it has always been the case that changing something in your environments.yaml won't have any effect on an already-bootstrapped environment | 09:40 |
| thumper | rogpeppe1: https://bugs.launchpad.net/juju-core/+bug/1240708 | 09:41 |
| _mup_ | Bug #1240708: API server falls over repeatably during AllWatcher Next, killing GUI <juju-core:New> <juju-gui:Triaged> <https://launchpad.net/bugs/1240708> | 09:41 |
| thumper | rogpeppe1: I've been looking at that bug a little today | 09:42 |
| thumper | rogpeppe1: all I have been able to discern so far is that somewhere, someone is calling Stop on the watcher | 09:42 |
| rogpeppe1 | thumper: i hadn't seen that bug | 09:42 |
| * rogpeppe1 has a look | 09:42 | |
| axw | rogpeppe1: hmm, what about if bootstrap failed? or someone did sync-tools and not bootstrap yet? in the past, the environments.yaml change would take effect | 09:43 |
| thumper | rogpeppe1: yeah, filed by gary while you slept | 09:43 |
| axw | thumper: are we still going to have a meeting in a bit? | 09:44 |
| thumper | axw: aye | 09:44 |
| thumper | that is why I'm back :) | 09:44 |
| axw | makes sense :) | 09:44 |
| axw | thumper: when are you flying out? | 09:45 |
| rogpeppe | api client crashed. | 09:45 |
| rogpeppe | irc client, even | 09:45 |
| thumper | axw: sunday morning (from here), sunday night AKL -> SFO | 09:45 |
| thumper | arrive 11:15am SFO | 09:45 |
| axw | sameish | 09:45 |
| axw | I arrive a bit later I think | 09:46 |
| rogpeppe | and it doesn't seem to be notifying me when someone mentions my nickname any more, which is why i didn't see earlier remarks | 09:46 |
| axw | rogpeppe: what about when you don't have a 1 at the end of your name? | 09:46 |
| rogpeppe | axw: just testing - could you mention my irc nick, please? | 09:46 |
| rogpeppe | huh, weird | 09:50 |
| rogpeppe | this is the first time i've ever had a problem with this IRC app | 09:50 |
| axw | rogpeppe: testing | 09:51 |
| rogpeppe | axw: thanls | 09:55 |
| rogpeppe | axw: thanks even | 09:55 |
| axw | np | 09:55 |
| rogpeppe | axw: still buggered | 09:55 |
| rogpeppe | axw: if i bring up the "configure notifications" panel, the whole app halts when i click Ok | 09:56 |
| axw | rogpeppe: in case you missed all this: | 09:56 |
| axw | <rogpeppe1> thumper: i hadn't seen that bug | 09:56 |
| axw | * rogpeppe1 has a look | 09:56 |
| axw | <axw> rogpeppe1: hmm, what about if bootstrap failed? or someone did sync-tools and not bootstrap yet? in the past, the environments.yaml change would take effect | 09:56 |
| axw | <thumper> rogpeppe1: yeah, filed by gary while you slept | 09:56 |
| wallyworld_ | rogpeppe: i just saw your comments, thanks. so setting DisableKeepAlives=false has exactly the same effect as Close=true? | 09:56 |
| rogpeppe | wallyworld_: yes | 09:56 |
| wallyworld_ | ok | 09:57 |
| thumper | wouldn't DisableKeepAlives=true be the same as Close=true? | 09:57 |
| rogpeppe | thumper: yes | 09:57 |
| thumper | double negative would be like "enable keep alives" | 09:57 |
| wallyworld_ | whatever :-) | 09:57 |
| rogpeppe | thumper: yeah i missed the =false thing above | 09:58 |
| wallyworld_ | i knew what i meant :-) | 09:58 |
| thumper | wallyworld_: no one else did | 09:58 |
| rogpeppe | thumper: i did | 09:58 |
| wallyworld_ | rogpeppe did :-) | 09:58 |
| * thumper ignores them both | 09:59 | |
| rogpeppe | axw: i think that if bootstrap fails and we've prepared the environment in that step, that we should destroy the environment there and then | 09:59 |
| rogpeppe | axw: the sync-tools-then-bootstrap case is interesting | 10:00 |
| axw | rogpeppe: ideally, but you could still end up with a stale .jenv file if juju died half-way through | 10:00 |
| rogpeppe | axw: true - in general if you want to change attributes you need to destroy-environment first | 10:00 |
| rogpeppe | axw: warning about mismatched attributes may be a reasonable thing to do | 10:01 |
| rogpeppe | axw: we'd also want to check that a provider doesn't override any of the attributes at Prepare time (currently that's allowed) | 10:01 |
| axw | rogpeppe: I was thinking of adding in a provider.Validate call there, passing in .jenv/env.yaml as args | 10:02 |
| axw | rogpeppe: ? | 10:02 |
| axw | don't understand that bit | 10:02 |
| axw | rogpeppe: meeting is on | 10:03 |
| TheMue | rogpeppe: meeting | 10:06 |
| natefinch | rogpeppe: about the destroy-environment change I was proposing... I agree that you need to be able to script it. I just want it to require a little more thought than just throwing a -y on the end, if we're talking about taking down an entire network of services and destroying all the user's data | 10:53 |
| natefinch | rogpeppe: how about juju destroy-environment --confirm destroy-my_env_name ? | 10:54 |
| thumper | rogpeppe: confirmed just maas provider changed for the agent_name | 10:54 |
| rogpeppe | natefinch: if -y is good enough for fsck, it's good enough for me :-) | 10:55 |
| rogpeppe | thumper: yeah, i also confirmed that | 10:55 |
| rogpeppe | natefinch: how long do you have to make a name before it's hard enough to type? | 10:56 |
| rogpeppe | natefinch: that's the reason it's called "destroy-environment" rather than just "destroy" | 10:56 |
| natefinch | rogpeppe: yes, but the point is that people could destroy the *wrong* environment. That's why I want the environment name in the confirmation. | 10:56 |
| natefinch | rogpeppe: also, fsck will only fuck up one computer. destroy-environnent will fuck up potentially dozens or more | 10:57 |
| rogpeppe | natefinch: i dunno - have we actually encountered cases where this has been a problem? | 10:58 |
| rogpeppe | natefinch: a nicer solution would be to be able to deliberately "lock" an environment so that it's not possible to destroy until explicitly unlocked | 10:59 |
| natefinch | rogpeppe: then people have to remember to lock it | 11:00 |
| rogpeppe | natefinch: sure - you lock it if it's important to you | 11:00 |
| natefinch | rogpeppe: if you even realize that function exists | 11:00 |
| rogpeppe | natefinch: for many people destroying an environment isn't that big a deal - you can deploy everything again quite easily | 11:00 |
| thumper | natefinch: -y or --yes-I-know-what-Im-doing | 11:00 |
| thumper | :) | 11:01 |
| rogpeppe | natefinch: personally, i find even the current behaviour of destroy-environment to be annoying | 11:01 |
| natefinch | rogpeppe: which is more important, 10 keystrokes, or helping the users not shoot themselves in the foot? | 11:02 |
| rogpeppe | natefinch: that's a false dichotomy | 11:02 |
| natefinch | rogpeppe: this is the bug I was basing the work on: https://bugs.launchpad.net/juju-core/+bug/1057665 | 11:02 |
| _mup_ | Bug #1057665: juju destroy-environment is terrifying; please provide an option to neuter it <canonical-webops> <destroy-environment> <juju:Fix Committed by hazmat> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1057665> | 11:02 |
| natefinch | brb sorry | 11:03 |
| rogpeppe | natefinch: that bug report makes a similar suggestion to mine above | 11:03 |
| natefinch | rogpeppe: yes, but this solution is simpler and more effective. | 11:04 |
| rogpeppe | natefinch: i don't believe it's more effective | 11:05 |
| frankban | thumper: looking at bug 1240708: it could be a problem on the gui server side (aborting the connection) | 11:05 |
| _mup_ | Bug #1240708: API server falls over repeatably during AllWatcher Next, killing GUI <juju-core:New> <juju-gui:Triaged> <https://launchpad.net/bugs/1240708> | 11:05 |
| rogpeppe | natefinch: although it is simpler, i agree | 11:05 |
| frankban | thumper: working on it | 11:05 |
| rogpeppe | frankban: it certainly looked as if the API server saw a connection drop | 11:05 |
| natefinch | rogpeppe: it's more effective because it's automatic. Otherwise it's like having to turn on the airbag in your car. | 11:06 |
| rogpeppe | natefinch: i don't believe that making people type more makes an effective barrier - people will type *anything* without thinking | 11:07 |
| rogpeppe | natefinch: we've already got a written warning that mentions the name of the environment, and a user prompt | 11:07 |
| natefinch | rogpeppe: it's not just more, it's the fact that it's environment specific. You can't think you're destroying the test env when you're actually destroying production | 11:07 |
| natefinch | rogpeppe: no one reads | 11:07 |
| natefinch | rogpeppe: especially after the first couples times | 11:08 |
| rogpeppe | natefinch: we could potentially make it so that the -e flag is mandatory for destroy-environment | 11:10 |
| natefinch | rogpeppe: I had thought of that. That would be fine with me. | 11:10 |
| natefinch | rogpeppe: I'd be happy to do both, make the lock command and require -e. | 11:11 |
| rogpeppe | natefinch: (i'll just make a script, jujudestroy, which finds out the current env name and passes that as the -e arg :-]) | 11:12 |
| natefinch | rogpeppe: you're welcome to do that. Anyone can script a gun to shoot themselves in the foot... I just don't want juju to hand them one loaded with the safety off, in an ankle holster | 11:13 |
| rogpeppe | natefinch: the lock/nodestroy command is interesting, as it's not clear what we should do if you can't connect to the environment | 11:13 |
| rogpeppe | natefinch: if the environment instances have been destroyed, for example, we should still be able to destroy the environment | 11:14 |
| sinzui | natefinch, Did this branch also get merged into to trunk? https://code.launchpad.net/~natefinch/juju-core/fix-win-bootstrap/+merge/190461 | 11:14 |
| gary_poster | hey rogpeppe, I'm here (in mtgs but here) to discuss bug 1240708. Whether it is an issue in core (as I diagnosed) or gui (which is possible but seems unlikely to me), it's critical for gui | 11:14 |
| _mup_ | Bug #1240708: API server falls over repeatably during AllWatcher Next, killing GUI <juju-core:New> <juju-gui:Triaged> <https://launchpad.net/bugs/1240708> | 11:15 |
| natefinch | rogpeppe: that's a good point. Kinda hard to keep a central lock on the environment, when you might not be able to connect to the environment | 11:15 |
| rogpeppe | gary_poster: frankban seems to think it might be a problem on the gui server | 11:15 |
| natefinch | sinzui: hmm... lemme check | 11:15 |
| gary_poster | rogpeppe, ah! ok, will check with him thx | 11:15 |
| natefinch | sinzui: not in trunk. good catch, I'll move it over | 11:18 |
| sinzui | https://bugs.launchpad.net/juju-core/+bug/1240927 | 11:20 |
| _mup_ | Bug #1240927: os.rename does not wotk with windows <bootstrap> <windows> <juju-core:In Progress by natefinch> <juju-core 1.16:New> <https://launchpad.net/bugs/1240927> | 11:20 |
| sinzui | ^ natefinch your bug | 11:20 |
| TheMue | rogpeppe: just coming back from lunch and reading the log here I've seen your statement that destroying an environment isn't a big deal because everything can be deployed quite easy again | 12:12 |
| TheMue | rogpeppe: but how about lost data in that case | 12:12 |
| TheMue | rogpeppe: think of our typical blog example and kick you blog entries of the past two years -> ouch | 12:13 |
| TheMue | and that's one of the most harmless examples | 12:13 |
| jpds | Is juju aware of neutron security groups? | 12:19 |
| mgz | geh, hopefully internet is stable and alive for now | 13:29 |
| rogpeppe | mgz: i wondered why we didn't see you. has your internet been down? | 14:14 |
| mgz | yeah, went screwy for most of yesterday afternoon | 14:16 |
| mgz | seems okay now though at least | 14:16 |
| sinzui | rogpeppe, I see your merge into 1.16 branch. I updated two bugs that I think you will also want to update: https://bugs.launchpad.net/juju-core/+bug/1229275 and https://bugs.launchpad.net/juju-core/+bug/1081247 | 14:21 |
| _mup_ | Bug #1229275: [maas] juju destroy-environment also destroys nodes that are not controlled by juju <maas> <theme-oil> <juju:Triaged> <juju-core:In Progress by thumper> <juju-core 1.16:In Progress by rogpeppe> <juju-core (Ubuntu):Triaged> <maas (Ubuntu):Triaged> <juju-core (Ubuntu Saucy):Triaged> <maas (Ubuntu Saucy):Triaged> <https://launchpad.net/bugs/1229275> | 14:21 |
| _mup_ | Bug #1081247: maas provider releases all nodes it did not allocate [does not play well with others] <maas> <juju:Triaged> <juju-core:In Progress by julian-edwards> <juju-core 1.16:In Progress by rogpeppe> <MAAS:Invalid> <https://launchpad.net/bugs/1081247> | 14:21 |
| sinzui | rogpeppe, Are the bugs fix committed or in progress | 14:21 |
| rogpeppe | sinzui: the fixes are committed | 15:08 |
| sinzui | fab | 15:08 |
| rogpeppe | aargh, i wish i knew why my IRC client had suddenly stopped notifying me | 15:08 |
| sinzui | rogpeppe, any more bugs that need backporting? | 15:08 |
| natefinch | rogpeppe: I had the same problem with empathy not notifying me anymore | 15:08 |
| rogpeppe | sinzui: there are varying opinions on that | 15:09 |
| mgz | rogpeppe: but nothing else we urgently need asap after release, right? | 15:13 |
| mgz | just the question over whether most of what's on trunk should actually get into saucy too at some point | 15:14 |
| rogpeppe | mgz: i *think* so | 15:15 |
| sinzui | mgz I am looking for bugs that need to be backported before the 1.17.0 release. 1.17.0+ will be made available to saucy like our other series | 15:18 |
| mgz | sinzui: right. | 15:18 |
| rogpeppe | mgz: fancy spending an hour on the addressing stuff? | 15:19 |
| mgz | rogpeppe: sounds like a plan | 15:19 |
| sinzui | mgz, rogpeppe I really don't know if I should begin blessing 1.16 tip now. I see this bug that stakeholders may want backported https://bugs.launchpad.net/gomaasapi/+bug/1222671 | 15:20 |
| _mup_ | Bug #1222671: Using the same maas user in different juju environments causes them to clash <cts-cloud-review> <maas> <Go MAAS API Library:Fix Committed> <juju-core:Fix Committed by thumper> <https://launchpad.net/bugs/1222671> | 15:20 |
| rogpeppe | mgz: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1 | 15:20 |
| mgz | sinzui: I'm not sure what the status of that is, it required several changes to both juju and maas | 15:20 |
| sinzui | oh good. I think that disqualifies the bug | 15:21 |
| mgz | without both parts back, it doesn't make much sense to include the juju changes | 15:21 |
| sinzui | I believe SRUs must be limited to fixes to just the package | 15:21 |
| TheMue | off for today, cu tomorrow | 17:45 |
| mgz | rogpeppe: thanks, see you tomorrow | 17:54 |
| rogpeppe | mgz: ha, i pressed ^R in my web browser, not ^T | 17:54 |
| rogpeppe | mgz: so lost the connection | 17:54 |
| rogpeppe | mgz: cheers! | 17:54 |
| mgz | guessed that :) | 17:54 |
| rogpeppe | g'night all | 17:56 |
| narindergupta | i All I am trying to test the MAAS/JUJU from cloud tools from precise but stuck at know issue where mongodb with ssl was not installed. And mongodb listens on 27017 instead of 37017. Since i am using proxy so can not add the ppa of mongodb. If someone can tell me the ppa name for mongodb with ssl support for precise I can manually tried to update the mongodb and have bootstrap node working with juju-core? | 18:10 |
| jpds | Guys, how do I force juju to forget about a install hook lock? | 18:34 |
| jpds | I deployed service A, then service B, realized that I didn't need A, remove-unit'ed it, but now B's not moving because it still thinks A exists. | 18:36 |
| jpds | Oh, all on the same machine. | 18:38 |
| natefinch | jpds: sorry, I don't know, an this is kind of a dark time of the day for juju devs. Thumper should be coming online in the next hour or so. | 18:52 |
| jpds | natefinch: No worries. | 18:56 |
| wallyworld_ | thumper: a trivial goose review https://codereview.appspot.com/14769043 | 23:07 |
| wallyworld_ | and a small juju-core one https://codereview.appspot.com/14668044/ | 23:08 |
| thumper | +! | 23:08 |
| thumper | or 1 | 23:08 |
| wallyworld_ | you mean lgtm? | 23:08 |
| wallyworld_ | thanks :-) | 23:10 |
| thumper | done | 23:11 |
| thumper | I was going to be helping at the daughter's school's sports day | 23:11 |
| thumper | but rain cancelled it after two hours | 23:11 |
| thumper | so home agani | 23:11 |
| thumper | again | 23:11 |
| thumper | final trip prep... | 23:12 |
| thumper | and stuff | 23:12 |
| thumper | will be on and off irc periodically | 23:12 |
| wallyworld_ | me too | 23:12 |
| wallyworld_ | thanks | 23:12 |
| wallyworld_ | thumper: what do you mean multiple times? init() is only called once isn't it? | 23:13 |
| thumper | wallyworld_: but init() will be called for gwacl, goose, juju... | 23:14 |
| thumper | each one replacing the default in the http lib | 23:14 |
| wallyworld_ | that is true | 23:15 |
| wallyworld_ | but i'm not sure what can be done | 23:15 |
| thumper | but not really a big deal | 23:15 |
| wallyworld_ | yeah | 23:15 |
| * thumper shrugs | 23:15 | |
| thumper | I wouldn't bother | 23:15 |
| wallyworld_ | ok, will land :-) | 23:15 |
| * thumper takes a wet kid to school for the afternoon | 23:15 | |
| thumper | she doesn't wanna go | 23:15 |
| thumper | so I'm being a mean dad | 23:16 |
| wallyworld_ | hah | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!