| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-10 | |||
| 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 | |
| 02:39:44 | ayoung | What makes that one interesting is that it is possibly a migration to the same hardware, but a different libvirst (in a container) | |
| 02:40:19 | sean-k-mooney | in both ovirt and kubevirt there isnt realy and nic state to recreate and if you are uing an external storage solution you can proably jsut reuse it since kubvirt allow much more acess to the xml | |
| 02:40:53 | sean-k-mooney | ayoung: i mean technically you can do that with openstack too | |
| 02:41:20 | ayoung | Right. Hence me being here and asking the question of people I trust to have the basis for answering. | |
| 02:42:03 | ayoung | The real question is if you could set up a system to do that, and to make it work with old deployments. | |
| 02:42:23 | ayoung | Like RDO liberty to OSP 17 | |
| 02:42:35 | sean-k-mooney | ayoung: https://www.redhat.com/en/blog/migrating-openstack-platform-13-openstack-platform-16-os-migrate | |
| 02:43:18 | ayoung | Never show stuff like that to sales.... | |
| 02:43:26 | sean-k-mooney | https://github.com/os-migrate/os-migrate | |
| 02:43:42 | sean-k-mooney | ayoung: its now offically a supported part of the product starting in 16.1 | |
| 02:44:01 | sean-k-mooney | it might be tech preview | |
| 02:44:21 | sean-k-mooney | im also not sure if it live or cold migration | |
| 02:44:57 | sean-k-mooney | Shut down the instances that are going to be migrated. Currently this OpenStack to OpenStack migration solution only supports cold migration. | |
| 02:45:02 | sean-k-mooney | so ya cold right now | |
| 02:45:45 | sean-k-mooney | if you know it was libvirt or osp on both end | |
| 02:45:55 | sean-k-mooney | you proably could make live migration work too eventurally | |
| 02:46:16 | ayoung | Like OSP 13 to 16 ... | |
| 02:46:19 | sean-k-mooney | this really isnt something supportable upstream in nova. | |