| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-05 | |||
| 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 | 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:01 | pooja-jadhav | mriedem: yes | |
| 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 | https://review.openstack.org/#/c/590188/ | |
| 15:06:28 | pvc | can i push this to queens? | |
| 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 | io yet | |
| 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: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 | |
| 15:46:54 | mriedem | ok cool | |
| 15:46:59 | bauzas | mriedem: if we need *more* types, then that's a new change | |
| 15:47:15 | bauzas | for the moment, we only support one, hence your change being good | |
| 15:47:26 | mriedem | bauzas: also, on that libvirt change, i haven't actually tested that with a real system that has vgpu inventory on it | |
| 15:47:46 | bauzas | mriedem: tbh, that's the problem I have, my machine has been passed to another one... | |
| 15:47:50 | mriedem | so if you have a setup like that, or are able to do it quicker than me, that would be great if you could actually make sure this does the needful | |
| 15:47:54 | mriedem | ah | |
| 15:48:03 | bauzas | mriedem: yeah sure, it's just... | |
| 15:48:11 | bauzas | you know, hardware etc. | |
| 15:49:56 | mriedem | i'm sure sean-k-mooney has some hardware that he nabbed from intel on the way out | |
| 15:52:19 | sean-k-mooney | mriedem: unfortunetly not but i have some hardware i bought on ebay | |
| 15:52:26 | sean-k-mooney | what was it in relation too? | |
| 15:55:08 | mriedem | vgpu testing for my reshaper patch | |
| 15:57:05 | pvc | just a quick question mriedem | |
| 15:57:25 | pvc | what release does the cinder volume in-use state extension supported? | |
| 15:57:28 | sean-k-mooney | mriedem: ah unforunetly i dont have any vgpu suff currently. | |
| 16:00:01 | dansmith | mriedem: so do you think we squashed it? http://status.openstack.org/elastic-recheck/#1789484 | |
| 16:04:15 | mgagne | Lets say your Ironic instance only has 2 physical nics and you don't want a 3rd interface attached because it just wouldn't work. Would Nova check for this limitation and fail at the API level? | |
| 16:05:43 | mriedem | pvc: let me go back to your original question: https://review.openstack.org/#/c/590188/ will not be backported upstream | |
| 16:05:45 | mriedem | because it's for a feature | |
| 16:06:04 | mriedem | even though it says it's a bug, it's a bug related to implementing a feature | |
| 16:06:31 | pvc | i see thank you :) | |
| 16:07:40 | mriedem | volume extend support was added in pike https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/nova-support-attached-volume-extend.html | |
| 16:08:26 | pvc | yes but on LVM driver only. for rbd is not yet supported | |
| 16:09:01 | mriedem | sure, that's not a bug though | |
| 16:09:36 | mriedem | more specifically, it's supported for iscsi and fibrechannel volume types | |
| 16:09:42 | mriedem | which is more than just lvm | |
| 16:09:58 | pvc | yes do you have idea when is the implementation for rbd? | |
| 16:10:12 | mriedem | the next patch in that series https://review.openstack.org/#/c/594273/ | |