Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Krzysztof Opasiak via lists.onap.org]

 a F2F business
> meeting on the West Coast may be completely unacceptable when
> that same meeting is held on the East Coast.  Years ago I made
> that exact error at an internal company meeting I was attending.
>   I knew how company meetings operated out here and assumed that
> it was that way everywhere else in the company.  I was very,
> very wrong with that assumption and ended up embarrassing my
> Director and VP as a result.   Needless to say this took a long
> time to recover from career-wise.
> 
> Patience when working in a global community is a prerequisite
> and our most valuable asset as communication styles, business
> cultures and regional cultures around the world are very
> different than our own.
> 
> 
> I fully agree with all what you wrote above!
> 
> Ultimately we are all passengers who would like to get to our final
> station, nevertheless not all of us needs to take the same train.
> 
> When the train is broken, no one can get anywhere so everyone needs to
> wait and do their best to repair the train. As soon as the train is
> operational it should be moving according to the schedule.
> 
> Every passenger is different and independent. Everyone may have a
> different tempo, different additional duties, different size of
> suitcase, different limitations but everyone has a freedom to choose
> the
> course from the timetable which suits him the most and plan his or her
> journey accordingly. Nevertheless to take that train one needs to be on
> the platform on time, if not then the train just moves forward but no
> one is excluding that passenger from reaching his final destination. He
> just needs to wait a little bit and take the next train.
> 
> Obviously TSC is the body that creates timetables for our trains so
> it's
> also up to TSC to decide how long the train can wait at any point.
> In my
> opinion it's not an easy role and a really tough decision as every
> minute of waiting allow more late comers to take the train but in the
> same time it also delays all the passengers that are inside the train
> and makes their journey unpredictable. (Maybe next time we've 10 other
> passengers arriving late, speculating that it doesn't make any sense to
> be on time as the train will always wait for them?)
> 
> I've a very limited knowledge about the World so I'm not sure how it
> looks in other countries but in Poland there is a lot of jokes about
> our
> trains that are often delayed and a lot of admiration for
> ultra-punctual
> Japanese railway transport.
> 
> 
> Thanks!
> -kenny
> 
> 
> 
> -Original Message-
> From: onap-tsc@lists.onap.org  On
> Behalf Of Krzysztof Opasiak via lists.onap.org
> Sent: Monday, March 29, 2021 3:28 AM
> To: Xu Ran ; Catherine LEFEVRE
> ; Dong Wang 
> Cc: Alexander Mazuruk ; DESBUREAUX
> Sylvain TGI/OLN ; onap-tsc
> ; morgan.richo...@orange.com;
> marcin.przyb...@nokia.com; Kuzmicki,Krzysztof (Nokia -
> PL/Wroclaw) ; Closset,Christophe
> ; Bartek Grzybowski
>     ; HARDY Thierry TGI/OLN
> ; michal.jagie...@t-mobile.pl;
> Geissler, Andreas ;
> fu.guangr...@zte.com.cn; RAJEWSKI Lukasz O-PL
> ; Paweł Wieczorek
> ; Lasse Kaihlavirta
> ; FREEMAN, BRIAN D
> ; bin.y...@windriver.com; TIMONEY, DAN
> ; MAHER, RANDA ; HAHN III, JIM
> ; Seshu m ; Toine
> Siebelink ;
> krishna.moort...@wipro.com; onap-disc...@lists.onap.org
> Subject: Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM
> status update for RC0
> 
> Hi Xu Ran,
> 
> On 29.03.2021 03:40, Xu Ran wrote:
> 
> Dear Opasiak and Catherine,
> 
> I have noticed that the block thing of UUI’s merge into OOM is:
> 
> 
> https://protect2.fireeye.com/v1/url?k=072c4f49-58b77645-072dc406-000babff3563-8875456a004bfcbf&q=1&e=3baf245c-daee-4505-94b6-9ca68385b9c9&u=https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F118930
> 
> <https://protect2.fireeye.com/v1/url?k=1e966c5a-410d5543-1e97e715-000b
> 
> abff3793-f7ea0549a854ee69&q=1&e=26b28653-b4cf-4482-aed3-4b5732aa0935&u
> =https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F118930>
> 
> https://protect2.fireeye.com/v1/url?k=9a3d9b6c-c5a6a260-9a3c1023-000babff3563-cb4b23522f3aa0ba&

Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Xu Ran]

ltra-punctual Japanese railway transport.  Thanks! -kenny-Original Message- From: onap-tsc@lists.onap.org  On Behalf Of Krzysztof Opasiak via lists.onap.org Sent: Monday, March 29, 2021 3:28 AM To: Xu Ran ; Catherine LEFEVRE ; Dong Wang  Cc: Alexander Mazuruk ; DESBUREAUX Sylvain TGI/OLN ; onap-tsc ; morgan.richo...@orange.com; marcin.przyb...@nokia.com; Kuzmicki,Krzysztof (Nokia - PL/Wroclaw) ; Closset,Christophe ; Bartek Grzybowski ; HARDY Thierry TGI/OLN ; michal.jagie...@t-mobile.pl; Geissler, Andreas ; fu.guangr...@zte.com.cn; RAJEWSKI Lukasz O-PL ; Paweł Wieczorek ; Lasse Kaihlavirta ; FREEMAN, BRIAN D ; bin.y...@windriver.com; TIMONEY, DAN ; MAHER, RANDA ; HAHN III, JIM ; Seshu m ; Toine Siebelink ; krishna.moort...@wipro.com; onap-disc...@lists.onap.org Subject: Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for RC0  Hi Xu Ran,  On 29.03.2021 03:40, Xu Ran wrote: Dear Opasiak and Catherine, I have noticed that the block thing of UUI’s merge into OOM is: https://protect2.fireeye.com/v1/url?k=072c4f49-58b77645-072dc406-000babff3563-8875456a004bfcbf&q=1&e=3baf245c-daee-4505-94b6-9ca68385b9c9&u=https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F118930  abff3793-f7ea0549a854ee69&q=1&e=26b28653-b4cf-4482-aed3-4b5732aa0935&u =https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F118930> https://protect2.fireeye.com/v1/url?k=9a3d9b6c-c5a6a260-9a3c1023-000babff3563-cb4b23522f3aa0ba&q=1&e=3baf245c-daee-4505-94b6-9ca68385b9c9&u=https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F119124  abff3793-1e123c16f51c1874&q=1&e=26b28653-b4cf-4482-aed3-4b5732aa0935&u =https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F119124> They’re all related to the new NLP server, however, since there’re some several problems appearing in these two commits, we accept the result to delay this new part to Istanbul release. We’ll abandon these two commits and make further changes. And the H release plan of UUI will *NOT* include this part.  No need to abandon. You can always squash the two and move ahead with a new patchset on one of the reviews;)  As for the commit: https://protect2.fireeye.com/v1/url?k=96b7da32-c92ce33e-96b6517d-000babff3563-099d43a953f2a8f8&q=1&e=3baf245c-daee-4505-94b6-9ca68385b9c9&u=https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F119844  abff3793-15fb88f07d0c1278&q=1&e=26b28653-b4cf-4482-aed3-4b5732aa0935&u =https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F119844> This commit only contains the changes of E2E slicing service which are some minor ones.  Yes + there is an implementation of NLP server introduced by commit 7643cc5b373b167000d676c48d741e830081f3ab but I expect that as NLP is delayed to Istanbul then this is just disabled by default?  We hope that OOM team can review this change and merge it. If there’s any problem with the E2E part, we’ll be free to change.And also, Doctor @Dong Wang is the sponsor of the new NLP part, he is also available to response the problem of this part. We will attend today’s PTL meeting to make some more explanation, hope we can reach an agreement.  Gating seems to be fine on those patches. My only concern, that I expressed in the ticket is what is the rationale for not providing this container update before the deadline which is M3?  Your REQ tickets say that you don't expect a need to update OOM configuration for this release...   B.R. - Xu Ran China Mobile Research Institute No.32 Xuanwumen west street,Xicheng District, Beijing 100053, China Mobile: +86 15010868144 Email:  xuran...@chinamobile.com  - On 03/27/2021 03:05，Krzysztof Opasiak via lists.onap.org  wrote：  Dear Catherine,  On 26.03.2021 19:13, Lefevre, Catherine wrote:  Dear OOM Team,  David and I we are trying to understand what it is left from OOM  Backlog  that the project team(s) need to consider before the next PTL  call (3/29)  We understand from the TSC call (3/25) - SO, SDNC and UUI had an  action  but it was not clear that there were other projects.  Here is our understanding and the path to move forward.  After the following items are solved then we need to stabilize the  release and no more accept any OOM code submission except  for *versioning, documentation and show stoppers blocking E2E  Testing.*  #1 UUI  Remaining code submitted to change version is  "https://protect2.fireeye.com/v1/url?k=e495d5ce-bb0eecc2-e4945e81-000babff3563-2cf4bff145a7360d&q=1&e=3baf245c-daee-4505-94b6-9ca68385b9c9&u=https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F119844  "  I have reviewed it and did not notice anything wrong so I  believe it is  ready to merge  The UUI action was related to:  https://protect2.fireeye.com/

Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Krzysztof Opasiak via lists.onap.org]

Hi Kenny,

On 29.03.2021 19:17, Kenny Paul wrote:
> The most important thing we all need to remember is that everyone is working 
> very hard to ultimately achieve the same goal.
> 
> In an opensource world changes are most often influenced from the bottom up 
> rather than instituted from the top down.  How long a process change takes is 
> going to vary greatly based upon a number of factors that may or may not be 
> in the direct control of the community members trying to implement the change.
> 
> Consider the fact that ONAP is one of relatively few truly global open source 
> projects.  We are not unique in that aspect, but it creates far larger 
> challenges than any regionally or culturally centric OSS projects would ever 
> need to consider beyond just the simple time-zone issue we face.  Add in the 
> fact that ONAP developers are primarily company provided resources rather 
> than being  a group of purely volunteer individual contributors and our 
> challenges are even more difficult because you have a vast array of company 
> norms and policies  that may also need to be navigated to implement a change.
> 
> Here in the US what is perfectly acceptable for a F2F business meeting on the 
> West Coast may be completely unacceptable when that same meeting is held on 
> the East Coast.  Years ago I made that exact error at an internal company 
> meeting I was attending.  I knew how company meetings operated out here and 
> assumed that it was that way everywhere else in the company.  I was very, 
> very wrong with that assumption and ended up embarrassing my Director and VP 
> as a result.   Needless to say this took a long time to recover from 
> career-wise.
> 
> Patience when working in a global community is a prerequisite and our most 
> valuable asset as communication styles, business cultures and regional 
> cultures around the world are very different than our own.

I fully agree with all what you wrote above!

Ultimately we are all passengers who would like to get to our final 
station, nevertheless not all of us needs to take the same train.

When the train is broken, no one can get anywhere so everyone needs to 
wait and do their best to repair the train. As soon as the train is 
operational it should be moving according to the schedule.

Every passenger is different and independent. Everyone may have a 
different tempo, different additional duties, different size of 
suitcase, different limitations but everyone has a freedom to choose the 
course from the timetable which suits him the most and plan his or her 
journey accordingly. Nevertheless to take that train one needs to be on 
the platform on time, if not then the train just moves forward but no 
one is excluding that passenger from reaching his final destination. He 
just needs to wait a little bit and take the next train.

Obviously TSC is the body that creates timetables for our trains so it's 
also up to TSC to decide how long the train can wait at any point. In my 
opinion it's not an easy role and a really tough decision as every 
minute of waiting allow more late comers to take the train but in the 
same time it also delays all the passengers that are inside the train 
and makes their journey unpredictable. (Maybe next time we've 10 other 
passengers arriving late, speculating that it doesn't make any sense to 
be on time as the train will always wait for them?)

I've a very limited knowledge about the World so I'm not sure how it 
looks in other countries but in Poland there is a lot of jokes about our 
trains that are often delayed and a lot of admiration for ultra-punctual 
Japanese railway transport.

> 
> Thanks!
> -kenny
> 
> 
> 
> -Original Message-
> From: onap-tsc@lists.onap.org  On Behalf Of 
> Krzysztof Opasiak via lists.onap.org
> Sent: Monday, March 29, 2021 3:28 AM
> To: Xu Ran ; Catherine LEFEVRE 
> ; Dong Wang 
> Cc: Alexander Mazuruk ; DESBUREAUX Sylvain TGI/OLN 
> ; onap-tsc ; 
> morgan.richo...@orange.com; marcin.przyb...@nokia.com; Kuzmicki,Krzysztof 
> (Nokia - PL/Wroclaw) ; Closset,Christophe 
> ; Bartek Grzybowski 
> ; HARDY Thierry TGI/OLN 
> ; michal.jagie...@t-mobile.pl; Geissler, Andreas 
> ; fu.guangr...@zte.com.cn; RAJEWSKI Lukasz O-PL 
> ; Paweł Wieczorek ; 
> Lasse Kaihlavirta ; FREEMAN, BRIAN D 
> ; bin.y...@windriver.com; TIMONEY, DAN ; 
> MAHER, RANDA ; HAHN III, JIM ; Seshu m 
> ; Toine Siebelink ; 
> krishna.moort...@wipro.com; onap-disc...@lists.onap.org
> Subject: Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for 
> RC0
> 
> Hi Xu Ran,
> 
> On 29.03.2021 03:40, Xu Ran wrote:
>> Dear Opasiak and Catherine,
>>
>> I have noticed that the block thing of UUI’s merge into OOM is:
>>
>> https://protect2.fireeye.com/v1/url?k=072

Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Kenny Paul]

The most important thing we all need to remember is that everyone is working 
very hard to ultimately achieve the same goal.

In an opensource world changes are most often influenced from the bottom up 
rather than instituted from the top down.  How long a process change takes is 
going to vary greatly based upon a number of factors that may or may not be in 
the direct control of the community members trying to implement the change. 

Consider the fact that ONAP is one of relatively few truly global open source 
projects.  We are not unique in that aspect, but it creates far larger 
challenges than any regionally or culturally centric OSS projects would ever 
need to consider beyond just the simple time-zone issue we face.  Add in the 
fact that ONAP developers are primarily company provided resources rather than 
being  a group of purely volunteer individual contributors and our challenges 
are even more difficult because you have a vast array of company norms and 
policies  that may also need to be navigated to implement a change.

Here in the US what is perfectly acceptable for a F2F business meeting on the 
West Coast may be completely unacceptable when that same meeting is held on the 
East Coast.  Years ago I made that exact error at an internal company meeting I 
was attending.  I knew how company meetings operated out here and assumed that 
it was that way everywhere else in the company.  I was very, very wrong with 
that assumption and ended up embarrassing my Director and VP as a result.   
Needless to say this took a long time to recover from career-wise.

Patience when working in a global community is a prerequisite and our most 
valuable asset as communication styles, business cultures and regional cultures 
around the world are very different than our own. 

Thanks!
-kenny



-Original Message-
From: onap-tsc@lists.onap.org  On Behalf Of Krzysztof 
Opasiak via lists.onap.org
Sent: Monday, March 29, 2021 3:28 AM
To: Xu Ran ; Catherine LEFEVRE 
; Dong Wang 
Cc: Alexander Mazuruk ; DESBUREAUX Sylvain TGI/OLN 
; onap-tsc ; 
morgan.richo...@orange.com; marcin.przyb...@nokia.com; Kuzmicki,Krzysztof 
(Nokia - PL/Wroclaw) ; Closset,Christophe 
; Bartek Grzybowski 
; HARDY Thierry TGI/OLN 
; michal.jagie...@t-mobile.pl; Geissler, Andreas 
; fu.guangr...@zte.com.cn; RAJEWSKI Lukasz O-PL 
; Paweł Wieczorek ; Lasse 
Kaihlavirta ; FREEMAN, BRIAN D 
; bin.y...@windriver.com; TIMONEY, DAN ; MAHER, 
RANDA ; HAHN III, JIM ; Seshu m 
; Toine Siebelink ; 
krishna.moort...@wipro.com; onap-disc...@lists.onap.org
Subject: Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for 
RC0

Hi Xu Ran,

On 29.03.2021 03:40, Xu Ran wrote:
> Dear Opasiak and Catherine,
> 
> I have noticed that the block thing of UUI’s merge into OOM is:
> 
> https://gerrit.onap.org/r/c/oom/+/118930
> <https://protect2.fireeye.com/v1/url?k=1e966c5a-410d5543-1e97e715-000b
> abff3793-f7ea0549a854ee69&q=1&e=26b28653-b4cf-4482-aed3-4b5732aa0935&u
> =https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F118930>
> https://gerrit.onap.org/r/c/oom/+/119124
> <https://protect2.fireeye.com/v1/url?k=43d07bfd-1c4b42e4-43d1f0b2-000b
> abff3793-1e123c16f51c1874&q=1&e=26b28653-b4cf-4482-aed3-4b5732aa0935&u
> =https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F119124>
> 
> 
> They’re all related to the new NLP server, however, since there’re 
> some several problems appearing in these two commits, we accept the 
> result to delay this new part to Istanbul release. We’ll abandon these 
> two commits and make further changes. And the H release plan of UUI 
> will *NOT* include this part.

No need to abandon. You can always squash the two and move ahead with a new 
patchset on one of the reviews;)

> 
> As for the commit:
> https://gerrit.onap.org/r/c/oom/+/119844
> <https://protect2.fireeye.com/v1/url?k=430831be-1c9308a7-4309baf1-000b
> abff3793-15fb88f07d0c1278&q=1&e=26b28653-b4cf-4482-aed3-4b5732aa0935&u
> =https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F119844>
> 
> 
> This commit only contains the changes of E2E slicing service which are 
> some minor ones.

Yes + there is an implementation of NLP server introduced by commit 
7643cc5b373b167000d676c48d741e830081f3ab but I expect that as NLP is delayed to 
Istanbul then this is just disabled by default?

> We hope that OOM team can review this change and merge it. If there’s 
> any problem with the E2E part, we’ll be free to change.
>   And also, Doctor @Dong Wang is the sponsor of the new NLP part, he 
> is also available to response the problem of this part.
> 
> We will attend today’s PTL meeting to make some more explanation, hope 
> we can reach an agreement.

Gating seems to be fine on those patches. My only concern, that I expressed in 
the ticket is what is the rationale for not providing this co

Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Krzysztof Opasiak via lists.onap.org]

Hi Xu Ran,

On 29.03.2021 03:40, Xu Ran wrote:
> Dear Opasiak and Catherine,
> 
> I have noticed that the block thing of UUI’s merge into OOM is:
> 
> https://gerrit.onap.org/r/c/oom/+/118930 
> 
> https://gerrit.onap.org/r/c/oom/+/119124 
> 
>  
> 
> 
> They’re all related to the new NLP server, however, since there’re some 
> several problems appearing in these two commits, we accept the result to 
> delay this new part to Istanbul release. We’ll abandon these two commits 
> and make further changes. And the H release plan of UUI will *NOT* 
> include this part.

No need to abandon. You can always squash the two and move ahead with a 
new patchset on one of the reviews;)

> 
> As for the commit:
> https://gerrit.onap.org/r/c/oom/+/119844 
> 
>  
> 
> 
> This commit only contains the changes of E2E slicing service which are 
> some minor ones. 

Yes + there is an implementation of NLP server introduced by commit 
7643cc5b373b167000d676c48d741e830081f3ab but I expect that as NLP is 
delayed to Istanbul then this is just disabled by default?

> We hope that OOM team can review this change and merge 
> it. If there’s any problem with the E2E part, we’ll be free to change.
>   And also, Doctor @Dong Wang is the sponsor of the new NLP part, he is 
> also available to response the problem of this part.
> 
> We will attend today’s PTL meeting to make some more explanation, hope 
> we can reach an agreement.

Gating seems to be fine on those patches. My only concern, that I 
expressed in the ticket is what is the rationale for not providing this 
container update before the deadline which is M3?

Your REQ tickets say that you don't expect a need to update OOM 
configuration for this release...


> 
> 
> B.R.
> -
> Xu Ran
> China Mobile Research Institute
> No.32 Xuanwumen west street,Xicheng District, Beijing 100053, China
> 
> Mobile: +86 15010868144
> Email:  xuran...@chinamobile.com 
> -
> 
> On 03/27/2021 03:05，Krzysztof Opasiak via 
> lists.onap.org 
>  wrote：
> 
> Dear Catherine,
> 
> On 26.03.2021 19:13, Lefevre, Catherine wrote:
> 
> Dear OOM Team,
> 
> David and I we are trying to understand what it is left from OOM
> Backlog
> that the project team(s) need to consider before the next PTL
> call (3/29)
> 
> We understand from the TSC call (3/25) - SO, SDNC and UUI had an
> action
> but it was not clear that there were other projects.
> 
> Here is our understanding and the path to move forward.
> 
> After the following items are solved then we need to stabilize the
> release and no more accept any OOM code submission except
> 
> for *versioning, documentation and show stoppers blocking E2E
> Testing.*
> 
> #1 UUI
> 
> Remaining code submitted to change version is
> "https://gerrit.onap.org/r/c/oom/+/119844
> 
> "
> 
> I have reviewed it and did not notice anything wrong so I
> believe it is
> ready to merge
> 
> 
> The UUI action was related to:
> https://gerrit.onap.org/r/c/oom/+/118930
> 
> 
> https://gerrit.onap.org/r/c/oom/+/119124
> 
> 
> 
> Not the patch that you linked above. The one that you linked has been
> created *yesterday* 40 mins before the TSC meeting which is 4 weeks
> after the deadline for starting OOM review with new containers for
> Honolulu release.
> 
> In my personal opinion it's very unfair for other project teams to
> accept such changes with a monthly delay. Think how much extra features
> could CPS or DCAE Team implement if th

Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Catherine LEFEVRE]

Good morning Xu,

Thank you so much for your feedback.
I believe that’s the right thing to do.
I will also help to stabilize the release.
Let’s focus on 
https://gerrit.onap.org/r/c/oom/+/119844<https://urldefense.com/v3/__https:/gerrit.onap.org/r/c/oom/*/119844__;Kw!!BhdT!y699KwR9655LCDK-PsWXjo3WKFmTDi1Fs7M5wCjKKOvqT_godojKr2KCd7Wh6dINRH5E2e4$>
 as suggested.

Many thanks & regards
Catherine


From: Xu Ran 
Sent: Monday, March 29, 2021 3:40 AM
To: k.opas...@samsung.com; Lefevre, Catherine ; 
Dong Wang 
Cc: Alexander Mazuruk ; DESBUREAUX Sylvain TGI/OLN 
; onap-tsc ; Lefevre, 
Catherine ; morgan.richo...@orange.com; 
marcin.przyb...@nokia.com; Kuzmicki,Krzysztof ; 
Closset, Christophe ; Bartek Grzybowski 
; HARDY Thierry TGI/OLN 
; michal.jagie...@t-mobile.pl; Geissler, Andreas 
; fu.guangr...@zte.com.cn; RAJEWSKI Lukasz O-PL 
; Paweł Wieczorek ; Lasse 
Kaihlavirta ; FREEMAN, BRIAN D 
; bin.y...@windriver.com; TIMONEY, DAN ; MAHER, 
RANDA ; HAHN III, JIM ; Seshu m 
; Toine Siebelink ; 
krishna.moort...@wipro.com; onap-disc...@lists.onap.org
Subject: Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for 
RC0

Dear Opasiak and Catherine,

I have noticed that the block thing of UUI’s merge into OOM is:

https://gerrit.onap.org/r/c/oom/+/118930<https://urldefense.com/v3/__https:/gerrit.onap.org/r/c/oom/*/118930__;Kw!!BhdT!y699KwR9655LCDK-PsWXjo3WKFmTDi1Fs7M5wCjKKOvqT_godojKr2KCd7Wh6dINqOLvlmM$>
https://gerrit.onap.org/r/c/oom/+/119124<https://urldefense.com/v3/__https:/gerrit.onap.org/r/c/oom/*/119124__;Kw!!BhdT!y699KwR9655LCDK-PsWXjo3WKFmTDi1Fs7M5wCjKKOvqT_godojKr2KCd7Wh6dINNDpIxm4$>

They’re all related to the new NLP server, however, since there’re some several 
problems appearing in these two commits, we accept the result to delay this new 
part to Istanbul release. We’ll abandon these two commits and make further 
changes. And the H release plan of UUI will NOT include this part.

As for the commit:
https://gerrit.onap.org/r/c/oom/+/119844<https://urldefense.com/v3/__https:/gerrit.onap.org/r/c/oom/*/119844__;Kw!!BhdT!y699KwR9655LCDK-PsWXjo3WKFmTDi1Fs7M5wCjKKOvqT_godojKr2KCd7Wh6dINRH5E2e4$>

This commit only contains the changes of E2E slicing service which are some 
minor ones. We hope that OOM team can review this change and merge it. If 
there’s any problem with the E2E part, we’ll be free to change.
 And also, Doctor @Dong Wang is the sponsor of the new NLP part, he is also 
available to response the problem of this part.

We will attend today’s PTL meeting to make some more explanation, hope we can 
reach an agreement.


B.R.
-
Xu Ran
China Mobile Research Institute
No.32 Xuanwumen west street,Xicheng District, Beijing 100053, China

Mobile: +86 15010868144
Email:  xuran...@chinamobile.com<mailto:xuran...@chinamobile.com>
-

On 03/27/2021 03:05，Krzysztof Opasiak via 
lists.onap.org<mailto:k.opasiak=samsung@lists.onap.org>
 wrote：
Dear Catherine,

On 26.03.2021 19:13, Lefevre, Catherine wrote:
Dear OOM Team,

David and I we are trying to understand what it is left from OOM Backlog
that the project team(s) need to consider before the next PTL call (3/29)

We understand from the TSC call (3/25) - SO, SDNC and UUI had an action
but it was not clear that there were other projects.

Here is our understanding and the path to move forward.

After the following items are solved then we need to stabilize the
release and no more accept any OOM code submission except

for *versioning, documentation and show stoppers blocking E2E Testing.*

#1 UUI

Remaining code submitted to change version is
"https://gerrit.onap.org/r/c/oom/+/119844<https://urldefense.com/v3/__https:/gerrit.onap.org/r/c/oom/*/119844__;Kw!!BhdT!y699KwR9655LCDK-PsWXjo3WKFmTDi1Fs7M5wCjKKOvqT_godojKr2KCd7Wh6dINRH5E2e4$>
<https://protect2.fireeye.com/v1/url?k=46b413cc-192f2ad6-46b59883-000babff24ad-7502168be2f1c9a9&q=1&e=bb5ddae6-e181-4352-8e25-2bcfcc413086&u=https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2B%2F119844><https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=46b413cc-192f2ad6-46b59883-000babff24ad-7502168be2f1c9a9&q=1&e=bb5ddae6-e181-4352-8e25-2bcfcc413086&u=https*3A*2F*2Fgerrit.onap.org*2Fr*2Fc*2Foom*2F*2B*2F119844*3E__;JSUlJSUlJSUlJQ!!BhdT!y699KwR9655LCDK-PsWXjo3WKFmTDi1Fs7M5wCjKKOvqT_godojKr2KCd7Wh6dIN6EXXdKY$>"

I have reviewed it and did not notice anything wrong so I believe it is
ready to merge

The UUI action was related to:
https://gerrit.onap.org/r/c/oom/+/118930<https://urldefense.com/v3/__https:/gerrit.onap.org/r/c/oom/*/118930__;Kw!!BhdT!y699KwR9655LCDK-PsWXjo3WKFmTDi1Fs7M5wCjKKOvqT_godojKr2KCd7Wh6dINqOLvlmM$>
https://gerrit.onap.org/r/c/oom/+/119124<https://urldefense.com/v3/__https:/gerrit.onap.org/r/c/oom/*/119124__;Kw!!BhdT!y699KwR9655LCDK-PsWXjo3WKFmTDi1Fs7M5wCjKKOvqT_godojKr2KCd7Wh6dINNDpIxm4$>

Not 

Re: [onap-discuss] TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Xu Ran]

Dear Opasiak and Catherine,I have noticed that the block thing of UUI’s merge into OOM is:https://gerrit.onap.org/r/c/oom/+/118930https://gerrit.onap.org/r/c/oom/+/119124 They’re all related to the new NLP server, however, since there’re some several problems appearing in these two commits, we accept the result to delay this new part to Istanbul release. We’ll abandon these two commits and make further changes. And the H release plan of UUI will NOT include this part. As for the commit: https://gerrit.onap.org/r/c/oom/+/119844 This commit only contains the changes of E2E slicing service which are some minor ones. We hope that OOM team can review this change and merge it. If there’s any problem with the E2E part, we’ll be free to change.  And also, Doctor @Dong Wang is the sponsor of the new NLP part, he is also available to response the problem of this part.We will attend today’s PTL meeting to make some more explanation, hope we can reach an agreement. 

B.R.

  



-Xu RanChina Mobile Research InstituteNo.32 Xuanwumen west street,Xicheng District, Beijing 100053, China Mobile: +86 15010868144Email:  xuran...@chinamobile.com-



 


On 03/27/2021 03:05，Krzysztof Opasiak via lists.onap.org wrote： 


Dear Catherine,On 26.03.2021 19:13, Lefevre, Catherine wrote: Dear OOM Team,  David and I we are trying to understand what it is left from OOM Backlog  that the project team(s) need to consider before the next PTL call (3/29)  We understand from the TSC call (3/25) - SO, SDNC and UUI had an action  but it was not clear that there were other projects.  Here is our understanding and the path to move forward.  After the following items are solved then we need to stabilize the  release and no more accept any OOM code submission except  for *versioning, documentation and show stoppers blocking E2E Testing.*  #1 UUI  Remaining code submitted to change version is  "https://gerrit.onap.org/r/c/oom/+/119844  "  I have reviewed it and did not notice anything wrong so I believe it is  ready to mergeThe UUI action was related to:https://gerrit.onap.org/r/c/oom/+/118930https://gerrit.onap.org/r/c/oom/+/119124Not the patch that you linked above. The one that you linked has been created *yesterday* 40 mins before the TSC meeting which is 4 weeks after the deadline for starting OOM review with new containers for Honolulu release.In my personal opinion it's very unfair for other project teams to accept such changes with a monthly delay. Think how much extra features could CPS or DCAE Team implement if they had extra month for the development...  The following items - we will follow-up if these are required for RC1  containers  It does not look like new code but more modifications of config to build  UUI Container. To be confirmed by *XU*  https://gerrit.onap.org/r/c/oom/+/118930https://gerrit.onap.org/r/c/oom/+/119124  This is a *brand new* microservice that they are willing to add to ONAPIt's not a change in config, it's not any kind of bugfix, it's a brand new Helm chart under UUI project.It was uploaded to gerrit a little bit after the deadline but it was first sent to me via email so we decided to give it a chance. Unfortunately when we start reviewing it more deeply multiple issues has been discovered but never fixed and I believe that we cannot compromise the quality because of the deadline.  #2 SO  We check the remaining open defects,  SO-3584 - https://gerrit.onap.org/r/c/oom/+/119522/11(can we merge the code)?As stated in the review, the patch itself is fine (that's why it has +2 from  me and Sylvain) but we are waiting for a successful gating in patch that you referred below as this is actually where SO will start making use of that. If we merge it just now it would be just a blind merge as without the patch above we don't know if it really works.  SO-3590 - https://gerrit.onap.org/r/c/oom/+/119309(waiting for review)Waiting for gating...  *SESHU, *  SO-3473- suggestion is to descope the remaining item of SO factoring to  Istanbul - too many code submitted and not yet reviewed.  SO-3553- https://gerrit.onap.org/r/c/oom/+/118331- can we descope and shift it to Istanbul?  CCSDK/SDNC  https://gerrit.onap.org/r/c/oom/+/118284-- (version update + 1 big fix) Dan T to review the comments from MorganI believe that Dan has already fixed the issue reported by Morgan. We are waiting for gating to confirm this.  https://gerrit.onap.org/r/c/oom/+/117808--  verified job ok, ready for reviewI need to follow up with Alexander on this patch as I missed his comment. Sorry for that.  CPS - OK For Honolulu  https://gerrit.onap.org/r/c/oom/+/118995) verified job ok, ready for reviewIt's marked as WIP as Bruno is working to address comments from previous revision. Nevertheless changes would not require releasing a new c

Re: TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Krzysztof Opasiak via lists.onap.org]

Hi Catherine,

On 27.03.2021 00:29, Lefevre, Catherine wrote:
> Good evening Krzysztof,
> 
> Thank you for all the feedback that you have provided.
> 
> Concerning the UUI project, Xu Ran (UUI PTL) documented his inputs as part of 
> his M3, RC0 JIRA Management Tasks.

Would you mind pointing me to the exact jira task where this 
clarification has been provided?

> Therefore it would be fair to discuss directly with Xu Ran during the PTL 
> Call on Monday before drawing any final conclusion.
> Based on the results of these discussions, David will capture any action item 
> so we can continue to improve the new release cadence and remove any 
> misunderstanding in the future.
> 
> Have a good weekend.
> 
> Many thanks & regards
> Catherine
> 
> -Original Message-
> From: Krzysztof Opasiak 
> Sent: Friday, March 26, 2021 8:05 PM
> To: Lefevre, Catherine ; 
> morgan.richo...@orange.com; marcin.przyb...@nokia.com; Kuzmicki, Krzysztof 
> (Nokia - PL/Wroclaw) ; Closset, Christophe 
> ; Bartek Grzybowski 
> ; HARDY Thierry TGI/OLN 
> ; michal.jagie...@t-mobile.pl; Geissler, Andreas 
> ; fu.guangr...@zte.com.cn; RAJEWSKI Lukasz O-PL 
> ; Paweł Wieczorek ; 
> Lasse Kaihlavirta ; FREEMAN, BRIAN D 
> ; Xu Ran ; bin.y...@windriver.com; 
> TIMONEY, DAN ; MAHER, RANDA ; HAHN III, JIM 
> ; Seshu m ; Toine Siebelink 
> ; krishna.moort...@wipro.com
> Cc: Alexander Mazuruk ; DESBUREAUX Sylvain TGI/OLN 
> ; onap-tsc ; 
> onap-disc...@lists.onap.org
> Subject: Re: TR : [onap-tsc] [IMPORTANT] OOM status update for RC0
> 
> Dear Catherine,
> 
> On 26.03.2021 19:13, Lefevre, Catherine wrote:
>> Dear OOM Team,
>>
>> David and I we are trying to understand what it is left from OOM
>> Backlog that the project team(s) need to consider before the next PTL
>> call (3/29)
>>
>> We understand from the TSC call (3/25) - SO, SDNC and UUI had an
>> action but it was not clear that there were other projects.
>>
>> Here is our understanding and the path to move forward.
>>
>> After the following items are solved then we need to stabilize the
>> release and no more accept any OOM code submission except
>>
>> for *versioning, documentation and show stoppers blocking E2E
>> Testing.*
>>
>> #1 UUI
>>
>> Remaining code submitted to change version is
>> "https://protect2.fireeye.com/v1/url?k=28ef8233-7774bb7e-28ee097c-0cc47aa8f5ba-99486dc770ce2dc5&q=1&e=13bf9413-fa82-4d44-af46-f2798b79332a&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2A%2F119844_
>> _;Kw!!BhdT!1SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFl
>> AgOcMfoMgwkY$
>> <https://protect2.fireeye.com/v1/url?k=20537452-7fc84d1f-2052ff1d-0cc47aa8f5ba-487ad9c7dead1808&q=1&e=13bf9413-fa82-4d44-af46-f2798b79332a&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D46b413cc-192f2ad6-46b59883-000babff24ad-7502168be2f1c9a9%26q%3D1%26e%3Dbb5ddae6-e181-4352-8e25-2bcfcc413086%26u%3Dhttps%2A3A%2A2F%2A2Fgerrit.onap.org%2A2Fr%2A2Fc%2A2Foom%2A2F%2A2B%2A2F119844__%3BJSUlJSUlJSUl%21%21BhdT%211SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMboQfvdg%24>"
>>
>> I have reviewed it and did not notice anything wrong so I believe it
>> is ready to merge
> 
> The UUI action was related to:
> https://protect2.fireeye.com/v1/url?k=252814d5-7ab32d98-25299f9a-0cc47aa8f5ba-224bfeba073964bd&q=1&e=13bf9413-fa82-4d44-af46-f2798b79332a&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2A%2F118930__%3BKw%21%21BhdT%211SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMseKr-aY%24
> https://protect2.fireeye.com/v1/url?k=9e4359d8-c1d86095-9e42d297-0cc47aa8f5ba-680055d19bf3815e&q=1&e=13bf9413-fa82-4d44-af46-f2798b79332a&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgerrit.onap.org%2Fr%2Fc%2Foom%2F%2A%2F119124__%3BKw%21%21BhdT%211SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMjOMoeko%24
> 
> Not the patch that you linked above. The one that you linked has been created 
> *yesterday* 40 mins before the TSC meeting which is 4 weeks after the 
> deadline for starting OOM review with new containers for Honolulu release.
> 
> In my personal opinion it's very unfair for other project teams to accept 
> such changes with a monthly delay. Think how much extra features could CPS or 
> DCAE Team implement if they had extra month for the development...
> 
>>
>> The following items - we will follow-up if these are required for RC1
>> containers
>>
>> It does not look like new code but more modifications of config to build
>> UU

Re: TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Catherine LEFEVRE]

Good evening Krzysztof,

Thank you for all the feedback that you have provided.

Concerning the UUI project, Xu Ran (UUI PTL) documented his inputs as part of 
his M3, RC0 JIRA Management Tasks.
Therefore it would be fair to discuss directly with Xu Ran during the PTL Call 
on Monday before drawing any final conclusion.
Based on the results of these discussions, David will capture any action item 
so we can continue to improve the new release cadence and remove any 
misunderstanding in the future.

Have a good weekend.

Many thanks & regards
Catherine

-Original Message-
From: Krzysztof Opasiak  
Sent: Friday, March 26, 2021 8:05 PM
To: Lefevre, Catherine ; 
morgan.richo...@orange.com; marcin.przyb...@nokia.com; Kuzmicki, Krzysztof 
(Nokia - PL/Wroclaw) ; Closset, Christophe 
; Bartek Grzybowski 
; HARDY Thierry TGI/OLN 
; michal.jagie...@t-mobile.pl; Geissler, Andreas 
; fu.guangr...@zte.com.cn; RAJEWSKI Lukasz O-PL 
; Paweł Wieczorek ; Lasse 
Kaihlavirta ; FREEMAN, BRIAN D 
; Xu Ran ; bin.y...@windriver.com; 
TIMONEY, DAN ; MAHER, RANDA ; HAHN III, JIM 
; Seshu m ; Toine Siebelink 
; krishna.moort...@wipro.com
Cc: Alexander Mazuruk ; DESBUREAUX Sylvain TGI/OLN 
; onap-tsc ; 
onap-disc...@lists.onap.org
Subject: Re: TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

Dear Catherine,

On 26.03.2021 19:13, Lefevre, Catherine wrote:
> Dear OOM Team,
> 
> David and I we are trying to understand what it is left from OOM 
> Backlog that the project team(s) need to consider before the next PTL 
> call (3/29)
> 
> We understand from the TSC call (3/25) - SO, SDNC and UUI had an 
> action but it was not clear that there were other projects.
> 
> Here is our understanding and the path to move forward.
> 
> After the following items are solved then we need to stabilize the 
> release and no more accept any OOM code submission except
> 
> for *versioning, documentation and show stoppers blocking E2E 
> Testing.*
> 
> #1 UUI
> 
> Remaining code submitted to change version is 
> "https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/119844_
> _;Kw!!BhdT!1SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFl
> AgOcMfoMgwkY$ 
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=46b413cc-192f2ad6-46b59883-000babff24ad-7502168be2f1c9a9&q=1&e=bb5ddae6-e181-4352-8e25-2bcfcc413086&u=https*3A*2F*2Fgerrit.onap.org*2Fr*2Fc*2Foom*2F*2B*2F119844__;JSUlJSUlJSUl!!BhdT!1SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMboQfvdg$
>  >"
> 
> I have reviewed it and did not notice anything wrong so I believe it 
> is ready to merge

The UUI action was related to:
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/118930__;Kw!!BhdT!1SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMseKr-aY$
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/119124__;Kw!!BhdT!1SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMjOMoeko$
 

Not the patch that you linked above. The one that you linked has been created 
*yesterday* 40 mins before the TSC meeting which is 4 weeks after the deadline 
for starting OOM review with new containers for Honolulu release.

In my personal opinion it's very unfair for other project teams to accept such 
changes with a monthly delay. Think how much extra features could CPS or DCAE 
Team implement if they had extra month for the development...

> 
> The following items - we will follow-up if these are required for RC1 
> containers
> 
> It does not look like new code but more modifications of config to build 
> UUI Container. To be confirmed by *XU*
> 
> https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/118930__;Kw!!BhdT!1SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMseKr-aY$
>   
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=a47f0bfc-fbe432e6-a47e80b3-000babff24ad-e702636d9b0b5453&q=1&e=bb5ddae6-e181-4352-8e25-2bcfcc413086&u=https*3A*2F*2Fgerrit.onap.org*2Fr*2Fc*2Foom*2F*2B*2F118930__;JSUlJSUlJSUl!!BhdT!1SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMGQGy0uY$
>  >
> 
> https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/119124__;Kw!!BhdT!1SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMjOMoeko$
>   
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=07a5321d-583e0b07-07a4b952-000babff24ad-6ac11a2aeca53cf1&q=1&e=bb5ddae6-e181-4352-8e25-2bcfcc413086&u=https*3A*2F*2Fgerrit.onap.org*2Fr*2Fc*2Foom*2F*2B*2F119124__;JSUlJSUlJSUl!!BhdT!1SXyR9Emy_JF5aBnLIe-Net9CtU-ERUfC3ygxmShbdypr3cun_6AfcFWlFlAgOcMkdiWEno$
>  >

This is a *brand new* microservice that they are willing to add to ONAP
It's not a change in config, it's not any kind of bugfix, it's a brand 
new Helm chart under UUI project.

It was uploaded to

Re: TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Krzysztof Opasiak via lists.onap.org]

Dear Catherine,

On 26.03.2021 19:13, Lefevre, Catherine wrote:
> Dear OOM Team,
> 
> David and I we are trying to understand what it is left from OOM Backlog 
> that the project team(s) need to consider before the next PTL call (3/29)
> 
> We understand from the TSC call (3/25) - SO, SDNC and UUI had an action 
> but it was not clear that there were other projects.
> 
> Here is our understanding and the path to move forward.
> 
> After the following items are solved then we need to stabilize the 
> release and no more accept any OOM code submission except
> 
> for *versioning, documentation and show stoppers blocking E2E Testing.*
> 
> #1 UUI
> 
> Remaining code submitted to change version is 
> "https://gerrit.onap.org/r/c/oom/+/119844 
> "
> 
> I have reviewed it and did not notice anything wrong so I believe it is 
> ready to merge

The UUI action was related to:
https://gerrit.onap.org/r/c/oom/+/118930
https://gerrit.onap.org/r/c/oom/+/119124

Not the patch that you linked above. The one that you linked has been 
created *yesterday* 40 mins before the TSC meeting which is 4 weeks 
after the deadline for starting OOM review with new containers for 
Honolulu release.

In my personal opinion it's very unfair for other project teams to 
accept such changes with a monthly delay. Think how much extra features 
could CPS or DCAE Team implement if they had extra month for the 
development...

> 
> The following items - we will follow-up if these are required for RC1 
> containers
> 
> It does not look like new code but more modifications of config to build 
> UUI Container. To be confirmed by *XU*
> 
> https://gerrit.onap.org/r/c/oom/+/118930 
> 
> 
> https://gerrit.onap.org/r/c/oom/+/119124 
> 

This is a *brand new* microservice that they are willing to add to ONAP
It's not a change in config, it's not any kind of bugfix, it's a brand 
new Helm chart under UUI project.

It was uploaded to gerrit a little bit after the deadline but it was 
first sent to me via email so we decided to give it a chance. 
Unfortunately when we start reviewing it more deeply multiple issues has 
been discovered but never fixed and I believe that we cannot compromise 
the quality because of the deadline.

> 
> #2 SO
> 
> We check the remaining open defects,
> 
> SO-3584 - https://gerrit.onap.org/r/c/oom/+/119522/11 
> 
>  
> (can we merge the code)?

As stated in the review, the patch itself is fine (that's why it has +2 
from  me and Sylvain) but we are waiting for a successful gating in 
patch that you referred below as this is actually where SO will start 
making use of that. If we merge it just now it would be just a blind 
merge as without the patch above we don't know if it really works.

> 
> SO-3590 - https://gerrit.onap.org/r/c/oom/+/119309 
> 
>  
> (waiting for review)

Waiting for gating...

> 
> *SESHU, *
> 
> SO-3473 
> 
>  
> - suggestion is to descope the remaining item of SO factoring to 
> Istanbul - too many code submitted and not yet reviewed.
> 
> SO-3553 
> 
>  
> - https://gerrit.onap.org/r/c/oom/+/118331 
> 
>  
> - can we descope and shift it to Istanbul?
> 
> CCSDK/SDNC
> 
> https://gerrit.onap.org/r/c/oom/+/118284 
> 
>  
> -- (version update + 1 big fix) Da

Re: TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Catherine LEFEVRE]

Dear OOM Team,



David and I we are trying to understand what it is left from OOM Backlog that 
the project team(s) need to consider before the next PTL call (3/29)

We understand from the TSC call (3/25) - SO, SDNC and UUI had an action but it 
was not clear that there were other projects.

Here is our understanding and the path to move forward.



After the following items are solved then we need to stabilize the release and 
no more accept any OOM code submission except

for versioning, documentation and show stoppers blocking E2E Testing.





#1 UUI

Remaining code submitted to change version is 
"https://gerrit.onap.org/r/c/oom/+/119844";

I have reviewed it and did not notice anything wrong so I believe it is ready 
to merge



The following items - we will follow-up if these are required for RC1 containers

It does not look like new code but more modifications of config to build UUI 
Container. To be confirmed by XU

https://gerrit.onap.org/r/c/oom/+/118930

https://gerrit.onap.org/r/c/oom/+/119124



#2 SO

We check the remaining open defects,

SO-3584 - https://gerrit.onap.org/r/c/oom/+/119522/11 (can we merge the code)?

SO-3590 -   https://gerrit.onap.org/r/c/oom/+/119309 (waiting for review)



SESHU,

SO-3473<https://jira.onap.org/browse/SO-3473> - suggestion is to descope the 
remaining item of SO factoring to Istanbul - too many code submitted and not 
yet reviewed.

SO-3553<https://jira.onap.org/browse/SO-3553> - 
https://gerrit.onap.org/r/c/oom/+/118331 - can we descope and shift it to 
Istanbul?



CCSDK/SDNC

https://gerrit.onap.org/r/c/oom/+/118284 -- (version update + 1 big fix) Dan T 
to review the comments from Morgan

https://gerrit.onap.org/r/c/oom/+/117808 --  verified job ok, ready for review



CPS - OK For Honolulu

https://gerrit.onap.org/r/c/oom/+/118995 ) verified job ok, ready for review



OOF - OK For Honolulu

https://gerrit.onap.org/r/c/oom/+/113414 verified job ok, ready for review



Holmes - What's level of confidence that it will work? Can we move this to 
Istanbul.

https://gerrit.onap.org/r/c/oom/+/117395



AAI - OK For Honolulu (required for Certification)

https://gerrit.onap.org/r/c/oom/+/118248 - verified job ok, ready for review



Multicloud - submitted before RC0

https://gerrit.onap.org/r/c/oom/+/119125 - verified job ok, ready for review





OOM Team - do we miss  anything else? THANK YOU



Happy Friday !!!



Best regards

Catherine



-Original Message-
From: Krzysztof Opasiak 
Sent: Wednesday, March 24, 2021 8:31 PM
To: morgan.richo...@orange.com; marcin.przyb...@nokia.com; Kuzmicki, Krzysztof 
(Nokia - PL/Wroclaw) ; Lefevre, Catherine 
; Closset, Christophe 
; Bartek Grzybowski 
; HARDY Thierry TGI/OLN 
; michal.jagie...@t-mobile.pl; Geissler, Andreas 
; RAJEWSKI Lukasz O-PL 
; Paweł Wieczorek ; Lasse 
Kaihlavirta ; FREEMAN, BRIAN D 

Cc: Alexander Mazuruk ; DESBUREAUX Sylvain TGI/OLN 
; onap-tsc ; 
onap-disc...@lists.onap.org
Subject: Re: TR : [onap-tsc] [IMPORTANT] OOM status update for RC0



Hi,



On 24.03.2021 19:35, 
morgan.richo...@orange.com<mailto:morgan.richo...@orange.com> wrote:

> *TL; DR:*

> 

> xtesting dockers (tests) and xtesting-onap (test launchers) should have been 
> frozen before RC0..so next time we have to think to that..

> Integration shall guarantee a stable testing baseline to OOM to gate 
> confortably..

>

> Full Text

> ---

>

> As indicated by Sylvain, the tests in gate are used as a merge

> criteria

>

> so to avoid any turbulence, I should have frozen

> - the xtesting dockers i.e the tests: no new test - I merged dcaemod

> yesterday - it was false negative, the test was OK but was reported

> failed for few hours (it was not declared in DB, I declared it this

> morning)

> - xtesting-onap: I made an error this afternoon.  I merged a MR dealing with 
> weekly rule for tern test on weekly which broke the testing CI part - I just 
> saw the approval..and saw the CI issue few minutes too late, I reverted it 
> quickly but we missed 2 cycles so ~ 4h. Regarding the numbers of patches to 
> be checked before RC0 and the gating resources, I should not have even tried. 
> (I oom_redeployed the 2 faulty gates).

>

> it means also that we have to sync on the chronology of the integration of 
> the tests in CI.

> I assume that we should guarantee a stable test baseline to OOM between 
> before the RC0.



Well in perfect world probably yes but we all know that tests also needs to be 
fixed and updated when teams are introducing new containers



>

> - Old tests (version N-1) used to verify that there is no regression are not 
> a real problem, they continue to work or need adaptations but we can detect 
> it.

> - New tests (version N) can deal with

> -- new features (needs the ONAP patch merges before being valid - we

> had a misalignmen

Re: TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Krzysztof Opasiak via lists.onap.org]

e branch 
> of the new version is available (RC0)

Well I'm not convinced here. I'd allow those to be added at any time but 
maybe in the beginning we should have a separate category for them like 
"testing" or sth so that they are there but we just don't take them into 
account while merging patches until they are move to other category

> e.g. if we would consider such case today integrate in Master when Honolulu 
> is available (we can always run the tests manually on the staging/daily and 
> prepare the MR for the CI integration)
> - to allow integration of new tests (old features) before the frozen period 
> then after the RC0

As above. Personally I'd prefer to have some kind of control over 
xtesting dockers so that we are not surprised nor affected by their 
changes. Currently oom version is fully independent from them. I believe 
it woudl be great to have even a simple file like xtesting_version in 
the OOM repo that would be used to indicate which version of tests 
should be used.

This would allow your team to work smoothly and integrate tests whenever 
they want and then just update that file whenever we need or you are 
ready to introduce new tests.

Apart from what you mentioned I believe that main issue that we need to 
tackle is the lack of prompt bug fixing in projects.

Some of the issues that we've been fixing recently had jira tickets that 
were created in November and still not fixed. Even I personallyhave a 
patch for OOM that was created half a year ago and I cannot merge it 
because of bug that is in VID that is unfixed for more than half of the 
year. And it's same for many tickets. We (OOM & integration team) 
observe multiple issues and fill in jiras but often there is no interest 
from the project to fix those for a very long time. There is a lot of 
work being done to create new code but not many people care to make sure 
that what they already have works fine. I believe that with such 
attitude our quality and perception of ONAP in general really hurts.

> 
> what is your view?
> 
> 
> De : onap-tsc@lists.onap.org [onap-tsc@lists.onap.org] de la part de Sylvain 
> Desbureaux via lists.onap.org [sylvain.desbureaux=orange....@lists.onap.org]
> Envoyé : mercredi 24 mars 2021 18:34
> À : Krzysztof Opasiak
> Cc : dmcbr...@linuxfoundation.org; Lefevre, Catherine; Seshu m; TIMONEY, DAN; 
> dengyuanh...@chinamobile.com; 徐冉; HAHN III, JIM; Fiachra Corcoran; 
> onap-disc...@lists.onap.org; onap-tsc
> Objet : Re: [onap-tsc] [IMPORTANT] OOM status update for RC0
> 
> Also note that after the break of OOM master branch these last weeks and in 
> order to not break it again, we (the OOM committers) have decided to merge a 
> patch only if the code is OK and if the following rules on gate result is met:
> * changed component must have its pods running
> * if the patch changes one of « core » ONAP component (AAI, DMAAP, SDC, SDNC, 
> SO and VID): we mandate 100% healthchecks and 100% e2e tests to pass
> * for other components, we allow one healthcheck and one e2e test to fail
> 
> As the predictability of an ONAP deployment is not perfect, that a gate takes 
> ~200min, that we have only 4 system gating right now (azure systems tends to 
> fails fast these last days so I’ve decided to remove them for now), try to 
> push your changes as soon as possible if you want to have these changes in 
> Honolulu release.
> 
> Best regards,
> Sylvain
> 
>> Le 24 mars 2021 à 18:17, Krzysztof Opasiak  a écrit :
>>
>> Team!
>>
>> *TL; DR:*
>>
>> OOM patch submitters, please fix your patches/respond to our comments
>> ASAP. Less than 24h has left till RC0 and functional changes not merged
>> before RC0 will be postponed to Istanbul.
>>
>> This is call to all OOM patch submitter but especially to projects: SO,
>> SDNC, VFC, UUI, Policy, DMAAP.
>>
>> *Full text:*
>>
>> Heads-up, there is less than 24 hours left until proposed RC0 date so
>> let me give you the status update for RC0. Please treat it as a reminder
>> for projects who would like to have their functional changes to be
>> included in the Honolulu release.
>>
>> We finally managed to process all 3 categories (bugfix, beforeM3 and
>> afterM3) that we had previously. All patches that are still in our
>> pipeline have been divided into 2 categories using tags:
>>
>> honoluluCandidates - for patches that could be merged before RC0
>> https://protect2.fireeye.com/v1/url?k=aac407ec-f55f3e63-aac58ca3-0cc47a31307c-65c404bf990abdbb&q=1&e=ed62de06-8c17-4197-b0d6-b315c4e2df6d&u=https%3A%2F%2Fgerrit.onap.org%2Fr%2Fq%2Fhashtag%3A%2522honoluluCandidate%2522%2Bstatus%3Aopen
>>
>> istanbul - for pa

TR : [onap-tsc] [IMPORTANT] OOM status update for RC0

[Morgan Richomme via lists.onap.org]

*TL; DR:*

xtesting dockers (tests) and xtesting-onap (test launchers) should have been 
frozen before RC0..so next time we have to think to that..
Integration shall guarantee a stable testing baseline to OOM to gate 
confortably..

Full Text
---

As indicated by Sylvain, the tests in gate are used as a merge criteria

so to avoid any turbulence, I should have frozen 
- the xtesting dockers i.e the tests: no new test - I merged dcaemod yesterday 
- it was false negative, the test was OK but was reported failed for few hours 
(it was not declared in DB, I declared it this morning)
- xtesting-onap: I made an error this afternoon.  I merged a MR dealing with 
weekly rule for tern test on weekly which broke the testing CI part - I just 
saw the approval..and saw the CI issue few minutes too late, I reverted it 
quickly but we missed 2 cycles so ~ 4h. Regarding the numbers of patches to be 
checked before RC0 and the gating resources, I should not have even tried. (I 
oom_redeployed the 2 faulty gates).

it means also that we have to sync on the chronology of the integration of the 
tests in CI.
I assume that we should guarantee a stable test baseline to OOM between before 
the RC0.

- Old tests (version N-1) used to verify that there is no regression are not a 
real problem, they continue to work or need adaptations but we can detect it.
- New tests (version N) can deal with
-- new features (needs the ONAP patch merges before being valid - we had a 
misalignment with policy, the tests were updated but the patch not merged in 
OOM for some weeks, the policy healthcheck was always FAIL)
-- old features that were not covered so far by existing tests (usually not a 
problem as it can be integrated in master eraly during the dev process)

that is why I try to share early in time the CI evolution  some weeks before 
the RC0 => Honolulu CI evolution shared on the 17th of February: 
https://wiki.onap.org/download/attachments/6593670/honolulu_ci_evolution_08022021.pdf?version=1&modificationDate=1612772982000&api=v2

but it is not easy to plan for new tests when the feature will be available

Regarding the tests for Honolulu
- dcaemod (indicated by KK during the February meeting) is fully integrated in 
CI
- tern is under integration
- pnf-macro under test (no new ONAP feature, covering SO macro flow + 
multicloud + simulator management from onaptests)
- basic-clamp under test, we are not far but the lack of stability on master 
prevented to finalize the test
- CDS regression tests: as discussed I wonder if it would not make sense to add 
in in CSIT test first
- stability tests: need also a stable weekly master. For Honolulu we will 
probably not integrate it in CI (problematic to launch long duration tests from 
CI currently under investigation with the tern test)

and very recently due to the SO stuck requests, Michal and myself started 
working on basic_vm_macro and basic_cnf_macro (old feature/new tests).
Note this behavior has been observed in pnf-registrate which is using the macro 
mode

conclusions
I would recommend for next releases
- to freeze the tests/CI Test launcher at RC0-n weeks..n to be defined
- to integrate new tests based on new features only on master when the branch 
of the new version is available (RC0) 
e.g. if we would consider such case today integrate in Master when Honolulu is 
available (we can always run the tests manually on the staging/daily and 
prepare the MR for the CI integration)
- to allow integration of new tests (old features) before the frozen period 
then after the RC0

what is your view?


De : onap-tsc@lists.onap.org [onap-tsc@lists.onap.org] de la part de Sylvain 
Desbureaux via lists.onap.org [sylvain.desbureaux=orange@lists.onap.org]
Envoyé : mercredi 24 mars 2021 18:34
À : Krzysztof Opasiak
Cc : dmcbr...@linuxfoundation.org; Lefevre, Catherine; Seshu m; TIMONEY, DAN; 
dengyuanh...@chinamobile.com; 徐冉; HAHN III, JIM; Fiachra Corcoran; 
onap-disc...@lists.onap.org; onap-tsc
Objet : Re: [onap-tsc] [IMPORTANT] OOM status update for RC0

Also note that after the break of OOM master branch these last weeks and in 
order to not break it again, we (the OOM committers) have decided to merge a 
patch only if the code is OK and if the following rules on gate result is met:
* changed component must have its pods running
* if the patch changes one of « core » ONAP component (AAI, DMAAP, SDC, SDNC, 
SO and VID): we mandate 100% healthchecks and 100% e2e tests to pass
* for other components, we allow one healthcheck and one e2e test to fail

As the predictability of an ONAP deployment is not perfect, that a gate takes 
~200min, that we have only 4 system gating right now (azure systems tends to 
fails fast these last days so I’ve decided to remove them for now), try to push 
your changes as soon as possible if you want to have these changes in Honolulu 
release.

Best regards,
Sylvain

> Le 24 mars 2021 à 18

Re: [onap-tsc] [IMPORTANT] OOM status update for RC0

[Dan Timoney]

Sylvain, Krzysztof:

FYI - I found the root cause for the issues with this review : 
https://gerrit.onap.org/r/c/oom/+/118284 

I'm in the process now of creating updated release builds (the bug is in a 
library shared by a number of repos, so I need to re-release all the dependent 
repos).  Once that's done, I'll push a new changeset to my repo to bump the 
versions of the impacted images (I'll rebase locally before I push that 
changeset so we don't have to do a second gating build for the rebase)

Dan


-- 
Dan Timoney
dtimo...@att.com
Lead Member of Tech Staff
ONAP Project Technical Lead : CCSDK and SDNC projects
 

On 3/24/21, 1:35 PM, "onap-tsc@lists.onap.org on behalf of Sylvain Desbureaux 
via lists.onap.org"  wrote:

Also note that after the break of OOM master branch these last weeks and in 
order to not break it again, we (the OOM committers) have decided to merge a 
patch only if the code is OK and if the following rules on gate result is met:
* changed component must have its pods running
* if the patch changes one of « core » ONAP component (AAI, DMAAP, SDC, 
SDNC, SO and VID): we mandate 100% healthchecks and 100% e2e tests to pass
* for other components, we allow one healthcheck and one e2e test to fail

As the predictability of an ONAP deployment is not perfect, that a gate 
takes ~200min, that we have only 4 system gating right now (azure systems tends 
to fails fast these last days so I’ve decided to remove them for now), try to 
push your changes as soon as possible if you want to have these changes in 
Honolulu release.

Best regards,
Sylvain

> Le 24 mars 2021 à 18:17, Krzysztof Opasiak  a 
écrit :
> 
> Team!
> 
> *TL; DR:*
> 
> OOM patch submitters, please fix your patches/respond to our comments 
> ASAP. Less than 24h has left till RC0 and functional changes not merged 
> before RC0 will be postponed to Istanbul.
> 
> This is call to all OOM patch submitter but especially to projects: SO, 
> SDNC, VFC, UUI, Policy, DMAAP.
> 
> *Full text:*
> 
> Heads-up, there is less than 24 hours left until proposed RC0 date so 
> let me give you the status update for RC0. Please treat it as a reminder 
> for projects who would like to have their functional changes to be 
> included in the Honolulu release.
> 
> We finally managed to process all 3 categories (bugfix, beforeM3 and 
> afterM3) that we had previously. All patches that are still in our 
> pipeline have been divided into 2 categories using tags:
> 
> honoluluCandidates - for patches that could be merged before RC0
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/q/hashtag:*22honoluluCandidate*22*status:open__;JSUr!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGD7i8fyR$
 
> 
> istanbul - for patches that we want to delay till Istanbul (effectively 
> until we branch out honolulu).
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/q/hashtag:*22istanbul*22*status:open__;JSUr!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGJIqm4iL$
 
> 
> So for Honolulu we currently have 18 candidates to be included.
> 
> Out of those, below patches are waiting for the OOM team to review and 
gate:
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/119125__;Kw!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGNFnqZHg$
 
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/117808__;Kw!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGNE_L_4v$
 
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/118925__;Kw!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGGdJG-_j$
 
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/119488__;Kw!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGG0ARglV$
 
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/118248__;Kw!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGH6kXUSs$
 
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/117395__;Kw!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGAgUdiaE$
 
> 
> It seems to be save to say that till tomorrow TSC meeting we should be 
> able to handle most of them unless some unexpected failures occur and we 
> will need submitters to fix their patches.
> 
> Apart from that, below patches are waiting for authors to fix 
> them/respond to our review:
> 
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/113414__;Kw!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGDAb4Dee$
 
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/114380__;Kw!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGJDt1T3I$
 
> 
https://urldefense.com/v3/__https://gerrit.onap.org/r/c/oom/*/118995__;Kw!!BhdT!1tbw10e3gm6y8IKWHpmKxgrO9qVMapwrUcP0OIeTl0mM-KW1YoqNGOmAq0ki$
 

Re: [onap-tsc] [IMPORTANT] OOM status update for RC0

[Sylvain Desbureaux via lists.onap.org]

Also note that after the break of OOM master branch these last weeks and in 
order to not break it again, we (the OOM committers) have decided to merge a 
patch only if the code is OK and if the following rules on gate result is met:
* changed component must have its pods running
* if the patch changes one of « core » ONAP component (AAI, DMAAP, SDC, SDNC, 
SO and VID): we mandate 100% healthchecks and 100% e2e tests to pass
* for other components, we allow one healthcheck and one e2e test to fail

As the predictability of an ONAP deployment is not perfect, that a gate takes 
~200min, that we have only 4 system gating right now (azure systems tends to 
fails fast these last days so I’ve decided to remove them for now), try to push 
your changes as soon as possible if you want to have these changes in Honolulu 
release.

Best regards,
Sylvain

> Le 24 mars 2021 à 18:17, Krzysztof Opasiak  a écrit :
> 
> Team!
> 
> *TL; DR:*
> 
> OOM patch submitters, please fix your patches/respond to our comments 
> ASAP. Less than 24h has left till RC0 and functional changes not merged 
> before RC0 will be postponed to Istanbul.
> 
> This is call to all OOM patch submitter but especially to projects: SO, 
> SDNC, VFC, UUI, Policy, DMAAP.
> 
> *Full text:*
> 
> Heads-up, there is less than 24 hours left until proposed RC0 date so 
> let me give you the status update for RC0. Please treat it as a reminder 
> for projects who would like to have their functional changes to be 
> included in the Honolulu release.
> 
> We finally managed to process all 3 categories (bugfix, beforeM3 and 
> afterM3) that we had previously. All patches that are still in our 
> pipeline have been divided into 2 categories using tags:
> 
> honoluluCandidates - for patches that could be merged before RC0
> https://gerrit.onap.org/r/q/hashtag:%22honoluluCandidate%22+status:open
> 
> istanbul - for patches that we want to delay till Istanbul (effectively 
> until we branch out honolulu).
> https://gerrit.onap.org/r/q/hashtag:%22istanbul%22+status:open
> 
> So for Honolulu we currently have 18 candidates to be included.
> 
> Out of those, below patches are waiting for the OOM team to review and gate:
> https://gerrit.onap.org/r/c/oom/+/119125
> https://gerrit.onap.org/r/c/oom/+/117808
> https://gerrit.onap.org/r/c/oom/+/118925
> https://gerrit.onap.org/r/c/oom/+/119488
> https://gerrit.onap.org/r/c/oom/+/118248
> https://gerrit.onap.org/r/c/oom/+/117395
> 
> It seems to be save to say that till tomorrow TSC meeting we should be 
> able to handle most of them unless some unexpected failures occur and we 
> will need submitters to fix their patches.
> 
> Apart from that, below patches are waiting for authors to fix 
> them/respond to our review:
> 
> https://gerrit.onap.org/r/c/oom/+/113414
> https://gerrit.onap.org/r/c/oom/+/114380
> https://gerrit.onap.org/r/c/oom/+/118995
> https://gerrit.onap.org/r/c/oom/+/118331
> https://gerrit.onap.org/r/c/oom/+/118284
> https://gerrit.onap.org/r/c/oom/+/118510
> https://gerrit.onap.org/r/c/oom/+/119102
> https://gerrit.onap.org/r/c/oom/+/119012
> https://gerrit.onap.org/r/c/oom/+/119124
> https://gerrit.onap.org/r/c/oom/+/118602
> https://gerrit.onap.org/r/c/oom/+/119309
> 
> This means that everything is in your hands now. You need to fix your 
> review ASAP in order to give us time to gate and merge your patch before 
> reaching RC0 as according to new release cadence all OOM reviews that 
> contain functional changes and cannot be merged before RC0 are going to 
> be delayed until Istanbul (we'll just merge it to master as soon as you 
> make it work).
> 
> Special heads up for:
> SO
> SDNC
> VFC
> UUI
> Policy
> DMAAP
> 
> Major  Honolulu container updates for those projects are still in the 
> review and waiting to be fixed. Especially for DMAAP which still 
> contains the hardcoded cert and if we don't get a working version of 
> your review soon then we'll have a certificate issue in master within 
> few days.
> 
> Best regards,
> -- 
> Krzysztof Opasiak
> Samsung R&D Institute Poland
> Samsung Electronics

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is no

[onap-tsc] [IMPORTANT] OOM status update for RC0

[Krzysztof Opasiak via lists.onap.org]

Team!

*TL; DR:*

OOM patch submitters, please fix your patches/respond to our comments 
ASAP. Less than 24h has left till RC0 and functional changes not merged 
before RC0 will be postponed to Istanbul.

This is call to all OOM patch submitter but especially to projects: SO, 
SDNC, VFC, UUI, Policy, DMAAP.

*Full text:*

Heads-up, there is less than 24 hours left until proposed RC0 date so 
let me give you the status update for RC0. Please treat it as a reminder 
for projects who would like to have their functional changes to be 
included in the Honolulu release.

We finally managed to process all 3 categories (bugfix, beforeM3 and 
afterM3) that we had previously. All patches that are still in our 
pipeline have been divided into 2 categories using tags:

honoluluCandidates - for patches that could be merged before RC0
https://gerrit.onap.org/r/q/hashtag:%22honoluluCandidate%22+status:open

istanbul - for patches that we want to delay till Istanbul (effectively 
until we branch out honolulu).
https://gerrit.onap.org/r/q/hashtag:%22istanbul%22+status:open

So for Honolulu we currently have 18 candidates to be included.

Out of those, below patches are waiting for the OOM team to review and gate:
https://gerrit.onap.org/r/c/oom/+/119125
https://gerrit.onap.org/r/c/oom/+/117808
https://gerrit.onap.org/r/c/oom/+/118925
https://gerrit.onap.org/r/c/oom/+/119488
https://gerrit.onap.org/r/c/oom/+/118248
https://gerrit.onap.org/r/c/oom/+/117395

It seems to be save to say that till tomorrow TSC meeting we should be 
able to handle most of them unless some unexpected failures occur and we 
will need submitters to fix their patches.

Apart from that, below patches are waiting for authors to fix 
them/respond to our review:

https://gerrit.onap.org/r/c/oom/+/113414
https://gerrit.onap.org/r/c/oom/+/114380
https://gerrit.onap.org/r/c/oom/+/118995
https://gerrit.onap.org/r/c/oom/+/118331
https://gerrit.onap.org/r/c/oom/+/118284
https://gerrit.onap.org/r/c/oom/+/118510
https://gerrit.onap.org/r/c/oom/+/119102
https://gerrit.onap.org/r/c/oom/+/119012
https://gerrit.onap.org/r/c/oom/+/119124
https://gerrit.onap.org/r/c/oom/+/118602
https://gerrit.onap.org/r/c/oom/+/119309

This means that everything is in your hands now. You need to fix your 
review ASAP in order to give us time to gate and merge your patch before 
reaching RC0 as according to new release cadence all OOM reviews that 
contain functional changes and cannot be merged before RC0 are going to 
be delayed until Istanbul (we'll just merge it to master as soon as you 
make it work).

Special heads up for:
SO
SDNC
VFC
UUI
Policy
DMAAP

Major  Honolulu container updates for those projects are still in the 
review and waiting to be fixed. Especially for DMAAP which still 
contains the hardcoded cert and if we don't get a working version of 
your review soon then we'll have a certificate issue in master within 
few days.

Best regards,
-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#7648): https://lists.onap.org/g/onap-tsc/message/7648
Mute This Topic: https://lists.onap.org/mt/81582486/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: 
https://lists.onap.org/g/onap-tsc/leave/2743226/21656/1412191262/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-