| menn0 | wallyworld: thanks | 00:00 |
|---|---|---|
| wallyworld | menn0: actually, i don't have credentials for jujubot, i'll ask the qa guys | 00:02 |
| menn0 | wallyworld: I would have thought you could do it with your own account? | 00:05 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | menn0: that's don | 00:09 |
| wallyworld | e | 00:09 |
| wallyworld | menn0: yeah, i could, i didn't realise i could :-) | 00:10 |
| menn0 | wallyworld: cheers :) | 00:14 |
| wallyworld | np | 00:14 |
| wallyworld | menn0: fyi, i'm working on the status 2.0 spec based on notes from the sprint; still very much wip https://docs.google.com/a/canonical.com/document/d/19ljAmIe3wVC-jpDRFl8KfvJKQzx0HIC0yuPu3cCMh7Q | 00:19 |
| menn0 | wallyworld: having a quick look | 00:23 |
| === kadams54-away is now known as kadams54 | ||
| menn0 | wallyworld: looking good so far | 00:28 |
| menn0 | wallyworld: I made a few tiny typo corrections | 00:28 |
| wallyworld | menn0: oh ty, didn't mean to burden you just yet with corrections :-) | 00:29 |
| menn0 | wallyworld: I couldn't help myself :) | 00:29 |
| wallyworld | :-) | 00:29 |
| sinzui | wallyworld, Do you have minute to review http://reviews.vapour.ws/r/1497/ | 01:11 |
| wallyworld | sure | 01:12 |
| wallyworld | sinzui: you always give me the difficult ones | 01:12 |
| sinzui | wallyworld, its an opportunity for you to say STOP, I have another issue that needs fixing | 01:13 |
| wallyworld | sinzui: i left off the :-) | 01:14 |
| sinzui | :) | 01:14 |
| sinzui | wallyworld, http://reports.vapour.ws/releases/2570 shows that 1.23.2 Passed every test, even against adverse dirty substrates and flakey vivid | 01:25 |
| wallyworld | yay | 01:26 |
| sinzui | This is could be the highest score ever gotten | 01:26 |
| wallyworld | now all we need is for 1.24 to do the same | 01:26 |
| wallyworld | let's hope it's reproducable then | 01:28 |
| axw | wallyworld: reviewed your branch | 01:41 |
| wallyworld | ty | 01:41 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| wallyworld | axw: with the client facade, william didn't want to bump that beyond 0. the only other alternative is to introduce a whole new facade and stick the method on that. I started going down that path but couldn't decide on a suitable facade so took the path of least resistence (the branch was already big enough and i was trying to get it done in time before branching). given we already have AddMachinesV2, any proper refactoring work would | 01:47 |
| wallyworld | have to sort out that stuff also, which is getting beyond the scope of removing a storage feature flag | 01:47 |
| axw | wallyworld: why does he not want to bump the version? | 01:48 |
| wallyworld | gets messy - we would need to fire up api servers for both 0 and the new version, and we want to ultimately move stuff off client anyway | 01:50 |
| wallyworld | we support uniter v 0, 1, 2, but that's a much smaller facade | 01:50 |
| wallyworld | i was trying to avoid depending on a charm repo change with the patching but i guess that's unavoidable :-( | 01:50 |
| wallyworld | and even with the uniter stuff, the tests are incomplete as it's hard to write common tests to cover all facade versions | 01:51 |
| wallyworld | s/hard/tedious due to code cut and paste | 01:52 |
| axw | wallyworld: can we at least hide this ugliness in api/client? so if the caller of AddMachines specifies storage, it calls AddMachinesV3 instead of V2 | 01:55 |
| axw | wallyworld: not sure ify ou saw this before | 02:25 |
| axw | <axw> wallyworld: can we at least hide this ugliness in api/client? so if the caller of AddMachines specifies storage, it calls AddMachinesV3 instead of V2 | 02:25 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | axw: here's a patch to the charm repo to allow juju to patch the NewCharmStore from any package https://github.com/juju/charm/pull/123 | 03:10 |
| axw | wallyworld: ?! why? | 03:11 |
| axw | where is this needed? | 03:11 |
| wallyworld | axw: to allow core tests to run - stuff in the apiserver/service package calls into methods in apiserver/client and the apiserver/client code calls NewCharmRepo and this needs to be patched. the apiserver/client package patches NewCharmRepo but you objected to tha being exposed to apiserver/service package | 03:12 |
| axw | wallyworld: I object to patching across packages in general, not that one case | 03:13 |
| * axw looks at code in question | 03:14 | |
| wallyworld | so it's easier to just patch at the source of the charm repo creation instead of indirectly | 03:14 |
| wallyworld | axw: sadly we already patch charmrepo.CacheDir | 03:16 |
| wallyworld | so i'm at least lining up with what's done already | 03:16 |
| axw | yeah, I want to stop the sadness :) I'm looking if there's a better alternative.. | 03:17 |
| wallyworld | and the client code patches across packages anyway to patch charmrepo.NewCharmRepo | 03:17 |
| wallyworld | longer term, agreed. but this is simply to remove a feature flag to get 1.24 out | 03:17 |
| wallyworld | it's not introducing new badness | 03:18 |
| axw | wallyworld: service doesn't call into client, client calls into service | 03:18 |
| wallyworld | service calls s.APIState.Client().AddCharmWithAuthorization(curl, nil) | 03:18 |
| axw | client previously *internally* patched that function, which isn't great but at least doesn't spread the hack around | 03:18 |
| wallyworld | to set up a test | 03:18 |
| * axw looks again | 03:18 | |
| axw | I see | 03:19 |
| wallyworld | yes it did, but any code can also patch cahrmrepo.CahedDir | 03:19 |
| wallyworld | this is a consequence of starting to move service apis off the client facade | 03:20 |
| wallyworld | and onto their own Service facade | 03:20 |
| wallyworld | there's a whole bunch of other service apis with todos to move | 03:20 |
| wallyworld | sadly, it we designed our code using inversion of control, this wouldn't be an issue, but we didn't :-( | 03:21 |
| axw | wallyworld: this can be fixed by changing apiserver/service to operate on interfaces rather than *state.State. getting out of scope, so please ditch the juju/charm change and use the original patch change and add a TODO(wallyworld) | 03:24 |
| axw | if we're adding hacks, let's at least confine them to juju/juju | 03:25 |
| anastasiamac | axw: wallyworld: on a different note, here is the start of dynamic add - http://reviews.vapour.ws/r/1498/ | 03:27 |
| axw | anastasiamac: reviewing now | 03:49 |
| anastasiamac | axw: tyvm :D | 03:49 |
| axw | anastasiamac: done | 03:55 |
| wallyworld | axw: so, just to confirm you happy to retain the x-package patching as per what i submitted so that we don't have to modify charm.v5? that was my original thought and rationale also | 04:15 |
| wallyworld | axw: FFS, disconnected again, may have missed your reply | 04:22 |
| axw | wallyworld: sorry, was afk. yes. | 04:48 |
| axw | wallyworld: provided it gets replaced later with an interface and the cross-package patching removed | 04:49 |
| wallyworld | axw: yeah, there's a bit of work to do there. won't happen for 1.24 is suspect, best we can do is 1.25. i've updated the PR on RB | 04:51 |
| axw | looking | 04:51 |
| wallyworld | axw: i guess i should add a MachineManager facade and stuck the new AddMachine API on that. i was previously trying to avoid missing the 1.24 branching but given that's already happened, might be best not to introduce another lagacy API to have to support | 05:28 |
| axw | wallyworld: that would be ideal | 05:29 |
| wallyworld | yeah, agreed. sigh. branch already soo bg | 05:30 |
| axw | wallyworld: I already gave a shipit, you don't have to do it immediately | 05:31 |
| wallyworld | axw: ok, i'll land but then do an immediate followup | 05:31 |
| axw | cool | 05:31 |
| axw | wallyworld: is that a straight backport? do I need to review again? | 05:39 |
| mup | Bug #1449367 was opened: remove storage feature flag <juju-core:Triaged by wallyworld> <juju-core 1.24:In Progress by wallyworld> <https://launchpad.net/bugs/1449367> | 05:43 |
| mup | Bug #1449367 changed: remove storage feature flag <juju-core:Triaged by wallyworld> <juju-core 1.24:In Progress by wallyworld> <https://launchpad.net/bugs/1449367> | 05:49 |
| mup | Bug #1449367 was opened: remove storage feature flag <juju-core:Triaged by wallyworld> <juju-core 1.24:In Progress by wallyworld> <https://launchpad.net/bugs/1449367> | 05:55 |
| === rawang is now known as Guest64369 | ||
| mup | Bug #1449390 was opened: storage: charms must wait for storage to be attached before running "install" hook <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1449390> | 07:07 |
| === rogpeppe2 is now known as rogpeppe | ||
| TheMue | voidspace: sorry for not being in hangout, have to help daughter | 09:02 |
| voidspace | TheMue: no problem | 09:03 |
| voidspace | TheMue: it's just you and me anyway :-) | 09:03 |
| voidspace | TheMue: I'm working on forward porting the addressable container feature flag to master | 09:03 |
| voidspace | TheMue: nearly done | 09:03 |
| voidspace | TheMue: hard work - just about none of the patch applied cleanly | 09:03 |
| voidspace | TheMue: only two more files to do though | 09:03 |
| voidspace | TheMue: that's my report :-) | 09:03 |
| mup | Bug #1449436 was opened: Environment variables are not propagated to jujud on vivid <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:Triaged by axwalk> <https://launchpad.net/bugs/1449436> | 09:13 |
| TheMue | voidspace: so, "first aid" done, daughter has troubles with her car on the highway and asked what to do. and the other daughter is ill at home. :( | 09:14 |
| TheMue | voidspace: I'm currently writing a little conference report about last week, the continue with the process changes with Katherine, and will then take a look in the list Dimiter sent | 09:15 |
| voidspace | TheMue: ok | 09:22 |
| mup | Bug #1449436 changed: Environment variables are not propagated to jujud on vivid <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:Triaged by axwalk> <https://launchpad.net/bugs/1449436> | 09:25 |
| mup | Bug #1449436 was opened: Environment variables are not propagated to jujud on vivid <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:Triaged by axwalk> <https://launchpad.net/bugs/1449436> | 09:31 |
| axw | jam: gotta go, fix up for review here FYI -- http://reviews.vapour.ws/r/1500/ | 10:19 |
| jam | axw: have a good night | 10:19 |
| jam | axw: I believe this should also go into 1.23, right? | 10:19 |
| jam | Since that is what we're actually releasing on V | 10:19 |
| Mmike | lads, when I bootstrap my env and then do 'juju ensure-availability', juju will fire up additional three units, set up replicaset for mongodb and all of that. Now when unit 0 dies (the initial bootstrap unit) I can't connect to my env any more. I need to manually change my environment.jenv file and remove references to machine 0 from there. Then juju works ok again. Now I want to remove machine 0 from juju, as it no longer exists, but juju won't let me | 10:21 |
| Mmike | do so, saying: "ERROR no machines were destroyed: machine 0 is required by the environment". | 10:21 |
| Mmike | Is this by design, or am I doing something wrong? | 10:21 |
| Mmike | Using juju 1.22 currently, but observed same behaviour on 1.23 | 10:21 |
| natefinch | hooooly shit. just went to write a fake object to fulfill the CloudConfig interface, and umm.. it has over 60 functions :/ | 10:22 |
| davecheney | that's no interface .... mother of god! | 10:29 |
| davecheney | Mmike: machine 0 is special, it cannot be removed | 10:29 |
| natefinch | luckily the function I need to mock it for only uses like 6 of those functions, so I can replace the interface with a more narrow one, but still, jeezus. | 10:30 |
| natefinch | davecheney, Mmike: you definitely should be able to kill machine 0 and have your environment still work fine. | 10:31 |
| natefinch | (when in HA) | 10:31 |
| natefinch | I don't know about actually tell juju to remove the phantom machine from its DB, but your environment should definitely still work. | 10:32 |
| jam | natefinch: seems a bit oversized. Though you can do ttype | 10:33 |
| jam | type MyFake struct { CloudConfig } | 10:33 |
| jam | and then only override the ones you actually want to | 10:33 |
| jam | (you'll get nil pointer dereference failures for anything that gets used that you didn't define) | 10:33 |
| jam | Mmike: so I'd like to walk through it a bit with you. | 10:33 |
| jam | After "juju ensure-availability" do you end up with 3 or 4 total machines? | 10:33 |
| jam | (I would expect 3) | 10:33 |
| jam | second, after those machines are up and running, you should be able to run "juju status", and connect to that env | 10:33 |
| jam | and then it will notice that there are more machines | 10:33 |
| jam | and record them as alternatives in your environments.jen | 10:33 |
| jam | It won't actually record new machines until they are up and running and connected (AIUI) | 10:33 |
| jam | but you shouldn't have to edit your JENV normally | 10:33 |
| jam | just you have to connect to the environment once the extra machines are running. | 10:33 |
| jam | Mmike: third, after machine-0 has died, you probably need to run "juju ensure-availability" again, where it should now notice that you have a dead machine, and try to take it out of official API server status | 10:33 |
| jam | (this is a bit of a wart, and we're looking at splitting up ensure-ha into more precise commands) | 10:33 |
| jam | and then you can "juju destroy-machine machine-0" (sp?) | 10:33 |
| jam | once it has lost its voting status | 10:33 |
| Mmike | jam: i see | 10:34 |
| Mmike | jam: let me try that | 10:34 |
| natefinch | jam: good idea embedding the interface in the struct | 10:35 |
| === natefinch is now known as natefinch-afk | ||
| perrito666 | morning all | 10:50 |
| Mmike | jam: where can I find the password jujud is using to connect to mongod? | 10:55 |
| jam | Mmike: you have to look on machine-0 for it, it should be in /var/lib/juju/agents/machine-0/agent.conf I think | 11:03 |
| jam | Mmike: sorry, looks like "/var/lib/juju/agents/machine-0.conf" | 11:03 |
| Mmike | jam: ack, thnx | 11:05 |
| perrito666 | nope /var/lib/juju/agents/machine-0/agent.conf | 11:05 |
| perrito666 | jam: unlest it changed | 11:05 |
| jam | perrito666: that's what I originally thought, but our backups test disagree | 11:05 |
| jam | perrito666: ./state/backups/files_test.go:114: filepath.Join(s.root, "/var/lib/juju/agents/machine-0.conf"), | 11:06 |
| Mmike | jam: actually on 1.22 it's in /var/lib/juju/agents/machine-0/agent.conf | 11:06 |
| Mmike | just verified | 11:06 |
| perrito666 | jam: ill remember to ping eric on that one | 11:06 |
| jam | perrito666: k. That sounds suspiciously like its a bad test. | 11:07 |
| jam | perrito666: but "cmds/juju-restore" does use /var/lib/juju/agents/machine-0/agent.conf | 11:08 |
| perrito666 | jam: it is | 11:08 |
| perrito666 | jam: looking at the code that it is testing it does not really matter since that seems the result of faking a glob result | 11:08 |
| perrito666 | but is missleading | 11:08 |
| jam | perrito666: yeah, I'm not saying the test doesn't pass, but we shouldn't have incorrect paths in a backup test :) | 11:09 |
| perrito666 | I have opened and restored that files enought times to know it is named agent.conf :p | 11:09 |
| * perrito666 makes a note for a less urgent time | 11:09 | |
| jam | perrito666: :) | 11:10 |
| jam | yeah, I would guess you did | 11:10 |
| dimitern | voidspace, ping | 11:17 |
| jam | Mmike: did you get things to work? | 11:34 |
| Mmike | jam: nope, not yet, my openstack deploy is a bit slow as I'm testing some other stuff too, so it takes time... | 11:34 |
| jam | Mmike: np | 11:34 |
| jam | just curious | 11:35 |
| Mmike | jam: yup, have a case about that, so I need to know how it works | 11:35 |
| Mmike | and for convenience too :) | 11:35 |
| dimitern | fwereade, http://reviews.vapour.ws/r/1501/ | 11:37 |
| jam | dimitern: is it actually allowed to start with - or _ | 11:38 |
| jam | ? | 11:38 |
| dimitern | jam, it is in fact | 11:38 |
| dimitern | jam, rvba just confirmed that | 11:39 |
| jam | dimitern: is there any reason not to be slightly more restrictive than them? | 11:40 |
| jam | I think avoiding opening "-" is probably a good thing | 11:40 |
| dimitern | jam, apart from another critical blocker from OIL | 11:40 |
| dimitern | can't think of one :) | 11:40 |
| dimitern | in case they now decide to have names like "-my_NET" | 11:41 |
| fwereade | dimitern, jam: so the core of the problem is that we use provider ids as network names | 11:41 |
| fwereade | dimitern, jam, which means we need to come up with a regexp that matches every possible valid provider network id | 11:42 |
| dimitern | fwereade, jam, yeah, that's the crux of it; but it's much harder to fix it properly | 11:42 |
| fwereade | dimitern, jam, but is still somehow useful | 11:42 |
| dimitern | fwereade, jam, also, fwiw this only applies to maas anyway now | 11:42 |
| fwereade | dimitern, jam: with that patch, can we still transform name<->tag safely? | 11:44 |
| fwereade | dimitern, jam: and can we depend on correctly munging globallKeys? | 11:44 |
| dimitern | fwereade, jam, yes - there are tests for that in fact, which didn't stop passing, and we don't allow / | 11:44 |
| jam | or # right? | 11:44 |
| dimitern | yeah | 11:44 |
| Mmike | jam: so, here is what I did: juju bootstrap; juju ensure-availability. Then I did 'juju status' until I had all three machines with "state-server-member-status: has-vote". Then I deployed some service (percona-cluster, with 3 units). | 12:04 |
| Mmike | Waited for that service to settle down, verified all is ok. | 12:05 |
| Mmike | After that I killed the machine 0 (as this is openstack, I did nova delete $instance_id). Did juju status after that, waited for like 2-3 minutes, and then juju status returned status with machine0 being down. | 12:05 |
| Mmike | Also, some percona-cluster units where shown as 'agent-state: down'. | 12:05 |
| jam | Mmike: 2-3 minutes sounds odd to me | 12:05 |
| jam | Mmike: one option is to use "juju status --verbose" (-v) which should have it report what its trying to do | 12:06 |
| jam | is it still 2-3 min per status? | 12:06 |
| jam | or is status fast now? | 12:06 |
| Mmike | Then I did juju ensure-availability, juju instantiated another machine. Waited for that one to have 'state-server-member-status: has-vote'. Then did: "juju destroy-machine 0", but juju complained about 'machine 0 being needed for the env' | 12:07 |
| Mmike | no, it is fast now | 12:07 |
| Mmike | just the first run after I killed machine 0 was slow. | 12:07 |
| Mmike | ok, now all of my percona-cluster units are up, and marked ok (no more 'agent-state: down'). | 12:08 |
| Mmike | But I still can't remove machine 0. | 12:08 |
| jam | Mmike: can you pastebin the "juju status" output ? | 12:09 |
| Mmike | sure | 12:09 |
| Mmike | jam: http://pastebin.ubuntu.com/10924694/ | 12:10 |
| Mmike | jam: I can paste whole termlog from the first bootstrap, if needed | 12:10 |
| jam | Mmike: so i *believe* that now that machine-0 has been removed from voting, you can do another "juju ensure-availability" and it will be removed as a state server entirely, and then you can "juju destroy-machine machine-0" | 12:11 |
| * Mmike tries | 12:12 | |
| jam | I think each transition needs another ensure-availability call. starts with has-vote, then goes to no-vote, then goes to no-longer-a-state-server | 12:12 |
| Mmike | jam: ack, confirmed. | 12:13 |
| Mmike | jam: excellent! :) | 12:13 |
| Mmike | jam: thank you very much | 12:13 |
| Mmike | just one more, though | 12:13 |
| Mmike | so let's say I had 3 state machines. One of them died. Then another died. Now mongodb on remaining unit is in readonly state. | 12:13 |
| Mmike | I don't have juju backup. | 12:14 |
| Mmike | I'm thinking, then, connecting to the remaining machine, and 'reseting' mongodb - forcing it to become primary again. | 12:14 |
| Mmike | Will that work? That is, will I be able to use juju afterwards? | 12:14 |
| Mmike | (Havent tried, just curious) | 12:14 |
| jam | Mmike: so if you manually poke the replicaset document in mongo | 12:15 |
| jam | you should be able to do anything you want :) | 12:15 |
| jam | just don't do it wrong. | 12:15 |
| jam | obviously with db surgery you can make anything work. I'm not 100% sure how much Juju would let you get away with, because it will likely try to write the replicaset document to match its own state | 12:15 |
| Mmike | well, obviously the 'right thing to do' is to have backups. | 12:16 |
| Mmike | But, there being only two kinds of people in the world... sooner or later I'll have to deal with 'we WILL be doing backups' kind of people :) | 12:17 |
| Mmike | jam: thnx for the inputs, will try breaking my env later again to verify if poking with mongo will bring it back to life | 12:17 |
| jam | Mmike: have you verified that Juju becomes completely unhappy with 2 machines down? | 12:18 |
| jam | It is *possible* that "juju ensure-availability" would rewrite things to try and get back into 3-man mode. | 12:18 |
| jam | but I can entirely believe that we didn't get there. | 12:18 |
| jam | And IIRC, we don't support "juju ensure-availability -n1" to get back out of HA mode | 12:18 |
| Mmike | jam: nop, tbh. But I know from previous mongodb experience that if two nodes go down the last remaining node is in read-only, as it has no quorum. | 12:19 |
| jam | Mmike: but being able to get a DB backup at that point seems *really useful* | 12:19 |
| === rawang is now known as Guest89813 | ||
| * perrito666 uses deployer for the first time ever | 13:05 | |
| === rawang is now known as Guest7759 | ||
| === natefinch-afk is now known as natefinch | ||
| === kadams54 is now known as kadams54-away | ||
| katco | natefinch: standup | 14:02 |
| aznashwan | natefinch: ping | 14:03 |
| natefinch | aznashwan: sup? | 14:04 |
| === kadams54-away is now known as kadams54 | ||
| aznashwan | natefinch: sorros | 14:13 |
| aznashwan | natefinch: got distracted | 14:13 |
| aznashwan | natefinch: could give me an idiot's guide to using that perl script for syscalls on windows? | 14:14 |
| === urulama is now known as urulama__ | ||
| aznashwan | natefinch: (if you could exemplify on your npipe package what the result should be; that would be awesome) | 14:15 |
| * perrito666 drops a bucket of debug messages onto deployer | 14:50 | |
| natefinch | aznashwan: all I really did was look at the files in the syscall stdlib and copy what they did there. The zsyscall_* files give the command line to use, and show the input file, which contains the patterns that generate the syscalls in comments at the top of the file. | 14:55 |
| natefinch | aznashwan: I meant to write a blog post about how to do it back when I wrote npipe, but never got around to it. I should brush up on it and do so, it would be pretty useful, I think. | 14:55 |
| voidspace | dimitern: just FYI, I merged the tests as well | 14:59 |
| voidspace | dimitern: that was easier | 14:59 |
| voidspace | dimitern: I have a bunch of failing tests to fix now | 14:59 |
| voidspace | dimitern: not all obvious, but I'll work through them | 15:00 |
| dimitern | voidspace, sweet! | 15:01 |
| voidspace | dimitern: hey, we have a test "TestNewCloudInitConfigNoFeatureFlag" | 15:05 |
| voidspace | dimitern: testing maas config generation | 15:05 |
| voidspace | https://github.com/juju/juju/compare/master...voidspace:addressable-featureflag | 15:05 |
| mattyw | jam, are you around this week? | 15:05 |
| voidspace | (the first s.SetFeatureFlags() in that branch is spurious I assume - and I've removed it locally) | 15:05 |
| voidspace | dimitern: the intent of the test seems to be to test we get the same config with feature flag on and off | 15:06 |
| voidspace | dimitern: but we don't | 15:06 |
| voidspace | dimitern: we get the juju-br0 stuff when the flag is off | 15:06 |
| jam | mattyw: I'm around | 15:06 |
| voidspace | dimitern: so the test seems flawed (and is failing for this reason) | 15:06 |
| jam | though its EOD for me now | 15:06 |
| mgz_ | dimitern: I failed to find you in person, but can I have a review please? :) | 15:07 |
| mgz_ | dimitern: https://github.com/go-goose/goose/pull/8/files | 15:07 |
| mup | Bug #1449613 was opened: service/windows is missing unit tests. <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1449613> | 15:08 |
| mgz_ | katco: can I wave bug 1447841 at you? | 15:20 |
| mup | Bug #1447841: eu-central-1 AWS region V4 signing required and not supported <ec2-provider> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1447841> | 15:20 |
| katco | mgz_: sure tal | 15:24 |
| katco | mgz_: should be an easy fix | 15:25 |
| natefinch | perrito666: review please? http://reviews.vapour.ws/r/1504/ | 15:27 |
| mup | Bug #1449617 was opened: service.Service implementations are missing functional tests. <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1449617> | 15:32 |
| perrito666 | natefinch: reviewed, just one issue | 15:33 |
| dimitern | vo | 15:35 |
| katco | mgz_: very small review for that bug: http://reviews.vapour.ws/r/1505/ | 15:35 |
| dimitern | voidspace, hey | 15:35 |
| mgz_ | pants, we have in fact not yet switched to gopkg.in goose yet | 15:36 |
| dimitern | voidspace, why is that happening can be gnarlly - check basically jujuconnsuite's setupsuite and setuptest - there might be something overriding the set FF | 15:37 |
| mgz_ | katco: change lgtm - no tests need updating? also, s3 auth works with the same auth object as ec2 okay? | 15:38 |
| mgz_ | I'm confident our testing will fail fast if anything is wrong | 15:38 |
| katco | mgz_: yeah s3 defaults to v4, we deprecated v2 signing for s3 | 15:39 |
| katco | mgz_: i haven't run tests, let me do that rq for just the ec2 provider package | 15:39 |
| katco | mgz_: those tests pass. i'll try and land and see what happens | 15:40 |
| alexisb | ericsnow, as always thank you! | 15:43 |
| mup | Bug #1449633 was opened: Cannot terminate/remove broken state server after ensure-availability <cts> <juju-core:New> <https://launchpad.net/bugs/1449633> | 15:44 |
| mgz_ | should we be sorting external import alphanum-wise? what can I use to do that? | 15:46 |
| mgz_ | hm, seems not, I have github.com and gopkg.in both ways round | 15:47 |
| natefinch | mgz_: go fmt will alphabetize | 15:49 |
| natefinch | mgz_: it sorts each section independently (where a section is delimited by blank lines) | 15:50 |
| natefinch | perrito666: thanks | 15:55 |
| perrito666 | np | 15:55 |
| mup | Bug #1449633 changed: Cannot terminate/remove broken state server after ensure-availability <cts> <juju-core:New> <https://launchpad.net/bugs/1449633> | 15:56 |
| mgz_ | natefinch: yeah, I was wondering about sorting the blocks after that - which we seem not to do | 15:58 |
| natefinch | mgz_: go fmt definitely sorts all the blocks... try it out here: http://play.golang.org/p/lb4Nc0Nz2B the blocks are intentionally out of order to start | 16:01 |
| mup | Bug #1449633 was opened: Cannot terminate/remove broken state server after ensure-availability <cts> <juju-core:New> <https://launchpad.net/bugs/1449633> | 16:02 |
| katco | perrito666: hey do you need any help with 1441826? | 16:02 |
| perrito666 | katco: I think I just nailed it :) | 16:03 |
| katco | perrito666: course you did... bc you're AWESOME ;p | 16:04 |
| natefinch | perrito666: nice | 16:04 |
| perrito666 | I am writing the patch now to see if it works, but apparently its a shim missing in the multiwatcher status | 16:04 |
| === kadams54 is now known as kadams54-away | ||
| mgz_ | ocr: can I request another review on http://reviews.vapour.ws/r/1473/ | 16:16 |
| mgz_ | I needed to bump goose version (and location) to add a test) | 16:17 |
| perrito666 | mm, that is a nasty thing to read on reviewboard | 16:21 |
| mgz_ | perrito666: blame Ian | 16:22 |
| perrito666 | ok | 16:22 |
| perrito666 | git blame ian | 16:22 |
| mgz_ | it was a nice clean change till I had to update all the imports | 16:22 |
| * perrito666 impatiently awaits for his stream to update | 16:23 | |
| * perrito666 reads in github and gets a pill for the headache | 16:23 | |
| mgz_ | perrito666: looking at each commit in turn may be more informative | 16:24 |
| perrito666 | mgz_: do you arrange your tests in lexicographic order? | 16:25 |
| === kadams54-away is now known as kadams54 | ||
| mgz_ | perrito666: I arrange them in random walk order | 16:29 |
| perrito666 | mgz_: brb, will review upon return, I promise | 16:31 |
| mgz_ | perrito666: no problem | 16:32 |
| mgz_ | I'm off for now at least | 16:32 |
| aznashwan | natefinch: sorry; got carried away again... | 16:34 |
| natefinch | aznashwan: did you see my prior responses? | 16:34 |
| aznashwan | natefinch: figured it out; it's quite handy | 16:35 |
| aznashwan | natefinch: yes I did | 16:35 |
| natefinch | aznashwan: ahh cool. Yeah. it's nice. | 16:35 |
| aznashwan | natefinch: I used the go one in the syscall package | 16:35 |
| aznashwan | natefinch: they should really raise awareness for it | 16:35 |
| natefinch | aznashwan: yeah, I remembered they added a go version finally... after I had to struggle with installing perl on windows ;) | 16:36 |
| aznashwan | natefinch: oh; it's yours? | 16:36 |
| aznashwan | natefinch: Windows salutes you :D | 16:36 |
| natefinch | aznashwan: no no... I was sorely tempted to port it, but never found the time. Not sure who did, but not me :) | 16:37 |
| aznashwan | natefinch: works great; but there was a lot a lot of guesswork involved in figuring out how to use it for procs' that weren't in kernel32 | 16:39 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| katco | perrito666: how is the bug coming? | 19:10 |
| perrito666 | katco: fixed It looks, fixing the tests now | 19:11 |
| katco | perrito666: awesome :) | 19:11 |
| perrito666 | mmpf I am pretty sure network manager indicator has less functions than before :( I dont seem to be able to priorize my connections | 19:14 |
| === kadams54 is now known as kadams54-away | ||
| perrito666 | talk about useful test failure errors | 19:59 |
| perrito666 | Error: entity mismatch; got len 1; want 1 | 19:59 |
| natefinch | perrito666: heh wow | 20:05 |
| katco | natefinch: hey is https://bugs.launchpad.net/juju-core/+bug/1446871 landed yet? | 20:09 |
| mup | Bug #1446871: Unit hooks fail on windows if PATH is uppercase <ci> <hooks> <windows> <juju-core:In Progress by natefinch> <juju-core 1.24:In Progress by natefinch> <https://launchpad.net/bugs/1446871> | 20:09 |
| natefinch | katco: I hadn't thought it was targetted at 1.24-alpha1, so I just have a PR up against master, which is blocked... but I could easily put it on 1.24 instead | 20:11 |
| natefinch | katco: so, no :) | 20:11 |
| katco | Nate looks like it's just targeted against 1.24 | 20:12 |
| katco | natefinch: mgz was working on https://bugs.launchpad.net/juju-core/1.24/+bug/1441826 but it's past his EoD... we're blocked until that is complete | 20:12 |
| mup | Bug #1441826: deployer and quickstart are broken in 1.24-alpha1 <api> <blocker> <ci> <deployer> <quickstart> <regression> <juju-ci-tools:Triaged> <juju-core:Triaged by hduran-8> <juju-core 1.24:In Progress by hduran-8> <https://launchpad.net/bugs/1441826> | 20:12 |
| katco | natefinch: looks like you might have had some insight there, so if you are blocked, it would be a good thing to look into | 20:13 |
| natefinch | katco: I can certainly look at that one, though I thought perrito666 had that one handled | 20:13 |
| katco | natefinch: i thought he was looking at https://bugs.launchpad.net/juju-core/+bug/1441826? | 20:14 |
| mup | Bug #1441826: deployer and quickstart are broken in 1.24-alpha1 <api> <blocker> <ci> <deployer> <quickstart> <regression> <juju-ci-tools:Triaged> <juju-core:Triaged by hduran-8> <juju-core 1.24:In Progress by hduran-8> <https://launchpad.net/bugs/1441826> | 20:14 |
| katco | gah... stupid copy/paste mistake | 20:14 |
| perrito666 | katco: you have a problem with your pastebin? | 20:14 |
| katco | haha | 20:14 |
| perrito666 | you sound just like the error I pasted a moment ago | 20:14 |
| katco | natefinch: i meant https://bugs.launchpad.net/juju-core/+bug/1440940 | 20:14 |
| mup | Bug #1440940: xml/marshal.go:10:2: cannot find package "encoding" <blocker> <ci> <regression> <test-failure> <juju-core:In Progress by gz> <juju-core 1.24:Triaged> <juju-release-tools:In Progress by gz> <https://launchpad.net/bugs/1440940> | 20:14 |
| natefinch | oh yeah that one | 20:14 |
| katco | natefinch: perrito666 is definitely working the other one | 20:14 |
| katco | natefinch: but mgz thought he had a fix, but apparently not | 20:15 |
| natefinch | katco: I'll look through what has been posted there since I last looked at the bug. | 20:15 |
| katco | natefinch: cool ty | 20:15 |
| katco | wwitzel3: are you blocked on 1326091? | 20:15 |
| natefinch | sinzui: you around? | 20:20 |
| sinzui | I am | 20:20 |
| natefinch | in the above bug about encoding, one of your recent messages contains a typo that makes it hard for me to understand: "The release tarfile but contain the encoding src or pkg, or we avoid using github.com/juju/govmomi/vim25/xml." | 20:20 |
| sinzui | natefinch, *must* | 20:21 |
| natefinch | sinzui: ahh, ok, I couldn't figure out what it was supposed to be | 20:21 |
| sinzui | natefinch, mgz advised that including the encoding package in the source tree would ensure gccgo found the package. He reported it was fixed but is not. The packages don't build and I don't see the package, so I don't know what mgz changed to lead him to believe the issue was fixed | 20:22 |
| sinzui | damn, too many uses of the word packages | 20:22 |
| sinzui | We cannot make debs, and I don't see "encoding" in src/ | 20:23 |
| natefinch | sinzui: it seems odd to me that we package up the standard library in our tarfile. shouldn't the standard library just be installed on the target machine, and we just tar-up what's outside the stdlib? I presume ubuntu doesn't build other languages by including the stdlib in the tar we give the builders. | 20:25 |
| natefinch | (and I'm using a very broad version of "installed" .... I don't actually care how it arrives on disk) | 20:26 |
| sinzui | natefinch, it seem odd to me we would fork xml and use it without checking it worked on all arcs | 20:27 |
| sinzui | regardless, *we* are obligated to deliver a tarball that Ubuntu and Lp can build ppc64el debs. so need to provide a version of encoding that work with that xml package | 20:27 |
| natefinch | sinzui: I guess my question would be... why isn't the entire go std library on the builder? Is it because there's no golang package we can apt-get install for PPC64el that we don't do it that way? | 20:29 |
| sinzui | natefinch, Ubuntu/debian uses shared lib and they are already built and distributed for Juju to link too | 20:30 |
| sinzui | natefinch, juju is *not* 100% static for ppc. it uses golib5 | 20:30 |
| natefinch | sinzui: I don't know what that is, unfortunately. | 20:30 |
| sinzui | natefinch, a lib that doesn't have encoding in it, at least, not by that name | 20:31 |
| natefinch | sinzui: where do we get golib from? google isn't being very helpful for me there | 20:32 |
| sinzui | well I can see there is an encoding, but it doesn't match what the xml package wants :( | 20:32 |
| sinzui | natefinch, I think you are taking the wrong path here | 20:32 |
| sinzui | natefinch, We will not release any 1.24 version in the next month if we are trying to bet debian/ubuntu to change packages. mgz's solution is to include just what is needed to satisfy debian packaging rules | 20:33 |
| natefinch | sinzui: we're getting an error that should be impossible. The most likely reason is because we're doing things in weird ways to satisfy people's ideas of the way things should be built. I'm just trying to figure out how this builder differs from what happens when I run gccgo. | 20:34 |
| natefinch | sinzui: if I can't look at golib, I can't figure out why its encoding is different | 20:34 |
| natefinch | sinzui: or how to fix it | 20:34 |
| natefinch | (it/us/whatever) | 20:35 |
| sinzui | natefinch, https://launchpad.net/ubuntu/+source/gccgo-go | 20:36 |
| sinzui | natefinch, I think trusty used http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/gccgo-go/trusty-proposed/files | 20:37 |
| sinzui | natefinch, but you are entering into packaging and linking in debian/gccgo which is not like golang | 20:38 |
| natefinch | sinzui: so, I do see the encoding directory and encoding.go under src/pkg: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/gccgo-go/trusty-proposed/files/head:/src/pkg/encoding/ | 20:40 |
| sinzui | natefinch, yes, we established that a few weeks ago | 20:41 |
| sinzui | natefinch, the recent change here is that go build to make packages was working, now it doesn't So the hack to create a goroot on the test machines wont work in the clean-room env used by builders | 20:43 |
| natefinch | sinzui: I'm more than willing to help, and I'm sorry if I get frustrated. There's a lot of the packaging part, especially for gccgo, that I still don't know well, so trying to figure out why something is going wrong is difficult without preloading a lot of knowledge. | 20:50 |
| katco | natefinch: sinzui: it seems extraordinarily hazardous to me that we would patch the go stdlib to include an entire package | 20:50 |
| katco | natefinch: sinzui: seems like we could get unexpected behavior quite easily, doesn't it? | 20:50 |
| natefinch | katco: we forked the xml package. I would not say we were patching the std lib at all. we copied the xml package to github.com/juju/xml and reference it as a normal 3rd party package | 20:51 |
| natefinch | katco: the problem seems to be that we're using any package that itself depends on the encoding package. | 20:51 |
| katco | natefinch: that doesn't have a dependency graph that spiders out into other parts of the go stdlib? | 20:51 |
| natefinch | katco: it should be exactly the same as if we just imported the xml package | 20:52 |
| sinzui | natefinch, I found 3 changes between the the time we could make packages and when we couldn't mgz made two of them https://bugs.launchpad.net/juju-core/+bug/1440940/comments/15 | 20:52 |
| mup | Bug #1440940: xml/marshal.go:10:2: cannot find package "encoding" <blocker> <ci> <regression> <test-failure> <juju-core:In Progress by gz> <juju-core 1.24:Triaged> <juju-release-tools:In Progress by gz> <https://launchpad.net/bugs/1440940> | 20:52 |
| katco | natefinch: well, what i'm getting at is we're using version X of the xml package with version Y of the rest of the go stdlib | 20:53 |
| katco | natefinch: and i'm wondering if that might introduce unintended consequences | 20:53 |
| natefinch | katco: it shouldn't matter, because the only code using our XML package is code we specifically wrote to use it. It should either compile on all platforms or not. | 20:54 |
| katco | natefinch: compilation =/= proof of correctness | 20:54 |
| natefinch | katco: but if the problem is a compilation error.... | 20:54 |
| katco | natefinch: this particular problem; i'm questioning the larger strategy | 20:54 |
| sinzui | natefinch, the xml package *did* compile a week ago. When only tests were broken I assumed it was test-double nonsense from gccgo | 20:55 |
| natefinch | katco: it's really conceptually no different than forking any other package and using it instead of the original. the stdlib isn't special, it's just normal go code. | 20:55 |
| katco | natefinch: correct, but the version of the xml package we've imported was written to depend on perhaps a different version of the go stdlib | 20:56 |
| katco | natefinch: what i'm getting at is: we're mucking with dependencies in a very non sustainable way | 20:56 |
| natefinch | katco: there's no version of the stdlib that doesn't have the encoding package, though | 20:57 |
| natefinch | katco: also, the stdlib is guaranteed backwards compatible to go1.0 and they're very strict about it | 20:57 |
| natefinch | I think looking at sinzui's list of commits that might have broken it is a good way to tackle the problem. IN theory, something should stand out. | 20:58 |
| katco | natefinch: from a signature perspective... not implementation | 20:58 |
| katco | natefinch: this line of questioning is probably irrelevant at this point, i'll drop it | 20:58 |
| natefinch | sinzui: is it possible to re-run the last test that worked? To rule out environmental / process changes? | 20:59 |
| katco | natefinch: but wow will this get messy fast | 20:59 |
| natefinch | sinzui, katco: unfortunately, I'm at EOD. I may be able to get online significantly later (9pm-ish eastern), but may not, depending on the state of my kids. | 21:00 |
| katco | natefinch: hope everyone feels better, and hope the appt. went well today | 21:00 |
| natefinch | I think it's worth going through the code changes to look for things that stand out ,and also doing a double check to make sure that the last run that worked still works. | 21:00 |
| natefinch | katco: thanks | 21:00 |
| sinzui | natefinch, not in CI since the job is publishing. But in this case, this is the actual packaging rules. anyone can take the release tarball, make a source package from the packaging branch, and then build it (on ppc | 21:01 |
| sinzui | ) | 21:01 |
| sinzui | natefinch, note that building happens in fakeroot, so changes cannot just happen | 21:02 |
| natefinch | *nod* | 21:02 |
| natefinch | ok, gotta run, sorry. Will try to be back on later. I'll take a look at the changelists and possibly the tarballs themselves to see if I can figure out what's going on. | 21:02 |
| natefinch | oh, one hack to fix it might just be to do an unnecessary import "encoding" from somewhere under github.com/juju/juju so we force that it gets included in the tarball | 21:04 |
| wwitzel3 | katco: no, it isn't blocked | 21:23 |
| katco | wwitzel3: k ty | 21:24 |
| menn0 | wallyworld: ping? | 21:36 |
| === kadams54 is now known as kadams54-away | ||
| mup | Bug #1449277 changed: juju environment create fails on aws: invalid config <juju-core:Invalid by waigani> <juju-core 1.24:Invalid by waigani> <https://launchpad.net/bugs/1449277> | 22:48 |
| perrito666 | so http://reviews.vapour.ws/r/1508/ and http://reviews.vapour.ws/r/1509/ Fix lp1441826 in 1.24 and master respectively, who would be so kind? wallyworld ? | 22:57 |
| perrito666 | katco: ? | 22:57 |
| perrito666 | ill go get some dinner and then come back | 22:57 |
| ericsnow | could I get a review on http://reviews.vapour.ws/r/1510/? | 23:23 |
| ericsnow | it's the fix we talked about on the call (build constraints for vsphere provider) | 23:23 |
| ericsnow | it should be super easy to review | 23:28 |
| perrito666 | famous last words | 23:29 |
| wallyworld | ericsnow: looks like there's additional unrelated changes in that diff | 23:41 |
| ericsnow | wallyworld: ah, that's just RB doing its thing (I'll fix) | 23:42 |
| ericsnow | fixed | 23:43 |
| wallyworld | looking again | 23:44 |
| wallyworld | ericsnow: what does the newly added init_gccgo do? | 23:44 |
| ericsnow | wallyworld: makes it so I don't have to touch provider/all/all.go :) | 23:45 |
| ericsnow | wallyworld: (allows import of "github.com/juju/juju/provider/vsphere") | 23:46 |
| ericsnow | wallyworld: I'll add a note to that effect | 23:46 |
| ericsnow | wallyworld: good to go? (I'm going AFK in a minute) | 23:56 |
| wallyworld | ericsnow: bah, i got disconnected again, i asked a quesion - what does the newly added init_gccgo do? | 23:57 |
| ericsnow | wallyworld: yep, and I responded :) I've added a comment explaining (allows imports of the package to continue to work) | 23:58 |
| wallyworld | sorry, didn't see | 23:58 |
| ericsnow | np :) | 23:58 |
| wallyworld | ericsnow: lgtm, ty | 23:59 |
| ericsnow | wallyworld: thanks | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!