| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-24 | |||
| 13:30:09 | sean-k-mooney | ack | |
| 13:30:23 | gibi | as I'm against silently ignoring things | |
| 13:30:26 | sean-k-mooney | ill try and take a look at the rest of the series but swapping to email for a bit | |
| 13:31:09 | gibi | sean-k-mooney[m]: thanks, no need to rush, I'm still working on the test for the top patch of the series then I will move from the db layer to the object / api | |
| 13:31:52 | sean-k-mooney | ack. do you have any nova feature that will consome this this cycle by the way | |
| 13:36:50 | gibi | no not at this cycle | |
| 13:37:10 | gibi | in the future I'd like to extend the qos support for multisegment networks | |
| 13:37:27 | gibi | where a port might belong to physnet A or physnet B hence the any-trait support need | |
| 13:37:55 | sean-k-mooney | right although really your talking about adding suport for multi segment provider networks | |
| 13:38:07 | sean-k-mooney | and just making sure it works with qos too | |
| 13:38:30 | sean-k-mooney | since we dont really support the multi provider physnet extnsion at all in nova today | |
| 13:38:37 | sean-k-mooney | we just use the first one always | |
| 13:38:50 | gibi | yeah we have a big hole in that support, but in a certain edge case it works :) | |
| 13:38:52 | sean-k-mooney | but yes that is a good use case for it | |
| 13:39:14 | sean-k-mooney | edge case beign you dont use sriov or qos | |
| 13:39:42 | gibi | if you use both, and the SRIOV is your first segment and you dont use numa aware vswitches then it works :) | |
| 13:39:47 | sean-k-mooney | gibi: once we have the ablity to supprot multi segment network we can do generic physnet arare shculding | |
| 13:40:03 | gibi | sean-k-mooney: yes, and I will look into making the generic case work of course | |
| 13:40:22 | sean-k-mooney | ack which woudl be a nice win | |
| 13:40:57 | gibi | I agree | |
| 13:41:04 | sean-k-mooney | its kind of amazing that we will only strat checkign if the phynest is on thet host in the 26th release :) | |
| 13:41:17 | gibi | better late than never :) | |
| 13:51:27 | sean-k-mooney | gibi: by the way the totaly generic case required neturon changes or addtional placment changes to allow matching tratis form sharing RPs without resouce requests | |
| 13:52:00 | sean-k-mooney | e.g. we need to be abel to create shareign RPs for the physnets and assocaited them with the compute nodes via aggreate | |
| 13:52:44 | sean-k-mooney | thos can be resouceless or they can contian invnetories of subnets/ip wand the port can request an allocation form them | |
| 13:53:05 | sean-k-mooney | so i suspect it will be simpler for you to get it working with qos ports first | |
| 13:53:31 | gibi | hm | |
| 13:53:56 | gibi | currently we have physnet RPs on the bridge RP or on the PF RP | |
| 13:54:01 | sean-k-mooney | then netron can report the ip inventorires or port invetories or whatever we use so that all ports can have a resouce request form the provier or the trait | |
| 13:54:11 | sean-k-mooney | gibi: yep we do | |
| 13:54:16 | gibi | ahh I see now | |
| 13:54:22 | gibi | we need a resource for the non QoS ports | |
| 13:54:27 | sean-k-mooney | yes | |
| 13:54:27 | gibi | and that would be the IP | |
| 13:54:37 | sean-k-mooney | ip or port or something else universal | |
| 13:54:55 | gibi | hm, there is a spec for ip less ports | |
| 13:54:57 | sean-k-mooney | or a placment feature to allow matching tratis agiasts resouceless rps | |
| 13:55:00 | gibi | so the ip is not universal | |
| 13:55:12 | sean-k-mooney | ya port likely is the best candiate | |
| 13:55:22 | gibi | OK, lets revisit this for the next cycle | |
| 13:55:28 | gibi | but good points | |
| 13:55:29 | gibi | thanks | |
| 13:55:36 | sean-k-mooney | yep i dont see this as a blocker to what you want to enable | |
| 13:55:55 | sean-k-mooney | just to the end goal fo network aware schdulign so it a sperate spec for the fully generic case | |
| 13:56:38 | sean-k-mooney | shduing based on ip aviablity is partly there for routed networks but as you and bauzas found out when impleenting it they are currently doign a hack with the reserved value | |
| 13:56:44 | sean-k-mooney | which we shoudl clean up eventually | |
| 13:58:40 | gibi | yepp | |
| 14:57:52 | opendevreview | Dan Smith proposed openstack/nova master: Add service version check workaround for FFU https://review.opendev.org/c/openstack/nova/+/826097 | |
| 14:57:59 | Guest295 | sean-k-mooney: gibi ^ | |
| 14:58:18 | gibi | dansmith: ack , will check | |
| 14:58:43 | dansmith | gibi: I assume you saw that thread on the ML | |
| 14:58:51 | gibi | yes | |
| 14:58:54 | dansmith | gibi: I've been working on an FFU grenade lately and poked that pretty easy :/ | |
| 14:59:08 | gibi | and we talked it through with sean-k-mooney last week | |
| 14:59:31 | gibi | I'm not against the WA flag | |
| 14:59:47 | gibi | as it is disabled by default | |
| 15:00:06 | dansmith | I think it sucks to need it, especially to set it for an upgrade, but I think it's probably the most straightforward mitigation at the moment | |
| 15:01:10 | gibi | yeah. I'm +2 on it, it is simple | |
| 15:01:17 | sean-k-mooney | i would proably have gone with "compute_service_check_is_fatal" to align with teh vif_plug checks but ya as a temp fix i think its the simplest thing to do | |
| 15:02:06 | dansmith | sean-k-mooney: workarounds were all supposed to be boolean, =False by default and opt-in to some alternate behavior | |
| 15:02:06 | sean-k-mooney | i can take a looks at it in a few just finishing up something | |
| 15:02:17 | dansmith | so that they should all be "off" in normal operation | |
| 15:02:28 | dansmith | we've deviated from that quite a bit unfortunately, but I hold the flame :) | |
| 15:02:48 | sean-k-mooney | ya i agree it should be off by default | |
| 15:03:05 | sean-k-mooney | and is_fatal woudl be one by default so what you suggested is more correct | |
| 15:03:13 | sean-k-mooney | i was orginially thinking this would not be a workaround | |
| 15:03:42 | sean-k-mooney | i guess my main question is do we know what we want to replace it with long term | |
| 15:03:47 | dansmith | we probably need to figure out how to fix this without a workaround, as noted, but this is a simple backport to get people out of the box | |
| 15:03:49 | dansmith | yeah, I dunno | |
| 15:04:01 | sean-k-mooney | you made a good point that looking at "up" is potentially racy | |
| 15:05:14 | dansmith | yeah | |
| 15:05:56 | sean-k-mooney | so for your grenade job i assuem you are just going to set this to true | |
| 15:06:14 | sean-k-mooney | we need to backport this to wallaby before that job can merge howere right | |
| 15:06:21 | sean-k-mooney | since it need to be set pre upgrade | |
| 15:06:36 | sean-k-mooney | or i guess xena not wallaby | |
| 15:06:57 | dansmith | sean-k-mooney: no we only need it on the target | |
| 15:07:01 | dansmith | but we need to backport it for people | |
| 15:07:19 | sean-k-mooney | well we only need it on the target but we are not ment to requrie config updates on upgrade | |
| 15:07:33 | sean-k-mooney | so to have both be true we should have the config option avaiable in the source version right | |
| 15:07:43 | sean-k-mooney | so just another reason to backport | |
| 15:08:40 | sean-k-mooney | actully so i guess design question for FFU are we going to assume the "no config updates are requried" part still hold true | |
| 15:08:46 | sean-k-mooney | or is that just for n to n+1 | |
| 15:09:04 | dansmith | well, this is really a FFU-specific config option, so it's appropriate for grenade until it's fixed, IMHO | |
| 15:09:14 | dansmith | running (base) with this enabled would be wrong and not like production | |
| 15:09:42 | sean-k-mooney | ack ok i can buy that. | |
| 15:09:43 | dansmith | no config updates from n-2 to n is a different thing, and I don't think we need to stick to that, no | |
| 15:09:51 | dansmith | however, this is an upgrade bug/quirk mitigation | |
| 15:29:56 | opendevreview | Lee Yarwood proposed openstack/nova master: WIP libvirt: Register defaults for undefined hw image properties https://review.opendev.org/c/openstack/nova/+/800708 | |
| 15:29:57 | opendevreview | Lee Yarwood proposed openstack/nova master: WIP manage: Add image_property commands https://review.opendev.org/c/openstack/nova/+/824392 | |
| 15:30:14 | sean-k-mooney | dansmith: https://review.opendev.org/c/openstack/nova/+/826097/1/nova/service.py#265 do you want this to work for just the conductor/schduler or also the api | |
| 15:30:55 | dansmith | sean-k-mooney: conductor is the important one, because it's how computes update their record.. does the api check separately? | |
| 15:31:02 | sean-k-mooney | yes | |
| 15:31:10 | sean-k-mooney | https://github.com/openstack/nova/blob/909cfc76369b94b026cf42b86fb5a310dce21a8c/nova/api/openstack/wsgi_app.py#L50 | |
| 15:31:34 | dansmith | ah, for wsgi yeah | |
| 15:31:45 | sean-k-mooney | when i was check rpc compatiabliy for train-> wallaby i had to commet out both | |
| 15:31:59 | dansmith | yeah I'll update | |
| 15:32:13 | dansmith | I imagine systemd is restarting api enough that it wasn't a problem for me in my grenade | |
| 15:32:27 | dansmith | I'm running a job on top of that now, but I will update when it's done | |
| 15:32:39 | dansmith | thanks for catching | |
| 15:36:44 | sean-k-mooney | no worries ping me when its up and ill rereview. | |