On Thu, Feb 25, 2021 at 1:33 PM Ilya Maximets <i.maxim...@ovn.org> wrote: > > On 2/25/21 6:56 AM, Frode Nordahl wrote: > > On Wed, Feb 24, 2021 at 5:36 PM Ilya Maximets <i.maxim...@ovn.org> wrote: > >> > >> On 2/19/21 9:10 AM, Christian Ehrhardt wrote: > >>> On Tue, Feb 16, 2021 at 5:32 PM Frode Nordahl > >>> <frode.nord...@canonical.com> wrote: > >>>> > >>>> ovs-ctl determines the system FQDN or hostname and records it in > >>>> the `external-ids:hostname` field of the `Open-vSwitch` table on > >>>> system startup. > >>>> > >>>> This value may be consumed by downstream software and having it > >>>> unset or set to a incorrect value could lead to erratic behavior > >>>> of a system. > >>>> > >>>> When a system is configured to use a Open vSwitch controlled > >>>> datapath as its only network connection, the current ordering of > >>>> events would always produce a unreliable hostname > >>>> > >>>> Reported-At: https://bugs.launchpad.net/bugs/1915829 > >>>> Signed-off-by: Frode Nordahl <frode.nord...@canonical.com> > >>> > >>> I've looked at this for the Ubuntu problem that started Frodes work, > >>> and while I can't give any authoritative Ack I can at least say > >>> > >>> Reviewed-by: Christian Ehrhardt <christian.ehrha...@canonical.com> > >>> > >> > >> Hi. Reading the description and the bug on launchpad it seems that > >> the issue is that hostname in database changes in unexpected way and > >> this is somewhat similar to what the following patch tried to fix: > >> > >> http://patchwork.ozlabs.org/project/openvswitch/patch/20200525152821.19838-1-dalva...@redhat.com/ > > > > Hello Ilya, and thank you for the review. > > > >> Is it still a problem with above patch applied? > > > > Yes, while the above patch is welcome and adds to the stability of the > > identifier, it does not solve the problem this patch addresses. > > > > What we see is that the data collected for the initial recording of > > the hostname field is incorrect. This occurs because the information > > might not be available at the time of initial Open vSwitch startup. > > > > We support the use of Open vSwitch to manage the only connection a > > computer has to a network, and to do that we start Open vSwitch early > > as part of the network target (in systemd terms). At this point in > > time there may be no network connectivity yet, depending on deployment > > type initial system configuration may not yet be applied (i.e. > > /etc/hostname may hold a default unconfigured value), FQDN hints may > > not yet be recorded in /etc/hosts etc. > > > > We seek to resolve this class of issues by breaking the hostname > > recording part out into a separate oneshot service [0] run after the > > network is online. > > > > To help support that we need to be able to manage whether and when > > `ovs-ctl` performs the recording of the hostname. > > > > 0: > > https://code.launchpad.net/~fnordahl/ubuntu/+source/openvswitch/+git/openvswitch/+merge/398174 > > > > Thanks for clarification. I see your point and I think it's OK to > have this change. One comment though: with this change 'record-hostname' > command will not do anything if hostname was already configured. > While this behavior is described in a 'help' message, this looks a bit > counterintuitive anyway. We should, probably, force it to re-write > currently set value or rename somehow, e.g. 'record-hostname-if-not-set' > or 'your better suggestion here'. > > What do you think?
Thank you for the feedback, and I do indeed agree that the command should be more clear as to what it actually does in the event of data already being set. The only other suggestion I have is to use '--may-exist' like the *-ctl commands to overwrite, but it would probably not help with clarity as one would then still have to look at the manual, and in addition wonder which of the commands that switch applies to. I'll post a v2 using your suggestion with 'record-hostname-if-not-set' as the name of the command. -- Frode Nordahl _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
