This commit is contained in:
Correl Roush 2022-01-31 20:55:25 -05:00
parent 8025d5e738
commit c6ec0dd4b0
9 changed files with 137 additions and 25 deletions

View file

@ -54,3 +54,4 @@ program correctness.
- [[https://www.python.org/dev/peps/pep-0640/][PEP 640 -- Unused variable syntax]]
- [[https://www.python.org/dev/peps/pep-0646/][PEP 646 -- Variadic Generics]]
- [[https://www.python.org/dev/peps/pep-0647/][PEP 647 -- User-Defined Type Guards]]
- [[https://www.python.org/dev/peps/pep-0654/][PEP 654 -- Exception Groups and except*]]

View file

@ -4,7 +4,7 @@
#+title: Migration to common RabbitMQ
All services and consumers pointed at the legacy RabbitMQ cluster in
Conshohocken should be migrated to the new common-rabbitmq cluster.
Conshohocken should be migrated to the new common-rabbitmq cluster as a [[id:db322997-ff5e-416a-8dc8-f29e6a4928c8][Technical Initiative]].
The new servers are available at
=common-rabbitmq.service.${ENVIRONMENT}.consul=.

View file

@ -3,6 +3,70 @@
:END:
#+title: Technical Initiative
* Active
- [[id:193f7c04-0a03-4870-90c8-2b5e3c4c92ce][Moving pages out of Sites]]
- [[id:b4f579f7-f848-4a7b-b7bc-f34fec36346a][Cleaning up public endpoints in proxy services]]
- [[https://confluence.aweber.io/display/~scottm/CP+Technical+Work+Brainstorming][2022 Brainstorming Document]]
- [[https://confluence.aweber.io/display/TCP/2022+Q1+CP+Priorities][2022 Q1 CP Priorities]]
- [[id:193f7c04-0a03-4870-90c8-2b5e3c4c92ce][Moving pages out of Sites]]
* Big
** Analytics View
- Coordinate on public URL structure with Dave S.
- Update dashboard and reports to use new endpoints as they're made available.
** [[id:11edd6c9-b976-403b-a419-b5542ddedaae][Subscriber Search Service]]
*** Store and paginate search results
:PROPERTIES:
:JIRA_ID: CCPANEL-7148
:END:
*** Rebuild Subscriber Management in React
:PROPERTIES:
:JIRA_ID: CCPANEL-11697
:END:
** Verifications
*** Updating the existing verification flow to use email-verifications
:PROPERTIES:
:JIRA_ID: CCPANEL-9416
:END:
*** Decommission Verifications
** Domain Validator
:PROPERTIES:
:JIRA_ID: CCPANEL-10554
:END:
** [[id:619b6c78-7be9-4ee4-a0b7-9d1a4d7536e2][Migrating services to use the new List service]]
*** Audit remaining services
*** Rebuild List Management in React
*** Rebuild List Settings in React
:PROPERTIES:
:JIRA_ID: CCPANEL-11694
:END:
*** Remove dependency on AWLists from Subscriber Import
** Retire AWSubscribers in favor of Recipient
*** Back Recipient with AppDB
*** Retire sync consumers
*** Identify gaps between AWSubs and Recipient
Determine which endpoints need to have analogs in Recipient or could be replaced
with calls to other, more appropriate services.
*** Look into folding in edeliv's bulk subscriber service
** [[id:03e00c18-99c0-477c-b7fb-95ddc538755e][Addlead]] Python rewrite
https://jira.aweber.io/browse/TRAC-118
- Find / Build a test suite that can be run against old and new addlead?
- WHAT DOES IT DO?! https://jira.aweber.io/browse/CCPANEL-7614
- ACP? https://jira.aweber.io/browse/CCPANEL-7613
** Enlightener rewrite
- Investigate how to rebuild this
** Sites login / session management
- Should advocate users be migrated to user management?
*** Separate from the rest of the CP
** Advocate CP
*** Python service + react application
** Verify Opt-in Python rewrite
** Unsubscribe Python rewrite
** [[id:b4f579f7-f848-4a7b-b7bc-f34fec36346a][Cleaning up public endpoints in proxy services]]
* Small
** [[id:af4ae6ee-5201-49ee-aa01-6cf6a0801908][Migrating AWS services]]
** [[id:96d1d218-60cd-41d9-91ba-48359137d239][Decommission the mail-relay service]]
** KTLO
- User Management
- Stripe Payments
- Commissions Processor

View file

@ -6,24 +6,4 @@
A [[id:db322997-ff5e-416a-8dc8-f29e6a4928c8][Technical Initiative]] to move endpoints exposed in "proxy" services into more
relevant services and instead expose them via Kong.
* Proxy Services
** subscriber-proxy
*** TODO =/<subscriber_id>=
*** TODO =/batch_delete=
*** TODO =/batch_tag=
*** TODO =/batch_unsubscribe=
*** TODO =/bulk-tagging/jobs=
*** TODO =/bulk-tagging/jobs/<id>=
** search-proxy
** tagging-proxy
** search-recipients
Endpoints have been consolidated into Search Proxy.

View file

@ -10,3 +10,7 @@ which could theoretically be deployed to our local Kubernetes cluster or to EKS.
We currently maintain two separate sets of clusters in AWS. Services should be
migrated to the new cluster, or to kubernetes, ideally.
- [[id:7e503917-646f-4275-aab9-3a125b99cbfd][Tagging Service]]
- Mapping
- Recipient

View file

@ -175,6 +175,18 @@ dedicated service, eliminating multiple search implementations.
*** Update broadcast-segment to use new search service
** Milestone 3: Add new search features
* Implementation
** [[id:7b0f97f3-9037-4d05-9170-a478e97c8d1f][Modeling the new search DSL]]
** Constructing SQL queries programmatically
** Translating legacy segments
** Gathering results
** Reaching into Analytics
* Resources
- [[https://confluence.aweber.io/display/AR/PostgreSQL+Backed+Search][PostgreSQL Backed Search]] (Rejected ACP)
- [[https://confluence.aweber.io/display/AR/Search+Proxy+Service][Search Proxy Service]]

View file

@ -0,0 +1,5 @@
:PROPERTIES:
:ID: 46515cfd-3e6c-46ac-a8f7-7fc722141338
:END:
#+title: Retire CAPI

View file

@ -0,0 +1,8 @@
:PROPERTIES:
:ID: 96d1d218-60cd-41d9-91ba-48359137d239
:END:
#+title: Decommission the mail-relay service
- https://jira.aweber.io/browse/CCPANEL-10580
Tackle remaining legacy emails and retire the mail relay container.

38
daily/2022-01-28.org Normal file
View file

@ -0,0 +1,38 @@
:PROPERTIES:
:ID: c1793364-997f-4ea8-917b-02f1ee2a6ddd
:END:
#+title: 2022-01-28
* Discuss Analytics View endpoint URLs
Discussion with Dave S. and Eric T. on how we will expose the [[id:c45881de-46f2-4f76-9579-063626c5956c][Analytics View
Service]] report endpoints as Public API URLs.
- Fields should be mapped to their PublicAPI standardized names
- Dave is documenting Public API naming conventions
- Should other entities be referenced by IDs or links?
- Perhaps both, for front-end URL building and for further API lookups
- Some
- Dave suggests returning a response data structure with attached entries rather
than a plain array to include additional metadata
- Should the total set of available reports be discoverable via the API?
- It's not planned currently, but would make sense to do at some point in the
future
- Watch out for pagination issues with dictionary object collections
- Are there discrete event IDs?
- Does a completed broadcast have an ID beyond the broadcast ID?
- What kind of URL pathing do we want to aim for?
- List-level reports under Lists
- Account level reports under Accounts
- If optionally filterable by list, might make sense to serve it under both
paths
- Having the analytics database cache external to the service could help with
large concurrent requests across service instances
- Broadcasts opens and clicks can be a performance pitfalls, see how Public API
campaigns implements opens and clicks in an efficient manner
- Be clear on endpoint result ordering
* Search service timeouts
Slow searches may run afoul of our nginx timeouts (See etsy-importer for
handling timeout expectations. Broadcasts also have issues with this.)