| Message ID | 1479211042-13260-1-git-send-email-bschanmu@redhat.com |
|---|---|
| State | Changes Requested |
| Headers | show |
On Tue, Nov 15, 2016 at 05:27:22PM +0530, bschanmu@redhat.com wrote: > From: Babu Shanmugam <bschanmu@redhat.com> > > Openstack compute manager uses FQDN to check for the hypervisors to > which the ports are bound. > > Without this fix, no instances can be launched as the hypervisor's hostname > mismatches. > > Signed-off-by: Babu Shanmugam <bschanmu@redhat.com> Can you document in vswitch.xml that this is a fully qualified domain name, and that before OVS 2.7 it was not fully qualified? (Or, before 2.6.2, if you want it backported?) Also, there is some possibility that some installations relied on this being non-fully-qualified, and if we get bug reports about that change then we'd probably have to revert it. Thanks, Ben.
On Wednesday 23 November 2016 04:01 AM, Ben Pfaff wrote: > On Tue, Nov 15, 2016 at 05:27:22PM +0530, bschanmu@redhat.com wrote: >> From: Babu Shanmugam <bschanmu@redhat.com> >> >> Openstack compute manager uses FQDN to check for the hypervisors to >> which the ports are bound. >> >> Without this fix, no instances can be launched as the hypervisor's hostname >> mismatches. >> >> Signed-off-by: Babu Shanmugam <bschanmu@redhat.com> > Can you document in vswitch.xml that this is a fully qualified domain > name, and that before OVS 2.7 it was not fully qualified? (Or, before > 2.6.2, if you want it backported?) Sure, Ben > Also, there is some possibility that some installations relied on this > being non-fully-qualified, and if we get bug reports about that change > then we'd probably have to revert it. I understand. > Thanks, > > Ben.
On Wed, Nov 23, 2016 at 1:25 AM, Babu Shanmugam <bschanmu@redhat.com> wrote: > > > On Wednesday 23 November 2016 04:01 AM, Ben Pfaff wrote: > >> On Tue, Nov 15, 2016 at 05:27:22PM +0530, bschanmu@redhat.com wrote: >> >>> From: Babu Shanmugam <bschanmu@redhat.com> >>> >>> Openstack compute manager uses FQDN to check for the hypervisors to >>> which the ports are bound. >>> >>> Without this fix, no instances can be launched as the hypervisor's >>> hostname >>> mismatches. >>> >>> Signed-off-by: Babu Shanmugam <bschanmu@redhat.com> >>> >> Can you document in vswitch.xml that this is a fully qualified domain >> name, and that before OVS 2.7 it was not fully qualified? (Or, before >> 2.6.2, if you want it backported?) >> > > Sure, Ben I think it should be backported as well. > > > Also, there is some possibility that some installations relied on this >> being non-fully-qualified, and if we get bug reports about that change >> then we'd probably have to revert it. >> > > I understand. This current patch certainly makes things easier on the Neutron OVN driver, so with that hat on I like this change. :-) With my OVS maintainer hat on, I'm worried about breaking people, like Ben said. Since this was such a recent addition (new in 2.6), maybe nobody else is relying on it yet. We can hope for that! If anyone complains, we could just add a new external-id called "fqdn" or something, but that would also require changes to ovn-controller to expose that via the chassis record and some changes to the Neutron OVN driver to make use of the new field.
On Wed, Nov 23, 2016 at 02:56:52PM -0500, Russell Bryant wrote: > On Wed, Nov 23, 2016 at 1:25 AM, Babu Shanmugam <bschanmu@redhat.com> wrote: > > > > > > > On Wednesday 23 November 2016 04:01 AM, Ben Pfaff wrote: > > > >> On Tue, Nov 15, 2016 at 05:27:22PM +0530, bschanmu@redhat.com wrote: > >> > >>> From: Babu Shanmugam <bschanmu@redhat.com> > >>> > >>> Openstack compute manager uses FQDN to check for the hypervisors to > >>> which the ports are bound. > >>> > >>> Without this fix, no instances can be launched as the hypervisor's > >>> hostname > >>> mismatches. > >>> > >>> Signed-off-by: Babu Shanmugam <bschanmu@redhat.com> > >>> > >> Can you document in vswitch.xml that this is a fully qualified domain > >> name, and that before OVS 2.7 it was not fully qualified? (Or, before > >> 2.6.2, if you want it backported?) > >> > > > > Sure, Ben > > > I think it should be backported as well. > > > > > > > > Also, there is some possibility that some installations relied on this > >> being non-fully-qualified, and if we get bug reports about that change > >> then we'd probably have to revert it. > >> > > > > I understand. > > > This current patch certainly makes things easier on the Neutron OVN driver, > so with that hat on I like this change. :-) > > With my OVS maintainer hat on, I'm worried about breaking people, like Ben > said. Since this was such a recent addition (new in 2.6), maybe nobody > else is relying on it yet. We can hope for that! I think that it's likely to be fine. > If anyone complains, we could just add a new external-id called "fqdn" or > something, but that would also require changes to ovn-controller to expose > that via the chassis record and some changes to the Neutron OVN driver to > make use of the new field. That's an idea too.
diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in index ce3fb58..79979c3 100755 --- a/utilities/ovs-ctl.in +++ b/utilities/ovs-ctl.in @@ -108,7 +108,7 @@ set_system_ids () { esac set "$@" external-ids:system-id="\"$SYSTEM_ID\"" - set "$@" external-ids:hostname="\"$(hostname)\"" + set "$@" external-ids:hostname="\"$(hostname -f)\"" if test X"$SYSTEM_TYPE" != X; then set "$@" system-type="\"$SYSTEM_TYPE\""