...
| Ref | Blocking? | Status | Component | Description/Notes | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 8 | Open | DR | 11/21: How to handle registration / provisioning of a new dr-node instance to an existing and/or "edge" DR deployment. Dominic Lunanuova recommended to use bus-controller api. Existing script in OOM BusController deploy. Is there a k8s way to do this "registration / unregistration"? 12/5: Deploy DR node, thinking on how you register to the API of BusController - 12/12: Similar issues across ONAP teams - continue to discuss with OOM team DMAAP-534 01/28: Mail thread in relation to this - should DR move to CADI to incorporate AAF roles (good idea!) Sunil might run through on Fri 02/01: CADI - Steps sent onto Mariusz Role based access will remain under AAF 02/04: DR looking into integrating AAF for provisioning via BC 02/06: Fiachra in discussions with Sunil to resolve and need to contact AAF but we already have certificates 02/11: Dom to ask Roman to attend to explain ECOMP strategy for Publisher api access. These changes could be ported back to DR code base. 02/13: Internally Romans team have done it for both prov and publish API - Roman willing to forward on the solution it back to ONAP DR Team will implement it 02/15: Prashant - need to structure -walkthrough from very high level 02/20: Dom to track down files as per requested 02/22: All files sent - team to continue implementation Dom to see if he can get Prashant to have chat with Fiachra 02/27: Meetings proceeded - keeping open until implementation complete 03/01: Work ongoing - 03/08: testing on windriver environment - take a call offline 03/13: Mail chain - Still blocked (Sunil to assist after call) 03/15: Issue resolved, so progress being made - mail chain 03/15 Fiachra to request port for dr-node and Sunil to request AAF team to take snapshot of permissions/roles 03/20: blocked - cannot add prov id to dr-admin role- similar issues to meeting call last week (identity itself is missing) (use aaf deployed within helm charts - ) What do we need to do now??? Sunil to send mail need AAF team to reset up test environment 03/22: Plan is to have this disabled by default Can be enabled for integration testing - then whenever we satisfied we can set it to enabled by default windriver image to be taken next week sometime!! Impact on BC to be conveyed early next week How to document this - DR API and equivalent in BC API 03/25: Cadi enabled for MR by default, use same variable name across all DMaaP. 03/29: Code in for review - Plan is to have it disabled by default for this release (Ability to turn on if desired -aafID passed will dictate its on) - Impacts on Bus controller Danger: Provisoner tries to use AAF, DR off, BC on - ? Risk: AAF environment req'd (More stable now with ability to deploy aaf locally) 04/01: Code review in process and docs in progress ( Bc updates also reqd) 04/03: Code merged/doc up for review/OOM code not merged 4/5: Remaining work items in Jira:
| |||||||||||||||||||||||||
| 26 | Open | DMaaP | 01/22: Component creation in Jira for DMaaP project: I do not posses "Project" admin rights in JIRA, I only posses DMaaP board rights | |||||||||||||||||||||||||
| 27 | Open | All | Swagger implementation? 01/28: Swagger is a requirement for Dublin Release (S3P requirements) ? What are the expectations here? Whom can we discuss with? - Sofia Wallin, 01/30: Rich Bennett Mail on this - still cryptic - is it Mandatory - requirement in Platform Maturity 02/06: Dom sent mail looking for clarification - Erik has yet to respond? 02/20: Still no word 02/22: Erik to document what is required 02/27: Still nothing from Erik documented 03/01: Tom to chase Erik up 03/08: Erik to documented beginning of next (hopefully) 03/13: Attend documentation this week 03/15: read the docs vs swagger files and what are they exactly looking for 03/29: Erik has code, just needs to merge (tom to chase up) | |||||||||||||||||||||||||
| 30 | Open | All | 02/01: Adolfo Perez-Duran The CIA team is preparing to submit contributions to DMAAP to migrate the base images to ONAP Normative Container Base Images. This migration is expected to reduce the image footprint and to enable multi-cpu architecture support for Dublin We expect the work to be minimally disruptive and to coordinate changes with tour team. ubuntu v alpine the talk continues 02/13: Lots of chat on discuss chat - need it to settle down before we implement 02/20: Frank Sandoval [mailto:frank.sandoval@oamtechnologies.com] to provide an update ! 02/20: Dom, Conor & Sunil to assist here Mandar to raise at TSC to see if the right course of action 02/22: Change image & Impacts: Hold off - will these reduce the container footprint? -Dosen't look likely, it is more to be uniform across ONAP 1) suggested we change our Maven approach to use "fabric" plugin instead of spotify (support for this has discontinued) plugin 2) use docker file instead of POM is recommended from spotify (currently we don't use except CSIT environment) 02/27: lets pose question to frank 02/27: Alpine is the decision for Dublin 03/01: Questions mailed to Frank - awaiting response testing changes - and need to send gerrit review to Dom 03/08: Frank made changes in relation to Alpine images only (unit test seems ok, built in jenkins - images not pushed to docker repo - investigation ongoing? Dom to check CSIT tests, Gerry to see if DR have similar issue) 03/13: Need to chase up with Frank in relation to jenkins build not pushing up images new image name is bc - oom changes pending 03/15: Frank merged 4 commits today, Dom & Sunil to be put on review 03/20: Worse - images not getting pushed, old images are no longer there CI-MGMT - where is the review? Dom to reach out 03/22: Switch to Alpine broke 2 things in BC
DR our daily builds are failing - Frank investigating New CI - MGMT push has impacts on Casablanca jobs ( not using Alpine ) - is a bug required here? Potentially only effects DR 03/29: MR having issues, CIA team looking into 04/03: Frank from CIA team still working on this | |||||||||||||||||||||||||
| 31 | Blocked | Open | All | 02/04: Discussion on Edge deployment commitments. Centralized ONAP Deployment (DMAAP + DCAE) DCAE k8s deployment - Epic
DFC -
PM Mapper -
DFC + Mapper instantiated at edge, central or both - dependency on DR and MR Service provider provision topic Work on it and review progress at M3 02/06: is there a central registry - AAI (Vijay in communication with them) How do you retrieve edge locations? a label/name is what we need (need to be consistent with DCAE) Secondary consideration : how do we deploy component in edge and are aware of these - managing HELM charts? 2/8: Dom started to capture approach based on ongoing meetings with OOM: DMaaP Edge Deployment 02/13: Edge Deployment group asked for page to be reviewed with their team - DOM to forward out meeting call to all 02/15: OOM meeting - Experiment with edge, DMaaP have voluntereed to assist here lets wait for answer to whether or not to split out components might be solution going forward 02/20: Mike to discuss further - OOM 02/22: Mike still investigating this topic further Fiachra to look into why DR is structured the way it is? -see 02/27 OOM losing personnel - CNI in particular to get HA K8s up and running - keep an eye on 02/27: might have a solution for this part - mariadb sub requirement under dr-prov, issue in relation to helm with regard this OOM meeting - 3-4 to discuss further 03/01: Mike to attend on Monday 03/04: Mike is holidays week 11-12, need to ensure Conor commit gets merged Dom & Sunil have changes to follow suit after Conor's merge 03/06: James Mckinder (OOM team) having issues - potentially - not cleaned correctly - to be discussed at OOM meeting 03/08: Code has been merged to facilitate component deployment in diff sites release name has release and component name in them - this is causing an issue for configMap at DMAAP level helm install vs helm deploy work differently - potential a bug in helm deploy
03/15: Dom has done some great work on post install script - plan is to get the components and discuss plan going forward 03/20: Patch set 4, awaiting a MERGE once merged Sunil has follow up changes - mirror maker 03/22: Need to confirm if BC is working after merge (aaf permissions?) 03/29: Commit up for review to resolve 03/22 issue Dom trying to release 1.0.5 - 04/01 - Image released and updated -https://gerrit.onap.org/r/#/c/83671/ should resolve OOM issue | ||||||||||||||||||||||||
| 32 | Open | All | No more running as root on containers Proposed Updates to Release Templates (Dublin) - Security Questions Is it required for M2 ? 02/11 Doesn't need to be implemented by M2, nice to have for M4. (Try to plan for M4). Here's the link to the Jira where applications are being asked to update their impact and concerns regarding this item.
02/13: Dublin timeframe - Not mandatory, if possible complete, if not have a backlog item for El Alto Mandar to update ticket 02/15: ticket updated to work on this in El Alto - Mandar to ask reporter how do we interpret this ticket? created ticket in backlog 02/27: Is this related to Alpine solution - not clear New requirement : Wanted position to be part of Dublin 03/04: Action to start investigating - how will this be verified - Mandar 03/08: krzysztof to write script to enable verifcation -mandar to chase up "Actually the script can be merged into oneliner:
kubectl --namespace=onap get pods | tail -n +2 | awk '{print $1}' |\ xargs -d \\n -I % kubectl --namespace=onap exec '%' -- /bin/sh -c \ 'ps aux | sed "s/^/%\t/"' | tee ps-all.txt
What it does it just exec into every pod and list processes that runs as a root. In general, if you run container using docker you can use user namespaces and match a root user inside the container to any uid on the host that you want but according kubernetes doc user namespace are not supported which effectively means that if sth runs as a root inside the container it is also a root on a host (just certain capabilities may be dropped)
Best regards, -- Krzysztof Opasiak" 03/13: Mail forward onto team 03/20: what is required, when is it achievable 03/29: Required by M4 (think its delayed to 11/4?) 04/01: work in progress for DR Code is Merged for DR - https://gerrit.onap.org/r/#/c/83879/ | |||||||||||||||||||||||||
| 35 | Open | Logging | 02/15: Mail sent from Emmett - any feedback in relation to this? Is it Mandatory or not? Manageability as part of platform maturity requirements Target level is 2 for Dublin - mandatory 02/27: Create EPIC - 03/11: Epic created in Jira :
03/15: appears to be a stretch goal for existing components | |||||||||||||||||||||||||
| 36 | Blocking | Open | DR | DR AAF Certificates expired - DR broken in Casablanca now. Possibly generate new certs.
02/22: Johnaton to supply fresh ones 02/27: Certs updated and merged for Dublin & Casablanca Need to get new artifacts released per release - mail sent to Ram/Mandar 03/01: Artifacts released - Code up and awaiting merge and release documents updates needed 03/04: Master - code needs to be merged in OOM Casablanca - Process (Post maintenance release process to be determined) to get change into this release - 3.0.1 tag is already created - due to be discussed at PTL meeting ---------- Dmaap 1066 follow up to see if related - replica DB failed to come up (Closed) Dmaap 1076 03/15: An overall ticket - to bundle all changes in together - Mandar to source ticket (power point in relation to release?) 03:18: updates from Mandar: Tickets:
All changes related to this cert expired issue should be committed before 3/25. Casablanca 3.0.2 will be released on 3/25. 03/22: awaiting for merge to solution 03/29: Bulk PM use case verified on Casablanca wind river environment 04/01: Release new image with cert of 12 month duration - working on this 04/03: Waiting on OOM review to sign off on this | ||||||||||||||||||||||||
| 37 | Open | All | 03/15: 55% code coverage target is for M4 03/20: code and line coverage to be > 55% 04/01: DR approx at 60% Mandar working on code coverage for MR 04/03: DmaaP client and BC (52%) is only outstanding concern | |||||||||||||||||||||||||
| 40 | Open | All | 03/15: All to review and report back 04/01: Mandar reviewed and may need clarification on one or two points | |||||||||||||||||||||||||
| 41 | Open | All | 3/18: New ask from security team. HTTP ports should not be exposed for any of the components. Only HTTPS ports should be exposed. Action for all to remove exposure of component's HTTP port by M4-Dublin 03/20: Conflicts with OOM request to have ability to disable TLS Need Mandar to get clarity on which way to turn - seems like without a good certificate solution we are shooting ourselves in the foot - Dom to ask his security contact 3/26: clarification from Security Team: "Dom, I had a conversation with Amy this morning on this topic. Here are some key points from our conversation.
Amy, care to add anything?
Tony" 3/27: DMaaP team thinks we should be compliant with this because:
03/29: Mandar to ask Amy directly 04/01: Awaiting response from Amy - Can we use the overwrite file (flag bullet point above) is the proposal to have "non-TLS ports could be disabled by an OOM flag. TBD" by default and have overwrite file to enable it Mandar to inquire about DMaaP ports and downstream apps that use DMaaP 04/03: still no response - mandar will inquire later | |||||||||||||||||||||||||
| 42 | Open | All | Anyone wishing to make changes to OOM in relation to DMaaP should discuss with DMaaP team in advance. Similar tasks been worked on in parallel (duplication of effort) - COLLABORATION is the key Sunil has his commit up, PM mapper guys have OOM changes | |||||||||||||||||||||||||
| 43 | Open | All | 04/01 - Helm deploy fail when DMaaP deploy on own - only deploying bc post install Sunil has seen timeout issue - DOM looking into how best to facilitate this recommend to use commit shared above in https://gerrit.onap.org/r/#/c/83671/ Tested the above patch (WITH AAF ENABLED) and deployed successfully. 04/03: All is ok once tested with Patch above if one job doesn't finish others might not run BC will allow others to provisioning topics/feed during run time Mirror Maker crash loop - 500 error | |||||||||||||||||||||||||
| 44 | Open | All | DR node reg with BC client? - Hook is in place, values need to pass still to be determined post install hooks, flag can be added to keep alive |
...