| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-23 | |||
| 15:09:07 | sean-k-mooney | we deprecated it because you cant use the aggret extra specs filter and compute capablities filter at the same time if you use unprefixed keys | |
| 15:09:20 | bauzas | sean-k-mooney: sure, I remember why we have this prefix | |
| 15:09:36 | bauzas | but I thought we only *documented* to use it if you were using both filters | |
| 15:09:45 | bauzas | not if you were only using one | |
| 15:09:56 | stephenfin | Multiple values can be given, as a comma-separated list. For backward compatibility, also works with non-scoped specifications; this action is highly discouraged because it conflicts with ComputeCapabilitiesFilter filter when you enable both filters. | |
| 15:10:04 | stephenfin | from way back in Mitaka https://docs.openstack.org/mitaka/config-reference/compute/scheduler.html | |
| 15:10:14 | stephenfin | "highly discouraged" is pretty strong :) | |
| 15:10:26 | bauzas | okay, so this is docs | |
| 15:10:35 | stephenfin | I can add the tests if you really want them though? | |
| 15:10:42 | sean-k-mooney | yes but with the intorctution of the flavor vlaidation it should be even more discuraged | |
| 15:10:42 | bauzas | the problem is that I know more ops that use this filter than the computecaps one | |
| 15:11:04 | bauzas | as the computecapabilities one is pretty useless now we have traits | |
| 15:11:20 | sean-k-mooney | bauzas: it can do thing tratis cant | |
| 15:11:36 | bauzas | stephenfin: as you wish, I won't both | |
| 15:11:38 | bauzas | bother | |
| 15:11:47 | bauzas | stephenfin: you added code, you proved me I was wrong | |
| 15:11:54 | bauzas | so that's a good start | |
| 15:12:02 | stephenfin | well I've done it now | |
| 15:12:07 | stephenfin | so you're getting the tests | |
| 15:12:11 | stephenfin | and you'll be happy with them | |
| 15:12:14 | sean-k-mooney | for what its worth i suggest we require custom: as a prefix when we were adding the flavor extra spec validation | |
| 15:12:38 | opendevreview | Stephen Finucane proposed openstack/nova master: Add tests for 'AggregateImagePropertiesIsolation' https://review.opendev.org/c/openstack/nova/+/754115 | |
| 15:12:38 | opendevreview | Stephen Finucane proposed openstack/nova master: Add tests for 'AggregateInstanceExtraSpecsFilter' https://review.opendev.org/c/openstack/nova/+/754116 | |
| 15:12:46 | stephenfin | gibi, bauzas: comments addressed ^ | |
| 15:13:10 | bauzas | stephenfin: looking again, then | |
| 15:14:20 | stephenfin | I'm pretty sure I had a fairly thorough reworking of the scheduler filter docs at some point. I wonder if that merged? | |
| 15:14:58 | stephenfin | nope https://review.opendev.org/c/openstack/nova/+/773645 | |
| 15:16:22 | gibi | I'm +2 on both test patch. thanks stephenfin | |
| 15:16:29 | stephenfin | thank you | |
| 15:17:16 | bauzas | sent to the gate, then | |
| 15:17:29 | bauzas | .... and, given this, folks, \o | |
| 15:17:47 | gibi | bauzas: o/, please remember I'm off next week, and the meeting chair is your :D | |
| 15:19:14 | sean-k-mooney | stephenfin: there are a few patches before that can it be pulled forward or should we try and merge the others first | |
| 15:19:32 | sean-k-mooney | the docs patch that is https://review.opendev.org/c/openstack/nova/+/773645 | |
| 15:19:46 | stephenfin | I'd say the latter. The docs changes assume the filter scheduler is the only one left, which requires the preceding changes | |
| 15:19:59 | sean-k-mooney | ack ok ill start form the bottom so | |
| 15:20:48 | bauzas | gibi: oh, I remember this, but I haven't said "good vacations" to you :p | |
| 15:21:14 | bauzas | gibi: fwiw, I'll be on PTO between Aug 9 and Aug 30 | |
| 15:21:27 | bauzas | ... just before end of Xena-3 :) | |
| 15:22:50 | gibi | bauzas: thanks | |
| 16:06:19 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support move ops with extended resource request https://review.opendev.org/c/openstack/nova/+/800087 | |
| 16:06:19 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] refactor interface attach with qos https://review.opendev.org/c/openstack/nova/+/800088 | |
| 16:07:36 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support interaface attach / detach with new resource request format https://review.opendev.org/c/openstack/nova/+/800089 | |
| 16:10:11 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] move unshelve test to the proper place https://review.opendev.org/c/openstack/nova/+/793621 | |
| 16:41:46 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support boot with extended resource request https://review.opendev.org/c/openstack/nova/+/800086 | |
| 16:41:47 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support move ops with extended resource request https://review.opendev.org/c/openstack/nova/+/800087 | |
| 16:43:02 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] refactor interface attach with qos https://review.opendev.org/c/openstack/nova/+/800088 | |
| 16:45:33 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support interaface attach / detach with new resource request format https://review.opendev.org/c/openstack/nova/+/800089 | |
| 16:46:50 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] move unshelve test to the proper place https://review.opendev.org/c/openstack/nova/+/793621 | |
| 16:48:05 | opendevreview | Balazs Gibizer proposed openstack/nova master: WIP support extended res req in heal port allocation https://review.opendev.org/c/openstack/nova/+/802060 | |
| 17:27:46 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support move ops with extended resource request https://review.opendev.org/c/openstack/nova/+/800087 | |
| 17:28:53 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] refactor interface attach with qos https://review.opendev.org/c/openstack/nova/+/800088 | |
| 17:30:10 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support interaface attach / detach with new resource request format https://review.opendev.org/c/openstack/nova/+/800089 | |
| 17:30:11 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] move unshelve test to the proper place https://review.opendev.org/c/openstack/nova/+/793621 | |
| 17:32:42 | opendevreview | Balazs Gibizer proposed openstack/nova master: WIP support extended res req in heal port allocation https://review.opendev.org/c/openstack/nova/+/802060 | |
| 17:45:19 | gmann | gibi: ah I thought placement is in cycle-with-intermediary model but it is cycle-with-rc so need to wait for rc release. | |
| 17:47:13 | opendevreview | Samuel proposed openstack/nova-specs master: Migrate Instance Between Projects https://review.opendev.org/c/openstack/nova-specs/+/802034 | |
| 17:48:32 | opendevreview | Samuel proposed openstack/nova-specs master: Migrate Instance Between Projects https://review.opendev.org/c/openstack/nova-specs/+/802034 | |
| 17:50:28 | opendevreview | Samuel proposed openstack/nova-specs master: Migrate Instance Between Projects https://review.opendev.org/c/openstack/nova-specs/+/802034 | |
| 17:57:11 | gmann | gibi: stephenfin in that case we will release placement in rc1 right? which is after oslo feature freeze. with that we have to wait for one more cycle to get https://review.opendev.org/c/openstack/oslo.policy/+/801929 in oslo.policy ? | |
| 17:57:32 | gmann | I think that is how we handle such situation ? | |
| 18:00:05 | sean-k-mooney | to do a release of placement yes we wait until m3 and then can release a release candiate for placmeent | |
| 18:01:19 | sean-k-mooney | even if placment was cycle with intermediary it woudl not affect the oslo patch really | |
| 18:01:42 | sean-k-mooney | gmann: why do you think it would? | |
| 18:02:30 | gmann | sean-k-mooney: we have to release placement first in pypi for fix done for proposed interface changes in oslo | |
| 18:02:53 | gmann | otherwise placement in pypi fail with the latest oslo release which include the interface change | |
| 18:03:07 | sean-k-mooney | wotn we have the same issue with nova | |
| 18:03:11 | sean-k-mooney | or keystone | |
| 18:03:42 | sean-k-mooney | or any other project that are part of the integrated release | |
| 18:03:51 | gmann | technically yes but placement is used from pypi in nova tests so it block gate itself | |
| 18:03:54 | sean-k-mooney | we wont be able to increase upper constirting on master | |
| 18:04:21 | sean-k-mooney | you mena placment lib is used | |
| 18:04:30 | sean-k-mooney | i dont think we use placement directly | |
| 18:04:41 | gmann | if any using repo we use form pypi in gate testing then it would let oslo change merge itself, like placement | |
| 18:04:47 | sean-k-mooney | the placment fixture shoudl be in placment-lib | |
| 18:06:22 | sean-k-mooney | even if placment was release with intermiday it would not be correct to do a release in this case | |
| 18:06:49 | gmann | its in nova fixture | |
| 18:07:33 | gmann | no, with intermediate release model we can release new version of placement anytime in release where code moved to new interface from oslo | |
| 18:07:44 | gmann | so oslo gate would not complain | |
| 18:07:51 | sean-k-mooney | gmann: we coudl but we should not | |
| 18:08:06 | sean-k-mooney | it is like release nova early | |
| 18:08:07 | gmann | :) yeah. i am not saying we should change release model | |
| 18:09:04 | sean-k-mooney | gmann: we can merge the oslo change but pin the oslo verion until after xena | |
| 18:09:11 | gmann | I am saying with rc release model, we have to wait lib changing interface for at least one cycle. | |
| 18:09:17 | sean-k-mooney | but that could cause other isseu | |
| 18:09:30 | gmann | we cannot merge until we change the usage of placement form master not from pypi | |
| 18:09:36 | sean-k-mooney | gmann: right i am saying the right thing to do would be to wait regardless | |
| 18:09:53 | gmann | yes, at least 1 cycle | |
| 18:10:02 | sean-k-mooney | the other way is to not chnage the interface | |
| 18:10:10 | sean-k-mooney | and to support both in parallel | |
| 18:10:48 | sean-k-mooney | deprecating the old behavior | |
| 18:11:22 | sean-k-mooney | so add a new parmater to rule default | |
| 18:11:50 | sean-k-mooney | e.g. deprecated_rule_action=warn|raise | |
| 18:11:57 | sean-k-mooney | have that parmater default to warn | |
| 18:11:59 | gmann | its after deprecation things not fresh change, warn->error | |
| 18:12:07 | sean-k-mooney | then next cycle change it to raise | |
| 18:12:55 | sean-k-mooney | no this is a fresh change | |
| 18:13:07 | sean-k-mooney | you care chanign the behavior of oslo_policy | |
| 18:13:21 | gmann | no | |
| 18:13:22 | sean-k-mooney | so tha tdeprecation become an error | |