| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-03 | |||
| 12:41:49 | sean-k-mooney | ok can we add the password one to https://etherpad.opendev.org/p/nova-runways-wallaby | |
| 12:42:01 | gibi | sean-k-mooney: the etherpad is up there it is just only brinzhang_ who put thing is nit | |
| 12:42:06 | gibi | thing in it | |
| 12:42:19 | brinzhang_ | sean-k-mooney: yeah, and I already used it to put cyborg support shelve/unshelve feature, and I will add the noVNC patch later in the runway | |
| 12:44:42 | gibi | zigo: looked at the diff but nothing popped out, so I guess it is bisect time. | |
| 12:45:02 | zigo | gibi: Thanks for looking, I'll try then. | |
| 12:45:12 | gibi | zigo: let me know what you found | |
| 12:45:30 | sean-k-mooney | yep so if we do noVNC then os-hyperviors then teants change? | |
| 12:46:10 | sean-k-mooney | that shoudl avoid it assumeing stephens paatch is already ready for review otherwise move os-hyperviors to 2.90 | |
| 12:48:08 | gibi | sean-k-mooney: as soon as we merging the first patch of the tenant_id referring internally to 2.88 (or any specific microversion) we commit to not have any other microversion bump merged until we finish the tenant_id work. I'm affraid of such commitment | |
| 12:49:02 | brinzhang_ | gibi: agree | |
| 12:49:58 | brinzhang_ | if I cannot complete it in Wallaby release, the 2.88 just suit for part of apis | |
| 12:51:05 | brinzhang_ | but if wait for all patches submited, and ready to review, there will be a heavy work | |
| 12:52:13 | gibi | there is no easy solution | |
| 12:52:14 | sean-k-mooney | brinzhang_: merging it would block all other api work however so really we need ti to be close before we merge the first patch | |
| 12:52:25 | vinay_m | hello every one, i have a devstack setup on a baremetal, and i have created a image out of snapshot of a openstack VM install with vepc software,when im launching vms with this image not able to ping or ssh , while vms with cirros or some other works fine | |
| 12:53:05 | vinay_m | not able to figure out what could be issue | |
| 12:53:16 | gibi | brinzhang_: let's make it so that I will review the open API patches in tenant_id, vnc and hypervisor series to see where we are now. | |
| 12:53:44 | sean-k-mooney | vinay_m: did you look at the console output to see if cloud init reran and updated the networking correctly | |
| 12:53:47 | zigo | It's super annoying: invidual unit tests are looking good, it's only when I start testing them all at once that I get failures ...:/ | |
| 12:54:31 | gibi | zigo: sh*t, I would like to help you. Is there any specific env setup that makes this appear? as I don't see it happening in the gate | |
| 12:54:39 | vinay_m | sean-k-mooney: yeah tried , but no log from this vm | |
| 12:54:42 | sean-k-mooney | vinay_m: if you had hardcoded macs or static ips the vm might just nto be getting the right ip | |
| 12:54:52 | zigo | gibi: I'll bisect and find out. | |
| 12:54:55 | gibi | zigo: anyhow I started running unit test on 22.0.1 in a loop now locally | |
| 12:55:02 | zigo | But it will take a long time... | |
| 12:55:09 | sean-k-mooney | vinay_m: there shoudl always be at least a minimal log is it actully booting correct | |
| 12:55:31 | brinzhang_ | gibi: the noVNC patch is ready to review now, IMO, it can be mereged firstly | |
| 12:55:43 | vinay_m | sean-k-mooney: same doubt , but status was showing active that's it | |
| 12:56:46 | brinzhang_ | the tenant_id just ready for the list servers apis change, except the policies changes, but after I get gmann's sugestions, I think it's easily to ready | |
| 12:57:18 | sean-k-mooney | vinay_m: and nothing form "openstack console log show <uuid>"? | |
| 12:57:39 | brinzhang_ | gibi: I am not similiar with the hypervisor series process | |
| 12:57:51 | vinay_m | sean-k-mooney: no console log | |
| 12:58:04 | sean-k-mooney | vinay_m: you might need to connect to libvirt directly and check but it sound like its not even getting to finding the os | |
| 12:58:14 | gibi | brinzhang_: I think you have to make progress with the tenant_id patches while we merges the other API impacts and then try to assess the situation to see if your patches can be merged in once | |
| 12:59:00 | sean-k-mooney | vinay_m: im not familar with vepc but if it used differnt disk buses or machine types it could cause the image to be unbootable | |
| 12:59:35 | gibi | sorry but from the overall nova developement progress perspective I have to prioritize the smaller API impacts first before we block the API changes due to the tenant_id work. | |
| 12:59:37 | vinay_m | sean-k-mooney: os i have used was ubuntu 18.0.4 | |
| 12:59:39 | sean-k-mooney | oh vepc is vEPC | |
| 13:00:03 | vinay_m | <sean-k-mooney> oh vepc is vEPC -> yes :-) | |
| 13:00:25 | brinzhang_ | From my current job, I may not be able to complete all of them, because I have to update the Cyborg Shelve /unshelve support patch, or the noVNC patch with my partner, and other jobs from my boss | |
| 13:00:33 | sean-k-mooney | i tought it was an image creation tool like disk image builder | |
| 13:00:49 | gibi | brinzhang_: does the tenant_id work has high priority from your perspective? | |
| 13:01:27 | sean-k-mooney | vinay_m: my best guess is there is someing in the vECP applcaition that is breakign the guest netorking | |
| 13:01:32 | brinzhang_ | gibi: is there a deadline line? maybe I can do some changes before the deadline | |
| 13:01:49 | gibi | brinzhang_: M3 is feature freeze | |
| 13:01:58 | sean-k-mooney | vinay_m: im not really sure we can help much unless you have a specific nova/libvirt errorr | |
| 13:01:59 | gibi | that is the deadline to land these changes | |
| 13:02:01 | gibi | in W | |
| 13:02:13 | brinzhang_ | gibi: it's lower than my boss's point | |
| 13:02:18 | brinzhang_ | when? | |
| 13:02:35 | sean-k-mooney | brinzhang_: m3 in march/april | |
| 13:02:37 | gibi | Marc 12 2021 | |
| 13:02:58 | sean-k-mooney | https://releases.openstack.org/wallaby/schedule.html yep | |
| 13:03:11 | gibi | brinzhang_: from my limited perspective the cyborg patches has higher prio than the tenant_id work as the cyborg patches finishing something we already started | |
| 13:03:44 | brinzhang_ | so if I want to complete this feature, I need to submit all changes before Marc 1 2021, otherwise there is no time to review and update | |
| 13:03:46 | vinay_m | sean-k-mooney: yes , i have thought same but i have tried this complete process in another devstack setup deployed in a ubuntu VM with same image , it worked over there | |
| 13:04:12 | sean-k-mooney | brinzhang_: ideally you would aim to finsih before that but ya | |
| 13:04:33 | brinzhang_ | gibi: yeah, the cyborg support patch is ready and it's closes to merge, hope you all to review | |
| 13:05:04 | gibi | brinzhang_: I suggest to focus on cyborg and the stuff that is higher on you boss's list | |
| 13:05:13 | brinzhang_ | sean-k-mooney: I am not sure I can complete, but I can try | |
| 13:05:16 | gibi | brinzhang_: as for me tenant_id can wait | |
| 13:05:48 | vinay_m | problem i'm thinking was with setup deployed on a bare metal .. will it ? | |
| 13:05:51 | brinzhang_ | gibi: Their priorities depend on my decision | |
| 13:06:34 | sean-k-mooney | vinay_m: if cirros/plain ubuntu is workign this is pointing to an issue with the vEPC config not with openstack | |
| 13:06:58 | brinzhang_ | gibi: yeah, after the shelve/unshelve patch merged, we will start the cyborg resume/paused support work, otherwise we will wait | |
| 13:07:01 | sean-k-mooney | brinzhang_: if you dont think you can complete the tenant work this cycle then we shoudl wait to merge it | |
| 13:07:19 | vinay_m | <sean-k-mooney> vinay_m: if cirros/plain ubuntu is workign this is pointing to an issue with the vEPC config not with openstack -> hoo ok | |
| 13:08:26 | gibi | brinzhang_: I know it is a pain to update such big series with a new api microversion number so I'm sorry but I still think we need to see the big picture and do that those rebases as we progress | |
| 13:09:36 | brinzhang_ | gibi: I said before, it's nothing | |
| 13:10:31 | gibi | brinzhang_: OK, then let's build up a series of tenant_id patches during the cycle, you can ping me to keep them reviewed, but we will not start merging the first one before we see more | |
| 13:10:33 | brinzhang_ | gibi: hope you all can review the patches, make it closes to merge except the microversion changes, maybe it's the smallest changes for me | |
| 13:11:28 | brinzhang_ | gibi: yeah, we can review but not merge it, I can accept this decision. | |
| 13:11:48 | gibi | brinzhang_: thank you for your understanding | |
| 13:12:28 | brinzhang_ | gibi, sean-k-mooney: NP, thanks again | |
| 13:13:52 | gibi | brinzhang_: o/ | |
| 13:52:41 | dcapone2004 | sean-k-mooney: I tried what you had suggested last night, and I think I need to pull the VM out and attempt to see what happens on a standalone libvirt kvm system....for some reason after start the VM, it would instantly automatically shut itself down | |
| 13:53:39 | gibi | stephenfin: when we removed os-fping in Rocky, did we intentionally kept the api doc for it in tree? | |
| 13:53:56 | sean-k-mooney | dcapone2004: ok i guess there might be a kernel panic or something | |
| 13:54:15 | sean-k-mooney | dcapone2004:in the windows guest | |
| 13:54:36 | dcapone2004 | sean-k-mooney: yeah not sure because I never am able to get to a console fast enough....Nova logs just show that instance stopped itself | |
| 13:55:21 | dcapone2004 | but the hypervisor=off parameter does get passed when it happens | |
| 13:55:44 | sean-k-mooney | ok so it still fails with hypervior=off | |
| 13:56:21 | sean-k-mooney | dcapone2004: you coudl also set hyperv to manual start in the windows service | |
| 13:56:30 | sean-k-mooney | that way when it crashs on start | |
| 13:56:36 | sean-k-mooney | you can check the system events | |
| 13:56:43 | sean-k-mooney | on the next boot in the vm | |
| 13:56:51 | sean-k-mooney | since it wont auto start | |
| 13:57:45 | dcapone2004 | I might try that but unsure if that will work either because the whole system immediately becomes unresponsive, so I dont know if anything even ends up logged | |
| 13:58:16 | lpetrut | hey, are instances automatically shutting down? nova might be doing it if db state says that it should be shut off | |
| 13:59:15 | dcapone2004 | ipetrut: it is a specific test case where I am trying to test something by shutting down and restarting an instance directly in libvirt instead of using the openstack api | |
| 13:59:37 | lpetrut | got it, that's expected behavior but it can be disabled | |
| 13:59:49 | lpetrut | just a sec, fetching the cfg opt | |
| 14:00:44 | dcapone2004 | original DB power_state: 4, current VM power_state: 1 | |
| 14:00:47 | lpetrut | you may want to use this so that Nova doesn't automatically turn the instance back off: http://paste.openstack.org/raw/800701/ | |
| 14:00:55 | dcapone2004 | help me with enum for the power states, that is what is showing in my logs | |
| 14:03:01 | dcapone2004 | just asked kolla to implement those changes, I'll report back in about 20 | |
| 14:03:35 | lpetrut | this is what you're seeing in the logs https://github.com/openstack/nova/blob/22.0.1/nova/compute/manager.py#L9622-L9627 | |
| 14:04:44 | lpetrut | unless those options are set, Nova will change the DB instance state when the instance is shut down through external actions. when it comes back up, nova enforces the db state and stops it again | |
| 14:08:03 | dcapone2004 | yeah except the message was confusing to me because it said "shutdown by itself", when in fact I just started it was libvirt | |