• Comply to OOM/Helm for Config Management - Projects will require to populate the helm configs, adapt their helm configs for Beijign
  • Each component shall support HA and geo-redundancy through K8S - Project teams will own the configurations in OOM of HA / geo-redundancy
  • Deployment for new containers
  • Following OOM Logging guidelines for new projects / adjust logging for existing projects
  • OOM CI triggered by component teams commits - what is the impact to component teams here? hook OOM to the job builder of each component teams
  • Backup and Restore: 
  • Upgradability / Rollbacks: comply to a "rest" API for upgrade, downgrade of the platform, how do we support rolling upgrade? should we support 2 versions of a component at the same time?
  • Health Monitoring: request component teams to provide REST level monitoring, and probably deeper health check so that OOM can provide a consistent view across, enabling DEBUG, 
  • Recoverability: components should be mostly stateless at target. Need to define what could be done for Beijign
  • Graceful shutdown: support k8s graceful shutdown feature
  • Storage: comply to a common persistent volume strategy, 

OOM shall document guidelines for each of those in order to support project teams

  • No labels

2 Comments

  1. Ashutosh Mishra

    Please see OOM for Production-Grade Deployments for more details.

  2. David Sauvageau

    Roger Maitland can you please take a look? thanks.