| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-26 | |||
| 14:02:59 | dansmith | but server actions are pretty much all not RESTful :) | |
| 14:03:08 | sean-k-mooney | so yes from that perspecive swap volume via update if fine | |
| 14:03:32 | sean-k-mooney | dansmith: yes by definition its acutlly a rest anti pattened to have rpc like api actions | |
| 14:03:56 | dansmith | right | |
| 14:04:26 | dansmith | so point is, I just don't think swap-via-update is super terrible in a fundamental way (swap in general may be) | |
| 14:04:35 | sean-k-mooney | i was ok with the PUT in the spec by the way. gmann was not so i proposed patch as a compormise | |
| 14:04:52 | dansmith | and I don't think that we need should justify using a different method externally because the internal plumbing is currently setup in one specific way | |
| 14:05:00 | sean-k-mooney | since the api method was free and it allowed used to expresss policy cleanly | |
| 14:05:01 | dansmith | that is the point of the api.. to abstract those things away | |
| 14:05:35 | dansmith | right, but where does it end? use HEAD for the next one? :) | |
| 14:06:02 | sean-k-mooney | no but patch is for a paritl update which is what we are doing | |
| 14:06:26 | sean-k-mooney | we are setting one atribute and not the rest | |
| 14:06:51 | sean-k-mooney | but as i said it was a compromise not the ideal solution | |
| 14:06:53 | dansmith | sure, but we're using a different http method because we just want to abuse the WSGI plumbing to call different code for this operation vs. the existing put | |
| 14:07:04 | dansmith | so when the next thing comes along, we could use HEAD and avoid having to abstract that one too :) | |
| 14:07:50 | sean-k-mooney | well head would only be apporpriate if the new action match the semantics of head but i get your point and i think you get mine | |
| 14:08:09 | sean-k-mooney | dansmith: in your view you would prefer that we keep with PUT correct | |
| 14:08:14 | dansmith | yes | |
| 14:08:27 | dansmith | and yes, HEAD is a silly example for the sake of being silly | |
| 14:09:04 | sean-k-mooney | i have not looked at gmann specific objection in a while but i belive it was related to the semaintic of the payload | |
| 14:09:16 | sean-k-mooney | do you have a proposal to adress his concern? | |
| 14:09:26 | dansmith | I don't know what his concern is | |
| 14:10:08 | sean-k-mooney | i think there was a question about including the volume id in the payload vs the url and how to correctly apply differnet policies to each sub filed | |
| 14:10:28 | sean-k-mooney | i belive we can already do a polciy check on the payload so that is not really a concern | |
| 14:10:37 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Block unsupported instance operations with accelerators. https://review.opendev.org/674726 | |
| 14:10:38 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Add cyborg tempest job. https://review.opendev.org/670999 | |
| 14:10:41 | dansmith | I don't see that as a problem yeah | |
| 14:10:50 | sean-k-mooney | but there was a question about if the volume shoudl be set in teh payload or just in the url | |
| 14:11:29 | sean-k-mooney | currently i think the volume id in the url is the current volume and the one in the payload is the one to swap too | |
| 14:12:17 | dansmith | well, that makes it even easier to determine what is going on right? | |
| 14:12:35 | dansmith | if they differ, then check admin policy, if they're the same, user policy and only look for user-changeable options in the body | |
| 14:12:35 | sean-k-mooney | i think we would have to require that its not set in the payload | |
| 14:12:55 | sean-k-mooney | well ya we could require they are the same | |
| 14:13:11 | dansmith | further, PATCH has to be atomic and provides no way to guarantee that the representation hasn't changed since I fetched it on the client side | |
| 14:13:33 | dansmith | so if someone has updated the definition between me fetching it and sending a single field to change, I might not notice | |
| 14:13:41 | dansmith | i.e. there's no generation or other indicator | |
| 14:13:43 | sean-k-mooney | honestly i could be miss remebering what gmann objection was | |
| 14:14:00 | sean-k-mooney | dansmith: yes that is also true | |
| 14:14:05 | dansmith | probably not likely on a volume attachment currently, but certainly could happen in the future | |
| 14:14:20 | dansmith | i.e. some sort of swap-snapshot-swap thing or something | |
| 14:14:32 | dansmith | (this is a major objection of mine to patch in general for most things) | |
| 14:14:46 | sean-k-mooney | i think the most likely issue would be with doing a volume detach via cinder in parralle | |
| 14:15:29 | sean-k-mooney | that said we have the same issue with PUT no? unless we have a genertion field in the payload | |
| 14:15:52 | dansmith | no, with put you have all the original fields there, you can check to see that nothing has changed | |
| 14:15:53 | sean-k-mooney | since put is ment to do a full update replacing all fields at least semantically | |
| 14:16:11 | dansmith | I'm not saying we *have* to for this specific case, but it's at least *possible* | |
| 14:16:18 | dansmith | also, looking at the api-ref here, | |
| 14:16:22 | sean-k-mooney | yes that is true | |
| 14:16:58 | dansmith | there's a big red warning about the whole api being obscure, because people would expect to be able to PUT that.. it would be a lot clearer to revise that and say "changing the volumeId requires special privileges and support" instead of just walling off all of PUT | |
| 14:17:03 | sean-k-mooney | anyway i was pretty nutral on this orginally so if there is a stong feeling (sounds like there is) that it should be PUT then im ok with that too | |
| 14:17:12 | dansmith | because people would say "What? why can't I change this flag without special virt support?" | |
| 14:17:42 | nightmare_unreal | how can I run nova functional tests ? | |
| 14:17:53 | sean-k-mooney | nightmare_unreal: tox -e functional-py36 | |
| 14:18:13 | nightmare_unreal | and for specific file ? -- -n file-name ? | |
| 14:18:34 | sean-k-mooney | you can do -- folowed by any arges supported by stestr | |
| 14:18:51 | sean-k-mooney | normally i just pass a regex for the class name or test name | |
| 14:19:06 | nightmare_unreal | cool :) Thanks | |
| 14:19:21 | sean-k-mooney | e.g. tox -e functional-py36 -- "compute|libvirt" | |
| 14:19:48 | nightmare_unreal | in quotes can i specify exact class name ? | |
| 14:19:55 | nightmare_unreal | like in your example | |
| 14:20:04 | sean-k-mooney | yes | |
| 14:20:11 | nightmare_unreal | awesome, thanks | |
| 14:20:21 | sean-k-mooney | the quote are jsut so the shell does not interperate the | as a pipe | |
| 14:20:54 | sean-k-mooney | so in this case is an or in the regex so that will run all gets with compute or libvirt in the fully qulified function name | |
| 14:21:29 | nightmare_unreal | understood | |
| 14:21:43 | gibi | dansmith, sean-k-mooney: from technical perspective I'm OK to have PUT or PATCH as well. I was convinced about both at some point in the past. From process perspective I feel bad that we might change direction of the API design 2 weeks before FF. | |
| 14:22:26 | gibi | I will raise the discussion again on the team meeting as I hope gmann will be there | |
| 14:22:31 | dansmith | gibi: I would hate to change our API so significantly on a process technicality | |
| 14:22:54 | dansmith | I'd much rather help brinzhang_ get it right, and/or approve a little extra time | |
| 14:23:09 | dansmith | the API stability is serious business to me and much more important to get it right than not | |
| 14:24:05 | gibi | dansmith: OK that is a good point. Let's double check with gmann but I'm OK to give extra time after FF if brinzhang_ needs time to change | |
| 14:24:16 | dansmith | meaning, it's not easily changeable later to allow something to land before a deadline | |
| 14:24:22 | dansmith | we have enough weird "huh, why is this different than *everything* else" warts on the API.. let's not make it worse | |
| 14:25:17 | openstackgerrit | Kevin Zhao proposed openstack/nova master: fix scsi disk unit number of the attaching volume when cdrom bus is scsi https://review.opendev.org/712607 | |
| 14:25:34 | PetrTuma | sean-k-mooney Hello, I had some time this week to test the https://review.opendev.org/#/c/703116/3 and the related issue in Rocky. I was able to reproduce original issue (thanks again for the help last week) and now I'm back to testing of the fix for that issue. Once again I updated code in my nova containers and I'm testing the rebuild between two | |
| 14:25:34 | PetrTuma | images (that differ in hw_numa_nodes and few other NUMA related properties). So far none of the rebuilds had been blocked. I added some extra logging to see whether the _validate_numa_rebuild method is actually called or not. It looks like it isn't, I don't see my message logged in any logs. I'm quite at loss what might be wrong. Do you have any | |
| 14:25:35 | PetrTuma | idea? | |
| 14:26:29 | sean-k-mooney | you updated the nova api container right | |
| 14:26:38 | PetrTuma | yes | |
| 14:26:56 | sean-k-mooney | just checking you didnt update the compute one :) | |
| 14:27:37 | sean-k-mooney | PetrTuma: what release is it? | |
| 14:27:44 | PetrTuma | Rocky | |
| 14:28:06 | dansmith | gibi: do you want me to circle back on that review and re-affirm my -1 with a summary here, or wait for the meeting or something else? | |
| 14:28:09 | sean-k-mooney | i tihnk rocky has the chagne that force the image to be checked if it changes | |
| 14:28:17 | sean-k-mooney | in older releases we did not do that | |
| 14:29:17 | sean-k-mooney | dansmith: you could propose a minor update to the spec with what you want to see? | |
| 14:29:32 | dansmith | I could | |
| 14:29:47 | openstackgerrit | Merged openstack/nova master: Non-Admin user can filter their instances by more filters https://review.opendev.org/701609 | |
| 14:29:53 | openstackgerrit | Merged openstack/nova master: Add default cpu model for AArch64 https://review.opendev.org/709494 | |
| 14:30:53 | PetrTuma | sean-k-mooney do you mean other change than the one I use? | |
| 14:31:49 | hrw | yes! | |
| 14:31:50 | gibi | dansmith: I would be glad for a summary back on the review | |
| 14:32:06 | sean-k-mooney | PetrTuma: yes so a cople of release ago we made a change to cause rebuild with a different image to query the schduler to determin if the current host was valid | |
| 14:32:28 | dansmith | gibi: okay | |
| 14:32:31 | gibi | dansmith: thank you | |
| 14:32:36 | sean-k-mooney | PetrTuma: that is one possiblity as to why this code is not beeing called. if it is not in rocky. although i tought that change was older then that | |
| 14:32:51 | gibi | dansmith: I will try to reach gmann to comment back | |
| 14:33:05 | gibi | dansmith: either on the meeting or separately | |
| 14:34:05 | PetrTuma | sean-k-mooney Ok, I'll try to find the change and confirm this, thanks for the moment | |
| 14:36:37 | gmann | reading logs... | |