Dogface2k opened a new issue, #13761:
URL: https://github.com/apache/cloudstack/issues/13761

   <!--
   Verify first that your issue/request is not already reported on GitHub.
   Also test if the latest release and main branch are affected too.
   Always add information AFTER of these HTML comments, but no need to delete 
the comments.
   -->
   
   ##### ISSUE TYPE
    * Bug Report
   
   ##### COMPONENT NAME
   ~~~
   Kubernetes Service (CKS), VPC, Network ACL
   ~~~
   
   ##### CLOUDSTACK VERSION
   ~~~
   4.22.1.0
   main (reproduced by regression test at 
4f117071c9397b1e4714c8fb61c384883c872842)
   ~~~
   
   ##### CONFIGURATION
   Advanced zone with NSX-backed networking, VPC with an ACL-capable tier 
offering, and a CKS cluster deployed within a project.
   
   The live reproduction used the NSX VPC offering `VPC offering with NSX - NAT 
Mode` and the tier offering `DefaultNSXVPCNetworkOfferingforKubernetesService`. 
The tier offering includes the NetworkACL service with provider Nsx.
   
   ##### OS / ENVIRONMENT
   Management server on Debian 13, VMware vSphere hypervisor, NSX 4.2.4, NFS 
primary/secondary storage, and CKS Kubernetes v1.34.7.
   
   ##### SUMMARY
   CKS create, etcd setup, validation, and delete paths throw an unboxing 
`NullPointerException` when a VPC tier does not yet have a network ACL attached.
   
   A missing tier ACL is a supported CloudStack state, not an invalid database 
artifact:
   
   - `createNetwork` declares `aclid` as optional.
   - CloudStack deliberately stopped assigning default-deny unconditionally in 
CLOUDSTACK-2809 (`b5148af0c6dfc583bcd1a52a7510df80e9eaa163`).
   - `NetworkACLServiceImpl.createAclListIfNeeded` explicitly preserves the 
legacy behavior of creating and attaching a custom ACL when a rule is created 
with `networkid` but no `aclid`.
   - `NetworkACLItemDaoImpl.listByACL(null)` intentionally returns an empty 
list.
   
   CKS already supplies `networkid` when provisioning a VPC-tier ACL rule, so 
it should reach that existing auto-create path. Instead, four comparisons 
auto-unbox the nullable `Long` returned by `Network.getNetworkACLId()` against 
primitive `long` constants:
   
   - `KubernetesClusterManagerImpl.validateVpcTier`
   - `KubernetesClusterResourceModifierActionWorker.createVpcTierAclRules`
   - `KubernetesClusterResourceModifierActionWorker.removeVpcTierAclRules`
   - `KubernetesClusterStartWorker.setupKubernetesEtcdNetworkRules`
   
   This is present in 4.22.1.0, current `4.22`, and current `main`.
   
   On an unmodified current-main checkout, focused regression tests covering 
these four nullable-ACL paths produced four errors with the same 
`Long.longValue()` NPE while all 56 existing/control tests passed.
   
   ##### STEPS TO REPRODUCE
   ~~~
   1. Create a VPC with an offering compatible with the chosen ACL-capable tier 
offering.
   2. Create the tier through the API without aclid:
   
      cmk create network \
        name=cks-null-acl-tier \
        displaytext=cks-null-acl-tier \
        networkofferingid=<acl-capable-vpc-tier-offering> \
        vpcid=<vpc> \
        zoneid=<zone> \
        gateway=10.35.15.1 \
        netmask=255.255.255.0
   
   3. Confirm that listNetworks reports no aclid for the tier.
   4. Create a CKS cluster on that tier.
   5. After the create failure, stop and start the cluster, then attempt to 
delete it.
   ~~~
   
   No database changes were used to create the failing state. The only omitted 
input was the optional `aclid`.
   
   In the live 4.22.1.0 reproduction, all cluster VMs were provisioned before 
create failed in `createVpcTierAclRules`. The cluster remained in `Starting` 
with an empty endpoint. Stop succeeded, start then failed because the endpoint 
was never recorded, and delete failed in `removeVpcTierAclRules`.
   
   Attaching an ACL with `replaceNetworkACLList` allowed cleanup to complete.
   
   ##### EXPECTED RESULTS
   ~~~
   - A CKS cluster can use an ACL-capable VPC tier whose ACL has not yet been 
attached.
   - CKS reaches the existing NetworkACLService behavior that creates and 
attaches a custom ACL when the first rule is added.
   - Validation does not reject or NPE on a null ACL ID.
   - Deleting a cluster from a tier that still has no ACL treats ACL cleanup as 
a no-op.
   ~~~
   
   ##### ACTUAL RESULTS
   ~~~
   Create:
   
   java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()"
   because the return value of "com.cloud.network.Network.getNetworkACLId()" is 
null
       at 
com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterResourceModifierActionWorker.createVpcTierAclRules(KubernetesClusterResourceModifierActionWorker.java:720)
       at 
com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterResourceModifierActionWorker.setupKubernetesClusterVpcTierRules(KubernetesClusterResourceModifierActionWorker.java:774)
       at 
com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterStartWorker.setupKubernetesClusterNetworkRules(KubernetesClusterStartWorker.java:624)
       at 
com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterStartWorker.startKubernetesClusterOnCreate(KubernetesClusterStartWorker.java:821)
       at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.startKubernetesCluster(KubernetesClusterManagerImpl.java:1865)
   
   Delete:
   
   java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()"
   because the return value of "com.cloud.network.Network.getNetworkACLId()" is 
null
       at 
com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterResourceModifierActionWorker.removeVpcTierAclRules(KubernetesClusterResourceModifierActionWorker.java:749)
       at 
com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterDestroyWorker.deleteKubernetesClusterVpcTierRules(KubernetesClusterDestroyWorker.java:197)
       at 
com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterDestroyWorker.deleteKubernetesClusterNetworkRules(KubernetesClusterDestroyWorker.java:215)
       at 
com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterDestroyWorker.destroy(KubernetesClusterDestroyWorker.java:326)
       at 
com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.destroyKubernetesCluster(KubernetesClusterManagerImpl.java:2439)
   ~~~
   


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