On 2/25/21 6:56 AM, Frode Nordahl wrote: > On Wed, Feb 24, 2021 at 5:36 PM Ilya Maximets <[email protected]> wrote: >> >> On 2/19/21 9:10 AM, Christian Ehrhardt wrote: >>> On Tue, Feb 16, 2021 at 5:32 PM Frode Nordahl >>> <[email protected]> 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 <[email protected]> >>> >>> 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 <[email protected]> >>> >> >> 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/[email protected]/ > > 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? _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
