| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-21 | |||
| 13:57:36 | dansmith | but then copied wrong :D | |
| 13:57:39 | sean-k-mooney | dansmith looks like you are right. the only config value that i see that effect this is the injected_files quota and changing the behavior based on that seams wrong | |
| 13:57:47 | mriedem | the docs builder doesn't actually fail on busted footnotes i don't think | |
| 13:58:04 | dansmith | mriedem: but I can look at the render and see if it looks right | |
| 13:58:12 | mriedem | regarding personality files, i will say, they are best effort and broken in lots of ways | |
| 13:58:41 | mriedem | as noted in my spec known issue, you lose them on unshelve, you lose them on evacuate, and you lose them if you're only relying on the metadata api and get migrated | |
| 13:58:47 | sean-k-mooney | mriedem: ya which is part of the reaosn we deprecated them. | |
| 13:59:06 | dansmith | I know, but it does kinda suck | |
| 13:59:24 | mriedem | i'm not disagreeing | |
| 13:59:32 | mriedem | it also seems like we kind of punted on fixing that long ago | |
| 13:59:41 | mriedem | when we talked for years about deprecating personality files, and then finally did it | |
| 13:59:43 | dansmith | and it sucks because we suck, not because throwing files in a disk image that we generate is icky for any other reason | |
| 13:59:51 | sean-k-mooney | on a pure policy basis do we/should we allow behavior changes that may break deprecated api features | |
| 14:00:16 | mriedem | meeting time | |
| 14:00:17 | dansmith | deprecated api features are no different than regular ones if they're still available, | |
| 14:00:28 | dansmith | and especially if they're still the default for the base api version | |
| 14:00:30 | dansmith | (IMHO) | |
| 14:00:36 | dansmith | no nova meeting for me, I have a conflict | |
| 14:00:37 | mriedem | agree ^ | |
| 14:00:46 | sean-k-mooney | ok | |
| 14:00:49 | mriedem | people can and do still use all this stuff on 2.1 | |
| 14:00:53 | mriedem | because that's what osc defaults to | |
| 14:01:27 | sean-k-mooney | ya true. maybe we shoudl fix osc to not default to that first :) | |
| 14:19:11 | bauzas | mriedem: just to understand correctly, you want some examples using osc-placement ? | |
| 14:19:24 | bauzas | so I need to use my hardware then | |
| 14:20:08 | bauzas | yay | |
| 14:20:13 | mriedem | bauzas: yeah | |
| 14:20:20 | mriedem | because the release note is just a lot of words, | |
| 14:20:35 | mriedem | but you really need to see an example on the command line to drive this home i think | |
| 14:20:45 | bauzas | okay, I'll try to get some commands | |
| 14:20:56 | bauzas | I still have a devstack node | |
| 14:43:59 | jackding | mriedem: Hi Matt, could you or other cores have a look at this please? It's been sitting there for quite a while. https://review.openstack.org/#/c/621646/ | |
| 14:47:35 | mriedem | efried: you'll want to jump in #openstack-release at some point | |
| 14:47:56 | mriedem | i added comments and re-word suggestions to the highlight patch https://review.openstack.org/#/c/644697/ | |
| 14:48:32 | sean-k-mooney | jackding: am we are cutting RC1 today so still in code freeze mode | |
| 14:49:06 | jackding | sean-k-mooney: ok didn't know that | |
| 14:49:07 | efried | mriedem: ack; what's the timeline on this, do I need to hit it or can we wait for melwitt? | |
| 14:49:16 | sean-k-mooney | jackding: master will open for train tomorow | |
| 14:49:23 | mriedem | efried: i think it's due today | |
| 14:49:44 | sean-k-mooney | jackding: not sure if this backportable but ill take a look again | |
| 14:49:55 | jackding | sean-k-mooney: will hassle cores later then :) thanks. | |
| 14:49:57 | mriedem | http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003952.html | |
| 14:49:59 | mriedem | efried: ^ | |
| 14:50:21 | mriedem | jackding: i can try to look when i'm not doing with release issues | |
| 14:50:25 | mriedem | *dealing with | |
| 14:50:56 | jackding | mriedem: great, thanks | |
| 14:51:52 | bauzas | hmmm, I thought we were tagging milestones automatically? | |
| 14:52:43 | bauzas | I don't see a 19.0.0.0b1 tag | |
| 14:53:59 | bauzas | mriedem: ^ | |
| 14:54:13 | mriedem | no | |
| 14:54:16 | bauzas | or are we done with milestones ? | |
| 14:54:17 | mriedem | not anymore | |
| 14:54:33 | bauzas | ok I missed this crucial info | |
| 14:54:42 | mriedem | bauzas: https://releases.openstack.org/reference/release_models.html#cycle-with-rc | |
| 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 | |