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
