| *** mhen_ is now known as mhen | 01:19 | |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix wrong argument to determine identity endpoint https://review.opendev.org/c/openstack/oslo.limit/+/947902 | 04:53 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Remove unused adapter options https://review.opendev.org/c/openstack/oslo.limit/+/947903 | 05:19 |
| skraynev | @gtema: thank you for the answers. I was offline, so I read them recently. Regarding the first question (about domain token) I have not any questions - your answer totally covers my question. For the second question (about validation based on attributes) it's also about Neutron, Did I get right, that I could NOT validate resource attribute for modify operations ? as I understand it happens, because Neutron evaluate policy check befor | 05:19 |
| skraynev | e fetching resource from neutron | 05:19 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix ignored KSA options https://review.opendev.org/c/openstack/oslo.limit/+/947904 | 05:25 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix ignored KSA adapter options https://review.opendev.org/c/openstack/oslo.limit/+/947904 | 05:27 |
| gtema | skraynev: yes, but it depends. Neutron has a dedicated field check that makes you feel it can be used for that. However, as I said, you can't implement a policy that will reject request based on the current resource state using only oslo.policy. I am working on integration with open policy agent and certain things would be possible there. But that is not going to land soon upstream (it's more a deployment question) | 05:40 |
| skraynev | @gtema got it, thank you. Do you have a reference on code with this "dedicated filed check" ? It will safe some time for me. otherwise I will find it myself. regarding support open policy agent - is the link in blueprint or design doc? | 05:44 |
| gtema | https://opendev.org/openstack/neutron/src/commit/9dc0d0fd2f44e348705804f1f99403086c138010/neutron/policy.py#L383 and https://github.com/gtema/oslo.policy.opa | 05:45 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix wrong argument to determine identity endpoint https://review.opendev.org/c/openstack/oslo.limit/+/947902 | 09:05 |
| opendevreview | Daniel Bengtsson proposed openstack/oslo.config stable/2024.1: Fix concurrent access crash in _all_opt_infos() https://review.opendev.org/c/openstack/oslo.config/+/947917 | 10:26 |
| opendevreview | Daniel Bengtsson proposed openstack/oslo.service master: Add threading backend implementation using cotyledon and standard threads https://review.opendev.org/c/openstack/oslo.service/+/945720 | 10:46 |
| opendevreview | Daniel Bengtsson proposed openstack/oslo.service master: Add threading backend implementation using cotyledon and standard threads https://review.opendev.org/c/openstack/oslo.service/+/945720 | 11:09 |
| gtema | tkajinam: would you pls approve https://review.opendev.org/c/openstack/releases/+/946535 for releasing openstackdocstheme. os-api-ref was released but not the theme | 11:48 |
| skraynev_ | @gtema thank you | 13:02 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix ignored KSA adapter options https://review.opendev.org/c/openstack/oslo.limit/+/947953 | 13:56 |
| tkajinam | sean-k-mooney, ^^^ this is pretty ugly but would be the only viable way to fix ignored adapter options which we have discussed. stephenfin may have a better idea, though | 13:59 |
| tkajinam | It was a huge surprise that these adapter options are not at all used. phhh | 14:00 |
| tkajinam | gtema, jfyi I've voted my +1 | 14:00 |
| gtema | thanks a lot | 14:00 |
| sean-k-mooney | i guess one of the qution i woudl ahve with any fix | 14:01 |
| sean-k-mooney | is do you plan to backport it to older release | 14:01 |
| sean-k-mooney | because this is a capablity that we would expect to work in older release and adding new config options is doable but non trivail for some installers | 14:02 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix ignored KSA adapter options https://review.opendev.org/c/openstack/oslo.limit/+/947953 | 14:02 |
| sean-k-mooney | its actully trivial for the one i work on | 14:02 |
| sean-k-mooney | but that slightly beside the point | 14:02 |
| sean-k-mooney | anyway i didnt want to interupt but it was also a surpise to me | 14:04 |
| sean-k-mooney | i was fully expecting https://github.com/openstack-k8s-operators/nova-operator/blob/main/templates/nova.conf#L329-L338 to result in usign the internal endpoint | 14:05 |
| sean-k-mooney | ill have to add valid_interface to that ot ensure the corerct behavior but as i noted that a trivial chagne | 14:06 |
| tkajinam | yeah | 14:07 |
| tkajinam | I think we can backport that fix because it's an actually bug fix to make the registered options work | 14:08 |
| tkajinam | these have been registered and is added to config file so ignoring these options is apparently a bug | 14:08 |
| tkajinam | it allows us to avoid adding that interface option (which can't be backported) | 14:09 |
| tkajinam | this is the bug which was introduced even before the endpoint lookup according to endpoint_* options were implemented | 14:12 |
| sean-k-mooney | right regardless of the endpoint stuff it it ignored those options then it woudl have taken the default enpoint for keystone | 14:21 |
| sean-k-mooney | which assume is public? i would have to check | 14:21 |
| sean-k-mooney | valid_interfaces also has the benift of being a list so it can fall back if the endpoitn is not aviable | 14:22 |
| sean-k-mooney | which is useful even if 99% of the time that fallback shoudl not be needed | 14:23 |
| tkajinam | afair the public endpoint is used by default | 14:29 |
| tkajinam | yeah. I don't expect that any user may use a list value, but accepting a list allows us to use ['internal', 'public'] as the default value, which usually works better in deployments with multiple endpoint interfaces while it works in deployments with only public endpoint | 14:30 |
| sean-k-mooney | yep, it also allow you to perfer not to go over the wan if you have a local api deployed in the current dc but fallback to a remote dc if that local api is unaviabel for whatever reaons | 14:31 |
| sean-k-mooney | internal is ment ot be for unmetered apis and shoudl be aviabel to service and tenants within a cloud | 14:32 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix ignored KSA adapter options https://review.opendev.org/c/openstack/oslo.limit/+/947953 | 14:33 |
| sean-k-mooney | tkajinam: by the way thanks for working on this. i didnt want to create extra work for you but i wanted to undersand this better before we potentially adapted nova for this bug | 14:35 |
| sean-k-mooney | with https://review.opendev.org/c/openstack/oslo.limit/+/947953 we likely wont need to modify nova just update the verion of oslo.limits to adress the bug | 14:36 |
| tkajinam | np. fixing this may also save my life as I already added a few adapter options such as valid_interfaces to puppet-nova | 14:36 |
| tkajinam | and it was caught in a good timing because the interface option was added AFTER 2025.1 release so it's not yet released | 14:36 |
| sean-k-mooney | ya so tripleo/packstack that leverage pupet-nova were the installer i was refering to where adding new optisn woudl be heavy wieght | 14:37 |
| sean-k-mooney | basically anythin that has multipel layers of indrection to render the config files | 14:37 |
| tkajinam | we could probably make the puppet modules simpler to replicate the same set of values of similar options instead of exposing individual options separately | 14:38 |
| tkajinam | but that is the design created in quite old days, which can't be changed easily nowadays :-P | 14:39 |
| sean-k-mooney | well for things like devsatck we have a common function to handel all the ksa options | 14:39 |
| sean-k-mooney | i think installer like kolla that supprot config overried instead of having an option (i.e. puppet parmater) per service cofnig | 14:40 |
| sean-k-mooney | have proved to be more maintainable in this regard over time | 14:40 |
| tkajinam | puppet does support config override (by passing dictionary values) though that interface often conflicts with native parameters implemented | 14:41 |
| tkajinam | regarding the management of keystoneauth options, there are some complexity caused by the old decision to suggest using service user of target service | 14:41 |
| tkajinam | I mean, in the install guide afair we suggest using neutron user for [neutron] section in nova while cinder user for [cinder] section | 14:42 |
| tkajinam | while the configurations could be pretty simplified if we use the nova user consistently for all interaction from nova | 14:42 |
| * frickler is a strong advocate of the latter fwiw | 14:43 | |
| tkajinam | yeah | 14:43 |
| opendevreview | Daniel Bengtsson proposed openstack/oslo.service master: Add threading backend implementation using cotyledon and standard threads https://review.opendev.org/c/openstack/oslo.service/+/945720 | 14:45 |
| sean-k-mooney | tkajinam: using the neutorn user for neutorn is really an anti pattern | 14:56 |
| sean-k-mooney | in nova the nova user shoudl be used to talk to all other services | 14:57 |
| sean-k-mooney | that was one of the secutiry enhancment we made in the new installe to stop using the neutron user in the nova config | 14:58 |
| sean-k-mooney | what i really wanted to do and still want to do | 14:58 |
| sean-k-mooney | is move to use applciation creditial instead | 14:58 |
| sean-k-mooney | frickler: you will be happy to see this then https://github.com/openstack-k8s-operators/nova-operator/blob/main/templates/nova.conf#L314-L315 | 14:59 |
| sean-k-mooney | frickler: long term i would prefer to allocate an applciation credital either per service or host | 14:59 |
| sean-k-mooney | i.e. have an appcliation credteial that is revoakble for nova or even for each comptue node | 15:00 |
| sean-k-mooney | to limit the blast radius if its ever leaked | 15:00 |
| sean-k-mooney | it would make password rotation simpler too in that you can allocate the new one before the old one expires | 15:00 |
| sean-k-mooney | and have both be vaild while your doing the rotaion in the config files | 15:01 |
| frickler | sean-k-mooney: indeed, I started implementing that for devstack to give it some test coverage, but didn't have time to finish it yet | 15:01 |
| frickler | for production one dedicated credential per service per host (or per container in the kolla case) would seem optimal to me | 15:02 |
| sean-k-mooney | my only concen with tha twas really how well does keystone scale | 15:03 |
| sean-k-mooney | ike if you have 1000 compute with 1 secret per service per host that your talking about 1000s of app creds just for the infra | 15:04 |
| sean-k-mooney | but it does create the tightest secuity envelope | 15:04 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!