Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-30
17:21:48 efried sean-k-mooney: You still planning to drive https://review.opendev.org/#/q/topic:bp/image-metadata-prefiltering+status:open in ussuri?
17:21:49 gibi dansmith: ohh, then I can hack on it right now
17:22:15 dansmith gibi: what about checking obj_what_changed() right before the refresh and asserting that it's either empty or just contains the pci request info and logging a warning if not?
17:23:07 dansmith gibi: in fact if you did that you could avoid the expensive refresh for everyone else if it's not SRIOV
17:23:14 gibi dansmith: I can do that. But I can also extend the refresh() call with an optiona; field list
17:23:45 dansmith gibi: I'm less excited about the latter just because of the potential effort in validating it, but it seems like that might be useful
17:24:21 dansmith gibi: I think the reason we didn't initially do that is because you may be creating a franken-instance where you've pulled some updates from the db and not others, which are co-dependent and then would save it back in an inconsistent state
17:24:22 gibi dansmith: OK. I will follow your suggestion and check obj_what_changed and log a warning if we would drop other fields than pci
17:24:37 dansmith gibi: and avoid the refresh if nothing is changed yeah?
17:24:41 gibi yepp
17:24:43 dansmith cool
17:24:50 gibi and make a note about selective refresh for later
17:24:57 gibi dansmith: thanks!
17:25:15 dansmith ack, also note my piconit :)
17:25:53 gibi ack :)
17:28:58 gibi o/
17:41:01 gmann cmurphy: can you revisit this review. i replied in the comment, https://review.opendev.org/#/c/701624/
17:41:43 gmann doing deprecation in base rule is to avoid adding the deprecation warning in each rule using base rule as their check_str
17:44:17 gmann cmurphy: you can find more discussion here on doing deprecation in base rule than specific rules - https://review.opendev.org/#/c/676682/4/nova/policies/admin_actions.py
17:49:14 efried stephenfin: is there anything further to be done for https://blueprints.launchpad.net/nova/+spec/remove-xvpvncproxy or can I mark it complete?
17:50:21 stephenfin efried: Nope, melwitt and mriedem closed it out a few weeks back. It's done.
17:50:27 efried sweet
17:51:59 cmurphy gmann: i will come back to it today, thanks for pointing me to the discussion
17:52:19 cmurphy i'm hoping lbragstad could also offer some insights ^
17:52:21 gmann cmurphy: thanks
17:52:25 gmann +1
18:26:15 efried dansmith: Are you pursuing this https://review.opendev.org/#/c/693226/ ? (nova-audit)
18:26:33 efried If so, would you please throw out a bp for it? I'm getting those ducks lined up.
18:28:10 dansmith efried: no, I had abandoned it
18:28:31 efried oh, looks like melwitt restored it. melwitt ^ ?
18:29:16 melwitt I had restored it to encourage ops review, I was told the abandonedness confused the people who would comment on it
18:30:02 efried melwitt: k. Been a couple weeks. If you wouldn't mind putting up a blueprint so it's properly trackable. Then I guess we can go-no-go it at spec freeze time.
18:30:36 melwitt efried: yeah, makes sense. I will do that
18:37:53 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Deprecate base rules in favor of new rules https://review.opendev.org/701624
18:38:23 gmann cmurphy: lbragstad done ^^
19:22:13 openstackgerrit Merged openstack/nova master: Use COMPUTE_SAME_HOST_COLD_MIGRATE trait during migrate https://review.opendev.org/695220
19:22:18 openstackgerrit Merged openstack/nova stable/stein: Remove 'test_cold_migrate_with_physnet_fails' test https://review.opendev.org/702971
19:34:59 openstackgerrit Artom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration https://review.opendev.org/672595
19:35:01 openstackgerrit Artom Lifshitz proposed openstack/nova master: NUMA LM: Add func test for bug 1845146 https://review.opendev.org/687404
19:35:01 openstack bug 1845146 in OpenStack Compute (nova) train "NUMA aware live migration failed when vCPU pin set" [High,Fix committed] https://launchpad.net/bugs/1845146 - Assigned to Dan Smith (danms)
19:52:08 stephenfin sean-k-mooney: want to drop your -W from https://review.opendev.org/#/c/703115/ now that the stable/stein changes have merged
19:53:32 sean-k-mooney done
20:57:11 efried Nova meeting shortly in #openstack-meeting
21:48:51 melwitt efried: created https://blueprints.launchpad.net/nova/+spec/nova-audit
21:49:03 efried thanks melwitt
22:16:57 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing attach_interfaces policies https://review.opendev.org/705126
22:40:42 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Remove old policy enforcement in attach_interfaces https://review.opendev.org/705127
22:52:57 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing attach_interfaces policies https://review.opendev.org/705126
22:55:15 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing attach_interfaces policies https://review.opendev.org/705126
23:14:11 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing attach_interfaces policies https://review.opendev.org/705126
23:40:03 melwitt gmann: question on https://review.opendev.org/701629
23:45:13 gmann melwitt: replied. I am removing user_id from policy target in https://review.opendev.org/#/c/701642/
23:45:49 gmann melwitt: but if we keep this operation restriction at user level then we can keep.
23:46:32 gmann we do not pass user_id for most of the(i think all except user level API like keypair etc) API. it is all enforced at project level
23:46:36 melwitt gmann: ok. I'm thinking from the perspective of us having to keep the legacy policy behavior for some time or some transition period. is my understanding correct?
23:47:22 melwitt because from the look of the old tests, we support letting operators restrict password change to only the user set on the instance
23:48:36 gmann melwitt: yeah, that is good point. We can keep supporting it same way till we completely migrate to new
23:49:06 melwitt I'm happy to be wrong but I thought we were keeping current support as-is for now and if we want to change it, need some signal about deprecation and a transition period before dropping
23:50:17 melwitt I was reading this part of the spec again https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/policy-defaults-refresh.html#backward-compatibility-and-migration-plan
23:52:40 gmann yeah. by removing the user_id from target we can break some deployment.
23:52:46 melwitt "Remove any project or user checks from the policy file defaults, as this is now done in code, without breaking user-id-based-policy-enforcement"
23:53:01 melwitt I'm wondering if we removed any in the already merged patches
23:54:30 gmann no, this is first one where user_id is passed and i updated to remove that. in "pass actual target" patches I pass the actual target wherever needed. like owner rule where project_id is needed.
23:55:22 melwitt ok
23:55:48 gmann "pass actual target" patches can tell us if any where we are changing user-level enforcement
23:56:04 melwitt ok, that is good to know
23:57:00 melwitt not directly related to this, I do wonder if operators would be disappointed to lose user-level enforcement in the future on something like a admin password. but that's a separate issue
23:58:15 melwitt I see now in the pass actual target, thanks for the tip https://review.opendev.org/#/c/701642/1/nova/api/openstack/compute/admin_password.py
23:58:15 gmann yeah, i think we need to change that with separate discussion if everyone ok. else keep it as it is.
23:59:25 gmann melwitt: i found one bug in attach_interface policy which is admin_or_owner but it pass for every context because project_id is not passed in policy target
23:59:29 melwitt yeah, agreed. I can't predict what operators would want to see there, would be a good question for the forum and if no one cares about user-level enforcement, we remove it after the transition period
#openstack-nova - 2020-01-31
00:00:20 gmann because our policy doc say it is admin_or_owner but code is buggy so I am thinking whether we can fix this as bug or leave this operation open for everyone
00:00:20 melwitt gmann: bug in the legacy policy or bug in the more recently policy patches merged?
00:00:27 gmann legacy
00:00:58 melwitt sigh ... I'm not surprised, there's a lot of bugs/quirks there.
00:00:58 gmann this one - https://review.opendev.org/#/c/705126/4
00:01:26 gmann i added the test with admin_or_owner context to pass and other proejct to fail. but those tests fail as you can see in gate.
00:01:38 melwitt I guess my instinct would be to fix the bug first and then stack the new stuff on top, but that might be just me
00:02:24 gmann yeah that is what i was thinking. so that we can see the bug and fix first and then start the new policy defaults
00:02:25 melwitt I see. well, that's a good sign for the new test coverage I guess :)
00:02:32 gmann yeah
00:02:36 melwitt it's catching bugs
00:02:55 gmann i will file bug and put fix as separate change.
00:03:09 melwitt sounds great ++
00:03:26 melwitt add me as reviewer when you have it ready
00:03:33 gmann sure, thanks
00:22:33 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Fix os-attach-interfaces policy to be admin_or_owner https://review.opendev.org/705135
02:12:21 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Fix os-attach-interfaces policy to be admin_or_owner https://review.opendev.org/705135
02:31:00 gmann melwitt: ^^
02:34:41 openstackgerrit Merged openstack/nova stable/stein: Block rebuild when NUMA topology changed https://review.opendev.org/702972
02:51:52 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Remove old policy enforcement in attach_interfaces https://review.opendev.org/705127
04:26:53 melwitt gmann: ack thanks, will look tomorrow
09:46:39 gibi dansmith: I've investigated the obj_what_changed() way to detect if the pci requests need s refres during live migraton rollback but this idea fails for mutliple reasons. See my answer in https://review.opendev.org/#/c/702261/4/nova/compute/manager.py@8563
10:17:29 jawad_axd Hi all. M writing once again here. Question is, iperf3 shows 9.89 Gbits/sec between hosts while instances on same network on these two hosts have iperf3 108 MBytes/sec from inside. How come bandwidth is so poor inside instances? I am using centos7.7, stein, linux bridge,vxlan setup. Any suggestions?
10:27:26 gibi jawad_axd: when you measure performance between the two hosts does the packets are going throigh the same linux bridge as the guests uses in the other measurement between guests?
10:32:50 jawad_axd Nope. Performance between physical hosts is using another bridge at physical NIC. Its just for reference point for guest performance. While guests using bridges created by neutron.
10:34:41 gibi jawad_axd: what I would do is to add layers from the guest-guest test to the host-host test one by one to see which layer causes the degradation
10:36:13 stephenfin bauzas: Could you take a look at these today? https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/remove-nova-network-ussuri
10:36:20 bauzas sure
10:36:31 bauzas I need to go to the gym but I can do it later

Earlier   Later