Re: [onap-tsc] [OOM] Move to gitlab (from Gerrit)

[Krzysztof Opasiak via lists.onap.org]

Hi,

On 30.11.2021 16:46, sylvain.desbure...@orange.com wrote:

Hello,

as said during TSC meeting on November, 4th, plan was to start "move 
process" from gerrit to gitlab one week after Istanbul release sign off.



I've worked on a fake (actually forked) repo of OOM to prepare that 
(https://gitlab.com/sylvainOL/oom) and I'm able to validate the 
following parts:



  * check that CLA is signed via external status check
  * all linting used today, including helm
  * launch a gate when all "basic" linting are green + change is done in
Kubernetes side.
  * gating projects on gerrit and in parallel other projects on gitlab
should work


you can see here (https://gitlab.com/sylvainOL/oom/-/merge_requests/3) 
what look likes a Merge request (this one has been used for a lot of 
tests, apology for the mess...) if you're interested (note that it's not 
green)


Now, I need to create a CONTRIBUTE.md file in order to explain how to 
contribute and we should be good


So my question is: how do we proceed now?

  * do I make a MR on gerrit to add the needed files in gerrit and then
we move to gitlab?


I'd vote on this one because currently we are just mirroring gerrit to 
gitlab. Migration the other way around is not possible so I'd suggest to 
switch to gitlab when everything is in place



  * do we move to gitlab and I add the needed files there?
  * do we do a "test" with selected usual contributors of OOM in the
forked OOM before move?


We cannot do a test. As far as I know gerrit would not be able to accept 
changes made outside as it expects to be "the owner of the repo"





thanks in advance for your comments,

Sylvain

_

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 not liable for messages that have been 
modified, changed or falsified.
Thank you.



--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8317): https://lists.onap.org/g/onap-tsc/message/8317
Mute This Topic: https://lists.onap.org/mt/87405094/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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] [ONAP] [Integration] Stepping down as Integration PTL

[Krzysztof Opasiak via lists.onap.org]

Morgan,

Big kudos an a huge THANK YOU for all the hard work that you did.

You really made an impact on the community and made ONAP a better place;)

On 04.05.2021 10:45, morgan.richo...@orange.com wrote:

Dear ONAP community and Integration team,

As announced in Guilin, Honolulu was the last release for me as 
Integration PTL.


I will still contribute to ONAP integration but Integration PTL requires 
a 100% commitment, which is no more possible due to changes of 
assignment within my company.
As several committers in Integration, I must now share my ONAP 
activities between community and internal activities, which is a good 
signal on ONAP adoption.


The 3 last versions were challenging and intense.
I would like to thankthe Integration team, I was lucky to work with such 
a great team.
I would like also to thank OOM and all the other project teams**for 
their patience and willingness.
I hope we built good baselines to ensure the sustainability of the 
solution and ensure a good balance between cutting edge PoCs and 
production ready solution.


I will still contribute to ONAP and will help with the transition.

Orange will also officially stop the support of the Orange openlab**as 
the Azure staging lab is enough for the community needs.

For the moment we keep all our daily|weekly|gating lab resources.
We will be more than happy to share also this load in the future with 
other company members and look carefully on the Intel/Windriver lab 
evolution.


I will send a call for nominations shortly

Many thanks and best regards

Morgan

_

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 not liable for messages that have been 
modified, changed or falsified.
Thank you.



--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#7821): https://lists.onap.org/g/onap-tsc/message/7821
Mute This Topic: https://lists.onap.org/mt/82573124/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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Krzysztof Opasiak via lists.onap.org]

Hi Xu Ran,

On 30.03.2021 09:34, Xu Ran wrote:
> Hi Opasiak,
> 
> I agree with your "train theory" and I think UUI team will accept the 
> result of TSC’s decision.
> Yesterday, I just wanted to make sure whether a commit without any 
> change of oom configuration can be merged since all the codes were just 
> minor functional changes.

So just for the record and to make sure that everyone is on the same 
page in a future:

before M3 projects can submit any number of patches to OOM that include:
- new charts or subcharts
- updates of containers that adds a new feature or improves the existing 
features
- updates of containers that contains bugfixes
- OOM bugfixes (those which are in helm charts)
- helm charts improvements
- any other oom rework

after M3 we expect to get:
- updates of containers that contains bugfixes
- OOM bugfixes (those which are in helm charts)
- helm charts improvements (but only really small)


> And I admit that we have misunderstood the 
> meaning of jira: https://jira.onap.org/browse/USECASEUI-545 
> <https://protect2.fireeye.com/v1/url?k=381f64fd-67845dff-381eefb2-0cc47a312ab0-3a3f94d5fc14610c=1=ff9b2be1-4f16-40f2-908e-e707d1c1d2e3=https%3A%2F%2Fjira.onap.org%2Fbrowse%2FUSECASEUI-545>
>  because 
> we think codes only need to committed in M3 if the oom configuration has 
> been changed, but actually we didn’t have to do that. A 4 weeks’ delay 
> occurs because we have *never* considered M3 as a deadline. So we have 
> never “asked” you guys to do anything, if oom thinks it’s unacceptable 
> to merge the codes, we are definitely ok to delay it to Istanbul 
> release, I just want to make sure of it.

Just to be sure that we are on the same page. From the OOM perspective 
there is no technical issues with your patch. Gating was fine so there 
is nothing technical that prevents us from merging that patch only the 
administrative part.

Thank you for providing the feedback regarding the jira ticket! It's a 
really important feedback and I believe we'll need to work on that Jira 
ticket together with David to avoid such confusion in the future.

No matter what decision the TSC will make please make sure that your 
patch is very high on our priority list. Based on the TSC decision it 
will be merged as soon as possible either for Honolulu or to master (as 
soon as we branch out honolulu)

> As for your suggestion about 
> the vote in TSC, we totally agree with the process and will accept any 
> result of it. Thank you very much.

Thank you for your kind understanding. I believe that what's really 
crucial here is the feedback that you provided that the jira ticket 
wasn't clear enough for you and that's the main reason of this delay.

> 
> BTW, China Railway High-speed is also very punctual, welcome to Beijing 
> and enjoy it.

Thank you for the invitation! I'd pleased to try it:) I've never been in 
Beijing so I'm really looking forward to visit it!

> 
> 
> 
> 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/30/2021 06:21，Krzysztof Opasiak via 
> lists.onap.org 
> <mailto:k.opasiak=samsung@lists.onap.org> wrote：
> 
> 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 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=072c4f49-58b77645-072dc406-

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=1=13bf9413-fa82-4d44-af46-f2798b79332a=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$
>> "
>>
>> 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=1=13bf9413-fa82-4d44-af46-f2798b79332a=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=1=13bf9413-fa82-4d44-af46-f2798b79332a=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
>> UUI Container. To be confirmed by *XU*
>>
>> https://protect2.fireeye.com/v1/url?k=21237f50-7eb8461d-2122f41f-0cc47aa8f5ba-a75d6d213166b4a8=1=13bf9413-fa82-4d44-af46-f2798b79332a=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
>> 

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) Dan T to review the comments from Morgan

I believe 

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

[Krzysztof Opasiak via lists.onap.org]

Hi,

On 24.03.2021 19:35, 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 
> misalignment with policy, the tests were updated but the patch not merged in 
> OOM for some weeks, the policy healthcheck was always FAIL)

That's obviously a chicken and egg problem that can be solved in many 
ways but either of them would require some changes in the gating

One of them that I can imagine is to keep the reference to xtesting 
docker version in then OOM repo.

To updates xtesting dockers you need oom commit, as you need oom commit 
every change of those dockers would be gated.

Additionally everyone who introduces or modifies a feature and needs to 
user newer version of xtesting docker may update it in the same commit 
as the functional change.

Not sure if it's the best idea but still it's at least some idea...
What do you think?

> -- 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://protect2.fireeye.com/v1/url?k=c0ae9ad2-9f35a35d-c0af119d-0cc47a31307c-9d5162ca6ac8b403=1=ed62de06-8c17-4197-b0d6-b315c4e2df6d=https%3A%2F%2Fwiki.onap.org%2Fdownload%2Fattachments%2F6593670%2Fhonolulu_ci_evolution_08022021.pdf%3Fversion%3D1%26modificationDate%3D1612772982000%26api%3Dv2
> 
> 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

Personally I still believe that main fault is on us as OOM committers. 
We've been really to gentle with the review and allow patches to be 
merged trying to persuade ourselfs that we know the root cause of the 
issue, not taking into account that this one issue that we know may hide 
tons of other issues.

> I would recommend for next releases
> - to freeze the tests/CI Test launcher at RC0-n weeks..n to be defined

I'd say that the deadline here would be same as end of coding for projects.

> - to integrate new tests based on new features only on master when the 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 

[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 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]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-tsc] RC0 blockers a step forward has been made

[Krzysztof Opasiak via lists.onap.org]

Dear all,

Let me provide the status update for our blocking issue in the master 
branch.

It seems that we managed to bring master to a workable state.
Currently we have a workaround for the nasty bug in VID but I'm working 
on proper solution that we hope to merge before EOW.

This means that we finally unlocked our OOM review pipeline. We believe 
that the realistic date for RC0 is next Thursday (25th).

As the number of reviews (>70) in our pipeline is overwhelming for the 
work force that we've performed a triage on those patches has been 
performed.
We divided all patches into 3 categories:

Bugfixes (from the OOM perspective):
https://gerrit.onap.org/r/q/hashtag:%22bugfix%22+(status:open%20OR%20status:merged)

Reviews created before M3:
https://gerrit.onap.org/r/q/hashtag:%22beforem3%22+(status:open%20OR%20status:merged)

Reviews created after M3:
https://gerrit.onap.org/r/q/hashtag:%22afterm3%22+(status:open%20OR%20status:merged)

OOM patches are going to be processed in this order. We'll do our best 
to review and merge category 1 & 2 before RC0 but to make it happen we 
really need project teams to be supportive and fix issues reported in 
the review promptly.

* IMPORTANT NOTE TO PTLs: *
We are using gerrit hashtags for our triage process thus please DO NOT 
MODIFY TAGS ASSIGNED BY THE OOM TEAM ON YOUR OWN. You can always write 
an email or catch us on slack and discuss if sth from 3rd category has 
to be merged for Honolulu but don't move your patch between categories 
on your own.

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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#7634): https://lists.onap.org/g/onap-tsc/message/7634
Mute This Topic: https://lists.onap.org/mt/81413900/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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-requirements-sub] [onap-tsc] Continuing a REQ from one release to the next #guilin #honolulu

[Krzysztof Opasiak via lists.onap.org]

Hi,

so as long as it goes about the new release process I share Lukasz point 
of view.

Key differences between old release process and new one is:

1) Split technical discussion on proposed change and the resource discussion

2) Let people interested in the requirement plan their work how they 
want and not force them to do everything till the particular milestone.

So in the new release process the Feature or Spec is a technical 
description of the proposed change. It should clearly present what 
people want to achieve and by design this is not tight to the particular 
release. The only thing that we require is to get Feature/Spec approved 
by impacted parties before the M2. If someone fails to meet the deadline 
and get it approved a week later his or her feature can be worked on in 
the next release but not the current one.

As we have removed the resource part from the table, TSC will no longer 
need to waste their time to try to asses how many Features or specs we 
can fit into particular release or to decide what to descope and what 
not. If the proposed change is technically correct and impacted parties 
are fine with it then community may start working on it. When it will be 
ready? It's all matter of resources that community is willing to 
dedicate to this task but it's purely the decision of interested 
companies. If this feature has top priority for them they may assign 
enough resources to implement that in a week but if it's a low priority 
task they may be working on it for 3 years. When they finish and test 
their solution they would just report to TSC by updating particular 
ticket that this feature is finally ready and that's it.

This model is nothing new in the open source community. It's exactly the 
model in which Open Stacks specs or kubernetes KEPs are being used.

On 02.12.2020 19:38, David McBride wrote:
> Remember that scope affects planning and resource allocation for the 
> release.  It also affects how the TSC evaluates milestone progress and 
> GO/NOGO decisions.  For example, the component impact table documents 
> what components will be impacted by the defined scope of the 
> requirement.  If your scope includes work that you won't do until 
> subsequent releases, then the component impact table may imply 
> allocation of resources that isn't necessary.
> 
> Also, if your defined scope is broader than what you intend to complete 
> in the release, then it confuses TSC evaluation of your progress at 
> milestones.
> 
> Perhaps a good compromise would be to include two parts in the 
> requirement description.  The first part would document the overall 
> scope of the requirement, while the second part would document the scope 
> that you intend to complete for the current release.
> 
> David
> 
> On Wed, Dec 2, 2020 at 10:21 AM Rajewski Łukasz - Hurt 
> mailto:lukasz.rajew...@orange.com>> wrote:
> 
> So we mix here scope for release with the scope of the entire
> requirement  what is not the same. If the requirements can be
> defined for many releases the scope for each release is a part of
> the entire one. Otherwise what we mean by continuation of
> requirements by design? There is no such option then and you
> consider only continuation for reqs that have some leftovers but the
> original plan was to deliver them in one release. 
> 
> __ __
> 
> So do we really let requirements to be split into many releases by
> design? I have an impression that no because nobody plans
> non-intentional delays in the implementation by design.
> 
> __ __
> 
> Regards,
> 
> __ __
> 
> Logo Orange
> 
>   
> 
> *Łukasz Rajewski*, R Expert
> Orange Labs Poland, Advanced Network Solutions Agency
> *Mob.: +48 519 310 854*
> Orange Polska, Obrzeżna 7, 02-691 Warsaw
> www.orange.pl 
> 
> *From:*David McBride  >
> *Sent:* Wednesday, December 2, 2020 6:51 PM
> *To:* Rajewski Łukasz - Hurt  >
> *Cc:* onap-tsc@lists.onap.org ;
> onap-release  >;
> onap-usecase...@lists.onap.org
> ; Kenny Paul
> mailto:kp...@linuxfoundation.org>>
> *Subject:* Re: [onap-requirements-sub] [onap-tsc] Continuing a REQ
> from one release to the next #guilin #honolulu
> 
> __ __
> 
> I respectfully disagree. 
> 
> __ __
> 
> It's fine to plan implementation of a requirement over multiple
> releases.  Nothing in this process contradicts that. However, the
> scope defined in the Jira issue, should be the scope that you expect
> to complete _for that release_, and not the entire requirement. 
> 
> __ __
> 
> David
> 
> __ __
> 
> On Wed, Dec 2, 2020 at 9:45 AM Lukasz Rajewski via lists.onap.org
> 
> 

[onap-tsc] Removing POMBA from OOM helm charts

[Krzysztof Opasiak via lists.onap.org]

Hi,

As the number of helm charts in OOM repo is constantly growing while our 
team is still the same size we would like to reduce the amount of 
maintenance work on the components that are not actively used by the 
community. Thus we would like to remove all POMBA charts from oom repo.

This is the final call to the community to speak up and let us know if 
you are using POMBA and you would strongly prefer to keep it.

We plan to ask TSC for an agreement during 3/12/2020 call. Please let us 
know before that date if you have any concerns.

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


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

Re: [onap-tsc] [onap-discuss] [ONAP] CD chains and CSIT tests strongly impacted by dockerhub policy change

[Krzysztof Opasiak via lists.onap.org]

On 19.11.2020 18:53, Jessica Wagantall wrote:
> Hi Morgan,
> 
> I brought this concern to Steve Winslow. Let me quote his reply so that 
> there is no confusion:
> 
> "If we are pulling the build image from our nexus solely for internal 
> runs and not making the third party images available to external folks, 
> then I'm not concerned about that."
> "The issue we had talked about with the ONAP teams earlier this year was 
> that we should not be redistributing binary container images / layers 
> that consist of base layers outside the ONAP project. It's okay to point 
> to pulling those base layers from DockerHub or third party sources but 
> we should not be redistributing them ourselves."

Right. So the bottom line is that only LF internal system will be able 
to use nexus as a proxy right?

> 
> Please let me know if this clarifies the concern
> 
> Thanks!
> Jess
> 
> 
> On Wed, Nov 18, 2020 at 11:21 PM  > wrote:
> 
> Hi,
> 
> recently Docker has enabled download rate limits for pull requests
> on Docker Hub.
> Several upstream components used in ONAP are hosted in dockerhub.
> 
> As a consequences lots of CD chains or CSIT tests are now failing
> due to the error:
> "Error response from daemon: toomanyrequests: You have reached your
> pull rate limit. You may increase the limit by authenticating and
> upgrading: https://www.docker.com/increase-rate-limit;
> 
> Some CSIT tests committed patches to use the Nexus3 as a proxy/cache
> for these upstream repositories.
> 
> It has obviously major impacts on integration activities.
> 
> @Jessica do you confirm that it is possible and there is no legal
> issues? as far as I remember it was decided not to host third-party
> dockers for legal issues, caching them is not very different from
> hosting, no?
> 
> As far as I can see Mirantis that acquired the dockerhub activities
> recently is a member of the lfn networking, is there any way to
> discuss with their representatives to see if they could exclude
> community activities from this rate limitation mechanism?
> 
> 
> Regards
> 
> /Morgan
> 
> 
> 
> 
> 
> _
> 
> 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 not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
> 
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics


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

Re: [onap-tsc] [OOM] PTL election results

[Krzysztof Opasiak via lists.onap.org]

Congratulation!

On 21.07.2020 16:28, eric.deb...@orange.com wrote:

Congrats to Sylvain

Best regards

Eric

*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é :* mardi 21 juillet 2020 15:56
*À :* onap-tsc@lists.onap.org
*Cc :* onap-rele...@lists.onap.org; Borislav Glozman; Mike Elliott; 
Krzysztof Opasiak

*Objet :* [onap-tsc] [OOM] PTL election results

Dear TSC members,

All committers of OOM project have voted 
(https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_3584830cbf9b0f18).


I've been elected as PTL.

Thanks OOM committers for their confidence.

Best regards,
Sylvain Desbureaux

_

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 not liable for messages that have been 
modified, changed or falsified.
Thank you.



_

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 not liable for messages that have been 
modified, changed or falsified.
Thank you.



--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6832): https://lists.onap.org/g/onap-tsc/message/6832
Mute This Topic: https://lists.onap.org/mt/75703864/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] [Maintenance Release]Status Update

[Krzysztof Opasiak via lists.onap.org]

+ onap-tsc
+ onap-ptl (if I have permissions)

On 20.07.2020 11:46, sylvain.desbure...@orange.com wrote:

Hello,

here's Monday status update for El Alto and Frankfurt Maintenance release.
Fyi, I've no right to send emails to onap-tsc and onap-ptl, so I'm 
trying 'onap-release' channel.


[El Alto]

https://gerrit.onap.org/r/q/project:oom+status:open+branch:elalto 


All Proposed merge requests have been merged.

from https://gating-results.onap.eu/results/, 
 
we can see:


* Failing deployments (consistant on the 4 last runs):
CLAMP ELK stack is not starting (no idea why, no 'events' when I looked 
at) --> I consider it as MINOR and RN should be updated


* Failing Healtchecks (consistants on the 4 last runs):
OOF CMSO is failing (Certificate issue?) --> I consider it as MEDIUM 
(some use cases won't work) and RN should be updated
Modeling is failing (via MSB call) no idea why --> I consider it as 
MEDIUM (some use cases won't work) and RN should be updated


Everything is red but actually, the rest is OK (small, core, healthdist, 
postinstall)


* E2E
All tests are red
Onboarding is OK but issue during instanciation between SO and Openstack 
I believe ({'requestState': 'FAILED', 'statusMessage': "STATUS: Received 
vfModuleException from VnfAdapter: category='INTERNAL' 
message='Exception during create VF 404 NOT FOUND: ' rolledBack='true'", 
'percentProgress': 100, 'timestamp': 'Mon, 20 Jul 2020 06:22:59 GMT'})
--> Unfortunately, our 2 instanciation expert on Orange are on holidays 
so I can't say why :(



So it's not perfect but not that bad either. I let TSC to decide what to do


[Frankfurt]

https://gerrit.onap.org/r/q/project:oom+status:open+branch:frankfurt 

All Proposed merge requests have been merged except one (we -- OOM 
committers -- consider it as a new feature and we rather prefer not to 
merge).


Last gating is "super green" (100% infra, 100% HC, 100% e2e) :) --> 
https://gating-results.onap.eu/results/onap_daily_pod4_frankfurt-645985740-07-20-2020_02-07/ 




My recommendation (from OOM perspective but I believe Morgan from 
Integration would say the same) is a GO for the maintenance release


Regards,

Sylvain Desbureaux

_

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 not liable for messages that have been 
modified, changed or falsified.
Thank you.



--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6808): https://lists.onap.org/g/onap-tsc/message/6808
Mute This Topic: https://lists.onap.org/mt/75678726/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] [ONAP][Maintenance Releases] What's onboarded from an OOM point of view

[Krzysztof Opasiak via lists.onap.org]

On 16.07.2020 11:54, Krzysztof Opasiak wrote:

s/CC/TO/ Mateusz Pilat

Just to make sure that he notices this email;)


sic! Your better than me:D I should have read the whole thread before 
responding;)




On 16.07.2020 08:56, sylvain.desbure...@orange.com wrote:

Hello David,
Here's my take on the two spreadsheet for OOM:

El Alto:
OOM-2361
:
@Mateusz, do you have some news on this one?


^^ This is the question to you Mateusz;)


OOM-2392
:
cause of OOM-2336

so "matched"
All OOM "not matched" will be obviously in Release and release note


Frankfurt:
OOM-2316
:
this is a feature we rolled back because of bad behavior. *Will not* be
part of Frankfurt Maintenance Release


By the way, I'm not allowed anymore to send emails to
onap-...@lists.onap.org  and
onap-tsc@lists.onap.org . Is it normal?

Regards,
Sylvain

*De :* David McBride [dmcbr...@linuxfoundation.org]
*Envoyé :* mercredi 15 juillet 2020 22:36
*À :* Krzysztof Opasiak
*Cc :* TIMONEY, DAN; DESBUREAUX Sylvain TGI/OLN; LEFEVRE, CATHERINE;
LUCAS, JACK; HERNANDEZ-HERRERO, JORGE; fiachra.corco...@est.tech;
marek.szwalkiew...@external.t-mobile.pl; LUNANUOVA, DOMINIC; DETERME,
SEBASTIEN; PARTHASARATHY, RAMESH; seshu.kuma...@huawei.com; DRAGOSH,
PAM; SONSINO, OFIR; MALAKOV, YURIY; onap-...@lists.onap.org;
onap-tsc@lists.onap.org; DEBEAU Eric TGI/OLN; RICHOMME Morgan TGI/OLN
*Objet :* Re: [ONAP][Maintenance Releases] What's onboarded from an OOM
point of view

Thanks for starting this thread.  I'd like to use this discussion to
reconcile the different views on the content of the maintenance releases.

I took all of the Jira issues referenced in this thread and put them
into two spreadsheets; one for El Alto, and one for Frankfurt.  Each
spreadsheet has two tabs:  "Matched" and "Not Matched". All of the
issues in Jira that are labeled for the maintenance release are shown in
the left hand column on the "Matched" tab.  In the columns to the right
are where the labeled issues in Jira match with an issue cited by one of
you.

The "Not Matched" tab shows issues that one of you cited, that are not
currently labeled for the maintenance release.

I'm happy to take all of the "Not Matched" issues and apply the
maintenance release label to them, en masse.

What I would like for you to do is to look at the issues in the
left-hand column on the "Matched" tab, that are not matched by an issue
in this email, and consider whether they should be included, or excluded.

David

On Wed, Jul 15, 2020 at 11:25 AM Krzysztof Opasiak
mailto:k.opas...@samsung.com>> wrote:



 On 15.07.2020 20:08, TIMONEY, DAN wrote:
  > Krzysztof,
  >
  > For Guilin, instead of certInitializer, how about if we change
 dgbuilder to use http instead of https and use it as a trial for
 using an ingress controller instead of a node port?  Since dgbuilder
 is a design time tool primarily, it's pretty isolated and low risk-
 and then we'll have one less cert to have to worry about maintaining.

 Well as long as it is exposed to the outside world it should be https.
 So we can either:

 1) Change its type to ClusterIP if doesn't have to be exposed.
 2) Keep it https;)

  >
  > For Frankfurt, could we cherry pick that same change?   If so,
 I'm happy to make that a priority if you can provide some pointers
 on how to switch from using a node port to ingress controller for
 the dgbuilder service, and then I can make that change once the
 right way.

 Actually there is nothing to do from OOM perspective apart from
 enabling
 ingress;)

 All the ingress configuration (with SSL passthrough) is already there.
 The only thing that you need to do is to make sure that dgbuilder can
 actually work with ingress which means that there is no hardcoded
 urls etc

  >  Otherwise, I'm happy to install those certs in the Frankfurt
 branch like Sylvain did for us for the CDS py-executor pod recently.

 That's exactly what I've been talking about:)

  >
  >
  > Dan
  >
  > -Original Message-
  > From: Krzysztof Opasiak 

[onap-tsc] Follow-up on release cadence?

[Krzysztof Opasiak via lists.onap.org]

Dear ONAP TSC,

Last Wednesday we had a final meeting on a release cadence proposal.
I hope that we managed to answer all the questions but if not please 
feel free to ask them in this thread or via wiki 
(https://wiki.onap.org/display/DW/Release+Cadence+Proposal).

As there were no more points to discuss I'd like to ask for your opinion 
on how to proceed with this? Should we present it to TSC or do sth else?

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6758): https://lists.onap.org/g/onap-tsc/message/6758
Mute This Topic: https://lists.onap.org/mt/75500087/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] List of approved licenses in ONAP dockers

[Krzysztof Opasiak via lists.onap.org]

Dear TSC,

this is a gentle reminder about a below request just to make sure that 
it didn't got lost.

On 06.07.2020 16:03, Krzysztof Opasiak wrote:
> ***DISCLAIMER***
> 
> I'm not a lawyer. My comments may be biased and imprecise thus if you
> have any doubts regarding any of licenses mentioned in this email please
> contact your lawyer.
> 
> @Steve
> Please correct me if I made any mistake on the licenses described below.
> 
> ***END DISCLAIMER**
> 
> Dear TSC,
> 
> I'd like to kindly ask you to approve or reject usage of packages in
> ONAP containers that are licensed under:
> 
> Apache-2.0 - same as ours
> 
> Artistic - "equivalent of GPL" extended beyond software
> 
> GFDL
> GFDL-1.2
> GFDL-1.3 - copyleft licenses used for documentation
> (https://en.wikipedia.org/wiki/GNU_Free_Documentation_License)
> 
> GPL-1 - copyleft license (for difference to popular v2 see
> https://stackoverflow.com/questions/2844055/what-is-the-difference-between-gplv1-to-gplv2-in-simple-words)
> 
> GPL-2 - copyleft license (probably the most popular).  Everything that
> links with GPL code has to be GPL but you may use it in docker image
> without linking and then you code may be under different license but you
> need to make sure that users of your software will get the copy of GPL
> license and access to the source code that was used to create the binary
> 
> GPL-3 - copyleft license which extends the restrictions put by GPL v2 to
> not only provide the source code and license text but also exact
> instructions how to replace the given component in your product. Many
> companies have concerns regarding this license thus please pay spacial
> attention to this one.
> 
> LGPL-2
> LGPL-2.1
> LGPL-3 - used for libraries. The library code is licensed under
> particular version of GPL but does not enforce GPL license on the
> component that links with it. (unless you modify the library itself)
> 
> MPL-1.1
> MPL-2.0 - mozilla public license
> (https://en.wikipedia.org/wiki/Mozilla_Public_License)
> 
> OpenSSL License - used in older versions of openssl now openssl uses
> apache 2.0 (https://www.openssl.org/source/license.html)
> 
> 
> There is also a dozen of less popular but usually permissive and widely
> accepted licenses:
> 
> BSD
> MIT
> CC0-1.0
> zlib
> boost
> OpenLDAP
> Python
> SISSL
> Vim
> ISC
> 
> 
> Best regards,
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6757): https://lists.onap.org/g/onap-tsc/message/6757
Mute This Topic: https://lists.onap.org/mt/75333278/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] [ONAP] [Frankfurt] [Maintenance release] status on certificates

[Krzysztof Opasiak via lists.onap.org]

On 09.07.2020 14:28, ZWARICO, AMY wrote:
> Expired certificates: Is it possible to have the hard-coded certs 
> replaced by the init container for the maintenance releases because that 
> is the best long term solution?

I'm happy to take such patches into oom

> 
> @krzysztof please give your perspective >
> Proposal: Certificate management is a “must” criteria for maturity.
> 
> SSL/TLS versioning: please send a list of the SSL/TLS errors and I will 
> review. Projects should use TLS 1.2 or higher (all standard browsers 
> support TLS 1.3). Earlier version of TLS and all versions of SSL are broken.
> 
> *From:* onap-tsc@lists.onap.org  *On Behalf Of 
> *Morgan Richomme via lists.onap.org
> *Sent:* Thursday, July 9, 2020 3:12 AM
> *To:* onap-rele...@lists.onap.org; onap-...@lists.onap.org; 
> onap-tsc@lists.onap.org
> *Cc:* Paweł Wieczorek ; ZWARICO, AMY 
> ; 'Pawel Pawlak' ; Krzysztof Opasiak 
> 
> *Subject:* [onap-tsc] [ONAP] [Frankfurt] [Maintenance release] status on 
> certificates
> 
> Hi
> 
> I know that we are approaching the Frankfurt maintenance release.
> 
> I was wondering what is planned regarding the certificates.
> 
> I shared the certificate view from the nodeport perspective some weeks ago.
> 
> Yesterday we detected that an internal certificate also expired 
> (aaf-cert-service) so I gave a try on all the ports I found from inside 
> the cluster (experimental ~ systematic try, I am not sure it is 100% 
> relevant).
> 
> I attached both reports in the mail.
> 
> What we can see
> 
> on the nodeport report (test executed as end user calling the exposed 
> https endpoints) nothing new regarding the previous report
> 
> 1) the 2 dgbuilder certificates have expired since almost 1 year.
> 
> @Taka, Dan: shall we keep them as such?
> 
> 2) Refrepo expired 17 days ago
> 
> @Kanagaraj any plan?
> 
> 3) so-vnfm
> 
> @seshu would it be fixed with the next generation of dockers planned for 
> the maintenance release?
> 
> 4) several projects include too long certificates and the root CA is not 
> correct
> 
> robot: so it is for the Integration PTL :), this pod is only for testing.
> 
> I do not plan to do anything for the Frankfurt maintenance release. But 
> a refactoring of this pod is planned for Guilin)
> 
> What about the uui, msb, cli, appc project, which are part of the release?
> 
> on the internal report we have additional info as we are trying all the 
> ports reported by the kubernetes client on the ONAP namespace
> 
> we do not see the recent expiration because the deployment failed due to 
> the expiration. There is a patch in gate to fix aaf-cert-service
> 
> esr-server certificate expired more than 2 days ago..
> 
> without surprise holmes certificates are expired. We do not test them 
> but the components are still deployed.
> 
> multicloud certificates are also too long
> 
> I got lots of SSL errors, either wrong version number , SSLv3 bad 
> certificate,  I am not an expert so I am not 100% sure of the test 
> results but I got lots of such errors when I try to retrieve internal 
> certificates. Seccom has surely a better view on that.
> 
> /Morgan
> 
> BTW: shall the certificate management not be a criteria for maturity? I 
> guess the answer is yes. It seems that there are still lots of work for 
> most of the projects in this area.
> 
> _
> 
> 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 not liable for messages that have been 
> modified, changed or falsified.
> 
> Thank you.
> 
> 
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6753): https://lists.onap.org/g/onap-tsc/message/6753
Mute This Topic: https://lists.onap.org/mt/75393481/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

[Krzysztof Opasiak via lists.onap.org]

... and correct Pawel Pawlak email;)


On 05.06.2020 16:53, Krzysztof Opasiak wrote:
> Hi Jason,
> 
> On 05.06.2020 16:27, Jason Hunt wrote:
>>    Krzysztof,
>> Great point.  There are two options to address it:
>> 1. The TSC votes to amend the Technical Community Document to include
>> security in the criteria for the mature state
>> 2.  We modify the template for the maturity reviews to allow for
>> security information to be included under the "mature artifacts"
>> criteria.  The TSC would then include that in its decision whether a
>> project has met the "mature artifacts" portion of the criteria.
> 
> I'll deffer this to Pawel & Amy to decide which way to go.
> 
>> I would prefer the latter and am happy to make the update.  Please let
>> me know if there is suggested input you would like to see from projects
>> so that we can update the template accordingly.
> 
> I'd definitely would like to make sure that before any project is called
> mature it:
> 
> 1) Does not hardcode any credentials in the container & OOM helm charts
> 2) Its docker containers are free of any hardcoded certificates
> 3) It doesn't use static TLS certificates but obtains them at runtime
> 4) It has no open OJSI tickets
> 5) It has no known vulnerabilities in its direct dependencies
> 6) It uses base image that is free of license violation and
> vulnerabilities (aka recommended by seccom)
> 7) Does not run as a root
> 8) Does not access any DB as root from the application container (unless
> there is a valid reason for that which has been presented & approved by
> SECCOM)
> 9) Does not access any DB that is owned by other service
> 10) Uses only well-known, open source libraries for handling crypto
> 11) Does not contain its own user store
> 12) Can be access & used via ingress controller
> 13) Has no runtime Internet dependencies
> 14) Use secure communication to access anything that is outside of
> kubernetes cluster
> 15) Has no unprotected APIs/UIs exposed
> 16) Has only a single process per container
> 17) Has properly configured liveness & readiness checks
> 18) Container rootfs is mounted read-only
> 
> @Pawel
> @Amy
> Do you have anything more to add?
> 
>> By the way, for the "core" state of projects (which comes after
>> "mature"), the criteria in the Technical Community Document include:
>> "Stability, Security, Scalability and Performance levels have reached a
>> high bar."
> 
> Right. But it would be great to ensure some "basic" security from
> project which is called mature right?
> 
>>
>> Regards,
>> Jason Hunt
>> Distinguished Engineer, IBM
>>
>> Phone: +1-314-749-7422
>> Email: djh...@us.ibm.com
>> Twitter: @DJHunt
>>
>>  - Original message -
>>  From: "Krzysztof Opasiak via lists.onap.org"
>>  
>>  Sent by: onap-tsc@lists.onap.org
>>  To: onap-tsc@lists.onap.org, onap-rele...@lists.onap.org, Jason Hunt
>>  
>>  Cc: "pawel.pawl...@orange.com" , "ZWARICO,
>>  AMY" 
>>  Subject: [EXTERNAL] Re: [onap-tsc] ONAP Project Lifecycle:
>>  recommended actions
>>  Date: Fri, Jun 5, 2020 9:05 AM
>>  Hi Jason,
>>
>>  On 05.06.2020 00:13, Jason Hunt wrote:
>>   > TSC and PTLs,
>>   > Per the discussion in today's TSC meeting, we wanted to make everyone
>>   > aware of the ONAP project lifecycle and encourage projects to
>>  consider
>>   > their status and any changes.
>>   > The current lifecycle is depicted in this diagram:
>>   >
>>   > The suggestion is that we use this lifecycle to place the ONAP
>>  project
>>   > portfolio into three buckets:
>>   >
>>   > -*Mature projects:*for projects with active release participation &
>>   > solid artifacts; they should submit for a "maturity review"
>>   >
>>   > - *Inactive (Archived) projects*: for projects where there is no
>>  longer
>>   > any contributions, they should follow the termination review
>>   >
>>   > -*Other (Incubation) projects*: for those projects that are still
>>  active
>>   > but not ready for move to "mature" phase
>>   >
>>   > For *mature projects*, the TSC encourages qualifying projects to
>>  submit
>>   > for a maturity review.  They do this by filling out the template
>>  in the
>>   >

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

[Krzysztof Opasiak via lists.onap.org]

Hi Jason,

On 05.06.2020 00:13, Jason Hunt wrote:
> TSC and PTLs,
> Per the discussion in today's TSC meeting, we wanted to make everyone 
> aware of the ONAP project lifecycle and encourage projects to consider 
> their status and any changes.
> The current lifecycle is depicted in this diagram:
> 
> The suggestion is that we use this lifecycle to place the ONAP project 
> portfolio into three buckets:
> 
> -*Mature projects:*for projects with active release participation & 
> solid artifacts; they should submit for a "maturity review"
> 
> - *Inactive (Archived) projects*: for projects where there is no longer 
> any contributions, they should follow the termination review
> 
> -*Other (Incubation) projects*: for those projects that are still active 
> but not ready for move to "mature" phase
> 
> For *mature projects*, the TSC encourages qualifying projects to submit 
> for a maturity review.  They do this by filling out the template in the 
> wiki (https://wiki.onap.org/display/DW/Project+Maturity+Review+Template 
> )
>  
> and send an email to the TSC list.  In order to accelerate reviews (and 
> free up time on the TSC calls), we may want to form a working group to 
> do a preliminary maturity review for the projects.  The group 
> would submit their recommendations to the TSC who would then vote 
> +1/0/-1 for promotion to the mature phase.

Shouldn't we have any security review before we move project to the 
mature state? There is no single question regarding security in this 
template...

> 
> For the*inactive projects*, there is no guidance on who should initiate 
> a termination review.  Because there may not be a PTL, perhaps the TSC 
> could initiate a termination review for a project.  Again, we may want a 
> working group to conduct the steps of the termination review.  This 
> group should consist of people who are familiar with the project or at 
> least interface with/depend upon the project.  This working group will 
> need to walk through the steps of the termination review as outlined 
> here: (scroll down)
> 
> https://wiki.onap.org/display/DW/ONAP+Project+and+Component+Lifecycle 
> 
> 
> All other projects need no action.
> 
> Background slide deck on project lifecycle reviews: 
> https://wiki.lfnetworking.org/pages/viewpage.action?pageId=25364127=/25364127/28738708/ONAP%20Proj%20Lifecycle%20and%20Review%2015Jan2020%20v1.pdf
>  
> 
> 
> Please reply with any questions on the process.
> 
> Regards,
> Jason Hunt
> Distinguished Engineer, IBM
> 
> Phone: +1-314-749-7422
> Email: djh...@us.ibm.com
> Twitter: @DJHunt
> 
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6486): https://lists.onap.org/g/onap-tsc/message/6486
Mute This Topic: https://lists.onap.org/mt/74681700/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] [Onap-usecasesub] REMINDER - Guilin Release - CALL FOR ACTION - Ends May 27th, 5 PM Pacific

[Krzysztof Opasiak via lists.onap.org]

On 27.05.2020 22:45, David McBride wrote:
> Sylvain,
> 
> I'm not sure what you mean by "useless".  The requirements documented on 
> that page must be turned into JIRA tickets in the REQ project.  However, 
> I don't think that makes the wiki page useless.  Please clarify.

So by saying useless Sylvain was trying to ask "Why we need to put track 
this in two different places instead of one?".

> 
> David
> 
> On Wed, May 27, 2020 at 9:21 AM Sylvain Desbureaux via lists.onap.org 
> 
>  
>  > wrote:
> 
> Hi david,
> so
> 
> https://wiki.onap.org/display/DW/Guilin+release+-+non-functional+requirements+proposed+list
> 
> 
> is useless?
> 
> *De :* onap-tsc@lists.onap.org 
> [onap-tsc@lists.onap.org ] de la
> part de David McBride [dmcbr...@linuxfoundation.org
> ]
> *Envoyé :* mercredi 27 mai 2020 14:25
> *À :* Catherine LEFEVRE
> *Cc :* onap-tsc@lists.onap.org ;
> onap-usecase...@lists.onap.org 
> *Objet :* Re: [onap-tsc] [Onap-usecasesub] REMINDER - Guilin Release
> - CALL FOR ACTION - Ends May 27th, 5 PM Pacific
> 
> Team,
> 
> Please remember to follow the new process
> 
> 
> for documenting requirements.
> 
> David
> 
> On Tue, May 26, 2020 at 2:50 PM Catherine LEFEVRE
>  > wrote:
> 
> 
> 
> __ __
> 
> Dear ONAP Community,
> 
> __ __
> 
> On behalf of the ONAP TSC, I want to remind you that tomorrow –
> Wednesday May 27^th , 5pm PST is the last day to submit your
> requirements (use cases, functional or non functional
> requirements) for the Guilin Release.
> 
> So far, 14 requirements have been submitted -
> https://wiki.onap.org/display/DW/Guilin+Release+Requirements
> 
> 
> 
> __ __
> 
> Best regards
> 
> Catherine
> 
> __ __
> 
> __ __
> 
> __ __
> 
> __ __
> 
> 
> 
> -- 
> *David McBride*
> Release Manager
> Linux Foundation Networking (LFN)
> Mobile: +1.805.276.8018 
> Email/Google Talk: dmcbr...@linuxfoundation.org
> 
> IRC: dmcbride
> 
> 
> _
> 
> 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 not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
> 
> 
> 
> -- 
> *David McBride*
> Release Manager
> Linux Foundation Networking (LFN)
> Mobile: +1.805.276.8018 
> Email/Google Talk: dmcbr...@linuxfoundation.org 
> 
> IRC: dmcbride
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6442): https://lists.onap.org/g/onap-tsc/message/6442
Mute This Topic: https://lists.onap.org/mt/74498435/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] ESR root containers fix

[Krzysztof Opasiak via lists.onap.org]

On 15.05.2020 10:14, andreas-geiss...@telekom.de wrote:
> Hi,
> 
> I updated the deployment.yaml files in my Daily Master environment.
> ESR Server version: 1.5.2
> 
> ESR GUI version: 1.4.0 (=ElAlto Version)
> 
> This is the console output in the ESR server container:
> 
> ubuntu@control01-onap-master:/opt/oom/kubernetes$ kubectl exec -ti 
> onap-esr-server-6d78678fd7-7tcb5 -n onap bash
> 
> Defaulting container name to esr-server.
> 
> Use 'kubectl describe pod/onap-esr-server-6d78678fd7-7tcb5 -n onap' to 
> see all of the containers in this pod.
> 
> groups: cannot find name for group ID 1001
> 
> I have no name!@onap-esr-server-6d78678fd7-7tcb5:/home/esr$ who am i
> 
> I have no name!@onap-esr-server-6d78678fd7-7tcb5:/home/esr$

Yup this is expected as in container there is no user with such UID but 
we may still run with it;)

> 
> And ESR gui container:
> 
> ubuntu@control01-onap-master:/opt/oom/kubernetes$ kubectl exec -ti 
> onap-esr-gui-744486d94d-mhskg -n onap bash
> 
> groups: cannot find name for group ID 1001
> 
> I have no name!@onap-esr-gui-744486d94d-mhskg:/home/esr$
> 
> And the UI is working:
> 
> So I consider this as successful, right ?

If the UI part works for you then rest is fine;)

> 
> Best regards
> 
> Andreas
> 
> -Ursprüngliche Nachricht-
> Von: Krzysztof Opasiak 
> Gesendet: Donnerstag, 14. Mai 2020 21:37
> An: dmcbr...@linuxfoundation.org; Lefevre, Catherine 
> ; Geissler, Andreas 
> 
> Cc: Seshu m ; FORSYTH, JAMES ; 
> DESBUREAUX Sylvain TGI/OLN ; onap-tsc 
> ; onap-release ; 
> RICHOMME Morgan TGI/OLN 
> Betreff: ESR root containers fix
> 
> Hi,
> 
> I've just pushed patches which makes ESR pods to run as non-root:
> 
> https://gerrit.onap.org/r/c/oom/+/107707 
> 
> 
> https://gerrit.onap.org/r/c/oom/+/107699 
> 
> 
> I've a very limited knowledge of esr thus I tested this with just couple 
> of wgets.
> 
> @Andreas
> 
> It would be great if you could check if those patches work for you.
> 
> Best regards,
> 
> --
> 
> Krzysztof Opasiak
> 
> Samsung R Institute Poland
> 
> Samsung Electronics
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6380): https://lists.onap.org/g/onap-tsc/message/6380
Mute This Topic: https://lists.onap.org/mt/74213003/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-tsc] ESR root containers fix

[Krzysztof Opasiak via lists.onap.org]

Hi,

I've just pushed patches which makes ESR pods to run as non-root:

https://gerrit.onap.org/r/c/oom/+/107707
https://gerrit.onap.org/r/c/oom/+/107699

I've a very limited knowledge of esr thus I tested this with just couple 
of wgets.

@Andreas
It would be great if you could check if those patches work for you.

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6372): https://lists.onap.org/g/onap-tsc/message/6372
Mute This Topic: https://lists.onap.org/mt/74213003/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] [onap-ptl] [OOM] Guilin Release Plan

[Krzysztof Opasiak via lists.onap.org]

I knew that if I say anything in this thread it will mean I'll have to 
do some extra work xD


but OK, I may start putting sth together but after a while I think that 
actually a page in read the docs like documentation team has (doc 
developer guide) would be more suitable. Any thoughts?


On 29.04.2020 15:45, sylvain.desbure...@orange.com wrote:

Well, yes it's a good idea!
As part of it comes from SECCOM, I propose someone who has the two hats to 
initiate the writing, a.k.a you :-P

De : Krzysztof Opasiak [k.opas...@samsung.com]
Envoyé : mercredi 29 avril 2020 15:37
À : DESBUREAUX Sylvain TGI/OLN; TIMONEY, DAN; onap-...@lists.onap.org; 
onap-tsc@lists.onap.org
Cc : RICHOMME Morgan TGI/OLN; Mike Elliott; CLOSSET, CHRISTOPHE; 
dmcbr...@linuxfoundation.org; Kenny Paul
Objet : Re: [onap-ptl] [OOM] Guilin Release Plan

Hi,

On 29.04.2020 15:11, sylvain.desbure...@orange.com wrote:

Hey Dan,

Nope I didn't create any stories.

What I can do (if possible) is to create one story per requirement (I
count roughly 15) and create a sub task per project (if possible in
project board).
That would add 15 tasks per project (knowing that some will be
irrelevant for the project, like "check postgresql 12.2 is ok for your
project" for you)

Or, we don't do that and create Jira tickets when we find that one
requirement is not met (like "all logs to STDOUT" for you).


I think Sylvain that sth else what we could do is to create a wiki page
with the list of requirements that has to be fulfilled in order to get
your patch accepted in OOM



it's up to you PTLS, as you prefer

*De :* TIMONEY, DAN [dt5...@att.com]
*Envoyé :* lundi 27 avril 2020 20:33
*À :* onap-...@lists.onap.org; DESBUREAUX Sylvain TGI/OLN;
onap-tsc@lists.onap.org
*Cc :* RICHOMME Morgan TGI/OLN; Krzysztof Opasiak; Mike Elliott;
CLOSSET, CHRISTOPHE; dmcbr...@linuxfoundation.org; Kenny Paul
*Objet :* Re: [onap-ptl] [OOM] Guilin Release Plan

Sylvain,

Thank you for the excellent summary, which was also explained quite well
at last week’s virtual face to face event.

One process question, though: are there already user stories created for
these items (perhaps SECCOM user stories)?  I want to make sure we’re
tracking these requirements when we do our release planning for Guilin.

Thanks!

Dan

*From: * on behalf of "Sylvain Desbureaux via
lists.onap.org" 
*Reply-To: *"onap-...@lists.onap.org" ,
"sylvain.desbure...@orange.com" 
*Date: *Monday, April 27, 2020 at 12:22 PM
*To: *"onap-...@lists.onap.org" ,
"onap-tsc@lists.onap.org" 
*Cc: *RICHOMME Morgan TGI/OLN , Krzysztof
Opasiak , Mike Elliott ,
"CLOSSET, CHRISTOPHE" ,
"dmcbr...@linuxfoundation.org" , Kenny
Paul 
*Subject: *[onap-ptl] [OOM] Guilin Release Plan

Dear PTLs, dear TSC members,

as RC0 is (almost) passed and Frankfurt branch will be soon created, I
think it's important to share with you all the OOM release plan for Guilin.

As you'll eventually push your changes in OOM, I think it's important
that you know our plans.

# TL;DR;

* If you don't retrieve your certificates automatically, this is the
__first__ thing you must do. See
https://protect2.fireeye.com/url?k=c7d639cc-9a056543-c7d7b283-0cc47a31ce52-21da0bbc9685518d=1=https%3A%2F%2Fgithub.com%2Fonap%2Foom%2Ftree%2Fmaster%2Fkubernetes%2Fnbi

as an example. `certInit` template (a.k.a `aafInit`) is the **strongly**
preffered way to do that.
* No more than 1 main process per container. If you have more, it'll be
a blocker for updates
* All logs to STDOUT
* No direct commit to Frankfurt but master then cherry-pick
* All upstream components should use an upstream (dockerhub, googlehub)
version
* Common chart version bump
  * Mariadb common chart will be upgraded to 10.4.12
  * PostgreSQL common chart will be upgraded to 12.2
  * Cassandra common chart will be upgraded to 3.11.6
  * MongoDB common chart will be upgraded to 4.2.2
  * ElasticSearch common chart may be upgraded, waiting for SECCOM
proposed version
* AAF is an optional requirement, meaning your component must work
without AAF (certificates and RBAC), even on degraded mode
* MSB is an optional requirement, meaning your component must work
without MSB
* Your component can use http as **server** and **client**
* Password removal will continue on common charts (postgreSQL at least)
and start on your component, be prepared to receive so call for help
* Commit messages must be meaningful and follow the format shown below.
* Proper crash (if your component fails, it must exit with code > 0, 

Re: [onap-tsc] [onap-ptl] [OOM] Guilin Release Plan

[Krzysztof Opasiak via lists.onap.org]

Hi,

On 29.04.2020 15:11, sylvain.desbure...@orange.com wrote:

Hey Dan,

Nope I didn't create any stories.

What I can do (if possible) is to create one story per requirement (I 
count roughly 15) and create a sub task per project (if possible in 
project board).
That would add 15 tasks per project (knowing that some will be 
irrelevant for the project, like "check postgresql 12.2 is ok for your 
project" for you)


Or, we don't do that and create Jira tickets when we find that one 
requirement is not met (like "all logs to STDOUT" for you).


I think Sylvain that sth else what we could do is to create a wiki page 
with the list of requirements that has to be fulfilled in order to get 
your patch accepted in OOM




it's up to you PTLS, as you prefer

*De :* TIMONEY, DAN [dt5...@att.com]
*Envoyé :* lundi 27 avril 2020 20:33
*À :* onap-...@lists.onap.org; DESBUREAUX Sylvain TGI/OLN; 
onap-tsc@lists.onap.org
*Cc :* RICHOMME Morgan TGI/OLN; Krzysztof Opasiak; Mike Elliott; 
CLOSSET, CHRISTOPHE; dmcbr...@linuxfoundation.org; Kenny Paul

*Objet :* Re: [onap-ptl] [OOM] Guilin Release Plan

Sylvain,

Thank you for the excellent summary, which was also explained quite well 
at last week’s virtual face to face event.


One process question, though: are there already user stories created for 
these items (perhaps SECCOM user stories)?  I want to make sure we’re 
tracking these requirements when we do our release planning for Guilin.


Thanks!

Dan

*From: * on behalf of "Sylvain Desbureaux via 
lists.onap.org" 
*Reply-To: *"onap-...@lists.onap.org" , 
"sylvain.desbure...@orange.com" 

*Date: *Monday, April 27, 2020 at 12:22 PM
*To: *"onap-...@lists.onap.org" , 
"onap-tsc@lists.onap.org" 
*Cc: *RICHOMME Morgan TGI/OLN , Krzysztof 
Opasiak , Mike Elliott , 
"CLOSSET, CHRISTOPHE" , 
"dmcbr...@linuxfoundation.org" , Kenny 
Paul 

*Subject: *[onap-ptl] [OOM] Guilin Release Plan

Dear PTLs, dear TSC members,

as RC0 is (almost) passed and Frankfurt branch will be soon created, I 
think it's important to share with you all the OOM release plan for Guilin.


As you'll eventually push your changes in OOM, I think it's important 
that you know our plans.


# TL;DR;

* If you don't retrieve your certificates automatically, this is the 
__first__ thing you must do. See 
https://github.com/onap/oom/tree/master/kubernetes/nbi 
 
as an example. `certInit` template (a.k.a `aafInit`) is the **strongly** 
preffered way to do that.
* No more than 1 main process per container. If you have more, it'll be 
a blocker for updates

* All logs to STDOUT
* No direct commit to Frankfurt but master then cherry-pick
* All upstream components should use an upstream (dockerhub, googlehub) 
version

* Common chart version bump
     * Mariadb common chart will be upgraded to 10.4.12
     * PostgreSQL common chart will be upgraded to 12.2
     * Cassandra common chart will be upgraded to 3.11.6
     * MongoDB common chart will be upgraded to 4.2.2
     * ElasticSearch common chart may be upgraded, waiting for SECCOM 
proposed version
* AAF is an optional requirement, meaning your component must work 
without AAF (certificates and RBAC), even on degraded mode
* MSB is an optional requirement, meaning your component must work 
without MSB

* Your component can use http as **server** and **client**
* Password removal will continue on common charts (postgreSQL at least) 
and start on your component, be prepared to receive so call for help

* Commit messages must be meaningful and follow the format shown below.
* Proper crash (if your component fails, it must exit with code > 0, and 
not wait or exit with code 0)
* Ingress will be the default deployment option (via Nginx Ingress). No 
more access via NodePort per default
* New code will be submitted only if pods + healthchecks + basic tests 
are OK

* No root access to any Database from application container
* No configuration generation using sed in the application container

# Certificates

Certificates in Docker are not allowed in Francfurt release per SECCOM 
recommendation.
They won't be allowed either in helm chart starting branching of 
Frankfurt. This means you must move to automatic retrieval at boot.

You'll either have to:

* use `certInit` template (formerly known as `aafInit` template) (see 
[NBI](https://github.com/onap/oom/tree/master/kubernetes/nbi 

Re: [onap-tsc] Gerrit usage too heavy with local HTTP calls

[Krzysztof Opasiak via lists.onap.org]

Hi Jess,

is there any chance to provide us list of IP addresses and some traffic 
stats so that we can check internally if it's not our fault?

On 23.04.2020 19:16, Jessica Wagantall wrote:
> Dear team,
> 
> We have noticed several times that ONAP Gerrit is being flooded with 
> HTTP requests
> which causes the server to be overloaded and drop causing backlogs in 
> Jenkins too and
> requiring a lot of work to restore these services.
> 
> I would like to remind you to please use Github for cloning the repos 
> you need instead.
> 
> Also, please remember we have the APAC mirror too:
>      git://gerrit-mirror-ap.onap.org/mirror/${PROJECT} 
> 
> Example clone:
>      git clone git://gerrit-mirror-ap.onap.org/mirror/ci-management.git 
> 
>  
> 
> 
> Thanks so much!
> Jess
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6185): https://lists.onap.org/g/onap-tsc/message/6185
Mute This Topic: https://lists.onap.org/mt/73222930/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] [onap-cnf-taskforce] OVP 2.0 - Workstream 7 - ONAP POC and existing development work

[Krzysztof Opasiak via lists.onap.org]

On 22.04.2020 23:14, Srini wrote:

Hi Eric,

Just to be on the same page:

 1. Application life cycle management on K8s Clusters is taken care by
following micro-services
 1. K8s Plugin Service in Multi Cloud project (new development)
 2. Mongo DB & etcd (Non-ONAP open source)
 3. SDC Client in Multi-Cloud (New development)
 4. SDC modifications
 5. SO modification
 6. Multi-Cloud broker modifications.
 2. ONAP4K8s is one recipe and useful for greenfield (e.g Enterprises
and Industry 4.0) deployments. It has following
 1. K8s Plugin Service in Multi Cloud project
 2. Security Micro-services (SMS, Vault, TPM related)
 3. Mongo DB & etcd (Non-ONAP open source)

 From the beginning, we wanted to make sure that everything we do is 
modular and can be deployed standalone fashion,  keeping micro-service 
architecture principles in mind.


ONAP4K8s recipe need not be used if the intention is to use along with 
rest of ONAP (SDC, SO, AAF, OOF etc…). We have both models supported 
(standalone or integrated).


ONAP4K8s is mainly for greenfield scenarios.

If the term ‘ONAP’ in ONAP4K8s is confusing, we can rename this recipe 
as something else.  I think based on another email on similar subject, 
you seem to be implying that if people are not using some components 
such as SDC, SO, AAF are not used, then it should not be called as ONAP. 
If this is the concern,  we don’t mind removing ONAP4K8s page altogether 
and put it in places (such as Akraino/ICN) where it is being used.  Let 
us know.


Is the concern/confusion that we are not using OOM for this profile? If 
this is the concern, we do have plans to ensure that OOM is leveraged 
for creating the profile with above services as in (2).  But at this 
time, OOM granularity is selection of projects, but not micro-services 
in each project. Hence, we created something to move forward.


Such a feature is more than welcome in OOM so instead of creating this 
from scratch you can just submit a patch to OOM:)


Patches are always welcomed



Thanks

Srini

*From:* onap-cnf-taskfo...@lists.onap.org 
 *On Behalf Of *Eric Debeau via 
lists.onap.org

*Sent:* Wednesday, April 22, 2020 11:51 AM
*To:* onap-cnf-taskfo...@lists.onap.org; ranny.ha...@samsung.com; 
catherine.lefe...@intl.att.com; onap-tsc@lists.onap.org
*Subject:* Re: [onap-cnf-taskforce] OVP 2.0 - Workstream 7 - ONAP POC 
and existing development work


Hi

I participated this afternoon to the various sessions around CNF where 
there is a lot of activities for this long journey towards managing CNF.


However, I am still confused about the communication about ONAP4K8S and 
the statement that we should rely on ONAP4K8S to manage CNF in ONAP.


We can not state that ONAP4K8 is an ONAP profile. Based on the code 
available on the ONAP repo 
https://git.onap.org/multicloud/k8s/tree/deployments/helm/onap4k8s, 
 
we can see that ONAP4K8S is not using existing ONAP project. There is a 
dedicated chart for the deployment not reusing existing ONAP ones 
(managed by OOM project):


https://git.onap.org/multicloud/k8s/tree/deployments/helm/onap4k8s. 
 
It is only based on one Docker from multicoud project (multicloud-ks), 
mongodb, etcd and other common components with no reference to existing 
official ONAP charts defined in OOM repo.


I have no problem if we consider it clearly as a PoC, but we can not 
claim that is an ONAP profile and the way we communicate on ONAP4K8S is 
not clear an is very confusing.


As an example of "ONAP profile", we can find one for 5G slicing use-case 
where the use-case team has defined an optimized subset of ONAP 
components for their slicing 
use-case:https://git.onap.org/oom/tree/kubernetes/onap/resources/overrides/onap-5g-network-slicing.yaml 



We really need to clarify this topic.

Best Regards

Eric



*De :*onap-cnf-taskfo...@lists.onap.org 
 
[onap-cnf-taskfo...@lists.onap.org] de la part de Ranny Haiby (Samsung) 
via lists.onap.org [ranny.haiby=samsung@lists.onap.org]

*Envoyé :* mardi 21 avril 2020 01:56
*À :* onap-cnf-taskfo...@lists.onap.org 
; 
catherine.lefe...@intl.att.com 
*Objet :* Re: [onap-cnf-taskforce] OVP 2.0 - Workstream 7 - ONAP POC and 
existing development 

Re: [onap-tsc] List of OJSI tickets left for Frankfurt

[Krzysztof Opasiak via Lists.Onap.Org]

Hi Taka,

On 26.03.2020 19:18, Taka Cho wrote:
> I think you need to refine your query
> 
> OJSI 63 and 32 are AAF related issues. Should be waived for Frankfurt.

You are right! THank you for reminding me about this. I've fixed that in 
the wiki

> 
> Taka
> 
> -Original Message-
> From: onap-tsc@lists.onap.org  On Behalf Of 
> Krzysztof Opasiak via Lists.Onap.Org
> Sent: Thursday, March 26, 2020 12:45 PM
> To: onap-tsc 
> Cc: LEFEVRE, CATHERINE ; Seshu m 
> ; p.paw...@f5.com; ZWARICO, AMY 
> Subject: [onap-tsc] List of OJSI tickets left for Frankfurt
> 
> Dear TSC,
> 
> as requested today I've filtered the OJSI tickets and provided the list of 
> tickets that should be closed in Frankfurt:
> 
> https://protect2.fireeye.com/url?k=a51d7a0c-f8c9c664-a51cf143-0cc47a3356b2-d38cba2493226233=https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_OJSI-2BTickets-2BStatus=DwICaQ=LFYZ-o9_HUMeMTSQicvjIg=i5VHNTZ3SDPgIii87sudZA=Vdi1zm6jbaMULEW7qVgubpJFxa6RQaxalM3FmCEb5So=1jiACsg_UvImXM7UhCBEQAYajXglisio3OHE854xHFQ=
> 
> --
> Krzysztof Opasiak
> Samsung R Institute Poland
> Samsung Electronics
> 
> 
> 
> 
> 
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6081): https://lists.onap.org/g/onap-tsc/message/6081
Mute This Topic: https://lists.onap.org/mt/72568090/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-tsc] List of OJSI tickets left for Frankfurt

[Krzysztof Opasiak via Lists.Onap.Org]

Dear TSC,

as requested today I've filtered the OJSI tickets and provided the list 
of tickets that should be closed in Frankfurt:

https://wiki.onap.org/display/DW/OJSI+Tickets+Status

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6079): https://lists.onap.org/g/onap-tsc/message/6079
Mute This Topic: https://lists.onap.org/mt/72568090/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] [OOM][Coronavirus] Containment in France and consequences

[Krzysztof Opasiak via Lists.Onap.Org]

Hi,

On 16.03.2020 09:00, sylvain.desbure...@orange.com wrote:
> Hello all,
> 
> Due to Coronavirus, most of us inside Orange are working remotely.

The same in Samsung Poland.

> 
> It shouldn’t change a lot of thing, except some delays in our mails (VPN 
> access will be a scarce resource…) and child care from time to time.

In my case nothing should change as I've been already working remotely;)

> 
> Our apologies if the time to answer will be a bit longer than usual, 
> we’ll do our best!

Stay healthy that's the most important now, OOM patches can wait 5 
minutes more;)

> 
> Regards,
> 
> -- 
> 
> cid:image001.png@01D33D23.D1353070 
> 
> *Sylvain Desbureaux *
> 
> Senior Automation Architect
> 
> ORANGE/IMT/OLN/CNC/NCA/SINA
> 
> Fixe : +33 2 96 07 13 80 
> 
> 
> Mobile : +33 6 71 17 25 57 
> 
> 
> sylvain.desbure...@orange.com 
> 
> _
> 
> 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 not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6035): https://lists.onap.org/g/onap-tsc/message/6035
Mute This Topic: https://lists.onap.org/mt/71992944/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] Please join the ONAP PTL meeting NOW!

[Krzysztof Opasiak via Lists.Onap.Org]

+ 1

There is a reason why it's clearly marked as 14:00 UTC in the wiki

On 09.03.2020 14:33, Sylvain Desbureaux via Lists.Onap.Org wrote:
> I agree with Morgan, the meeting is in 27min as it’s UTC
> 
> ---
> 
> Sylvain Desbureaux
> 
> *De : *RICHOMME Morgan TGI/OLN 
> *Date : *lundi 9 mars 2020 à 14:32
> *À : *"onap-tsc@lists.onap.org" 
> *Cc : *DESBUREAUX Sylvain TGI/OLN 
> *Objet : *Re: [onap-tsc] Please join the ONAP PTL meeting NOW!
> 
> Hi,
> 
> I already mentioned it in ONAP and OPNFV, the time MUST be in UTC - U 
> means Universal, it is a reference to avoid confusion, it does not 
> change whatever the timezone -
> 
> in the agenda the meeting is at 2PM UTC, so it starts in 30 minutes...
> 
> everybody usually knows the time change of his/her timezone but cannot 
> know all the time changes of every time zones.
> 
> /Morgan
> 
> Le lundi 09 mars 2020 à 06:11 -0700, David McBride a écrit :
> 
> Team,
> 
> Sorry for the confusion.  The calendar currently lists the PTL
> meeting starting at 7 a.m. Pacific, in approximately 55 minutes. 
> That is NOT correct.  The meeting has started now.  If you are
> available, please join the call.  We will try to get the calendar
> fixed this week.
> 
> David
> 
> _
> 
> 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 not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#5999): https://lists.onap.org/g/onap-tsc/message/5999
Mute This Topic: https://lists.onap.org/mt/71834092/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-tsc] SSRF Vulnerability in ONAP jira

[Krzysztof Opasiak via Lists.Onap.Org]

Dear TSC,

This is a notification email to ensure a full transparency of ONAP 
vulnerability management subcommittee.

On 28th of November 2019 we (secur...@lists.onap.org) received a report 
from user identifying himself as "p0desta" on Server Side Request 
Forgery in ONAP jira instance (jira.onap.org). The vulnerability was 
previously known and identified as CVE-2019-8451. Official Atlassian 
ticket related to this vulnerability is:

https://jira.atlassian.com/browse/JRASERVER-69793

As the vulnerability is not related to the ONAP itself, but only to the 
supporting infrastructure we decided to not create a new OJSI ticket nor 
issue ONAP Security Advisory (OSA) but rather report it directly to the 
Linux Foundation using a limited visibility service desk ticket:

https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-18372

The vulnerability has been fixed today by the Linux Foundation IT 
support team by performing an upgrade of ONAP jira instance to the 
version that includes a fix for this security vulnerability.

Best regards,
-- 
Krzysztof Opasiak
on behalf of the ONAP vulnerability sub-committee

Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#5728): https://lists.onap.org/g/onap-tsc/message/5728
Mute This Topic: https://lists.onap.org/mt/65207300/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] Reorg of subcommittee pages on ONAP Wiki?

[Krzysztof Opasiak via Lists.Onap.Org]

Hi Kenny,

On 21.11.2019 20:40, Kenny Paul wrote:

Hello everyone,

Currently all the subcommittee pages are direct children of the TSC 
page. To clean things up a bit I would like to realign the subcommittee 
landing pages under a parent subcommittee page.


Proposed structure:  TSC Home -> Subcommittee Home -> Subc-A, Subc-B, 
Subc-C, …


Thoughts?


Sounds like a good idea as long as we don't break any links;)

--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#5693): https://lists.onap.org/g/onap-tsc/message/5693
Mute This Topic: https://lists.onap.org/mt/61117266/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] Zoom Recording Retention Policy

[Krzysztof Opasiak via Lists.Onap.Org]

Hi,

even through I'm not a TSC I'd like to let you know my feedback.

On 12.11.2019 17:06, Perala, Timo (Nokia - FI/Espoo) wrote:

Hello,

I would like to understand first

1) What’s the current cost and what is the savings potential e.g. if we 
implement policy along the lines outlined below.


2) What’s the volume split between projects/TSC & SubCs/DDFs.

3) Assuming the TSC & SubC meeting recordings and DDF recordings 
constitute minority, I have inclination to keep them longer (e.g. 
indefinitely to start with).


4) Project recordings to stay there for the full release. I guess that 
would in practice mean 6 moths + small delta.


I support Timo's point of view. In general I believe that we should bind 
the recording lifecycle to ONAP release cadence not the absolute time.


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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#5614): https://lists.onap.org/g/onap-tsc/message/5614
Mute This Topic: https://lists.onap.org/mt/54381323/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-tsc] [Action Required] Security Release Notes

[Krzysztof Opasiak via Lists.Onap.Org]

Dear PTLs,

First of all, I'd like to thank you for updating security section of the 
release notes!

Unfortunately not all PTLs updated this section according to the current 
state of their project. Some people tend to put into "Fixed Security 
Issues" section all OJSI tickets even if they are not resolved yet and 
postponed till Frankfurt (for example due to resource constraint).

That's why I'd like to kindly although firmly request all PTLs to 
reevaluate this section of the release notes and remove from it all OJSI 
tickets that are not marked as "Done" in the ONAP jira.

Please remember that release notes are a communication channel between 
you and your users. Please don't make them believe that the 
vulnerability is fixed if it's not.

Thank you,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#5464): https://lists.onap.org/g/onap-tsc/message/5464
Mute This Topic: https://lists.onap.org/mt/34447508/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] WIKI access

[Krzysztof Opasiak via Lists.Onap.Org]

On 16.09.2019 16:00, Stephen Terrill via Lists.Onap.Org wrote:

Hi,

It seems like the ability to log into the ONAP wiki is down for the moment.


I confirm this. I've created a helpdesk ticket for this some time ago:

IT-17596



BR,

Steve

http://www.ericsson.com 

*Stephen Terrill*

Senior Expert, Automation and Management

TECHNOLOGY SPECIALIST

BDGS RDP Architecture & Technology

Phone: +34913393005

Mobile: +34609168515

stephen.terr...@ericsson.com

Ericsson

C/ Via de los Poblados 13. B

28033,Madrid, Madrid

Spain

ericsson.com 

http://www.ericsson.com/current_campaign 



Our commitment to Technology for Good 
 
and Diversity and Inclusion 
 contributes to 
positive change.
Follow us on: Facebook  LinkedIn 
 Twitter 



Legal entity:ERICSSON ABregistration number 556056-6258, registered 
office in Stockholm.
This communication is confidential. Our email terms: 
www.ericsson.com/en/legal/privacy/email-disclaimer 






--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#5427): https://lists.onap.org/g/onap-tsc/message/5427
Mute This Topic: https://lists.onap.org/mt/34164690/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Onap-arc] [onap-tsc] New SDC repositories request

[Krzysztof Opasiak via Lists.Onap.Org]

On 08.07.2019 10:20, Sylvain Desbureaux via Lists.Onap.Org wrote:
> Hello Kenny,
> 
> If I may I think that “micro” repos are a better way to handle code in a 
> CI/CD world. Let’s take two examples:
> 
>   * SO: SO has (roughly) one project into ONAP git but delivers 13
> containers. That means that 1 code change that should affect only
> one of the containers will rebuild the 13 containers so it’s
> __hard__ to debug at the end.
>   * SDC: SDC has 21 repos (if I’m not mistaken) and delivers 13
> containers also. That mean that 1 code change that should affect
> only one of the containers __should__ rebuild 1 containers. I assume
> that some repos could be merged together but not that much IMHO.
> 
> So for me a good practice is:
> 
>   * This “folder” / code produce 1 container àit should be a project
> into gerrit
>   * This “folder” / code is a common foundation for several containers
> àit should be a project into gerrit and we should have a __clear__
> (automated) policy on how to upgrade the upstream components.

I strongly agree with your point but I'd like to also add that in order 
to fully benefit from multiple repo workflow we should start using 
proper tags in gerrit (Depends-On:) if we are doing changes that affect 
other repos and learn our CI/CD system to properly interpret that to 
avoid fake failures in number of reviews...

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#5191): https://lists.onap.org/g/onap-tsc/message/5191
Mute This Topic: https://lists.onap.org/mt/32389899/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-