| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-20 | |||
| 09:12:44 | lyarwood | bauzas: I'm specifically trying to find the service version, not the package version btw. | |
| 09:12:50 | lyarwood | bauzas: https://github.com/openstack/nova/blob/stable/queens/nova/compute/api.py#L3976-L3998 for this | |
| 09:12:56 | bauzas | lyarwood: yup, I understood your question | |
| 09:13:14 | bauzas | but AFAIR, we don't expose the service versions, just the package versions | |
| 09:13:14 | lyarwood | bauzas: I'm thinking that there's an older compute still registered somewhere that's causing that to use the old legacy path | |
| 09:14:10 | lyarwood | kk thanks | |
| 09:15:54 | bauzas | lyarwood: this being said, the version field of the Service object is maybe expose thru the REST API | |
| 09:15:59 | bauzas | exposed* | |
| 09:16:59 | bauzas | meh, nvm | |
| 09:17:07 | bauzas | this would be a nova-manage thing | |
| 09:18:13 | bauzas | at least we don't return it to the API https://docs.openstack.org/api-ref/compute/?expanded=list-compute-services-detail#id368 | |
| 09:21:04 | bauzas | lyarwood: I think I found something interesting for your problem | |
| 09:22:27 | bauzas | lyarwood: the logs can emit some information about an old service when it starts https://github.com/openstack/nova/blob/master/nova/service.py#L72-L81 | |
| 09:34:05 | nightmare_unreal | hello is there a way to get nova cli output in json ? for e.g. openstack server list -f json give output in json. but there is no such thing(-format) in nova cli | |
| 09:38:32 | gibi | bauzas, lyarwood: the version notifications contain the service version https://github.com/openstack/nova/blob/master/doc/notification_samples/common_payloads/ServiceStatusPayload.json#L12 | |
| 09:39:02 | bauzas | gibi: ah good point, forgot it | |
| 09:39:04 | lyarwood | gibi: ah! thanks | |
| 09:39:44 | lyarwood | gibi: but that's only for active services right? | |
| 09:39:51 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Allocate mdevs when resizing or reverting resize https://review.opendev.org/712741 | |
| 09:40:04 | lyarwood | gibi: I'm assuming these computes are dead tbh so maybe the db is the only real way to tell | |
| 09:40:16 | bauzas | I had to modify again something I fixed locally | |
| 09:40:45 | bauzas | for some reason, my editor provided me a stale version of an old file | |
| 09:41:02 | bauzas | so my last commit reverted another fix I made | |
| 09:41:04 | bauzas | strange... | |
| 09:41:13 | bauzas | (I have to be cautious now) | |
| 09:41:18 | bauzas | Atom-- | |
| 09:44:34 | gibi | lyarwood: if you can interact with the service via the REST API then you can get the above notificaiton | |
| 09:44:40 | gibi | like when you disable it | |
| 09:45:09 | lyarwood | ack thanks | |
| 09:46:51 | bauzas | gibi: lyarwood: I don't think it's a crucial and secret information bit to expose the service object version thru the logs | |
| 09:47:47 | lyarwood | bauzas: for admins no I guess not | |
| 09:48:05 | gibi | bauzas: agree, this is not a secret for admins | |
| 09:48:08 | bauzas | just sayin', we could log something there https://github.com/openstack/nova/blob/stable/queens/nova/service.py#L166 (for DEBUG purposes) | |
| 09:48:26 | gibi | sure | |
| 09:48:49 | bauzas | we already do https://github.com/openstack/nova/blob/stable/queens/nova/service.py#L158 | |
| 09:49:04 | bauzas | lyarwood: feel free to file a patch ;) | |
| 09:57:55 | brinzhang | good morning all | |
| 09:58:39 | brinzhang | gibi: I am not sure which is true, but I replied something in https://review.opendev.org/#/c/720670/ | |
| 09:59:28 | brinzhang | Indeed, nova-cinder interaction and nova-neutron interaction have different result, if the xxxclient reports exception | |
| 10:03:24 | bauzas | stephenfin: gibi: fwiw, we said we could let it go https://review.opendev.org/#/c/712741/ | |
| 10:03:40 | bauzas | (don't leave it frozen) | |
| 10:04:06 | bauzas | okay, it was a terrible play of words | |
| 10:04:15 | bauzas | => [] | |
| 10:06:41 | brinzhang | bauzas: a nit inline ^ | |
| 10:07:22 | bauzas | brinzhang: can't see your comment :) | |
| 10:07:34 | gibi | bauzas: I will reply after lunch | |
| 10:07:46 | brinzhang | bauzas: my net so .. slowly | |
| 10:07:51 | bauzas | thanks migi and brinzhang | |
| 10:07:53 | gibi | brinzhang: same to you | |
| 10:07:58 | bauzas | oh shit, wrong mix | |
| 10:08:05 | brinzhang | gibi: thanks | |
| 10:08:07 | bauzas | thanks gibi | |
| 10:08:11 | bauzas | migi, gibi, dammit | |
| 10:08:39 | bauzas | ah, sad, he's not connected here | |
| 10:08:49 | brinzhang | bauzas: done | |
| 10:09:42 | bauzas | brinzhang: ack, good, can respin since Zuul hasn't replied yet | |
| 10:11:14 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Allocate mdevs when resizing or reverting resize https://review.opendev.org/712741 | |
| 10:16:00 | brinzhang | bauzas: thanks quickly update ^ | |
| 10:16:48 | brinzhang | bauzas: stephenfin working on change "import mock" to "from unittest import mock", https://review.opendev.org/#/c/714676/3 | |
| 10:17:47 | brinzhang | bauzas: does this [1] need to change? or wait for this merged, than stephenfin update that patch? [1]https://review.opendev.org/#/c/712741/6/nova/tests/functional/libvirt/test_vgpu.py@17 | |
| 10:17:52 | bauzas | I honestly think this is a rathole :) | |
| 10:19:13 | brinzhang | bauzas: yeah, I think so | |
| 10:20:57 | brinzhang | bauzas: https://review.opendev.org/#/c/712741/6/nova/virt/libvirt/driver.py@10111 need someone to check? I saw you add ? in | |
| 10:22:03 | brinzhang | others looks good to me | |
| 10:32:52 | bauzas | brinzhang: not sure I understand your question ? | |
| 10:33:10 | bauzas | brinzhang: do you mean that the comment is confusing ? | |
| 10:33:20 | bauzas | b/c it's a question ? | |
| 10:33:27 | brinzhang | yes, | |
| 10:33:50 | brinzhang | that should a note, right? | |
| 10:34:03 | bauzas | ahah, no, it's just something like 'verify if we need to assign some mdevs" | |
| 10:34:33 | bauzas | if it was a question, it would be a FIXME or a TODO | |
| 10:35:06 | brinzhang | bauzas: ah, yes, I think you missed TODO or FIXME tag | |
| 10:36:10 | bauzas | brinzhang: again, no | |
| 10:36:14 | bauzas | it wasn't a question for others | |
| 10:37:08 | brinzhang | You only put one question here, and there is no extra detail, I think it needs to be added, isn't it? | |
| 10:38:01 | bauzas | brinzhang: it's not really a question for others, it's just explain what the method does | |
| 10:38:07 | bauzas | it just explains* sorry | |
| 10:39:35 | brinzhang | it's ok, it really confuses me, maybe I should take it seriously. | |
| 10:39:41 | brinzhang | thanks bauzas ^ | |
| 10:41:01 | bauzas | I can provide a FUP if you want | |
| 10:56:44 | gibi | brinzhang: responded in https://review.opendev.org/#/c/720670 | |
| 10:57:43 | gibi | bauzas: I have started looking at https://review.opendev.org/#/c/712741/ just now | |
| 11:00:57 | brinzhang | gibi: I think your think make sense, agree, thanks | |
| 11:03:14 | brinzhang | this is an invalid bug | |
| 11:22:13 | songwenping | gb:Hi gibi. I am working on nova-cyborg-interaction now, and commit this patch https://review.opendev.org/#/c/720670/ | |
| 11:22:38 | gibi | songwenping: hi | |
| 11:22:50 | songwenping | We haven't show the ARQ id in dashboard now. | |
| 11:23:09 | songwenping | But i think we will show it like cinder volume. | |
| 11:24:05 | songwenping | So should we handle the cyborg exception after showing it? | |
| 11:24:06 | gibi | songwenping: still, expecting the end user to _know_ where and how to clean up after a seemingly _successfull_ server delete operations feels bad | |
| 11:24:58 | gibi | basically after every server delete the end user would need to check the cyborg API to know if the ARQs are freed up or not | |
| 11:25:09 | gibi | I don't like that | |
| 11:26:20 | brinzhang | gibi, songwenping: agree with gibi, if there are so many resources leaked in Cyborg, it will be a heavy works to cleanup | |
| 11:26:49 | brinzhang | but compared with Cinder logical, it also has the same issue. | |
| 11:27:32 | brinzhang | maybe we shuold have a logical to deal with this, or dealed in Cinder and/or Cyborg | |
| 11:33:23 | songwenping | gb:Yeah, it's indeed a problem leaking many resources in system. I just want to keep pace with cinder logical. | |
| 11:36:57 | gibi | songwenping: what is the use case you want to solve? you mentioned deploy and undeploy cyborg. there I think before undeploy the admin needs to clean up the cyborg users. Also mentioned failure in cyborg. If that failure is intermittent (e.g service restart or network interrupt) then I think end user needs to retry the delete. if the cyborg failure is static then that is a cyborg but to be fixed | |
| 11:37:20 | gibi | s/but/bug/ | |
| 11:43:24 | songwenping_ | gibi:i want to solve the second use case. | |
| 11:45:33 | brinzhang | gibi: I give you use case from my customer | |