| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-01-17 | |||
| 16:36:51 | sean-k-mooney | dependign on review bandwith | |
| 16:36:56 | bauzas | sean-k-mooney: me too, but that still requires us some effort | |
| 16:37:24 | sean-k-mooney | i am a little worried for soem of them but hopeful we will land the majoriy of them | |
| 16:37:32 | bauzas | I mean, I know me, I'll need to put my review energy on the right way and an etherpad will help me to direct my energy productively | |
| 16:37:45 | sean-k-mooney | i dobth it will be too much over half | |
| 16:37:48 | bauzas | #link https://blueprints.launchpad.net/nova/antelope | |
| 16:38:02 | bauzas | you can find the list of those blueprints there ^ | |
| 16:38:28 | bauzas | #topic Review priorities | |
| 16:38:34 | bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2) | |
| 16:38:40 | bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | |
| 16:39:18 | bauzas | nothing to mention here | |
| 16:39:23 | bauzas | #topic Stable Branches | |
| 16:39:27 | bauzas | elodilles: floor is yours | |
| 16:39:38 | elodilles | #info stable branches don't seem to be blocked, but patches mostly need rechecks | |
| 16:39:47 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:39:54 | elodilles | and last but not least: Xena will transition to Extended Maintenance after the release of 2023.1 Antelope | |
| 16:40:00 | elodilles | so to prepare for that: | |
| 16:40:08 | elodilles | #info release patches were generated for *stable/xena* : https://review.opendev.org/q/topic:xena-stable+reviewer:sbauza%2540redhat.com | |
| 16:40:13 | sean-k-mooney | the release team proposed doign a release of several repos for xena. do we want ot wait for the tox pin to be merged | |
| 16:40:34 | elodilles | sean-k-mooney: which one do you mean? | |
| 16:40:45 | sean-k-mooney | the ones you were linking | |
| 16:40:46 | elodilles | (and that was all from me about stable branches) | |
| 16:40:59 | gmann | tox pin is merged for stable branches. it is done at central place in openstck-zuul-jobs repo | |
| 16:41:02 | bauzas | that's fun, stable branches are more stable than master :) | |
| 16:41:03 | sean-k-mooney | so we dont have the pin to tox<4 on xena yet | |
| 16:41:13 | sean-k-mooney | gmann: oh ok | |
| 16:41:22 | sean-k-mooney | i tought we needed to do it in the tox.ini too | |
| 16:41:28 | sean-k-mooney | so that it worked if you run tox loclaly | |
| 16:41:31 | gmann | let me check if osc-placement and python client is merged or not | |
| 16:41:40 | elodilles | no, the workaround was merged last week, as gmann says | |
| 16:41:51 | sean-k-mooney | will that work outside ci | |
| 16:42:17 | sean-k-mooney | im not sure hwo you can fix it centrally unless we did it in upper-constraits? | |
| 16:42:21 | gmann | yeah tox one is merged but this placement functional test this is not yet #link https://review.opendev.org/q/I4e3e5732411639054baaa9211a29e2e2c8210ac0 | |
| 16:42:32 | gmann | bauzas: sean-k-mooney elodilles ^^ | |
| 16:42:41 | elodilles | oh, i missed that somehow | |
| 16:42:45 | elodilles | will review ASAP | |
| 16:42:49 | bauzas | ack | |
| 16:42:51 | elodilles | sorry for that | |
| 16:42:52 | bauzas | tab open | |
| 16:43:07 | bauzas | I'll do my homework after the meeting | |
| 16:43:15 | sean-k-mooney | so my question still is not really answered | |
| 16:43:17 | elodilles | (the stable ones o:)) | |
| 16:43:19 | gmann | thanks | |
| 16:43:42 | sean-k-mooney | where is tox pinned in https://github.com/openstack/nova/blob/stable/xena/tox.ini | |
| 16:43:44 | elodilles | sean-k-mooney: in that case we can wait until the xena one merges :) | |
| 16:43:47 | bauzas | sean-k-mooney: how to cap tox under 3 ? | |
| 16:43:58 | gmann | sean-k-mooney: only for CI. you mean to pin it in tox.ini itself ? | |
| 16:44:01 | bauzas | under 4, I mean | |
| 16:44:24 | sean-k-mooney | yes so that developers can also run tox locally to test backports | |
| 16:44:45 | gmann | sean-k-mooney: if we want to fix it for local run to make sure we do not run it with tox4 then yes we need to pin in tox.ini also but that can be done if we really need | |
| 16:44:47 | sean-k-mooney | i was asking should we do that before doing the final release for extended mainance | |
| 16:45:33 | elodilles | hmmm. good question. | |
| 16:45:44 | bauzas | that sounds doable to me | |
| 16:45:45 | gmann | for local run I think both way ok either make sure we have tox<4 in our env or pin it in tox.ini | |
| 16:46:04 | sean-k-mooney | i replciated the pin in ci downstream | |
| 16:46:32 | gmann | we did for python-novaclient https://review.opendev.org/c/openstack/python-novaclient/+/869598/2/tox.ini#4 | |
| 16:46:35 | gmann | #link https://review.opendev.org/c/openstack/python-novaclient/+/869598/2/tox.ini#4 | |
| 16:47:27 | sean-k-mooney | yes | |
| 16:47:38 | sean-k-mooney | so do we want to do it for all the other nova delivberable | |
| 16:47:46 | elodilles | then i'm OK to do the same and release after that merged | |
| 16:47:50 | sean-k-mooney | if so we should do it before the em tansition | |
| 16:48:35 | elodilles | yes, I'm OK with that, I don't see now any reason not to do it before the transition | |
| 16:49:56 | elodilles | (the generated xena release patches don't have deadlines, but best not to postpone them for weeks) | |
| 16:50:28 | bauzas | ok, sounds an agreement, we just need an owner | |
| 16:50:53 | sean-k-mooney | i can do it for os-vif maybe some of the others | |
| 16:51:00 | bauzas | ack | |
| 16:51:02 | sean-k-mooney | its really just one line and ensuring it works loocally | |
| 16:51:10 | bauzas | I know | |
| 16:51:12 | elodilles | sean-k-mooney: ping me if i forgot the reviews o:) | |
| 16:51:52 | bauzas | anyway I guess we're done with this topic and we have a specless blueprint ask in a sec | |
| 16:51:59 | bauzas | so, moving on | |
| 16:52:17 | bauzas | #topic Open discussion | |
| 16:52:30 | bauzas | (sean-k-mooney) https://blueprints.launchpad.net/nova/+spec/default-ephemeral-format-unformated | |
| 16:53:03 | sean-k-mooney | ya so tl;dr is currently we use libguestfs in two places in nova | |
| 16:53:12 | sean-k-mooney | file injection which is deprecated for a long time | |
| 16:53:25 | sean-k-mooney | and formating the filesystem of the addtional ephmeral disks | |
| 16:53:41 | bauzas | true | |
| 16:53:45 | sean-k-mooney | i would like to have a way to allwo tthe ephmeral disk to be unformated | |
| 16:53:53 | sean-k-mooney | making libguestfs optional | |
| 16:54:14 | sean-k-mooney | to the proposal is either add unformated to https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_ephemeral_format | |
| 16:54:28 | sean-k-mooney | or sligly cleaner add a bool opt to trun off the formating | |
| 16:54:35 | bauzas | what does the default value which is None ? | |
| 16:54:55 | sean-k-mooney | and i want to kwno if there is a prefernce and if we think this could be a spec or specless | |
| 16:55:02 | dansmith | either is okay with me, I guess format=unformatted seems better to me because it's just another option for an existing knob | |
| 16:55:31 | sean-k-mooney | i need to check the default of none but i belive it makes it os dependednt | |
| 16:55:36 | bauzas | sean-k-mooney: I see None as the default value, what's then the behaviour ? | |
| 16:55:38 | bauzas | ok | |
| 16:55:43 | sean-k-mooney | i need to dig into this a little more | |
| 16:56:04 | sean-k-mooney | but basically i wanted ot know if peopel think this is ok to do this cycle | |
| 16:56:13 | sean-k-mooney | or shoudl we discuss in the ptg and do it next cycle | |
| 16:56:14 | bauzas | I think this is a very small feature | |
| 16:56:19 | bauzas | self-containede | |
| 16:56:26 | dansmith | yeah no need for lots of discussion, IMHO | |
| 16:56:30 | bauzas | particularly if we go with adding a new value | |
| 16:56:56 | sean-k-mooney | ok so 1 i need to document what none does. 2 determin if it can disable the formating today alredy | |
| 16:57:02 | bauzas | true | |
| 16:57:10 | sean-k-mooney | and 3 if not add unformated as an option to expcitly do that | |
| 16:57:20 | bauzas | sounds a simple plan to me | |
| 16:57:34 | sean-k-mooney | so at a minium ill add a docs change to say what none does | |
| 16:57:45 | sean-k-mooney | and we can then evaluate in the gerrit review if we need unformated | |