| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-23 | |||
| 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 | |
| 18:20:32 | sean-k-mooney | here https://github.com/openstack/nova/blob/master/tox.ini#L97 | |
| 18:21:17 | gmann | yes | |
| 18:21:44 | sean-k-mooney | we should not be importing the fixtuer the way we currently are | |
| 18:22:34 | sean-k-mooney | ... ok | |
| 18:22:44 | sean-k-mooney | that explians it we still have not create placment-lib | |
| 18:23:19 | sean-k-mooney | gmann: we were ment to move the fixture and other common code in a placement-lib repo cycle or two ago | |
| 18:23:23 | sean-k-mooney | looks like that never happened | |
| 18:23:45 | gmann | yeah | |
| 18:24:01 | sean-k-mooney | it was to aovid a direct import of placment so we could release the lib ahead of the main release and avoid this | |
| 18:25:29 | sean-k-mooney | this is kind of tricky | |
| 18:26:03 | sean-k-mooney | the best way to adress this would be to pin the oslo.plolicy version in nova func test until after placment is released | |
| 18:27:38 | sean-k-mooney | which i think we could do with oslo.policy<=${last version without error} here https://github.com/openstack/nova/blob/master/tox.ini#L96 | |
| 18:28:18 | gmann | we should not actually, and keep testing with latest oslo otherwise we can get more surprise. | |
| 18:28:47 | gmann | either moving placement fixture to lib side or do like current way 'wait for 1 cycle in oslo side' | |
| 18:28:54 | sean-k-mooney | well the other way is to deploy placment form master | |
| 18:28:59 | sean-k-mooney | on master | |
| 18:29:05 | gmann | yeah that too work | |