Components

  1. Postgres database operations
    • WHAT: basic operations to create, retrieve, update, and delete records, and make it easier to find related records.
      • fluid component wrapping basic data base queries, that are somewhat biased by the data models supported (see "Implement Data Model" below).
    • STATUS: mostly done.
    • TODO: want to explore the Postgres' foreign keys ability to link records together
      • There are references among different types of records in the data model e.g, a CloudCredentials record references and PrefsSafes record via its prefsSafesId field/column
      • The technique to use one record to find another is the same as used in GPII:
        1. given the ID of a CloudCredentials record, fetch that record,
        2. find the prefsSafesId field and retrieve its value
        3. fetch the PrefsSafes record given the identifier.
        4. ...
      • Would be nice if the database itself did this lookup/retrieval via "foreign key", where the prefsSafesId in a CloudCredentials record is postgres-declared as the reference to the assorciated PrefsSafes record, and the correct postgres-query-statement is issued.
  2. Implement Data Model records in the database
    • WHAT: fluid component that uses the Postgres operations component described above, but specifically to create and manage the records defined in the data model.
    • STATUS: in progress, draft pull request: https://github.com/fluid-project/preferencesServer/pull/6
      • the above PR includes the work for 1. "Postgres database operations" above.
    • TODO:
      • the data model itself has a number of "to-dos" that need to be resolved.  See the "Todo List".
      • the data model is heavily dependent on the OAuth2 component (see next item below), and work on that is currently feeding back into this layer.
        • most of the record types in the data model have to do with the OAuth2 machinery
  3. Implement OAuth2 server
    • WHAT: fluid components and utilities that act as a shield allowing only authorized access to the database.
    • STATUS: in progress; most of the current effort is here, and is tracked on github: https://github.com/klown/preferencesServer/tree/oauth2
    • TODO:
      • this is a port of the OAuth2 server code from GPII.
      • involves disentangling that code from the Flowmanager, and any other components of the GPII.
      • convert to postgres – GPII used CouchDB, so there is some conversion here in terms of database access.
      • continue to learn the OAuth2 spec to get a better grasp of OAuth2 and how it works.
  4. Preferences Server itself
    • WHAT: API (endpoints) and their handlers
      • the public facing part of the whole endeavour
    • STATUS: waiting for the other tasks to finish, although some work on defining the endpoints has been done.
    • TODO:
      • define the endpoints and their structure, see github issue GH-5
      • determine how to deploy, and implement
        • possibility:  two docker containers, one for the database, and one for everything else, deployed on AWS, GCP, or Azure
          • if so, will need deployment implementation involving Kubernetes, rakefiles, book-keeping scripts (e.g, flushtokens), others?

Meeting 27-Jan-2021

  • Justin, Jonathan, Joseph
  • Consider wrapping part 1-3 with fluid DataSource.
    • Post-meeting: (JS) the preferences server, part 4., will likely be a kettle app.  Check where DataSource objects come into play with kettle.request.http.
  • No labels