Earlier  
Posted Nick Remark
#openstack-nova - 2020-09-04
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
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

Earlier   Later