Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-01-04
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
17:55:45 sean-k-mooney qqmber: you should still look in to why it took 2 hours to boot
17:56:22 qqmber because it's a snapshot of 160GB and the host is pretty busy
17:56:24 qqmber that's all
17:56:28 sean-k-mooney unless you have reallly slow HDD and are copying TBs of root disk over 1G links it should not be that slow
17:56:50 sean-k-mooney i see
17:56:58 sean-k-mooney well if you know why i guess that is ok
17:57:05 qqmber sean-k-mooney: that's why I'm doing the snapshot, to take off those instances to a new cluster
17:57:07 qqmber a faster one
#openstack-nova - 2021-01-05
01:35:56 brinzhang0 gmann: hi
01:36:40 brinzhang0 gmann: https://review.opendev.org/c/openstack/tempest/+/769120 this tempest depends-on the nova patch, but it seems didnot active, could you give some guide?

Earlier   Later