Skip to content

Changes

Page history
Update Meeting Minutes 2020 authored by Chris McGinn's avatar Chris McGinn
Show whitespace changes
Inline Side-by-side
Meeting-Minutes---2020.md 0 → 100644
View page @ 3d96c581
**Admin UI API Discussion with Chris Zhang**
**Dec 29, 2020**
**Attendees**: **Chris Zhang**, Anshu, Osho, Ashwani, Chris.
- Demo'd Admin UI through AWS platform showing overall layout of screens, navigation through screens, create group, add member to group, capability to delete member from group, create legal tags.
- Chris shared with us a document with details for various Services & APIs:
- URL: https://gitlab.opengroup.org/osdu/subcommittees/business-model-outreach/projects/cert/docs/-/blob/master/TeamDocuments/R3%20Deliverables/OSDU_Technical_Standard_V1_draft_16.docx
**Action Items:**
- Contact Alan Henson for getting more inputs on Data Loading user stories and APIs.
------------------------------------------------------------------------------------
**Admin UI - EDS user stories and requirements**
**Dec 29, 2020**
**Attendees:** **Jacob Rougeau**, Anshu, Osho, Ashwani, Chris.
- Discussed on various API’s like storage, schemas, dataset Registry and how the payload needs to be sent to the API call in detail.
- Jacob informed that there are new services for Schema, which is still under progress.
- Demo'd Admin UI through AWS platform for Entitlement Module.
- Jacob suggested to add one more widget on Admin UI dashboard for External Data Source, and onclick of that widget it gets navigated to a page where we display the user stories for EDS module.
**Jacob Summarizes as below:**
1. Use schema/storage service to retrieve the schemas for ConnectedSourceDataJob and ConnectedSourceRegistryEntry.
1. Transform the user’s web form input into json payloads for ConnectedSourceDataJob and ConnectedSourceRegistryEntry.
1. Use a json library to validate the document from #2 against the schemas from #1. If valid, then submit to Storage API. If invalid, then display error message to user.
**Action Items:**
- Jacob to provide the requirements for developing UI for External Data Sources.
- Need to confirm on the scope for EDS user story development.
------------------------------------------------------------------------------------
**Admin UI - EDS user stories and requirements**
**Dec 21, 2020**
**Attendees**: **Jacob Rougeau, Rawaa.Al-Saffar,** Anshu, Osho, Ashwani, Swetha, Chris.
- Jacob gave an overview of EDS (External Data Sources).
- Goal of external Data services is to extend the OSDU platform, so that it can seamlessly retrieve data from external sources.
- Explained about source registry and its use.
- External Data source Admin UI needs to be created.
- The data manager to update the required details to the UI:
- Data that describes the external source
- Add additional configuration
- When the schedule job to start
- What type of data need to be retrieved
- What service account need to be used to retrieve the data
- Jacob shared with us the wiki link for EDS
- url: https://community.opengroup.org/osdu/platform/data-flow/ingestion/external-data-sources/external-data-framework/-/wikis/home
- Jacob showed us a rough UI screen for External Source Registration which needs to be developed by Admin UI Development Team (Infosys).
- Jacob mentioned that there will be mainly 2 screens for EDS UI. First page will be to register the high level source and the second screen is for registering the scheduled jobs.
- Jacob gave an overview of Storage services and search services.
- Jacob informed that currently there are no API’s for Data Monitoring, Error Handling, Audit and Metrics. These API’s will be developed and available in later horizon.
- Chris shared with Jacob and Rawaa the wiki page URL for OSDU admin UI.
**Action Items:**
- Jacob to provide the requirements for developing UI for External Data Sources.
- Jacob to send details on User Stories and APIs for developing the UI.
- Admin UI Development team to develop a prototype for EDS.
------------------------------------------------------------------------------------
**Admin UI status with GCP**
**Dec 17, 2020 9:30am Houston**
Attendees: **Ferris Argyle, Dmitriy Rudco,** Paco Hope, Anshu, Osho, Ashwani, Swetha, Chris, Sourabh
- Admin UI Development team asked for a walk through of Data loading and Data Ingestion module.
- Ferris provided the point of contact for Data loading and Data Ingestion.
- Dmitriy provided the link for Data ingestion postman collection for R2 APIs.
- url: https://community.opengroup.org/osdu/platform/data-flow/ingestion/ingestion-framework-getting-started
- Data loading (File services) -these APIs might change in future. So Dmitriy asked to not start developing Data loading.
Dmitriy informed that GCP partition services is not available currently, it will be available by February.
**Action Items:**
- Follow up with Dmitry_Kniazev@epam.com re. ISV Training Postman test harness.
- Follow up with alan.henson@parivedasolutions.com and Kateryna_Kurach@epam.com for walkthrough of Data Loading (getting file into storage) and Ingestion respectively (including workflow status).
- Dmitriy to elevate permissions provided for test accounts(Need to be able to list members, delete members and add groups; can only add a group.)
- Dmitriy to provide information on Partition service endpoint when it’s available(M4)
------------------------------------------------------------------------------------
**AdminUI demo for Johan
Dec 17, 2020 7am Houston**
**Attendees:**
**Johan Krebbers, Dennis Stevens, Paco Hope**, Anshu, Osho, Ashwani, Swetha, Chris, Sourabh
- Reviewed activity with module owners, CSPs, and SMEs since first week of Nov.
- Demo'd Admin UI through AWS platform showing overall layout of screens, navigation through screens, create group, add member to group, capability to delete member from group, create legal tags.
Discussed access to the 4 CSPs:
- AWS - all access needed is done;
- GCP - need more diverse user IDs (only have two right now);
- Azure - Sourabh and Dania are close to getting this in place;
- IBM - In progress with Wlad
**Feedback from Johan:**
- Operator should be responsible for defining super-user for their organization, not CSPs
- Get with Jacob for EDS User Stories
- Check with Stephen Whitley if there are any DDMS User Stories
- Add details to user stories to help those working on it
- Get sign-off from module owners on user stories
- OSDU logo on first page is outdated - contact Steve Phillip from marketing for the right one
- Navigation to go back from browser or return to home screen by selecting "Dashboard" is good
- Provide me a list of shortcomings in the OSDU platform. What is missing, not necessarily what is in -progress because we know it's being worked on at least.
- Add help information on complex screens (such as legal tags create/update)
- For now, work with me for Operations & Ops (formerly audit & metrics)
- Any other issues, contact me for help
**Action Items:**
- Chris - by this weekend, add details to user stories in the Wiki **In-Progress**
- Chris - Get EDS user stories from Jacob R **(Meeting set for Dec 21st)**
- Chris - check with Stephen Whitley if there are any DDMS user stories **(Slack message sent; waiting on response**
- Chris - contact Steve Phillips in Slack for correct OSDU logo - **Done**
- Anshu - Add tool tips/help information for user experience on complex screens
- Anshu - Update OSDU logo on main page
- Paco/Chris - Provide list of API shortcomings to Johan **(In-Progress)**
-------------------------------------------------------------------------------------
**AdminUI status
Dec 16, 2020 9am Houston**
**Attendees:**
**Joe Nieten, Paco Hope**, Anshu, Osho, Ashwani, Swetha, Chris, Sourabh
Discussed wiki User Story and API Availability line items with Joe
Recommendations from Joe:
- Start on E&O first, since most APIs are available
- Data loading APIs are not settled; targeted for M3
- Data Ingestion APIs are not settled; targeted for M3
- Recommends building the UI pages for Data ingestion, loading, and data platform for M4.
-------------------------------------------------------------------------------------
**AdminUI wiki status
Dec 16, 2020 8am Houston**
**Attendees:**
**Paco Hope**, Anshu, Osho, Ashwani, Swetha, Chris, Sourabh
Update on wiki folders:
- Added Design and Development approach
- Added Deployment Architecture
Srihari sent userid creditionals and endpoints yesterday;
**Action Item:**
- [ ] team to verify their AWS credentials, endpoints work, and CORS headers are configured as needed.
-----------------------------------------------------------------------------
**AdminUI wiki documents
Dec 14, 2020 9am Houston**
**Attendees:**
**Paco Hope**, Anshu, Osho, Ashwani, Swetha, Chris, Sourabh
Plan for restructuring AdminUI wiki
- Paco and Anshu will work on Design and Development document
- Create separate wiki respository for User story and API Availability
--------------------------------------------------------------------------------
**System Configuration user stories and APIs
Dec 14, 2020 7:30am Houston**
**Attendees:**
**Raj Kannan**, Anshu, Osho, Chris
Raj recommends recording demo and putting on wiki.
- Recommends high-level role to group service roles together (admin/user/viewer) into logical sets.
- Example - data manager needs these 23 service types or data user needs these 15 service types
- Get CSP postman scripts and payload requests to entitlement services to have differences between an admin or viewer
- Reiterated starting small for prototype, as mentioned in 12/7 meeting, and save data ingestion/loading for later phase.
-------------------------------------------------------------------
**Data Loading user stories and APIs
Dec 11, 2020 8am Houston**
**Attendees:**
**Srihari Prabaharan**, Paco (first 5 min), Chris, Swetha, Osho, Ashwani
Srihari provided bootcamp for AWS entitlements and validations
--------------------------------------------------------------------------------------------------
**Data Loading user stories and APIs
Dec 11, 2020 8am Houston**
**Attendees:**
**Michael van der Haven, Paco Hope**, Chris, Swetha, Osho, Ashwani
Demo'd AdminUI prototype to Michael. Feedback:
- Viewers and owners are very limited for what customers want. Want others in addition to read/write roles.
- Michael will send Use Cases for other roles and permissions
- Model for creating groups are in Volve user stories which has partitions for Volve N, Volve S, Volve share. See https://gitlab.opengroup.org/osdu/subcommittees/data-def/projects/data-prep/docs/-/blob/master/R3-Data-Loading_MVE-Ingestion-Testing_Rev-03.docx
----------------------------------------------------------------------------------
**Data Ingestion user stories and APIs
Dec 11, 2020 7am Houston**
**Attendees:**
**Stephen Whitley**, Chris, Swetha, Osho, Ashwani
Demo'd AdminUI prototype to Stephen. Feedback:
Critical path would be to 1) have an Admin role on the entitlement service; 2) start adding permissions to legal services
Note - someone from the CSP has to provide access
Discussed User Stories:
- I need to get the status of data ingestion (API exists)
- I need to have detailed monitoring during ingestion workflow - API doesn't exist
- I need to load data with manifests - API exists
- I need to load data without manifests - API exists
- I need to search for data - Query payload should have Kind (API exists) and query parameters
- I need to search for data - Query payload should allow for wildcard values in the search
-------------------------------------------------------------------------------------------------
**E&O user stories and APIs
Dec 10, 2020 9am Houston**
**Attendees:**
**Hrvoje Markovic**, Chris, Sourabh, Anshu, Swetha, Osho, Ashwani
Ashwani demo'd the Admin UI for Hrvoje
Team asked about group names. Feedback from Hrvoje:
- Group name is more of a convention, so no API is available for group.
- You can create any group name and embed into either the application logic for dropdown or use a text box
- Be able to add groups, then use the add member API to add a group to another group
------------------------------------
**AWS Admin UI Status
Dec 9, 2020 9am Houston**
**Attendees:**
**Paco Hope, Joe Nieten**, Chris, Sourabh, Anshu, Swetha, Osho, Ashwani
Joe worked with the team to ensure everyone is provisioned and can see the AWS test environment.
Team should now have:
- access to CI/CD
- Code commit capability
- access to AWS code in GitLab
- access to R3 code
- development capabilities
Raj was unable to attend. We will follow up with him on getting User Stories
Team needs a better understanding of Cognito for bearer tokens. Joe will provide a bootcamp for this
**Action Items:**
Joe: Set up Cognito bootcamp this week. **Done - scheduled for Friday AM**
----------------------------------------------------------------------------------------------
**Admin UI Status
Dec 9, 2020 8am Houston**
**Attendees:**
**Paco Hope**, Chris, Sourabh, Anshu, Swetha, Osho, Ashwani
Demo'd work on E&O module and Legal tags in the UI screen using GCP test environment.
- Two user IDs were provided to the team: a Writer ID and a Reader ID
- Manage Users - calls to APIs to create and delete
- Manage Groups - calls to APIs to create and delete groups
Positive feedback from Paco, with the following recommendations/requirements
- Client ID / User ID discussions. We should only need User ID bearer tokens because the user is directly interacting with the UI. Anshu and Paco to follow up with each other.
- Need to have a markdown file showing origin of images with proof that they are royalty-free images.
- Left justify columns instead of centering.
- Instead of having text display when hovering over an icon, just add the text below the icon.
- Keep track of things we can't do because it doesn't exist in existing APIs, such as edit functions or paginate capabilities.
- Use ISO country codes with just the countries we need. Don't have a dropdown of all countries.
- Make sure we have abstractions to allow for localization, such as adding another language.
- Make sure to keep in mind accessibility of screen for all users, especially users with disabilities that prevent or challenge the use of MFA or mouse movement, etc.
**Action items:**
- [ ] Anshu - share detailed steps used for Client ID to Paco and work on using User ID instead.
Ash and Osho - update other recommendations made by Paco **Done**
-------------------------------------------------------------------------------------
**Admin UI Status
Dec 7, 2020 9am Houston**
**Attendees:**
**Paco Hope**, Chris, Sourabh, Anshu, Swetha, Osho, Ashwani
- Revisited last week's architecture discussions and refining clarification on a key decision:
**_The Admin UI application will be included with OSDU, but using it is optional._**
- Continuing issue with the team not having access to all test / preshipping environments. Paco will follow up. (Team currently only has partial access to GCP)
- Discussed Raj's approach for initial Admin UI delivery: Demonstrate the ability to create/update legal tags for Compliance API. This will show how the UI works, use CI/CD deployment, have a code base. Next steps are to make calls to the Entitlements API.
- Recommends creating an Admin UI channel in Slack
**Action items:**
- Chris - contact Meena to create Admin UI channel in Slack - **Done**
- Sourabh/Chris: Provide Paco status on access to the CSPs - **Done**
- Paco: Contact CSPs that still need to provide the team access to their test / preshipping environments. **Done**
-------------------------------------------------------------------------------
**Admin UI requirements for System Configuration
Dec 7, 2020 7:30am Houston**
Attendees: **Raj Kannan**, Chris, Sourabh, Anshu, Swetha, Osho, Ashwani.
**Raj’s comments:**
- We should prioritize on true authorization and administration functionality first, followed by runtime System configuration, then deployment time system configuration.
- Important links shared by Raj on basis API requirement:
1. https://community.opengroup.org/osdu/platform/security-and-compliance
1. https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements-gcp/-/blob/master/docs/EntitlementsFlowCharts.vsdx
1. https://community.opengroup.org/osdu/platform/security-and-compliance/legal
1. https://community.opengroup.org/osdu/platform/security-and-compliance/legal/-/blob/master/docs/api/compliance_openapi.yaml
1. https://community.opengroup.org/osdu/platform/security-and-compliance
1. https://community.opengroup.org/osdu/platform/system/schema-service
1. https://community.opengroup.org/osdu/platform/system/schema-service/-/blob/master/docs/api/schema.yaml
1. https://community.opengroup.org/osdu/platform/system/storage/-/pipelines/17105
- Raj suggests starting with Compliance (it is developed in manner which is completely common among all cloud providers) to define legal tags. Followed by Schema management, entitlement management, data management, etc.
- Raj gave few ideas on how the UI should look like. He suggests adding prepopulated drop downs, a form where in you can fill in additional data which is required for an API in order to create a tag. And once the tag is created a user should be able to group and sort the data accordingly.
**Action Item:**
- [ ] Contact Dania for more detail on System Configuration on Azure.
-------------------------------------------------------------------
**OSDU Admin UI user stories discussion
Dec 4, 2020, Dec 7, 2020**
Attendees: **Philip Jong**, Chris, Sourabh, Anshu, Swetha, Osho, Ashwani.
- Discussed with Philip on various user stories for System Administrator, System Operator, Data Manager, etc.
- Philip agreed that as part of Entitlements & Obligations, first time when someone is setting up the system there needs to be a super administrator who decides who has to be the administrator for each module or owners for each module. Then it’s up to the module owners to further setup the roles and groups for their members.
- Philip confirms that when a user login to OSDU Admin UI he/ she will be able to view all the 7 modules on the dashboard. But based on his/ her role and access the data which needs to be populated will be restricted.
- Configuration of System Dashboard is part of CSP functionality, development team is not part of that.
- Philip asked to contact Stephen and CSP team to get more details on System Operator module.
- Philip explained about Data Manager module, he explained in detail about the difference between data loading and data ingestion.
- Philip asked to contact Michael Van Der to get details on API’s related to Data loading and data Ingestion.
- Philip explained in detail about Master data, Reference data and different examples of reference data, Quality Rules, etc.
- Philip explained about Marketing site which is a separate website.
URL : http://osduforum.org/
- Action Items that will be moved to backlog or as part of Phase 2 are:
- External Data Sources access configuration as API’s are not available for now and contact Jacob for further help on EDS.
- Configuration of System behaviours (e.g., the visibility of metadata if the actual data is protected).
- To access the application and service catalogue of the Marketing Site.
- Ability to purchase the application or service.
**Action Items:**
- [ ] Contact Greg Wibben and Joe for AWS pre-shipping environment for Postman API details for Data loading and data ingestion.
- [ ] Contact Raj Kannan for semantics of how search API works.
-------------------------------------------------------------------
**Admin UI Development Prep
Dec 4, 2020 7AM Houston**
Attendees: **Paco Hope, Stephen Whitley,** Chris, Sourabh, Anshu, Swetha, Osho, Ashwani I.
- Discussed with Paco and Stephen on getting access to dev instances among all cloud providers. Everyone acknowledged this is a showstopper now. Paco offered to escalate this with the CSP leadership (done)
- Paco & Stephen mentioned Admin UI app is not going to interact with Cloud IDP. We are just going to have a link (console link ). Upon click of the link, user will have to enter their credentials for the respective cloud provider and will get navigated to different page based on their access privileges.
- Paco summarized we are going to deploy the Admin UI on container on it’s own which is going to live outside the data platform boundary. And the Admin UI endpoints should be enabled for CORS policy which will be cloud specific.
**Action Item:**
Paco to send a mail across all cloud providers to get the development team access to dev instances of OSDU (**DONE**).
Anshu to update the requirement document and share with this core group. **Done**
-------------------------------------------------------------------
**Microsoft Cloud Provider
Dec 3, 2020 1:30 pm Houston time**
**Attendees:**
**Dania Kodeih,** Sourabh Roy, Chris McGinn
- Provided Dania with overview of AdminUI project
- Dania recommends starting with Legal tags first, followed by E&O
- Dania recommends prioritizing adding single users first. Bulk-add of users may be more difficult later, as will adding users to groups in a group heirarchy.
- MS team has been able to add a single users, which is a simple API call to the Entitlements API
- E&O MS team recently tried OID to push in UserID to the Entitlement Svc. This is very manual now because there is no interface to call an API for OID. From a coding perspective though, this is very simple on Azure.
- For R2, MS team has been using Azure AD to add user to IDP, that goes to the Entitlement service which subsequently makes a Postman call to push in the user.
**Next Steps:**
- [ ] Sourabh: Since he already has a relationship with the Infosys E&O team, he will reach out to them as we go forward with collaborating with Dania. **In progress**
- [ ] Sourabh: Provide list of people to add to Dania, if approved by Infosys E&O developers. **In progress**
---------------------------------------------------------------------------------
**Meeting: OSDU architecture for Admin UI
Dec 3, 2020; 9-10AM Houston time**
**Attendees:**
Ferris Argyle
Wladmir Fraazao, Paco Hope, Raj Kannan,Dania Kodeih, Kateryna Kurach,
Hrvoje Markovic,Dmitri Rudko,Jingdong Sun, Michaël van der Haven,Stephen Whitley, Chris McGinn, Sourabh Roy , Anshu Nachie, Swetha Anshu, Osho Gupta, Ash Ittuveetil
**Agenda Outline**
In order to deploy the OSDU AdminUI, the data platform needs to host static web assets (e.g., HTML, Images, CSS, JavaScript) which it has never had to do before. We need to agree on an architecture that will host static assets in a way that they can be used to deliver the Admin UI. A couple challenges are included here:
1. The actual architecture (is it a container with a nginx inside? Some serverless technology that varies per infrastructure provider?)
2. The web server needs to deliver via HTTPS, which means that TLS certificates and domain names come into play.
3. CORS headers need to be handled by the various API endpoints so that the AdminUI can make XHR requests to those endpoints. This is probably cloud-provider-specific.
4. This whole process has to be bundled into a reliable deployment mechanism in the appropriate CI/CD pipeline.
**Goal of this meeting:**
We need to agree on an architecture that will host static assets in a way that they can be used to deliver the Admin UI.
**Key Architecture Decisions Made**
- No architecture change related to the core OSDU Data Platform is needed
- The Admin UI will be a non-mandatory application distributed with, but deployed and operated independently of the Data Platform
- The Admin UI will not be part of OSDU certification
**Meeting minutes:**
Agenda Item 1:
The actual architecture (is it a container with a nginx inside? Some serverless technology that varies per infrastructure provider?)
- No architecture change related to the core OSDU Data Platform is needed
- The Admin UI will be an application distributed with, but deployed and operated independently of the Data Platform, i.e., using the Admin UI will be optional.
- The Admin UI will not be part of OSDU certification
- All CSPs agreed to have Nginx inside container to run the Admin UI application
- It was agreed by everyone that developing the AdminUI application in Angular is the right approach
Agenda Item 2:
The web server needs to deliver via HTTPS which means that TLS certificates and domain names come into play.
- The AdminUI application is a client of OSDU and the web server will have 2 pieces: one is client side code (HTML) and the other is something like Python or other code that deals with all of the heavy logic and type script and other things Angular brings along with it.
- The assumption has been that we’d have the assets (HTML, typescripts files, etc) all sitting behind a simple web server and the application runs in the browser space.
- The Core platform has to protect itself from the web server; it’s a point of vulnerability in the platform.
- Server side space is needed for caching
Agenda Item 3:
CORS headers need to be handled by the various API endpoints so that the AdminUI can make XHR requests to those endpoints. This is probably cloud-provider-specific.
- Anshu: How do we enable CORS? If the UI application is going to sit outside of the core platform, we have to come up with the nomenclature of when it gets deployed because of the URL and the host that comes with it. Further discussion may be needed. (see Next Steps below)
- For Postman in non-browser environment, this is not an issue.
Agenda Item 4:
This whole process has to be bundled into a reliable deployment mechanism in the appropriate CI/CD pipeline.
- The application sits outside of the OSDU services and will be deployed independent of the OSDU Data Platform
- This is an application available as part of distribution. Because it’s part of open source, people can download, deploy it, etc. if they choose to do so.
- In scope is OSDU APIs, common code, application code, CSP-dependent aspects needing CICD pipelines to deploy
- Right now, the barrier to entry and getting this platform and actually using it is high for someone who doesn’t use Postman. This will be an application that provides a simple UI for people who are non-Postman literate.
- Portability of the application is important for the customers we’re deploying to, who are at multiple locations.
**Next Steps:**
- AdminUI team will need access to each CSP test environment
- AdminUI team will work with CSPs to get cloud-specific configurations
- AdminUI team and CSPs need to share endpoint URLs for CORS configuration
--------------------------------------------------------------
**E&O Requirements (Kerry Blinston)
Dec 3, 2020; 8 AM Houston time**
Attendees: **Kerry Blinston**, Sourabh Roy, Chris McGinn, Anshu, Swetha, Osho, Ashwani I.
Sourabh provided overview of Admin UI project.
**Kerry’s comments:**
- Should be able to define and manage rules and those rules set within the policy engine based on OPA. But not sure if the backend functionalities should define these rules or if a user interface is required for that.
- Currently there is a set of rules available in the Incubator which is been implemented by Hrvoje and his team, and therefore there will be API’s exposed for these rules which can be consumed by development team to implement frontend layout for Admin UI.
- Some of the concern’s pointed out by Kerry:
1. How do you ensure that all of the attributes used by policies are available and updated and valid on an ingest perspective?
2. There is generation of new data within the platform itself and how is that we ingest it? If there is more than one data source, how do you resolve some of the attributes? What is the country of origin?
- The decision or comment made by Information Security is that Authentication happens outside OSDU platform, which means we do not want to store or maintain personal data within OSDU platform.
- The Admin user interface should have the ability to change rules and change entitlements which should be secured.
- Need to manage User information, such as nationality of user. The list of required [User attribute](https://gitlab.opengroup.org/osdu/subcommittees/data-def/work-products/schema/-/issues/110)s were provided to team
- Operators will need to administer their own roles for individual users and job role attributes such as grade, seniority in company, etc.
- Future considerations: How would a future admin create rules? Who is entitled to create a rule? And how will you decide who is entitled to create rules? Who maintains the list of allowed values for rules?
**Action Items:**
- [ ] Sourabh: Get in contact with Hrvoje, Mandy and other development team from Mumbai to get more details on use cases for rules.
- [ ] AdminUI team: Based on various admin requirements contact Infosys technical team (Mandy in Mumbai) how are they managing it so far and going forward, over all cloud providers?
---------------------------------------------------------------
**ADMIN UI Requirements
Dec 1, 2020**
Attendees: **Stephen Whitley**, Sourabh Roy, Chris McGinn, Anshu, Swetha, Osho, Ashwani I.
Reviewed Requirements, Design and Approach document and also gave a quick update on last week’s progress with Stephen. **Stephen’s feedback:**
- E&O API format supposed to be common among all cloud providers.
- For Data platform, Data Loading and Data Ingestion the API’s that are going to be handled by development team will have common data format (input/output) among all clouds.
- Information & Security module: Need to check on the data consistency among different cloud providers
- Audit and Metrics are going to be different for all Clouds because the APIs for these two modules are cloud provider specific (infrastructure dependent)
- Tags Associated with data is going to be handled in E&O module.
- Confirmed that Infosys's approach to map the user stories to the API information is the right direction. Once we have this information consolidated (based on inputs from all SMEs), as a group, we will collectively prioritize the list so we can freeze the scope for this engagement and also have a clear plan for the next phases of work
**Action items:**
- [Infosys] Need to confirm about data format consistency for each cloud provider in E&O and Information Security module.
- [Infosys] Infosys to connect with Raj (again) on the API information across all the modules
----------------------------------------------------------------------------
**User Portal Requirements
Dec 1, 2020**
Attendees: **Phillip Jong**, Sourabh Roy, Chris McGinn, Anshu, Swetha, Osho, Ashwani I.
Reviewed Requirements, Design and Approach document and also gave a quick update on last week’s progress to Philip. **Philip’s feedback:**
- User portal from an end user perspective is just a way to login to Admin UI page. Once a user logs-in they will be able to access any UI module/page
- Need a starting URL for OSDU Admin UI for an end user to login. This will enable the enable the user to navigate different modules that the user has access to
- Need a web server to deploy admin UI code. Follow-up discussion planned with key stakeholders - including CSP SMEs - on the architecture
- From an overarching vision standpoint, landing page of OSDU UI is expected to have additional functionalities in the future - including showcasing third party apps that an user may have access to. An icon should be available for each application that the user may have access to. However, the current scope for Infosys is limited to the Admin functionalities of the stated modules
- In OSDU there is no project concept, it is achieved by tags.
- Need to document all the new requirements in a new Wiki page; so we know the requirements (or can create a backlog) for next stages of this engagement
**Action items:**
- [Infosys] To discuss about web server concept and the architecture with all SME’s
- [Infosys] Document the User Portal concept (discussed above)
----------------------------------------------------------------------------
**GCP Access and Responsibilities
Nov 30, 2020**
Attendees: **Ferris Argyle (GCP)**, **Dmitry Rudko (EPAM)**, **Kateryna Kurach (EPAM)**,Sourabh Roy, Chris McGinn, Anshu, Swetha, Osho Gupta, Ashwani I.
Sourabh provided overview of Admin UI project.
Ferris comments:
- Delineation of roles
Admin UI team: Build UI app, containers, CI/CD deployment pipeline on GCP test environment, testing
GCP: provide APIs, assistance with CI/CD
- Expectation is code speaks to OSDU APIs
- CICD pipeline will user Kubernetes
- OSDU APIs shield client access to strage credentials
CSP common:
- UI and Application Code
CSP dependent aspects:
- CI/CD pipelines
- SSO / identity management
**Action Items:**
- Dmitry will provide ingestion APIs
Chris set up weekly meetings. Ferris is available Wed/Thur 9:30-10 CT **Done**
----------------------------------------------------------------------------
**Weekly Admin UI Progress
Nov 30, 2020**
Attendees: **Paco Hope**, Sourabh Roy, Chris McGinn, Anshu, Swetha, Osho Gupta, Ashwani I.
Sourabh gave a quick update on OSDU Admin UI progress. Paco’s feedback:
- Informed that UI and API information shouldn’t vary with each cloud provider.
- Expand the use cases for each module and get their API information.
- Document everything. Mention which API is available and which is not.
- In order to get information on Audit & Metrics module, Ash will help us with the point of contact.
- Gwenola Michaud will help us with more information on OSDU as Gwenola does end to end testing.
- Joe has been informed to give us the access to test environment.
**Action Items:**
- Who will be the resource to whitelist developers ip and port to access the API.
- To discuss proper Architecture for publishing the code (will schedule a meeting with Stephen Whitley, Dania(Microsoft),Ferris(GCP), Wlad(IBM)).
----------------------------------------------------------------------------
**E&O Requirements and APIs
Nov 25, 2020**
Attendees: **Hrvoje Markovic**, Anshu, Swetha, Osho, Ashwani I.
Reviewed Requirements, Design and Approach document. Hrvoje's feedback:
- Check for information about the incubator
- Get access to, and review all policy services
Hrvoje provided links for information on APIs:
- https://community.opengroup.org/osdu/documentation/-/blob/master/platform/api/Entitlements-Service.swagger
- https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/wikis/Design
- https://community.opengroup.org/osdu/documentation/-/wikis/Releases/R2.0/Services/Entitlements/Tutorial
- https://community.opengroup.org/osdu/platform/security-and-compliance/legal/-/blob/master/docs/api/compliance_openapi.yaml
A few use cases were identified:
- Get a list of all groups
- Get a list of all groups that a user belongs to
- Add members to a group
**Action items:**
Set up meetings with CSPs for access to OSDU (Chris) **Done**
- Flesh out E&O user stories and provide API information (Hrvoje)
----------------------------------------------------------------------------
**Weekly AdminUI Progress
Nov 25, 2020**
Attendees: **Paco Hope**, Sourabh Roy, Anshu, Swetha, Osho, Ashwani I.
Reviewed Requirements, Design and Approach document. Paco's feedback:
- In 2nd diagram, move the cloud bubbles to the far right, connecting to the data platform
- Add a table of each function and associated API, if the API exists
Action items:
Chris : Follow up with Joe on access to dev environment **Done**
----------------------------------------------------------------------------
**Data Loading Requirements and APIs
Nov 16, 2020**
Attendees: **Michael van der Haven (Data Loading)**, Sourabh Roy, Anshu, Swetha, Osho, Ashwani I.
Initial meeting with Michael van der Haven
- Team relayed scope of Admin UI project for Michael
- Recommended reaching out to Dmitri for list of APIs
Team was provided a few user stories for Data Loading
- Roles for access based on specific regions
- Need role for loading Master data
- Need role for loading Reference data
- Need role for loading Work data
- Need role for user that can create data
- Need role for users that can update data
- Need role for users that can load but are not allowed to see data