List view
- Due by March 7, 2021
- Due by February 22, 2021
We want to lower the cost to develop, build, release, and test our Tanzu integration to facilitate releasing quarterly in 2020 with minimal disruptions to developer focus and work on other projects. In this milestone, we focus on tasks that will help us achieve these goals by: - Automating building and testing the tile - Reorganizing our test strategy to run heavy-weight end-to-end tests in the tile repository, and reserve unit and integration tests for the component repos - Moving toward standard dev / test scripts in these projects to enable quick startup when rejoining this project to begin development
Due by January 15, 2021- Due by May 14, 2020
See design [here](https://github.com/cyberark/conjur/tree/master/design/oss_suite_release.md).
Due by April 7, 2020ConjurOps is currently running v4. In order to get early feedback on v5 changes, take advantage of new features and have a robust pipeline, ConjurOps needs to be updated to v5. The approach is defined into different phases in order to allow regular checkpoints on continuing work and making adjustments based on discoveries. ### Goals of the upgrade * Find bugs and issues sooner in the process * Reduce time to perform XA * Improve Conjur design * Expose deficiencies in documentation * Improve overall UX of Conjur * Improve automated tests * Define pattern for v4 -> v5 upgrade ### Final target > The approach to use has changed and needs to be detailed. The existing phases and issues need to be updated and changed to match the new approach to use. * v5 cluster that uses HA/failover + follower and 3rd party certs automatically (and regularly) deployed and upgraded using the latest built version * Automated validation of deployed v5 cluster * v5 cluster regularly used for secret and variable retrieval ### Phase 1 The purpose of phase 1 is to get an initial v5 cluster up and running and available for use. - [x] Parent of #724 - A ConjurOps v5 cluster is available and can be easily redeployed ### Phase 2 The purpose of phase 2 is to automate deployment and upgrade of a v5 cluster. - [x] Parent of #739 - V5 Cluster can be automatically created and destroyed - [x] Parent of #743 - v5 cluster is monitored for health - [x] Parent of #708 - V5 cluster can be automatically deployed and upgrade ### Phase 3 The purpose of phase 3 is to fully integrate all changes and automation into the CI/CD workflow for Conjur. - [ ] Parent of #709 - Automation is integrated into the build process to automatically deploy new versions ### Phase 4 The purpose of phase 4 is to get to a point where everything except for the data stored in Conjur can be moved from v4 to v5. - [ ] Parent of #675 - v4 policy can be automatically converted to v5 policy ### Phase 5 The purpose of phase 5 is to get to a point where all structure and data can be migrated from a v4 cluster into a v5 cluster and the process is smooth and reliable. - [ ] Parent of #676 - Full data can be exported from a v4 instance and imported into a v5 instance - [ ] Parent of #677 - Upgrade process from v4 to v5 is smooth, reliable and predictable ### Missing Features In addition to the upgrade itself from v4 to v5, some features of Conjur v4 are used that are not present in v5 and need to be added to allow us to use the upgraded cluster. Jenkins currently uses a pam_ldap config to provide UI login to Jenkins that is backed by Conjur (which acts as an LDAP server). Additionally, it uses SSH keys stored in Conjur to provide ssh and sudo access to Jenkins master and executor servers. At a minimum, SSH support is needed. At this time, there are workarounds that can be used, so that should be done until the necessary epic is prioritized and completed - [ ] Parent of #248 - Conjur supports SSH management
No due date