Look for network plugin using name as path

[tomdee]

Solves the problem where the plugin path is hardcoded to a
read only directory on CoreOS.

This approach allows the most flexibility for plugin users
and is straightforward to implement.

Fixes #1948

[jonboulle]

I am kinda torn on whether this follows the principle of least surprise. @steveej thoughts? regardless, we definitely need some solution here

[jonboulle]

@tomdee would you be open to taking care of that TODO and making this configurable ? I'm a little concerned about the current implementation because I don't like that rkt might then behave differently depending on which directory it's run from.
/cc @krnowak

[tomdee]

OK, I'll take another punt at it. I would really like to get this into the next rkt release - how long do I have to get something merged?

[jonboulle]

We're currently targeting the 21st for the next release. We'll do our best
to give timely reviews etc and get it merged.

On Fri, Jan 15, 2016 at 6:17 PM, Tom Denham notifications@github.com
wrote:

OK, I'll take another punt at it. I would really like to get this into the
next rkt release - how long do I have to get something merged?

—
Reply to this email directly or view it on GitHub
#1950 (comment).

[tomdee]

A little design - am I on the right track? @jonboulle

• I'm adding a new field "netPlugin" next to "data" in rktKind: paths
• I'm not changing the rktVersion from v1. (Since I'm just adding a new field, older versions will just ignore it)
• I'm adding a new --netplugindir option to the rkt binary

Sounds OK?

[tomdee]

I've put up a first attempt of this here #1992

I can add tests and docs if you're happy with the approach

[jonboulle]

Closing in favour of #1992 and #2005.