BTW - cant remember if it was VID or portal that we backed out of shared. Both are on their own right now.
Brian From: [email protected] <[email protected]> On Behalf Of FREEMAN, BRIAN D Sent: Thursday, April 16, 2020 9:31 AM To: [email protected]; [email protected]; Krzysztof Opasiak <[email protected]>; Mike Elliott <[email protected]>; [email protected]; CLOSSET, CHRISTOPHE <[email protected]> Cc: RICHOMME Morgan TGI/OLN <[email protected]>; DEBEAU Eric TGI/OLN <[email protected]>; [email protected] Subject: Re: [onap-discuss] [ONAP][OOM] having charts for commodities ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. That's what we have with VID and we had to back out of the shared mariadb. I appreciate the application teams caution to maintain the separate database option but it does reduce the focus on making the shared databases perform. I do not know why the shared databases in some applications are under performant. I don't know if our efforts to minimize footprint have reduced the resources for shared database either in spindles or cpu/memory to the point they cant handle the shared load or something else is going on. Its not all applications, sdnc and so appear to share mariadb fine. Not sure that aai and sdc are as happy with their shared environment - in robot we see long delays in replication across the Cassandra cluster in our current nfs based solution (or at least that's what we think is going on when we create a service and then wait for confirmation to succeed on a GET). We will have to re-test once we are off the shared nfs. I do agree there is no reason for the application to have to spin up their own when it's a k8 single node deployment - historically when we started as VM's that might be in different data centers around the globe it made sense to bundle the database with the application, in a single deployment in one centraliled location it is less of an issue. Things like DCAE that are designed for remote deployment at the edge might be something to think about though. And controllers will likely have a regional deployment as well for 5G so that needs to be fatored into the design (and I think it still fits your model just the service provider will have to deploy their common database in the same nodes they are deploying DCAE or SDNC ). These are situations where the service provider would rather use the option for a common install of both data store and application. Brian From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Thursday, April 16, 2020 9:11 AM To: FREEMAN, BRIAN D <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Krzysztof Opasiak <[email protected]<mailto:[email protected]>>; Mike Elliott <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; CLOSSET, CHRISTOPHE <[email protected]<mailto:[email protected]>> Cc: RICHOMME Morgan TGI/OLN <[email protected]<mailto:[email protected]>>; DEBEAU Eric TGI/OLN <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE:[ONAP][OOM] having charts for commodities "deprecate" means not the default way but it will still be there at least for G :) ________________________________ De : FREEMAN, BRIAN D [[email protected]] Envoyé : jeudi 16 avril 2020 15:09 À : DESBUREAUX Sylvain TGI/OLN; [email protected]<mailto:[email protected]>; Krzysztof Opasiak; Mike Elliott; [email protected]<mailto:[email protected]>; CLOSSET, CHRISTOPHE Cc : RICHOMME Morgan TGI/OLN; DEBEAU Eric TGI/OLN; [email protected]<mailto:[email protected]> Objet : RE: [ONAP][OOM] having charts for commodities Good that a change to get off shared nfs will happen in G. Also have to track tooling impacts - cleanup.sh in integration that we use for redeployment will need to be updated if we don't have support for undeploy/delete removing the schema's on a delete (which is still not perfect because a failed boot usually means the schema got partially loaded and then the application lost its mind so cant do the cleanup). Aks install scripts would be impacted in integration repo (not a huge thing but something to make sure that K8 as a service isn't impacted) I guess dns will just work but our fqdn to talk to a common thing would be mariadb.common instead of mariadb.onap or something similar ? Seems like we would need the deployment scripts to do a two stage install - common first and then onap. Etc. It's a good thing to do. We just shouldn't under estimate the impact. Brian From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Thursday, April 16, 2020 9:01 AM To: FREEMAN, BRIAN D <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Krzysztof Opasiak <[email protected]<mailto:[email protected]>>; Mike Elliott <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; CLOSSET, CHRISTOPHE <[email protected]<mailto:[email protected]>> Cc: RICHOMME Morgan TGI/OLN <[email protected]<mailto:[email protected]>>; DEBEAU Eric TGI/OLN <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE:[ONAP][OOM] having charts for commodities I believe that most of the problem we have is coming that we're using old images (for mariadb), not well done and we've added our "secret sauce" which is not the best... For a testing perspective, it shouldn't change "anything" : * there would be a shared db, possibility to have a local cluster but the helm charts would be a lot better. Please bear in mind that we'll deprecate "shared nfs" folder in G release (you can use nfs-provisionner to have the same behavior) and thus our "particularities" won't be there anymore ________________________________ De : FREEMAN, BRIAN D [[email protected]] Envoyé : jeudi 16 avril 2020 14:55 À : [email protected]<mailto:[email protected]>; DESBUREAUX Sylvain TGI/OLN; Krzysztof Opasiak; Mike Elliott; [email protected]<mailto:[email protected]>; CLOSSET, CHRISTOPHE Cc : RICHOMME Morgan TGI/OLN; DEBEAU Eric TGI/OLN; [email protected]<mailto:[email protected]> Objet : RE: [ONAP][OOM] having charts for commodities The problem is that it varies. Sometimes an existing common version exists, sometimes it doesn't and for testing everyone would have to deploy our version anyway but putting it in a separate namespace will create a lot of work and breakage. It would drive the rigor to make sure its easy to reference /connect to an external database but the schema's required by the applications become difficult for the automated boot sequence (again tedious to get right as you point out with things like shared secrets since you couldn't dynamically generate them but have to use assigned credentials from the external system) Non-trivial decision due to the impact and in all honesty many times we have had to turn off shared datastores because the underlying datastorage layer isn't allowing it to perform. I'd rather fix that data storage layer first so that common databases actually scale and have no single points of failure. Maybe you already have that in plan. Brian From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Sylvain Desbureaux via lists.onap.org Sent: Thursday, April 16, 2020 7:56 AM To: Krzysztof Opasiak <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; CLOSSET, CHRISTOPHE <[email protected]<mailto:[email protected]>> Cc: RICHOMME Morgan TGI/OLN <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [onap-discuss] [ONAP][OOM] having charts for commodities Guys, I'm quite relunctant to keep on adding helm charts in "common" part of ONAP for software which is quite common (databases mostly) and have "custom" made charts which are way behind current kubernetes standards (bitnami for example or crunchydata for postgres). There's one issue as of today that "force" us to do that: * we don't didn't have a proper dynamic PV handling with ONAP components which would prevent this. So, I would like to remove these charts. We would document the need for ONAP to have consul, cassandra, mariadb, postgresql, mongo, elasticsearch and etcd deployed (and who's using it, so no need to install mongo if no NBI and Multicloud k8s for example). For testing purpose, we would install them like we're doing with contrib stuff but __within__ their own namespace. This would mean to "trick" our current secret handling (a secret can be accessed only from its own namespace but we could create two secrets instead of one in our templates I guess). What do you think? Of course, this would mean removal of other "specific" charts : * zk + kafka for DMaaP * prometheus for multicloud * kibana, elasticsearch, logstash for clamp and log project * redis for dcae and vfc * nifi registry for dcaemod (and I may have not found others) _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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 (#20695): https://lists.onap.org/g/onap-discuss/message/20695 Mute This Topic: https://lists.onap.org/mt/73052571/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
