Re: [openstack-dev] [magnum] Notes for Magnum design summit
Hi Hongbin, Thank you for your guidance. I’ll take a look at the related existing blueprints and patches to see whether there are any duplicated jobs first. Regards, Gary From: Hongbin Lu [mailto:hongbin...@huawei.com] Sent: Monday, June 13, 2016 10:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit Gary, It is hard to tell if your change fits into Magnum upstream or not, unless there are further details. I encourage you to upload your changes to gerrit, so that we can review and discuss it inline. Also, keep in mind that the change might be rejected if it doesn’t fit into upstream objectives or it is duplicated to other existing work, but I hope it won’t discourage your contribution. If your change is related to Ironic, we might request you to coordinate your work with Spyros and/or others who is working on Ironic integration. Best regards, Hongbin From: Spyros Trigazis [mailto:strig...@gmail.com] Sent: June-13-16 3:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit Hi Gary. On 13 June 2016 at 09:06, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) mailto:li-gong.d...@hpe.com>> wrote: Hi Tom/All, >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. We have already implemented a bay template that uses a flat networking model and other python code(making magnum to find the correct heat template) which is used in our own project. What do you think of this feature? If you think it is necessary for Magnum, I can contribute this codes to Magnum upstream. This feature is useful to magnum and there is a blueprint for that: https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips You can add some notes on the whiteboard about your proposed change. As for the ironic integration, we should modify the existing templates, there is work in progress on that: https://review.openstack.org/#/c/320968/ btw, you added new yaml files or you modified the existing ones kubemaster, minion and cluster? Cheers, Spyros Regards, Gary Duan -Original Message- From: Cammann, Tom Sent: Tuesday, May 03, 2016 1:12 AM To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit 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. 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. 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 nee
Re: [openstack-dev] [magnum] Notes for Magnum design summit
Hi Sypros, Thank you for pointing out the blueprint and the patch. What we have done is modifying the existing kubecluster-ironic, kubemaster –ironic and kubeminion-ironic yaml files. I take a look at the blueprint and the patch you pointed out. Regards, Gary From: Spyros Trigazis [mailto:strig...@gmail.com] Sent: Monday, June 13, 2016 3:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit Hi Gary. On 13 June 2016 at 09:06, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) mailto:li-gong.d...@hpe.com>> wrote: Hi Tom/All, >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. We have already implemented a bay template that uses a flat networking model and other python code(making magnum to find the correct heat template) which is used in our own project. What do you think of this feature? If you think it is necessary for Magnum, I can contribute this codes to Magnum upstream. This feature is useful to magnum and there is a blueprint for that: https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips You can add some notes on the whiteboard about your proposed change. As for the ironic integration, we should modify the existing templates, there is work in progress on that: https://review.openstack.org/#/c/320968/ btw, you added new yaml files or you modified the existing ones kubemaster, minion and cluster? Cheers, Spyros Regards, Gary Duan -Original Message- From: Cammann, Tom Sent: Tuesday, May 03, 2016 1:12 AM To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit 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. 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. 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. - 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 mailto:hongbin...@huawei
Re: [openstack-dev] [magnum] Notes for Magnum design summit
Gary, It is hard to tell if your change fits into Magnum upstream or not, unless there are further details. I encourage you to upload your changes to gerrit, so that we can review and discuss it inline. Also, keep in mind that the change might be rejected if it doesn’t fit into upstream objectives or it is duplicated to other existing work, but I hope it won’t discourage your contribution. If your change is related to Ironic, we might request you to coordinate your work with Spyros and/or others who is working on Ironic integration. Best regards, Hongbin From: Spyros Trigazis [mailto:strig...@gmail.com] Sent: June-13-16 3:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit Hi Gary. On 13 June 2016 at 09:06, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) mailto:li-gong.d...@hpe.com>> wrote: Hi Tom/All, >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. We have already implemented a bay template that uses a flat networking model and other python code(making magnum to find the correct heat template) which is used in our own project. What do you think of this feature? If you think it is necessary for Magnum, I can contribute this codes to Magnum upstream. This feature is useful to magnum and there is a blueprint for that: https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips You can add some notes on the whiteboard about your proposed change. As for the ironic integration, we should modify the existing templates, there is work in progress on that: https://review.openstack.org/#/c/320968/ btw, you added new yaml files or you modified the existing ones kubemaster, minion and cluster? Cheers, Spyros Regards, Gary Duan -Original Message- From: Cammann, Tom Sent: Tuesday, May 03, 2016 1:12 AM To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit 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. 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. 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. - 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
Re: [openstack-dev] [magnum] Notes for Magnum design summit
Hi Gary. On 13 June 2016 at 09:06, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) < li-gong.d...@hpe.com> wrote: > Hi Tom/All, > > >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. > > We have already implemented a bay template that uses a flat networking > model and other python code(making magnum to find the correct heat > template) which is used in our own project. > What do you think of this feature? If you think it is necessary for > Magnum, I can contribute this codes to Magnum upstream. > This feature is useful to magnum and there is a blueprint for that: https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips You can add some notes on the whiteboard about your proposed change. As for the ironic integration, we should modify the existing templates, there is work in progress on that: https://review.openstack.org/#/c/320968/ btw, you added new yaml files or you modified the existing ones kubemaster, minion and cluster? Cheers, Spyros > > Regards, > Gary Duan > > > -Original Message- > From: Cammann, Tom > Sent: Tuesday, May 03, 2016 1:12 AM > To: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit > > 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. > > 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. > > 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. > > - 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 > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org&
Re: [openstack-dev] [magnum] Notes for Magnum design summit
Hi Tom/All, >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. We have already implemented a bay template that uses a flat networking model and other python code(making magnum to find the correct heat template) which is used in our own project. What do you think of this feature? If you think it is necessary for Magnum, I can contribute this codes to Magnum upstream. Regards, Gary Duan -Original Message- From: Cammann, Tom Sent: Tuesday, May 03, 2016 1:12 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit 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. 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. 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. - 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 Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Saturday, 30 April 2016 at 05:05 To: "OpenStack Development Mailing List (not for usage questions)" 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 t
Re: [openstack-dev] [magnum] Notes for Magnum design summit
> -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 > 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 > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" > > Date: Saturday, 30 April 2016 at 05:05 > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > 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
Re: [openstack-dev] [magnum] Notes for Magnum design summit
> -Original Message- > From: Cammann, Tom [mailto:tom.camm...@hpe.com] > Sent: May-02-16 1:12 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit > > 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. I created a BP for that: https://blueprints.launchpad.net/magnum/+spec/decouple-lbaas > > 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. ACK. Thanks for pointing it out. > > 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. ACK. Thanks for the clarification. > > - 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. Yes, the idea needs a thoughtful discussion. I will send another ML to discuss it. I agree this doesn't have to be a priority in Newton cycle, but I knew there are at least two requested features that will benefit from this idea: 1. The ability to specify different availability zones for bay nodes: https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones 2. The ability to specify different flavors for bay nodes: http://lists.openstack.org/pipermail/openstack-dev/2016-April/092838.html > > Tom > > > From: Hongbin Lu > Reply-To: "OpenStack Development Mailing List (not for usage > questions)" > Date: Saturday, 30 April 2016 at 05:05 > To: "OpenStack Development Mailing List (not for usage questions)" > > 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
Re: [openstack-dev] [magnum] Notes for Magnum design summit
-Original Message- From: Ricardo Rocha [mailto:rocha.po...@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 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 > Reply-To: "OpenStack Development Mailing List (not for usage > questions)" > Date: Saturday, 30 April 2016 at 05:05 > To: "OpenStack Development Mailing List (not for usage questions)" > > 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
Re: [openstack-dev] [magnum] Notes for Magnum design summit
Hi. On Mon, May 2, 2016 at 7:11 PM, Cammann, Tom 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 > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Saturday, 30 April 2016 at 05:05 > To: "OpenStack Development Mailing List (not for usage questions)" > > 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/F
Re: [openstack-dev] [magnum] Notes for Magnum design summit
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. 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. 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. - 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 Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Saturday, 30 April 2016 at 05:05 To: "OpenStack Development Mailing List (not for usage questions)" 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
[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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
