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
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
Time
Item
Who
Notes
Documentation:
Notes: (Notes taken live in Requirements document)