| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-15 | |||
| 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 | |
| 07:26:21 | sean-k-mooney[m] | has it helpped | |
| 07:26:29 | bauzas | the problem would be to accept a flavor with disk=0 and magically create ephemeral storage | |
| 07:26:51 | jkulik | no, we don't have it in production. we lacked too much other functionality for bfv VMs (we're still on rocky, e.g. rescue) | |
| 07:26:53 | sean-k-mooney[m] | bauzas that is what we did untill around rocky issue i think | |
| 07:27:01 | bauzas | yup | |
| 07:27:08 | bauzas | I remember this | |
| 07:27:26 | bauzas | point is, look at the figures of the meet-and-greet | |
| 07:27:36 | sean-k-mooney[m] | jkulik so i think rescue is now there and rebuild is in flight this cycle | |
| 07:27:37 | jkulik | but it's not just disk=0, it's also that the flavor is explicitly marked for automatic bfv, right? | |
| 07:27:56 | bauzas | probably the one who requested for a bfv flag was hit by the fact he/she was running older than Rocky | |
| 07:27:57 | jkulik | sean-k-mooney: yeah, looking forward to it. we're also trying to jump to xena by this year | |
| 07:28:28 | bauzas | jkulik: that's what I call 'orchestration' | |
| 07:28:38 | bauzas | the 'automatic' side | |
| 07:29:28 | jkulik | ... and no orchestration in Nova itself | |
| 07:29:56 | sean-k-mooney[m] | jkulik for context novas project scope doc declares orchstration as out of scope and we tend to define that as any addtional inter service operation that can be done by a user and the result passed in to nova | |
| 07:30:19 | jkulik | like creating a volume from image, which Nova already does? | |
| 07:30:20 | sean-k-mooney[m] | i.e. create your port/volume ahead of time and tell nova to use it | |
| 07:30:23 | bauzas | https://docs.openstack.org/nova/latest/contributor/project-scope.html#no-more-orchestration | |
| 07:30:51 | sean-k-mooney[m] | jkulik yep so nova only can do that because we need to support that before cinder was split out | |
| 07:30:55 | bauzas | jkulik: you're exactly pointing some orchestration we keep | |
| 07:31:13 | bauzas | because of the API consistency | |
| 07:31:23 | sean-k-mooney[m] | cinder started as nova-volume | |
| 07:31:26 | jkulik | ok, if we keep it, we can still use it, right? I'm mean in the end it's just a flavor using exactly that | |
| 07:31:35 | sean-k-mooney[m] | the same way ironic started as nova-baremetal | |
| 07:31:48 | sean-k-mooney[m] | jkulik we likely will never remove it | |
| 07:31:59 | sean-k-mooney[m] | we would have to raise our min api verion to do so | |
| 07:32:06 | sean-k-mooney[m] | and we wont do that any time soon | |
| 07:32:07 | sean-k-mooney[m] | if ever | |