On Wed, Sep 7, 2016 at 11:05 PM, Casey Bodley <cbodley@xxxxxxxxxx> wrote: > Some specific requirements that I recall from our past discussions include: > > - don't heap allocate auth state per request Great. I understood that we don't need to optimize the early run-time (setup, initialization) to eradicate dynamic allocations. This would allow to make the things easier to read through skipping some crazy CRTP/SFINAE stuff. > - don't construct or call into AuthEngines that shouldn't be enabled for the > given handler This sounds like a step further in comparison with the current solution. In the past we had a lot of "ifs" executed per request. Currently, the logic is split into per-engine pieces and encapsulated in is_applicable method of AuthEngines. In my understanding the goal is to introduce init-time preselection. However, we need to discuss dealing with run-time config changes (operator injecting new configuration without restart). Do we want to cover this use case at all? > I'll add some of the other refactoring goals we've discussed, but I don't > think they place any strict requirements on the auth subsystem: > > - RGWHandler: being able to reuse handler instances, instead of allocating a > new one for each request At the moment RGWHandler is dynamically allocated on each request. Do we plan to remove only the allocations or go even further and make handlers entirely state-less? > - req_state: contains too many unrelated fields, some of which are > transformed in confusing ways over the lifetime of the request. needs to be > broken up into smaller, better encapsulated sub-objects I'm 100% behind that. > - concurrency: move away from a synchronous process_request() to build on > asio frontend work Sound really interesting. Let me propose another requirement: - critical components should facilitate unit testing. In the future they should be covered by reasonable set of unit tests. What do you think? Regards, Radek -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
