Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-06
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: Drop concept of '?validation' parameter https://review.opendev.org/717789
16:16:11 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Add documentation for flavor extra specs https://review.opendev.org/710037
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:12 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Move description of groups to document itself https://review.opendev.org/717790
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: 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

Earlier   Later