| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-05 | |||
| 13:45:37 | tssurya | mriedem, dansmith, melwitt: I'll by flying out today, should be in airport transit for the cells meeting if we are having one | |
| 13:46:25 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: List resource providers having inventory https://review.openstack.org/600016 | |
| 13:46:25 | dansmith | tssurya: ack, we should cancel.. I'm just getting back up to speed since last week anyway and we'll be together next week | |
| 13:47:23 | tssurya | dansmith:ack | |
| 14:04:28 | mriedem | alex_xu: how about i just pull the try/except change out of https://review.openstack.org/#/c/599744/ and make it a follow up so we can discuss what to do about it separately? | |
| 14:12:08 | openstackgerrit | Eric Fried proposed openstack/nova master: Use uuidsentinel from oslo.utils https://review.openstack.org/600070 | |
| 14:13:15 | efried | cdent: ^ | |
| 14:13:23 | cdent | roger | |
| 14:13:31 | efried | I guess I'll do the placement one... later | |
| 14:13:47 | pooja-jadhav | efried: Hello | |
| 14:14:03 | efried | cdent: or redo https://review.openstack.org/#/c/599386/ actually | |
| 14:14:08 | efried | pooja-jadhav: Howdy. | |
| 14:14:21 | alex_xu | mriedem: sounds a good idea | |
| 14:14:32 | pooja-jadhav | efried: R u aware about block device mapping? | |
| 14:15:02 | efried | pooja-jadhav: It's a roiling, swirling vortex of mystery to me. | |
| 14:15:22 | cdent | efried: I suspect it is easier/clean to let 599386 merge and adapt it to uuidutils after | |
| 14:15:33 | efried | cdent: ack | |
| 14:15:54 | mriedem | alex_xu: ok i'll pull that out then | |
| 14:16:23 | pooja-jadhav | efried: can u locate me to the correct person who knows about it in detail?? | |
| 14:16:37 | mriedem | pooja-jadhav: just ask the question and someone that maybe can help, can try to help | |
| 14:16:43 | efried | pooja-jadhav: I hate to throw mriedem under the bus for everything, but he's probabl... | |
| 14:16:49 | efried | yeah, that :) | |
| 14:16:54 | pooja-jadhav | ohk | |
| 14:19:03 | pooja-jadhav | mriedem, efried: we can boot volume backed instance by two ways. 1. using --boot-volume 2. mentioned in the ref[1]https://docs.openstack.org/newton/user-guide/cli-nova-launch-instance-from-volume.html | |
| 14:20:05 | mriedem | oh there are myriad ways to bfv | |
| 14:20:16 | mriedem | don't forget image-defined bdms | |
| 14:20:20 | pooja-jadhav | mriedem, efried: When i boot an instance using --boot-volume. it creates single entry in block_device_mapping table. while when i use using --block-device in that case it creates 2 entries(1 for image and 1 for volume) | |
| 14:20:49 | mriedem | when you say --boot-volume do you mean --block-device? | |
| 14:21:03 | pooja-jadhav | no | |
| 14:21:16 | pooja-jadhav | --boot-volume (we need to passed bootable volume there) | |
| 14:21:26 | pooja-jadhav | volume created by an image | |
| 14:21:36 | cdent | "oh there are myriad ways to bfv" is the opening like to the poem that will get me the nobel prize for lit | |
| 14:21:51 | cdent | but only after my editor corrects my typing | |
| 14:22:31 | mriedem | pooja-jadhav: so this, "cinder create --image-id $IMAGE_ID --display_name=bootable_volume $SIZE_IN_GB" | |
| 14:23:13 | mriedem | "When i boot an instance using --boot-volume. it creates single entry in block_device_mapping table. while when i use using --block-device in that case it creates 2 entries(1 for image and 1 for volume)" | |
| 14:23:27 | mriedem | in the first case, the bootable volume is the root disk of the vm, it's the boot_index=0 bdm | |
| 14:23:32 | mriedem | that's why there is 1 bdm | |
| 14:23:38 | pooja-jadhav | issue i observed is: when i checked the instance created by above ref doc and tried to verifies is it BFV then as block device mapping gives me two entries. this method(is_volume_backed_instance) returns false | |
| 14:24:01 | pooja-jadhav | mriedem: yes | |
| 14:24:01 | mriedem | in the 2nd case, there is an ephemeral root disk on the compute host, not a volume, and then a blank non-bootable volume is attached to the vm where boot_index=None | |
| 14:24:14 | mriedem | b/c it's not volume-backed | |
| 14:24:30 | mriedem | if you want a volume-backed server, the root volume is specified with boot_index=0 | |
| 14:24:47 | mriedem | https://docs.openstack.org/nova/latest/user/block-device-mapping.html might be helpful | |
| 14:25:18 | mriedem | re: boot_index "Setting a negative value or None indicates that the device should not be used for booting." | |
| 14:25:43 | mriedem | from the example, | |
| 14:25:44 | mriedem | "nova boot --flavor FLAVOR --block-device \ source=SOURCE,id=ID,dest=DEST,size=SIZE,shutdown=PRESERVE,bootindex=INDEX \ NAME" | |
| 14:25:49 | mriedem | bootindex=INDEX Orders the boot disks. Use 0 to boot from this volume. | |
| 14:26:07 | mriedem | "nova boot --flavor 2 \ --block-device source=volume,id=$VOLUME_ID,dest=volume,size=10,shutdown=preserve,bootindex=0 \ myInstanceFromVolume" | |
| 14:26:25 | mriedem | ^ means boot from bootable volume $VOLUME_ID | |
| 14:27:12 | mriedem | the size field should probably be omitted from that last example since i don't think it's used for a pre-existing volume | |
| 14:27:26 | mriedem | the --block-device size field is only used when nova creates the volume and boots from it | |
| 14:27:41 | mriedem | cdent: "call me mriedem" | |
| 14:28:42 | mriedem | pooja-jadhav: does that answer your questions? | |
| 14:29:19 | pooja-jadhav | mriedem: yes, I will try this thing immediately, and let u know.. if anything more needed. Thanks for ur time :) | |
| 14:29:34 | mriedem | yw | |
| 14:29:38 | pooja-jadhav | mriedem: and for quick responses :) | |
| 14:41:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Configure placement DB context manager for nova-manage/status https://review.openstack.org/599744 | |
| 14:41:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove error-masking try/except from _run_migration https://review.openstack.org/600085 | |
| 14:41:31 | mriedem | gibi_off: alex_xu: ^ | |
| 14:46:03 | prometheanfire | mriedem: thanks | |
| 14:55:53 | pvc | hi anyone experience instance not getting an IP address? error on communication with the DHCP but when I create a new network it successfully get an IP address? | |
| 15:00:32 | pvc | lvdombrkr | |
| 15:00:36 | pvc | hi anyone experience instance not getting an IP address? error on communication with the DHCP but when I create a new network it successfully get an IP address? | |
| 15:03:47 | mriedem | looks like we need some stable/rocky reviews https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/rocky | |
| 15:03:56 | mriedem | melwitt: you can exercise your newfound stable core powers ^ | |
| 15:04:31 | melwitt | roger copy | |
| 15:06:06 | pvc | mriedem | |
| 15:06:07 | pvc | can i ask | |
| 15:06:28 | pvc | can i push this to queens? | |
| 15:06:28 | pvc | https://review.openstack.org/#/c/590188/ | |
| 15:19:55 | mriedem | pvc: backports go in order, so that would first have to merge on master, then backported to rocky, then backported to queens | |
| 15:21:08 | breton | hi! Are VMs with memory encryption supported now in Nova? Amd's SEV for example | |
| 15:22:55 | mriedem | never heard of it | |
| 15:23:54 | mriedem | i bet windriver would be all over it though | |
| 15:23:59 | mriedem | if only cfriesen were around | |
| 15:26:12 | mriedem | mnaser: re your questions about placement extraction and data migration, | |
| 15:26:18 | mriedem | if placement were down but nova-api was up, | |
| 15:26:43 | mriedem | users could try to delete instances which should work in nova (i haven't tested this) but leave stale records in placement which would require a script to cleanup, | |
| 15:26:50 | mriedem | but new requests for scheduling would also fail with NoValidHost | |
| 15:27:02 | mriedem | is the latter something you're OK with? | |
| 15:27:11 | melwitt | tssurya, dansmith: ack for canceling | |
| 15:27:17 | pvc | mriedem i see thank you | |
| 15:27:37 | pvc | can i use to my openstack queens for testing? | |
| 15:27:58 | mriedem | pvc: you can do whatever you want in your local environment | |
| 15:31:40 | pvc | both on controller and compute? | |
| 15:34:20 | mriedem | pvc: that patch only applies to compute | |
| 15:37:30 | pvc | if i push it, the ceph volume extension on fly will be okay also right | |
| 15:37:50 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Fix nova-status "_check_resource_providers" check https://review.openstack.org/600098 | |
| 15:40:55 | mriedem | pvc: i don't know what that means | |
| 15:41:07 | mriedem | but i also can't speak for this patch because i haven't looked at it in awhile | |
| 15:41:18 | mriedem | if it fixes your bug, and it applies to queens, then i guess you find out | |
| 15:42:20 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Fix nova-status "_check_resource_providers" check https://review.openstack.org/600101 | |
| 15:43:27 | mriedem | naichuans: bauzas: efried: i added an item to the ptg etherpad about the libvirt/xenapi driver implementation for reshaper - my libvirt patch is only written to handle the existing upgrade case of moving a single VGPU inventory class from the root provider to a new child provider, it does not intend to handle multiple child providers for multiple VGPU types b/c we didn't support that yet, so we wouldn't reshape *from* that sc | |
| 15:43:27 | mriedem | io yet | |
| 15:43:45 | mriedem | but i'm worried that maybe there are things to come with multi-vgpu child providers that i'm not appreciating | |
| 15:43:57 | mriedem | although i figured that might be handled with traits? | |
| 15:44:23 | mriedem | if you have multiple vgpu type providers on the same host, they'd be children under the same root with separate traits describing the vgpu type per provider | |
| 15:44:45 | efried | I would think so, yes. | |
| 15:46:32 | bauzas | mriedem: yeah, and I agree with you | |
| 15:46:37 | bauzas | mriedem: that's the comment I said | |