| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-15 | |||
| 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 | |
| 07:58:59 | bauzas | and again, I'm afraid bfv-auto would generate kind of a config-driven API | |
| 07:59:29 | bauzas | jkulik: I'd propose other clients to do the same, to be precise | |
| 07:59:29 | sean-k-mooney[m] | well that is why i suggested the falvor | |
| 07:59:34 | jkulik | config-driven API is where the values, the API should get via request comes in from other sources e.g. flavor or config? | |
| 07:59:57 | sean-k-mooney[m] | no it explcitly refer to useing nova.conf values to alter behavior | |
| 08:00:04 | jkulik | ah, thanks | |
| 08:00:15 | bauzas | like, delete_on_termination | |
| 08:00:28 | sean-k-mooney[m] | that is not a config value is it | |
| 08:00:34 | sean-k-mooney[m] | i did not think it was | |
| 08:00:43 | bauzas | ah my bad, bad example | |
| 08:00:53 | sean-k-mooney[m] | the option i normall think of is force_configdrive | |
| 08:01:04 | sean-k-mooney[m] | which is a config value | |
| 08:01:31 | bauzas | honestly, I'm not opposed to add a way to describe automatic bfv, but we seriously need to consider the impacts | |
| 08:01:59 | bauzas | and I personally have concerns with the solution be a flavor extraspec | |
| 08:02:06 | sean-k-mooney[m] | ack | |
| 08:02:12 | sean-k-mooney[m] | ya thats fair | |
| 08:02:33 | sean-k-mooney[m] | i think i would want to see the last partity gaps get closed which i think is just rebuild first | |
| 08:02:50 | bauzas | agreed | |
| 08:03:25 | sean-k-mooney[m] | up until this cycle the delta for bfv and non bfv was too much to not have teh user be aware of which it was going to use ectra. | |
| 08:03:37 | jkulik | hm ... if not flavor extraspecs where else? we also have baremetal flavors, which can't even use volume storage in our cloud | |
| 08:03:58 | bauzas | sean-k-mooney: that's the problem with operator feedback | |
| 08:04:04 | sean-k-mooney[m] | jkulik actully they could depending on yoru release | |
| 08:04:15 | sean-k-mooney[m] | ironic support boot form cinder via iscsi | |
| 08:04:19 | bauzas | sean-k-mooney: ideally I think we should propose a talk or some live thing about what nova can do with bfv noxw | |
| 08:04:36 | jkulik | sean-k-mooney: not in our cloud. all volume-types are in some vmware datastores ... :( | |
| 08:04:36 | bauzas | to let people know about what BFV is today | |
| 08:05:11 | sean-k-mooney[m] | jkulik its pretty new too only like 2-3 relases i think | |
| 08:05:32 | sean-k-mooney[m] | bauzas ya a general bfv talk woudl be good | |
| 08:06:22 | sean-k-mooney[m] | basically a bfv “state of the union” talk of hay with z this is how it can now be used | |
| 08:06:23 | bauzas | Vancouver is too far away | |
| 08:06:46 | sean-k-mooney[m] | i would wait for vancouver honestly | |