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]; DESBUREAUX Sylvain TGI/OLN; Krzysztof Opasiak; Mike Elliott; [email protected]; CLOSSET, CHRISTOPHE Cc : RICHOMME Morgan TGI/OLN; DEBEAU Eric TGI/OLN; [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] <[email protected]> On Behalf Of Sylvain Desbureaux via lists.onap.org Sent: Thursday, April 16, 2020 7:56 AM To: 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]; [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. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20691): https://lists.onap.org/g/onap-discuss/message/20691 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]] -=-=-=-=-=-=-=-=-=-=-=-
