GutoVeronezi commented on PR #6442:
URL: https://github.com/apache/cloudstack/pull/6442#issuecomment-1427828264

   > Just FYI - there is a UI-only workaround that may even be implemented (so 
just a UI feature). When creating a network in the UI, ask in the same form or 
as a next step the IP that the user wants, and acquire that public IP. The 
first IP acquired in an isolated network for ex. becomes the SNAT IP :) I've 
been using this approach for years ;)
   
   It is good to have a workaround right away; however, I think we still should 
provide a clear and solid method for operators to define the source NAT of the 
network/VPC, as the workaround is only possible for not persistent networks and 
if we create VPCs without starting it.
   
   I think that a better solution here would be to behave as the "add VM to 
network process": if no IP is provided, one is selected at random; if the IP is 
provided, validations are executed, and if everything is fine, the IP is used. 
We could receive the parameter via the `createVPC`/`createNetwork` APIs and 
acquire the IP for the VPC/network (if it is available) directly in the code; 
in the UI, we could implement the IP selection for the `Create VPC` and `Create 
Network` forms.
   
   ---
   
   @DaanHoogland, is there any reason to consider `selecting the source NAT IP` 
as a capacity of the `source NAT` service? 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.


-- 
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]

Reply via email to