| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-02 | |||
| 14:25:31 | ygk_12345 | cdent: efried yes | |
| 14:25:52 | ygk_12345 | cdent: how to validate it ? | |
| 14:25:59 | ygk_12345 | cdent: regarding cells ? | |
| 14:27:28 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.openstack.org/555081 | |
| 14:27:35 | cdent | listing your hypervisors | |
| 14:27:45 | cdent | I think you need to look at your n-cpu logs | |
| 14:27:48 | ygk_12345 | cdent: all the hypervisors are enabled | |
| 14:27:54 | mriedem | efried: i think that's this http://status.openstack.org/elastic-recheck/#1793364 | |
| 14:28:06 | ygk_12345 | cdent: where to look at the n-cpu logs ? | |
| 14:28:54 | cdent | ygk_12345: it depends on how you installed your openstack, but somewhere you have a nova-compute process, on the host which is or manage your hypervisor | |
| 14:29:41 | ygk_12345 | cdent: i see only nova-compute log in the hypervisor. Also I cant find any entry with the vm uuid in the nova-compute log | |
| 14:29:59 | cdent | nova-compute log and n-cpu log are the same thing | |
| 14:30:28 | cdent | the name depends on how things were installed | |
| 14:30:39 | ygk_12345 | cdent: ok then I dont find any vm uuid entries there and all seems to be fine on the hypervisor | |
| 14:32:11 | cdent | ygk_12345: then either in the conductor log or the scheduler log there should be some kind of error, after the timestamp of the "claim resources" | |
| 14:32:35 | cdent | grepping for the vm uuid won't be sufficient, you need to look through the log for an error or warning | |
| 14:33:28 | openstackgerrit | Hamdy Khader proposed openstack/nova master: Fix port update of host_id in case of baremetal instance https://review.openstack.org/649345 | |
| 14:35:38 | ygk_12345 | cdent: I find this in conductor log "Setting instance to ERROR state.: MessagingTimeout: Timed out waiting for a reply to message ID ef508c01e69841ae9f84356b7463165c" | |
| 14:35:56 | ygk_12345 | cdent: Failed to compute_task_build_instances: Timed out waiting for a reply to message ID ef508c01e69841ae9f84356b7463165c: MessagingTimeout: Timed out waiting for a reply to message ID ef508c01e69841ae9f84356b7463165c | |
| 14:36:31 | sean-k-mooney | ygk_12345: well that is the down call to the comptue to spawn the instance | |
| 14:36:41 | sean-k-mooney | i think | |
| 14:36:58 | cdent | ygk_12345: okay that's progress (in the sense of useful info). either your messaging bus (rabbitmq) is too busy or your conductor and compute host are unable to talk to one another over that bus | |
| 14:37:01 | sean-k-mooney | so on the compute you should be able to grep for ef508c01e69841ae9f84356b7463165c | |
| 14:37:16 | cdent | this might mean the compute node is misconfigured | |
| 14:37:35 | ygk_12345 | cdent: sean-k-mooney let me check | |
| 14:37:38 | sean-k-mooney | cdent: as in listneing to the wrong exchange | |
| 14:37:50 | cdent | ygk_12345: I'm sorry but I've got to go, good luck with it | |
| 14:38:28 | ygk_12345 | sean-k-mooney: i dont find any log entry on the compute node with that message ID | |
| 14:39:14 | ygk_12345 | sean-k-mooney: do u suspect its the rabbitmq issue with compute node ? | |
| 14:39:30 | sean-k-mooney | that would seam like the next most likely option | |
| 14:39:38 | ygk_12345 | sean-k-mooney: how to check that ? | |
| 14:40:03 | ygk_12345 | sean-k-mooney: but I dont think we made any changes to rabbitmq | |
| 14:40:14 | sean-k-mooney | am first you need to check the amqp setting in your nova.conf on both the conduction and compute node and make sure they are the same | |
| 14:40:51 | sean-k-mooney | the next thing to do would be to look a the topic queue and see if you can see the pending message | |
| 14:41:53 | ygk_12345 | sean-k-mooney: i see that all the rabbit servers are pingable from the compute node | |
| 14:44:15 | mnaser | jaypipes: around right now, ill do the explain | |
| 14:44:33 | ygk_12345 | sean-k-mooney: any idea ? | |
| 14:46:05 | mnaser | jaypipes: http://paste.openstack.org/show/748727/ | |
| 14:46:54 | sean-k-mooney | ygk_12345: have you logged into rabbitmq to see if the messages are still in the excahge queues | |
| 14:47:14 | ygk_12345 | sean-k-mooney: i dont see any queues around when I did list_queues | |
| 14:47:31 | ygk_12345 | sean-k-mooney: there r three rabbit containers | |
| 14:48:17 | sean-k-mooney | well presuably you are using the clustering plugin so from any of them you should see the same view | |
| 14:48:31 | ygk_12345 | sean-k-mooney: yes haproxy | |
| 14:48:41 | sean-k-mooney | haproxy is not the same thing | |
| 14:48:56 | ygk_12345 | sean-k-mooney: i see no error messages in the compute log | |
| 14:49:37 | sean-k-mooney | haproxy sits in front of rabbitmq and loadblances across the rabbit instances. but the 3 rabbitmq instance also need to be in a cluster. | |
| 14:49:57 | ygk_12345 | sean-k-mooney: yes it is openstack-ansible setup | |
| 14:50:13 | dansmith | this sounds like it's very not dev discussion? maybe you guys could move to #openstack? | |
| 14:51:15 | sean-k-mooney | perhaps although ygk_12345 i think the openstack ansible chanel might be able to help more | |
| 14:52:19 | sean-k-mooney | there is obviosly some issue between the compute node and the conducttor after the compute node filled up its disk and it appears to be related to rabbitmq | |
| 14:53:26 | ygk_12345 | sean-k-mooney: ok | |
| 14:56:15 | mnaser | btw, novnc has broken us and refuses to revert the thing that broke us: https://github.com/novnc/noVNC/pull/1220 | |
| 14:56:34 | mnaser | so CI currently installs novnc from packaging but anyone using the actual latest novnc will be broken | |
| 14:59:37 | dansmith | mnaser: so it looks like we need to do something on our end then | |
| 15:00:02 | jaypipes | mnaser: that's what I was afraid of... thanks. | |
| 15:01:26 | mnaser | dansmith: yeah, im not sure how we "do something on our end" because of the design architecture, it doesn't give you a way to pass that info, unless we implement our own vnc.html and store it in repo and serve it.. overlaid on top of the vnc code, it starts to be iffy | |
| 15:01:37 | mnaser | I pinned the novnc release in openstack ansible to avoid this but yeah. | |
| 15:01:41 | mnaser | jaypipes: :< you're welcome | |
| 15:02:26 | dansmith | mnaser: yeah, I'm guessing that is what they're saying, that we should provide our own implementation of the client (html) if we're going to do the auth part | |
| 15:02:56 | mnaser | dansmith: the weird thing is that the auth part, they have their own "token" stuff, including something called token_plugins which you can implement | |
| 15:03:10 | mnaser | but even if you implement a token plugin, you can't even use novnc without rewriting things.. I don't get it. | |
| 15:04:00 | dansmith | without rewriting an html file you mean right? | |
| 15:06:47 | dansmith | passing the token in path means we just get the token at the websocket url, right? | |
| 15:06:59 | dansmith | that'd be the right place to do the auth, so why is that a problem? | |
| 15:08:54 | dansmith | (looks further) yeah, that's where we're getting the token for our server side websocket | |
| 15:09:05 | dansmith | so I'm not sure why that's not a solution | |
| 15:10:49 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Add functional regression test for bug 1669054 https://review.openstack.org/649362 | |
| 15:10:50 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Do not persist RequestSpec.ignore_hosts https://review.openstack.org/649363 | |
| 15:10:50 | openstack | bug 1669054 in OpenStack Compute (nova) stein "RequestSpec.ignore_hosts from resize is reused in subsequent evacuate" [Medium,In progress] https://launchpad.net/bugs/1669054 - Assigned to Matt Riedemann (mriedem) | |
| 15:13:07 | kashyap | efried++ | |
| 15:13:24 | kashyap | (Hmm, should probably get a karma bot in here.) | |
| 15:17:35 | dansmith | no, we shouldn't. | |
| 15:19:49 | mnaser | dansmith: what if we did ?path=token -- thoughts? | |
| 15:20:01 | mnaser | then we can drop that whole path parsing thing and just grab all query params | |
| 15:20:32 | dansmith | mnaser: you mean path=$token instead of path=token=$token? | |
| 15:20:37 | mnaser | yeah | |
| 15:20:55 | kashyap | dansmith: Was only joking; where is your characteristic sense of humor... | |
| 15:20:56 | dansmith | you don't want to defeat the ability to actually use a path as part of that and have a proxy in between do you? | |
| 15:21:32 | dansmith | path=$token seems far more hacky than actually providing a legit url as the path | |
| 15:21:38 | mnaser | yeah, that is valid | |
| 15:22:00 | mnaser | the only concern I have now is *hopefully* that works for both old and new novnc | |
| 15:22:47 | dansmith | not sure why that matters, since we control our package versions (and it's up to the distro to match), but as far as I can tell, they didn't change the path behavior | |
| 15:22:50 | dansmith | or claim not to | |
| 15:25:23 | mnaser | dansmith: nova's CI actually installs novnc from distro pkgs which is probably why this wasn't caught | |
| 15:25:33 | mnaser | and yeah, the path behavior seems to always have been there and continued to be there | |
| 15:25:44 | dansmith | oh? I thought we had an u-c for it | |
| 15:25:55 | mnaser | nope, discovered this yesterday | |
| 15:26:17 | mnaser | we have u-c for Websockify probably | |
| 15:26:21 | mnaser | but novnc isn't even a python package so yeah | |
| 15:26:41 | mnaser | dansmith: https://github.com/openstack-dev/devstack/blob/358cc122c3a6d30bf043b3e478790fd2773e9a88/.zuul.yaml#L220 | |
| 15:27:22 | dansmith | okay | |
| 15:27:29 | dansmith | yeah I guess that makes sense actually | |
| 15:27:31 | sean-k-mooney | mnaser: oh your right we set NOVNC_FROM_PACKAGE=True | |
| 15:35:30 | openstackgerrit | Mohammed Naser proposed openstack/nova master: wip: start using ?path=%3Ftoken%3D= |
|
| 15:35:44 | mnaser | I don't have time to follow up on this too much but I guess its a start for someone to go through and start a discussion | |
| 15:36:26 | dansmith | seems like melwitt has some interest at least | |
| 15:37:14 | mnaser | yeah, so maybe that's the initial copy pasta which will probably fail | |
| 15:39:21 | cfriesen | sean-k-mooney: do you know if nova is supposed to handle PCI passthrough for Intel QAT devices? | |
| 15:39:28 | sean-k-mooney | yes | |
| 15:39:37 | sean-k-mooney | it has worked since before icehouse | |