Re: [ovs-dev] [PATCH ovn v2] Provide the option to pin ovn-controller and ovn-northd to a specific version.
On Wed, Nov 18, 2020 at 6:52 PM Dumitru Ceara wrote: > > On 11/18/20 2:08 PM, Numan Siddique wrote: > > On Wed, Nov 18, 2020 at 5:23 PM Dumitru Ceara wrote: > >> > >> On 11/17/20 12:57 PM, num...@ovn.org wrote: > >>> From: Numan Siddique > >>> > >>> OVN recommends updating/upgrading ovn-controllers first and then > >>> ovn-northd and OVN DB ovsdb-servers. This is to ensure that any > >>> new functionality specified by the database or logical flows created > >>> by ovn-northd is understood by ovn-controller. > >>> > >>> However certain deployments may upgrade ovn-northd services first and > >>> then ovn-controllers. In a large scal deployment, this can result in > >>> downtime during upgrades as old ovn-controllers may not understand > >>> new logical flows or new actions added by ovn-northd. > >>> > >>> Even with upgrading ovn-controllers first, can result in ovn-controllers > >>> rejecting some of the logical flows if an existing OVN action is > >>> changed. One such example is ct_commit action which recently was updated > >>> to take new arguments. > >>> > >>> To avoid such downtimes during upgrades, this patch adds the > >>> functionality of pinning ovn-controller and ovn-northd to a specific > >>> version. An internal OVN version is generated and this version is stored > >>> by ovn-northd in the Southbound SB_Global table's > >>> options:northd_internal_version. > >>> > >>> When ovn-controller notices that the internal version has changed, it > >>> stops handling the database changes - both Southbound and OVS. All the > >>> existing OF flows are preserved. When ovn-controller is upgraded to the > >>> same version as ovn-northd services, it will process the database > >>> changes. > >>> > >>> This feature is made optional and disabled by default. Any CMS can > >>> enable it by configuring the OVS local database with the option - > >>> ovn-pin-to-northd=false. > >>> > >>> Signed-off-by: Numan Siddique > >>> --- > >> > >> Hi Numan, > >> > >> Next to Flavio's comments I have some too. > >> > > > > Thanks Flavio and Dumitru for the reviews. > > > > > >>> > >>> v1 -> v2 > >>> > >>> * Added test cases and missing documentation. > >>> * Renamed the ovsdb option from ignore_northd_verison > >>> to ovn-pin-to-northd. > >>> * Added NEWS item. > >>> > >>> NEWS| 3 + > >>> controller/ovn-controller.8.xml | 11 +++ > >>> controller/ovn-controller.c | 58 - > >>> lib/ovn-util.c | 17 > >>> lib/ovn-util.h | 4 + > >>> northd/ovn-northd.c | 18 +++- > >>> tests/ovn.at| 147 > >>> 7 files changed, 251 insertions(+), 7 deletions(-) > >>> > >>> diff --git a/NEWS b/NEWS > >>> index 6010230679..bb95724b36 100644 > >>> --- a/NEWS > >>> +++ b/NEWS > >>> @@ -8,6 +8,9 @@ Post-v20.09.0 > >>> server. > >>> - Support other_config:vlan-passthru=true to allow VLAN tagged > >>> incoming > >>> traffic. > >>> + - Support version pinning between ovn-northd and ovn-controller as an > >>> + option. If the option is enabled and the versions don't match, > >>> + ovn-controller will not process any DB changes. > >>> > >>> OVN v20.09.0 - 28 Sep 2020 > >>> -- > >>> diff --git a/controller/ovn-controller.8.xml > >>> b/controller/ovn-controller.8.xml > >>> index 16bc47b205..357edd1f5c 100644 > >>> --- a/controller/ovn-controller.8.xml > >>> +++ b/controller/ovn-controller.8.xml > >>> @@ -233,6 +233,17 @@ > >>> The boolean flag indicates if the chassis is used as an > >>> interconnection gateway. > >>> > >>> + > >>> + external_ids:ovn-pin-to-northd > >> > >> This still seems misleading to me. We don't actually pin to a northd > >> version, we pin to an OVN internal version. What if we call it > >> "ovn-pin-to-version"? > > > > It's true that we pin to the OVN internal version, but my idea is that > > ovn-northd writes > > its internal version to SB_Global. And ovn-controller reads the northd > > version and compares > > with its own version. > > > > Few other points > > - I think ovn-pin-to-northd (or ovn-pin-to-northd-version) makes > > sense from a CMS point of view. > > - CMS doesn't need to know about the internal version mechanism used. > > - In production deployments when northd services are updated first, > > ovn-northd will update its new > > internal version to SB_Global. > > - And the idea of this patch is to pin the controller to the same > > northd version. > > So I guess this translates to "make ovn-controller reject SB contents if > they were created by the wrong northd version". > > > > > So I'd prefer to call it ovn-pin-to-northd. > > > > With that in mind, and considering your explanation, what about > "ovn-match-northd-version"? Sounds better. Thanks. > > > > >> > >>> + > >>> +The boolean flag indicates if ovn-controller needs > >>> to >
Re: [ovs-dev] [PATCH ovn v2] Provide the option to pin ovn-controller and ovn-northd to a specific version.
On 11/18/20 2:08 PM, Numan Siddique wrote: > On Wed, Nov 18, 2020 at 5:23 PM Dumitru Ceara wrote: >> >> On 11/17/20 12:57 PM, num...@ovn.org wrote: >>> From: Numan Siddique >>> >>> OVN recommends updating/upgrading ovn-controllers first and then >>> ovn-northd and OVN DB ovsdb-servers. This is to ensure that any >>> new functionality specified by the database or logical flows created >>> by ovn-northd is understood by ovn-controller. >>> >>> However certain deployments may upgrade ovn-northd services first and >>> then ovn-controllers. In a large scal deployment, this can result in >>> downtime during upgrades as old ovn-controllers may not understand >>> new logical flows or new actions added by ovn-northd. >>> >>> Even with upgrading ovn-controllers first, can result in ovn-controllers >>> rejecting some of the logical flows if an existing OVN action is >>> changed. One such example is ct_commit action which recently was updated >>> to take new arguments. >>> >>> To avoid such downtimes during upgrades, this patch adds the >>> functionality of pinning ovn-controller and ovn-northd to a specific >>> version. An internal OVN version is generated and this version is stored >>> by ovn-northd in the Southbound SB_Global table's >>> options:northd_internal_version. >>> >>> When ovn-controller notices that the internal version has changed, it >>> stops handling the database changes - both Southbound and OVS. All the >>> existing OF flows are preserved. When ovn-controller is upgraded to the >>> same version as ovn-northd services, it will process the database >>> changes. >>> >>> This feature is made optional and disabled by default. Any CMS can >>> enable it by configuring the OVS local database with the option - >>> ovn-pin-to-northd=false. >>> >>> Signed-off-by: Numan Siddique >>> --- >> >> Hi Numan, >> >> Next to Flavio's comments I have some too. >> > > Thanks Flavio and Dumitru for the reviews. > > >>> >>> v1 -> v2 >>> >>> * Added test cases and missing documentation. >>> * Renamed the ovsdb option from ignore_northd_verison >>> to ovn-pin-to-northd. >>> * Added NEWS item. >>> >>> NEWS| 3 + >>> controller/ovn-controller.8.xml | 11 +++ >>> controller/ovn-controller.c | 58 - >>> lib/ovn-util.c | 17 >>> lib/ovn-util.h | 4 + >>> northd/ovn-northd.c | 18 +++- >>> tests/ovn.at| 147 >>> 7 files changed, 251 insertions(+), 7 deletions(-) >>> >>> diff --git a/NEWS b/NEWS >>> index 6010230679..bb95724b36 100644 >>> --- a/NEWS >>> +++ b/NEWS >>> @@ -8,6 +8,9 @@ Post-v20.09.0 >>> server. >>> - Support other_config:vlan-passthru=true to allow VLAN tagged incoming >>> traffic. >>> + - Support version pinning between ovn-northd and ovn-controller as an >>> + option. If the option is enabled and the versions don't match, >>> + ovn-controller will not process any DB changes. >>> >>> OVN v20.09.0 - 28 Sep 2020 >>> -- >>> diff --git a/controller/ovn-controller.8.xml >>> b/controller/ovn-controller.8.xml >>> index 16bc47b205..357edd1f5c 100644 >>> --- a/controller/ovn-controller.8.xml >>> +++ b/controller/ovn-controller.8.xml >>> @@ -233,6 +233,17 @@ >>> The boolean flag indicates if the chassis is used as an >>> interconnection gateway. >>> >>> + >>> + external_ids:ovn-pin-to-northd >> >> This still seems misleading to me. We don't actually pin to a northd >> version, we pin to an OVN internal version. What if we call it >> "ovn-pin-to-version"? > > It's true that we pin to the OVN internal version, but my idea is that > ovn-northd writes > its internal version to SB_Global. And ovn-controller reads the northd > version and compares > with its own version. > > Few other points > - I think ovn-pin-to-northd (or ovn-pin-to-northd-version) makes > sense from a CMS point of view. > - CMS doesn't need to know about the internal version mechanism used. > - In production deployments when northd services are updated first, > ovn-northd will update its new > internal version to SB_Global. > - And the idea of this patch is to pin the controller to the same > northd version. So I guess this translates to "make ovn-controller reject SB contents if they were created by the wrong northd version". > > So I'd prefer to call it ovn-pin-to-northd. > With that in mind, and considering your explanation, what about "ovn-match-northd-version"? > >> >>> + >>> +The boolean flag indicates if ovn-controller needs to >>> +be pinned to the exact ovn-northd version. If this >>> +flag is set to true and the ovn-northd's version >>> (reported >>> +in the Southbound database) doesn't match with the >>> +ovn-controller's internal version, then it will stop >>> +processing the Southbound and local Open vSwitch
Re: [ovs-dev] [PATCH ovn v2] Provide the option to pin ovn-controller and ovn-northd to a specific version.
On Wed, Nov 18, 2020 at 5:23 PM Dumitru Ceara wrote: > > On 11/17/20 12:57 PM, num...@ovn.org wrote: > > From: Numan Siddique > > > > OVN recommends updating/upgrading ovn-controllers first and then > > ovn-northd and OVN DB ovsdb-servers. This is to ensure that any > > new functionality specified by the database or logical flows created > > by ovn-northd is understood by ovn-controller. > > > > However certain deployments may upgrade ovn-northd services first and > > then ovn-controllers. In a large scal deployment, this can result in > > downtime during upgrades as old ovn-controllers may not understand > > new logical flows or new actions added by ovn-northd. > > > > Even with upgrading ovn-controllers first, can result in ovn-controllers > > rejecting some of the logical flows if an existing OVN action is > > changed. One such example is ct_commit action which recently was updated > > to take new arguments. > > > > To avoid such downtimes during upgrades, this patch adds the > > functionality of pinning ovn-controller and ovn-northd to a specific > > version. An internal OVN version is generated and this version is stored > > by ovn-northd in the Southbound SB_Global table's > > options:northd_internal_version. > > > > When ovn-controller notices that the internal version has changed, it > > stops handling the database changes - both Southbound and OVS. All the > > existing OF flows are preserved. When ovn-controller is upgraded to the > > same version as ovn-northd services, it will process the database > > changes. > > > > This feature is made optional and disabled by default. Any CMS can > > enable it by configuring the OVS local database with the option - > > ovn-pin-to-northd=false. > > > > Signed-off-by: Numan Siddique > > --- > > Hi Numan, > > Next to Flavio's comments I have some too. > Thanks Flavio and Dumitru for the reviews. > > > > v1 -> v2 > > > > * Added test cases and missing documentation. > > * Renamed the ovsdb option from ignore_northd_verison > > to ovn-pin-to-northd. > > * Added NEWS item. > > > > NEWS| 3 + > > controller/ovn-controller.8.xml | 11 +++ > > controller/ovn-controller.c | 58 - > > lib/ovn-util.c | 17 > > lib/ovn-util.h | 4 + > > northd/ovn-northd.c | 18 +++- > > tests/ovn.at| 147 > > 7 files changed, 251 insertions(+), 7 deletions(-) > > > > diff --git a/NEWS b/NEWS > > index 6010230679..bb95724b36 100644 > > --- a/NEWS > > +++ b/NEWS > > @@ -8,6 +8,9 @@ Post-v20.09.0 > > server. > > - Support other_config:vlan-passthru=true to allow VLAN tagged incoming > > traffic. > > + - Support version pinning between ovn-northd and ovn-controller as an > > + option. If the option is enabled and the versions don't match, > > + ovn-controller will not process any DB changes. > > > > OVN v20.09.0 - 28 Sep 2020 > > -- > > diff --git a/controller/ovn-controller.8.xml > > b/controller/ovn-controller.8.xml > > index 16bc47b205..357edd1f5c 100644 > > --- a/controller/ovn-controller.8.xml > > +++ b/controller/ovn-controller.8.xml > > @@ -233,6 +233,17 @@ > > The boolean flag indicates if the chassis is used as an > > interconnection gateway. > > > > + > > + external_ids:ovn-pin-to-northd > > This still seems misleading to me. We don't actually pin to a northd > version, we pin to an OVN internal version. What if we call it > "ovn-pin-to-version"? It's true that we pin to the OVN internal version, but my idea is that ovn-northd writes its internal version to SB_Global. And ovn-controller reads the northd version and compares with its own version. Few other points - I think ovn-pin-to-northd (or ovn-pin-to-northd-version) makes sense from a CMS point of view. - CMS doesn't need to know about the internal version mechanism used. - In production deployments when northd services are updated first, ovn-northd will update its new internal version to SB_Global. - And the idea of this patch is to pin the controller to the same northd version. So I'd prefer to call it ovn-pin-to-northd. > > > + > > +The boolean flag indicates if ovn-controller needs to > > +be pinned to the exact ovn-northd version. If this > > +flag is set to true and the ovn-northd's version > > (reported > > +in the Southbound database) doesn't match with the > > +ovn-controller's internal version, then it will stop > > +processing the Southbound and local Open vSwitch database changes. > > +The default value is considered false if this option is not > > defined. > > + > > > > > > > > diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c > > index a06cae3ccb..a7344ea9c4 100644 > > --- a/controller/ovn-controller.c > > +++
Re: [ovs-dev] [PATCH ovn v2] Provide the option to pin ovn-controller and ovn-northd to a specific version.
On 11/17/20 12:57 PM, num...@ovn.org wrote:
> From: Numan Siddique
>
> OVN recommends updating/upgrading ovn-controllers first and then
> ovn-northd and OVN DB ovsdb-servers. This is to ensure that any
> new functionality specified by the database or logical flows created
> by ovn-northd is understood by ovn-controller.
>
> However certain deployments may upgrade ovn-northd services first and
> then ovn-controllers. In a large scal deployment, this can result in
> downtime during upgrades as old ovn-controllers may not understand
> new logical flows or new actions added by ovn-northd.
>
> Even with upgrading ovn-controllers first, can result in ovn-controllers
> rejecting some of the logical flows if an existing OVN action is
> changed. One such example is ct_commit action which recently was updated
> to take new arguments.
>
> To avoid such downtimes during upgrades, this patch adds the
> functionality of pinning ovn-controller and ovn-northd to a specific
> version. An internal OVN version is generated and this version is stored
> by ovn-northd in the Southbound SB_Global table's
> options:northd_internal_version.
>
> When ovn-controller notices that the internal version has changed, it
> stops handling the database changes - both Southbound and OVS. All the
> existing OF flows are preserved. When ovn-controller is upgraded to the
> same version as ovn-northd services, it will process the database
> changes.
>
> This feature is made optional and disabled by default. Any CMS can
> enable it by configuring the OVS local database with the option -
> ovn-pin-to-northd=false.
>
> Signed-off-by: Numan Siddique
> ---
Hi Numan,
Next to Flavio's comments I have some too.
>
> v1 -> v2
>
> * Added test cases and missing documentation.
> * Renamed the ovsdb option from ignore_northd_verison
> to ovn-pin-to-northd.
> * Added NEWS item.
>
> NEWS| 3 +
> controller/ovn-controller.8.xml | 11 +++
> controller/ovn-controller.c | 58 -
> lib/ovn-util.c | 17
> lib/ovn-util.h | 4 +
> northd/ovn-northd.c | 18 +++-
> tests/ovn.at| 147
> 7 files changed, 251 insertions(+), 7 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 6010230679..bb95724b36 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -8,6 +8,9 @@ Post-v20.09.0
> server.
> - Support other_config:vlan-passthru=true to allow VLAN tagged incoming
> traffic.
> + - Support version pinning between ovn-northd and ovn-controller as an
> + option. If the option is enabled and the versions don't match,
> + ovn-controller will not process any DB changes.
>
> OVN v20.09.0 - 28 Sep 2020
> --
> diff --git a/controller/ovn-controller.8.xml b/controller/ovn-controller.8.xml
> index 16bc47b205..357edd1f5c 100644
> --- a/controller/ovn-controller.8.xml
> +++ b/controller/ovn-controller.8.xml
> @@ -233,6 +233,17 @@
> The boolean flag indicates if the chassis is used as an
> interconnection gateway.
>
> +
> + external_ids:ovn-pin-to-northd
This still seems misleading to me. We don't actually pin to a northd
version, we pin to an OVN internal version. What if we call it
"ovn-pin-to-version"?
> +
> +The boolean flag indicates if ovn-controller needs to
> +be pinned to the exact ovn-northd version. If this
> +flag is set to true and the ovn-northd's version
> (reported
> +in the Southbound database) doesn't match with the
> +ovn-controller's internal version, then it will stop
> +processing the Southbound and local Open vSwitch database changes.
> +The default value is considered false if this option is not defined.
> +
>
>
>
> diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> index a06cae3ccb..a7344ea9c4 100644
> --- a/controller/ovn-controller.c
> +++ b/controller/ovn-controller.c
> @@ -2136,6 +2136,37 @@ struct ovn_controller_exit_args {
> bool *restart;
> };
>
> +static bool
> +pin_to_northd(struct ovsdb_idl *ovs_idl)
> +{
> +const struct ovsrec_open_vswitch *cfg =
> ovsrec_open_vswitch_first(ovs_idl);
> +return !cfg ? false : smap_get_bool(>external_ids,
> +"ovn-pin-to-northd", false);
> +}
> +
> +/* Returns false if the northd internal version and ovn-controller internal
> + * version doesn't match.
> + */
> +static bool
> +check_northd_version(const struct sbrec_sb_global *sb, const char
> *my_version)
> +{
> +if (!sb) {
> +return false;
> +}
> +
> +const char *northd_version =
> +smap_get_def(>options, "northd_internal_version", "");
> +
> +bool mismatch = strcmp(northd_version, my_version);
> +if (mismatch) {
> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
> +VLOG_WARN_RL(,
Re: [ovs-dev] [PATCH ovn v2] Provide the option to pin ovn-controller and ovn-northd to a specific version.
Hi Numan!
A few nits I thought of mentioning [inline]
> On Nov 17, 2020, at 6:57 AM, num...@ovn.org wrote:
>
> From: Numan Siddique
>
> OVN recommends updating/upgrading ovn-controllers first and then
> ovn-northd and OVN DB ovsdb-servers. This is to ensure that any
> new functionality specified by the database or logical flows created
> by ovn-northd is understood by ovn-controller.
>
> However certain deployments may upgrade ovn-northd services first and
> then ovn-controllers. In a large scal deployment, this can result in
> downtime during upgrades as old ovn-controllers may not understand
> new logical flows or new actions added by ovn-northd.
>
> Even with upgrading ovn-controllers first, can result in ovn-controllers
> rejecting some of the logical flows if an existing OVN action is
> changed. One such example is ct_commit action which recently was updated
> to take new arguments.
>
> To avoid such downtimes during upgrades, this patch adds the
> functionality of pinning ovn-controller and ovn-northd to a specific
> version. An internal OVN version is generated and this version is stored
> by ovn-northd in the Southbound SB_Global table's
> options:northd_internal_version.
>
> When ovn-controller notices that the internal version has changed, it
> stops handling the database changes - both Southbound and OVS. All the
> existing OF flows are preserved. When ovn-controller is upgraded to the
> same version as ovn-northd services, it will process the database
> changes.
>
> This feature is made optional and disabled by default. Any CMS can
> enable it by configuring the OVS local database with the option -
> ovn-pin-to-northd=false.
^^=false or =true^^ ?
>
> Signed-off-by: Numan Siddique
> ---
>
> v1 -> v2
>
> * Added test cases and missing documentation.
> * Renamed the ovsdb option from ignore_northd_verison
>to ovn-pin-to-northd.
> * Added NEWS item.
>
> NEWS| 3 +
> controller/ovn-controller.8.xml | 11 +++
> controller/ovn-controller.c | 58 -
> lib/ovn-util.c | 17
> lib/ovn-util.h | 4 +
> northd/ovn-northd.c | 18 +++-
> tests/ovn.at| 147
> 7 files changed, 251 insertions(+), 7 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 6010230679..bb95724b36 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -8,6 +8,9 @@ Post-v20.09.0
> server.
>- Support other_config:vlan-passthru=true to allow VLAN tagged incoming
> traffic.
> + - Support version pinning between ovn-northd and ovn-controller as an
> + option. If the option is enabled and the versions don't match,
> + ovn-controller will not process any DB changes.
>
> OVN v20.09.0 - 28 Sep 2020
> --
> diff --git a/controller/ovn-controller.8.xml b/controller/ovn-controller.8.xml
> index 16bc47b205..357edd1f5c 100644
> --- a/controller/ovn-controller.8.xml
> +++ b/controller/ovn-controller.8.xml
> @@ -233,6 +233,17 @@
> The boolean flag indicates if the chassis is used as an
> interconnection gateway.
>
> +
> + external_ids:ovn-pin-to-northd
> +
> +The boolean flag indicates if ovn-controller needs to
> +be pinned to the exact ovn-northd version. If this
> +flag is set to true and the ovn-northd's version
> (reported
> +in the Southbound database) doesn't match with the
> +ovn-controller's internal version, then it will stop
> +processing the Southbound and local Open vSwitch database changes.
> +The default value is considered false if this option is not defined.
> +
>
>
>
> diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> index a06cae3ccb..a7344ea9c4 100644
> --- a/controller/ovn-controller.c
> +++ b/controller/ovn-controller.c
> @@ -2136,6 +2136,37 @@ struct ovn_controller_exit_args {
> bool *restart;
> };
>
> +static bool
> +pin_to_northd(struct ovsdb_idl *ovs_idl)
> +{
> +const struct ovsrec_open_vswitch *cfg =
> ovsrec_open_vswitch_first(ovs_idl);
> +return !cfg ? false : smap_get_bool(>external_ids,
> +"ovn-pin-to-northd", false);
> +}
> +
> +/* Returns false if the northd internal version and ovn-controller internal
> + * version doesn't match.
> + */
> +static bool
> +check_northd_version(const struct sbrec_sb_global *sb, const char
> *my_version)
> +{
> +if (!sb) {
> +return false;
> +}
> +
> +const char *northd_version =
> +smap_get_def(>options, "northd_internal_version", "");
> +
> +bool mismatch = strcmp(northd_version, my_version);
> +if (mismatch) {
> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
> +VLOG_WARN_RL(, "controller version - %s mismatch with northd "
> + "version - %s", my_version, northd_version);
> +}
> +
> +return mismatch;
>
[ovs-dev] [PATCH ovn v2] Provide the option to pin ovn-controller and ovn-northd to a specific version.
From: Numan Siddique
OVN recommends updating/upgrading ovn-controllers first and then
ovn-northd and OVN DB ovsdb-servers. This is to ensure that any
new functionality specified by the database or logical flows created
by ovn-northd is understood by ovn-controller.
However certain deployments may upgrade ovn-northd services first and
then ovn-controllers. In a large scal deployment, this can result in
downtime during upgrades as old ovn-controllers may not understand
new logical flows or new actions added by ovn-northd.
Even with upgrading ovn-controllers first, can result in ovn-controllers
rejecting some of the logical flows if an existing OVN action is
changed. One such example is ct_commit action which recently was updated
to take new arguments.
To avoid such downtimes during upgrades, this patch adds the
functionality of pinning ovn-controller and ovn-northd to a specific
version. An internal OVN version is generated and this version is stored
by ovn-northd in the Southbound SB_Global table's
options:northd_internal_version.
When ovn-controller notices that the internal version has changed, it
stops handling the database changes - both Southbound and OVS. All the
existing OF flows are preserved. When ovn-controller is upgraded to the
same version as ovn-northd services, it will process the database
changes.
This feature is made optional and disabled by default. Any CMS can
enable it by configuring the OVS local database with the option -
ovn-pin-to-northd=false.
Signed-off-by: Numan Siddique
---
v1 -> v2
* Added test cases and missing documentation.
* Renamed the ovsdb option from ignore_northd_verison
to ovn-pin-to-northd.
* Added NEWS item.
NEWS| 3 +
controller/ovn-controller.8.xml | 11 +++
controller/ovn-controller.c | 58 -
lib/ovn-util.c | 17
lib/ovn-util.h | 4 +
northd/ovn-northd.c | 18 +++-
tests/ovn.at| 147
7 files changed, 251 insertions(+), 7 deletions(-)
diff --git a/NEWS b/NEWS
index 6010230679..bb95724b36 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,9 @@ Post-v20.09.0
server.
- Support other_config:vlan-passthru=true to allow VLAN tagged incoming
traffic.
+ - Support version pinning between ovn-northd and ovn-controller as an
+ option. If the option is enabled and the versions don't match,
+ ovn-controller will not process any DB changes.
OVN v20.09.0 - 28 Sep 2020
--
diff --git a/controller/ovn-controller.8.xml b/controller/ovn-controller.8.xml
index 16bc47b205..357edd1f5c 100644
--- a/controller/ovn-controller.8.xml
+++ b/controller/ovn-controller.8.xml
@@ -233,6 +233,17 @@
The boolean flag indicates if the chassis is used as an
interconnection gateway.
+
+ external_ids:ovn-pin-to-northd
+
+The boolean flag indicates if ovn-controller needs to
+be pinned to the exact ovn-northd version. If this
+flag is set to true and the ovn-northd's version (reported
+in the Southbound database) doesn't match with the
+ovn-controller's internal version, then it will stop
+processing the Southbound and local Open vSwitch database changes.
+The default value is considered false if this option is not defined.
+
diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
index a06cae3ccb..a7344ea9c4 100644
--- a/controller/ovn-controller.c
+++ b/controller/ovn-controller.c
@@ -2136,6 +2136,37 @@ struct ovn_controller_exit_args {
bool *restart;
};
+static bool
+pin_to_northd(struct ovsdb_idl *ovs_idl)
+{
+const struct ovsrec_open_vswitch *cfg = ovsrec_open_vswitch_first(ovs_idl);
+return !cfg ? false : smap_get_bool(>external_ids,
+"ovn-pin-to-northd", false);
+}
+
+/* Returns false if the northd internal version and ovn-controller internal
+ * version doesn't match.
+ */
+static bool
+check_northd_version(const struct sbrec_sb_global *sb, const char *my_version)
+{
+if (!sb) {
+return false;
+}
+
+const char *northd_version =
+smap_get_def(>options, "northd_internal_version", "");
+
+bool mismatch = strcmp(northd_version, my_version);
+if (mismatch) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
+VLOG_WARN_RL(, "controller version - %s mismatch with northd "
+ "version - %s", my_version, northd_version);
+}
+
+return mismatch;
+}
+
int
main(int argc, char *argv[])
{
@@ -2428,10 +2459,14 @@ main(int argc, char *argv[])
.enable_lflow_cache = true
};
+char *ovn_internal_version = ovn_get_internal_version();
+VLOG_INFO("OVN internal version is : [%s]", ovn_internal_version);
+
/* Main loop. */
exiting = false;
restart = false;
bool sb_monitor_all =
