| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-21 | |||
| 09:39:30 | bauzas | gibi: fwiw, I wouldn't speak of a new virt driver | |
| 09:39:44 | bauzas | gibi: that said, adding a new virt driver isn't a big deal in nova and you know | |
| 09:39:44 | bauzas | gibi: that said, adding a new virt driver isn't a big deal in nova and you know | |
| 09:40:31 | bauzas | gibi: I was more considering that some network people could think that multiple switches on an agent could be nice | |
| 09:40:31 | bauzas | gibi: I was more considering that some network people could think that multiple switches on an agent could be nice | |
| 09:40:46 | bauzas | for HA or whatever | |
| 09:40:46 | bauzas | for HA or whatever | |
| 09:41:06 | bauzas | I'm no longer surprised by the creativity of the community | |
| 09:41:06 | bauzas | I'm no longer surprised by the creativity of the community | |
| 09:41:16 | sean-k-mooney | ha | |
| 09:41:16 | sean-k-mooney | ha | |
| 09:41:50 | sean-k-mooney | last time i suggested adding a new virt driver it got shot down quicker then adding cellsv1 back | |
| 09:41:50 | sean-k-mooney | last time i suggested adding a new virt driver it got shot down quicker then adding cellsv1 back | |
| 09:42:13 | bauzas | (that being said, I'm up with sean-k-mooney on the fact that I also feel that modeling the agent itself is pointless if no resources are really offered by it) | |
| 09:42:14 | bauzas | (that being said, I'm up with sean-k-mooney on the fact that I also feel that modeling the agent itself is pointless if no resources are really offered by it) | |
| 09:42:47 | bauzas | sean-k-mooney: I was just mentioning this is *technically* easy to develop a new driver :) | |
| 09:42:47 | bauzas | sean-k-mooney: I was just mentioning this is *technically* easy to develop a new driver :) | |
| 09:42:50 | sean-k-mooney | what is the meaning of modelign the vswitch by the way | |
| 09:42:50 | sean-k-mooney | what is the meaning of modelign the vswitch by the way | |
| 09:43:13 | sean-k-mooney | give the packet procesing rate is an atribute of the datapath instnace | |
| 09:43:13 | sean-k-mooney | give the packet procesing rate is an atribute of the datapath instnace | |
| 09:43:25 | gibi | the agent RP was added originally to have a clear root RP for the agent to handle. | |
| 09:43:25 | gibi | the agent RP was added originally to have a clear root RP for the agent to handle. | |
| 09:43:27 | sean-k-mooney | and a singe ovs instance can have multipel datapath instances | |
| 09:43:27 | sean-k-mooney | and a singe ovs instance can have multipel datapath instances | |
| 09:44:04 | sean-k-mooney | yes we had form the start planned ot model packet rate on the agent rp | |
| 09:44:04 | sean-k-mooney | yes we had form the start planned ot model packet rate on the agent rp | |
| 09:44:14 | bauzas | sean-k-mooney: huh to what you say, you'd say that we could want to have multiple SLAs on different datapaths ? | |
| 09:44:14 | bauzas | sean-k-mooney: huh to what you say, you'd say that we could want to have multiple SLAs on different datapaths ? | |
| 09:44:18 | sean-k-mooney | among ohter things like port capasity | |
| 09:44:18 | sean-k-mooney | among ohter things like port capasity | |
| 09:44:43 | bauzas | either way, I don't want to bikeshed on this | |
| 09:44:43 | bauzas | either way, I don't want to bikeshed on this | |
| 09:44:49 | sean-k-mooney | bauzas: wehn you create ovs bridge you set a data path on them "system" or netdev | |
| 09:44:49 | sean-k-mooney | bauzas: wehn you create ovs bridge you set a data path on them "system" or netdev | |
| 09:44:58 | bauzas | this makes sens | |
| 09:44:58 | bauzas | this makes sens | |
| 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 | |