On 2/25/21 2:34 PM, Frode Nordahl wrote: > 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.
OK. Sounds good to me. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev