more notes

debian.org

@@ -0,0 +1,10 @@
+#+TITLE: Debian
+
+
+* Moving to Unstable
+  Helpful links:
+  - https://wiki.debian.org/DebianUnstable#What_are_some_best_practices_for_testing.2Fsid_users.3F
+  - https://wiki.debian.org/DebianTesting
+  - https://wiki.debian.org/DebianUnstable
+  - https://wiki.debian.org/DontBreakDebian
+  - https://linuxconfig.org/how-to-run-debian-sid-relatively-safely

notes.org

@@ -26,3 +26,4 @@ Cluster api - failed provision
 
    check on rescue and reinstall operations
 ** TODO Create a ticket to deal with 403s for provisioning failures
+** TODO Talk to Laurence about self service reservations

notes.org_archive

@@ -253,3 +253,93 @@ Results [[file:capacity_levels_pricing.csv][capacity_levels_pricing.csv]]
 :ARCHIVE_CATEGORY: notes
 :ARCHIVE_TODO: DONE
 :END:
+
+* DONE Talk about interfaces OU in graphql
+:PROPERTIES:
+:ARCHIVE_TIME: 2023-05-19 Fri 13:27
+:ARCHIVE_FILE: ~/notes/org-notes/notes.org
+:ARCHIVE_OLPATH: Tasks
+:ARCHIVE_CATEGORY: notes
+:ARCHIVE_TODO: DONE
+:END:
+
+- when you define a io, that subgraph can't implement that interface
+- create EM project type, that also implements Resource owner
+- it can have a EM organization, and that org can have the ID
+- opts:
+  - Provides graph for projects and orgs
+  - Or
+
+
+Problem statement:
+
+We need a way to expose metal orgs/projects to the infratographer
+supergraph, because graph queries will need to resolve Metal project
+IDs as part of their request.
+
+Discussion
+
+We originally had planned that we'd replicate the state of
+orgs/projects up to the tenant-api, but after the graph changes we may
+not want to do that. This is a use case where we may want to implement
+our own graph API which serves up a Resource Owner.
+
+Currently tenant-api would expose a resource that impelements the
+Resource Owner interface. Instead of replicating the data up to the
+tenant-api, we can instead expose a graph API from the data within the
+monolith.
+
+Doing this means we don't have to lift the data out of the monolith
+directly, but instead just present it in a way that fits with the
+infratographer expectations.
+
+We would still need to emit events about operations which modify
+organizations/projects because those events are consumed by other
+services in the ecosystem to update their internal states.
+
+
+Options:
+
+1. Serve data from a shim service while reading from a replica of the
+  monolith DB
+2. Serve data from a shim service with it's own data store
+3. Serve data directly from the monolith with a graph interface
+4. Migrate Org/Project data completely out of the monolith and expose
+  an interface.
+
+Option 4 is the heaviest option, and may be the ultimate goal, but it
+comes with high risk and is not quick to implement since every feature
+relates back to organizations and projects on some level.
+
+Option 3 would be much simpler, but doesn't move toward the goal of
+carving out functionality of the monolith
+
+Option 2 starts to split out data, but still requires us to lift data
+out of the monolith and keep it consistent for the time being
+
+Option 1,creates a dedicated service for the infratographer graph
+integration, which achieves the goal of presenting an interface to
+satisfy the graphQL interfaces, while still giving us a stepping stone
+to start carving data out of the monolith.
+
+** References:
+
+[[https://gist.github.com/jnschaeffer/1217a7a597f7cdab0c91493a994ed615#file-tenancy-org][tenancy gist]]
+
+* DONE Discuss tenantID vs projectID with John
+:PROPERTIES:
+:ARCHIVE_TIME: 2023-05-19 Fri 13:27
+:ARCHIVE_FILE: ~/notes/org-notes/notes.org
+:ARCHIVE_OLPATH: Tasks
+:ARCHIVE_CATEGORY: notes
+:ARCHIVE_TODO: DONE
+:END:
+
+GraphQL - implementation specific
+
+GraphQL
+- resolvers for every type
+- apollo supergraph does the mapping from resource type to service
+- interface - set of required fields
+- __type determines resource type
+- nanoid thing ent node