| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-21 | |||
| 09:45:00 | bauzas | sense* | |
| 09:45:00 | bauzas | sense* | |
| 09:45:21 | sean-k-mooney | so if you wanted you could have 1 bridge using dpdk and the other using the kernel datapath | |
| 09:45:21 | sean-k-mooney | so if you wanted you could have 1 bridge using dpdk and the other using the kernel datapath | |
| 09:45:25 | bauzas | exactly like a qemu instance I guess | |
| 09:45:25 | bauzas | exactly like a qemu instance I guess | |
| 09:45:30 | sean-k-mooney | and they woudl have indepent capsities | |
| 09:45:30 | sean-k-mooney | and they woudl have indepent capsities | |
| 09:45:47 | bauzas | yeah, i can imagine that | |
| 09:45:47 | bauzas | yeah, i can imagine that | |
| 09:46:04 | bauzas | exactly like you could have a nova-compute using different qemu endpoints | |
| 09:46:04 | bauzas | exactly like you could have a nova-compute using different qemu endpoints | |
| 09:46:05 | sean-k-mooney | there woudl still only be one ovs-vsiwwtch process in that case | |
| 09:46:05 | sean-k-mooney | there woudl still only be one ovs-vsiwwtch process in that case | |
| 09:46:27 | bauzas | but in this case, this would be easier to have one n-cpu per qemu endpoint, right? | |
| 09:46:27 | bauzas | but in this case, this would be easier to have one n-cpu per qemu endpoint, right? | |
| 09:46:40 | sean-k-mooney | yes it would | |
| 09:46:40 | sean-k-mooney | yes it would | |
| 09:46:56 | sean-k-mooney | if you wnated to run ovs and ovs-dpdk on the same host | |
| 09:46:56 | sean-k-mooney | if you wnated to run ovs and ovs-dpdk on the same host | |
| 09:47:07 | bauzas | okay, so making an analogy | |
| 09:47:07 | bauzas | okay, so making an analogy | |
| 09:47:14 | sean-k-mooney | the simplete way to do it woudl be to have 2 ovs isntances and dbs and 2 agents | |
| 09:47:14 | sean-k-mooney | the simplete way to do it woudl be to have 2 ovs isntances and dbs and 2 agents | |
| 09:47:33 | bauzas | this is easier to have one single ovs-vswitch per datapath instance | |
| 09:47:33 | bauzas | this is easier to have one single ovs-vswitch per datapath instance | |
| 09:47:42 | bauzas | yeah | |
| 09:48:10 | bauzas | and then 2 agents | |
| 09:48:10 | bauzas | and then 2 agents | |
| 09:48:25 | sean-k-mooney | which woudl mean 2 ovs agent RPs | |
| 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 | |