Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev