| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-15 | |||
| 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 | |
| 07:47:03 | sean-k-mooney[m] | i was thinking the same | |
| 07:47:04 | bauzas | sean-k-mooney: gibi: this reminds me the Public Cloud SIG session | |
| 07:47:19 | bauzas | sean-k-mooney: gibi: do you know that they stuggle having the same flavor names ? | |
| 07:47:23 | bauzas | struggle | |
| 07:47:39 | sean-k-mooney[m] | disk=0 ram=0 vcpu=0 and just allow —resouce rc=ammount on server create | |
| 07:47:49 | sean-k-mooney[m] | and use unified limits for quota/billing | |
| 07:47:54 | bauzas | proposing a common set of flavors between all Passport operators seemed nearly impossible to achieve | |
| 07:48:05 | sean-k-mooney[m] | ya we should likely not do that | |
| 07:48:22 | sean-k-mooney[m] | the only way to do that is for nova to ship with default flavors | |
| 07:48:27 | bauzas | even that | |
| 07:48:27 | sean-k-mooney[m] | that you can opt into | |
| 07:48:36 | sean-k-mooney[m] | and never update just disable | |
| 07:48:39 | bauzas | they get rid of our default flavors | |
| 07:48:49 | bauzas | OVH has strong concerns about touching their flavors, by instance. | |
| 07:48:57 | sean-k-mooney[m] | we dont ship them the devstack one are not defualt in nova | |
| 07:49:28 | gibi | I have no hard opinion about default flavors. I dont think this is a technical issue, it is an issue of how to create standards | |
| 07:49:34 | bauzas | anyway, I'm just saying we're on a territory I don't like | |
| 07:49:52 | bauzas | gibi: agreed, this isn't a problem we should solve technically | |
| 07:50:14 | bauzas | gibi: we should let the community agree on a standard set, if they agree eventually | |
| 07:50:32 | sean-k-mooney[m] | that or provide supprot for creating them in osc | |
| 07:50:38 | sean-k-mooney[m] | or as a plugin | |