| === kadams54 is now known as kadams54-away | ||
| === natefinch-afk is now known as natefinch | ||
| === brandon is now known as Guest42275 | ||
| natefinch | niemeyer: you around? | 02:48 |
|---|---|---|
| thumper | wallyworld: ping | 02:55 |
| wallyworld | yo | 02:55 |
| thumper | chat? | 02:55 |
| wallyworld | sure | 02:55 |
| thumper | 1:1 | 02:56 |
| perrito666 | natefinch: its nearly midnight where he lives | 02:57 |
| natefinch | perrito666: yeah, figured | 02:58 |
| natefinch | perrito666: same where you live though, right? | 03:03 |
| perrito666 | natefinch: yup | 03:04 |
| === kadams54 is now known as kadams54-away | ||
| mup | Bug #1463641 opened: lease: data race in tests (again) <juju-core:In Progress by dave-cheney> <https://launchpad.net/bugs/1463641> | 03:16 |
| mup | Bug #1463643 opened: worker/provisioner: 9 data races in tests <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1463643> | 03:16 |
| davechen1y | % go test | 03:23 |
| davechen1y | OOPS: 91 passed, 7 FAILED | 03:23 |
| davechen1y | --- FAIL: Test (79.72s) | 03:23 |
| davechen1y | FAIL | 03:23 |
| davechen1y | exit status 1 | 03:23 |
| davechen1y | FAIL github.com/juju/ju | 03:23 |
| davechen1y | well, gocheck, don't keep it to yourself ... | 03:23 |
| menn0 | davechen1y: just reviewing your PR | 03:26 |
| menn0 | davechen1y: how did races creep in again? | 03:26 |
| davechen1y | menn0: i don't know | 03:28 |
| menn0 | davechen1y: someone messed up conflict resolution during a merge perhaps | 03:29 |
| davechen1y | no idea, but it got unfixed | 03:29 |
| === kadams54-away is now known as kadams54 | ||
| menn0 | davechen1y: ship it although the test still sucks | 03:32 |
| menn0 | davechen1y: but that's not your fault | 03:32 |
| natefinch | davechen1y: am I right in assuming that if I have an RPC method that doesn't have any return data, I still have to give it an argument, something like this: https://github.com/natefinch/juju/blob/wpt-plugins/procmanager/plugins/api/err.go#L13 | 03:38 |
| davechen1y | natefinch: sorry | 03:41 |
| davechen1y | no idea off hand | 03:41 |
| natefinch | davechen1y: np | 03:41 |
| davechen1y | i think you can all rpc methods that don't have a return value | 03:41 |
| davechen1y | but i cannot think of any off hand | 03:41 |
| menn0 | davechen1y: the goroutine that's defined in-line in the test seems unnecessary | 03:44 |
| menn0 | davechen1y: AFAICS the select at the bottom should be reading directly from the subscription channel | 03:45 |
| menn0 | davechen1y: and the way things are now if the lease is never released that goroutine will hang around forever | 03:45 |
| davechen1y | oh no | 03:48 |
| davechen1y | gocheck isn't thread safe | 03:48 |
| davechen1y | i think i need to go and have a lie down | 03:48 |
| davechen1y | menn0: i'm just applying the old fix from PR 2422 | 03:48 |
| menn0 | davechen1y: yeah I know. i don't expect you to fix it. | 03:48 |
| davechen1y | i don't want to marry the test | 03:48 |
| menn0 | davechen1y: i just noticed that it could be better while reviewing your change | 03:49 |
| davechen1y | patches accepted :thumbsup: | 03:49 |
| davechen1y | in david's britton, any test importing "time" would be shot on sight | 03:50 |
| thumper | davechen1y: http://paste.ubuntu.com/11686336/ | 04:04 |
| thumper | davechen1y: wondering about the best way to test this | 04:04 |
| thumper | davechen1y: fails on windows due to OS error message being different | 04:04 |
| thumper | davechen1y: is there a nice OS agnostic way to do this better? | 04:04 |
| === kadams54 is now known as kadams54-away | ||
| davechen1y | thumper: does that error fit though os.IsNotExist ? http://golang.org/pkg/os/#IsNotExist | 04:26 |
| davechen1y | if it's been gift wrapped, you might have to write a helper to unwrap it | 04:27 |
| thumper | kk | 04:27 |
| thumper | I'll check | 04:27 |
| davechen1y | does anyone remember off the top of their head if it is safe to call c.Fail inside a goroutine ? | 05:00 |
| davechen1y | this is the same rule as t.Fatal | 05:00 |
| davechen1y | oh no | 05:00 |
| davechen1y | actually this is far worse | 05:00 |
| davechen1y | c.Assert in a goroutine triggers a race | 05:01 |
| axw | wallyworld: I've put up a PR that addresses all the storage relationships I can. there's a bunch more we'll need to do when we support shared storage | 05:07 |
| mup | Bug #1463661 opened: worker/provisioner: kvm broker test failure <juju-core:New> <https://launchpad.net/bugs/1463661> | 05:07 |
| axw | wallyworld: and detaching/attaching volumes and filesystems from machines | 05:07 |
| wallyworld | fair enough, ty, will look | 05:08 |
| thumper | alrighty then, I'm done | 05:26 |
| thumper | laters | 05:27 |
| wallyworld | axw: given in this new pr SetFilesystemInfo ensures any required volume is provisioned, that means that 1.24 could be broken? | 05:30 |
| axw | wallyworld: in theory. it's just a safe guard, the worker should be doing the right thing anyway | 05:32 |
| axw | wallyworld: storageprovisioner waits until the volume is provisioned before trying to provision the filesystem | 05:33 |
| wallyworld | ok | 05:34 |
| mup | Bug #1463643 changed: worker/provisioner: 9 data races in tests <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1463643> | 08:50 |
| dimitern | TheMue, standup? | 09:00 |
| mup | Bug #1463643 opened: worker/provisioner: 9 data races in tests <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1463643> | 09:11 |
| mup | Bug #1463643 changed: worker/provisioner: 9 data races in tests <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1463643> | 09:14 |
| * TheMue discovered params.ErrorResults.Combine(), nice | 11:54 | |
| wwitzel3 | katco: ping | 11:59 |
| jam | fwereade: probably a public issue. I'm trying to run "juju run relation-get" but I'm running into a problem because it is a peer relation | 12:20 |
| jam | specifically, trying to do "relation-ids" returns an empty list | 12:20 |
| jam | and relation-list et al all tell me I'm using an "unknown relation id" | 12:21 |
| jam | though if you pass the name of a known-incorrect relation name, it doesn't give an error, so I'm entirely possibly doing it wrong | 12:23 |
| jam | ok it was pebkac. I wasn't specifying the endpoint name correctly | 12:27 |
| fwereade | jam, that was not a deliberate http://dilbert.com/strip/1997-11-06 but glad to see it's resolved :) | 12:40 |
| jam | fwereade: heh. So one problem is that finding the relation-id means it is a 2 round trip process | 12:41 |
| fwereade | jamif it's inconvenient to jam the whole script into juju-run, you could just make it part of the charm and juju-run that script | 12:41 |
| jam | fwereade: I'm trying out "relation-get -r $(relation-ids endpoint)" if you assume there is only one, which seems to work | 12:44 |
| fwereade | jam, if it's a peer relation you can be sure | 12:44 |
| natefinch | niemeyer: note the difference between https://godoc.org/github.com/natefinch/juju and http://godoc.org/gopkg.in/natefinch/juju.v0 | 12:44 |
| natefinch | niedbalski: the latter doesn't show the directories (except the one I manually typed into the url at one point) | 12:45 |
| natefinch | niemeyer: ^ (sorry niedbalski) | 12:45 |
| perrito666 | morning | 12:46 |
| natefinch | morning perrito666 | 12:47 |
| * natefinch found a neat hack to show godoc of his WIP branches... just git tag your branch as v0 and then you can serve it up via godoc: https://godoc.org/gopkg.in/natefinch/juju.v0/procmanager/plugins/api | 12:47 | |
| katco | dimitern: this looked like it might be a networking bug (bug 1463480). it's a blocker; has anyone in our half of the world looked at this yet? | 13:08 |
| mup | Bug #1463480: Failed upgrade, mixed up HA addresses <blocker> <canonical-bootstack> <ha> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.22:Incomplete> <juju-core 1.24:Incomplete> <https://launchpad.net/bugs/1463480> | 13:08 |
| dimitern | katco, I'll have a look | 13:09 |
| katco | dimitern: ty sir | 13:10 |
| dimitern | katco, it doesn't quite look like a networking issue, more likely something around sorting / picking a private address for the unit | 13:12 |
| dimitern | katco, I'll add comments | 13:15 |
| * fwereade off collecting laura again, cath's back this evening, normal service will resume shortly | 13:15 | |
| sinzui | dimitern: katco : We need an engineer to comment on bug 1463608. Does modern Juju us pv (paravirtual) types in ec2? That type is going away alone with i386? | 13:15 |
| mup | Bug #1463608: Deprecate support for 32-bit and PV AMI's for AWS Images <ec2-provider> <i386> <streams> <juju-core:Triaged> <juju-release-tools:Triaged> <https://launchpad.net/bugs/1463608> | 13:15 |
| mgz_ | sinzui: we have instance types with pv, yeah | 13:17 |
| mgz_ | and have had user requests to keep t1.micro working, even though not all aws regions provide it | 13:19 |
| sinzui | mgz_: Yeah. I recalled the request to keep that running, but AWS doesn’t agree. I think this raised the priority of my concern that we are loosing our ability to retest old juju | 13:20 |
| * sinzui want to stop making i386 agents. | 13:21 | |
| mgz_ | sinzui: I think in all current supported jujus we can always force the instance type specifically with a constraint | 13:21 |
| mgz_ | provided there's at least one instance type that juju knows about that's still available | 13:22 |
| mup | Bug #1463826 opened: TestProvisioningDoesNotOccurWithAnInvalidEnvironment fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1463826> | 13:23 |
| sinzui | mgz_: http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:aws.json is still dominated by pv. I assume hvm will become the peferred typ | 13:27 |
| mgz_ | sinzui: yes, I think we should have a hvm one for each release though? | 13:28 |
| sinzui | mgz_: I think so. Our get_ami prefers pv. I think all ami we provision are pv | 13:29 |
| mup | Bug #1458721 changed: lease: data races in tests <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1458721> | 13:44 |
| mup | Bug #1459085 changed: worker/logger: data race in tests <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1459085> | 13:44 |
| mup | Bug #1461385 changed: apiserver/instancepoller: data race in test <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1461385> | 13:44 |
| mup | Bug #1458721 opened: lease: data races in tests <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1458721> | 13:50 |
| mup | Bug #1459085 opened: worker/logger: data race in tests <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1459085> | 13:50 |
| mup | Bug #1461385 opened: apiserver/instancepoller: data race in test <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1461385> | 13:50 |
| mup | Bug # changed: 1456315, 1458721, 1459085, 1461385, 1462412 | 13:53 |
| sinzui | mgz_: can you review http://reviews.vapour.ws/r/1909/ | 13:55 |
| mgz_ | sinzui: lgtm | 13:57 |
| sinzui | thank you mgz_ | 13:57 |
| mup | Bug #1463870 opened: unitSuite teardown fails <ci> <unit-tests> <juju-core:Incomplete> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1463870> | 14:51 |
| voidspace | dimitern: it's simple | 15:19 |
| voidspace | dimitern: we're not populating the NetworkInfo of StartInstanceResult inside the StartInstance method of the brokers | 15:19 |
| voidspace | dimitern: easy fix | 15:19 |
| dimitern | voidspace, really? I though we did.. | 15:20 |
| * dimitern is looking at commit history of lxc-broker.go | 15:20 | |
| voidspace | dimitern: take a look at the last line of StartInstance in lxc-broker.go | 15:20 |
| dimitern | voidspace, aw ffs.. | 15:21 |
| dimitern | voidspace, of course :) good catch! I was thinking of args.NetworkInfo being updated after PCII() | 15:22 |
| voidspace | dimitern: at least it's easy to fix :-) | 15:23 |
| voidspace | dimitern: from my debugging, it *will* be propagated all the way up | 15:23 |
| dimitern | voidspace, yeah, easy fix indeed, but please make a quick live test to make sure populating it won't break anything | 15:24 |
| voidspace | dimitern: sure | 15:27 |
| voidspace | dimitern: it *really* shouldn't | 15:27 |
| voidspace | dimitern: but you never know I guess... | 15:28 |
| dimitern | voidspace, yeah, it might break some tests around juju status, if it expects no networks to be listed | 15:29 |
| dimitern | voidspace, as the networks added during SetInstanceInfo will show up there | 15:30 |
| voidspace | dimitern: sure, I'll have to fix test failures | 15:30 |
| voidspace | dimitern: and I'll check any failures to see if they're significant | 15:30 |
| dimitern | voidspace, cheers! | 15:33 |
| TheMue | this state.IPAddress <-> network.Address <-> params.Address sometimes drives me crazy. | 15:41 |
| TheMue | would have liked a dumb type model package with pure structs for our model and and pure function interface to State (or however the persistency layer is called). | 15:41 |
| TheMue | and the api as well as the persistency layer are accepting the dumb model | 15:42 |
| * TheMue takes a relaxing bike ride home and continues later | 15:48 | |
| voidspace | dimitern: ooh, now I have a provisioner error - invalid network name, so it looks like the parameters need a bit of massaging | 15:48 |
| voidspace | digging in | 15:48 |
| voidspace | empty network name: "" | 15:48 |
| dooferlad | TheMue: Could you do me a review of http://reviews.vapour.ws/r/1910/ ? | 15:52 |
| dimitern | voidspace, right | 15:53 |
| dimitern | voidspace, that's because NetworkName should be set on the InterfaceInfo | 15:54 |
| voidspace | dimitern: sure, but I just passed it through from the BridgeNetworkConfig | 15:56 |
| dimitern | voidspace, for now I'd suggest just turning the empty name into a warning log instead of an error in state.AddNetwork | 15:56 |
| voidspace | or maybe just not add the network | 15:57 |
| voidspace | or does every interface need to be associated with a network? | 15:57 |
| voidspace | I'll look | 15:57 |
| dimitern | voidspace, technically - yes, but it's not used anywhere yet | 15:57 |
| voidspace | dimitern: I can still ssh into the container with "juju ssh" | 15:58 |
| voidspace | dimitern: so it's still created ok | 15:58 |
| dimitern | voidspace, that's good :) | 16:01 |
| katco | ericsnow: hey reviewing your patch http://reviews.vapour.ws/r/1905 | 16:04 |
| ericsnow | katco: thanks | 16:04 |
| katco | ericsnow: you lead in saying it's a refactor, but it looks like there's some new stuff? is that right? | 16:04 |
| ericsnow | katco: depends on how you look at it :) | 16:05 |
| katco | ericsnow: well for instance, i'm not seeing where the leadership stuff came from? | 16:05 |
| ericsnow | katco: what leadership stuff? | 16:06 |
| ericsnow | katco: ah | 16:06 |
| ericsnow | katco: the old test double didn't have those method explicitly but I added them | 16:06 |
| katco | ok, ty, that helps frame things | 16:07 |
| dimitern | dooferlad, you have a review btw | 16:27 |
| dimitern | dooferlad, good work! | 16:27 |
| dimitern | dooferlad, don't forget to move your card ;) | 16:28 |
| mup | Bug #1461871 changed: worker/diskmanager sometimes goes into a restart loop due to failing to update state <canonical-bootstack> <storage> <juju-core:Fix Released> <juju-core 1.22:Fix Committed by axwalk> <juju-core 1.24:Fix Released by axwalk> <https://launchpad.net/bugs/1461871> | 16:30 |
| mup | Bug #1461871 opened: worker/diskmanager sometimes goes into a restart loop due to failing to update state <canonical-bootstack> <storage> <juju-core:Fix Released> <juju-core 1.22:Fix Committed by axwalk> <juju-core 1.24:Fix Released by axwalk> <https://launchpad.net/bugs/1461871> | 16:36 |
| mup | Bug #1461871 changed: worker/diskmanager sometimes goes into a restart loop due to failing to update state <canonical-bootstack> <storage> <juju-core:Fix Released> <juju-core 1.22:Fix Committed by axwalk> <juju-core 1.24:Fix Released by axwalk> <https://launchpad.net/bugs/1461871> | 16:42 |
| mup | Bug #1463904 opened: TestReadLeadershipSettings fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1463904> | 16:42 |
| natefinch | ericsnow, wwitzel3, katco: I need input on whether my plugin architecture is overkill or not: https://godoc.org/gopkg.in/natefinch/juju.v0/procmanager/plugins/api | 16:47 |
| ericsnow | natefinch: k | 16:48 |
| natefinch | I think that if we never add anything to it, then it is. But I think the chances that we never add anything to it are small. | 16:48 |
| katco | natefinch: tal | 16:49 |
| natefinch | right now it can all be accomplished with simple CLI input and stdout output with return codes..... | 16:49 |
| ericsnow | katco: thanks for the review | 16:55 |
| katco | ericsnow: ty for the refactor | 16:55 |
| katco | natefinch: it doesn't seem like overkill to me | 16:57 |
| katco | natefinch: one suggestion: for states: maybe just have 1 "errored" state, and allow juju to query the plugin for more info? | 16:57 |
| katco | natefinch: it could allow for plugin-specific detail w/o having to enumerate all possible states | 16:58 |
| natefinch | katco: my concern is that I'm making plugin authors write a whole RPC client thingy, when, right now, the requirements are simple enough to allow just printing to stdout and signifying an error via a non-zero exit code. | 16:59 |
| katco | natefinch: that is a good point | 16:59 |
| katco | natefinch: let's look at it practically... what languages will people most likely be writing plugins in? | 17:00 |
| natefinch | katco: no idea. It would be trivial for us to make a helper packages for Go and python.... but as I state in my doc, it pretty much precludes bash. | 17:02 |
| katco | natefinch: well not completely, right? bash can just as easily fork out to something that could create the json | 17:03 |
| natefinch | katco: well, yes. but it's a lot harder than it is in a real programming language where someone's already written all the json-rpc code. | 17:03 |
| katco | natefinch: well, what i mean to say is: echo $(python my-rpc-generator --id=1 --err="Couldn't start container") or some such | 17:04 |
| katco | natefinch: plugins can look for assistance for the heavy lifting | 17:05 |
| natefinch | I guess the question is - how likely is it that the requirements for these plugins is going to get significantly more complicated? If it's pretty likely, then I think the current architecture is fine. If it's not likely to change, then we might want to lower the barrier of entry for third parties writing plugins (that being said, I kinda wonder how many third parties we'll really have writing plugins for this). | 17:06 |
| katco | natefinch: i think you're right to worry about the way juju interacts with containers as something that will evolve over time. | 17:07 |
| katco | natefinch: that's my take. i'd love ericsnow and wwitzel3's | 17:07 |
| katco | natefinch: i think the p(the way juju interacts w/ containers changes) > p(need to support more containers) | 17:08 |
| mup | Bug #1463910 opened: Upgrade tests timeout on ppc64 <ci> <gccgo> <intermittent-failure> <regression> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1463910> | 17:12 |
| ericsnow | natefinch: it may be too much | 17:18 |
| ericsnow | natefinch: we need 3 commands (launch/status/stop) | 17:18 |
| ericsnow | natefinch: I don't think we need an Info; launch should return the LaunchDetails | 17:19 |
| natefinch | ericsnow: info is status | 17:19 |
| ericsnow | natefinch: the status command should return just the status string that makes sense for the plugin | 17:19 |
| ericsnow | natefinch: I could see the status command returning extra volatile status-like data | 17:20 |
| natefinch | ericsnow: this is what I have for how juju calls the plugins: https://godoc.org/gopkg.in/natefinch/juju.v2/procmanager/plugins | 17:21 |
| ericsnow | natefinch: having the status command return ProcessInfo means the plugin would have to store all that information (information Juju already has and would ignore) | 17:21 |
| natefinch | ericsnow: I was assuming that you're getting information from the plugin, and storing that in state... otherwise, where are you getting that information from | 17:21 |
| ericsnow | natefinch: that is correct | 17:22 |
| ericsnow | natefinch: the plugin is not expected to store that information | 17:22 |
| natefinch | ericsnow: I didn't think it would. Info just returns information about the process... whatever information it thinks is appropriate | 17:23 |
| ericsnow | natefinch: the only thing we need right now would be status | 17:23 |
| ericsnow | natefinch: I'm not sure that extra "Details" field is worth it | 17:25 |
| ericsnow | natefinch: is your branch based on our feature branch? | 17:26 |
| natefinch | ericsnow: no... I could make it so, though | 17:27 |
| ericsnow | natefinch: that may help you | 17:27 |
| natefinch | ericsnow: I was referencing it, and the doc... under "info" it has "technology specific details" which I figured must come from the plugin | 17:28 |
| ericsnow | natefinch: those details are a one-time thing at launch time | 17:28 |
| natefinch | ericsnow: ok, I didn't realize that | 17:29 |
| ericsnow | natefinch: ah, sorry that wasn't more clear | 17:29 |
| === kadams54_ is now known as kadams54-away | ||
| mup | Bug #1463922 opened: Text file busy <bootstrap> <ci> <intermittent-failure> <juju-core:Incomplete> <juju-core feature-proc-mgmt:Triaged> <https://launchpad.net/bugs/1463922> | 17:54 |
| natefinch | katco, ericsnow: ok, so, I think what I'll do is rework the plugins to just be CLI input writing to stdout, and if we later need to make them complicated, we can just create new-style plugins or something. | 17:55 |
| ericsnow | natefinch: k | 17:55 |
| cholcombe | are there certain things that are not available in the leader context? when leader-elected is run I tried to gather some context info and nothing worked | 18:04 |
| natefinch | cholcombe: should be the same as any other context | 18:08 |
| cholcombe | ok then i'm seeing some odd behavior | 18:08 |
| cholcombe | in the leader-elected hook JUJU_RELATION_ID and JUJU_RELATION are coming up blank | 18:08 |
| natefinch | I'm not 100% up to speed on the leader election stuff.... but those are relation-specific variables that generally only get set during relation hooks (relation changed, relation joined etc). | 18:10 |
| cholcombe | ok | 18:11 |
| cholcombe | so what should i be doing in the leader-elected hook? | 18:11 |
| cholcombe | i'm not sure i have enough info in that hook to do anything | 18:11 |
| natefinch | cholcombe: that's possible. you can always run is-leader or leader-get from other hooks to get info about the leader | 18:13 |
| cholcombe | yeah that's what is also strange | 18:13 |
| cholcombe | when i run is-leader in the other hooks they always return False | 18:13 |
| cholcombe | i'm on juju 1.23.3 | 18:13 |
| mup | Bug #1461578 opened: TestKVMProvisionerObservesConfigChange fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1461578> | 18:18 |
| natefinch | cholcombe: The guy who knows most about the leadership stuff is not here right now, though I think he said he'll be on later. Look for fwereade. Unfortunately, I don't know very much about it, since it's a new feature and still in the experimental phase. It should *function* however... | 18:19 |
| cholcombe | ok thanks :) | 18:19 |
| ericsnow | katco: PTAL: https://github.com/juju/charm/pull/137 | 18:23 |
| * natefinch just got smacked with a "Pull Requests welcome" when filing a bug against godoc.org :/ | 18:28 | |
| katco | ericsnow: this could use some comments: https://github.com/juju/charm/pull/137/files#diff-c0e084d1eb96781ebe2d307ae3dcebcbR265 | 19:01 |
| katco | ericsnow: i'm having a little trouble understanding what that code is trying to do | 19:01 |
| katco | ericsnow: the public method doesn't have a comment either (drive-by fix) | 19:02 |
| ericsnow | katco: k | 19:02 |
| ericsnow | katco: feel free to leave comments on the PR | 19:03 |
| katco | ericsnow: sorry, doing so | 19:04 |
| natefinch | ericsnow: so you said launch is expected to return an id and some details? | 19:07 |
| === kadams54-away is now known as kadams54_ | ||
| * perrito666 read lunch | 19:10 | |
| natefinch | haha | 19:10 |
| ericsnow | natefinch: yep | 19:11 |
| natefinch | ericsnow: where details is... like a map or something? | 19:11 |
| ericsnow | natefinch: LaunchDetails in package/plugin.go | 19:12 |
| natefinch | ericsnow: did you push? I don't see it: https://github.com/juju/juju/blob/feature-proc-mgmt/process/plugin.go | 19:15 |
| ericsnow | natefinch: oh, it's ProcessDetails | 19:16 |
| natefinch | ericsnow: I figured status was what was returned by the Status call | 19:17 |
| ericsnow | natefinch: yep | 19:18 |
| ericsnow | natefinch: it's in ProcessDetails for convenience | 19:18 |
| natefinch | ok, so... launch should return the ID of the process and also whatever status on that id would report? | 19:18 |
| katco | i've been neglectful of my duties. someone needs to be looking at this: bug 1463480 | 19:21 |
| mup | Bug #1463480: Failed upgrade, mixed up HA addresses <blocker> <canonical-bootstack> <ha> <upgrade-juju> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1463480> | 19:21 |
| katco | (let ((victims '(wwitzel3 ericsnow perrito666 natefinch cherylj))) | 19:23 |
| katco | (elt victims (random (length victims)))) | 19:23 |
| katco | cherylj you have been selected by my computer's pseudorandomness | 19:23 |
| natefinch | katco: you need a bot to do that | 19:24 |
| katco | natefinch: since i use emacs, my irc client is the bot :) | 19:24 |
| natefinch | katco: yes, but if there was a bot then other people with lesser editors could use it, too :) | 19:25 |
| katco | mup: why can't you do this, ya mup. | 19:25 |
| mup | katco: I apologize, but I'm pretty strict about only responding to known commands. | 19:25 |
| natefinch | mup: help | 19:26 |
| mup | natefinch: Run "help <cmdname>" for details on: bug, contrib, echo, help, infer, login, poke, register, run, sendraw, sms | 19:26 |
| cherylj | heh | 19:26 |
| katco | mup: help infer | 19:26 |
| mup | katco: infer [-all] <query ...> — Queries the WolframAlpha engine. | 19:26 |
| mup | katco: If -all is provided, all known information about the query is displayed rather than just the primary results. | 19:26 |
| cherylj | katco: yeah, I can take a look... | 19:26 |
| katco | mup: infer randomly select between 1 and 4 | 19:26 |
| mup | katco: 1. | 19:26 |
| katco | mup: infer randomly select between these options: natefinch wwitzel3 ericsnow and cherylj | 19:27 |
| mup | katco: Cannot infer much out of this. :-( | 19:27 |
| katco | mup: infer randomly select natefinch wwitzel3 ericsnow cherylj | 19:27 |
| mup | katco: Cannot infer much out of this. :-( | 19:27 |
| katco | mup: infer RandomChoice{"natefinch"|"wwitzel3"|"ericsnow"|"cherylj"} | 19:31 |
| mup | katco: Cannot infer much out of this. :-( | 19:31 |
| katco | mup: infer RandomChoice{"natefinch" | "wwitzel3" | "ericsnow" | "cherylj"} | 19:31 |
| mup | katco: Cannot infer much out of this. :-( | 19:31 |
| katco | gah | 19:31 |
| katco | i thought gustavo was using WA for this | 19:32 |
| katco | mup: infer how good is juju? | 19:32 |
| mup | katco: Cannot infer much out of this. :-( | 19:32 |
| katco | cherylj: sorry, thank you for tal. | 19:34 |
| perrito666 | katco: it will be a lot easier to go look for the code | 19:35 |
| katco | cherylj: i was having too much fun with mup | 19:35 |
| katco | perrito666: RandomChoice works on WA's web interface | 19:35 |
| perrito666 | katco: the code of mup | 19:35 |
| alexisb | alright all, I am shutting down to head into town to meet up with canonical pdxers, if you need me while I am not online call my cell | 19:45 |
| katco | alexlist: tc | 19:46 |
| natefinch | mup: infer RandomChoice[{'wwitzel', 'ericsnow', 'natefinch', 'cherylj'}] | 19:49 |
| katco | lol | 19:50 |
| katco | natefinch: mup straight up just doesn't like you | 19:50 |
| natefinch | mup: infer RandomChoice[{'wwitzel', 'ericsnow', 'natefinch', 'cherylj'}] | 19:50 |
| mup | natefinch: natefinch. | 19:50 |
| katco | LOL | 19:50 |
| natefinch | lol | 19:50 |
| natefinch | mup: infer RandomChoice[{'wwitzel', 'ericsnow', 'natefinch', 'cherylj'}] | 19:50 |
| mup | natefinch: cherylj. | 19:50 |
| natefinch | there ya go | 19:50 |
| katco | confirmed. doesn't like you. | 19:50 |
| natefinch | ericsnow: so... when I launch a process, should launch return both the id and whatever status(id) would return? Or is there special data that is expected to be returned only at launch time? | 19:56 |
| ericsnow | natefinch: yeah, there may be extra data | 19:57 |
| natefinch | ericsnow: ok, so I'm going to return a string id and a map[string]interface{} that'll be whatever yaml garbage launch wants to spit out | 19:58 |
| ericsnow | natefinch: yep | 19:58 |
| * natefinch assumes we'll want it to be yaml because that's the Juju way, even though yaml is terrible ;) | 19:58 | |
| natefinch | katco, ericsnow: new plugins - https://godoc.org/gopkg.in/natefinch/juju.v3/process/plugin | 21:01 |
| natefinch | out for dinner, back in a few hours | 21:01 |
| === natefinch is now known as natefinch-afk | ||
| thumper | mramm: I'm in our hangout a bit early if you are free | 21:24 |
| === kadams54_ is now known as kadams54-away | ||
| thumper | davecheney: would https://github.com/go-check/check/pull/35/files fix our problem? | 22:45 |
| thumper | trivial review for someone: http://reviews.vapour.ws/r/1911/diff/# | 23:15 |
| thumper | if we had a trivial tag, I'd just land it :-) | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!