Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-01-31
15:04:15 gibi gmann: yes
15:04:28 gmann 'changing behavior of " required=A&required=B " with microversion' is all good, I am thinking on for old microverison change
15:04:29 gibi btw efried is on gmann's side in the code review...
15:04:36 gmann which break users
15:04:47 sean-k-mooney gmann: it wont break users
15:04:57 sean-k-mooney gmann: user that have a duplciat request are already broken
15:04:58 gibi gmann: it breaks uses if the user query was wrong in the first place
15:05:03 efried ^
15:05:07 gmann sean-k-mooney: 200 to 400. when user asking with wring query
15:05:31 sean-k-mooney yes it will only be 400 for an invild query
15:05:38 sean-k-mooney where one of the requiremnt was being ignored
15:06:57 sean-k-mooney nova wont generate this but if we were to consider the isolated aggreates feature
15:06:59 sean-k-mooney https://docs.openstack.org/nova/latest/reference/isolate-aggregates.html
15:07:19 gibi I can imagine one case when we break a valid query. required=A,B&required=A,B is valid today and has a good meaning but it will be HTTP 400 after the fix
15:07:36 sean-k-mooney if we had &required:CUSTOM_LICENSED_WINDOWS&required:CUSTOM_SOMETHING_ELSE
15:07:43 sean-k-mooney the the isolated aggreate part would be lost
15:07:55 opendevreview Stephen Finucane proposed openstack/nova stable/wallaby: api: Reject duplicate port IDs in server create https://review.opendev.org/c/openstack/nova/+/827121
15:08:19 sean-k-mooney gibi: two idential values i guess we could check for and allow that
15:08:39 opendevreview Stephen Finucane proposed openstack/nova stable/victoria: api: Reject duplicate port IDs in server create https://review.opendev.org/c/openstack/nova/+/827122
15:08:51 gibi sean-k-mooney: we coudl but that gets complicate if we need to allow required=A,B&required=B,A as well
15:09:10 sean-k-mooney gibi: it does and i would still consider that to be invalid today
15:09:19 opendevreview Stephen Finucane proposed openstack/nova stable/ussuri: api: Reject duplicate port IDs in server create https://review.opendev.org/c/openstack/nova/+/827123
15:09:29 sean-k-mooney it makes logical sense but the parmater is not intended to be repatable today
15:09:30 efried IMO going into the weeds to allow special corner cases is not The Way. I think we should fix this, but it would be best to do it in a microversion.
15:09:46 efried And by "we" of course I mean "y'all" :P
15:09:50 sean-k-mooney efried: we cant backport it then
15:10:05 sean-k-mooney we can certenly fix it in a microverion if that is what we want
15:10:24 sean-k-mooney but if we do that we need to docuemnt that for older microversion only the last requires clasue will be used
15:10:34 gibi we have the microversion to fix it above in that series :)
15:10:37 sean-k-mooney and we need to ensure we dont break that goign forward for older microverion so tech debt
15:11:04 opendevreview Imran Hussain proposed openstack/nova master: [nova/libvirt] Support for checking and enabling SMM when needed https://review.opendev.org/c/openstack/nova/+/825496
15:11:04 sean-k-mooney gibi: yes i guess it fixed implictly by the new fature
15:11:10 sean-k-mooney *feature
15:11:11 gibi sean-k-mooney: yes
15:11:27 gmann f I am using it required=A,B&required=B with expectation that I need B (onerously wrong way) but it will be broken if we do without microversion
15:11:48 efried such is life. I thought the whole point of the microversion thing was that we weren't locked into major versions where we had to worry about backporting at all. You use whatever microversion you use, from whatever version of other stuff you are using, to support whatever features you need.
15:11:54 gmann and if we are changing the behavior with microversion then we are fixing it anyways so no need to fix for older microversion
15:12:08 efried ^
15:12:48 gmann gibi: if you would change it from 400 ever then we might think to do without microversion or not. otherwise it is like required=A,B&required=B is 200 now, required=A,B&required=B is 400 after fix required=A,B&required=B is again 200 with microversion
15:13:06 gmann * if you would change it from 400 always
15:13:08 sean-k-mooney efried: iguess we were just tryign to avoid operators having upgrade pain
15:13:11 gmann * if you would change it to 400 always
15:13:19 sean-k-mooney nova will not repeat the parmaters today
15:13:30 sean-k-mooney so for nova this wont matter one way of another
15:14:32 efried yeah, as usual the reality is that it is vanishingly unlikely that anything in the field is going to be affected by this fix; it's a matter of doing The Right Thing software hygiene process-wise.
15:14:58 gibi I feel more hygenic if we not silently ignore query params
15:15:00 sean-k-mooney right so hygine wise accepting known invlaid input to me is wrong
15:15:33 efried um, that's not the point. I don't think anyone is disputing that there's a bug. It's a matter of the proper procedure to get the fix done.
15:15:42 opendevreview Stephen Finucane proposed openstack/nova stable/train: api: Reject duplicate port IDs in server create https://review.opendev.org/c/openstack/nova/+/827126
15:15:49 gibi I cannot fix the bug on stable branches if it is requires a microversion bump
15:16:09 gmann efried: yeah.
15:16:10 efried stable branches of what?
15:16:14 sean-k-mooney placment
15:16:16 gibi placenet
15:16:20 gibi placement
15:16:49 efried And those stable branches affect... what? Only OpenStack?
15:16:51 gmann it is definitely a bug but our code has made it working in some way even with not expected result
15:17:27 gibi efried: this argument can be used for any placement change. should we then drop all placement stable branches?
15:17:38 gmann or may be expected results as we cannot say users would not be using it for query B only but in mistaken way of leaving duplicate query
15:18:09 efried IMHO documenting the old broken behavior for stable branches would be adequate.
15:18:54 efried Stable consumers who are affected and care can fix their query if they wish.
15:18:55 gmann gibi: sean-k-mooney efried I feel best way for existing user or stable is to update the api-ref "required=A,B&required=B is unexpected behavior until microversion 1.39 and after it work like returning both "
15:19:32 gmann yeah documenting it is enough I think when we are anyways fixing it with microversion
15:20:32 gmann that is how we do for any other bugs also right? 'fix in new microversion and old microverison it is bug and we donot fix'
15:20:39 sean-k-mooney gmann: well the primary reason for supprot it in 1.39 is for the any traits feature
15:20:55 gibi I don't believe that we want to keep around an incorrect behavior just because somebody might depend on it. but at the same time we say stable consumers can fix their query. I would say master consumer can fix their query too after we forbid the wrong behavior
15:20:58 gmann sean-k-mooney: yeah, I mean if we are fixing this query format too
15:21:00 sean-k-mooney gmann: if one of the repeated section does not use in: you still shoudl not be using it
15:21:33 gibi sean-k-mooney: after 1.39 you can repeate required without in: prefix as well
15:21:56 sean-k-mooney yes but im not sure we shoudl actully allow that
15:21:59 sean-k-mooney it simpler too
15:22:05 sean-k-mooney but its not useing the api as intended
15:22:15 sean-k-mooney we can allow it but i dont think we shoudl encurage it
15:22:29 sean-k-mooney after all it we have a limited query string lenght
15:22:42 sean-k-mooney and this is much more wasteful the jsut combining them
15:23:01 sean-k-mooney so it may be valild but not idiomatic
15:23:39 gibi I will be back in an hour
15:23:44 gibi sorry
15:24:08 sean-k-mooney sorry didnt want to burn you out either
15:25:00 sean-k-mooney im not really asking for you to expiclty block the repated case without in specificaly but i woudl like us to docuemnt that it shoudl only be used for that usecase ideally
15:25:59 gmann I think blocking it with microversion and asking to do via "required=A,B" is better way and saying "required=A,B&required=B" in older microversion is unknown behaviour
15:26:38 gmann or even "required=A,B&required=B" is unknown behavior is any microversion , do via "required=A,B"
15:27:02 sean-k-mooney ok if that is what peopel prefer but i dont like having to opt into correct behavior which is what that forces
15:32:38 gmann It was the same issue for nova query param too, we were ignoring the param and users might not get the expected behavior what they think will get. But we did not fix that without microversion and have to fix in new microversion to avoid breaking any users
15:33:31 gmann why I say it break users is we allowed our API to be used that way and it return something and we do not know what users expect with API to be used that wrong way, expectation might be what our code return now.
15:34:28 sean-k-mooney gmann: yes i understand your argument, i just find it hard to accpet that argument when we no any qurty that does this today is invalid
15:35:00 sean-k-mooney /qurty/query
15:35:54 sean-k-mooney if the perference is to document this which it seams you and efried perfer and only fix going forward as part of the new feature we can do that
15:36:28 sean-k-mooney its what gibi initally did before i raiesed the question in the review
15:37:17 gmann yeah, that is better way IMO. documenting the known bug until this microversion and with new version we fixed it.
15:37:18 sean-k-mooney well technially gibi put in functional tests to assert the current behavior for old microverison to ensure he did not break it
15:37:54 sean-k-mooney gmann: to me this is like intentiolly leaving a cve open but ok
15:38:04 sean-k-mooney we know it wont affect nova
15:38:14 sean-k-mooney sicne we never generate this edge case
15:39:04 sean-k-mooney ironic dpeloyed in standalone mode without nova today i dont think uses placment
15:39:36 sean-k-mooney so im not aware of an consumer of placment that are likely to hit this other then endusers making direct curl requests
15:39:56 sean-k-mooney so the impact really shoudl be minor
15:40:08 gmann I know, and its a bug and we have to accept/live with it for older microversion as this is what our API returned even wrong or right does not matter but in some cases it might return right-as-per-usage
15:41:53 sean-k-mooney gmann: i can say very clearly that if we had a customer that relied on this in any way we would not supprot there continued use of it at the expence of the rest of our customers
15:42:58 opendevreview Imran Hussain proposed openstack/nova master: [nova/libvirt] Support for checking and enabling SMM when needed https://review.opendev.org/c/openstack/nova/+/825496

Earlier   Later