1. TSC
  2. Topics

[release] OVSDB : moving project to self-managed for Silicon release cycle.

Robert Varga
 

On 04/10/2020 16:49, Chetan via lists.opendaylight.org wrote:
Hi All,
Hello Chetan,

As per discussion in TSC meeting on 01-Oct-2020, we are expressing our
intent to move OVSDB project to self-managed for Silicon release cycle.

 

https://wiki.opendaylight.org/x/ZxQF

 

Requesting community to respond in 2 weeks if it would like to continue
keeping this project in managed mode and would request to take up the
current responsibilities of this project if needed to continue as
managed project.
We might be interested in OVSDB, but unfortunately it depends on
ServiceUtils.

Now there is no thread for ServiceUtils and while the project seems to
be small, there I cannot seem to find the spec for SRM nor UPGRADE
components -- aside from very terse javadoc, which do not provide enough
context.

Is there anyone who could shed some more light on those two?

Btw. this is also a concern for anyone who'd want to take over
OFP/Genius/Netvirt.

Thanks,
Robert

signature.asc

signature.asc

Faseela K <k.faseela@...>
 

Robert,
  Sorry, this was never moved to ServiceUtils.
Thanks,


On Tue, 6 Oct 2020 at 02:19, Robert Varga <nite@...> wrote:
On 04/10/2020 16:49, Chetan via lists.opendaylight.org wrote:
> Hi All,

Hello Chetan,

> As per discussion in TSC meeting on 01-Oct-2020, we are expressing our
> intent to move OVSDB project to self-managed for Silicon release cycle.
>
>  
>
> https://wiki.opendaylight.org/x/ZxQF
>
>  
>
> Requesting community to respond in 2 weeks if it would like to continue
> keeping this project in managed mode and would request to take up the
> current responsibilities of this project if needed to continue as
> managed project.

We might be interested in OVSDB, but unfortunately it depends on
ServiceUtils.

Now there is no thread for ServiceUtils and while the project seems to
be small, there I cannot seem to find the spec for SRM nor UPGRADE
components -- aside from very terse javadoc, which do not provide enough
context.

Is there anyone who could shed some more light on those two?

Btw. this is also a concern for anyone who'd want to take over
OFP/Genius/Netvirt.

Thanks,
Robert






--
Faseela.K
Cisco, Bengaluru
MEC 2k10
Chetan
 

Hi Robert,

 

On the serviceUtils dependency in OVSDB in mainly on UpgradeState Flag. Ovsdb depends on this flag to decide whether to trigger reconciliation or not when the openvswitch/hwvtep switch get connected to ODL.

 

As part of reconciliation, we compare config and oper DS and based on the difference we attempt to create/delete missing entries(ex: tunnels)

 

During Upgrade, when the southbound port 6640 is opened for accepting connection, its possible the config DS is not fully build-up and if reconciliation is triggered with partial config Data, we will end-up in deleting valid entries from the switches. In order to avoid this, ovsdb depends on upgrade flag and if it set, reconciliation will not be triggered. Once upgrade-flag is turned-off, then only we trigger reconciliation.

 

Thanks,

Chetan

 

From: Faseela K <k.faseela@...>
Sent: 06 October 2020 11:36
To: Robert Varga <nite@...>
Cc: Chetan Arakere Gowdru <chetan.arakere@...>; tsc <tsc@...>; Release <release@...>
Subject: Re: [release] OVSDB : moving project to self-managed for Silicon release cycle.

 

Robert,

  Sorry, this was never moved to ServiceUtils.

Thanks,

 

On Tue, 6 Oct 2020 at 02:19, Robert Varga <nite@...> wrote:

On 04/10/2020 16:49, Chetan via lists.opendaylight.org wrote:
> Hi All,

Hello Chetan,

> As per discussion in TSC meeting on 01-Oct-2020, we are expressing our
> intent to move OVSDB project to self-managed for Silicon release cycle.
>
>  
>
> https://wiki.opendaylight.org/x/ZxQF
>
>  
>
> Requesting community to respond in 2 weeks if it would like to continue
> keeping this project in managed mode and would request to take up the
> current responsibilities of this project if needed to continue as
> managed project.

We might be interested in OVSDB, but unfortunately it depends on
ServiceUtils.

Now there is no thread for ServiceUtils and while the project seems to
be small, there I cannot seem to find the spec for SRM nor UPGRADE
components -- aside from very terse javadoc, which do not provide enough
context.

Is there anyone who could shed some more light on those two?

Btw. this is also a concern for anyone who'd want to take over
OFP/Genius/Netvirt.

Thanks,
Robert



 

--

Faseela.K

Cisco, Bengaluru

MEC 2k10

smime.p7s

smime.p7s

Robert Varga
 

On 09/10/2020 12:04, Chetan Arakere Gowdru wrote:
Hi Robert,
Hello Chetan,

On the serviceUtils dependency in OVSDB in mainly on UpgradeState Flag.
Ovsdb depends on this flag to decide whether to trigger reconciliation
or not when the openvswitch/hwvtep switch get connected to ODL.

 

As part of reconciliation, we compare config and oper DS and based on
the difference we attempt to create/delete missing entries(ex: tunnels)

 

During Upgrade, when the southbound port 6640 is opened for accepting
connection, its possible the config DS is not fully build-up and if
reconciliation is triggered with partial config Data, we will end-up in
deleting valid entries from the switches. In order to avoid this, ovsdb
depends on upgrade flag and if it set, reconciliation will not be
triggered. Once upgrade-flag is turned-off, then only we trigger
reconciliation.
Thanks for the explanation. Unfortunately I could not find much about
the upgrade feature -- do you know where a user guide or similar might
be found, please?

Thanks,
Robert
Chetan
 

Hi Robert,

Unfortunately, I couldn't find any User Guide as such for this
Upgade-Flag(@Faseela K, Please point us if there any)

This UpgradeState Flag utility was earlier implemented in GENIUS project and
latest moved to service-utils so that other project can leverage it.

Please find below JIRA/Patches related this.

https://git.opendaylight.org/gerrit/c/genius/+/65299
https://git.opendaylight.org/gerrit/c/serviceutils/+/73677
https://git.opendaylight.org/gerrit/c/genius/+/74472

https://jira.opendaylight.org/browse/GENIUS-190

Thanks,
Chetan

-----Original Message-----
From: Robert Varga <nite@...>
Sent: 15 October 2020 17:08
To: Chetan Arakere Gowdru <chetan.arakere@...>; 'Faseela K'
<k.faseela@...>
Cc: 'tsc' <tsc@...>; 'Release'
<release@...>
Subject: Re: [release] OVSDB : moving project to self-managed for Silicon
release cycle.

On 09/10/2020 12:04, Chetan Arakere Gowdru wrote:
Hi Robert,
Hello Chetan,

On the serviceUtils dependency in OVSDB in mainly on UpgradeState Flag.
Ovsdb depends on this flag to decide whether to trigger reconciliation
or not when the openvswitch/hwvtep switch get connected to ODL.



As part of reconciliation, we compare config and oper DS and based on
the difference we attempt to create/delete missing entries(ex:
tunnels)



During Upgrade, when the southbound port 6640 is opened for accepting
connection, its possible the config DS is not fully build-up and if
reconciliation is triggered with partial config Data, we will end-up
in deleting valid entries from the switches. In order to avoid this,
ovsdb depends on upgrade flag and if it set, reconciliation will not
be triggered. Once upgrade-flag is turned-off, then only we trigger
reconciliation.
Thanks for the explanation. Unfortunately I could not find much about the
upgrade feature -- do you know where a user guide or similar might be found,
please?

Thanks,
Robert

smime.p7s

smime.p7s

daya k
 

hi robert,
not sure of documentation, sorry about that.
we did present this in a ddf, the slides are here -




i can talk give a brief walkthrough of the relevant parts either today, or a tws session, with some of the module implementors.

going fwd, i see 3 options for the flag, if we want to keep the functionality -
1. move it to a common project, such as md-sal or controller
2. replicate it in ovsdb and openflow plugin
3. keep service-utils as a managed project in case someone is willing to steer it on a day-to-day basis.

thanks,
daya

On Friday, October 16, 2020, 08:27:26 AM GMT+5:30, Chetan via lists.opendaylight.org <chetan.arakere=altencalsoftlabs.com@...> wrote:


Hi Robert,

Unfortunately, I couldn't find any User Guide as such for this
Upgade-Flag(@Faseela K, Please point us if there any)

This UpgradeState Flag utility was earlier implemented in GENIUS project and
latest moved to service-utils so that other project can leverage it.

Please find below JIRA/Patches related this.

https://git.opendaylight.org/gerrit/c/genius/+/65299
https://git.opendaylight.org/gerrit/c/serviceutils/+/73677
https://git.opendaylight.org/gerrit/c/genius/+/74472

https://jira.opendaylight.org/browse/GENIUS-190

Thanks,
Chetan

-----Original Message-----
From: Robert Varga <nite@...>
Sent: 15 October 2020 17:08
To: Chetan Arakere Gowdru <chetan.arakere@...>; 'Faseela K'
<k.faseela@...>
Cc: 'tsc' <tsc@...>; 'Release'
<release@...>

Subject: Re: [release] OVSDB : moving project to self-managed for Silicon
release cycle.

On 09/10/2020 12:04, Chetan Arakere Gowdru wrote:
> Hi Robert,

Hello Chetan,

> On the serviceUtils dependency in OVSDB in mainly on UpgradeState Flag.
> Ovsdb depends on this flag to decide whether to trigger reconciliation
> or not when the openvswitch/hwvtep switch get connected to ODL.
>
>
>
> As part of reconciliation, we compare config and oper DS and based on
> the difference we attempt to create/delete missing entries(ex:
> tunnels)
>
>
>
> During Upgrade, when the southbound port 6640 is opened for accepting
> connection, its possible the config DS is not fully build-up and if
> reconciliation is triggered with partial config Data, we will end-up
> in deleting valid entries from the switches. In order to avoid this,
> ovsdb depends on upgrade flag and if it set, reconciliation will not
> be triggered. Once upgrade-flag is turned-off, then only we trigger
> reconciliation.

Thanks for the explanation. Unfortunately I could not find much about the
upgrade feature -- do you know where a user guide or similar might be found,
please?

Thanks,
Robert
daya k
 

here's another one that focuses specifically on the usecases for the upgrade flag, (some things are slightly dated implementation wise, but the general idea is all sound)


thanks,
daya

On Friday, October 16, 2020, 10:05:38 AM GMT+5:30, daya kamath <daya_k@...> wrote:


hi robert,
not sure of documentation, sorry about that.
we did present this in a ddf, the slides are here -







i can talk give a brief walkthrough of the relevant parts either today, or a tws session, with some of the module implementors.

going fwd, i see 3 options for the flag, if we want to keep the functionality -
1. move it to a common project, such as md-sal or controller
2. replicate it in ovsdb and openflow plugin
3. keep service-utils as a managed project in case someone is willing to steer it on a day-to-day basis.

thanks,
daya

On Friday, October 16, 2020, 08:27:26 AM GMT+5:30, Chetan via lists.opendaylight.org <chetan.arakere=altencalsoftlabs.com@...> wrote:


Hi Robert,

Unfortunately, I couldn't find any User Guide as such for this
Upgade-Flag(@Faseela K, Please point us if there any)

This UpgradeState Flag utility was earlier implemented in GENIUS project and
latest moved to service-utils so that other project can leverage it.

Please find below JIRA/Patches related this.

https://git.opendaylight.org/gerrit/c/genius/+/65299
https://git.opendaylight.org/gerrit/c/serviceutils/+/73677
https://git.opendaylight.org/gerrit/c/genius/+/74472

https://jira.opendaylight.org/browse/GENIUS-190

Thanks,
Chetan

-----Original Message-----
From: Robert Varga <nite@...>
Sent: 15 October 2020 17:08
To: Chetan Arakere Gowdru <chetan.arakere@...>; 'Faseela K'
<k.faseela@...>
Cc: 'tsc' <tsc@...>; 'Release'
<release@...>

Subject: Re: [release] OVSDB : moving project to self-managed for Silicon
release cycle.

On 09/10/2020 12:04, Chetan Arakere Gowdru wrote:
> Hi Robert,

Hello Chetan,

> On the serviceUtils dependency in OVSDB in mainly on UpgradeState Flag.
> Ovsdb depends on this flag to decide whether to trigger reconciliation
> or not when the openvswitch/hwvtep switch get connected to ODL.
>
>
>
> As part of reconciliation, we compare config and oper DS and based on
> the difference we attempt to create/delete missing entries(ex:
> tunnels)
>
>
>
> During Upgrade, when the southbound port 6640 is opened for accepting
> connection, its possible the config DS is not fully build-up and if
> reconciliation is triggered with partial config Data, we will end-up
> in deleting valid entries from the switches. In order to avoid this,
> ovsdb depends on upgrade flag and if it set, reconciliation will not
> be triggered. Once upgrade-flag is turned-off, then only we trigger
> reconciliation.

Thanks for the explanation. Unfortunately I could not find much about the
upgrade feature -- do you know where a user guide or similar might be found,
please?

Thanks,
Robert
Robert Varga
 

On 16/10/2020 06:48, daya kamath wrote:
here's another one that focuses specifically on the usecases for the
upgrade flag, (some things are slightly dated implementation wise, but
the general idea is all sound)
https://docs.google.com/presentation/d/1eZj703NYakcVtJi2fh1F9qBGFaKh2t7JOuRwdY6GiVs/edit#slide=id.p3
<https://docs.google.com/presentation/d/1eZj703NYakcVtJi2fh1F9qBGFaKh2t7JOuRwdY6GiVs/edit#slide=id.p3>
Thanks for the pointer, but this presentation seems to be protected. Can
you make it public perhaps?

Thanks,
Robert
Robert Varga
 

On 16/10/2020 06:35, daya kamath wrote:
hi robert,
Hello Daya,

not sure of documentation, sorry about that.
we did present this in a ddf, the slides are here -
Upgrade @ DDF 2018
<https://docs.google.com/presentation/d/1PedCjs7UgB49Of1iTWs4FcZkjCAa8LHc3ID0nrSV10o/edit#slide=id.p>
No worries, this seems to confirm my suspicion on what this provides.

Just to clarify:

1) does current state of affairs include anything from Gap/Future
Developments (slide 11) items?

2) is my understanding correct that this mostly involves upgrading the
datastore state?

3) Is actual ovsdb/ofp/genius/netvirt code required for that state upgrade?

Thanks,
Robert
daya k
 

hi robert,
pls see inline.

thanks,
daya

On Thursday, October 22, 2020, 09:14:05 PM GMT+5:30, Robert Varga <nite@...> wrote:


On 16/10/2020 06:35, daya kamath wrote:
> hi robert,

Hello Daya,

> not sure of documentation, sorry about that.
> we did present this in a ddf, the slides are here -
> Upgrade @ DDF 2018
> <https://docs.google.com/presentation/d/1PedCjs7UgB49Of1iTWs4FcZkjCAa8LHc3ID0nrSV10o/edit#slide=id.p>

No worries, this seems to confirm my suspicion on what this provides.

Just to clarify:

1) does current state of affairs include anything from Gap/Future
Developments (slide 11) items?
daya->all the feature gaps (until slide 19)are already covered, and implemented in the code. slide 19 was more of an idea discussion, that we did not get around to doing.
the csit is also not fully updated. upgrade is covered, but the hitless part is not really tested in the csit.

2) is my understanding correct that this mostly involves upgrading the
datastore state?
daya->no, actually, it involves clearing most of the persisted data from datastore, and building it up again while keeping dataplane running. so, the upgrade becomes baseline free, and there are no backward compatibility restrictions to a large extent beyond the small subset of data that does get persisted 

3) Is actual ovsdb/ofp/genius/netvirt code required for that state upgrade?
daya->not clear on your question. all of these modules would populate derived data and operational data freshly after the code upgrade into the datastore. so, the business logic in these modules could change between different versions, and they can go ahead and change any way they want to use the datastore between these versions.

Thanks,
Robert
daya k
 

hey robert,
i need to revise my answer, pls see additional clarifications inline.

thanks,
daya

On Friday, October 30, 2020, 10:54:35 AM GMT+5:30, daya kamath <daya_k@...> wrote:


hi robert,
pls see inline.

thanks,
daya

On Thursday, October 22, 2020, 09:14:05 PM GMT+5:30, Robert Varga <nite@...> wrote:


On 16/10/2020 06:35, daya kamath wrote:
> hi robert,

Hello Daya,

> not sure of documentation, sorry about that.
> we did present this in a ddf, the slides are here -
> Upgrade @ DDF 2018
> <https://docs.google.com/presentation/d/1PedCjs7UgB49Of1iTWs4FcZkjCAa8LHc3ID0nrSV10o/edit#slide=id.p>

No worries, this seems to confirm my suspicion on what this provides.

Just to clarify:

1) does current state of affairs include anything from Gap/Future
Developments (slide 11) items?
daya->all the feature gaps (until slide 19)are already covered, and implemented in the code. slide 19 was more of an idea discussion, that we did not get around to doing.
the csit is also not fully updated. upgrade is covered, but the hitless part is not really tested in the csit.

daya2->the initial implementation for reading and writing config to be persisted was through the neutron odlv2 driver re-conciliation mechanisms, the evolved approach is to use external scripts with rest api to pull and push the data models. from a gaps perspective, some of these models fall into derived data and would not be available in the 1st approach of using neutron driver. since the external script is not part of any project, its not available in the upstream. i can put together a list of data models that need to be persisted beyond what the neutron odl driver gives us by default. pls give me a day or 2 to come up with this list. i can add the same to the google presentation, or if a wiki page is preferred, can put it on a wiki page, if you can send me a pointer to where it should go.

2) is my understanding correct that this mostly involves upgrading the
datastore state?
daya->no, actually, it involves clearing most of the persisted data from datastore, and building it up again while keeping dataplane running. so, the upgrade becomes baseline free, and there are no backward compatibility restrictions to a large extent beyond the small subset of data that does get persisted 

3) Is actual ovsdb/ofp/genius/netvirt code required for that state upgrade?
daya->not clear on your question. all of these modules would populate derived data and operational data freshly after the code upgrade into the datastore. so, the business logic in these modules could change between different versions, and they can go ahead and change any way they want to use the datastore between these versions.


Thanks,
Robert

1 - 11 of 11