| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-10 | |||
| 23:23:14 | sean-k-mooney | or rahter check if the serivce is disable or down | |
| 23:23:34 | sean-k-mooney | and add COMPUTE_STATUS_DISABLED in both cases | |
| 23:23:45 | sean-k-mooney | or maybe add a COMPUTE_STATUS_DOWN trait too | |
| 23:24:00 | sean-k-mooney | if we dont want to over load COMPUTE_STATUS_DISABLED | |
| 23:24:43 | sean-k-mooney | so with that in mind i might undo the deprecation of the compute filter for victoria and just deprecte the az filter since the placment prefilter for that has the same behavior | |
| 23:25:04 | sean-k-mooney | and then fix the compute prefilter behavior in wallaby | |
| 23:25:33 | sean-k-mooney | stephenfin: gibi when ye are awake does ^ make sense to ye | |
| 23:26:55 | sean-k-mooney | also sriov attach/detach megered :) that is good | |
| #openstack-nova - 2020-09-11 | |||
| 00:34:14 | luyao | stephenfin: Hi, recheck succeeds at ' | |
| 00:34:15 | luyao | Rollback when reset running live migration' https://review.opendev.org/#/c/747899/, thanks for review | |
| 01:30:55 | openstackgerrit | zhufl proposed openstack/nova master: Fix invalid assert_has_calls https://review.opendev.org/751143 | |
| 02:24:53 | openstackgerrit | Eric Xie proposed openstack/nova master: Fix error that cannot overwrite policy rule for 'forced_host' https://review.opendev.org/751152 | |
| 02:31:37 | openstackgerrit | Merged openstack/nova master: Track error migrations in resource tracker https://review.opendev.org/745281 | |
| 02:56:43 | openstackgerrit | Rui Zang proposed openstack/nova master: DO NOT REVIEW https://review.opendev.org/751156 | |
| 07:11:43 | gibi | sean-k-mooney: sounds interesting. I will have to dig into it a bit | |
| 07:39:00 | bauzas | good Friday Nova | |
| 07:39:26 | bauzas | gibi: I have a specific concern on the relnote for the vmwareapi driver undeprecation but I forgot to tell it during the meeting yesterday | |
| 07:39:29 | bauzas | gibi: https://review.opendev.org/#/c/742407/5/releasenotes/notes/undeprecate-vmware-victoria-2eaf5d877733f8d9.yaml | |
| 07:39:41 | bauzas | not worth holding the change, but maybe a FUP could be nice | |
| 07:42:11 | gibi | bauzas: will push a follow up, thanks | |
| 07:42:19 | bauzas | thanks | |
| 07:42:26 | gibi | and good Friday morning to you too | |
| 07:42:58 | bauzas | gibi: and I -w'd the prelude because of the xenapi change still in the gate + this one that I think which needs to be in the prelude | |
| 07:43:30 | gibi | yeah, I kikked the xenapi series this morning with a recheck | |
| 07:43:35 | gibi | *kicked | |
| 07:43:59 | bauzas | I saw | |
| 08:23:52 | sean-k-mooney | o/ | |
| 08:25:37 | sean-k-mooney | gibi: so i would still like to procee with the deprecation of the az filter and enableing the placment version by default in Victoria since its behavior is equivalent, but i think i am going to split out the Comptefilter changes and look to adress that in Wallaby when we have more time to think about it | |
| 08:27:08 | sean-k-mooney | i dont know if we want to reuse the COMPUTE_STATUS_DISABLED trait for force down or not and i dont really want ot rush figuring that out | |
| 08:28:15 | sean-k-mooney | i think having a sperate COMPUTE_STATUS_DOWN trait is proably more correct but that would need an os-traits release and i dont think this warrents a FFE for os-triats since its just tech debt removal | |
| 08:28:19 | gibi | sean-k-mooney: make sense, keep the ComputeFilter then for V and please open a bug to track the problem you detected with the pre-filter | |
| 08:29:17 | sean-k-mooney | yep i can do that that was actully going to be my question should i open a bug or blueprint. e.g. is this an oversight in the original filter that it ignore force down or a new feature | |
| 08:31:13 | gibi | i consider this as a bug | |
| 08:35:42 | sean-k-mooney | cool ill file one so then respin the patch to drop the computefitler changes | |
| 08:36:12 | gibi | thanks | |
| 08:38:46 | bauzas | sean-k-mooney: wait, what ? | |
| 08:38:56 | bauzas | sean-k-mooney: which filter are you going to deprecate ? | |
| 08:39:05 | bauzas | AZFilter or ComputeFilter ? | |
| 08:39:13 | sean-k-mooney | i was deprecating both | |
| 08:39:22 | sean-k-mooney | but the behavior of the ComputeFilter | |
| 08:39:31 | sean-k-mooney | is not identical to the placment prefilter for compute status | |
| 08:39:48 | sean-k-mooney | because the prefilter does not take accound of force_down | |
| 08:39:50 | bauzas | ok, now I better understand and yes | |
| 08:39:59 | bauzas | I was about to say this | |
| 08:40:32 | bauzas | but... are we considering the AZfilter deprecation for the Victoria cycle ? | |
| 08:40:35 | sean-k-mooney | so for now im just going to depercate teh az filter then file a bug for the gap in behavior and we can figure out the correct way to handel force_down in wallaby | |
| 08:40:38 | bauzas | I'd say it's a Wallaby thing | |
| 08:40:46 | sean-k-mooney | bauzas: yes i was | |
| 08:41:11 | sean-k-mooney | https://review.opendev.org/#/c/745605/ | |
| 08:41:34 | sean-k-mooney | i have had that open for a while but only dug into the fun test fialure properly yesterday | |
| 08:41:48 | bauzas | ok, I feel we need to talk then | |
| 08:42:04 | bauzas | because I agree with the fact that the AZfilter is on par with the pre-filter | |
| 08:42:49 | sean-k-mooney | i could delay this if you want by the way but if you dont have an object ot the AZfilter then i would prefer to proceed with just that | |
| 08:42:50 | bauzas | but I know ops use filters by ordering them like they want | |
| 08:43:01 | sean-k-mooney | yes | |
| 08:43:10 | sean-k-mooney | but the AZ filter always goes first right | |
| 08:43:29 | bauzas | no | |
| 08:43:39 | sean-k-mooney | no? | |
| 08:43:41 | bauzas | by default, ComputeFilter goes first | |
| 08:43:54 | bauzas | and then AZ | |
| 08:44:08 | bauzas | if we deprecate the AZ, this will change | |
| 08:44:39 | bauzas | oh shit | |
| 08:44:41 | bauzas | I'm wrong | |
| 08:44:51 | openstackgerrit | Dat Le proposed openstack/nova stable/rocky: Fix unplugging VIF when migrate/resize/rebuild VM between hosts have difference VIF type https://review.opendev.org/751186 | |
| 08:44:52 | sean-k-mooney | ya i was going to say https://review.opendev.org/#/c/745605/3/nova/conf/scheduler.py | |
| 08:44:57 | bauzas | that's... disturbing | |
| 08:45:13 | sean-k-mooney | it makes sense from an information gain point of view | |
| 08:45:14 | bauzas | I'm almost sure this wasn't the case years ago | |
| 08:45:27 | bauzas | but anyway | |
| 08:45:33 | bauzas | in this case, this sounds legit | |
| 08:45:48 | bauzas | sean-k-mooney: if so, I'll review your deprecation patch | |
| 08:46:06 | sean-k-mooney | the point is in anycase to move both operation eventually to the placment query | |
| 08:46:25 | sean-k-mooney | since in that case ordering does not matter | |
| 08:47:01 | sean-k-mooney | at least form teh point of view of the query construction | |
| 08:48:19 | sean-k-mooney | bauzas: ill ping you with the update patch with just the AZfilter deprecation in a few once its ready | |
| 08:48:34 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Spell out 3pp in vmware undeprecation reno https://review.opendev.org/751188 | |
| 08:48:53 | sean-k-mooney | whats 3pp | |
| 08:49:06 | sean-k-mooney | oh hehe | |
| 08:49:13 | sean-k-mooney | third party | |
| 08:49:28 | sean-k-mooney | i see that was bauzas nit | |
| 08:51:39 | bauzas | sean-k-mooney: also, I left a comment on your deprecation patch, having the sheduler being underoptimized is not a performance issue | |
| 08:55:34 | sean-k-mooney | bauzas: thanks that said the orginal doc state that enabling the prefilter improves performance, so when i flip the docs to state its enabled by default now does it not make sense to now also state that reverting to the az filter woudl reduce performance | |
| 08:56:05 | sean-k-mooney | bauzas: i can remove that i just basically inverted the previous statement but if you dont think it adds value ill just drop it | |
| 08:56:25 | sean-k-mooney | bauzas: you were refering to your comment here right https://review.opendev.org/#/c/745605/3/doc/source/admin/availability-zones.rsthttps://review.opendev.org/#/c/745605/3/doc/source/admin/availability-zones.rst | |
| 08:57:54 | sean-k-mooney | the funny thing is that change was orginally just ment to be the az filter | |
| 08:58:39 | sean-k-mooney | i only added the compute filter when i was doing the doc update and was like waith there is a prefilter that "does the same thing" that can go too. i was wrong :( | |
| 09:13:31 | openstackgerrit | Federico Ressi proposed openstack/nova master: Log stack trace when fails launching a defined domain https://review.opendev.org/750652 | |
| 09:13:47 | openstackgerrit | Federico Ressi proposed openstack/nova master: Log stack trace when fails launching a defined domain https://review.opendev.org/750652 | |
| 09:14:58 | bauzas | sean-k-mooney: I know, we have a lot of docs that are wrong by saying "heh, prefilters are better for performance" | |
| 09:15:09 | bauzas | tbc: NO | |
| 09:15:21 | bauzas | a prefilter just allows you to get more candidates | |
| 09:15:53 | sean-k-mooney | bauzas: that is not true | |
| 09:16:13 | bauzas | filters perfomance is not an issue | |
| 09:16:15 | sean-k-mooney | bauzas: if you enable a prefilter and disable a schduler filter the db outperform python | |
| 09:16:25 | bauzas | sean-k-mooney: again, it's wrong | |
| 09:16:26 | sean-k-mooney | bauzas: in general yes | |
| 09:16:41 | bauzas | lots of folks (eg. CERN) looked at the scheduler performance | |
| 09:16:46 | sean-k-mooney | bauzas: we have see this form operators reporting that its faster | |
| 09:16:53 | bauzas | and none of them said that the filters were outperfomed | |
| 09:17:10 | bauzas | the problem was with the DB | |