Hi, Thanks, all makes sense its just that you are ahead of the most of the current ONAP deployment in your thinking so it stood out a bit.
I think I found an unlikely but possible way that the "corruption" of the init data could have happened and I raised. https://jira.onap.org/browse/AAF-938 Its not a high priority as I think it is quite unlikely (but possible) Thanks /Andrew On 09/08/2019 15:03, GATHMAN, JONATHAN C wrote: Greetings, Long term data is (currently) on the NFS, though if I could figure out how to do it effectively in K8s, I wouldn't put it there either. For the generating Config info, they include Certificates and other sensitive Security Information. I suggest local Container Node persistence for a couple of reasons. * An NFS, in my opinion, may very well be configured badly, and allow for security issues. * NFS is Network Drive. if access is interrupted, and ALL AAF Instances require it, then ALL AAF is down. If ALL AAF is down, then all ONAP is down. * I consider this security infrastructure to be Mission Critical, when used, so I avoid as many catastrophe generating implementations as possible. * A local Drive on the Node is much less likely to fail, and if it does, and there are multiple nodes, AAF keeps going * Certificates, and configurations (including Geo Location) is better on Node basis, if possible. * Nodes are more isolated, less easy to get to * If a Node has a problem, such as letting a Cert Expire, other Nodes may well cover traffic if theirs aren't expired, allowing for better Resiliency * AAF's "Locator" architecture allows you to put AAF "nodes" anywhere in the world, allowing for localized access for fastest possible access time, which is critical, given it is Security. I suspect an NFS drive would negate that advantage, forcing what COULD be an Independent Node in Singapore to talk to what may be US Based NFS drive for DB data storage. That is unacceptable, imho. Future instances of ONAP, I hope to figure out how to do Cassandra in K8S startups reasonably fast, so they can be Per Node as well, giving the kind of Global Scalability and Resiliency that AAF already provides as Standalone VMs for my company. -- Jonathan Gathman Principled-System Architect ATO Tech Dev/SEAT/Platform Architecture and Technology Management AT&T Services, Inc. m 314-550-3312 | [email protected]<mailto:[email protected]> On 8/9/19, 8:32 AM, "[email protected] on behalf of Andrew Fenner"<mailto:[email protected]> <[email protected] on behalf of [email protected]><mailto:[email protected][email protected]> wrote: Hi, On an el-alto staging install my aaf didn't come up. After a bit of digging I found that the file /opt/app/osaaf/local/org.osaaf.aaf.cassandra.props was missing and that this was mapped from /mnt/data/aaf/config/local/ After a bit of cleanup and restarts the problem went away so I put it down to one of the wierd issues that happens. If it happens again I'll try to get to the bottom of it and raise a jira. But the question is why the aaf isn't using the /docker-nfs directory for this data as it makes it very hard to debug and unpredicatable as the /mnt/data/aaf/config directory is local to each k8s host. Is there a reason for this ? Thanks /Andrew -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18509): https://lists.onap.org/g/onap-discuss/message/18509 Mute This Topic: https://lists.onap.org/mt/32810443/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
