| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-04 | |||
| 14:11:13 | sean-k-mooney | deprecating it im more ok with | |
| 14:11:31 | dansmith | well, we might have only noticed that we weren't patching when the cells stuff was added, we weren't really running in real wsgi mode much before that, | |
| 14:11:41 | dansmith | so perhaps we weren't but didn't notice in a devstack that it mattered | |
| 14:12:15 | sean-k-mooney | ya that is more or less my feels on it too | |
| 14:12:37 | dansmith | but yeah, I dunno about changing the default.. especially if it's configureable back, it doesn't seem *that* bad to me | |
| 14:13:11 | sean-k-mooney | i guess we just need to test it and flag it to ooo if we see it causing gate issue | |
| 14:13:20 | sean-k-mooney | or in our donwstream testing | |
| 14:13:34 | dansmith | aye | |
| 14:16:28 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support SRIOV interface attach and detach https://review.opendev.org/740995 | |
| 14:17:24 | gibi | sean-k-mooney, stephenfin: I finished adding functional tests. I consider this patch ready for review ^^ | |
| 14:19:55 | sean-k-mooney | gibi: cool on downstream call but ill look after | |
| 14:20:02 | gibi | thanks | |
| 14:31:04 | gibi | stephenfin: here is a simple doc patch to light up your Friday https://review.opendev.org/#/c/744492 | |
| 14:48:31 | stephenfin | gibi: done the latter, looking at the former now | |
| 14:49:50 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Add a routed networks scheduler pre-filter https://review.opendev.org/749068 | |
| 14:49:51 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add requested_networks field to RequestSpec object https://review.opendev.org/749977 | |
| 14:49:57 | bauzas | gibi: sean-k-mooney: ^ routed networks | |
| 14:50:15 | bauzas | still a WIP because I wanted to make better functional tests | |
| 14:50:32 | bauzas | but this seems to work for migrating too \o/ | |
| 14:51:08 | bauzas | gibi: stephenfinat least, you can get another segment from the same network, right? | |
| 14:51:11 | bauzas | whoops | |
| 14:51:17 | bauzas | gibi: sean-k-mooney: ^ | |
| 14:54:12 | sean-k-mooney | bauzas: you can have multiple segment in an network yes | |
| 14:54:18 | bauzas | I know | |
| 14:54:20 | sean-k-mooney | you will have 1 per subnet | |
| 14:54:29 | bauzas | but then it's okay | |
| 14:54:39 | sean-k-mooney | but ya ill take a look after i look at gibis patches | |
| 14:54:52 | bauzas | np, just wanted to make sure this was an expected behaviour | |
| 14:55:02 | bauzas | ie. to not limit to the existing segment | |
| 14:55:08 | bauzas | (for moves) | |
| 14:55:24 | bauzas | sean-k-mooney: amirite ? | |
| 14:57:29 | openstackgerrit | Merged openstack/nova master: Revert "Handle Neutron errors in _post_live_migration()" https://review.opendev.org/747443 | |
| 14:59:12 | gibi | stephenfin: thanks | |
| 14:59:19 | gibi | bauzas: I will check soon | |
| 14:59:32 | bauzas | cool, ta | |
| 14:59:42 | sean-k-mooney | bauzas: for move you have to move ot the same segment | |
| 14:59:50 | sean-k-mooney | bauzas: you cannot move to another segment | |
| 15:00:06 | bauzas | ah | |
| 15:00:11 | sean-k-mooney | bauzas: since the ip cannot change and is only valid in the specific segment it is allcoated form | |
| 15:00:16 | bauzas | then it's not good | |
| 15:00:38 | bauzas | sean-k-mooney: yeah, I was thinking of this | |
| 15:00:52 | sean-k-mooney | thats the main point of the feature to only migrate in the same segment | |
| 15:01:52 | sean-k-mooney | by the way this part of why i want to put the segment in the vif object | |
| 15:02:25 | sean-k-mooney | bauzas: right now without that you need to check which subnet the ip is from and hten use that to figure out which segment it is | |
| 15:02:56 | bauzas | again I need to verify why I got a host from another segment then | |
| 15:03:21 | bauzas | that's not me who wrote the functest so I need to verify a few things | |
| 15:03:22 | sean-k-mooney | i havent looked at your code but ill keep an eye out for that | |
| 15:35:34 | gmann | dansmith: any reason we did not add nova-ceph-multistore in gate pipeline though it is voting | |
| 15:36:06 | sean-k-mooney | gmann: do we need it there. we dont add all jobs to gate | |
| 15:36:15 | dansmith | gmann: I think because the ceph job wasn't there, right? but no reason not to, IMHO | |
| 15:36:16 | gmann | sean-k-mooney: we need to add if voting | |
| 15:36:30 | sean-k-mooney | we have several voting jobs that are not in gate | |
| 15:36:41 | gmann | dansmith: ohk, and ceph job was made voting later. | |
| 15:37:20 | dansmith | the ceph-multistore job vastly increases coverage of nova and ceph and glance, IMHO, so it's not bad to have it gating, IMHO | |
| 15:37:45 | sean-k-mooney | gmann: compare https://github.com/openstack/nova/blob/master/.zuul.yaml#L480-L494 vs https://github.com/openstack/nova/blob/master/.zuul.yaml#L425-L479 | |
| 15:37:57 | sean-k-mooney | dansmith: im not against adding it | |
| 15:38:09 | sean-k-mooney | just the idea that voting = in gate and check | |
| 15:38:16 | bauzas | sean-k-mooney: okay, I think I found the problem | |
| 15:38:32 | bauzas | sean-k-mooney: for create, we don't need to verify the segments | |
| 15:38:39 | bauzas | for a network | |
| 15:38:43 | bauzas | but for a port, we do | |
| 15:38:47 | sean-k-mooney | bauzas: correct | |
| 15:38:49 | bauzas | and then, for a move op, too | |
| 15:38:55 | sean-k-mooney | well for a port only if it has an ip | |
| 15:39:00 | bauzas | we need to look at the port to know the segment | |
| 15:39:16 | bauzas | it has a port when moving, right? | |
| 15:39:30 | sean-k-mooney | yes | |
| 15:39:31 | bauzas | I mean, it does have an ip address | |
| 15:39:37 | sean-k-mooney | yes | |
| 15:39:40 | bauzas | okay, so for create, meh | |
| 15:39:49 | gmann | sean-k-mooney: there is no voting job which is not running on gate pipeline except the ceph one - https://review.opendev.org/#/c/747443/ | |
| 15:39:55 | bauzas | unless if it has a specific address | |
| 15:40:00 | sean-k-mooney | gmann: nova-lvm | |
| 15:40:05 | gmann | it is n-v | |
| 15:40:08 | sean-k-mooney | gmann: that is only in check | |
| 15:40:29 | gmann | https://github.com/openstack/nova/blob/master/.zuul.yaml#L136 | |
| 15:40:36 | sean-k-mooney | also the linux bridge one | |
| 15:40:59 | sean-k-mooney | oh we shoudl stop setting that there | |
| 15:41:03 | sean-k-mooney | and move it down | |
| 15:41:04 | bauzas | sean-k-mooney: fwiw, the spec is then invalid for the pseudo-code | |
| 15:41:13 | bauzas | sean-k-mooney: https://specs.openstack.org/openstack/nova-specs/specs/victoria/approved/routed-networks-scheduling.html#proposed-change | |
| 15:41:15 | bauzas | but meh | |
| 15:41:27 | bauzas | i'll look at the requested network | |
| 15:41:38 | bauzas | if it has a ip address, I'll look at the segment | |
| 15:41:56 | bauzas | if it doesn't have an ip address, I'll just look at all the segments from the network | |
| 15:42:02 | bauzas | sean-k-mooney: lgty ? ^ | |
| 15:42:25 | sean-k-mooney | am ya that sound viable | |
| 15:42:32 | bauzas | cool | |
| 15:42:45 | bauzas | we're getting the fixed IPs from the VIF | |
| 15:42:54 | bauzas | (in the instance infocache) | |
| 15:43:00 | sean-k-mooney | yes | |
| 15:43:07 | bauzas | so I can look at them and ask for the related segments | |
| 15:43:11 | bauzas | amirite ? | |
| 15:43:22 | gmann | sean-k-mooney: yeha only neutron-tempest-linuxbridge is 2nd one not in gate, i did not notice this as it is defined in neutron side | |
| 15:43:37 | bauzas | now, the big question is : how can I get a segment from an IP address, but I'll figure this out | |
| 15:43:54 | sean-k-mooney | bauzas: you need to get the subnet with is in the vif too | |
| 15:44:01 | bauzas | ah, right | |
| 15:44:03 | sean-k-mooney | so instead of looking at the ips | |
| 15:44:08 | sean-k-mooney | you cna look at teh subnet | |
| 15:44:08 | bauzas | then this is better | |