Versions Compared

Old Version 3

changes.mady.by.user Sean Bohan

Saved on

compared with

New Version Current

changes.mady.by.user Nathan Southern

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

...

...

View file
nameGMT20221205-193412_Recording_1920x1080.mp4
height250

Date

ZOOM Meeting Information:

Monday, December 5, 2022 at  9am PT/12pm ET


Join Zoom Meeting

https://zoom.us/j/7904999331

Meeting ID: 790 499 9331

Attendees:

...

  • Sean Bohan (openIDL)
  • Ken Sayers (AAIS)
  • Peter Antley (AAIS)
  • Nathan Southern (openIDL)
  • Mason Wagoner (AAIS)
  • Faheem Zakaria (Hanover)
  • Jeff Braswell (openIDL)
  • Tsvetan Georgiev (Senofi)
  • Brian Hoffman (Travelers)
  • Yanko Zhelyazkov (Senofi)
  • Ash Naik (AAIS)
  • Dale Harris (Travelers)
  • David Reale (TRavelers)

Agenda:

  1. Ken - Update on ND
  2. Jeff - Update on Testnet
  3. Sean - Request for ARG WG AWG Chairs
  4. Sean - Infrastructure Partners WG
  5. Sean - Merge (ND and Testnet) and Maintainers Profess Process 

Drawings here: https://lucid.app/lucidchart/ac20d4e1-50ad-4367-b5cf-247ed9bad667/edit?viewport_loc=-301%2C-37%2C3200%2C1833%2CkgLSxXlpoGmM&invitationId=inv_de1a5e61-8edc-488a-90ee-8312f8c69cd4#

  1. Continue discussion - Architecture& Scenarios
    1. openIDL - Architecture Definition Workspace (NEW)
  2. Previous Discussions 
    1. openIDL - System Requirements Table
    2. openIDL - Policies
    3. openIDL - Operating Roles

Meeting Notes:

  • ND POC kicks off Feb
  • Testnet - solid progress
    • Show and tell to come
  • Request for AWG Chairs
  • Infrastructure Partners WG
  • Merge (ND and Testnet) and Maintainers Process 
  • When is a good time to rethink managed services decision ?
    • Do some work to see if they should reverse the decision?
  • What improvements can we make to make it easier to deploy/redeploy/etc. (reason for Infrastructure WG proposal)
  • Participants can/should run on their own provider/managed service - governance of the network is critical
  • Peter Antley
    • Working on auto coverage report for some time
    • PDF on right is actual report from 2010
    • Image Added
    • now has same values, need to be sorted correctly, has top ones and middle ones, all the rows needed on this report + columns 
    • next week, will have a prototype of this report built, caveat: for all the records in HDS for year, not filtering by state but approaching point where producing same report via HDS and EP as in the trad legacy ways
    • Developed reporting key
    • Coverage codes paired with diff deductibles
    • talking with DB people not sure if the right people are on here, but talk about report generating system, how to put reports together
    • how do we want to set up reports? how recyclable do we want it to be
    • Auto - two reports, good way to combine data from nodes and make report
  • Ken - ND is simple report - doing just that
    • how do we create report across all carriers?
  • PA - say gen this report, get 4 carriers to make the same report, no %s on this one, would a report gen take all datasets and add rows together based on reporting code?
  • KS - for some cases (average, etc.) - need to figure it out - lets get to report that meets that requirement - everything should be summable, if we need to do further aggregation
  • JB - two phase consent, mechanics of identifying total coverage or %s basis will be asked for
  • KS - get to some place where data call, do diff calculations later on, not have to wait, do report after the fact
  • PA - way building table, has assigned reporting codes based on this report to every row in DB on load, as we have more and more reports, convo when James is on call, figure out what the right way to keep track what reports to keep all these rows on
  • KS - why in DB and not in temp table? dont want every reports report key in the db itself? in temp table that goes away as part of reporting process
  • JB - are these keys functional routines based on the data
  • PA - 18 diff ways things can go together, gives every unique group its own ID
  • KS - temp table built in process, not in HDS
  • JB - report design, produce number of diff reports
  • PA - can do it in a temp table
  • KS - in script, passed in, like a mapping step (map-reduce)
  • PA - if you do that, make stuff that works well for business users, build temp table at query time is preferable, not optimize for easy business use
  • JB - extract or reporting process at Analytics node?
  • PA - how do we set up to be successful?
  • KS - 2 things - get out of any carriers extract, over however many channels on analytics node, summs these up, thats your report, assignment of transax to particular keys part of script that builds result doesnt save in HDS
    • not doing analysis on HDS
  • Jb - in EP anyway, can agg fundamental numbers, do that on reporting of agg dataset
  • JB - types of things working on DB for testnet?
  • PA - most has been cleaning code here, get to where we can produce report, in terms of where we are with testnet, SENOFI got him access to testnet, read and wrote a few transax to hyperledger example
    • hasnt gotten in with active development
    • getting into it
    • talking about doing some POC stuff with postgres
  • TG - some progress with postgrest, replace mongoDB as a datastore for the data, has somethign already working locally (hasn't deployed on testnet yet), need some more discussion on the data itself, structure, fields, etc.
    • did manage to repplace map-reduce with sql, simple db table, flow worked fine
  • KS - updated data flow processor
  • TG - changes on service not chaincode, saw things didnt like in chaincode, will work around to convert to SQL, designed with NOSQL and map-reduce idea, couple things dont need, cleaned up, thinking is if we 
    • if we want to support both (Postgres AND Mongo) we could do that 
  • KS - cant mix two, EPs different
  • TG - tailored to specific db, pick and choose
  • JB - doing SQL for now 
  • KS - where put postgres sql? in kubernetes?
  • TG - both ways possible, cheaper in kub, already have costs on cluster covered, if deployed as managed db costs something
  • PA - to get into mongo need kub - pain point - price add of RDS vs Kub?
  • KS - cognizant of every time we do RDS it is specific to AWS, should we toss Kub as it adds complexity, meant to go cross clouds, complexity-costly, not sure best choice? is Kub right thing (hard to debug) but if we blow it out on AWS, put into GCP or Azure
  • DR - try to make cloud agnostic you can make it worse
  • KS - Kub is powerful in a lot of ways, difficult to debug
  • DR - unless you need that superpower of Kub, it is touch
  • TG - diff teams, companies, strengths  - question if you think in context of single org, def yes, put most software on same cloud, HERE talking diff orgs/needs/knowledge - not a ? of "do we all use AWS" but hacing that option as a choice 
  • DR - most enterprises who adopt Kub, dont adopt in a way to run, not getting portability, TRV Kub diff than Hartford or anyone elses
  • FZ - Kub is great, meant for specific purpiose - if reqs not something we need or add later on, maybe not a priority - not required for carrier vs core node?
  • KS - excited by discussion, Kub makes it more portable
  • DR - not portable if you dont need high extensibility, scaing, on demand - get a lot of overhead
  • KS -AWS serverless and get all that stuff - what about Azure?
  • PA - Azure can do serverless, can do managed DB service, can do postgress, if we do javascript + then terraform?
  • FZ - Azure, AWS - complimentary, diff levels of containers, run into whatever service levle they want, (Azure containers, apps)
  • KS - if we focus on providing images as deploiyment and each carrier might use diff image
  • TG - cannot get away from specifics of fabric deployment
  • FZ - does it come in OCI image or not, up and running in diff environment
  • KS - Fabric is managed service in AWS, not sure about Azure
    • AWS managed service, controlling network, use simpler implmentation
  • JB - some of the work Senofi have done with reliability/redundance would be worth discussing, fabric runnign across providers
  • TG - need to do more, explore Operator, worth looking to, abstracts many things around deployment, couple thiungs need to do cloud-specific
  • JB - need a sep meeting to go into mroe detail, topic is fairly timely and needs attention 
  • KS - decide if in POC, do we inc bigger refactorings to get first report - what tech stack use for POC
  • JB - obj to support POC, whatever subset it might be, general solution
  • DR - people want to consume this as a SaaS, dont lead with it, get carrier to buy in, dont tell em whats under the hood, will just start questions about complexity - cant be a total black box, every carrier will auydit, know whats going on, if we over index on tech and try to explain all the stuff, "why Kub", etc. - sets off hodgepodge of tech, dig into it deeper - treat is "here is a SaaS offering", let them do DUe Dilligence after the fact, not setting a technology but selling a solution which is what they want
  • KS - other thing - slightly diff, if someone wants to host their own, diff level of due dilligence,
  • DR - where you want it to be much simpler than it is - point of POC: it works and get more to participate - dont overwhelm with too much stuff - consider streamlining deck as a full rewrite
  • JB -container approach could be deploy more easily
  • DR - still a lot of interaxtions that could occur, with enterprise regs, minute you differ from SaaS style offerings, running into all sorts of guardrails, controls and checks that you now have to disentangle and integrate - containers dont help there
  • JB -with Infra Partners can provide as a service
  • DR - hosted as a service easier to consume
  • KS - when carrier wants to host whole stakc themselves
  • FZ - if ytou dont want to host, what do you need?
  • KS - current direction - few pics, call over to run EP and get results
  • FZ need HDS and adapter?
  • KS - yes, HDS and executor of extractions
  • DR - simple - containerize adapter, simplify HDS, more manageable to take on, doable - otherwise simplify drastically
  • JB - with postgres, operated on by EP
  • DR - adapter, serverless code in a lambda, that is a doable sell to go to a carrier and ask them to do that - anything beyond that scare people off
  • JB - network side, app side, maintain distinction, make it easier to manage
  • PA - get with senofi and jef tomorrow - has schemas ready to talk about schema and test data, look into it more, also working this week over doing a state of openIDL, catalog what current state is, going, get done - present next week to this group - today got thru HDS and report gen, not a lot more for today
  • JB



TimeItemWhoNotes




Documentation:

...