Better Heuristic For Finding Openflow Executable

[craig-riecke]

When Frenetic runs with http-controller, it starts up the separate executable openflow.native as a subprocess. This works fine for programming in Python or REST. However, it doesn't work well when building a monolithic OCaml Frenetic app (basically the Northbound app is compiled in with Frenetic itself).

Currently the workaround is to create a symbolic link to openflow.native in the same directory as the monolithic app executable, as show in the Wiki. It'd be nice not to require that.

[smolkaj]

Just compile with make install. Then openflow should be on the PATH.

[craig-riecke]

Yeah, that would work ... if a monolithic app looked on the PATH. It doesn't. It only looks for openflow or openflow.native in the same directory as the executable you're running. The logic is in Frenetic_OpenFlow0x01_Controller.ml line 30.

It should be an easy fix.

[jnfoster]

Wait. Why do we have two executables anyway? It seems like it only causes
confusion with PATH, etc. I think we should run frenetic.native twice (or n
times) with different command-line arguments -- once for the high-level
controller and once for the low-level controller. The first one could even
fork() to create the other copies so we only need one invocation at the
command line.

-N

On Tue, Jun 21, 2016 at 3:03 PM, Craig Riecke [email protected]
wrote:

Yeah, that would work ... if a monolithic app looked on the PATH. It
doesn't. It only looks for openflow or openflow.native in the same
directory as the executable you're running. The logic is in
Frenetic_OpenFlow0x01_Controller.ml line 30.

It should be an easy fix.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#508 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABwi0gzfkXPGqw5W4reJteIBYXDfm3z8ks5qODV-gaJpZM4I6sgQ
.

[craig-riecke]

@jnfoster We do use one invocation - the frenetic.native binary (or the monolithic app) starts the openflow.native binary through Process.create. It would be great to use fork instead, but we can't because of Async. Or rather, the Async scheduler - we start it up to handle some deferred's and ivar's (they are needed for other parts of Frenetic) prior to creating the openflow.native process. If we forked, the Async scheduler would be totally mucked up in the child process, ref: https://groups.google.com/forum/#!topic/ocaml-core/an6dwjN_yCY

We could do one binary, but a monolithic app would have the same problem finding frenetic.native - Process.create doesn't look through the PATH by default. Unless maybe it started another copy of itself...

[smolkaj]

good point...

[jnfoster]

Not sure which point is a good one.

It would still be my preference to have a single binary -- it eliminates
complexity in several places.

-N

On Wed, Jun 22, 2016 at 1:53 PM, Steffen Smolka [email protected]
wrote:

good point...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#508 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABwi0jFm3fmulD6ULWn7rr9KTLY0sEq7ks5qOXZ_gaJpZM4I6sgQ
.

[smolkaj]

"Good point" was referring to Nate's comment. Having two binaries trying to find each other sounds like it will break very easily. There must be a way around it.

Craig, under the link you posted they mention reset_in_forked_process. Can't we use that?