Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-17
10:56:01 sean-k-mooney stephenfin: yes we will we already have accounted for that in his work
10:56:14 sean-k-mooney we support the soft pinning case for numa
10:56:20 stephenfin awesome
10:56:33 sean-k-mooney so we just need to ensure that we also pass back the info for non pinned guests
10:56:42 stephenfin Yup
10:56:44 stephenfin bhagyashris: Any other questions before I disappear for lunch?
10:56:57 sean-k-mooney so there should be a change in the cpu pinning spec that extend what he is doing for shared instances
10:57:47 sean-k-mooney * not spec but patch series
10:58:15 bhagyashris s so in that case it will consume both the inventories
10:58:15 bhagyashris stephenfin: but the host aggregates will come into picture only when the host are under that aggregate and that aggregate having meta data pinned and flavor also need to set the extra specs "aggregate_instance_extra_specs:pinned": "true" but as per the new implementation and flavor having new flavor extra specs (``resources:PCPU=1 and resources:VCPU=1``) and dont have "aggregate_instance_extra_specs:pinned": "true" extra spec
10:59:06 sean-k-mooney "resources:PCPU=1 and resources:VCPU=1" is not valid in train
10:59:23 sean-k-mooney bhagyashris: we can have the api reject instance with that config
10:59:29 stephenfin Yeah, you need to stop worrying about that. We can't and won't support it in Train
10:59:43 stephenfin In fact, we should have an explicit check to prevent that
11:00:18 stephenfin Until we get to U and submit a new spec for adding this functionality
11:00:38 sean-k-mooney stephenfin: bhagyashris ya we should alex_xu pointed out that there is already a check in the api tha validates the numa and pinning extra_specs are valide so we can extend it
11:02:27 bhagyashris stephenfin, sean-k-mooney : but ie user request it separately say in the first request he request resources:PCPU=1 and in second request he request resources:VCPU=1 then it will consume the resources form the same cpu_set
11:02:48 sean-k-mooney bhagyashris: what second request
11:02:57 sean-k-mooney do you mean two different vms?
11:03:08 bhagyashris sean-k-mooney : yes
11:03:14 sean-k-mooney that is fine
11:03:39 sean-k-mooney we will be allowing one vm with pinning and another with out pinning on the same host
11:04:01 bhagyashris sean-k-mooney : plz check this I have detailed the scenario here : http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007144.html
11:04:02 sean-k-mooney if and only if it has inveotry of both VCPU and PCPUs
11:04:34 sean-k-mooney bhagyashris: yes as i pointed out that is supported
11:04:54 bhagyashris sean-k-mooney : if that is fine then this is the violation to pinning feature
11:05:33 sean-k-mooney bhagyashris: its not, it would be if and only if you have not set cpu_dedicated_set
11:06:39 sean-k-mooney you will not be ably to support mixing vms until after you have cpu_dedicated_set and removed the use of vcpu_pinned_set
11:07:42 sean-k-mooney which mean operators should continue to use host aggrages to prevent mixing until they have modified there config to use the new feature
11:07:51 bhagyashris sean-k-mooney : but as mentioned in the spec if we have vcpu_pin_set set in the Stein and now it's upgraded to Train then will report both the inventory PCPU and VCPU and after that if user request two vim separately as we discussed above then
11:09:00 bhagyashris sean-k-mooney : I that case it will consume resources from same CPUs and I think that is wrong
11:09:11 sean-k-mooney we know
11:09:24 sean-k-mooney and we are going to allow that as that is the pre train behaviro
11:10:00 sean-k-mooney we are aware that in that case the floating instace can float over the pinned instances
11:10:29 sean-k-mooney but mixing vms on the same host will only be supported after you have defiend cpu_dedicated_set
11:10:31 bhagyashris sean-k-mooney : yeah and thats my concern
11:10:43 sean-k-mooney bhagyashris: we intentionlly want to allow that
11:11:04 sean-k-mooney bhagyashris: we need to allow it to allow inplace upgrade of nodes with running instances
11:11:04 bhagyashris sean-k-mooney : ok
11:14:12 sean-k-mooney one of the requirements for edge workload is we need to be able to do inplace upgrades without draining a host of instaces. going for Train to U we will remove the vcpu_pin_set option which means before upgrading to U you will need to updated your config to remove it.
11:15:34 bhagyashris sean-k-mooney : just want to clear some points 1. As we discussed above that the floating instace can float over the pinned instances is allowed for train release
11:15:56 sean-k-mooney its only allowed if cpu_dedicated_set is not defined
11:16:38 bhagyashris sean-k-mooney : if user request the both the resources:PCPU and VCPu resources in the same request then that should get rejected
11:17:16 sean-k-mooney if cpu_dedicated_set is defiend VCPU inventory will only be reported if cpu_shared_set is defiend. if both cpu_shared_set and cpu_dedicated_set are defiend then nova will soft pin floating cores to the cpu_shared_set cpus
11:18:03 sean-k-mooney bhagyashris: yes if the user request VCPUs and PCPUs in the same request it will be reject in the api as part of the boot request before we get to the schduler
11:19:54 bhagyashris sean-k-mooney : and if user sets only cpu_shared_set then in that case VCPU inventory will be reported right?
11:21:38 bhagyashris sean-k-mooney : and that will be used as shared cpu resources
11:22:37 bhagyashris sean-k-mooney : my concern is what will happen if inly cpu_shared_set is define
11:22:47 bhagyashris only*
11:22:52 sean-k-mooney yes if cpu_shared_set is defeind and vcpu_pin_set is not then only VCPUs will be reported
11:22:58 sean-k-mooney and we should soft pin to that set
11:23:43 sean-k-mooney if cpu_shared_set is defiend and vcpu_pin_set is defiend then we ignore cpu_shared_set for reporting to placement and do not soft pin the cpus to cpu_shared_set
11:25:06 sean-k-mooney bhagyashris: if they only define cpu_shared_set we soft ping floating instance to the cpu_share_set and only report VCPU for the cores enabeld in teh cpu_shared_set and dont report any PCPU inventory
11:25:48 sean-k-mooney so the soft pinning of floating instace will not be done if vcpu_pin_set is defiend and will be done in all other cases
11:26:29 sean-k-mooney we could allow it if all 3 values are defiend but i would prefer to treat that as an error
11:26:41 sean-k-mooney we can decided that in code reveiw
11:26:51 bhagyashris sean-k-mooney : ok
11:32:47 bhagyashris sean-k-mooney : I would just like to know about soft pinning
12:14:36 openstackgerrit Merged openstack/nova master: Add 'path' query parameter to console access url https://review.opendev.org/649372
13:29:04 openstackgerrit Boxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server https://review.opendev.org/645520
13:43:09 stephenfin sean-k-mooney: Not sure if you've got to them or not, but do all my replies so far match up with what you'd expected?
13:43:18 stephenfin RE: the cpu-resources spec?
13:47:11 sean-k-mooney more or less
13:47:23 sean-k-mooney you mean on the mailing list post right
13:47:59 sean-k-mooney the prefilter will default to false in the config
13:48:06 sean-k-mooney so on upgade it will be disabeld by default
13:48:41 sean-k-mooney as you are not ment to modify config as part of upgade that means that by default we will get inveoties of both VCPU and PCPU
13:49:14 sean-k-mooney then later we can enable the prefilter and add the dedicated_cpu_set and remove teh vcpu_pin_set
13:52:18 sean-k-mooney personally i had assumed that defineing the dedicated_cpu_set option is what would have done the reshape fo exisitng instances
13:53:43 sean-k-mooney reshape is a little impresise what i mean is modifying the allcoation for exsiting instance to consume PCPUs if needed
13:59:31 shilpasd Hi, can anybody help me to test live migration? i using openstack via devstack, and facing below error
13:59:33 shilpasd libvirtError: operation failed: Failed to connect to remote libvirt URI qemu+tcp://<vm_user>@<compute_node_name>/system: unable to connect to server at '<compute_node_name>:16509': Connection refused
14:00:08 shilpasd FYI: referred 'https://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/' for libvirtd.conf configuration
14:01:45 shilpasd after running telnet >>Unable to connect to remote host: Connection refused
14:02:07 shilpasd seems configuration issue, can anybody provide me any specific link for live-migration
14:05:13 mriedem efried: i've half a mind to revert this https://review.opendev.org/#/c/663502/
14:05:28 mriedem he removed an unused method but it's a regression to not be using that method
14:05:32 openstack Launchpad bug 1830260 in OpenStack Compute (nova) stein "Inefficient host_status lookup when listing servers with details (regression)" [Medium,Triaged]
14:05:32 mriedem https://bugs.launchpad.net/nova/+bug/1830260
14:06:20 mriedem but i guess it could be reverted when someone actually fixes the bug
14:06:57 efried mriedem: ack. in any case, I'd like to understand the path I should have taken as a reviewer to know about that bug and that using this method was a solution
14:07:38 mriedem it's not really your fault. i don't know, but i suspect takashi noticed it when i pointed out the regression in a recent-ish ML thread.
14:08:25 efried okay
14:09:41 efried mriedem: I guess a note in the bug mentioning the commit where it was removed so it can be reinstated?
14:09:58 efried ...reinstated when fixing the bug?
14:10:01 mriedem yeah good point
14:21:06 shilpasd mriedem: hi do you have few time, want to discuss @ live migration issue i am facing
14:21:30 sean-k-mooney so if im following correctly https://bugs.launchpad.net/nova/+bug/1830260 was really intoduced by https://review.opendev.org/#/c/584590/ when that stop calling the method that https://review.opendev.org/#/c/663502/1 removed
14:21:30 openstack Launchpad bug 1830260 in OpenStack Compute (nova) stein "Inefficient host_status lookup when listing servers with details (regression)" [High,Triaged]
14:23:15 sean-k-mooney should ^ have a stein-backport-potential tag
14:33:14 sean-k-mooney mriedem: by the way your cross cell resize series should be entering the runway in a day or so. i assume the reviewers guide you sent before is still pretty much accurate? ill try to start on the series again later this weeks but ill re read that in the mean time to reload the context
14:47:32 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Remove references to nova-consoleauth https://review.opendev.org/652965
14:47:32 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Stop starting consoleauth in functional tests https://review.opendev.org/652966
14:47:33 openstackgerrit Stephen Finucane proposed openstack/nova master: xvp: Start using consoleauth tokens https://review.opendev.org/652967
14:47:33 openstackgerrit Stephen Finucane proposed openstack/nova master: xvp: Remove use of '_LI' marker https://review.opendev.org/665425
14:47:34 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-status: Remove consoleauth workaround check https://review.opendev.org/652968
14:47:34 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove nova-consoleauth https://review.opendev.org/652969
14:47:35 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Remove ConsoleAuthToken.to_dict https://review.opendev.org/652970
14:47:35 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Rework nova console diagram https://review.opendev.org/660147
14:47:36 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Integrate 'sphinx.ext.imgconverter' https://review.opendev.org/665693

Earlier   Later