Earlier  
Posted Nick Remark
#openstack-nova - 2021-07-23
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
18:13:31 sean-k-mooney yes that is the api change
18:13:40 sean-k-mooney https://review.opendev.org/c/openstack/oslo.policy/+/801929/2/oslo_policy/policy.py#1243
18:13:49 gmann it is, already deprecated in previous cycle and this cycle changing warning to error
18:13:56 sean-k-mooney no
18:14:00 sean-k-mooney the policy rule is
18:14:23 sean-k-mooney but here we are changing the behavior of the RuleDefault class
18:14:53 sean-k-mooney the fact a project policy rule is deprecated does not mean the RuleDefault class usage is deprecated
18:15:18 sean-k-mooney https://review.opendev.org/c/openstack/oslo.policy/+/801929 is a new oslo.polify feature
18:15:26 sean-k-mooney which is a breaking change
18:15:59 sean-k-mooney so this need a oslo.policy major viersion bump since its not a additive change
18:16:09 gmann yes, major version bump
18:16:24 sean-k-mooney you can make it an addtivie chagne rather simply though
18:16:40 sean-k-mooney add a new parmater to the contructor of RuleDefault
18:16:59 gmann we did that in past via warning, not I am proposing to do a breaking change and remove the old ay
18:17:06 gmann *now I
18:17:21 sean-k-mooney right i am saying that is not a valid stragy
18:17:37 gmann humm, so keep supporting old way always?
18:17:44 gmann and keep warnings also?
18:18:02 sean-k-mooney no you need to wait until all or most of your users have adapted to the new api
18:18:07 gmann we introduced warning becasue we want usage to mvoe to new way right
18:18:22 sean-k-mooney when was the warnign intoduced
18:18:24 gmann sean-k-mooney: I did https://review.opendev.org/q/topic:%22fix-oslo-policy-warnings%22+(status:open%20OR%20status:merged)
18:18:43 gmann http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023646.html
18:18:46 sean-k-mooney basically i dont think you shoudl do this type of change late in the cycle
18:18:48 gmann ^^ has all the details
18:19:11 gmann we cannot do in this cycle, we have to wait for next cycle due to dependencies
18:19:16 sean-k-mooney i guess the issue is just the unit tests
18:19:24 sean-k-mooney can you show me where in nova we are importign placment
18:19:35 opendevreview Samuel proposed openstack/nova-specs master: Migrate Instance Between Projects https://review.opendev.org/c/openstack/nova-specs/+/802034
18:19:39 gmann https://github.com/openstack/nova/blob/master/nova/tests/functional/fixtures.py#L17
18:19:48 gmann sean-k-mooney: ^^
18:19:55 sean-k-mooney placement is not in our test requirements
18:20:01 sean-k-mooney im trying to figure out where it is listed

Earlier   Later