| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-02 | |||
| 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/ |
|
| 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 | |
| 11:53:51 | gibi | the above API log can be the result of the client trying to use the flavor name as id and then fallbacking to listing the the flavors whent that query returns 404 | |
| 11:55:46 | frickler | seems they are not sure yet whether the change in header alignment is a bug or a feature https://github.com/jazzband/prettytable/pull/183 | |
| 11:57:41 | sean-k-mooney | frickler: if tis a feature its tecnially a breaking change so should have been a major bump | |
| 11:59:10 | frickler | sean-k-mooney: ack, added a comment on that PR now | |
| 11:59:30 | gibi | frickler: thanks | |
| 11:59:59 | frickler | maybe then we can avoid having to fix it in nova and just exclude 3.4.0 | |
| 12:04:35 | sean-k-mooney | by the way why are we not hitting this on master? | |
| 12:05:02 | sean-k-mooney | ah | |
| 12:05:10 | sean-k-mooney | master is clampped already to 3.3.3 | |
| 12:05:18 | sean-k-mooney | 3.3.0 | |
| 12:05:24 | sean-k-mooney | https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L141 | |
| 12:06:35 | sean-k-mooney | frickler: we are not clamping it on master today https://github.com/openstack/requirements/blob/5b346cf74df6bbfc67f794c053d3c4210da4bacb/global-requirements.txt#L197 | |
| 12:06:48 | sean-k-mooney | we just have not merged the update to move it forward form 3.3.0 | |
| 12:06:54 | sean-k-mooney | but we have done that on yoga | |
| 12:07:07 | sean-k-mooney | presumable this can break all branches | |
| 12:07:31 | sean-k-mooney | so we shoudl definlaly also clamp it on master to prevent breaking the gat during FF | |
| 12:08:24 | sean-k-mooney | elodilles: gibi ^ | |
| 12:09:10 | gibi | sean-k-mooney: it is known and intentionally not updated on master by https://review.opendev.org/c/openstack/requirements/+/854862/2..3/upper-constraints.txt | |
| 12:09:33 | gibi | sean-k-mooney: we are pinned to 3.3.0 on master at the moment | |
| 12:09:46 | sean-k-mooney | where | |
| 12:10:09 | sean-k-mooney | that goign to get overrided when the bot runs | |
| 12:10:15 | gibi | https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L141 | |
| 12:11:02 | gibi | sean-k-mooney: this all happend already. the bot ran and update the constraint, the nova job failed on the requirements patch, and then frickler removed the bump from the patch | |
| 12:11:28 | sean-k-mooney | hum ok | |
| 12:11:40 | gibi | frickler even pinged us during the weekend about it :) | |
| 12:11:44 | sean-k-mooney | so instead of pinning it in global-requireemnts where the both will not try to bump it | |