| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-04 | |||
| 14:42:29 | sean-k-mooney | but i think we call into os-brick | |
| 14:42:44 | sean-k-mooney | we call into os-vif to ensure the vifs are pluuged in init host | |
| 14:42:50 | sean-k-mooney | i expect we do the same for os-brick | |
| 14:43:14 | zoharm | ok, we want to keep this change out of nova for now since its specifically deals with only volumes | |
| 14:43:51 | zoharm | unless you think its better to add it to nova | |
| 14:44:13 | sean-k-mooney | dose os-brick have an inialise function? | |
| 14:44:22 | zoharm | for volume connection? | |
| 14:44:36 | zoharm | there is init for the connector which is called when its loaded up for first time | |
| 14:44:41 | sean-k-mooney | no for the lib in general | |
| 14:44:46 | sean-k-mooney | os-vif has https://github.com/openstack/os-vif/blob/master/os_vif/__init__.py#L24 | |
| 14:45:04 | sean-k-mooney | which is called when the compute agent start to tell os vif to load all its plugin dirvers | |
| 14:45:05 | zoharm | i dont know, but i think that is not best place to put this re-init agent entrypoint | |
| 14:45:19 | zoharm | do you know if nova ends up calling os-brick connect_volume during host_init? | |
| 14:45:45 | zoharm | if it does, then that solves everything for us because connect_volume is currently the entry point | |
| 14:46:31 | zoharm | we dont want to launch this agent when os-brick or connector loads (since all connectors / os-brick are loaded for every service and we dont want this agent running everywhere, only where nvme volumes are connected via the connector) | |
| 14:46:35 | sean-k-mooney | im just reading https://github.com/openstack/nova/blob/b0f241e5425c99866223bae4b404a4aa1abdfddf/nova/compute/manager.py#L956 now | |
| 14:46:54 | sean-k-mooney | for each instance we call _init_instance in init_host | |
| 14:47:37 | sean-k-mooney | this is where we ensure the network interfaces are set up https://github.com/openstack/nova/blob/b0f241e5425c99866223bae4b404a4aa1abdfddf/nova/compute/manager.py#L1137 | |
| 14:48:26 | zoharm | im looking through it too now, found _init_volume_connection but it is not called during init_host | |
| 14:48:58 | zoharm | back to python-daemon, do you think it is not ok to propose this new depedency? | |
| 14:51:35 | sean-k-mooney | you could but do you need too | |
| 14:51:40 | sean-k-mooney | what benifit will it provide | |
| 14:56:50 | zoharm | it will allow to run this agent as a single independent process that will keep running regardless of the different services that may spawn it | |
| 14:57:25 | sean-k-mooney | ok but then how to you interact with it and manage its lifetime | |
| 14:57:30 | zoharm | and we can have it terminate itself when no connections are left if needed | |
| 14:58:22 | zoharm | we dont need to interact with it much, the interaction is mostly spawning it, and then it will be calling volume backend API for its functionality | |
| 14:59:22 | sean-k-mooney | based on what? i will need to have some set of input and know when a nvme volume attachemt is made | |
| 14:59:24 | zoharm | once it runs it basically just monitors local nvme connections belonging to it (it can tell them apart) and calling volume backend if necessary | |
| 15:00:02 | zoharm | the nvme connector connect_volume is called when nvme volume attachment is made, and that is the entry point where we ensure the agent is running | |
| 15:01:07 | zoharm | certain agent implementation is vendor specific, but it can tell by reading nvme device related dev paths information about where it came from | |
| 15:01:19 | zoharm | and backend provides metadata | |
| 15:01:28 | openstackgerrit | Merged openstack/python-novaclient master: Fix a functional test for 'nova agent-list' https://review.opendev.org/c/openstack/python-novaclient/+/769066 | |
| 15:02:05 | zoharm | basically what the agent does is reconcile metadata from backend with physical connection state on host (this is mostly for mdraid replicated volumes) | |
| 15:02:20 | sean-k-mooney | im reading the spec now but i dont think this agent really fits in the project scope fo os-brick | |
| 15:03:03 | zoharm | i understand your concern, this is where we settled on putting it for now | |
| 15:03:05 | sean-k-mooney | it really does seam like an indepenet service similar to multipathd rhater then a capablity a libviary shoudl be providing | |
| 15:03:20 | zoharm | good point | |
| 15:03:55 | sean-k-mooney | well im concerend that this is a possibel ddos vector for the cinder api or storage backend depending on how it monitors the conenctiions and what api calls its makink | |
| 15:04:17 | sean-k-mooney | e.g. if i have a 1000 node deployment and i install this on all notes how will that work | |
| 15:05:03 | sean-k-mooney | this agent will spawn a monitoring task which will repeat | |
| 15:05:05 | sean-k-mooney | periodically. | |
| 15:05:23 | sean-k-mooney | does it need to be an agent or could it be a perodic task defined in os-brick | |
| 15:05:47 | sean-k-mooney | that is then elecitly run by the consumer of os-brick | |
| 15:06:36 | sean-k-mooney | "One key problem that would need to be addressed by this selection is a scenario | |
| 15:06:38 | sean-k-mooney | where compute service goes down, while the VMs continue operating (and their | |
| 15:06:40 | sean-k-mooney | volumes remain attached) - we don't want to lose this agent in this case. | |
| 15:06:42 | sean-k-mooney | " | |
| 15:06:56 | sean-k-mooney | that is the main motivator for a seperate deamon process right | |
| 15:07:48 | sean-k-mooney | https://review.opendev.org/c/openstack/cinder-specs/+/766732/12/specs/wallaby/nvme-agent.rst#71 | |
| 15:10:49 | zoharm | right | |
| 15:11:18 | zoharm | open to all suggestions here | |
| 15:14:40 | zoharm | we want it to be a periodic task that is launched only when nvme volumes are connected by the nvme connector | |
| 15:28:35 | kashyap | stephenfin: One more, sorry: vTPM 2.0 and TPM passthrough -- both are supported in upstream Train, yeah? | |
| 15:29:27 | stephenfin | kashyap: no, vTPM is supported since Victoria. TPM passthrough is not supported afaik | |
| 15:29:59 | sean-k-mooney | TPM passtough can only be done via pci passtough | |
| 15:30:12 | sean-k-mooney | but that is for stateless devices only | |
| 15:30:23 | sean-k-mooney | so using it wiwth a tpm which has state would be invalid | |
| 15:30:36 | kashyap | stephenfin: sean-k-mooney: Nod; thx. Context on these random questions, I got a ping elsewhere about these, so trying to fill in details | |
| 15:31:08 | sean-k-mooney | if cyborg had a TPM dirver it could provide a tpm to us and do the required cleaning but they dont as far as i know | |
| 15:31:37 | kashyap | stephenfin: I have one more: I take it, your recent virtio device addition work means, we now support all these devices, corecct? — | |
| 15:32:03 | kashyap | virtio-serial, virtio-vga, virtio-balloon, virtio-input, virtio-keyboard, virtio-mouse, virtio-tablet | |
| 15:32:06 | kashyap | Perhaps not the -mouse yet | |
| 15:32:21 | sean-k-mooney | you conflating different things | |
| 15:32:35 | kashyap | sean-k-mooney: What am I conflating? | |
| 15:32:39 | sean-k-mooney | virtio-serial has been supproted for year with the serial-console | |
| 15:33:08 | sean-k-mooney | virtio-ballon cant be turned off yet so you always get it because libvirt adds one we agreeed to change that | |
| 15:33:09 | kashyap | sean-k-mooney: Yeah; I know some of them have existed forever; all I care about is - does the latest upstream release support all the above devices or not | |
| 15:33:35 | kashyap | Right. (I know -balloon is supported; and we recommend it to turn off for especially the real-time cases) | |
| 15:33:37 | sean-k-mooney | virti-input i think is not but im not sure | |
| 15:33:51 | sean-k-mooney | kashyap: yes but right now you cant turn it off | |
| 15:33:56 | kashyap | (And I recall reviewing the -keyboard and -input patches from Stephen, recently) | |
| 15:34:02 | sean-k-mooney | you uses to be able to by disbleing mermoy stat monitoring | |
| 15:34:11 | sean-k-mooney | but at some point libvirt started always adding it | |
| 15:34:38 | sean-k-mooney | kashyap: im just sure what -input is | |
| 15:35:00 | sean-k-mooney | -tablet is definetly supported | |
| 15:35:03 | kashyap | sean-k-mooney: You mean not sure? | |
| 15:35:09 | kashyap | https://www.kraxel.org/blog/2016/09/using-virtio-input-with-libvirt/ | |
| 15:35:09 | sean-k-mooney | sorry yes | |
| 15:35:52 | sean-k-mooney | ya ok so stephenfin was changing that but i havent revied it in a while | |
| 15:36:04 | sean-k-mooney | but he wrote a nice table in the commit message | |
| 15:36:54 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/756552 | |
| 15:37:26 | sean-k-mooney | oh the table was in https://review.opendev.org/c/openstack/nova/+/756551/3 | |
| 15:40:37 | kashyap | sean-k-mooney: Right; inded, I was looking at that table a minute ago | |
| 15:41:04 | kashyap | Okay; thanks. I may come back with more "does upstream support X?" questions, if I can't figure it out myself :-) | |
| 17:06:41 | qqmber | Hi! How can I make a auth token to last longer? Because when I try to create a snapshot of a big instance takes around 120 minutes and fails because a 401 error, due a timeout ( auth expired). I tried to configure "expiration_time = 7200" in [cache] section, but no luck.... | |
| 17:06:46 | qqmber | in keystone.conf | |
| 17:08:37 | sean-k-mooney | you can use service tokens | |
| 17:08:45 | sean-k-mooney | but it should not take 120mins to spawn | |
| 17:09:15 | qqmber | hmmm... sorry, I don't get it.. what do you mean? | |
| 17:10:15 | qqmber | How can I use service tokens? Never did before.. | |
| 17:14:13 | sean-k-mooney | you have to configure them in the nova config | |
| 17:14:16 | sean-k-mooney | one sec | |
| 17:14:59 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/use-service-tokens.html | |
| 17:27:54 | lyarwood | qqmber: https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html might be useful assuming the instance is boot from volume? | |
| 17:28:15 | qqmber | sean-k-mooney: thanks | |
| 17:28:28 | qqmber | lyarwood: it does not boot from volume | |
| 17:38:03 | qqmber | sean-k-mooney: actually I'm in Pike.. and as says there.. is a change proposal... so.. I guess I can't use it in Pike :( | |
| 17:48:21 | sean-k-mooney | qqmber: it was added in pike | |
| 17:48:32 | sean-k-mooney | so that the first release you cna use it in | |
| 17:49:07 | qqmber | oh, cool. thx | |