Excerpts from corvus's message of 2017-06-09 09:41:37 -0700: > Monty Taylor <[email protected]> writes: > > > We should use aiohttp with no extra REST framework. > > > > Meaning: > > > > - aiohttp serving REST and websocket streaming in a scale-out tier > > - talking RPC to the scheduler over gear or zk > > - possible in-process aiohttp endpoints for k8s style health endpoints > > ... > > > Since we're starting fresh, I like the idea of a single API service > > that RPCs to zuul and nodepool, so I like the idea of using ZK for the > > RPC layer. BUT - using gear and adding just gear worker threads back > > to nodepol wouldn't be super-terrible maybe. > > Thanks for the thoughtful analysis. I think your argument is compelling > and I generally like the approach you suggest. > > On the RPC front, how about we accept that, for the moment, the > webserver will need to consult ZK for collecting some information > (current nodepool label/image status), and use gear for other things > (querying zuul about build status)? > > The rest of Zuul already uses both things, let's just have the webserver > do the same. Eventually gear functions will be replaced with ZK. >
Your words are more succinct than what I wrote, which is nice. I think we agree on the general direction for the time being. However, I don't think ZK will be a good choice for async event handling. I'd sooner expect MQTT to replace gear for that. It's worth noting that MQTT's protocol shares a lot in common with gearman and was created to do similar things. _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
