| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-15 | |||
| 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 | bauzas | "could be, eventually" | |
| 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: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 | bauzas | and I don't want config-driven APIs | |
| 07:35:22 | sean-k-mooney[m] | well we use the default volume type | |
| 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 | |
| 07:38:41 | sean-k-mooney[m] | or —network on server create | |
| 07:39:11 | sean-k-mooney[m] | the differnece with a port is that is never in a flaovr to begin with | |
| 07:40:44 | bauzas | sean-k-mooney: not if you do bandwidth-aware requests :) | |
| 07:42:23 | sean-k-mooney[m] | there is nothing in the falvor for that | |
| 07:42:23 | gibi | I think give me a network is when you say --nic auto | |
| 07:42:37 | sean-k-mooney[m] | the bandwith request comes form the port | |
| 07:43:01 | gibi | yepp bw is a disaggregated resource | |
| 07:43:15 | jkulik | why does the flavor have to be specified diskless btw.? Couldn't we just let the operator specify whether the disk should be on ephemeral or on volume storage i.e. determine the deestination_type of the BDM? | |
| 07:43:24 | sean-k-mooney[m] | no give me a network is the neutron feature that will create a network, subnet and router automaticaly to replicate nova-networks behavior | |
| 07:43:35 | gibi | sean-k-mooney[m]: /o\ | |
| 07:44:03 | bauzas | should we ask the same to cinder then ? | |
| 07:44:09 | sean-k-mooney[m] | https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/get-me-a-network.html | |
| 07:44:15 | bauzas | "give me a volume" | |
| 07:44:28 | bauzas | and nova be --disk auto | |
| 07:44:28 | sean-k-mooney[m] | its called volume create | |
| 07:44:38 | sean-k-mooney[m] | its not the same thing | |
| 07:44:59 | sean-k-mooney[m] | in the neutron case people just wanted the vm to have a port with an ip by defualt | |
| 07:45:21 | sean-k-mooney[m] | but with neutron to do that you ahve to create a networ, subnet and router first | |
| 07:45:40 | bauzas | jkulik: you're right, operators could propose both ephemeral storage and block one | |
| 07:46:46 | bauzas | life would be way easier if we weren't having flavors | |