Progressive stack complexity (Topic from James Madison)
"How much of the full stack listed on the architecture pages is actually needed to get going, to run mid-size, to run at scale.
The three that came up are Cognito, RAM, Elastic Load Balancing. Could we swap out Cognito for something like IBM APIC, what do we need RAM for, do we need ELB if we care to stay small."
TSC Member Engagement
Other Steering or Board committee updates
Open Floor: Community input/feedback on current efforts
TSC Backlog Planning/Grooming
Upcoming events and TSC schedule
TSC Items to Consider:
Wrap-up: To-dos and community communication
Discussion: time permitting
Adjourn: 11am PT/2pm ET
Extended Discussion/Socialization – Chair will keep meeting open as community requests, for up to 1 hour (12pm PT/3pm ET; minutes not recorded)
2021-10-08 TSC Recording
Notes:
10:05 Convened
10:06 Minutes approved, motion by Truman, seconded by James, no objections.
10:07 Introductions, including of non-TSC folks
10:09: Ken Sayers updates on core tech:
Up and running on AWS, have now left IBM infrastructure.
Working with Chainyard to finalize documentation
10:12: Truman updates:
Uninsured Motorist RFI for North Dakota, open to input from the community. Similar to COVID19 POC.
Regulatory Reporting Governance Committee is getting going
Briefings have been done with the anticipated next head of NAIC and others in industry
10:18: Main discussion: getting to production
James: Progressive stack complexity. How much of this is needed to get going? How fast can we get a node going if we didn't enable or have to enable some services? E.g. Elastic Load Balancing.
Ken: let's work together to find ways to make them optional. These kinds of things will require work with each carrier.
David Reale: the smaller the footprint that has to be agreed upon, the better for all of us. We want enough consistency so it doesn't become an operational burden, but we need flexibility. We are hoping to stand up a full node next week on Monday and so this is a live issue.
James - where can we engage on something like this? What's the Linux Foundation way?
Brian: this is a safe space, let's talk here, and focus it on aspects of public code.Oh, we need to set up a TSC mailing list. That's where this stuff should happen. You can have ad-hoc conversations but let's post decisions or minutes to a public place, the wiki or mailing lists or the like.
(general consensus this makes sense). Lots of discussion about how to have more public conversations and change the working norms towards more public processes.
Action Item: Brian/openIDL staff to create a technical discussion mailing list specific to the openidl core platform development. For now, use TSC mailing list for any technical discussions.
moving on to questions James had posted last time...
James: Do we have a bias towards some specific data model, towards denormalization? How general-purpose can we be? What's the balance point?
Truman: this is up to us! We want to grow the community. It all depends on how many different use cases and communities we pull together - auto vs home vs COVID all represent different models and lifecycles
Ken: data architecture will be per use-case, they come together at some point in the middle.
Brian: harmonization of models will be something TSC and the RR-WG take on, and evolve over time.
James: is there a timing on the database question? Which one will we be using? Truman: there likely will be different ones used based on the data model.
Time
Item
Who
Notes
5min
Agenda item
Name
Notes for this agenda item
Action items
Type your task here. Use "@" to assign a user and "//" to select a due date.
Attendees