| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-21 | |||
| 09:48:25 | sean-k-mooney | which woudl mean 2 ovs agent RPs | |
| 09:48:28 | bauzas | like we do with a specific n-cpu service | |
| 09:48:28 | bauzas | like we do with a specific n-cpu service | |
| 09:48:34 | bauzas | OK, gotcha | |
| 09:48:34 | bauzas | OK, gotcha | |
| 09:48:52 | bauzas | ok, by making this analogy, I feel better | |
| 09:48:52 | bauzas | ok, by making this analogy, I feel better | |
| 09:49:20 | sean-k-mooney | for what its worth i always treated the ovs agent and the ovs process as intercahngable when thinking about the resouce provider | |
| 09:49:21 | sean-k-mooney | for what its worth i always treated the ovs agent and the ovs process as intercahngable when thinking about the resouce provider | |
| 09:49:44 | gibi | today there is a strong 1:1 mapping | |
| 09:49:44 | gibi | today there is a strong 1:1 mapping | |
| 09:49:56 | sean-k-mooney | i know thats a bit hand wavy butthat was the mental model i had to reason about this | |
| 09:49:57 | sean-k-mooney | i know thats a bit hand wavy butthat was the mental model i had to reason about this | |
| 09:49:58 | bauzas | like if anyone was asking for nova-libvirt to manage two different qemu endpoints and me saying 'heh, dude, just configure another n-cpu service instead', I'd then recommend configuring separate agents | |
| 09:49:58 | bauzas | like if anyone was asking for nova-libvirt to manage two different qemu endpoints and me saying 'heh, dude, just configure another n-cpu service instead', I'd then recommend configuring separate agents | |
| 09:50:07 | gibi | technically the vnic_type trait belongs to the agent and the pps capacity belongs to the OVS datapath | |
| 09:50:07 | gibi | technically the vnic_type trait belongs to the agent and the pps capacity belongs to the OVS datapath | |
| 09:50:39 | gibi | as the agent is configurable which vnic_type to report | |
| 09:50:40 | gibi | as the agent is configurable which vnic_type to report | |
| 09:50:52 | sean-k-mooney | yes | |
| 09:51:00 | sean-k-mooney | i think that config option is used as a filter | |
| 09:51:00 | sean-k-mooney | i think that config option is used as a filter | |
| 09:51:03 | gibi | yes | |
| 09:51:12 | sean-k-mooney | rather then just being able to speciay any vnic_type but yes | |
| 09:51:12 | sean-k-mooney | rather then just being able to speciay any vnic_type but yes | |
| 09:51:40 | bauzas | ok, but again, this doesn't hurt me | |
| 09:51:40 | bauzas | ok, but again, this doesn't hurt me | |
| 09:52:07 | bauzas | in nova, we have specific resources that are tied to the compute service, while other resources are offered by the virt driver | |
| 09:52:07 | bauzas | in nova, we have specific resources that are tied to the compute service, while other resources are offered by the virt driver | |
| 09:52:20 | sean-k-mooney | so right now libvirt and os-vif can only be confirued to tlak to 1 ovs instance | |
| 09:52:20 | sean-k-mooney | so right now libvirt and os-vif can only be confirued to tlak to 1 ovs instance | |
| 09:52:40 | gibi | I honestly don't want to prevent anybody starting to draw a plant to support two OVS per agent. With the current proposal we allocate certain extra cost on such a person sure, but until I don't see that that such plan is close to reality this is a future cost that might never be paid | |
| 09:52:40 | gibi | I honestly don't want to prevent anybody starting to draw a plant to support two OVS per agent. With the current proposal we allocate certain extra cost on such a person sure, but until I don't see that that such plan is close to reality this is a future cost that might never be paid | |
| 09:52:51 | sean-k-mooney | if we wanted to support multipel on the same host we would need to have the ovs instnace connection infomathion pass form neutron to nova to tell use which one ot use | |
| 09:52:51 | sean-k-mooney | if we wanted to support multipel on the same host we would need to have the ovs instnace connection infomathion pass form neutron to nova to tell use which one ot use | |
| 09:53:25 | sean-k-mooney | * sean-k-mooney aw i have been trying to prevent two ovs for a long time :( | |
| 09:53:42 | sean-k-mooney | well on the same host | |
| 09:53:43 | sean-k-mooney | well on the same host | |
| 09:53:59 | sean-k-mooney | im totally ok with the idea of the neutorn agent managing multpile remote ovs agents | |
| 09:53:59 | sean-k-mooney | im totally ok with the idea of the neutorn agent managing multpile remote ovs agents | |
| 09:54:07 | elod | gibi bauzas lyarwood : sorry for the interrupt o:) if any of you have time for a quick look at the train-em patch and +1 it, then it would be good. so that we can proceed with that as well. https://review.opendev.org/c/openstack/releases/+/790761 | |
| 09:54:07 | elod | gibi bauzas lyarwood : sorry for the interrupt o:) if any of you have time for a quick look at the train-em patch and +1 it, then it would be good. so that we can proceed with that as well. https://review.opendev.org/c/openstack/releases/+/790761 | |
| 09:54:16 | gibi | sean-k-mooney: I'm not saying I would like to have two OVS on the same host, I just say that I don't want to prevent anybody planning it :) | |
| 09:54:16 | gibi | sean-k-mooney: I'm not saying I would like to have two OVS on the same host, I just say that I don't want to prevent anybody planning it :) | |
| 09:54:34 | gibi | elod: ack | |
| 09:54:48 | bauzas | elod: ack, will look | |
| 09:54:49 | sean-k-mooney | bauzas: do you see any reason to have booth an ovs RP and and ovs agent RP | |
| 09:54:49 | bauzas | elod: ack, will look | |
| 09:54:49 | sean-k-mooney | bauzas: do you see any reason to have booth an ovs RP and and ovs agent RP | |
| 09:55:08 | elod | thanks o/ | |
| 09:55:08 | elod | thanks o/ | |
| 09:55:10 | bauzas | sean-k-mooney: good question | |
| 09:55:10 | bauzas | sean-k-mooney: good question | |
| 09:55:12 | lyarwood | elod: looking | |
| 09:55:12 | lyarwood | elod: looking | |
| 09:55:43 | bauzas | sean-k-mooney: your last sentence on the fact that an agent RP seems irrelevant puzzles me | |
| 09:55:43 | bauzas | sean-k-mooney: your last sentence on the fact that an agent RP seems irrelevant puzzles me | |
| 09:56:02 | bauzas | sean-k-mooney: what exact resource classes do we have on the agent ? | |
| 09:56:03 | bauzas | sean-k-mooney: what exact resource classes do we have on the agent ? | |
| 09:56:07 | bauzas | the qos ones I guess ? | |
| 09:56:07 | bauzas | the qos ones I guess ? | |
| 09:56:16 | bauzas | gibi: ? | |
| 09:56:16 | bauzas | gibi: ? | |
| 09:56:27 | sean-k-mooney | it was planned to have an inventory of PORTs there at one point | |
| 09:56:28 | sean-k-mooney | it was planned to have an inventory of PORTs there at one point | |
| 09:56:58 | gibi | bauzas: pps is on the agent as per the current proposal | |
| 09:56:58 | gibi | bauzas: pps is on the agent as per the current proposal | |
| 09:57:09 | bauzas | gibi: sure, that and what else ? | |
| 09:57:09 | bauzas | gibi: sure, that and what else ? | |
| 09:57:10 | sean-k-mooney | ovs for stp reasons i belive normally has a limit of 4096 ports per bridge | |
| 09:57:10 | sean-k-mooney | ovs for stp reasons i belive normally has a limit of 4096 ports per bridge | |
| 09:57:31 | sean-k-mooney | ovs dpdk used to be 1024 and at one point that was going to reduce to 32 | |
| 09:57:31 | sean-k-mooney | ovs dpdk used to be 1024 and at one point that was going to reduce to 32 | |
| 09:57:35 | gibi | bauzas: I have no more plans :) but I defer to sean-k-mooney | |
| 09:57:35 | gibi | bauzas: I have no more plans :) but I defer to sean-k-mooney | |
| 09:58:30 | sean-k-mooney | bauzas: that was the orgin resouce class that the agent was coing to model. on the traits side it was hopped we would report the network types suspported | |
| 09:58:30 | sean-k-mooney | bauzas: that was the orgin resouce class that the agent was coing to model. on the traits side it was hopped we would report the network types suspported | |
| 09:58:31 | gibi | bauzas: I also imagine that the segment RP providign IP resources should be sharing the IP resource to the agent RP, but technically sharing with the compute RP is OK too I guess | |
| 09:58:31 | gibi | bauzas: I also imagine that the segment RP providign IP resources should be sharing the IP resource to the agent RP, but technically sharing with the compute RP is OK too I guess | |
| 09:58:46 | sean-k-mooney | the final case was incluing the agent RP in ^ | |
| 09:58:46 | sean-k-mooney | the final case was incluing the agent RP in ^ | |
| 09:59:06 | sean-k-mooney | gibi: ya the root RP woudl work | |
| 09:59:07 | sean-k-mooney | gibi: ya the root RP woudl work | |
| 09:59:26 | sean-k-mooney | althoguh | |
| 09:59:26 | sean-k-mooney | althoguh | |
| 09:59:30 | sean-k-mooney | maybe not in all cases | |
| 09:59:30 | sean-k-mooney | maybe not in all cases | |
| 09:59:36 | sean-k-mooney | if you have sriov and ovs for example | |
| 09:59:36 | sean-k-mooney | if you have sriov and ovs for example | |
| 09:59:46 | sean-k-mooney | you might want to scope it to the agent? | |
| 09:59:46 | sean-k-mooney | you might want to scope it to the agent? | |
| 10:00:01 | gibi | sean-k-mooney: I havent thought it through | |
| 10:00:01 | gibi | sean-k-mooney: I havent thought it through | |
| 10:00:15 | gibi | sean-k-mooney: maybe it belongs to the physnet bridge? | |
| 10:00:15 | gibi | sean-k-mooney: maybe it belongs to the physnet bridge? | |
| 10:00:16 | sean-k-mooney | similar to the physnet net which is scoped to the bridge | |
| 10:00:16 | sean-k-mooney | similar to the physnet net which is scoped to the bridge | |
| 10:00:35 | sean-k-mooney | well the segment is mapped to a physnet | |
| 10:00:35 | sean-k-mooney | well the segment is mapped to a physnet | |
| 10:00:45 | sean-k-mooney | so perhaps | |