Hi. On Mon, May 2, 2016 at 7:11 PM, Cammann, Tom <[email protected]> wrote: > Thanks for the write up Hongbin and thanks to all those who contributed to > the design summit. A few comments on the summaries below. > > 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.) > > We need to implement a bay template that can use a flat networking model as > this is the only networking model Ironic currently supports. Multi-tenant > networking is imminent. This should be done before work on an Ironic template > starts. > > 7. Magnum adoption challenges: > https://etherpad.openstack.org/p/newton-magnum-adoption-challenges > - The challenges is listed in the etherpad above > > Ideally we need to turn this list into a set of actions which we can > implement over the cycle, i.e. create a BP to remove requirement for LBaaS.
There's one for floating IPs already: https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips > > 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. > > We decided only bay driver versioning was required. The template and template > driver does not need versioning due to the fact we can get heat to pass back > the template which it used to create the bay. This was also my understanding. We won't use heat template versioning, just the bays. > 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. > > We split this topic into 3 parts – bay telemetry, bay monitoring, container > monitoring. > Bay telemetry is done around actions such as bay/baymodel CRUD operations. > This is implemented using using ceilometer notifications. > Bay monitoring is around monitoring health of individual nodes in the bay > cluster and we decided to postpone work as more investigation is required on > what this should look like and what users actually need. > Container monitoring focuses on what containers are running in the bay and > general usage of the bay COE. We decided this will be done completed by > Magnum by adding access to cAdvisor/heapster through baking access to > cAdvisor by default. I think we're missing a blueprint for this one too. Ricardo > > - 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. > > The idea revolves around creating a heat stack for each node in the bay. This > idea shows a lot of promise but needs more investigation and isn’t a current > priority. > > Tom > > > From: Hongbin Lu <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]> > Date: Saturday, 30 April 2016 at 05:05 > To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]> > Subject: [openstack-dev] [magnum] Notes for Magnum design summit > > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
