Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-09-02
10:44:00 sean-k-mooney that will need a neutron spec and there will have to be a dicussion of if that shoudl be something that the operator defince and a user slects
10:44:05 sean-k-mooney kind of like qos polcies
10:44:12 auniyal I was looking this one https://docs.openstack.org/nova/ussuri/user/resize.html
10:44:13 sean-k-mooney or if the user should be able ot request quese
10:49:59 justas_napa in my PoV, it should be something that operator defines, because it is related to the underlying HW
10:50:21 justas_napa like a flavor of an instance
10:50:30 sean-k-mooney justas_napa: which is not compatible how openstack is ment to work
10:50:46 sean-k-mooney openstack is ment to be an cloud abstraction
10:51:21 sean-k-mooney there are some atribute that we can expsoe but low level hardware turnign is out of scope
10:51:44 sean-k-mooney justas_napa: what we can do is scudle based on how many quee are avaible with some constriats
10:52:07 sean-k-mooney and provide a way to ask for a VF with x queue
10:52:26 justas_napa yes, I think this would be OK
10:52:57 sean-k-mooney we can also have the libvirt driver do min(vf_queue,vcpus)
10:53:09 sean-k-mooney on a per interface basis
10:53:21 justas_napa that is actually a very good idea
10:53:54 sean-k-mooney those are the types of abstration that we need to build to make this useable in a openstack context.
10:54:16 sean-k-mooney where the end user does not know anything about the hardware and the operator knows nothing about the worklaod
10:55:20 gibi elodilles: JayF: sean-k-mooney: the requirement fix for the stable/yoga prettytable gate block https://review.opendev.org/c/openstack/requirements/+/855643
10:57:04 gibi frickler: ^^ this is also related to the prettytable issue you reported last weekend
10:59:40 justas_napa but allowing to ask for VF w/ X queues meant that we expose the use to some kind of knowledge of underlying HW
11:00:36 sean-k-mooney it depens on how its done
11:00:40 justas_napa Isn't this like allowing a user to choose an instance with 1G or 4G of RAM?
11:01:15 sean-k-mooney for example if we created a neutron qos policy that enabled (packeed queues, multi queue and 4 queue)
11:01:21 sean-k-mooney then the user could select that
11:01:24 justas_napa ant then allocating this instance on a server that has enough resources (in this case, a VF with required number of queues)
11:01:30 sean-k-mooney the operator is provideeing the hward ware knoladge
11:01:41 sean-k-mooney the user is jsut select the mutliqueue qos policy
11:02:10 sean-k-mooney justas_napa: if we did it ^ way
11:02:12 sean-k-mooney it woudl be
11:02:26 sean-k-mooney if we jsut put the number of quese in the bining profile its not
11:03:26 frickler gibi: ah, I'd rather see a fix than a pin, but anyway. also not sure how we actually py39 pins when we don't have them there globally
11:03:35 justas_napa I think we are aligned on the overall idea of implementation. The only question is the implementation.
11:05:01 sean-k-mooney i think you will need to build agreement between both nova and neutron to move this forward
11:05:06 sean-k-mooney it will require 2 specs
11:05:06 gibi frickler: the above pin is for stable/yoga. I'm not sure we ever intended to test with unconstrained deps on stable
11:05:26 sean-k-mooney justas_napa: and it will require quite a bit more designg work before it can proceed
11:05:47 sean-k-mooney justas_napa: im not against supprot multi queue with hardware offloead ovs
11:06:10 sean-k-mooney but just seting expectation that his is a lot more invoveld then your spec implies.
11:08:14 frickler gibi: right, let's discuss that in the requirements team.
11:08:31 gibi frickler: sure
11:08:31 sean-k-mooney justas_napa: have you read https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html
11:08:53 sean-k-mooney justas_napa: if not you shoudl read it in detail becasue your propoals will ahve to be compatable with that and its futrue direction
11:10:20 sean-k-mooney gibi: https://review.opendev.org/c/openstack/nova-specs/+/855514/ that would be good for you to add to your review list as the scdhuling aspecst will directly affect pci in placment eventually
11:11:47 sean-k-mooney justas_napa: have you spoken to the neutron team about this by the way
11:15:06 sean-k-mooney gibi: just reviewd https://review.opendev.org/c/openstack/placement/+/849348 form stephen. we are just pass FF bug this is a bug fix as far as im concerned so is it still ok to merge it
11:16:12 gibi sean-k-mooney: this is a bugfix so I'm OK to land it
11:16:19 gibi sean-k-mooney: bug we don't have the tracking bug for it
11:16:44 gibi bug/but
11:17:13 sean-k-mooney ya i noticed that. we dont always require it but it is nice to have. it would be a story because placment
11:17:31 sean-k-mooney i stongly dislike story broard
11:17:58 sean-k-mooney i suspect that is why stephen did not file one too
11:19:17 sean-k-mooney bauzas: any input ^
11:19:31 sean-k-mooney or stephenfin if you are about
11:26:18 elodilles gibi: thanks, looks good!
11:29:15 gibi sean-k-mooney: I've added my immediate questions and suggestions the the smartnic mutiqueue spec
11:29:22 gibi thanks for the headsup
11:29:25 elodilles gibi: i just wonder why this does not affect master branch :-o
11:30:03 gibi elodilles: on master prettytable is pinned
11:30:08 gibi in upper constarints
11:30:13 elodilles oh, is it? :-o
11:30:13 gibi I think
11:30:34 gibi https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L141
11:30:37 gibi it is
11:30:40 gibi without python version filter
11:30:44 gibi but on stable/yoga
11:30:54 gibi it is only pinned for py38 and py36
11:31:07 gibi not for py39
11:31:36 gibi the general issue that there is no py39 pins in upper constarints on stable/yoga is now raised in the requirements channel
11:32:44 elodilles for the record, this means whenever prettytable reqs will be bumped on master branch things will break on master as well :S
11:36:08 opendevreview Balazs Gibizer proposed openstack/nova master: Rename _to_device_spec_conf to _to_list_of_json_str https://review.opendev.org/c/openstack/nova/+/855648
11:36:09 opendevreview Balazs Gibizer proposed openstack/nova master: Strictly follow placement allocation during PCI claim https://review.opendev.org/c/openstack/nova/+/855650
11:36:09 opendevreview Balazs Gibizer proposed openstack/nova master: Reproduce PCI pool filtering bug https://review.opendev.org/c/openstack/nova/+/855649
11:37:36 gibi elodilles: yes it was detected during the last weekend by frickler here https://zuul.opendev.org/t/openstack/build/2e4535d6aa2d4fd987ddfd0d0bc296d1
11:37:48 gibi elodilles: and the master constraint was not bumped
11:38:01 gibi https://review.opendev.org/c/openstack/requirements/+/854862/2..3/upper-constraints.txt
11:40:02 elodilles yet
11:40:16 elodilles but we'll need to bump after some time
11:41:11 elodilles today is the Requirements Freeze date, so for Zed this is probably OK
11:42:15 gibi yes, I agree that we should do something on master
11:42:40 gibi I'm not sure at the moment that we need to directly adapt to the breaking change in a minor version or what
11:43:29 gibi as I haven't looked it into what exactly changed in prettytable and what our test expects exacltly
11:43:40 elodilles yepp, i also don't know whether this is a feature or a bug in prettytable :)
11:43:46 gibi exactly
11:43:59 auniyal I am getting lot of these - http://pastebin.test.redhat.com/1072393, for unknown reason
11:43:59 justas_napa sean-k-mooney: sorry for a late reply, work meeting. No, I have not talked with Neutron yet, I check the proposal you've linked.
11:44:39 auniyal flavour is available, I can see it user openstack flavor show, but still ....
11:44:45 gibi auniyal: you have to put that into a public pastebin as the linked one is RH internal
11:44:56 gibi ie. you can use https://paste.opendev.org/
11:45:44 gibi I can look at it as I'm in RH but like elodilles cannot
11:46:15 auniyal thanks, gibi, sure will use opendev
11:46:29 auniyal copied here as well - https://paste.opendev.org/show/bDpuAInn7ZW6bETeUVjU/
11:48:58 gibi auniyal: GET /flavors/ expects a flavor_id not the name of the flavor https://docs.openstack.org/api-ref/compute/?expanded=show-flavor-details-detail#show-flavor-details
11:49:27 gibi so in "GET /compute/v2.1/flavors/m1.medium" the m1.medium is the name of the flavor not the id
11:49:36 auniyal I ran resize operation, last time it took name
11:49:52 gibi the openstack client can translate between names and ids
11:49:55 auniyal like today only
11:50:01 opendevreview Vlad Gusev proposed openstack/nova stable/stein: Ensure MAC addresses characters are in the same case https://review.opendev.org/c/openstack/nova/+/855553
11:50:25 auniyal so I should try to use ID instead of name
11:50:49 gibi btw, during such translation the openstack client will try the name as a flavor id and if that query returns 404 then it lists the flavors and filter by name locally
11:52:16 gibi if you do things via the openstack client then you can use --debug to look at what API requests the client make so you can correlate the error in the nova log with the client request

Earlier   Later