Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-06
16:02:35 stephenfin we ignore all unknown namespaces
16:02:40 gibi OK, make sense
16:02:50 openstackgerrit John Garbutt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/712143
16:02:51 stephenfin (and those without namespaces, fwiw)
16:03:12 openstackgerrit John Garbutt proposed openstack/nova master: Add stub unified limits driver https://review.opendev.org/712137
16:03:23 openstackgerrit John Garbutt proposed openstack/nova master: Assert quota related API behavior when noop https://review.opendev.org/712140
16:03:30 gibi stephenfin, johnthetubaguy: seems like a good idea.
16:03:35 openstackgerrit John Garbutt proposed openstack/nova master: Make unified limits APIs return reserved of 0 https://review.opendev.org/712141
16:03:47 openstackgerrit John Garbutt proposed openstack/nova master: Add logic to enforce local api and db limits https://review.opendev.org/712139
16:03:59 openstackgerrit John Garbutt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/712142
16:04:16 openstackgerrit John Garbutt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/712143
16:05:31 johnthetubaguy melwitt: oops :/
16:05:43 johnthetubaguy probably means the same for our users
16:05:49 melwitt yeah :( we were just talking about this the other day but I didn't realize how intense it is
16:06:03 johnthetubaguy does it mean almost every API call?
16:06:14 johnthetubaguy or just a massive storm on restart?
16:06:23 melwitt we need to get it removed asap. we were already talking to gmann about it and he was cool with removing it and doing a reno-only announcement re: policy changes
16:06:41 johnthetubaguy melwitt: is there a patch up?
16:06:45 melwitt looks like every API call
16:07:05 johnthetubaguy yeah, that isn't right :/
16:07:46 melwitt no not that I know of, no patch yet
16:14:45 openstackgerrit Alexandre arents proposed openstack/nova master: Calculate disk_over_committed for raw instances https://review.opendev.org/717037
16:14:52 johnthetubaguy its probably all system only API calls... as our tests probably don't have a system admin user yet
16:16:10 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Add microversion for extra spec validation https://review.opendev.org/708436
16:16:11 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Add documentation for flavor extra specs https://review.opendev.org/710037
16:16:11 openstackgerrit Stephen Finucane proposed openstack/nova master: Drop concept of '?validation' parameter https://review.opendev.org/717789
16:16:12 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Move description of groups to document itself https://review.opendev.org/717790
16:16:12 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Add 'nova' domain and include extra specs in it https://review.opendev.org/717791
16:16:45 stephenfin johnthetubaguy: I think that matches up with what you were expecting ^
16:17:06 stephenfin gibi: Also, I retooled the docs. It's _much_ nicer now (we can cross-reference!)
16:17:31 gibi stephenfin: will look but sounds awesome!
16:19:47 openstackgerrit John Garbutt proposed openstack/nova master: Update limit APIs https://review.opendev.org/712707
16:23:56 gibi bauzas: o/ sorry I could not get to the vgpu series of yours
16:24:01 gibi maybe tomorrow
16:24:08 bauzas gibi: thanks and no worries
16:24:33 bauzas gibi: in the meantime, I'll write to provide a func change for seeing the behaviour
16:24:42 openstackgerrit John Garbutt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/712749
16:24:45 gibi bauzas: thanks
16:29:55 openstackgerrit John Garbutt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/713301
16:33:32 openstackgerrit John Garbutt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/615180
16:40:52 melwitt johnthetubaguy: I wonder if we should revert https://review.opendev.org/701624 for now? or is there some other way to approach this cc gmann
16:41:00 gibi do somebody know the irc nick of the owner of https://review.opendev.org/#/c/713089/ ? we would need to release the novaclient this week and patches are blocked on this
16:43:01 melwitt gibi: looks like it might be alisterle https://launchpad.net/~alistarle
16:43:41 gibi melwitt: thenk I will try to ping him when he is up
16:43:56 johnthetubaguy melwitt: are we sure we know what is causing the logs, I think it might be the scope chagnes
16:44:14 openstackgerrit John Garbutt proposed openstack/nova master: Add legacy limits and usage to unified limits https://review.opendev.org/713498
16:44:14 openstackgerrit John Garbutt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/713499
16:44:15 openstackgerrit John Garbutt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/715271
16:45:05 melwitt johnthetubaguy: I don't have deep enough knowledge to know that but I was thinking if we unmarked the things as deprecated it would stop the deprecated messages?
16:45:22 melwitt I guess I would propose the revert as -W to see for sure
16:45:27 johnthetubaguy we have about 20 or more patches like that though
16:45:39 johnthetubaguy do you have the log message causing the issue to hand?
16:45:53 melwitt oh really? it's not just the one that marks deprecated
16:45:57 johnthetubaguy logs I am looking at at failing to load now... which could be related
16:46:04 johnthetubaguy we have deprecated loads though
16:46:10 melwitt ok I see
16:46:34 johnthetubaguy we might have to change the logging config for oslo.policy
16:46:50 johnthetubaguy assuming that is possible somehow
16:47:37 gmann johnthetubaguy: melwitt let me propose it to disable it temp and then find a good way
16:47:51 johnthetubaguy gmann: thanks, sounds like a plan
16:47:59 johnthetubaguy gmann: which log message is it?
16:48:21 melwitt this is an example, https://6d82362f2cdc504b27f1-9f757b11a1d2b00e739d31e1ecad199a.ssl.cf5.rackcdn.com/717662/1/check/tempest-integrated-compute/b3260ce/controller/logs/screen-n-api.txt
16:48:25 gmann johnthetubaguy: it is from base rule
16:49:17 melwitt gmann: yay you're here, thank you. once we disable it I need to tell clarkb so he can dump the current logs from indexing. he said it will never catch up and we need to start fresh
16:55:58 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Disable the policy warning temporary https://review.opendev.org/717802
16:56:18 gmann melwitt: johnthetubaguy ^^
16:58:00 johnthetubaguy gmann: assuming that works, lets do it.
16:59:59 gmann johnthetubaguy: yeah, let's wait for gate result also
17:01:47 melwitt gibi: fyi ^ patch to temporarily disable policy deprecation warnings currently making nova-api logs huge with log spam (example is linked few messages back in backscroll)
17:04:52 johnthetubaguy oh my, its very chatty :/
17:05:17 melwitt yeah it's ... a lot more logging than I had realized
17:09:31 dansmith only 15k in that one log
17:09:56 melwitt "only"
17:09:57 johnthetubaguy ah, right, that isn't so bad then (ducks)
17:10:28 dansmith melwitt: yes, extreme sarcasm around the only
17:10:53 melwitt I know, I thought it was funny
17:11:39 gmann johnthetubaguy: melwitt dansmith : to sync up on some approach on policy warning and adopting new behaviour ( lbragstad and I discussed last week i think)
17:12:22 lbragstad o/
17:12:47 gmann Warning: 1. do not log warning for policy changing defaults (but still not enabled as we support old defaults also) 2. do log warning where policy names are changed (granular cases in our case)
17:13:51 gmann New behaviour: 1. one way was to make enforce_policy as all-new-together a flag to disable the deprecation rules also. means if this flag is true then support only new defaults_scope
17:14:53 lbragstad i was thinking about this a little more, did we want to provide a way for people to opt into the new defaults without writing to the policy file (again)?
17:15:23 gmann yeah, that one. with enforce_scope flag right ?
17:15:42 melwitt I thought there was a way, by setting enforce_scope = True? or is that not something a user can do
17:16:21 gmann yeah there is but that only control scope_type checks not the deprecated old rules
17:16:22 lbragstad kind of - but we didn't expect to use that option to adjust deprecation behavior
17:16:59 melwitt oh I see
17:17:39 gmann or we can do with new flag which we can keep it for future usual policy changes also
17:17:51 lbragstad but i can understand the usecase where deployers want to opt into the new policy system without having to write "new" defaults back into the policy file to get around noisy logs and the logical OR in oslo.policy
17:18:10 gmann so when enforce_scope if true by default or we remvoe that in future we can keep new flag for deprecation things always
17:18:50 lbragstad i guess that's the part i'd like to walk through, does it make sense to reuse that option or do we need something new?
17:20:11 bnemec I think they're separate things. enforce_scope is a temporary thing while everyone gets their policies scope-ready, this new deprecation flag is something that we would keep indefinitely because it will have use any time a policy is deprecated for any reason.
17:20:23 gmann IMO, something new make sense for considering the future cases
17:21:37 bnemec Also, I should note that we are past all of the freeze dates that apply to oslo.policy, so whatever we do it needs to be ASAP so we can request an FFE.
17:22:41 gmann bnemec: yeah that is what i was thinking yesterday and about to ask if oslo.policy is already released ?
17:24:48 sean-k-mooney stephenfin: ill review the new version you pushed. i think i can live with that compromise but im not entirely sure its an improvemnt
17:25:05 bnemec Yeah, that ship has sailed. Our last planned feature release (which was an FFE itself) happened Friday.
17:25:11 gmann ok
17:25:50 bnemec I think this is worth an FFE, but it's no longer up to me alone.
17:26:02 gmann I (or if lbragstad want to do) can propose that if all agree on that ?
17:28:23 lbragstad gmann i'm happy to review if you push something up

Earlier   Later