| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-04-04 | |||
| 16:16:37 | bauzas | gibi: I'm ok with leaving it as one topic | |
| 16:16:50 | bauzas | gibi: I don't have anything more to say besides it | |
| 16:17:00 | sean-k-mooney | gibi: we used to have contibutor docs for recheck i dont think it will be contoverl to re add them to nova | |
| 16:17:15 | gibi | sean-k-mooney: that is a good action item | |
| 16:17:26 | sean-k-mooney | so i hope its more an FYI and then proceed to the gerrit doc review for main details | |
| 16:17:26 | gibi | bauzas: OK, lets keep it as is then | |
| 16:17:35 | bauzas | then let's move the CI point closer to the procedural section | |
| 16:17:38 | bauzas | gibi: ^ | |
| 16:17:53 | gibi | bauzas: I have no problem with that | |
| 16:18:04 | bauzas | done | |
| 16:18:22 | gibi | sean-k-mooney: top of the doc change I think we should start pointing to that doc when we see blind rechecks (i.e. apply peer pressure) | |
| 16:18:26 | gibi | bauzas: cool | |
| 16:19:20 | bauzas | gibi: yup, I think we agreed on ideally having a zuul reply that would provide this link but at least we can comment using this link | |
| 16:19:35 | bauzas | but let's not start the conversation by now | |
| 16:19:39 | gibi | yepp, I would you the link in my comment :) | |
| 16:19:42 | gibi | ack | |
| 16:21:05 | sean-k-mooney | gibi: we currently point to the shared contibutor doc but its kind of burried | |
| 16:21:22 | sean-k-mooney | so the shared one already tells peopel to not do a blind recheck | |
| 16:21:34 | sean-k-mooney | but again its not trivial to find that | |
| 16:23:22 | bauzas | ideally this should be a contributor doc, not a project doc | |
| 16:23:24 | sean-k-mooney | so here https://docs.openstack.org/nova/latest/contributor/code-review.html we have https://docs.openstack.org/infra/manual/developers.html#peer-review as the first line | |
| 16:23:31 | sean-k-mooney | bauzas: it is | |
| 16:23:46 | sean-k-mooney | in https://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing | |
| 16:24:07 | sean-k-mooney | point 2 | |
| 16:24:09 | sean-k-mooney | Examine the console log or other relevant log files to determine the cause of the error. If it is related to your change, you should fix the problem and upload a new patchset. Do not use “recheck”. | |
| 16:25:09 | sean-k-mooney | we link to that in our testing doc https://opendev.org/openstack/nova/src/branch/master/doc/source/contributor/testing.rst#voting-in-gerrit | |
| 16:25:14 | bauzas | sean-k-mooney: the point is, this is acceptable to do 'recheck something' | |
| 16:25:26 | bauzas | provided 'something' is meaningful | |
| 16:25:34 | sean-k-mooney | https://docs.openstack.org/nova/latest/contributor/testing.html#voting-in-gerrit | |
| 16:25:57 | bauzas | sean-k-mooney: add those links to the etherpad and we'll discuss it once we're at this topic | |
| 16:25:58 | sean-k-mooney | right but my point is its hard to find the exsing docs on when you should recheck | |
| 16:26:08 | sean-k-mooney | sure | |
| 16:29:34 | bauzas | sean-k-mooney: I don't disagree, this is tribal knowledge | |
| 16:29:47 | bauzas | hence why I'd have appreciated some automatic zuul reply with link | |
| 16:29:59 | sean-k-mooney | yes that is why i suggested doing that | |
| 16:30:19 | bauzas | sean-k-mooney: I think I expressed this beforehand :p | |
| 16:30:39 | bauzas | anyway, if there is a consensus, we should see how to do this | |
| 16:30:47 | sean-k-mooney | i know how to do this | |
| 16:30:49 | sean-k-mooney | its trivial | |
| 16:31:00 | bauzas | not for me :) | |
| 16:31:13 | bauzas | but I'll review you :p | |
| 16:31:15 | sean-k-mooney | update this https://github.com/openstack/project-config/blob/master/zuul.d/pipelines.yaml#L10-L12= | |
| 16:31:36 | sean-k-mooney | it currently links to the section that contians the guidence on when to recheck | |
| 16:32:07 | sean-k-mooney | this is part of the pipeline config so it affect all jobs in the pipeline | |
| 16:32:22 | sean-k-mooney | so it woudl be for all projects | |
| 16:32:49 | sean-k-mooney | we likely and update that to be more explcit and say do not recheck without first reading .... | |
| #openstack-nova - 2022-04-05 | |||
| 05:36:37 | opendevreview | melanie witt proposed openstack/nova master: block_device: Add DriverImageBlockDevice to block_device_info https://review.opendev.org/c/openstack/nova/+/826527 | |
| 05:36:37 | opendevreview | melanie witt proposed openstack/nova master: scheduler: Add an ephemeral encryption pre filter https://review.opendev.org/c/openstack/nova/+/760456 | |
| 05:36:38 | opendevreview | melanie witt proposed openstack/nova master: virt: Add block_device_info helper to find encrypted disks https://review.opendev.org/c/openstack/nova/+/826529 | |
| 05:36:38 | opendevreview | melanie witt proposed openstack/nova master: block_device: Add encryption attributes to image and ephemeral disks https://review.opendev.org/c/openstack/nova/+/826528 | |
| 05:36:39 | opendevreview | melanie witt proposed openstack/nova master: imagebackend: Add disk_info_mapping as an optional attribute of Image https://review.opendev.org/c/openstack/nova/+/826530 | |
| 05:36:39 | opendevreview | melanie witt proposed openstack/nova master: blockinfo: Add encryption details to the disk_info mappings when provided https://review.opendev.org/c/openstack/nova/+/772272 | |
| 05:36:40 | opendevreview | melanie witt proposed openstack/nova master: privsep: Move qemu-img create calls under nova.privsep.qemu https://review.opendev.org/c/openstack/nova/+/826750 | |
| 05:36:41 | opendevreview | melanie witt proposed openstack/nova master: privsep: Add encryption support to qemu-img create command https://review.opendev.org/c/openstack/nova/+/826752 | |
| 05:36:41 | opendevreview | melanie witt proposed openstack/nova master: privsep: Return QemuImgInfo objects from qemu-img info calls https://review.opendev.org/c/openstack/nova/+/826751 | |
| 06:45:01 | gibi | good morning nova | |
| 09:27:41 | Uggla | Hello guys, dumb question. Is there a preferred style syntax for string. I mean any preference for 'string' or "string" ? | |
| 09:31:04 | opendevreview | Wenping Song proposed openstack/nova-specs master: Usage of new trait of OWNER_NOVA https://review.opendev.org/c/openstack/nova-specs/+/836583 | |
| 09:34:09 | opendevreview | Wenping Song proposed openstack/nova-specs master: Usage of new trait of OWNER_NOVA https://review.opendev.org/c/openstack/nova-specs/+/836583 | |
| 09:38:36 | gibi | Uggla: no hard rule exists. I try to follow the style from the code around my edit (if that is consistent :D) | |
| 09:41:20 | sean-k-mooney | gibi: or we can have pre-comit do it | |
| 09:41:31 | gibi | yeah | |
| 09:41:31 | sean-k-mooney | there is a rule that will make them all '' | |
| 09:41:54 | gibi | but black would change everything so we would loose git blame and easy backport | |
| 09:41:54 | sean-k-mooney | i used it on one of my other repos personaly i prefer "" | |
| 09:42:14 | gibi | I use black for personal projects too | |
| 09:42:15 | sean-k-mooney | but i prefer machine enforced style more | |
| 09:42:21 | sean-k-mooney | oh i dont use black | |
| 09:42:31 | sean-k-mooney | i just use pre-commit + autopep8 | |
| 09:42:36 | gibi | ahh autopep8 | |
| 09:42:49 | gibi | can it only format the current diff? | |
| 09:42:57 | sean-k-mooney | i was suggesting we could use pre-commit to normalise the strings and have that run in the pep8 target | |
| 09:43:01 | sean-k-mooney | if we wanted too | |
| 09:43:16 | sean-k-mooney | yes | |
| 09:43:29 | gibi | then I'm supportive | |
| 09:43:35 | gibi | I use https://github.com/gibizer/blacken_selection in my IDE | |
| 09:43:48 | sean-k-mooney | but we already did the gloabl update for autopep8 but pre-commit only runs on the current diff by default | |
| 09:46:32 | Uggla | sean-k-mooney, is autopep8 will be "smart" enough to not broke strings like: "Share '0000:1222:1144:7777'" ? (strings where you want to display quotes). | |
| 09:47:53 | sean-k-mooney | autopep8 wont change this we would have to use a pre-commit hook. autopep8 is conservitive and tries to only enforce pep8 rules and sting format is not one of them | |
| 09:48:05 | sean-k-mooney | so we shoudl just test the hook. | |
| 09:48:17 | sean-k-mooney | https://pre-commit.com/hooks.html | |
| 09:48:24 | sean-k-mooney | double-quote-string-fixer | |
| 09:48:34 | sean-k-mooney | is the one i use in other repo | |
| 09:54:22 | Uggla | I have question regarding https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/libvirt-virtiofs-attach-manila-shares.html | |
| 09:55:18 | Uggla | Is there a reason to have an "attachmentId" ? Not saying that because I forget it... :) | |
| 09:58:33 | Uggla | this field is not used by the api. | |
| 10:02:29 | sean-k-mooney | yes | |
| 10:02:42 | sean-k-mooney | so a volume can have multiple attachments when its moving | |
| 10:03:19 | sean-k-mooney | althoguh this is a manilla share | |
| 10:03:28 | sean-k-mooney | so not entirly sure | |
| 10:03:35 | sean-k-mooney | i woudl ahve to read the spec again | |
| 10:05:49 | sean-k-mooney | Uggla so attachment id is the interanl id filed in the share_mappings table https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/libvirt-virtiofs-attach-manila-shares.html#data-model-impact | |
| 10:07:37 | sean-k-mooney | i think the intent is to allow the share to be assoated with teh vim but with differe exprot locations during move operations | |
| 10:08:03 | sean-k-mooney | but im not certin | |
| 10:08:23 | Uggla | sean-k-mooney, each line of the table is unique by the couple instance_uuid, share_id | |
| 10:08:50 | sean-k-mooney | i think attachment id was ment to be in the unique constraint | |
| 10:09:03 | sean-k-mooney | lyarwood: ^ if you are around | |
| 10:09:18 | sean-k-mooney | lyarwood: do you remember why we have attachment id | |
| 10:11:26 | sean-k-mooney | if the id filed is just intended as a primary key it should be an integer not a uuid so the fact its listed as a uuid is what is making me belive it for move operations | |
| 10:11:52 | Uggla | sean-k-mooney, I think I can add it easily, it is just to understand the purpose of it. | |