Earlier  
Posted Nick Remark
#openstack-nova - 2020-02-05
17:54:21 sean-k-mooney my isp decied to force recet my router again and broke my internet
17:54:23 sean-k-mooney yes
17:54:37 sean-k-mooney so i obvioulsy never wrote the updated draft
17:54:40 efried from what I could glean, "we" decided at some point that the blueprint could be specless.
17:54:54 sean-k-mooney yes i brought it up in the nova meeting
17:55:15 sean-k-mooney and we said if we spell out the minor changes need then it could be specless
17:55:22 efried great
17:56:52 sean-k-mooney umbSublime: this sliped off my radar sorry.
17:57:41 umbSublime reporting in o/
17:58:04 sean-k-mooney umbSublime: if you are still up for working on the code cahgne ill try and draft some worth in the ether path to describe what is needed. if you are happy with tem we can update the blueprint and i can help you with reviewing your patch
17:58:57 umbSublime Sounds good to me! I don't think I'll have much time to work on this this week, but next week should be fine!
17:59:34 umbSublime sean-k-mooney, in which etherpad would that be ?
17:59:56 efried sean-k-mooney, umbSublime: we'll want something in approvable form by next week (spec freeze).
18:00:08 sean-k-mooney https://etherpad.openstack.org/p/invtsc
18:00:15 umbSublime efried, I see
18:00:30 sean-k-mooney umbSublime: so looking at my private irc logs from talking to you in novemeber
18:01:05 sean-k-mooney i think the proposal was to add a hw:tsc_freq_mhz flavor extra spec
18:01:40 sean-k-mooney and a hw:invtsc=on|off extra spec
18:02:12 sean-k-mooney that would be how you requested the feature i the flavor
18:02:41 umbSublime yes iirc that's we had discussed last time. I'll have to read back my notes to
18:02:58 sean-k-mooney form a shcduler point of view we would need a new trait for invtsc support
18:03:17 sean-k-mooney which would be auto added if you enabled the flavor extra spec
18:03:41 sean-k-mooney and then the last bit was just the libvirt driver chagne to add the xml elements and report support
18:04:43 mriosfer Hi , where i can find a suported list of gpu supported by queens?
18:05:01 mriosfer sean: looks like hw:video_ram dont report vram to windows for some reason :S
18:05:07 sean-k-mooney umbSublime: do you want to take go at writing that up? or shall i?
18:05:42 sean-k-mooney umbSublime: i also linked https://review.opendev.org/#/c/671338/ to you as an example of how to add the feature just to refresh your memory
18:06:22 sean-k-mooney mriosfer: so in the image its hw_video_ram and you need to set hw_video:max_ram in the flavor i think
18:06:38 mriosfer yes i got it
18:06:45 mriosfer im going to double check
18:06:50 umbSublime Considering I'm not really familiar with the codebase yet, I think it would help me if you'd point me in the right direction (right I had forgotten that link). I'll read on this and take a closer look this afternoon. I'll report back if have any questions/concerns
18:08:49 sean-k-mooney umbSublime: ok i wont get to it today but ill write a rough draft of the chagne in the etherpad tomorrow. then we can update the blue print and review it with the nova team
18:09:35 sean-k-mooney umbSublime: would you be able to attend the nova team meeting tommorow in case people have questions about your usecase
18:09:39 umbSublime Thank you so much, I hope this isn't too much of a burden :/
18:09:47 umbSublime Yes I should be available tomorrow
18:10:55 sean-k-mooney well normally if we had more time its something that we would help to do. its almost the feature proposal deadline so it will need to be approve this week or next so i can help a little more then normal
18:12:17 umbSublime There a few few "newcoming contributer" docs out there for OS, but is there one more specific to nova I should up on ?
18:12:57 sean-k-mooney we do have a nova one im not sure if it differe much form the generic one let me see if i can find it
18:14:01 sean-k-mooney umbSublime: they are here https://docs.openstack.org/nova/latest/contributor/index.html
18:14:13 umbSublime \o/
18:15:33 sean-k-mooney umbSublime: you might find this one useful https://docs.openstack.org/nova/latest/contributor/how-to-get-involved.html
18:16:14 umbSublime I'll try and get up to speed on this tonight
18:38:41 openstackgerrit Merged openstack/nova master: nova-net: Remove now unnecessary nova-net workaround https://review.opendev.org/702440
18:49:39 openstackgerrit Eric Fried proposed openstack/nova master: WIP: refactor: Do network & accel discovery near volumes https://review.opendev.org/706083
18:49:53 efried dansmith: Does that ^ refactor look like what you had in mind?
18:51:21 dansmith efried: from a skim, yeah
18:52:58 efried dansmith: If so, my main objections to the preceding patch are addressed. The other bits I noted are still worth doing, but could conceivably be FUP'd if there's motivation not to respin the series.
18:53:16 dansmith ack
20:07:00 openstackgerrit Mykola Yakovliev proposed openstack/nova master: Fix boot_roles in InstanceSystemMetadata https://review.opendev.org/698040
20:33:24 sean-k-mooney umbSublime: i have updated https://etherpad.openstack.org/p/invtsc with what i think woudl be sufficent for the blueprint.
20:34:20 sean-k-mooney umbSublime: i have not spellchecked it and as efried will attest that is likely required.
20:35:05 sean-k-mooney ill add this to the end of the nova meeting agendra for tomorrow but if you are happy with the content can you update the blueprint.
20:49:43 umbSublime sean-k-mooney, thanks! I did a first pass on spellcheck. I think I'll wait until tomorrow to post it in case I think of something to add in the meantime
20:55:18 sean-k-mooney umbSublime: ya if you want to reframe the problem statement etc feel free
21:19:10 spatel sean-k-mooney: hey
21:20:21 spatel I am seeing strange performance issue, I am running erlang application on openstack instance which is giving me very poor performance but if i run same application on bare metal performance is really good
21:21:01 spatel I have created big VM and allocated all vCPU to instance so only single VM running on compute node..
21:21:17 spatel trying to understand where is the bottleneck
21:31:36 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Fetch 'Service' objects once when building AZs https://review.opendev.org/705653
21:31:37 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Merge unnecessary 'NovaProxyRequestHandlerBase' separation https://review.opendev.org/705655
21:31:37 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Bump minimum version of websockify https://review.opendev.org/705654
21:31:38 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Integrate mypy https://review.opendev.org/676208
21:31:38 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Remove 'run_once' helper https://review.opendev.org/705656
21:31:39 openstackgerrit Stephen Finucane proposed openstack/nova master: mypy: Add nova.cmd, nova.conf, nova.console https://review.opendev.org/705657
21:31:39 openstackgerrit Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to 'nova.pci' https://review.opendev.org/676209
21:31:40 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: mypy: Add type annotations to top-level modules https://review.opendev.org/705658
21:32:42 sean-k-mooney spatel: erlang is pretty memory sensitive so using hugepages in the gust and likely on the host for the vm should help
21:33:20 sean-k-mooney spatel: you shoudl also look into http://erlang.org/doc/man/HiPE_app.html
21:35:15 openstackgerrit Merged openstack/nova master: Handle neutron without the fip-port-details extension https://review.opendev.org/705760
21:38:42 spatel sean-k-mooney: i am using hugepage
21:38:52 spatel I have tried all possible best practices
21:39:56 spatel earlier i gave all CPU to vm (32 core) so thinking i should just create VM with 16 vCPU so it stay one side of NUMA zone to see how its performing..
21:42:30 sean-k-mooney ya numa affinitising the vm might help or create a dual numa guest
21:42:56 sean-k-mooney that would report the numa affintiy to erlang but if you are using hugepags it has a numa toplogy of 1 already
21:43:03 spatel I am only curious if i run same benchmark on bare metal then i get good result but if i run on VM then it gives poor result
21:43:16 sean-k-mooney what it could be is the cpu model
21:43:34 sean-k-mooney if you are not useing host-passthouhg you might not have all the cpu feature in the vm that you have in the host
21:43:36 spatel my CPU mode is passthrough
21:43:58 sean-k-mooney well if you have it numa affined and cpu passthohg
21:44:03 sean-k-mooney are you using cpu pinning
21:44:06 spatel Yes
21:44:11 spatel CPU pinning
21:44:27 sean-k-mooney then the only bottelnecs you have left are disk io or netwrok
21:44:52 sean-k-mooney what disk cache mode are you using
21:44:53 spatel I am using SR-IOV and not seeing any single packetloss or performance issue on network layer
21:45:08 spatel We have SSD
21:45:15 spatel not sure about disk cache mode?
21:45:47 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.disk_cachemodes
21:46:08 spatel I have noticed in SS command lost of packet getting in queue and increasing latency
21:46:29 sean-k-mooney file=writeback,block=writeback,network=writeback would be the highest performace setting in most cases
21:48:06 spatel hmm
21:48:27 spatel I will try that too
21:48:50 spatel is that kvm setting ?
21:49:34 sean-k-mooney ya its a setting for the libvirt dirver
21:49:38 spatel I have flavor setting numa_node=2
21:49:41 sean-k-mooney so in the [libvirt] section
21:49:58 spatel ok.. i will give it a try and see if that make any difference
21:50:22 spatel tomorrow i am going to run more erlang test and see where is the bottleneck.. i will keep you posted..
22:26:05 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Deprecate base rules in favor of new rules https://review.opendev.org/701624
22:26:31 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Fix os-attach-interfaces policy to be admin_or_owner https://review.opendev.org/705135

Earlier   Later