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). 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: <onap-...@lists.onap.org> on behalf of "Sylvain Desbureaux via lists.onap.org" <sylvain.desbureaux=orange....@lists.onap.org> Reply-To: "onap-...@lists.onap.org" <onap-...@lists.onap.org>, "sylvain.desbure...@orange.com" <sylvain.desbure...@orange.com> Date: Monday, April 27, 2020 at 12:22 PM To: "onap-...@lists.onap.org" <onap-...@lists.onap.org>, "onap-tsc@lists.onap.org" <onap-tsc@lists.onap.org> Cc: RICHOMME Morgan TGI/OLN <morgan.richo...@orange.com>, Krzysztof Opasiak <k.opas...@samsung.com>, Mike Elliott <mike.elli...@amdocs.com>, "CLOSSET, CHRISTOPHE" <christophe.clos...@intl.att.com>, "dmcbr...@linuxfoundation.org" <dmcbr...@linuxfoundation.org>, Kenny Paul <kp...@linuxfoundation.org> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_onap_oom_tree_master_kubernetes_nbi&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=HceOARp59TvXni8a6PJgJVBW81QZ4IHOTjrxRGuNiU0&s=KJ89qSlgfhIhQT-fXkbJYG8mmP0FgLxUJHMqe1-UUnk&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_onap_oom_tree_master_kubernetes_nbi&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=HceOARp59TvXni8a6PJgJVBW81QZ4IHOTjrxRGuNiU0&s=KJ89qSlgfhIhQT-fXkbJYG8mmP0FgLxUJHMqe1-UUnk&e=>) as an example) * do it by your own + explain why you can't use `certInit` template (will be subject to acceptance / not acceptance from both SECCOM and OOM team) # No More than 1 main process per container Several containers uses several process (main component + database(s)) in the same docker. Each container should have only one concern. Decoupling applications into multiple containers makes it easier to scale horizontally and reuse containers. For instance, a web application stack might consist of three separate containers, each with its own unique image, to manage the web application, database, and an in-memory cache in a decoupled manner. Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule. For example, not only can containers be spawned with an init process, some programs might spawn additional processes of their own accord. For instance, Celery can spawn multiple worker processes, and Apache can create one process per request. This will not be accetped anymore as it's a very bad pattern (https://docs.docker.com/develop/develop-images/dockerfile_best-practices/<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.docker.com_develop_develop-2Dimages_dockerfile-5Fbest-2Dpractices_&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=HceOARp59TvXni8a6PJgJVBW81QZ4IHOTjrxRGuNiU0&s=QuU9n_5-csVHuOz_IadQvZI5yOaJL8hfcttcxWnDek8&e=>). # All logs to STDOUT As per SECCOM (and testers ;) ) requests, all the logs **must** go to STDOUT. It'll easier troubleshooting and future centralized log work. # Smart Healthchecks If your healtchecks just verify that `/status` is answering 200, there are not useful as readiness/liveness probes can do it. So create meaningful healtchecks or remove them if they can be done via readiness/liveness probes. # Relevant commit messages: the commit message (on OOM) **must** follow this form: ``` [NAME_OF_COMPONENT|DOC|COMMON|GENERIC] Meaningful title (from OOM side) at least one sentence explaining the change done in this patch, cause and consequences and possibly more of course Issue-ID: AS_WE_ARE_FORCED_BUT_MEANINGLESS Change-ID: xxx Sign-off: xxx ``` Commit message will be the last stuff that will stay with our code so it must clearly explain the changes, the "why" and the consequences. If it change OOM behavior in any way, documentation **must** be also updated. Starting Frankfurt branching, merge requests which are not following this pattern will not be merged. Please read the following pages and follow the guidelines for writing commit message contained therein. * http://bit.ly/goodcommitmessages<https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_goodcommitmessages&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=HceOARp59TvXni8a6PJgJVBW81QZ4IHOTjrxRGuNiU0&s=8TSHbPBYRXs4hLPF0AyUWy3t67S_NZ4jnv1CybU9jtM&e=> * http://who-t.blogspot.com/2009/12/on-commit-messages.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__who-2Dt.blogspot.com_2009_12_on-2Dcommit-2Dmessages.html&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=HceOARp59TvXni8a6PJgJVBW81QZ4IHOTjrxRGuNiU0&s=w857YnB7tIRHodxOgiaNsAaCbJBrKD-8PVK60_9oGXo&e=> * http://dep.debian.net/deps/dep3/<https://urldefense.proofpoint.com/v2/url?u=http-3A__dep.debian.net_deps_dep3_&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=HceOARp59TvXni8a6PJgJVBW81QZ4IHOTjrxRGuNiU0&s=J02E092N_nvYErW7hnEiVcptrpNlqERHHGrOwGA_wLY&e=> # No root access to any Database from application container If you need to create users, tables etc do it from init container. You can either: * use common.mariadb-init template for MariaDB (will be extended for PostgreSQL) * use your init container + explain why you can't use the common chart # No configuration generation using sed in the application container It can be delivered as a config map or if it has to be somehow processed this should happen in the init container. # Kubernetes upgrade to 1.18 In order to move to Kuebernetes 1.18, significant changes will be done on helm charts, using templates we've made. It shouldn't be harmful on your side. Moving to 1.16+ will allow use to use [startupProbe](https://v1-16.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/<https://urldefense.proofpoint.com/v2/url?u=https-3A__v1-2D16.docs.kubernetes.io_docs_tasks_configure-2Dpod-2Dcontainer_configure-2Dliveness-2Dreadiness-2Dstartup-2Dprobes_&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=HceOARp59TvXni8a6PJgJVBW81QZ4IHOTjrxRGuNiU0&s=tM2BQ0LyxoMwxXA2d66SLP2ZQOa0o6cXQNJkW5Yeoy4&e=>), if you've have slow starting components, please tell us! # Databases upgrades Databases will move to follow [SECCOM proposition]( https://wiki.lfnetworking.org/display/LN/2020+April+Technical+Event+Schedule?preview=/34605773/34606179/password_removal_update.pptx<Versions</a>), %20please%20advise%20if%20your%20component%20is%20not%20compatible%20with%20the%20recommended%20version.<br> <br> If%20you're%20using%20a%20**specific**%20(out%20of%20common)%20version%20of%20a%20component%20listed%20in%20the%20page,%20you'll%20either%20have%20to:<br> <br> * %20move%20to%20the%20common%20chart%20(**preferred**)<br> * %20deal%20with%20the%20upgrade%20+%20explain%20why%20you%20can't%20use%20the%20common%20chart<br> <br> #%20All%20upstream%20components%20should%20use%20an%20upstream%20(dockerhub,%20googlehub)%20version<br> <br> All%20upstream%20components%20directly%20used%20(databases,%20kafka,%20zookeeper,%20nginx,%20haproxy,%20...)%20should%20use%20directly%20the%20upstream%20version%20and%20not%20embed%20it%20into%20its%20own%20docker<br> <br> #%20AAF%20component%20is%20optional<br> <br> AAF%20is%20used%20for%20certificates%20and%20RBAC.%20It's%20a%20non%20mandatory%20requirement,%20meaning%20your%20component%20**must**%20be%20able%20to%20not%20use%20it%20for%20both%20features%20(but%20this%20is%20*enabled*%20per%20default).<br> The%20mode%20can%20be%20obviously%20degraded%20(no%20HTTPs,%20no%20rbac%20but%20basicAuth)%20when%20AAF%20is%20disabled.<br> <br> Please%20bear%20in%20mind%20that%20we're%20working%20on%20removing%20needs%20for%20AAF%20for%20certificates%20AND%20need%20for%20AAF%20for%20RBAC%20so%20this%20will%20be%20tested.%20(see%20[AAF%20Removal]()<br> <br> #%20MSB%20component%20is%20optional<br> <br> MSB%20is%20interesting%20when%20used%20on%20non%20Kubernetes%20deployment.%20But%20the%20features%20proposed%20are%20an%20overlap%20of%20basic%20Kubernetes%20features.<br> Furthermore,%20it%20prevents%20to%20correctly%20traces%20dependencies%20between%20ONAP%20components.<br> <br> As%20such,%20your%20component%20**must**%20be%20able%20to%20not%20use%20MSB<br> <br> #%20Password%20removal<br> <br> Full%20status:%20<a%20href=> Mariadb password removal is done. The work will continue on postgresql and other common charts. Work will be started on component (Policy is underway), be prepared to receive so call for help. # Pods requests/limits Every container (including init containers) should have requests/limits with "good" values (not too high, not too low). A check will be done and some values will be changed. A "simple" rule for setting the limits requests: * request should be the mean use of the container * limits you should be somewhat higher to expected MAX use. * For memory, if you can set MAX values in the underlying program (like in Java), set the max to 1.2 times this value. If not, set 1.5 times of max ever used. * For CPU, set 2 or 3 times of max ever used as some CPU may be significantly slower. # Ingress use as default deployment (instead of node ports) Instead of using NodePorts, we want to push the use by default of Ingress. Significative changes will be made when this is ready (especially removing "NodePort" as default service type from most of ONAP services). If your component is using "hardcoded" access to other components via NodePort (like Portal), please advise as it won't be possible anymore (but access will still be possible via ClusterIP for internal, Ingress for external). Using node ports will still possible, by configuring the different services. # Dynamic PVC as default deployment (instead of /dockerdata-nfs) Instead of pushing everything to /dockerdata-nfs, we'll default using storage class(es). It will still be possible to use /dockerdata-nfs but won't be the default way. # Service Mesh PoC Wiki page: https://wiki.onap.org/display/DW/ONAP+Security+Model<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2BSecurity-2BModel&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=HceOARp59TvXni8a6PJgJVBW81QZ4IHOTjrxRGuNiU0&s=9hJXMi91c1ptqG-ttHA-7LTcSY7y9xAVHQSitAQ-itM&e=> A PoC using service mesh (Istio), Ingress (component tbd) and RBAC management (keycloak) will be started. For that, we must be able for your components to: * use HTTP (and not HTTPs) as Istio handles the TLS part for both **server** and **client** part * disable RBAC / basicAuth as keycloak will do the RBAC for your component (meaning if a request is coming on your component, it has already been granted by keycloak) for both **server** and **client** part Some call for help may be launched if we don't understand your component behavior. This work will be done starting by "Core" component (DMAAP, AAI, SDC, SO, SDNC) and be extended. I understand it's a very "bold" plan but I believe we can make it and ONAP deployment will be a lot more consistent! Best regards, -- 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. _________________________________________________________________________________________________________________________ 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. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#6235): https://lists.onap.org/g/onap-tsc/message/6235 Mute This Topic: https://lists.onap.org/mt/73311065/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] -=-=-=-=-=-=-=-=-=-=-=-
