[
https://issues.apache.org/jira/browse/CLOUDSTACK-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13606125#comment-13606125
]
Pranav Saxena commented on CLOUDSTACK-1676:
-------------------------------------------
So after doing an analysis of this issue , I happened to observe the following
-
1) When you select defaultSharedNetworkOffering , the securitygroupsenenabled
parameter in the createZone response is still set to TRUE which should not be
the case.
2) If you list the network offerings (listNetworkOfferings) , there in the
defaultSharedNetworkOffering , the security group service is not there in the
response which is right .
UI makes a check on the type of network offering and disabled /enables security
group which is working absolutely fine . The need is to check the listNetworks
API and correctly handle the response of security groups enabled parameter
depending upon the service offering.
The network offering we choose is passed only in the createnetwork API call for
which security groups is NOT the service provider . The point to be seen here
is if the networkOffering properties (called at the network level) is
overriding the parameters set at the zone level or not.
Perhaps some backend developer needs to check this behavior once .
Thanks !
> basic zone security groups enabled with 'DefaultSharedNetworkOffering'
> ----------------------------------------------------------------------
>
> Key: CLOUDSTACK-1676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1676
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller
> Affects Versions: 4.1.0
> Environment: KVM Hosts
> Reporter: Marcus Sorensen
> Assignee: Pranav Saxena
> Fix For: 4.2.0
>
>
> I deployed a basic zone with a management bridge and a guest bridge,
> selecting 'DefaultSharedNetworkOffering' as the network offering.
> I launched an instance
> I could not ssh into instance, but instance could ping gateway, google, etc.
> I ran 'ebtables -t nat -L' and saw that there were rules for this instance.
> I ran 'ebtables -t nat -F i-2-3-VM-in', and could now SSH into server.
> It was as though firewall/security groups were enabled, but without any way
> to edit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
