| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-04 | |||
| 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 | bauzas | then this is better | |
| 15:44:08 | sean-k-mooney | you cna look at teh subnet | |
| 15:44:32 | sean-k-mooney | so i would like to update the subnet object ot have the segment id in it optionally at some point | |
| 15:44:43 | bauzas | okay, lemme look | |
| 15:44:55 | sean-k-mooney | well proably beter to put the segment in the vif object | |
| 15:45:05 | bauzas | eek | |
| 15:45:06 | sean-k-mooney | we should not have a singel port on multipel segment | |
| 15:45:07 | bauzas | can't do it | |
| 15:45:21 | sean-k-mooney | that is the correct place to put it | |
| 15:46:43 | sean-k-mooney | we can put it in the subnet but even though a port can have multipel ips form multiple subnets in general that is not true for routed networks | |
| 15:47:07 | sean-k-mooney | well... | |
| 15:47:08 | gibi | bauzas: I think looking at the ip_allocation of the port is a better source of information than checking if it has an ip or not | |
| 15:47:25 | bauzas | sean-k-mooney: I can try to lookup directly in the pre-filter | |
| 15:47:36 | bauzas | gibi: good point | |
| 15:47:37 | sean-k-mooney | no it cant because of limitation in the neutron implemation | |
| 15:47:45 | bauzas | but grrrr, I need to stop working | |
| 15:48:09 | bauzas | parents-teacher meeting at 6pm, since kids are back at school | |
| 15:48:10 | sean-k-mooney | gibi: we could but i think caching it in the VIF is better | |
| 15:48:32 | sean-k-mooney | to avoid needign to call neutron during the prefileter | |
| 15:48:35 | gibi | sean-k-mooney: for move operations I'm OK with that | |
| 15:48:49 | sean-k-mooney | gibi: ya for create since we dont have the vif objects | |
| 15:48:50 | gibi | bauzas: no worries, enjoy your weekend | |
| 15:48:56 | bauzas | thinking out loud, this is unrealistic to merge it before victoria-3 | |
| 15:48:58 | sean-k-mooney | we need to look it up if we are passed a port | |
| 15:49:27 | sean-k-mooney | proably altough viable for early m1 | |
| 15:49:31 | bauzas | so, I'll continue working on it, but let's all agree this will be a Wallaby merge | |
| 15:49:43 | bauzas | yeah, can continue investigating during RC1 | |
| 15:49:55 | bauzas | we're close to the job done, I think | |
| 15:50:02 | gibi | bauzas: OK. let's merge this in W | |
| 15:50:21 | sean-k-mooney | bauzas: for the limited usecases in the spec maybe :) | |
| 15:50:29 | sean-k-mooney | enjoy o/ | |
| 15:51:11 | gibi | bauzas: also if you boot an instance with a network then I think nothing guarantees that every compute host will is attached to one of the segments of that networks. So we still have to filter hosts based on segments even if the instance is booted with network | |
| 15:51:59 | bauzas | gibi: we do it already in my change | |
| 15:52:29 | gibi | bauzas: yes, you just said something about it above and I wanted to make sure this check will not be removed | |
| 15:52:32 | gibi | :) | |
| 15:52:46 | gibi | bauzas: also I read through your patches and I like them | |
| 15:52:59 | gibi | thanks for picking up this feature | |
| 15:53:27 | sean-k-mooney | gibi: ya so bauzas is going to limit to the full set of segment on a network if we boot to a network | |
| 15:53:46 | sean-k-mooney | or just the segment related to the ip if we have a port with an ip | |
| 15:54:11 | gibi | sean-k-mooney: yeah that feels correct | |
| 15:54:13 | sean-k-mooney | gibi: so that will covert the case fo only looking at the subset of host with the correct segment reacblitiy | |
| 15:54:21 | gibi | aagree | |
| 15:56:07 | sean-k-mooney | gibi: did you see https://review.opendev.org/#/c/749175/1 by the way | |
| 15:56:32 | sean-k-mooney | that might fix the PF edgecase i notes while testing your code | |
| 15:56:39 | gibi | no I haven't | |
| 15:56:49 | gibi | I will check that patch on Monday | |
| 15:56:51 | sean-k-mooney | ill try to test that on monday and ill retest your code | |
| 15:56:56 | gibi | cool | |
| 15:57:14 | sean-k-mooney | they are proposing it for a different edgecase | |
| 15:57:31 | sean-k-mooney | where a deivce did not support sriov and after some operation it now does | |
| 15:57:42 | sean-k-mooney | changing it form type-pci to type-PF | |
| 15:58:39 | sean-k-mooney | that only happens if 1 you change the device phsyically, 2 you updated the frimeare to add sriov supprot, 3 you reconfitre the firmware/bios to supprot it by for exampel chanige from datacenter bridging mode to sriov mode | |