Earlier  
Posted Nick Remark
#openstack-nova - 2022-06-15
06:46:55 sean-k-mooney[m] ports are entirly seperate
06:47:06 gibi yepp like that
06:47:08 sean-k-mooney[m] so you would prefer if disk was also seperate
06:47:14 gibi yepp
06:47:36 sean-k-mooney[m] there sort of in a weird middel ground today
06:48:20 sean-k-mooney[m] cause they can be seperate and in the case of flavor.ephmeral you can subdevide that into multiple disks
06:48:22 bauzas sean-k-mooney: what is the usecase ?
06:48:39 bauzas why they don't want to ask for a volume or other way ?
06:48:53 gibi $ openstack disk create --type [boot|ephemeral|swap] --backend [local-disk|volume] --size
06:48:56 gibi $ openstack server create ... --disk <disk-uuid>
06:49:23 sean-k-mooney[m] i belive they want to have diskless compute or low disk compute and have there tenants always use cinder storage
06:50:04 sean-k-mooney[m] but they didint want there users to have to rememebr to do that, wasnt in the room :)
06:50:19 sean-k-mooney[m] its the last line on the meet and greet doc
06:50:51 sean-k-mooney[m] gibi that is an intersting idea
06:50:57 gibi or even
06:50:58 gibi $ openstack disk profile create --type [boot|ephemeral|swap] --backend [local-disk|volume] --size
06:50:58 gibi # admin
06:51:01 gibi # user
06:51:04 gibi $ openstack disk create --profile <profile-uuid>
06:51:28 gibi to have the way the admin limit the sizes and types
06:51:37 sean-k-mooney[m] right i prefer the latter but that is getting into composable flavors
06:51:45 gibi exactly
06:51:52 gibi so it solves both problems :D
06:51:57 gibi (no it does not )
06:52:04 bauzas sean-k-mooney: then maybe they should provide flavors with DISK_GB=0
06:52:06 sean-k-mooney[m] right if we did that i would prefer to do that for all resouces
06:52:25 sean-k-mooney[m] bauzas they can yes
06:52:42 sean-k-mooney[m] with our default policy that would for bfv usage
06:52:59 bauzas if you create a flavor with some disk value, then it would create an ephemeral volue
06:53:00 sean-k-mooney[m] *force
06:53:20 bauzas so if you have diskless computes, don't create those flavors
06:53:20 sean-k-mooney[m] no not always
06:53:50 sean-k-mooney[m] people pushed back when i suggested we should not allow you do do boot form volume with flavor wiht disk!=0
06:54:17 sean-k-mooney[m] well what if you have a mix some diskless some with local storage
06:54:46 sean-k-mooney[m] psi has fast nvme storage on the ci aggrate and the general aggreate is backed by ceph
06:55:22 sean-k-mooney[m] that is why we litrally have ci.* and general.* flavors
06:55:50 sean-k-mooney[m] as a user you are ment to rember to use qcow with ci* and raw images with general*
06:56:50 sean-k-mooney[m] gibi to your point i do think composable flaors is proably the best approch but everyone hates thoses so meh
06:57:28 sean-k-mooney[m] and by that somehting liek the —disk-profile you were suggesting
06:57:36 gibi yeah. also I don't think we have workforce to make composable happen
06:57:42 gibi so it is just a dream
06:58:45 sean-k-mooney[m] we can hope
06:59:02 sean-k-mooney[m] there were simpler pain points to adress frist
06:59:30 gibi sorry again for being extra negative this morning
06:59:49 sean-k-mooney[m] im interested to see how many of the quota pain points will get addressed by unifed limits
07:00:16 sean-k-mooney[m] gibi: its oke eventully you will underflow and be very very positive again :)
07:00:39 bauzas sorry, I think I still don't get the problem about what we miss
07:00:54 bauzas but I'm of course wrong
07:01:12 gibi sean-k-mooney[m]: I'm waiting for that :D
07:01:38 sean-k-mooney[m] bauzas a simple declaritive way to say that vms should use bfv
07:01:50 sean-k-mooney[m] the command line is imperitive
07:02:16 sean-k-mooney[m] i would have said images_type=cinder
07:02:34 sean-k-mooney[m] but they expictly said not via a host level config option
07:02:38 bauzas sean-k-mooney: wdym by imperative ?
07:03:00 sean-k-mooney[m] bauzas as a user i have to know and remember to ask for bfv
07:03:18 jkulik just to chime in, we also want flavors that default to boot-from-volume instead of ephemeral disk without the user having to explicitly specify bfv
07:03:19 sean-k-mooney[m] as an operator i cant make that default by declaring it in a flaovr or image
07:03:20 bauzas oh, because of --block-device
07:03:39 bauzas as this is a flag, this can be missed by the user, gotcha
07:03:50 sean-k-mooney[m] yep
07:04:03 sean-k-mooney[m] hence hw:bfv=true in flaovr
07:04:16 sean-k-mooney[m] meaing that this flavor would always use bfv
07:04:18 bauzas well, if you ask for disk=0 with no block device, you end up with ERROR, right?
07:04:27 sean-k-mooney[m] yes
07:04:45 gibi did we fixed that?
07:04:47 sean-k-mooney[m] actully no
07:04:55 bauzas so, basically, users are pushed to add a block device
07:04:56 sean-k-mooney[m] ya so it depned on policy
07:04:57 gibi in the past disk=0 meant no enforcement
07:05:04 sean-k-mooney[m] correct
07:05:08 gibi ahh OK
07:05:20 sean-k-mooney[m] so default policy requires admin for the unbounded case
07:05:20 bauzas honestly, I just want to make sure disk=0 is meaningful
07:05:46 bauzas if you don't ask for a local disk, then you're forced to add a volume
07:06:00 sean-k-mooney[m] it kind of is as an end user with just the member role you cannot boot with bfv if disk=0
07:06:05 sean-k-mooney[m] *without
07:06:06 bauzas unless people want some OS residing fully in memory
07:06:25 sean-k-mooney[m] right but that imperitive
07:06:40 sean-k-mooney[m] it doesnt just work the same as any other flavor but use cinder netapp storage
07:06:47 bauzas sean-k-mooney: again, I could be wrong, but this behaviour seems correct to me
07:07:09 bauzas which is, nova won't provide you disk for your instance
07:07:20 bauzas then you have to provide it
07:07:31 sean-k-mooney[m] jkulik: did you want to expand on this a little
07:07:47 jkulik this was the approach we fiddled with https://github.com/sapcc/nova/commit/e65287727ab5f78fbcf3f6da26a54456eaebf932 it will automatically add a boot_index=0 BDM if the flavor has a property boot_from_volume=true
07:08:24 jkulik as we don't want to let our customers re-learn how to create VMs. it should "just work" like with ephemeral disks
07:09:05 bauzas in the past, we said those magics behind the hood were nearly orchestration
07:09:21 sean-k-mooney[m] ah you remembered to set delete on terminate to true too
07:10:09 sean-k-mooney[m] jkulik: it would be less maintance for you to do that via middleware by the way
07:11:14 sean-k-mooney[m] right but im not sure nova should avoid all orchestration at the expense of ux
07:11:50 sean-k-mooney[m] i generally agree we should not add any complex orchestation
07:12:08 jkulik sean-k-mooney: can you point me to some docs on that? I can see how we could edit a request coming in, but I wouldn't expect a middleware to be able to query Nova's DB to get the flavor
07:12:11 sean-k-mooney[m] and im sure my deffintion and yours of complex willl differ and thats ok too :)
07:12:58 sean-k-mooney[m] jkulik well it runs in the api process so it can access the the nova.conf
07:13:19 jkulik sounds wrong to me, tbh
07:13:19 sean-k-mooney[m] i dont think we have example that hit the db today
07:13:48 sean-k-mooney[m] less wrong then downstream modifications to the source code :)
07:14:12 jkulik haha, yes, well ... I've given up on not having those
07:14:53 sean-k-mooney[m] i was just suggesting if you have rebase issues due to this maybe middleware would help
07:15:14 sean-k-mooney[m] but i did not think about db access for the flavor definition
07:15:16 jkulik and I thank you for the advice. I had never thgouth about that.

Earlier   Later