| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-21 | |||
| 14:54:43 | bauzas | I knew we weren't needing to provide a tag | |
| 14:55:07 | bauzas | gotcha, thanks | |
| 14:55:23 | bauzas | I was just wanting to checkout some m-1 tag for my devstack | |
| 14:55:54 | bauzas | but I'll rather checkout stable/rocky | |
| 14:56:13 | mriedem | if you check out stable/rocky you won't get the nested/reshaper stuff but ok | |
| 14:57:00 | bauzas | well, I want to verify the reshape using osc-placement | |
| 14:57:08 | bauzas | so I can provide some examples | |
| 15:11:54 | mriedem | cdent: looks like the vmware 3rd party CI is skipping live migration tests... http://207.189.188.190/logs/52/626952/9/check-vote/ext-nova-zuul/744e2c6/tempest_results.html.gz | |
| 15:12:17 | mriedem | kind of sucks to report in our prelude release notes that vmware supports live migration now but it's not tested | |
| 15:12:36 | mriedem | http://207.189.188.190/logs/52/626952/9/check-vote/ext-nova-zuul/744e2c6/tempest.log.gz#_2019-03-19_10_59_00_155 | |
| 15:12:54 | mriedem | i shall post to the ML so it's not your issue :) | |
| 15:16:01 | NobodyCam | Good Morning nova folks, can someone point me in the right direction to troubleshoot A instance not starting? I see the instance get scheduled I see a entry in the selected hosts compute log like: "Instance <BLAH> has been scheduled to this compute host, the scheduler has made an allocation against this compute node but the instance has yet to start" | |
| 15:16:54 | sean-k-mooney | NobodyCam: if you have got that far your next step is to check the nova compute agent log and see if it ever recived a boot request | |
| 15:17:43 | sean-k-mooney | if it did not then you shoudl check the nova-conductor log to ensure the down call from the conductor to the compute node was made. | |
| 15:18:10 | dansmith | sean-k-mooney: that message is from the compute log | |
| 15:18:13 | sean-k-mooney | if it was then the issue is related to rabbitmq and you shoudl check the memsage queue | |
| 15:18:47 | sean-k-mooney | dansmith: oh ok | |
| 15:18:58 | NobodyCam | sean-k-mooney: Thank you :) | |
| 15:20:27 | sean-k-mooney | NobodyCam: from dansmith reply given the message you quated is form the nova compute agent are there any errors? | |
| 15:21:24 | NobodyCam | no errors | |
| 15:21:36 | NobodyCam | Rabbit appears up and running | |
| 15:21:42 | NobodyCam | I see services connecting | |
| 15:22:23 | openstackgerrit | Merged openstack/nova stable/queens: Don't persist RequestSpec.requested_destination https://review.openstack.org/611945 | |
| 15:23:30 | sean-k-mooney | NobodyCam: if you grep for the instace uuid in the logs of the nova compute agent are there any results? if so coudl you share the last couple so we know howfar it got | |
| 15:24:34 | NobodyCam | just that message repeating itself several times | |
| 15:24:57 | dansmith | NobodyCam: that message is not an error | |
| 15:25:14 | NobodyCam | yea I not seeing nt errors | |
| 15:25:25 | dansmith | NobodyCam: it means that the scheduler picked that host but never got so far as to give it to the host to start, so the message is saying that it's ignoring that assuming the boot request will be coming in soon | |
| 15:25:29 | dansmith | that means it's finding it in the DB | |
| 15:25:31 | NobodyCam | conductor only has two messages with that uuis | |
| 15:25:35 | dansmith | so look elsewhere for logs, likely conductor | |
| 15:25:37 | NobodyCam | uuids | |
| 15:26:08 | NobodyCam | http://paste.openstack.org/show/hrQOgRtlb6g0GbZN1mfa/ | |
| 15:26:59 | sean-k-mooney | NobodyCam: what state is the instance in by the way? is it still building or in error? | |
| 15:27:14 | NobodyCam | building | |
| 15:27:34 | sean-k-mooney | and the task is still block_device_mapping? | |
| 15:27:47 | sean-k-mooney | or something similar | |
| 15:28:48 | NobodyCam | task-state is scheduling | |
| 15:29:52 | NobodyCam | http://paste.openstack.org/show/g2rPJbBSCo4Aj2KufVFN/ | |
| 15:31:14 | sean-k-mooney | that does not really make sense. https://docs.openstack.org/nova/rocky/reference/vm-states.html#create-instance-states | |
| 15:31:46 | sean-k-mooney | the condoctor is showing that it is creating the block device mappings in this case you were booting with epherial storage form an image | |
| 15:32:49 | dansmith | we really should have a condoctor service | |
| 15:32:53 | sean-k-mooney | so the vm shoudl be in in task state Block_device_mapping or spawning | |
| 15:33:23 | openstackgerrit | Surya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event https://review.openstack.org/636132 | |
| 15:33:40 | sean-k-mooney | and a super condoctor | |
| 15:33:44 | NobodyCam | yea, there is not ethereal requested with at flavor | |
| 15:33:45 | NobodyCam | http://paste.openstack.org/show/y7eD1LLJIlvkldWKOqFd/ | |
| 15:34:13 | NobodyCam | *ephemeral | |
| 15:34:52 | sean-k-mooney | NobodyCam: no what i ment is you are not usign boot from volume as the block device mappings show the root disk is local | |
| 15:35:13 | NobodyCam | ahh yes! | |
| 15:35:16 | sean-k-mooney | and from the flavor i can now see you have a root disk of 10G | |
| 15:35:55 | NobodyCam | yes! | |
| 15:36:18 | tssurya | dansmith: whenever you have some time, your opinion on https://review.openstack.org/#/c/636132/ would be highly valued/needed :) thanks in advance | |
| 15:38:12 | sean-k-mooney | anyway form the sequence diagarm of the boot state transition there is definetly somthing wrong. the only time the task state shoudl be in Schduling after the conductor started setting up the disk would be a rechedule after a failed spawn i think | |
| 15:38:32 | sean-k-mooney | unfortunetly the diagram does not capture the error paths | |
| 15:44:07 | efried | stephenfin: You seem like an obvious choice for nova/docs liaison https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation -- can I put you down? | |
| 15:44:22 | dansmith | tssurya: ack | |
| 15:44:35 | stephenfin | efried: I've already been appointed the oslo one so why not | |
| 15:45:07 | efried | stephenfin: you mean the oslo/docs liaison or the oslo/nova liaison? Cause I could totally put you down for that too. | |
| 15:45:17 | NobodyCam | thank you sean-k-mooney :) I will attempt to redeploy nova | |
| 15:45:23 | stephenfin | oslo/docs | |
| 15:45:36 | stephenfin | but sure, oslo/nova maybe makes sense too | |
| 15:45:41 | efried | k | |
| 15:47:45 | efried | Kevin_Zheng, nicolasbock: Y'all are currently down as the nova/docs liaisons https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation -- are you wanting to continue in that capacity? | |
| 15:48:36 | mriedem | efried: i think you could replace | |
| 15:49:16 | efried | ight | |
| 15:50:38 | efried | it seems pretty clear this list isn't used much for some of the categories. Not sure how much I ought to care about it. | |
| 15:59:03 | openstackgerrit | Merged openstack/nova stable/rocky: ironic: check fresh data when sync_power_state doesn't line up https://review.openstack.org/640772 | |
| 15:59:12 | openstackgerrit | Merged openstack/nova stable/rocky: pass endpoint interface to Ironic client https://review.openstack.org/643098 | |
| 15:59:15 | efried | jackding: Did you send out a ML post for https://review.openstack.org/#/c/621646/ warning of the ComputeDriver interface change? | |
| 15:59:26 | openstackgerrit | Merged openstack/nova master: Documentation for bandwidth support https://review.openstack.org/642064 | |
| 15:59:35 | openstackgerrit | Merged openstack/nova master: Add a prelude release note for the 19.0.0 Stein GA https://review.openstack.org/644412 | |
| 15:59:49 | efried | mriedem: looks like ready to cut rocky --^ ? | |
| 16:00:49 | mriedem | efried: yup i'll propose a release | |
| 16:00:57 | efried | k | |
| 16:02:51 | sean-k-mooney | jackding: the change you ping about before still looks good to me by the way | |
| 16:02:58 | gibi | efried: do you need anything else regarding https://review.openstack.org/#/c/645084/ ? | |
| 16:03:14 | jackding | efried: no. Do I need to? it's an optional parameter that has a default value. | |
| 16:03:50 | jackding | efried: not invoked by default | |
| 16:03:54 | efried | gibi: nope, just forgot. +A now | |
| 16:04:08 | gibi | efried: coolio | |
| 16:04:17 | efried | jackding: Any time the signature changes, even for an optional kwarg, it breaks OOT drivers. | |
| 16:04:34 | efried | jackding: We're not supposed to care about them, but I still have a soft spot in my heart. | |
| 16:05:20 | efried | gibi: Should we wait for that --^ for RC1? | |
| 16:05:33 | efried | I guess so, since it's renos | |
| 16:07:43 | efried | mriedem: you see anything else we should hold rc1 for? | |
| 16:08:03 | mriedem | efried: https://review.openstack.org/#/c/642863/ | |
| 16:08:41 | gibi | efried: yeah it is fixing the renos | |
| 16:08:48 | gibi | efried: so I would wait for that | |
| 16:10:20 | mriedem | the release patch can depends-on the known stuff you want to hold up for and then just adjust the hash when they land | |
| 16:11:34 | efried | don't see a lot of value in the depends-on if the content needs to be updated anyway. Just to stop them from automerging it? | |
| 16:11:44 | mriedem | yup | |
| 16:41:37 | openstackgerrit | Merged openstack/nova master: Fix links to neutron QoS minimum bandwidth doc https://review.openstack.org/645084 | |
| 17:01:00 | mdbooth | Could this be a source of random SSH failures in the gate: https://bugzilla.redhat.com/show_bug.cgi?id=1689933 ? | |
| 17:01:02 | openstack | bugzilla.redhat.com bug 1689933 in openstack-nova "[RFE] Add a simple way to enable random number generator on all flavor/image" [Unspecified,New] - Assigned to nova-maint | |
| 17:04:46 | kashyap | bauzas: mdbooth: efried: When you get a minute, please put this one out of its misery: https://review.openstack.org/#/c/641981/ (libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable) | |
| 17:05:08 | efried | kashyap: did you want that in RC1? | |
| 17:05:09 | bauzas | I'm just wrapping my head with devstack atm | |
| 17:05:22 | efried | Cause that's all we're gonna merge today. | |
| 17:05:24 | kashyap | efried: Would certainly be useful to get some initial testing | |