On Tue, Jun 02, 2015 at 11:17:29AM -0400, Russell Bryant wrote: > On 06/02/2015 09:24 AM, Flavio Leitner wrote: > > On Fri, May 29, 2015 at 02:51:26PM -0700, Ben Pfaff wrote: > >> On Fri, May 29, 2015 at 05:07:19PM -0400, Russell Bryant wrote: > >>> On 05/29/2015 04:50 PM, Ben Pfaff wrote: > >>>> On Fri, Apr 24, 2015 at 01:06:06PM -0400, Russell Bryant wrote: > >>>>> This patch creates a new subpackage for OVN, openvswitch-ovn. It also > >>>>> installs systemd unit files for ovncontroller and ovnnorthd services. > >>>>> Finally, it installs some template service configuration files into > >>>>> /etc/sysconfig/. > >>>>> > >>>>> If you want to run ovn-controller on a host running ovs: > >>>>> > >>>>> # systemctl start ovncontroller > >>>>> > >>>>> If you want to run ovn-northd and ovsdb-server on a management host: > >>>>> > >>>>> # systemctl start ovnnorthd > >>>>> > >>>>> If you want to run all of ovs and ovn on the same host: > >>>>> > >>>>> # cat << EOF > /etc/sysconfig/openvswitch > >>>>> OPTIONS="'--extra-dbs=ovnnb.db ovnsb.db'" > >>>>> EOF > >>>>> > >>>>> # cat << EOF > /etc/sysconfig/ovnnorthd > >>>>> OPTIONS="--no-ovsdb-server" > >>>>> EOF > >>>>> > >>>>> # ovn-ctl create_ovn_dbs > >>>>> # systemctl start openvswitch > >>>>> # systemctl start ovnnorthd > >>>>> # systemctl start ovncontroller > >>>>> > >>>>> Signed-off-by: Russell Bryant <rbry...@redhat.com> > >>>> > >>>> This looks nice but it seems awkward to have to edit config files if you > >>>> want to run both OVS and OVN on a host. Do you think there's a way to > >>>> make it simply a matter of starting both services? > >>> > >>> I agree that it's a little awkward. It's a bit better in the latest > >>> rev, but you still have to create the ovn dbs and edit the openvswitch > >>> config to use them. > >>> > >>> http://openvswitch.org/pipermail/dev/2015-May/055586.html > >>> > >>> I hadn't thought of a good way to make it better, but let's see ... > >>> > >>> I see that ovsdb-server supports a command over the appctl unix socket > >>> to tell it to add a db. We could make ovn-northd automatically create > >>> the dbs if they're not present and tell ovsdb-server to add them. That > >>> should make it as simple as just starting the services. > >> > >> You could make it tell ovsdb-server to add them, or you could just make > >> it restart ovsdb-server, which is not very expensive (and all the > >> clients will automatically reconnect). > > > > I like this idea. > > OK thanks, I'll work on this. > > >> By the way, on Debian I got in some trouble for initially putting the > >> OVS configuration DB into /etc/openvswitch, because the rule there is > >> that only human-readable and -editable files should be in /etc. Thus, > >> in the official Debian packaging the database is in /var/lib/openvswitch > >> instead (with a symlink from /etc/openvswitch). This has been a thorn > >> in my side ever since. It would be really nice, therefore, not to > >> repeat the issue with the new databases, by putting them in > >> /var/lib/openvswitch to begin with. > > > > Same here, but what about the inconsistency between OVN and OVS? > > It seems better to just start the "right" way instead of leaving a sym > link in the "wrong" place to be consistent.
Well, we could do that also for OVS. I thought OVN would go only for the "right" way and leave /etc alone. > >>> A downside is that would make a built-in assumption in ovn-northd that > >>> it runs local to ovsdb-server. The systemd unit file assumes that right > >>> now, but the code doesn't (and probably shouldn't). The same general > >>> thing could be implemented in a shell wrapper for ovn-northd ... which > >>> sounds kind of like ovn-ctl, so maybe I should go back to making use of > >>> that. > >> > >> Sounds like you've got it all worked out. > > > > How would you find if ovsdb-server is local or not? > > From ovn-northd's perspective, the ovsdb remote is just a command line > argument. Ok, that's good. It looks like a modified local copy of the systemd unit would be enough. See: http://www.freedesktop.org/software/systemd/man/systemd.unit.html section: Example 2. Overriding vendor settings > For the ovn-northd systemd unit, it assumes its local right now, but we > could make it configurable, I guess. It seems pretty reasonable to > expect that they are co-located for now. Both are central components, > so I say we just revisit whenever the architecture changes in some > drastic way (ovn-northd becomes horizontally scalable, or more > importantly, ovsdb-server becomes distributed or gets replaced by > something that is). I can't tell if expecting to be local or remote is reasonable. My concern is if we are not wrapping up something that is expected and supported by systemd. Of course, project's preferences matters, so it pretty much depends on what the shell wrapper has to offer in terms of improving the user experience. Just keep in mind that systemd doesn't allow you to pass arbitrary parameters to the service unit, so doing things like hot upgrade can be really difficult with a wrapper in the middle trying to be clever. fbl _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
