Open Stack

-----Original Message-----
From: Ricardo Rocha [mailto:rocha.porto at gmail.com] 
Sent: Tuesday, May 03, 2016 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.

I think the work on bay templates for multi-tenant networking can start now if we cherry pick this patch from Ironic:
https://review.openstack.org/#/c/256367/
and this patch for Ironic python client:
https://review.openstack.org/#/c/206144/
These should have all the dependency patches for supporting Ironic/Neutron-ML2 integration. (We'd still need to figure out e.g. how to specify which of N nics to use, and how to specify/detect LAG groups.) The Ironic support for Cinder volumes doesn’t seem as far along, but in the interim we can probably use volume drivers such as rexray (don't know if this works for kube).

>
> 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.

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