openstack
/
neutron-specs
Code Issues Proposed changes
neutron-specs/aee09a8a2d8420dce54c76692e8...

333 lines
14 KiB
Plaintext
Raw Blame History

{
"comments": [
{
"unresolved": false,
"key": {
"uuid": "58a3bbf1_f7e40f02",
"filename": "/PATCHSET_LEVEL",
"patchSetId": 4
},
"lineNbr": 0,
"author": {
"id": 15554
},
"writtenOn": "2023-01-05T12:55:42Z",
"side": 1,
"message": "The overall goal is perfectly reasonable to me. I left a few questions where I believe we could better adapt to ovn architecture (as much as I understand it).",
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "21fe3b24_f41a6ad7",
"filename": "/PATCHSET_LEVEL",
"patchSetId": 4
},
"lineNbr": 0,
"author": {
"id": 16688
},
"writtenOn": "2023-01-05T15:36:47Z",
"side": 1,
"message": "Updating the spec now...",
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "b2790b02_f12516a7",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 8,
"author": {
"id": 15554
},
"writtenOn": "2023-01-05T12:55:42Z",
"side": 1,
"message": "Probably forgot to update.",
"range": {
"startLine": 8,
"startChar": 0,
"endLine": 8,
"endChar": 55
},
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "48361728_0c80a947",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 8,
"author": {
"id": 16688
},
"writtenOn": "2023-01-05T15:36:47Z",
"side": 1,
"message": "Ups sorry!",
"parentUuid": "b2790b02_f12516a7",
"range": {
"startLine": 8,
"startChar": 0,
"endLine": 8,
"endChar": 55
},
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "f36a2275_bb039d2b",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 33,
"author": {
"id": 11975
},
"writtenOn": "2023-01-04T13:47:00Z",
"side": 1,
"message": "nitty nit: \"and\" I guess",
"range": {
"startLine": 33,
"startChar": 22,
"endLine": 33,
"endChar": 24
},
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "e2f50aa0_9881fff8",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 33,
"author": {
"id": 16688
},
"writtenOn": "2023-01-05T16:32:28Z",
"side": 1,
"message": "Done",
"parentUuid": "f36a2275_bb039d2b",
"range": {
"startLine": 33,
"startChar": 22,
"endLine": 33,
"endChar": 24
},
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "5f61d723_9eaeb605",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 40,
"author": {
"id": 8655
},
"writtenOn": "2023-01-04T20:41:11Z",
"side": 1,
"message": "As discussed by emails with Rodolfo, I\u0027d like to open a discussion about making a generic Neutron-OVN agent that provides an interface for various functionality - like for example what the proposed OVN monitor does for QoS and HWOL. It can also (in the next cycles) consume the metadata agent and also for example replace current agent API implementation with rpc methods.\n\nThis suggestion is to kick-off a discussion about this approach, I think having relevant data in memory for all services can be beneficial.",
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "e72302e7_ef4d89eb",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 40,
"author": {
"id": 6773
},
"writtenOn": "2023-01-05T11:59:48Z",
"side": 1,
"message": "Thanks for starting this discussion.\n\nI like the idea of a single OVN agent instead of multiple ones. As long as it\u0027s engineered in a way that is easy to extend (a well defined API) in a plugin-in style where functionalities can be enabled/disabled easily.\n\nA single agent does help deployers as new functionalities no longer need another service running. It also helps with monitoring such service.\n\nAnd the main thing for me, at least with OVN in mind, is scalability because we really struggle to scale OVSDB and having multiple agents almost always translate into more connections to the OVSDB databases for each service. A single agent could benefit from a single OVSDB connection which is shared across all functionalities.",
"parentUuid": "5f61d723_9eaeb605",
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "ecdf719c_ce5c5cf1",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 40,
"author": {
"id": 6773
},
"writtenOn": "2023-01-05T12:01:54Z",
"side": 1,
"message": "Another PRO point for us developers is that every time a new service is introduced we need to update then deployment tool to include it, create packages, containers etc...\n\nIn TripleO for example that means adding it to Tripleo Heat Templates, as well we Puppet repositories, etc...\n\nA single agent saves us a lot of that work too.",
"parentUuid": "e72302e7_ef4d89eb",
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "1f91cad9_2556596d",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 40,
"author": {
"id": 15554
},
"writtenOn": "2023-01-05T12:55:42Z",
"side": 1,
"message": "I think it\u0027s a good idea to start with a generic agent that can be used for later features also requiring an agent.\n\nI believe the following combinations make sense:\na) a general-purpose but ml2/ovn-specific agent that uses ovsdb to communicate\nb) a general-purpose but non-ml2/ovn-specific agent that uses the mq (rpc) to communicate\n\nMy understanding was that ovn architecture preferred communication via ovsdb over rpc partially because of scaling reasons. (Though I don\u0027t remember reading an in-practice comparison of its scaling properties compared to the previous rpc approach demonstrating that it actually scales differently.) However if we add an rpc-using agent to ovn, then ovn will have both communication methods\u0027 scaling bottlenecks. For this reason I\u0027m leaning into the direction of keeping all communication inside ovsdb. Then ovn would have the scaling bottlenecks of only one communication method.",
"parentUuid": "5f61d723_9eaeb605",
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "d19efee7_889d4036",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 40,
"author": {
"id": 8655
},
"writtenOn": "2023-01-05T15:22:05Z",
"side": 1,
"message": "I think it\u0027s a really good point about the rpc (mq) with the agent. I\u0027m not familiar in details about scaling issues with the mq. I know what I\u0027m gonna say is out of context of this spec, so probably this spec should not think about rpc at all and just provide the pluggable agent functionality + implementation of HWOL configuration.\n\nOT: imho the rpc may be good for things like agent API similarly to what ml2/ovs agents do - periodically calling and rpc method to update timestamps in the agent DB. Another thing where I think rpc could be good is metering - we\u0027ve talked a couple of times with operators about metering capabilities for OVN. Given that this is OpenStack specific rather than CMS (maybe OVN can provide stats too) but reporting stats back to server is something may happen in future too. Generally one-way periodic communication from agent towards server is something what I think could be good for rpc as it won\u0027t cause any side-effects. Just wanted to share my opinion on rpc with agents :)",
"parentUuid": "1f91cad9_2556596d",
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "c998edc3_5e0c5cde",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 40,
"author": {
"id": 16688
},
"writtenOn": "2023-01-05T15:36:47Z",
"side": 1,
"message": "For now, I think we should stick to the ovsdb communication agent. We can implement the RPC part (even a new agent) in future releases/RFEs.\n\nSo, if I\u0027m reading you well, the idea is:\n1) To create this OVN agent (generic) with an extensible interface, same as other agents. I was thinking about using the ``agent.agent_extensions_manager.AgentExtensionsManager`` class to implement it, same as in other ML2 agents.\n2) Implement the QoS HWOL feature.\n3) In future releases, move the metadata functionality to this \"OVN agent\".\n\nI\u0027ll push a new PS to portray these ideas.",
"parentUuid": "1f91cad9_2556596d",
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "a4a4cc08_ffc155f9",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 200,
"author": {
"id": 11975
},
"writtenOn": "2023-01-04T13:47:00Z",
"side": 1,
"message": "nitty nit: remote",
"range": {
"startLine": 200,
"startChar": 63,
"endLine": 200,
"endChar": 69
},
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "0ba902ae_62a5f337",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 200,
"author": {
"id": 16688
},
"writtenOn": "2023-01-05T16:32:28Z",
"side": 1,
"message": "Done",
"parentUuid": "a4a4cc08_ffc155f9",
"range": {
"startLine": 200,
"startChar": 63,
"endLine": 200,
"endChar": 69
},
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "cd3de78f_d3b747f0",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 205,
"author": {
"id": 15554
},
"writtenOn": "2023-01-05T12:55:42Z",
"side": 1,
"message": "This is in conflict with my understanding of ovn architecture. I believed that:\n\n* NB DB has a global logical view, which changes (relatively) slowly and it has a very limited set of users (practically the cms and ovn-northd) therefore it\u0027s easy to scale\n* SB DB has an in-detail physical view, which can change quickly, therefore it may be hard to scale, but at least 1) the scaling problems are localized to the SB DB, and 2) theoretically (but AFAIU not practically today) the SB DB could be sharded, that is one SB DB instance could handle only a subset of all chassis (plural).\n\nIf this is correct (is it? I\u0027m not sure) then the agent proposed here should not directly read from the NB DB - just like ovn-controller does/should not.",
"range": {
"startLine": 205,
"startChar": 0,
"endLine": 205,
"endChar": 57
},
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "a1b265d0_d00b885b",
"filename": "specs/2023.1/ovn-monitor.rst",
"patchSetId": 4
},
"lineNbr": 205,
"author": {
"id": 16688
},
"writtenOn": "2023-01-05T15:36:47Z",
"side": 1,
"message": "You are right on this. The QoS information should be translated to the corresponding logical flows with their own matches and actions. But in this case this is not happening due to limitations in the driver. In order to read the min-bw values (that are not applied on the VF), we need to retrieve the Logical_Switch_Port register",
"parentUuid": "cd3de78f_d3b747f0",
"range": {
"startLine": 205,
"startChar": 0,
"endLine": 205,
"endChar": 57
},
"revId": "aee09a8a2d8420dce54c76692e8e17d7568bbe40",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
}
]
}
View Git Blame Copy Permalink