Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-08-10
10:04:04 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Mock LoopingCallBase._sleep in rbd tests https://review.opendev.org/745512
10:04:15 lyarwood stephenfin: ^ something nice and trivial for you on a Monday
10:16:29 jsuchome lyarwood: good morning, I am wondering ... anything new about setup for https://review.opendev.org/#/c/743220/ ?
11:15:09 openstackgerrit Merged openstack/nova stable/train: catch libvirt exception when nodedev not found. https://review.opendev.org/745116
13:11:44 openstackgerrit Stephen Finucane proposed openstack/nova master: [Trivial] Remove wrong format_message() conversion https://review.opendev.org/744280
13:11:45 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Add helpers for suspend, resume and reboot of server https://review.opendev.org/741285
13:11:45 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Pass context, instance to '_create_guest' https://review.opendev.org/741286
13:11:46 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Reject non-spawn operations for vTPM https://review.opendev.org/741500
13:11:46 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Add emulated TPM support to Nova https://review.opendev.org/631363
13:11:47 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Add docs for vTPM support https://review.opendev.org/739213
13:11:48 openstackgerrit Stephen Finucane proposed openstack/nova master: Add type hints to 'nova.compute.manager' https://review.opendev.org/742863
13:11:48 openstackgerrit Stephen Finucane proposed openstack/nova master: Don't unset Instance.old_flavor, new_flavor until necessary https://review.opendev.org/741995
13:11:49 openstackgerrit Stephen Finucane proposed openstack/nova master: privsep: Add support for recursive chown, move_tree operations https://review.opendev.org/742864
13:11:49 openstackgerrit Stephen Finucane proposed openstack/nova master: Add type hints to 'nova.virt.libvirt.utils' https://review.opendev.org/742865
13:11:50 openstackgerrit Stephen Finucane proposed openstack/nova master: Add support for resize and cold migration of emulated TPM files https://review.opendev.org/639934
13:54:54 openstackgerrit Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to 'nova.pci' https://review.opendev.org/676209
13:54:54 openstackgerrit Stephen Finucane proposed openstack/nova master: mypy: Add nova.cmd, nova.conf, nova.console https://review.opendev.org/705657
13:54:55 openstackgerrit Stephen Finucane proposed openstack/nova master: rpc: Rework 'get_notifier', 'wrap_exception' https://review.opendev.org/741663
13:54:55 openstackgerrit Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to top-level modules https://review.opendev.org/705658
13:54:56 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: Expand type hints for nova.block_device https://review.opendev.org/742170
13:58:20 gbajson Hi, could anyone of you explain when Nova uses allocation values configured in nova.conf (e.g. cpu_allocation_rate), please?
13:58:40 gbajson As far as I understand, and tested, all allocation values are set in Placement
13:58:57 gbajson and values from nova.conf are being ignored.
14:00:05 sean-k-mooney cpu_allocation_rate cpu_allocation_ratio?
14:00:19 gbajson My bad, cpu_allocation_ratio
14:00:24 sean-k-mooney they need to be configured on the compute nodes
14:00:37 sean-k-mooney setting it on the contoler is nologer supported
14:01:08 sean-k-mooney before the intodcution of placment you coudl set tehm in the schdluer config but that is nolonger correct.
14:01:25 gbajson ok, but I have just unconfigured them completely on compute nodes, and I still control allocation rates through Placement
14:01:34 sean-k-mooney yes
14:01:37 gbajson so I am wondering if they are still used/needed
14:01:54 sean-k-mooney when they are not set it used the initial_allocation_*ratio values instead
14:02:24 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.initial_cpu_allocation_ratio
14:02:45 sean-k-mooney initial_cpu_allocation_ratio is use when first creating the RP
14:03:04 sean-k-mooney it defaults to 16
14:03:51 gbajson initial_cpu_allocation_ratio seems to be ignored too. By default it's 16.0 but I set up 2.0 through in Placement and I can only use 2* PCPUs on the compute node
14:03:56 sean-k-mooney initial_cpu_allocation_ratio will set the default value for the placment RP VCPU inventory allocation ratio
14:04:13 gbajson ok
14:04:27 sean-k-mooney it will not change the value of an existing RP
14:04:33 sean-k-mooney and it does not apply to PCPUs
14:04:47 sean-k-mooney PCPU inventories should always be set to 1.0
14:04:56 gbajson ok
14:05:42 sean-k-mooney so initial_*_allocation_ratio are ineteded for wehn you want to manage the ratios via the placment api
14:05:44 gbajson So, if I understand correctly, values set in Placement override cpu_allocation_ratio, right?
14:05:57 sean-k-mooney the *_allocation_ratios are for when you want to manage the values via the config
14:06:20 sean-k-mooney if cpu_allocation_ratio, is set it will orverride any value you set in plamcnet
14:06:26 sean-k-mooney back to the value in the config
14:06:39 sean-k-mooney if you want to manage it via placment cpu_allocation_ratio, should not be defiend
14:06:54 gbajson thanks
14:07:16 sean-k-mooney https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#allocation-ratios
14:08:06 sean-k-mooney the api driven approch is given as an example in the usage_senairos sectoin
14:08:09 sean-k-mooney https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#usage-scenarios
14:10:36 gbajson Is it possible *not to use Placement* in Rocky+ releases?
14:10:45 sean-k-mooney no
14:11:00 sean-k-mooney well not if you are using the filter schulder
14:12:04 sean-k-mooney the chance and caching schduler techniclaly dont need placment but neither should be used in production
14:12:37 gbajson OK, that explains all my concerns! Many thanks for help Sean
14:12:43 sean-k-mooney both are removed in later relases
14:12:48 sean-k-mooney no worries
14:34:49 openstackgerrit Stephen Finucane proposed openstack/os-vif master: mypy: Add type annotations https://review.opendev.org/745162
14:34:50 openstackgerrit Stephen Finucane proposed openstack/os-vif master: mypy: Extend type annotations to 'vif_plug_noop' https://review.opendev.org/745163
15:20:00 openstackgerrit Stephen Finucane proposed openstack/nova master: fakelibvirt: Remove nova-network remnants https://review.opendev.org/737329
15:20:00 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Add type hints https://review.opendev.org/744869
15:20:01 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Drop 'vpn' parameter from 'allocate_for_instance' https://review.opendev.org/744870
15:20:01 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Remove unused 'affect_auto_assigned' parameter https://review.opendev.org/744871
15:20:02 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Remove 'kwargs' from 'get_instance_nw_info' https://review.opendev.org/744872
15:39:32 stephenfin melwitt: when you're caffeinated, could you take a look at https://review.opendev.org/#/c/744958/ again? I think I resolved all of your comments
15:44:39 melwitt stephenfin: ack will do (and +1 to the caffeination that is needed haha)
15:46:54 stephenfin Thanks :)
17:44:59 openstackgerrit Merged openstack/nova stable/rocky: objects: Update keypairs when saving an instance https://review.opendev.org/743268
23:51:52 openstackgerrit sean mooney proposed openstack/nova master: Deprecate filters that have been replaced by placement filters https://review.opendev.org/745605
#openstack-nova - 2020-08-11
01:43:44 ayoung Dumb idea time. Say I wanted to live migrate a VM from one openstack instance to another, across cluster boundaries. Would this be at all feasable?
02:23:24 sean-k-mooney ayoung: only by using libvirt directly and then manuly updating the db
02:23:36 sean-k-mooney ayoung: in other words no not really
02:23:46 sean-k-mooney ayoung: not in any way that would be supportable by nova
02:25:37 ayoung Of course it would be horrible. But so is leaving a cluster in place because it has key workloads.
02:26:35 ayoung So, yeah, diret libvirt would be necessary, and the receiving cluster would need to be able to take that running VM and make a database entry for it. On the old host, you would need to finish the migration and then set the VM into a non-runnable mode, too.
02:26:58 sean-k-mooney the eaiser approch would be to snapshot the vms and then copy the images and restore them on another cloud
02:27:01 ayoung So, say I needed to do something like this to migrate ahead to Victoria
02:27:14 ayoung Yeah, but that means downtime, right?
02:27:27 ayoung We can snapshot and restore today
02:27:57 sean-k-mooney the live snapshot would not but you would hten need to restore the snapshot (createing a second instance of the applcaiotn) and somehow sync there state
02:28:05 ayoung openstack vm --steal <source>
02:28:46 sean-k-mooney if you looking for a solution before the end of they year it will need to be somethign you develop your self unfortuntely
02:28:56 sean-k-mooney what versions are you dealing with
02:29:10 sean-k-mooney is it n to n+1 or multiple versions
02:29:19 ayoung Oh, old stuff by your standards. OSP 16 is...Train?
02:29:23 ayoung I'
02:29:36 sean-k-mooney ayoung: do you work for redhat
02:29:45 ayoung I'm really more interested in being able to talk someone thriough waht it would take and why it is a bad idea
02:29:59 ayoung Yep, I work for Red Hat. I used to be Keystone core, but now I see stuff....
02:30:03 ayoung sell stuff
02:30:13 sean-k-mooney well its a bad idea in general because you cant assume two openstack clouds are using the same hypervior
02:30:21 sean-k-mooney one could be libvirt and the other vmware
02:30:27 sean-k-mooney in which case you cant live migrate
02:30:46 sean-k-mooney ayoung: ah ok im in the compute dfg
02:30:55 ayoung Nah, that is not a problem. We know it is all libvirt when we are talking about this. People have old clusters...I have one on RDO Liberty....
02:31:17 sean-k-mooney yes so there is the paralle cloud migration work that is being done
02:31:50 ayoung I suspect that even the live migrationm would not make them happy, but I need to be able to talk it through. I suspect that the payloads would not suffer the cloud split anyway.
02:31:54 sean-k-mooney that works by runing basicaly a proxy vm on each cloud that can acess the hosts running the vms then it somehow orchestrates the migration betwen the clouds

Earlier   Later