weizhouapache commented on issue #3780: Enhancement: Allow creating atmost 1 physical network with null tag URL: https://github.com/apache/cloudstack/pull/3780#issuecomment-572758112 > clear to me @weizhouapache, however a user would still want to be able to have all networks allowing all traffic in some installations, would you agree? So a global setting to enforce this would be nice. @DaanHoogland in default installation (mostly used), there is only 1 physical network for guest networks (isolated/shared) > Thanks for the explanation @weizhouapache - this should be in the description of the PR in the first place :) > > I've repeated commands that @ravening used to create 2 physical networks and attempt (and succeeded) to create a Guest traffic type on a specific Physical network (in clean 4.5 and clean 4.13) > > On the other hand, with this clean (zero-tags-anywhere) setup (clean 4.5 or clean 4.13) - I can see the following "warning" in the API (same one in the GUI) > > > (localcloud) SBCM5> > create network networkofferingid=471039c4-d0f9-4105-a5d8-2e58551bf445 zoneid=450c5085-8832-46af-a60f-109a25af293a name=yyy displaytext==yyy > > ** Error: (HTTP 431, error code 4350) More than one physical networks exist in zone id=1 and no tags are specified in order to make a choice** > > So all checks are in place to ensure that an operator configures things "correctly". > > Perhaps it's just me, but I don't see a value in the behaviour that this PR brings - it allows you to have at most 1 untagged physical network/offering combination - but why (what does it solve)? All one needs to do is to tag both the physical network and the offering and be 100% clear on what is going to be created where (update tags in DB). > > As @DaanHoogland pointed out, the operator might have a valid case where he wants both (more than one) physical networks untagged. > So, can we please have a global configuration setting - that would make more sense (defaulting to the old behaviour)? @DaanHoogland @andrijapanicsb in current cloudstack implementation, if there are multiple (>=2) physical networks for guest networks (isolated/shared), all MUST be tagged (network offerings as well). Othewise cloudstack is not able to make decision which physical network will be used. That's same as the error message you got in your testing. I think it makes sense. As a cloudstack user, when I create a guest network, I am very clear which physical network will be used. I do not think It is a good idea to let cloudstack choose a physical network from a list. Maybe we are one of few cloudstack user who use multiple physical networks. On each hypervisor, there is a default interface for guest networks (which connect internet via core switches). meanwhile, there is another interface to connect to other dedicated racks in our data center which make us to build hybrid cloud very easily. In default cloudstack setup , there is 1 physical network and some network offerings. all are not tagged. when we add new physical networks, we have to tag all physical networks and offerings, including the existing. as I said in previous comment, with this patch, we only need to tag the new things. It make our changes a bit easier.
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
