132 lines
6.1 KiB
Plaintext
132 lines
6.1 KiB
Plaintext
{
|
|
"comments": [
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "a35f818c_86c4d5df",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 4
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 11975
|
|
},
|
|
"writtenOn": "2024-04-24T09:00:37Z",
|
|
"side": 1,
|
|
"message": "I\u0027m definitely not an Ironic expert but it looks good for me generally. One question: will this new feature be able to work together with Neutron or if this will be enabled, Ironic will not use Neutron at all?",
|
|
"revId": "6aeec08df09662a289b7ef8a59d79a3c00dd3d8d",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "465e94b2_e79c502f",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 4
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 11655
|
|
},
|
|
"writtenOn": "2024-04-24T13:38:53Z",
|
|
"side": 1,
|
|
"message": "With ironic\u0027s plugin model, each node\u0027s network_interface would govern the pattern of behavior. Today we have \"flat\" and \"neutron\" network_interfaces which use neutron. We would likely end up with an additional interface \"mercury\" in an MVP and those could be selected independently based upon the user. Users are also able to presently select \"noop\" which means \"do nothing with networking and Neutron\".\n\nI hope that answers your question, please let me know if you have any others.\n\nThanks!",
|
|
"parentUuid": "a35f818c_86c4d5df",
|
|
"revId": "6aeec08df09662a289b7ef8a59d79a3c00dd3d8d",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "d7f5aff1_9ad99d0e",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 4
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 11975
|
|
},
|
|
"writtenOn": "2024-04-25T08:09:47Z",
|
|
"side": 1,
|
|
"message": "yes, thx a lot",
|
|
"parentUuid": "465e94b2_e79c502f",
|
|
"revId": "6aeec08df09662a289b7ef8a59d79a3c00dd3d8d",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "e47ca181_a98b55dc",
|
|
"filename": "specs/approved/mercury.rst",
|
|
"patchSetId": 4
|
|
},
|
|
"lineNbr": 56,
|
|
"author": {
|
|
"id": 24828
|
|
},
|
|
"writtenOn": "2024-04-24T01:14:18Z",
|
|
"side": 1,
|
|
"message": "Hi Julia, it\u0027s an exciting idea!\nIt looks like we will have a new rpc service which is mainly responsible for the switch configuration, I wonder how it relates with the ngs?\nIf it\u0027s not function as an IPAM, do we have other mechanisms to land the network configuration like ip assignment, dhcp service, in case neutron is not available?\nAlso, in the openstack scenario, the \"network\" team may provide ml2 plugin into neutron service so they act as the sole entry to the network complexity from the ironic perspective. I wonder how the new service would cope in 😊",
|
|
"revId": "6aeec08df09662a289b7ef8a59d79a3c00dd3d8d",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "e214d350_ff6c2fec",
|
|
"filename": "specs/approved/mercury.rst",
|
|
"patchSetId": 4
|
|
},
|
|
"lineNbr": 56,
|
|
"author": {
|
|
"id": 11655
|
|
},
|
|
"writtenOn": "2024-04-24T13:38:53Z",
|
|
"side": 1,
|
|
"message": "Greetings Kaifeng!\n\nHope your doing well!\n\nAnyway, yes, in the current shape largely relates to being able to take NGS or some *other* ML2 plugin and being able to call it for the physical port operations.\n\nDuring the PTG we didn\u0027t get deep into IPAM issues, but a related discussion was basically that DHCP with dnsmasq is not really a viable path for CI moving forward, Ironic has the ability to directly do some configuration management of that based upon user inputs for the standalone use case. I think the case we vision into the future is more a virutal media based model than a network boot model. Combine with many standalone operators already have these challenges solved, or only need it solved for a provisioning network, largely means the project scope is simplified based on existing model. This might end up being something along the existing network_data field on a node being supersceeded down the road, but only time will tell.\n\nAs for a ML2 plugin *only* being plugged into Neutron, I don\u0027t think that would really change anything for what we\u0027re proposing, just the new resulting network_interface drivers wouldn\u0027t be able to be leveraged.\n\n-Julia",
|
|
"parentUuid": "e47ca181_a98b55dc",
|
|
"revId": "6aeec08df09662a289b7ef8a59d79a3c00dd3d8d",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "e85c4690_a33c87b2",
|
|
"filename": "specs/approved/mercury.rst",
|
|
"patchSetId": 4
|
|
},
|
|
"lineNbr": 349,
|
|
"author": {
|
|
"id": 11655
|
|
},
|
|
"writtenOn": "2024-05-04T00:00:55Z",
|
|
"side": 1,
|
|
"message": "As a practical note, I\u0027d swap these. I started seeing how I\u0027d wire in a genericized interface in, and realize it would just be best to figure out what I need to call *first* to prototype the mapping for the service.",
|
|
"revId": "6aeec08df09662a289b7ef8a59d79a3c00dd3d8d",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "2df37ddb_2b6d9343",
|
|
"filename": "specs/approved/mercury.rst",
|
|
"patchSetId": 4
|
|
},
|
|
"lineNbr": 352,
|
|
"author": {
|
|
"id": 11655
|
|
},
|
|
"writtenOn": "2024-05-04T00:00:55Z",
|
|
"side": 1,
|
|
"message": "It looks like we may have already done this as a result of refactoring/cleanup in the last few cycles. It *appears* we can just post a id number in and we should be golden regarding this.",
|
|
"range": {
|
|
"startLine": 351,
|
|
"startChar": 0,
|
|
"endLine": 352,
|
|
"endChar": 69
|
|
},
|
|
"revId": "6aeec08df09662a289b7ef8a59d79a3c00dd3d8d",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
}
|
|
]
|
|
} |