| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-15 | |||
| 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 | |
| 07:50:58 | bauzas | that's one of the reasons we wanted this unified client | |
| 07:51:22 | sean-k-mooney[m] | i.e. have a repo where we can host some flavor templats for standard flaovr that opertors can contibute too | |
| 07:51:34 | bauzas | nacking the fact that we could bfv auto in the client just because others don't use our client seems an alternative we quickly refused because $whataboutism | |
| 07:52:02 | sean-k-mooney[m] | bauzas we already have the ablity to do bfv in the client today | |
| 07:52:32 | bauzas | then, personnally I feel the problem solved. | |
| 07:52:41 | jkulik | but not auto-bfv | |
| 07:52:56 | bauzas | then patch the client | |
| 07:53:11 | jkulik | yeah, I can do that. again, doesn't help my customers ;) | |
| 07:53:14 | bauzas | and patch any other fancy client | |
| 07:53:18 | jkulik | I'll patch Nova instead thus. downstream | |
| 07:53:47 | sean-k-mooney[m] | we have openstack server create —boot-form-volume <size> today | |
| 07:54:54 | sean-k-mooney[m] | so ^ is our baseline in terms fo client just incase you were not aware bauzas | |
| 07:55:02 | bauzas | sean-k-mooney: thanks, appreciated | |
| 07:55:07 | bauzas | I was looking at the client docs | |
| 07:55:23 | sean-k-mooney[m] | its here https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-create | |
| 07:55:40 | bauzas | sean-k-mooney: we can move on the etherpad and propose the CLI usage | |
| 07:55:45 | bauzas | and see what people think | |
| 07:55:52 | sean-k-mooney[m] | i thikn since walaby when stepehnfin pushed to get parity | |
| 07:55:58 | bauzas | yay | |
| 07:56:02 | bauzas | again, see the metrics | |
| 07:56:06 | bauzas | Queens and beyond | |
| 07:56:13 | sean-k-mooney[m] | honestly i dont think that helps in any way | |
| 07:56:24 | sean-k-mooney[m] | i was assumeing they already had that and it was not sufficent | |
| 07:56:33 | sean-k-mooney[m] | but sure they may be on old clouds | |
| 07:56:37 | sean-k-mooney[m] | so maybe its enough | |
| 07:56:56 | jkulik | I get the approach of keeping the scope small and saying "we support osc, everything else is out of scope". But adding features like this only to osc will keep them away from a lot of customers on our side, so it might as well not be there. No hard feelings. | |
| 07:56:58 | bauzas | trust me, they use very old relases | |
| 07:57:34 | bauzas | jkulik: we support any client able to access our REST API | |
| 07:58:02 | sean-k-mooney[m] | well technially we supprot the apis not the client | |
| 07:58:02 | bauzas | we even support clients that aren't able to negociate with the API about new microversions | |
| 07:58:27 | sean-k-mooney[m] | we dont supprot any client excpet nova client from a project perspective | |
| 07:58:28 | bauzas | here, we're not brainstorming about a lack in our APIs | |
| 07:58:55 | jkulik | then I don't get why you would propose to add the feature to a single client instead | |