[01:37] waigani: #1270466 can be closed now? [01:37] hm, mup doesn't recognise LP bug IDs anymore? :( [01:38] axw: closed [01:39] cool [01:42] axw: so getting api endpoints at end of bootstrap. I can get machine 0's public address. But what about HA? I see a machine has a DistributionGroup. Should I use that to see if we are in HA and get the endpoints of the others? I think api.Client.APIHostPorts() would get them all, but that func is not allowed while 'in upgrade' [01:43] waigani: there's only one machine during bootstrap. bootstrap already grabs that machine's address so it can SSH in [01:45] waigani: see waitSSH in provider/common/bootstrap.go [01:45] axw: will do, cheers [01:45] waigani: once Bootstrap has returned successfully, you should be able to assume that the instance has addresses, so you don't need the complicated logic from there [01:46] you may just want to return the addresses from there tho [01:47] axw: ah, perfect. I assumed something like that was going on, as bootstrap finished but common.ProviderStateInstances was not finding any instances. I'll use waitSSH to wait [01:49] waigani: just to be clear, waitSSH is already used by bootstrap. So you should just be able to bubble up the addresses it calculates [01:50] axw: I have not been able to do that so far [01:51] axw: but I'll have a look at how waitSSH is used and see what I'm missing [01:51] waigani: provider/common.Bootstrap should return addresses. it should get them from FinishBootstrap, which should get them from waitSSH [01:52] axw: ah, the dummy bootstrap does not use common.Bootstrap [01:53] waigani: you'll need to change Environ.Bootstrap's signature to return hostports, and dummy/manual/local will need different logic as they don't use common.Bootstrap [01:53] not that straightforward; maybe you do want to make an API call for the first cut [01:54] waigani: if you make an API connection, *any* method (assuming Login passes validation), then you [01:54] 'll get back the hostports [01:54] cached by juju.NewAPIConn [01:57] axw: sorry otp, reading now [02:05] axw: yeah, so I that is where I've ended up, dummy and local don't use common.Bootstrap, so I'm doing an API call to get endpoints (EnvCommandBase.NewAPIClient()). But client.APIHostPorts() is not allowed, because we are in 'upgrade' at the end of bootstrap. [02:06] axw: so I can only (so far) get the public address of machine 0 [02:06] waigani: (you could just return localhost for local, and any old thing for dummy...) -- but you don't actually need to call APIHostPorts, you could just call, say, client.Status [02:07] that is allowed during upgrade [02:07] the act of making a method call will cache the addresses [02:07] you don't need to explicitly do anything with that [02:08] waigani: actually, I don't think you even need to make a method call. just open and close the API connection [02:08] axw: that was my first thought but thumper was adamant that just calling status does not work, he said he tried. I'll try myself (to be sure) [02:09] waigani: you can see how it works in juju/api.go [02:09] at the bottom of newAPIFromStore [02:14] axw: grrrr, just calling state bloody works. I'll try just connecting to the api [02:15] waigani: just calling status you mean? [02:15] axw: yes sorry [02:15] sure, just checking I understand [02:19] yep, that works - sigh [02:19] thanks axw [02:19] waigani: cool, nps [02:20] how much use do you guys make of syslog? I got the impression from the ML that you're thinking of stopping using it? [02:20] bigjools: we don't use syslog directly, we write our logs to a file and have rsyslog tail it [02:21] then they all send to a centralised rsyslog to aggregate [02:21] ok [02:21] In maas we're moving towards just sending everything to syslog and letting it do the heavy lifting [02:22] bigjools: does that get sent anywhere remote? aggregated? [02:23] the plan is to aggregate somewhere, yes, not sure where yet [02:23] mmk [02:23] well we don't have a "central" place [02:24] so the decision is not easy :) [02:24] when I said centralised, I actually meant to all of the juju state servers [02:24] so it's still HA [02:25] * axw doesn't know MAAS well enough to draw parallels [02:25] right [02:25] we might do something similar and sync to all appservers === rogpeppe1 is now known as rogpeppe [07:17] morning all [07:31] yay, online [07:31] morning everyone [07:48] morning [08:26] could someone take a look at https://github.com/juju/juju/pull/464 ? === rvba` is now known as rvba [08:34] tasdomas: yep, will do. [08:37] TheMue, thanks! [08:37] tasdomas, LGTM with a followup, I think the problems may run a little deeper [08:38] fwereade: just seen you’ve LGTMed the PR [08:45] hmm... when I try to submit a "national holiday" to hr.canonical.com it asks me to attach supporting evidence to the request... [08:56] rogpeppe, would you be able to take another look at https://github.com/juju/juju/pull/469 [08:56] mattyw: looking [08:57] voidspace, https://www.gov.uk/bank-holidays [08:58] voidspace, I think Auntie Liz has to approve bank holiday's each year so I did a quick google to see if I could find a pdf of her signature [08:59] mattyw: i'm mostly +1 on fwereade's suggestion [09:00] mattyw: except that i'd use Reset rather than creating a new timer each time [09:01] rogpeppe, that is what's i'm doing in the latest code [09:02] mattyw: oh, weird. i never quite get how github comments work [09:02] rogpeppe, oh right - fwereade commented 4 minutes ago [09:02] rogpeppe, so you were refering to a comment I hadn't seen yet :s - concurrency on a monday morning [09:03] mattyw: his code is pretty much functionally equivalent, but slightly neater and fits with a common worker pattern [09:12] mattyw: hehe, [09:23] * fwereade bbiab [10:46] TheMue: dimitern: internet has recovered, so I may make standup after all [10:46] but first, coffee... [10:46] voidspace, great :) see you there [11:27] morning === Guest42485 is now known as wallyworld [11:39] could somebody take a look at https://github.com/juju/juju/pull/455 ? [12:02] katco: mgz: standup? [12:12] no katco yet alas. [12:13] I'm seeing a failure on master in the test suite for utils/ssh : http://paste.ubuntu.com/8016636/ - is anybody else seeing something like this? [12:15] tasdomas: nope, what does `ssh -V` say for you? [12:16] ...not that that should matter actualyl [12:17] mgz, ssh: Could not resolve hostname hostname: Name or service not known [12:17] tasdomas: your ssh looks broken then, check yuor network config? [12:18] mgz, that's the error I get when running the ssh line in terminal [12:18] mgz, ssh -V : OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 Jan 2014 [12:20] oh, I was right, the ssh should in fact not be used [12:23] tasdomas: try `BASH_ENV="" go test`? [12:24] mgz, seems like it was a godeps issue - forgot to run godeps -u [12:25] fair enough. [12:25] mgz, and I need to update my vm [12:28] mgz, thanks [13:49] fwereade: you around? [13:50] natefinch, heyhey [13:50] natefinch, how's it going? [13:50] fwereade: not bad. Well rested from my week of not traveling ;) [13:52] lol, too soon [13:52] fwereade: I'm a bit stuck on what to do about log rotation. There's a few different bad options, and I'm not sure how to choose between them [13:52] wwitzel3: heh [13:52] natefinch, haha [13:53] natefinch: I'm working on tht now, with rsyslog, should I not be, or you talking about Windows? [13:53] natefinch, wwitzel3: windows is also interesting, gsamfira certainly has relevant input there [13:54] wwitzel3: you're doing all-machines, right? [13:54] natefinch, wwitzel3: I would hope that log rotation would encompass *all* our logs, even if the work came in a few stages [13:55] fwereade: yes of course. There's really only a couple spots to hit - all-machines is a different beast than the machine-n and unit-n logs [13:55] natefinch, cool [13:56] natefinch: yeah, all-machine [13:56] s [13:56] wwitzel3: cool, yes, there's no real option for anything but logrotate / rsyslog rotation there. [13:57] not even if we log directly to rsyslog from juju? in the case of all-machines.log I mean [13:57] ? [13:57] gsamfira: the rotation has to be on the state machine, which is listening using rsyslog [13:58] that's fine. That should be easily doable using standard logrotate [13:58] and for all other juju logs, lumberjack can take care of the rotation [13:58] no? [13:58] gsamfira: yes, sorry if I wasn't clear. That's what wwitzel3 is doing [13:58] ahh [13:59] yep :) [13:59] my mistake. Read diagonally [13:59] the thing that I'm talking about is rotating the unit-n and machine-n logs. Some people have questioned why we don't just use logrotate for those as well, and only make windows use something else. [13:59] my preference would be that if we can do something the same everywhere, to do it the same, that way we don't need to maintain different codepaths depending on OS [14:00] well, as you pointed out on the mailing list, its better to have one config that works across platforms then 2-3 separate ones :) [14:00] yes [14:00] yep [14:00] :) [14:00] the more os specific dependencies you can remove, the better [14:00] I believe that as well [14:02] fwereade: the question is - how far do we go? Do we write directly to syslog from inside juju, thereby bypassing rsyslog and not needing to worry about whether it misses log messages due to rotation? Or do we continue with rsyslog and figure out how to make that work with rotation? Or do you disagree with me. and think we should use logrotate on linux? [14:02] implementing syslog using Go, should be simple enough. I will cleanup the fork I made of the standard syslog package, and I can have a shot at implementing it in Juju by tomorrow. [14:03] natefinch, so, if we can write directly to syslog, I would like that very much [14:03] natefinch, I think thumper was going to reply to your post explaining the problems he'd found with go syslog [14:03] fwereade: ahh, that would be very good to hear about. [14:03] natefinch, apart from handwaving about how it outputs stuff is in some way inconvenient I can't actually remember the issue with it myself [14:04] hmm. Syslog implements io.Writer. In theory, it should be like writting to a file. The only thing is that you need to set a prefix, which you would normally do via the rsyslog config [14:04] but nay formatting should be done via loggo [14:07] gsamfira: as long as loggo does it's output in a single write, that's ok. If it batches them or breaks a single line into multiple writes, it can be a problem. the syslog package expects each write to be a single log message. [14:07] I would like to try and tackle any issues that might have stopped us from using this. Until better log aggregation is found at least :) [14:07] gsamfira: I think that would be great [14:08] natefinch: standup :) [14:10] natefinch: Hopefully loggo adheres to that expectation as well :). I'll have a look [14:32] good morning all [14:33] mgz: wallyworld: sorry about missing the standup [14:33] natefinch: wwitzel3 ericsnow suddenly the page died on my and I can no longer connect sorry [14:33] katco: no problem, ian will catch us up on last week tomorrow [14:34] mgz: ok cool [14:35] perrito666: np [14:48] natefinch: have you seen bug 1355219? [14:51] morning all [14:58] mgz: go get gopkg.in/natefinch/npipe.v2 works for me [15:01] mgz: It looks like we assume juju-core_1.21-alpha1.tar.gz has it in there.... we should look at how that's generated and why it's not getting juju's dependencies. [15:02] mgz: my guess is that it solely uses godeps and someone either messed up godeps or forgot to update it. [15:02] brb [15:28] anybody willing to review a quick fix https://github.com/juju/juju/pull/491 for bug https://bugs.launchpad.net/juju-core/+bug/1353443 ? [15:28] TheMue, rogpeppe, voidspace, fwereade ^^ [15:28] dimitern: looking [15:29] rogpeppe, ta! [15:29] dimitern: what if we're running inside kvm inside lxc? should that trigger the same logic? [15:30] rogpeppe, so the kvm is the host, and the lxc is where the MA+networker runs? [15:30] dimitern: i was thinking the other way around actually [15:31] rogpeppe, i don't think you can run kvm inside lxc [15:31] dimitern: you sure about that? [15:31] rogpeppe, 99% [15:32] rogpeppe, it doesn't make sense, as kvm needs full access to hardware virtualization, which an lxc host cannot provide [15:33] dimitern: i'm still a bit uncomfortable about assuming that there's no container type that can run inside lxc [15:33] dimitern: now and for the indefinite future [15:33] rogpeppe, lxc can run inside lxc [15:34] dimitern: ok, no non-lxc container type :-) [15:34] dimitern: i'd be happier if the logic looked at the last container type [15:34] dimitern: because that's what it actually cares about, no? [15:35] rogpeppe, you mean the logic about parsing the machine id ? [15:35] dimitern: yes [15:36] dimitern: specifically the fact you use strings.Contains [15:36] sinzui: you around? [15:37] rogpeppe, well, my idea there is that if lxc is involved at any level of nesting, we shouldn't modprobe [15:38] mgz: I presume that 1.21 build is running off of trunk? [15:38] natefinch: yup [15:38] dimitern: that's a big test for a little bit of code [15:38] mgz: k thanks [15:39] voidspace, it's a fairly involved worker for all it does :) [15:39] heh, right [15:39] voidspace, we need to simplify it [15:39] "we" [15:39] :-p [15:40] I'm going afk for a while (two hours) [15:41] dimitern: i have difficulty working out if that's a valid decision or not [15:41] dimitern: because it's not clear to me that you might not be able to nest some container type that *does* allow modprobe [15:41] rogpeppe, i'm chatting with jamespage and hallyn at #server (@c) about this actually [15:41] dimitern, rogpeppe: lets talk here [15:43] jamespage, right, sorry about the context switching :) [15:43] dimitern, np [15:44] jamespage, so, is my idea about not allowing modprobe if lxc is involved at any level of nesting, not only the last level? [15:44] dimitern, rogpeppe: its possible to hack an LXC container sufficiently so it can run a KVM instance - but this still runs within the host kernel [15:44] is it a correct approach to the problem, i mean [15:45] dimitern, a KVM instance will always support modprobe as it has its own kernel etc... [15:45] dimitern, LXC will not and should not [15:46] dimitern, this is why its possible to run the nova-compute charm on KVM, but not LXC [15:46] jamespage, so you can modprobe 8021q for example inside the kvm, hosted inside an lxc without 8021q on its respective host? [15:46] dimitern, yes [15:46] dimitern, in the very hyperthetical situation that is true [15:47] jamespage, ok, so to be absolutely correct, we should check what rogpeppe suggests - only the last-level-of-nesting container, which runs the agent should not be lxc [15:47] i think we should allow that case, even if hypothetical [15:47] dimitern, yes [15:48] jamespage, rogpeppe, ok, fair enough, thanks for the feedback [15:48] dimitern: another approach might be just to ignore that error from modprobe [15:49] dimitern: that way if someone fixes lxc, the code will just work again [15:49] rogpeppe, I don't really like this [15:50] rogpeppe, because it's hard enough to deal with the output lsmod and modprobe give anyway [15:50] dimitern: yeah [15:51] dimitern: another thought is to put the "isRunningInLXC" logic inside (or called from) ensureVLANModule [15:51] dimitern: because at the moment it's really not clear why we call isRunningInLXC before calling ensureVLANModule [15:52] dimitern: but if we passed the machine id into ensureVLANModule and did the check in there, the connection is obvious (and the comments would read nicely too) [15:53] rogpeppe, ensureVLANModule should not be called like this, but this is another issue - we should only call it, if there are any VLANs to setup [15:59] Fix for LP-1355319 : https://github.com/juju/juju/pull/493 [16:00] rogpeppe, updated isRunningInLXC a bit to check the last level container type [16:01] dimitern: looking [16:01] dimitern: i don't think that will actually work, will it? [16:02] I hate it when I know I'm doing something stupidly wrong.... but still can't figure out what it is [16:02] rogpeppe, why? [16:02] dimitern: don't you want something like: if len(parts) > 2 && parts[len(parts)-2] == "lxc" { ? [16:03] dimitern: because AFAICS the logic you've got now checks whether *any* of the splits holds the string "lxc" [16:03] rogpeppe, ah, because it could be "0", yes ofc [16:03] rogpeppe, it checks the last split first going forward [16:03] dimitern: better test case required :-) [16:03] dimitern: i'd write a test case for isRunningInLXC directly [16:03] rogpeppe, you mean add a test for isRunningInLXC specifically? [16:03] ok [16:04] dimitern: it would seem worth it, yes [16:05] dimitern: your current logic doesn't seem to test the last split moving forward... [16:05] wallyworld, perrito666 since you're on call reviewers :) PTAL https://github.com/juju/juju/pull/493 [16:06] trivial dependencies.tsv fix [16:06] jcw4: certainly [16:06] perrito666: tx [16:08] natefinch: shall I just close https://github.com/juju/juju/pull/493 ? (perrito666) [16:09] jcw4: leave it open for now, if I can't get my fix in before yours, we can just use yours. But I'd like to see if I can get mine in so godeps produces the correct result [16:10] natefinch: +1 :) [16:12] jcw4: I was really expecting a larger patch [16:12] perrito666: :) [16:12] dimitern: what calls networker.SetUp ? [16:13] dimitern: ah, it's StringsWorker [16:13] dimitern: why are privateInterface and priviateBridge global variables? [16:13] dimitern: and unguarded by a mutex [16:14] dimitern: that gets my trouble whiskers twitching [16:15] rogpeppe, that's all vlad's code, and needs some work [16:15] dimitern: but it's landed in core? hmm. [16:16] rogpeppe, yes, but it's hardly ever used for now - only with maas and only when there are networks defined [16:16] dimitern: yeah but... sigh [16:18] rogpeppe, I agree it needs refactoring, there are tech dept bugs for some things already [16:19] rogpeppe, thanks for bearing with me :) [16:20] rogpeppe, updated yet again - isrunninginlxc fixed + added a test [16:29] rogpeppe, all comments addressed or replied to, can I get LGTM? :) [16:29] is there a way to do an in-place branch in bazaar? creating a branch for some code changes is messing up the imports since it creates a new directory. [16:29] dimitern: i'm still trying to grok the test [16:31] rogpeppe, so there's a fair amount of boilerplate setup code in there [16:32] rogpeppe, the main thing is patching the executeCommands and monitoring modprobe does not happen before ifup commands [16:32] rogpeppe, I tested if fails when I comment out the && !isRunningInLXC part [16:39] natefinch: the more I think about it the more I think I should just close my PR and let you do the full fix. If we're going to fix this bug we should fix it right and your plan sounds right :) [16:40] jcw4: I have mine ready to propose anyway [16:40] natefinch: perfect; thx [16:41] dimitern: review done === Ursinha is now known as Ursinha-afk [16:42] rogpeppe, thanks! [16:44] rogpeppe: quick review? https://github.com/juju/juju/pull/494 [16:47] jcw4: ^^ [16:47] natefinch: i hope you mean "godeps -t ./..." [16:48] oh oops [16:49] rogpeppe: no, but they apparently produce the same results on github.com/juju/juju [16:50] (currently) [16:50] natefinch: i guess that's not actually too surprising [16:50] natefinch: because of the testing packages [16:50] wtf is this?! "Build failed: Does not match ['fixes-1355219', 'fixes-1347715']\n build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/261\n" [16:50] rogpeppe: yep, was thinking that [16:50] neither of those were mentioned in the PR at all [16:51] dimitern: you *need* to mention those in the PR [16:51] dimitern: because they're the critical bugs that currently need fixing [16:51] dimitern: master is locked [16:51] natefinch, rogpeppe, I see, ok [16:51] dimitern: I have this labeled as "CI blockers" in my bookmarks bar: https://bugs.launchpad.net/juju-core/+bugs?field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL [16:51] nothing to worry about then, it will get picked up by the bot when trunk is unblocked? [16:52] that I'm not sure about [16:52] you might need to repropose [16:52] * rogpeppe adds that to his bookmarks bar too [16:52] i actually want a status constantly showing whether juju-core is currently blocked [16:52] * dimitern as well, thanks! [16:52] (that link is from curtis) [16:53] rogpeppe: challenge: add it to your shell prompt ;) [16:53] natefinch: i don't believe in dynamic shell prompts [16:53] rogpeppe: ha ok [16:53] natefinch: too much noise [16:54] natefinch: i just have a single character for my prompt [16:54] rogpeppe: I find it handy for seeing the current git branch, but yeah, I get that it can be noisy [16:54] rogpeppe: where would you want to see the notification that master is blocked? [16:55] natefinch: in the (largely blank) notification bar at the top of my screen [16:55] rogpeppe, you won't like my shell prompt then: [maas-trusty] (lp-1353443-dont-modprobe-in-lxc) dimitern@kubrik:~/work/juju-core$ [16:55] :) [16:56] rogpeppe: fair enough. I hhave no idea how to do that. [16:56] dimitern: i'm surprised you've got any room to type a command there! :-) [16:56] rogpeppe, like most problems in the world, this as well can be solved with a bigger screen :D [16:56] for many of the shell commands i execute, i don't have a command prompt at all :-) [16:57] dimitern: yeah, i could do with a 6 foot by 6 foot screen :-) [16:58] natefinch: why does your PR update the mgo dependency too? [16:58] rogpeppe, but then again... who couldn't! [16:58] * dimitern needs to stop for today [16:59] DmC hack&slash awaits! [16:59] rogpeppe: it's the same commit, it was just in the wrong (not alphabetical) spot [17:00] natefinch: ha, good point :-) [17:00] dimitern: enjoy! [17:01] rogpeppe: but thanks for checking... I realized I hadn't actually double checked that the commit numbers were the same. [17:01] natefinch: reviewed [17:02] rogpeppe: what portable API could it export? [17:03] natefinch: a named pipe implementation that works on all platforms? [17:04] rogpeppe: that is a bit overkill [17:04] named pipes on windows are a bit different then on linux. They are more akin to unix sockets. [17:05] rogpeppe: it's just an implementation for net.Listener and net.Conn [17:05] (etc) === jog_ is now known as jog [17:07] natefinch: the portable API could be almost exactly that exported by the juju/sockets package [17:08] natefinch: (speaking of which, why is that package under juju at all?) [17:09] rogpeppe: that's where a bunch of our OS-specific abstractions live... probably just by accident, because thats where osenv lived first [17:10] natefinch: osenv *is* very juju specific [17:10] natefinch: sockets is not at all juju specific [17:13] natefinch: FWIW, i'm not really sure why we're using named pipes at all under windows. we could presumably just use localhost sockets instead (the current port could be stored in the unit agent directory) [17:14] natefinch: hmm, just thought: does juju-run mean that any process on the host can get root privileges? [17:15] hi natefinch [17:15] sinzui: hey [17:16] rogpeppe: that's how it was implemented in the PoC (tcp sockets bound to localhost). The run.socket actually held 127.0.0.1: :) [17:16] gsamfira: PoC ? [17:16] proof of concept [17:16] Proof of Concept [17:17] gsamfira: ah. that seems fine to me. apart from you can't hide the socket inside a root-accessible-only directory, i guess. which i *hope* we're doing currently. [17:17] TCP sockets are slower though. It was noticeable when running juju commands. [17:18] well, on windows at least, named pipes are not represented on disk [17:18] gsamfira: *really*? the sockets are that high-bandwidth? [17:18] its not bandwidth...but the whole protocol stack init process and round trip [17:19] named pipes are recommended for Inter-process communication on windows. Chrome/Firefox use them [17:19] overhead is minimal [17:19] and they behave like unix sockets [17:19] but with a file API [17:19] so you treat them as you would any file [17:19] gsamfira: i guess that a hook will make quite a lot of these connections [17:19] but it allows bidirectional communication [17:19] yes [17:19] most do [17:20] even juju-run was slower then with named pipes [17:20] the biggest issue was allocating ports though [17:20] gsamfira: that was slow? [17:20] because there is no database locally, you needed to find a free one [17:21] and each time you deploy a new charm, you need to make sure you don't overlap [17:21] a simple directory listing via juju-run would take about a second [17:21] :) [17:22] so in terms of allocating a named pipe, its simple. you have `\\.\pipe\unit-tag-run` and `\\.\pipe\unit-tag-agent` [17:24] ohh, and it was easier for an installed application (by a charm for example) to take over the port you allocated. So when a juju command would try to run, it would fail to bind on that port. [17:25] gsamfira: couldn't you just let the OS allocate one for you? [17:26] gsamfira: i guess that last is a potential problem though [17:26] you could in theory allocate a different port each time. [17:26] but in the end it was simpler just to use nate's named pipes module :) [17:26] gsamfira: :-) [17:27] named pipes is an unfortunate name [17:27] gsamfira: yeah. [17:27] especially considering that on unix it has such different behavior [17:28] namespaces are important :) [17:28] gsamfira: a better name might be fsnet, i suppose (for "file-system network") [17:28] windows.NamedPipe != linux.NamedPipe [17:28] natefinch: you couldn't possibly know how much i agree with you there :-) [17:29] natefinch: (about namespaces) [17:29] yep :) [17:29] natefinch: i still think that npipe should export a portable interface [17:29] well, its kind of hard to do [17:29] natefinch: so that anyone that wants a filesystem based listener can use it, and their code will work regardless of whether it's on windows or not [17:29] named pipes on windows allows bi-directional communication, whereas on linux it does not [17:30] rogpeppe: it's specifically a windows implementation... I think it would be a good idea to provide a different package that uses it to produce a platform-agnostic API [17:30] rogpeppe: maybe the problem is just that it should be called winnpipe or something [17:31] natefinch: what is in the npipe API that's windows-specific? [17:31] whatever it ends up being called, I would love to see it in the standard "net" package :) [17:31] natefinch: why dont you call the thing winPipes :p [17:32] natefinch: i know you've written it as a window-specific package, but i don't see why it has to be. by making it portable, you make it more useful. [17:32] s/window/windows/ [17:33] natefinch: i guess the name space argument looks quite different [17:33] rogpeppe: I'm not sure named pipes on Linux can be used in the same way [17:33] gsamfira: it wouldn't use named pipes on linux [17:33] gsamfira: it would use unix-domain sockets [17:33] hmm, but the net package already does that [17:33] gsamfira: sure. but not for windows. === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs 1355320, 1347715, 1355324 [17:33] if nate's implementation makes it into the stdlib, we should be all set :) [17:34] gsamfira: so this would be a portable way of getting the same functionality using either net directly or the windows named pipe stuff === Ursinha-afk is now known as Ursinha [17:36] my hope is that at some point we could do a rpc.Dial("local", path) and have the rpc package use named pipes on windows [17:36] and unix sockets in linux [17:36] without any 3rd party package [17:36] but I see what you are saying [17:37] a helper package would be ok until that happens [17:38] gsamfira: rpc doesn't have a Dial function :-) [17:38] gsamfira: well, the juju one anyway [17:38] rogpeppe: yeah, the real problem is that net.Listen("namedpipe", "\\.\foo") doesn't call my code on windows :) [17:38] rogpeppe: that's the cross-platform API [17:39] natefinch: we should always try to make cross-platform APIs when possible, in my view [17:39] rogpeppe, gsamfira: I'd love to get the package into the stdlib... I don't know how likely that is, though. [17:39] natefinch: platoform-specific code should be pushed down to as low a level as possible [17:39] rogpeppe: I agree completely [17:40] rogpeppe: like I said, it should live in platform-specific code inside net, if that were possible [17:40] natefinch: sure, but given that it can't why not provide an interface similar to what you'd hope the net package *should* provide [17:40] ? [17:41] natefinch: so that folks can use the abstraction your package provides without needing to write windows-specific shims like our juju/sockets package [17:42]