On Tue, Aug 9, 2016 at 9:10 AM, Christian Svensson wrote:
>
> ovs-appctl -t $PWD/my-daemon.$(
To compromise on the client side:
How would you feel making ovs-appctl and socket_name_from_target look for
both naming schemes?
Psuedo code:
if isfile(target + '.ctl'):
return targ
On Wed, Aug 10, 2016 at 11:51 PM, Ben Pfaff wrote:
>
> Hmm. I think that OVS actually solves all of these problems. First,
> the return code of the parent should be correct, in that if the child
> fails to start properly the parent exits with a nonzero exit code.
> Second, observers can ensure
On Wed, Aug 10, 2016 at 10:30 PM, Aaron Conole wrote:
>
> > On a related note, it would be good to improve the ovn-northd and
> ovn-controller systemd units to
> > use type=forking instead of type=oneshot as well, if you happened to be
> interested in helping
> > improve that too. :-)
>
> I certa
Hi,
On Wed, Aug 10, 2016 at 6:15 PM, Ben Pfaff wrote:
> This is how OVS works.
>
Only when specifically launched with --detach. It's not the binary default,
which I feel is important to note.
> What's the advantage of sd_notify? You say that sd_notify() is
> "recommended". By whom, and wher
Hi,
As far as I understand, right now the daemonizing flow for an OVS process
is:
1. Process calls daemonize_start to fork into a child if running in
detached mode
Parent waits until daemonize_complete is called
2. Child (or parent if not daemonized) executes initialization
3. daemonize_complet
On Mon, Aug 8, 2016 at 11:59 PM, Ben Pfaff wrote:
>
> Including the PID allows multiple daemons of a single type to run.
While technically true, in practice I would argue this doesn't hold and is
indeed one of the reason I made this change.
The documented way to connect to a daemon is "ovs-appct
On Mon, Aug 8, 2016 at 7:59 PM, Ben Pfaff wrote:
> OK, let's add that then.
>
I forgot to add a critical point why I'm not ready to consider the
alternative yet:
One of the optional goals I'm trying to achieve is that ovs-appctl -t
my-daemon should still work (keeping all documentation etc.), wh
On Mon, Aug 8, 2016 at 7:59 PM, Ben Pfaff wrote:
> OK, let's add that then.
>
While it's an alternative, I feel like going down that path is hasty and
for my use case I will probably just patch our local fork of OpenvSwitch.
Why so hostile towards this change? Is there a better forum I can expl
Thanks for the comments.
On Mon, Aug 8, 2016 at 6:29 PM, Ben Pfaff wrote:
>
> I don't think it's reasonable to make this a configuration-time option.
> I want Open vSwitch behavior to be fairly uniform at runtime, not
> unpredictable based on whatever flags were supplied at build time.
>
Isn't i
/114.
Signed-off-by: Christian Svensson
---
AUTHORS| 1 +
Makefile.am| 8
configure.ac | 1 +
lib/unixctl.c | 4 +++-
m4/openvswitch.m4 | 26 ++
ovsdb/ovsdb-client.c
On Tue, Aug 2, 2016 at 12:42 PM, Christian Svensson
wrote:
> I just noticed that the first patch only was a URL, retrying with the real
> patch attached.
This is weird.
I'm unable to attach the patch, and 'git send-email' based patches never
show up in the archive, even t
On Fri, Jul 29, 2016 at 11:53 PM, Christian Svensson
wrote:
> [Sorry in advance for the formatting, submitting on mobile. Raw patch
> attached.]
>
I just noticed that the first patch only was a URL, retrying with the real
patch attached.
>
> Sorr
in detached mode.
This closes https://github.com/openvswitch/ovs-issues/issues/114.
Signed-off-by: Christian Svensson
---
AUTHORS| 1 +
Makefile.am| 4
configure.ac | 1 +
lib/unixctl.c | 4 +++-
m4
13 matches
Mail list logo
