| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-15 | |||
| 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 | sean-k-mooney[m] | no not always | |
| 06:53:20 | bauzas | so if you have diskless computes, don't create those flavors | |
| 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 | bauzas | honestly, I just want to make sure disk=0 is meaningful | |
| 07:05:20 | sean-k-mooney[m] | so default policy requires admin for the unbounded case | |
| 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 | sean-k-mooney[m] | i dont think we have example that hit the db today | |
| 07:13:19 | jkulik | sounds wrong to me, tbh | |
| 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. | |
| 07:16:41 | sean-k-mooney[m] | for what its worth the keystone middelware makes rest calls to validate the auth token so they can be complex but normally they are simple | |
| 07:20:20 | bauzas | sean-k-mooney: sorry was disturbed by some paperwork due to a flight cancelled | |
| 07:20:55 | bauzas | thanks Europe, I'm owed 250€ | |
| 07:21:12 | bauzas | sean-k-mooney: well, surely we can improve the UX | |
| 07:21:50 | sean-k-mooney[m] | the question is how :) | |
| 07:22:11 | bauzas | I just wanted to express the general thought that was 'if it implies kind of roundtrips between multiple projets and a lot of conditionals, then we should maybe discuss on the opportunity to make it a client thing' | |
| 07:22:19 | jkulik | by linking to the docs in the error-message? :D | |
| 07:22:25 | sean-k-mooney[m] | we used to punt on this and say use a heat template | |
| 07:22:35 | bauzas | now we have openstackcli | |
| 07:22:57 | sean-k-mooney[m] | well there is a simple way to do it in the client now i think | |
| 07:23:17 | bauzas | and thanks to hard efforts of stephenfin and a couple of others, we are able to have it done in the CLI | |
| 07:23:20 | sean-k-mooney[m] | that does not really solve the problem that uers have to rememebr to do it | |
| 07:23:38 | jkulik | most of our users don't use openstackcli either | |
| 07:24:05 | bauzas | directly the REST APIs, heh ? | |
| 07:24:14 | sean-k-mooney[m] | jkulik do they use api directly/via a differnt client or horizon/heat | |
| 07:24:20 | jkulik | $some library or yes, the REST APIs :( | |
| 07:24:39 | bauzas | if so, they are powered users that can understand the need for block storage if disk=0 | |
| 07:24:41 | sean-k-mooney[m] | ah hard core curl users :) | |
| 07:24:50 | jkulik | iirc gophercloud is much used, but there was also a Java library that's in much use | |
| 07:25:13 | sean-k-mooney[m] | bauzas not nessisarly | |
| 07:25:27 | jkulik | right. they build their own library and it takes ages to make them update anything :D that's why we would like to be able to do it on our side | |
| 07:25:31 | sean-k-mooney[m] | they could just be developers of applcition that run on openstack clouds | |
| 07:25:38 | bauzas | fair enough | |
| 07:26:04 | bauzas | but again, conceptually, if we fail with a flavor of disk=0, then I think we're consistent | |
| 07:26:16 | sean-k-mooney[m] | jkulik so you have that patch in production i take it | |