| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-23 | |||
| 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 | |
| 18:29:55 | sean-k-mooney | we coudl replace openstack-placement>=1.0.0 with -e git+https://opendev.org/openstack/placement.git@master#egg=placement | |
| 18:31:37 | sean-k-mooney | ok lets pick this up next weeks and see if thre is a way forward | |
| 18:35:21 | gmann | actually we should keep testing with released placement and if we want we can do with master version also so that we test both way. | |
| 18:36:35 | gmann | for oslo, I feel (from other usage also with pypi released version) is to wait for next cycle. This cycle I fixed almost all the usage in once they are released with oslo version supporting both way then 2, in next cycle remvoe old style in oslo | |
| 18:36:57 | gmann | that is best way to introduced the breaking change or major version bumo | |
| 18:36:59 | gmann | bump | |
| 18:37:22 | gmann | doing both in one cycle can break or mixup the things | |
| 19:17:48 | opendevreview | Samuel proposed openstack/nova-specs master: Migrate Instance Between Projects https://review.opendev.org/c/openstack/nova-specs/+/802034 | |
| 19:59:49 | opendevreview | Samuel proposed openstack/nova-specs master: Migrate Instance Between Projects https://review.opendev.org/c/openstack/nova-specs/+/802034 | |
| 20:12:22 | opendevreview | Samuel proposed openstack/nova-specs master: Migrate Instance Between Projects https://review.opendev.org/c/openstack/nova-specs/+/802034 | |
| 20:22:37 | opendevreview | Merged openstack/placement master: Add support for RP re-parenting and orphaning https://review.opendev.org/c/openstack/placement/+/784020 | |
| 20:35:36 | opendevreview | melanie witt proposed openstack/placement master: Add consumer_types migration, database and object changes https://review.opendev.org/c/openstack/placement/+/669170 | |