mistercrunch commented on PR #36368:
URL: https://github.com/apache/superset/pull/36368#issuecomment-3831661093

   > On the topic of feature flagging and migrating all tasks with a config
   
   Seems we need a way for people to opt-in/opt-out and test during some sort 
of progressive rollout. The question here is whether rollout is hard-coded or 
whether each environment can decide what's using GTF or not. In this case, it 
feels to me like evidence of the framework working in some environments doesn't 
guarantee it'll work in all others, main variables here might be scale/QPS and 
what metadata database engine they use (MySQL/Postgres), how it's configured 
(innodb vs lower level of transaction isolation), and database CPU headroom 
(can I afford the extra db overhead right now?).
   
   If each new future version has more and more traffic going through GTF, it 
might be hard for operators to keep track of what's happening and plan/test 
accordingly. Like "I want the latest SHA but don't want the GTF implications 
that come with it right now".
   
   If we have everything going through the framework with config flags 
(determining which async event goes through the db), operators more could 
easily run tests/validations: "ok I'm going to test whether it works with a set 
of low-traffic events" or "ok now I'm going to test whether things still work 
after routing all events through the framework" without touching code.
   
   ---
   
   Anyhow, seems we need config flags to properly test/rollout this feature, at 
the very least some sort of kill switch, but having more control (a list of 
events that should go through the db for instance), makes it easier for 
operators to test/validate/rollout. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to