On Fri, Mar 6, 2015, at 06:35 PM, xiaoyuan wrote: > Hi everyone, > > I am Xiaoyuan Lu, a recipient oftheHP Helion OpenStack scholarship, and > ElizabethK. Josephis my mentor from HP. I would like to work on projects > related to Keystone. Considering the amount of work and tiime limit, > after going through the Keystone specs, finally we decided to work on > "oslo-cache-using-dogpile".[0] > > At the Oslo meeting this week, I met with the Oslo team and we > identified the need to add some ideas for what the library API might > need to include with regard to the Oslo Cache Updated to use > dogpile.cache spec. > > Can we get some feedback to help flesh this out? > > [0]http://specs.openstack.org/openstack/oslo-specs/specs/kilo/oslo-cache-using-dogpile.html
Looking at the documentation for the backends in the dogpile.cache docs [1], I see that each backend driver may take different arguments. Some of those values, like the URL to the memcached server, could become configuration options defined in oslo.cache. So one thing you could start with is figuring out a reasonable starting list of those configuration options. We won't need every single option, just some of the basics to start with. Then we need to decide what an API in oslo.cache that uses those configuration options might look like. For example, there are places in keystone where someone might want a "memory" cache and other places where they might want a "persistent" cache. So we might have 2 functions in oslo.cache with names like get_memory_cache_region() and get_persistent_cache_region(). Those could be implemented as thin wrappers around dogpile.cache.make_region(), calling it with the appropriate arguments taken from the configuration options. They would return the region, and then the application developer would use it directly. I haven't thought much about how many different versions of those functions we need, though. We don't want one for each dogpile backend, because we don't necessarily need to support each backend. And we don't need multiple versions of the function for the persistent storage, so how does the deployer (not the application developer) pick which persistent storage mechanism to use? And do we need different memory configurations, too? Probably, for devstack, but maybe not. If you start by adding details like this to the existing spec, the rest of the team can help work out missing details and make suggestions to keep the oslo.cache API consistent with some of the other Oslo libraries. Doug [1] http://dogpilecache.readthedocs.org/en/latest/api.html#module-dogpile.cache.backends.memory > > -- > Xiaoyuan Lu > Computer Science M.S. > UC Santa Cruz > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev