Devstack, Cinder, Nova versus memcached
Hello:
We all know how Cinder and Nova use memcached to save Keystone tokens (technically, authtoken middleware does it for them). That is expected. However, devstack leaves a config for Cinder that looks like this:
[nova] region_name = RegionOne memcached_servers = localhost:11211
Does anyone remember how that is used? I looked at Cinder and python-novaclient, and neither use memcached for anything there.
Thanks in advance, -- Pete
Hello Pete,
The auth_token middleware is responsible for generating and validating these tokens using a shared secret key. The middleware also caches these tokens in memory so that they can be reused by other services without contacting Keystone again.
The memcached_servers config option can be set in different places depending on the OpenStack service. For example, for nova, it can be set in the [nova] section of the devstack configuration file.
For Cinder, it can be set in the [cinder] section of the devstack configuration file.. However, this option does not affect how Cinder or Nova use memcached internally. They still rely on authtoken middleware to handle authentication and authorization
I hope it helps your question.
Kerem ÇELİKER Head of Cloud Architecture linkedin.com/in/keremceliker/
On Tue, 19 Dec 2023 17:04:53 -0000 "KEREM CELIKER" kmceliker@gmail.com wrote:
The memcached_servers config option can be set in different places depending on the OpenStack service. For example, for nova, it can be set in the [nova] section of the devstack configuration file.
In this case, I'm talking about /etc/cinder/cinder.conf. Why does Devstack put memcached_servers in [nova] section of it?
I hope it helps your question.
Unfortunately, it does not help. I'm looking for the piece of code that makes use of that configuration, if such code exists.
Greetings, -- Pete
On Tue, 2023-12-19 at 14:37 -0600, Pete Zaitcev wrote:
On Tue, 19 Dec 2023 17:04:53 -0000 "KEREM CELIKER" kmceliker@gmail.com wrote:
The memcached_servers config option can be set in different places depending on the OpenStack service. For example, for nova, it can be set in the [nova] section of the devstack configuration file.
its being set as a sideffect fo this call
https://github.com/openstack/devstack/blob/6b0f055b4ed407f8a190f768d0e654235...
configure_keystone_authtoken_middleware which is not correct. the content of both are similar but not the same.
https://github.com/openstack/devstack/commit/c04ac03e21546a3d25a2b6794802c49... intoduced this behavior 6 years ago.
based on https://docs.openstack.org/cinder/latest/configuration/block-storage/samples...
cinder does nto use the memcache servers option form that section so its currently being ignored.
In this case, I'm talking about /etc/cinder/cinder.conf. Why does Devstack put memcached_servers in [nova] section of it?
I hope it helps your question.
Unfortunately, it does not help. I'm looking for the piece of code that makes use of that configuration, if such code exists.
there is none the nova section in cinder is defiend here https://github.com/openstack/cinder/blob/master/cinder/compute/nova.py#L35-L...
Greetings, -- Pete
Pete,
If you can explain what you kindly provide better, I or our older friends can help you. Since it is very general in this way, we can give you examples with different solutions.
Please elaborate a bit more and what exactly do you want to do and what is your goal?
Thanks, Kerem ÇELİKER
On Tue, 19 Dec 2023 21:08:51 -0000 "KEREM CELIKER" kmceliker@gmail.com wrote:
Please elaborate a bit more and what exactly do you want to do and what is your goal?
I need to ensure that aceess to memcached is authenticated.
And, while we're at it, maybe clean up some of the unnecessary cruft in devstack.
-- Pete
On Wed, 2023-12-20 at 13:37 -0600, Pete Zaitcev wrote:
On Tue, 19 Dec 2023 21:08:51 -0000 "KEREM CELIKER" kmceliker@gmail.com wrote:
Please elaborate a bit more and what exactly do you want to do and what is your goal?
I need to ensure that aceess to memcached is authenticated.
And, while we're at it, maybe clean up some of the unnecessary cruft in devstack.
it woudl proably be better to take a step back then and come up with a design propsoal and talks to teh qa team about your objectives. i dont think devstack uses spec but tis would be better to define the exact set of goals and agree with the maintianers if its in scope before trying to make large changes.
-- Pete
On Wed, 20 Dec 2023 19:57:39 +0000 smooney@redhat.com wrote:
it woudl proably be better to take a step back then and come up with a design propsoal and talks to teh qa team about your objectives. i dont think devstack uses spec but tis would be better to define the exact set of goals and agree with the maintianers if its in scope before trying to make large changes.
Honestly I hoped just to sprinkle a few reviews. Rolling a whole spec just to add a couple of new fields for credentials is going to create a whole lot of delay. You know how slow they go in.
You are right, of course, but what a drag.
-- P
On Wed, 2023-12-20 at 16:47 -0600, Pete Zaitcev wrote:
On Wed, 20 Dec 2023 19:57:39 +0000 smooney@redhat.com wrote:
it woudl proably be better to take a step back then and come up with a design propsoal and talks to teh qa team about your objectives. i dont think devstack uses spec but tis would be better to define the exact set of goals and agree with the maintianers if its in scope before trying to make large changes.
Honestly I hoped just to sprinkle a few reviews. Rolling a whole spec just to add a couple of new fields for credentials is going to create a whole lot of delay. You know how slow they go in.
You are right, of course, but what a drag.
you dont nessiarly need a spec. you just need to socialise the aim with the peopel that have review rights so that they are aware of the work your doing and why. that will help them recommend how to do it correctly and speed up the review process.
part of the reason that reviews linger sometimes is that we dont know why someone has proposed it or even that they have propsed it. so grouping a set of related changes into a gerrit topic and then reaching out on irc to the maintaienr or starting a email thread similar to this but where you lay out the problem description and why you want to chagne it can help land your code much faster.
devstack is a developmet tool so while there is no direct need to have authenticated memcache access as it is not for use in production there is no reason not to if its simple to enable across all distos that are supported and can be used to test that functionaltiy in oslo.cache for example. if that your over all goal, ensuring that openstack can correcctly use memcahce with auth enabled then enhancing devstack to support that make sense to me.
-- P
participants (3)
-
KEREM CELIKER
-
Pete Zaitcev
-
smooney＠redhat.com