Skip to main content

Log - Sprint 1 🛫

· 3 min read

Key Accomplishments​

  • In a collaborative effort between the customer and our Client Engineering team, we achieved a successful documentation and deployment of OpenLDAP into the customer's environment.
  • Through collaboration between the customer and our Client Engineering team, we successfully deployed the FileNet Operator into the customer's AWS EKS environment.

Challenges​

  • PreStaging: While collaborating, we took the opportunity to work deeply with the customer in pre-staging their environment and helping to educate them in product requirements for both software and environment. See #2

  • Reference Environment: During our collaboration with the customer, we staged an internal cluster to mirror their environment as much as possible in order to faciliate a smooth transfer of knowledge between us. See #3

  • Different Environment: During our collaboration, we worked together with the customer to deploy FileNet FNCM in a shared AWS EKS environment. However, we acknowledged that each environment is unique and may require specific considerations. For instance, the customer was already utilizing Kynverno as a cluster policy manager.

  • Private Registry: To ensure smooth integration, we worked with the customer to identify all the necessary images for FileNet, including Postgres and OpenLDAP. This information was crucial for them to pre-stage their private repository since external traffic was not permitted in their cluster. See #6

  • Cluster Privileges: A collaborative approach required us to determine the cluster privileges available to the customer within their environment. By understanding their permissions, we could effectively align our efforts and ensure seamless integration.

  • Resource Quota : As part of our combined efforts, we recognized that the cluster was created through an automated process, which automatically assigned namespace resource quotas. This allowed us to optimize resource allocation and ensure efficient usage within the shared environment. See #8

  • Operator Image: During our collaboration, we encountered a blocker in the customer's environment where the default image did not set resource quotas for temporary job containers. Working with the internal dev team we were able to get a hotfix in place for the operator image. See #9 and Development Collaboration Slack Thread also referenced See #8

Lessons Learned​

  • Empowering Education: A key aspect of our collaborative approach was to provide the customer with valuable resources to empower themselves. We shared links that enabled them to proactively learn about Kubernetes, AWS, and even utilize an AWS Sandbox for hands-on practice. This proactive learning approach set a strong foundation and allowed us to make significant progress upon our onsite engagement.

  • Comprehensive Cluster Privilege Guidance: While working together, we recognized that certain privileges were necessary for a smooth installation of the FileNet operator. To ensure a seamless experience for future customers, we took the initiative to identify and compile a comprehensive list of required cluster privileges. By sharing this list, we aimed to minimize any potential roadblocks and foster a more efficient onsite collaboration.

Action Items​

  • ReadOnlyRootFileSystem - FCN 5.5.10 has readOnlyRootFilesystem implemented as part of security improvements applied to the container image. This causes problems as the customer uses Dynatrace in their environment and these folders cannot be copied thus causing the setup jobs to fail when deploying the FileNet pods. For now we are asking the customer to disable Dynatrace. See #8
  • RFE to be opened - CSFN-I-167

Up Next​

  • Successfully deploying the CR to the FileNet operator See #8

Metrics​

Notes​

Tracking​