Hi team, For reference, below is a summary of the discussions/decisions in Austin design summit. Please feel free to point out if anything is incorrect or incomplete. Thanks.
1. Bay driver: https://etherpad.openstack.org/p/newton-magnum-bay-driver - Refactor existing code into bay drivers - Each bay driver will be versioned - Individual bay driver can have API extension and magnum CLI could load the extensions dynamically - Work incrementally and support same API before and after the driver change 2. Bay lifecycle operations: https://etherpad.openstack.org/p/newton-magnum-bays-lifecycle-operations - Support the following operations: reset the bay, rebuild the bay, rotate TLS certificates in the bay, adjust storage of the bay, scale the bay. 3. Scalability: https://etherpad.openstack.org/p/newton-magnum-scalability - Implement Magnum plugin for Rally - Implement the spec to address the scalability of deploying multiple bays concurrently: https://review.openstack.org/#/c/275003/ 4. Container storage: https://etherpad.openstack.org/p/newton-magnum-container-storage - Allow choice of storage driver - Allow choice of data volume driver - Work with Kuryr/Fuxi team to have data volume driver available in COEs upstream 5. Container network: https://etherpad.openstack.org/p/newton-magnum-container-network - Discuss how to scope/pass/store OpenStack credential in bays (needed by Kuryr to communicate with Neutron). - Several options were explored. No perfect solution was identified. 6. Ironic Integration: https://etherpad.openstack.org/p/newton-magnum-ironic-integration - Start the implementation immediately - Prefer quick work-around for identified issues (cinder volume attachment, variation of number of ports, etc.) 7. Magnum adoption challenges: https://etherpad.openstack.org/p/newton-magnum-adoption-challenges - The challenges is listed in the etherpad above 8. Unified abstraction for COEs: https://etherpad.openstack.org/p/newton-magnum-unified-abstraction - Create a new project for this efforts - Alter Magnum mission statement to clarify its goal (Magnum is not a container service, it is sort of a COE management service) 9. Magnum Heat template version: https://etherpad.openstack.org/p/newton-magnum-heat-template-versioning - In each bay driver, version the template and template definition. - Bump template version for minor changes, and bump bay driver version for major changes. 10. Monitoring: https://etherpad.openstack.org/p/newton-magnum-monitoring - Add support for sending notifications to Ceilometer - Revisit bay monitoring and self-healing later - Container monitoring should not be done by Magnum, but it can be done by cAdvisor, Heapster, etc. 11. Others: https://etherpad.openstack.org/p/newton-magnum-meetup - Clear Container support: Clear Container needs to integrate with COEs first. After the integration is done, Magnum team will revisit bringing the Clear Container COE to Magnum. - Enhance mesos bay to DCOS bay: Need to do it step-by-step: First, create a new DCOS bay type. Then, deprecate and delete the mesos bay type. - Start enforcing API deprecation policy: https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html - Freeze API v1 after some patches are merged. - Multi-tenancy within a bay: not the priority in Newton cycle - Manually manage bay nodes (instead of being managed by Heat ResourceGroup): It can address the use case of heterogeneity of bay nodes (i.e. different availability zones, flavors), but need to elaborate the details further.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
