Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-06
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: Update quota apis with keystone limits and usage https://review.opendev.org/713499
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: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
17:30:09 gmann lbragstad: ok. I will try to push that today.
17:50:57 openstackgerrit Merged openstack/nova stable/rocky: Unplug VIFs as part of cleanup of networks https://review.opendev.org/715404
18:11:53 openstackgerrit Sasha Andonov proposed openstack/nova master: rbd_utils: increase _destroy_volume timeout https://review.opendev.org/705764
18:22:53 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Fix new context comparison workaround in base tests class https://review.opendev.org/717825
18:26:04 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Fix new context comparison workaround in base tests class https://review.opendev.org/717825
18:59:51 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Fix misc comments on policy work https://review.opendev.org/717835
21:01:14 openstackgerrit Lee Yarwood proposed openstack/nova master: workarounds: Add option to disable native LUKSv1 decryption by QEMU https://review.opendev.org/708030
21:01:15 openstackgerrit Lee Yarwood proposed openstack/nova master: workarounds: Add option to locally attach RBD volumes on compute hosts https://review.opendev.org/708029
21:13:32 openstackgerrit Merged openstack/nova master: Disable the policy warning temporary https://review.opendev.org/717802
21:40:24 sean-k-mooney melwitt: regarding the oslo.policy cahnge. if we cant deliver that via a FFE is the plan to leave the deprecation warning disabled or do something slighly hacky like monky patch oslo.policy to do what we want for ussuri
21:41:07 sean-k-mooney melwitt: i know we have monkeypatched other libs in the past but i would feel weired doing it to oslo so i assume it would be left disabled
21:44:13 melwitt sean-k-mooney: yeah, I'm thinking about the same thing and I am not sure. I would think leave it disabled in the worst case scenario of not being able to solve it in oslo.policy via FFE. but I know that leaves us in a bind too wrt to any policy name changes that are also occurring
21:44:25 melwitt gmann: did you have any thoughts on this yet, what do we do if we can't get the oslo.policy stuff figured out? ^
21:49:25 gmann melwitt: I will push both things on oslo side today if those cannot be merged due to any reason, then i think we left with no option than keep it disabled.
21:50:53 gmann we are saying to support the old defaults by 2 cycles at least so existing deployement are not going to break immediately which mean no-warning things also not so bad
21:58:56 melwitt gmann: ack thanks
21:59:39 melwitt that's true we have some time to sort it out from that perspective
23:14:13 sean-k-mooney gmann: the oslo team are currently asking for an FFE for some libs so if we want to get this in we should ask them to include it in that FFE
23:16:04 gmann sean-k-mooney: yeah, I am working on changes and will ask FFE
23:41:35 openstackgerrit Luigi Toscano proposed openstack/nova master: zuul: Switch to the Zuulv3 grenade job https://review.opendev.org/704364
#openstack-nova - 2020-04-07
00:05:01 brinzhang dansmith: Could you please update the separate update and seap volume policies patch? https://review.opendev.org/#/c/711194/ , I seem not get the logical what would you want to do, although I read the chat history of gmann and you.
00:07:25 brinzhang gibi: I dont know whois Victor Coutellier, I have two patches of microversion 2.84 and v2.85 rebased on v2.83 https://review.opendev.org/#/c/713089/ , it is very close to April 9th, I hope he can update ASAP
00:12:52 gmann brinzhang: he was new to nova side, not sure if he is aware of deadline.
00:13:22 gmann brinzhang: is more changes requied on his patch?
00:13:38 gmann i have not looked into review comments yet
00:16:24 gmann if those are not too much, we can help him by fixng those
00:26:34 brinzhang gmann: Got it, if so, I will looked into
00:26:36 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Disable warning for policies changing default check_str https://review.opendev.org/717884
00:26:45 brinzhang gmann: thanks
00:27:49 gmann brinzhang: thanks.
00:28:28 melwitt alex_xu: heya, could you pls revisit these 2 patches you have reviewed before, they are about removing the "" to "/" redirect in nova api for version discovery https://review.opendev.org/685180
00:28:45 alex_xu melwitt: I will try it today
00:28:50 melwitt and allowing unauthenticated for version discover
00:28:54 melwitt thanks alex_xu
00:29:01 alex_xu np
00:49:14 gmann lbragstad: should I make the changes of operators flag to new system in this or separate ? -https://review.opendev.org/#/c/717879/1
00:50:11 gmann lbragstad: the disable warning flag we need as separate so that we can disable the warning from now itself not based on new-system-flag
00:51:36 lbragstad gmann oh - sorry, i didn't realize you were going to put that functionality behind a separate flag

Earlier   Later