> -----Original Message----- > From: Ricardo Rocha [mailto:rocha.po...@gmail.com] > Sent: May-03-16 8:34 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit > > Hi. > > On Mon, May 2, 2016 at 7:11 PM, Cammann, Tom <tom.camm...@hpe.com> > 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- > versionin > > g > > - 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.
Created a blueprint for that: https://blueprints.launchpad.net/magnum/+spec/container-monitoring > > 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 <hongbin...@huawei.com> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <openstack-dev@lists.openstack.org> > > Date: Saturday, 30 April 2016 at 05:05 > > To: "OpenStack Development Mailing List (not for usage questions)" > > <openstack-dev@lists.openstack.org> > > 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- > operatio > > ns > > - 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- > versionin > > g > > - 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- > standar > > d-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 > > _______________________________________________________________________ > ___ > 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 __________________________________________________________________________ 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