| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-15 | |||
| 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. | |
| 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 | |
| 07:32:11 | bauzas | never | |
| 07:32:14 | jkulik | :) | |
| 07:32:25 | bauzas | in particular given the lag we have | |
| 07:32:30 | sean-k-mooney[m] | bauzas well i object to never | |
| 07:32:44 | bauzas | sean-k-mooney: okay, let's be less pragmatic | |
| 07:32:50 | jkulik | so imho, if the user comes in with a BDM of image -> volume, we create the volume. why can't we specify the flavor to default to image -> volume? | |
| 07:32:52 | sean-k-mooney[m] | as i think its wrong for use to have a min version filed if that is the stance we are taking | |
| 07:32:52 | bauzas | "could be, eventually" | |
| 07:33:09 | sean-k-mooney[m] | should be eventurally | |
| 07:33:35 | bauzas | sean-k-mooney: I was there in 2015 when we drafted v2 | |
| 07:33:42 | bauzas | v2.1 actually | |
| 07:33:58 | bauzas | we create min_version because we were considering it | |
| 07:34:01 | bauzas | created* | |
| 07:34:02 | sean-k-mooney[m] | yep and at that time we planned to increase it eventually | |
| 07:34:25 | bauzas | but given interop and other reasons, we ended up being less optimistic | |
| 07:34:26 | sean-k-mooney[m] | jkulik what volume_type should be used | |
| 07:34:37 | sean-k-mooney[m] | to create the volume form the image | |
| 07:34:49 | sean-k-mooney[m] | should we delete it on terminate | |
| 07:34:52 | jkulik | that's already a decision Nova has to make | |
| 07:34:59 | bauzas | nope | |
| 07:35:17 | jkulik | then Nova does nothing and it's the default volume type of Cinder | |
| 07:35:22 | sean-k-mooney[m] | well we use the default volume type | |
| 07:35:22 | bauzas | and I don't want config-driven APIs | |
| 07:35:31 | sean-k-mooney[m] | which i gues is your point | |
| 07:35:40 | bauzas | we have defaults for sure | |
| 07:35:48 | bauzas | but that's for a volume | |
| 07:35:52 | jkulik | I mean the feature is already there, I just want a flavor to use it | |
| 07:36:27 | sean-k-mooney[m] | yep it is. we just dont have a way to enable it except via an api parmater today | |
| 07:36:39 | bauzas | for many reasons | |
| 07:36:45 | jkulik | right. so my request would be to enable it via flavor parameter | |
| 07:37:11 | bauzas | again, what's the usecase if we force users to add a volume if they have a diskless flavor ? | |
| 07:37:29 | sean-k-mooney[m] | to not force user to do things | |
| 07:37:40 | sean-k-mooney[m] | and provide bettter ux | |
| 07:37:56 | bauzas | we have the "give me a port" thing | |
| 07:38:06 | bauzas | and this isn't within a flavor, right? | |
| 07:38:28 | sean-k-mooney[m] | do you mean give me an network | |