Open Stack

> -----Original Message-----
> From: Ricardo Rocha [mailto:rocha.porto at 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.cammann at 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.lu at huawei.com>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Saturday, 30 April 2016 at 05:05
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at 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-request at 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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev