GutoVeronezi commented on PR #6442: URL: https://github.com/apache/cloudstack/pull/6442#issuecomment-1446349235
> @GutoVeronezi , > > > @DaanHoogland, is there any reason to consider `selecting the source NAT IP` as a capacity of the `source NAT` service? > > In short because the offering having such a attribute when source NAT is not enabled makes no sense. > > > In my opinion, it is not related to the service supporting the functionality itself, but to the offering supporting the service; if the offering supports the `source NAT` service, then the source NAT IP can be informed, otherwise it cannot. For instance, with the current design, one could define a VPC offering without the `select the source NAT IP` capability, create the VPC without starting it, and still select the source NAT IP through the workaround @rohityadavcloud mentioned. > > Yes, one could. So do you want to prevent this, and how? delecting IPs must happen and the first one will always be the source NAT one, whether it is chosen or randomly assigned. I a, still trying to define the end functionality, but I think this is a good intermediate. Does that make sense? @DaanHoogland, my point was that we would not need an attribute like `selecting the source NAT IP` in the offering; we could just validate if the offering supports the `SourceNat` service; if the offering supports the `SourceNat` service, then the source NAT IP could be informed while creating the network/VPC, otherwise, it could not. In my opinion, it is a simplier design to implement and the operators would not need to create new offerings to use the feature. What do you think? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
