| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-01 | |||
| 07:37:46 | brinzhang | gmann: are you around? | |
| 07:38:55 | brinzhang | gmann: I dont understand what are you point *'groups' data* in https://review.opendev.org/c/openstack/nova/+/766726/17/nova/tests/unit/api/openstack/compute/test_security_groups.py#1005 | |
| 08:01:19 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Update Servers APIs https://review.opendev.org/c/openstack/nova/+/764292 | |
| 08:01:19 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs https://review.opendev.org/c/openstack/nova/+/765311 | |
| 08:01:20 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Rebuild Server API https://review.opendev.org/c/openstack/nova/+/766380 | |
| 08:01:21 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List SG API https://review.opendev.org/c/openstack/nova/+/766726 | |
| 09:29:34 | gibi | stephenfin: can we land https://review.opendev.org/c/openstack/python-novaclient/+/770573 before the client freze? | |
| 09:39:24 | brinzhang_ | gibi, stephenfin, gmann: we add none type to the auth_schemes when we configing the devstack env, it's fixing the noVNC nova-next task failed, pls review if you have free time | |
| 09:39:36 | brinzhang_ | gibi, stephenfin, gmann: https://review.opendev.org/c/openstack/devstack/+/777923 thanks. | |
| 09:41:10 | brinzhang_ | gmann: I think this is not necessary to register a bug for devstack, it belongs to the bp/nova-support-webvnc-with-password-anthentication | |
| 09:51:39 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | |
| 09:52:48 | stephenfin | gibi: Sure, I'll respin that now | |
| 09:57:54 | gibi | thanks | |
| 10:06:38 | openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: Add support for microversion v2.88 https://review.opendev.org/c/openstack/python-novaclient/+/770573 | |
| 10:06:46 | stephenfin | gibi ^ | |
| 10:07:03 | gibi | stephenfin: I'm on it | |
| 10:11:53 | gibi | brinzhang_: left a question in the tempest review | |
| 10:16:35 | gibi | sean-k-mooney: is there anything open in os-vif that needed for Wallaby? This week is nonclient library freeze. I looked tht the open patches and nothing popped out for me as important. | |
| 10:24:11 | gibi | stephenfin: +2 thanks for the client patch | |
| 10:26:38 | openstackgerrit | Merged openstack/nova master: objects: Add 'socket' PCI NUMA affinity https://review.opendev.org/c/openstack/nova/+/772748 | |
| 10:59:05 | stephenfin | brinzhang_: gibi: Big comment left on https://review.opendev.org/c/openstack/nova/+/622336. I think we've all gotten confused /o\ | |
| 10:59:23 | openstackgerrit | Merged openstack/nova master: Remove short call timeout from func test https://review.opendev.org/c/openstack/nova/+/777447 | |
| 11:07:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Remove dead code https://review.opendev.org/c/openstack/nova/+/772928 | |
| 11:07:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: rpc: Rework 'get_notifier', 'wrap_exception' https://review.opendev.org/c/openstack/nova/+/741663 | |
| 11:07:51 | openstackgerrit | Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to 'nova.pci' https://review.opendev.org/c/openstack/nova/+/676209 | |
| 11:07:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: mypy: Add nova.cmd, nova.conf, nova.console https://review.opendev.org/c/openstack/nova/+/705657 | |
| 11:07:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to top-level modules https://review.opendev.org/c/openstack/nova/+/705658 | |
| 11:07:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Clean manager.Manager, service.Service signatures https://review.opendev.org/c/openstack/nova/+/764806 | |
| 11:35:13 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow disabling CPU flags via `cpu_model_extra_flags` https://review.opendev.org/c/openstack/nova/+/774240 | |
| 11:49:09 | kashyap | Gah, needs a rebase | |
| 11:49:52 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow disabling CPU flags via `cpu_model_extra_flags` https://review.opendev.org/c/openstack/nova/+/774240 | |
| 12:12:30 | stephenfin | lyarwood: I saw that before. I think a second attempt to commit fixed the issue | |
| 12:12:38 | stephenfin | otherwise just pass the -n flag temporarily | |
| 12:13:19 | lyarwood | huh | |
| 12:13:26 | lyarwood | TIL about the -n flag | |
| 12:13:29 | lyarwood | thanks | |
| 12:30:33 | sean-k-mooney | gibi: thanks for the reminder. no not on master. there is one patch i want to be backported to train but ill ping lyarwood for that seperatly | |
| 12:30:47 | gibi | sean-k-mooney: thanks for the confirmation | |
| 12:31:40 | sean-k-mooney | lyarwood: https://review.opendev.org/c/openstack/os-vif/+/765970 is the patch i was refering too above | |
| 12:32:22 | sean-k-mooney | lyarwood: we will need it downstream for 16.2 because the linux kernel patch was added in 8.4 | |
| 12:34:26 | sean-k-mooney | gibi: ill try and figure out a unit test for https://review.opendev.org/c/openstack/nova/+/777679 when i get time | |
| 12:35:06 | sean-k-mooney | raising the excption via a mock and adding the assertions is not hard but its in an inner funciton so its a littele more work then normal to test. | |
| 12:43:36 | openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: Add support for microversion v2.88 https://review.opendev.org/c/openstack/python-novaclient/+/770573 | |
| 12:55:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Add support for virtio-based input devices https://review.opendev.org/c/openstack/nova/+/756552 | |
| 13:00:34 | legochen | hey sean-k-mooney, do you know anyone familiar with "Launch an instance from a volume” practcie… some questions posted above… would like to discuss | |
| 13:02:48 | sean-k-mooney | hi i have not read them back but i can take a look in a second | |
| 13:03:23 | gibi | sean-k-mooney: ack | |
| 13:03:48 | legochen | thank you | |
| 13:04:56 | sean-k-mooney | ok so your asking about osc and block device mappings | |
| 13:05:16 | sean-k-mooney | stephenfin: has a patch up to rework how osc supports this currently | |
| 13:06:08 | sean-k-mooney | https://review.opendev.org/c/openstack/python-openstackclient/+/771696 | |
| 13:07:55 | sean-k-mooney | so there are several ways to create a vm as im sure your aware | |
| 13:08:18 | sean-k-mooney | you can create a vm with local root disk and have seperate data volumes | |
| 13:08:45 | sean-k-mooney | or you can replace the root disk with a cinder volume instaed of having it stored locally on the compute node. | |
| 13:09:02 | sean-k-mooney | the later can be done several ways and is what we refer to as boot form volume | |
| 13:09:40 | sean-k-mooney | nova support eighter using a prexisting bootable volume, or a new volumn created by nova form either an image of volume snapshot | |
| 13:10:31 | sean-k-mooney | the efficncy fo each depend on 1 how you judge efficncy and 2 whatn nova, glance and cinder backends you have configured | |
| 13:11:00 | sean-k-mooney | for example if you are using ceph for cinder nova and glance then boot form volume and non boot form volume are basically the same | |
| 13:11:29 | sean-k-mooney | in all cases teh root disk will just be a thin snapshot over the orignial image | |
| 13:12:21 | sean-k-mooney | similarly you use cider as the glance backend and your cinder driver support it then bfv volumes created from images can simialrly be a thin provisioned volumn | |
| 13:13:49 | sean-k-mooney | the presence of addtional data volumne in any configuration is largely irrelvent to effincincy or perfroamce since in bfv or non bfv cases you should keep all data you care about in a cinder data volumn anyway so you can tree the root disk as ephemeral | |
| 13:14:19 | sean-k-mooney | legochen: not sure if that help but if you have a specific question i can try and answer that | |
| 13:15:25 | sean-k-mooney | im not really sure how you are gaugeing effiency (storage space? perfroamce(troughtput,latency,boot time)? network bandwith utilisation?) or what your usecase is | |
| 13:18:16 | legochen | hey sean-k-mooney, sorry just back. I think my major questions are about OSC stuff. | |
| 13:18:41 | legochen | 1) let “—boot-from-volume <volume-size>” option can specify volume-type | |
| 13:19:04 | legochen | 2) support —block-device option as what ocata version has. | |
| 13:20:24 | sean-k-mooney | 2 is done in https://review.opendev.org/c/openstack/python-openstackclient/+/771699/3/openstackclient/compute/v2/server.py | |
| 13:20:26 | legochen | otherwise, the current OSC doesn’t have the ability to use an available & existing block-storage volume as root partition to boot an instance. | |
| 13:20:30 | sean-k-mooney | still unmerged | |
| 13:21:16 | legochen | okay, understood, do we have timeline to merge it :D | |
| 13:21:26 | sean-k-mooney | we are deprecating --block-device-mapping in fravor of --block-device | |
| 13:21:31 | sean-k-mooney | am not sure | |
| 13:22:00 | sean-k-mooney | stephenfin: ^ any idea when you expect the osc bfv change to merge | |
| 13:22:09 | sean-k-mooney | will it happen this cycle | |
| 13:22:25 | legochen | do you mean you recommend --block-device instead of “ --block-device-mapping” ? | |
| 13:23:01 | sean-k-mooney | legochen: osc does not curently have --block-device but we are adding it and it will replace teh use fo teh existing --block-device-mapping command in osc | |
| 13:23:20 | lyarwood | sean-k-mooney: ack sorry was out at lunch | |
| 13:23:40 | legochen | okay, thanks. clear now. | |
| 13:24:07 | legochen | about 1) … I feel if it cannot specify “volume-type”, it will be not that useful. | |
| 13:24:14 | sean-k-mooney | legochen: the imporant point form your point of view will be the abllit to set volume_type | |
| 13:24:40 | sean-k-mooney | legochen: that could be added | |
| 13:25:40 | sean-k-mooney | well looking at it its proably not possible actuly | |
| 13:26:00 | sean-k-mooney | currently --boot-from-volume is defiend as an int | |
| 13:26:11 | sean-k-mooney | we could proably add a --volumn-type however | |
| 13:26:20 | sean-k-mooney | so you would use both | |
| 13:27:18 | sean-k-mooney | so somthign like --boot-from-volume 100G --image <my-image> --volume-type=<my-volume-type> | |
| 13:27:42 | legochen | yes, that would be better ! | |
| 13:28:05 | sean-k-mooney | you should file a bug with osc or if you have time a patch? | |
| 13:28:20 | sean-k-mooney | otherwise see if stephenfin has time to adress it in a follow up. | |
| 13:28:37 | sean-k-mooney | legochen: currently he is trying to close the remaining gaps between nova clinet and osc | |
| 13:29:01 | sean-k-mooney | so that has priorty over adding syntatic sugar. this would be nice to have but less of a priorty then his other patches | |
| 13:29:18 | legochen | thanks, about 2) is not that require to me beacuse I feel 1) is much better in my use cases. | |
| 13:29:55 | sean-k-mooney | 2 is needed for other usecase and what stephen has already implmented | |
| 13:30:09 | sean-k-mooney | 1 i would guess he wont have time to work on in the near future | |
| 13:30:48 | legochen | understood….btw, if you don’t mind, I’d like to go back to talk the performance questions with you. | |
| 13:31:08 | legochen | https://docs.openstack.org/nova/latest/user/launch-instance-from-volume.html | |
| 13:31:46 | sean-k-mooney | sure | |
| 13:32:03 | legochen | basically, one OpenStack cluster could be split into two parts 1) Control Plane 2) Hypervisors . | |
| 13:32:12 | legochen | in that document | |
| 13:32:34 | legochen | These two options “Create a volume from an image and boot an instance from that volume.” and “Boot from an existing source image, volume, or snapshot.” | |