| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-10 | |||
| 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 | |
| 02:32:10 | ayoung | So migrate from Nova to proxy and then from Proxy to new cloud? | |
| 02:32:30 | ayoung | Ah, proxy VM, not proxy host | |
| 02:32:41 | sean-k-mooney | i think how its ment to work is the first recreate the flavors network imaves on the new cloud | |
| 02:32:50 | sean-k-mooney | both a new vm on the new cloud with thos imnages | |
| 02:33:05 | sean-k-mooney | then migrate the runing instnce form one cloud to the prepared vm on the new cloud | |
| 02:33:10 | sean-k-mooney | something like that | |
| 02:33:17 | ayoung | So the proxy is smart enough to "trick" the old and new Novas that all is well | |
| 02:33:43 | sean-k-mooney | i think the plan is to recreate the resouces on the new cloud with the same uuid/flavors ectra | |
| 02:33:49 | sean-k-mooney | e.g. spin up a nova managed vm | |
| 02:34:02 | sean-k-mooney | then swap out the root disk ectra using a migration | |
| 02:34:14 | sean-k-mooney | its totally a hack but its one thing that people are looking at | |
| 02:34:36 | sean-k-mooney | the proxy just provides connectivity between the cloud i think | |
| 02:34:36 | ayoung | So it is not a completely crazy idea, but it requires a substantial amoung of work to make it stable. | |
| 02:34:52 | sean-k-mooney | oh its crazy i would never use it in production or recommend it to customer | |
| 02:35:04 | sean-k-mooney | that does not mean that marketing dont like it and want to sell it | |
| 02:35:20 | sean-k-mooney | and there are people working on maiking it work | |
| 02:35:53 | sean-k-mooney | just because its a crazy idea does not mean its a worse idea then doing FFU form libverty to train | |
| 02:36:20 | sean-k-mooney | if your on osp 7 still it makes sense in a strange way | |
| 02:36:25 | ayoung | mind if I use " oh its crazy i would never use it in production or recommend it to customer" in my next deck? | |
| 02:37:13 | sean-k-mooney | i mean you can if you want | |
| 02:37:15 | ayoung | I am sure some sick bastid somewhere got live migration from vmware to libirt (or the reverse) working | |
| 02:37:30 | sean-k-mooney | its not something the compoent teams are currently plannign on supporting | |
| 02:37:52 | sean-k-mooney | it being developl by the upgrades dfg with input form the feild teams and support | |
| 02:38:13 | sean-k-mooney | vmware proablyt have the reverse working | |
| 02:38:30 | sean-k-mooney | ayoung: but realistitly its very unlikely | |
| 02:38:44 | sean-k-mooney | the virtual devices are completely differnt | |
| 02:39:03 | ayoung | I was actually thinking through the steps required for oVirt to Kubevirt and realized it was the same kind of problem | |
| 02:39:35 | sean-k-mooney | yes althoguh in that case i think there is less state to recreate | |