OpenStack Deliverables Map -- Feedback Request
Hi everyone, One more follow up note from me today. In the joint leadership meeting we presented a map of OpenStack deliverables, which includes a new structure to categorize OpenStack projects. The goal is to better communicate “what is OpenStack?” by bucketing the projects according to functionality and simplifying the appearance of the project ecosystem. The map also hides many of the supporting projects, like libraries, to focus on the user-centric deliverables view. Here’s a link to the presentation the working group put together with the map: https://docs.google.com/presentation/d/1qQ1oCjhEE3bjtjkPydGhyeR6vFyuyFeOhbwc... <https://docs.google.com/presentation/d/1qQ1oCjhEE3bjtjkPydGhyeR6vFyuyFeOhbwc-WueddI/edit#slide=id.g253b34e9c2_0_24> We’re looking for feedback on the map on slide #3 and the buckets listed on slide #5 (which would equate to git repo directories). If you are unable to view the google presentation, please let me know, and I’ll email you the PDF. Next steps: 1. Please add any feedback to this etherpad by September 19th — https://etherpad.openstack.org/p/map-feedback <https://etherpad.openstack.org/p/map-feedback> 2. Thierry and I are going to review/consolidate the feedback and work with the Foundation design team to do another rev of the diagram. 3. Once we have the next version ready, we’ll share it back and likely set up a meeting to refine/debate any final points. The goal is to present the new map by Sydney, but we still need to work through the timeline for updating directory names / Github mirrors and communicating that to all appropriate stakeholders. Thanks, Lauren
Hi everyone, To follow up on this process, Thierry and I updated the OpenStack projects map based on feedback provided at the joint leadership meeting and subsequently in the etherpad. Thank you to everyone who took the time to review the map and provide feedback. Unless there are any major issues, we hope to present the current draft as v1 in Sydney and continue iterating over the next cycle. Changes made to v1 based on community feedback: - Added python sdk in the openstack-user bucket, since it is an official SDK - Added Blazar in Orchestration subcategory - Added Tricircle to the operations bucket under a "multi-region tools” subcategory - Added Cyborg to operations bucket under “Optimization" - Moved Freezer to 'Application Lifecycle’ subcategory - Moved Tacker to the "adjacent tech enabler" bucket, in a "NFV” subcategory - Moved Aodh to the "Orchestration” subcategory - Renamed the "OPENSTACK-IAAS" bucket to simply "OPENSTACK” (addressing some issues about what was defined as iaas, and side benefit: this would keep existing links to the main github org working) - Moved Glance to the "shared services” subcategory, based on feedback that it did not fit under virtual machines - Added Zun to a "Containers" column within the "Compute” subcategory, based on feedback that it was a lower level service, not orchestration Outstanding work (post Sydney v2): - Would be nice to be able to dynamically change the map to only show projects that have a given maturity level or higher - e.g. if you set it to "maturity of 6 and above", you'd see a map with Nova, Cinder, Keystone, Neutron, and Swift - There was also a comment about bold vs non-bold projects which is intended to be a maturity/adoption indicator in the meantime Also note we adjusted the layout so it fits more nicely into presentations without having to shrink the font as much. Thanks! Lauren
On Sep 11, 2017, at 2:30 PM, Lauren Sell <lauren@openstack.org> wrote:
Hi everyone,
One more follow up note from me today. In the joint leadership meeting we presented a map of OpenStack deliverables, which includes a new structure to categorize OpenStack projects. The goal is to better communicate “what is OpenStack?” by bucketing the projects according to functionality and simplifying the appearance of the project ecosystem. The map also hides many of the supporting projects, like libraries, to focus on the user-centric deliverables view.
Here’s a link to the presentation the working group put together with the map: https://docs.google.com/presentation/d/1qQ1oCjhEE3bjtjkPydGhyeR6vFyuyFeOhbwc... <https://docs.google.com/presentation/d/1qQ1oCjhEE3bjtjkPydGhyeR6vFyuyFeOhbwc-WueddI/edit#slide=id.g253b34e9c2_0_24>
We’re looking for feedback on the map on slide #3 and the buckets listed on slide #5 (which would equate to git repo directories). If you are unable to view the google presentation, please let me know, and I’ll email you the PDF.
Next steps: 1. Please add any feedback to this etherpad by September 19th — https://etherpad.openstack.org/p/map-feedback <https://etherpad.openstack.org/p/map-feedback> 2. Thierry and I are going to review/consolidate the feedback and work with the Foundation design team to do another rev of the diagram. 3. Once we have the next version ready, we’ll share it back and likely set up a meeting to refine/debate any final points.
The goal is to present the new map by Sydney, but we still need to work through the timeline for updating directory names / Github mirrors and communicating that to all appropriate stakeholders.
Thanks, Lauren
_______________________________________________ Foundation-board mailing list Foundation-board@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board
Lauren, A few comments. 1. Ironic is both baremetal provisioning and deployment tool. Suggest we replace Bifrost with Bifrost/Ironic. 2. Deployment tools is too restrictive. Suggest renaming it Life-cycle Management. It covers deployment, update, upgrade, etc. 3. Why is AODH part of Orchestration and not Monitoring Tools. 4. Suggest adding Tempest to Optimization/policy tools bucket. Also suggest renaming it as validation/optimization/policy tools. Tempest is used by many users as validation tool and we expect customers and distros submit tempest results for interop/refstack. Thanks, Arkady From: Lauren Sell [mailto:lauren@openstack.org] Sent: Monday, October 09, 2017 4:47 PM To: foundation-board@lists.openstack.org mailing list <foundation-board@lists.openstack.org>; goldmembers@lists.openstack.org; openstack-tc@lists.openstack.org Cc: Thierry Carrez <thierry@openstack.org> Subject: Re: [Gold Members] [Foundation Board] OpenStack Deliverables Map -- Feedback Request Hi everyone, To follow up on this process, Thierry and I updated the OpenStack projects map based on feedback provided at the joint leadership meeting and subsequently in the etherpad. Thank you to everyone who took the time to review the map and provide feedback. Unless there are any major issues, we hope to present the current draft as v1 in Sydney and continue iterating over the next cycle. Changes made to v1 based on community feedback: - Added python sdk in the openstack-user bucket, since it is an official SDK - Added Blazar in Orchestration subcategory - Added Tricircle to the operations bucket under a "multi-region tools” subcategory - Added Cyborg to operations bucket under “Optimization" - Moved Freezer to 'Application Lifecycle’ subcategory - Moved Tacker to the "adjacent tech enabler" bucket, in a "NFV” subcategory - Moved Aodh to the "Orchestration” subcategory - Renamed the "OPENSTACK-IAAS" bucket to simply "OPENSTACK” (addressing some issues about what was defined as iaas, and side benefit: this would keep existing links to the main github org working) - Moved Glance to the "shared services” subcategory, based on feedback that it did not fit under virtual machines - Added Zun to a "Containers" column within the "Compute” subcategory, based on feedback that it was a lower level service, not orchestration Outstanding work (post Sydney v2): - Would be nice to be able to dynamically change the map to only show projects that have a given maturity level or higher - e.g. if you set it to "maturity of 6 and above", you'd see a map with Nova, Cinder, Keystone, Neutron, and Swift - There was also a comment about bold vs non-bold projects which is intended to be a maturity/adoption indicator in the meantime Also note we adjusted the layout so it fits more nicely into presentations without having to shrink the font as much. Thanks! Lauren
Arkady.Kanevsky@dell.com wrote:
1. Ironic is both baremetal provisioning and deployment tool. Suggest we replace Bifrost with Bifrost/Ironic.
The deliverables in the "OPENSTACK-LIFECYCLEMANAGEMENT" bucket are the tools that can be used to deploy and/or handle the lifecycle of an OpenStack install. The reason we put Bifrost in that bucket is that it can be used to deploy Ironic standalone. I don't see Ironic as an OpenStack deployment/lifecycle tool, even if it can be used by deployment/lifecycle tools to deploy OpenStack... Could you expand on what you mean ?
2. Deployment tools is too restrictive. Suggest renaming it Life-cycle Management. It covers deployment, update, upgrade, etc.
That's a good idea, I agree it's a more complete description for that subcategory.
3. Why is AODH part of Orchestration and not Monitoring Tools.
Aodh was originally put in Monitoring, but we received several pieces of feedback that it would be better placed as an orchestration tool. Not all tools in the Telemetry toolbox are about monitoring. Aodh is a user-facing tool that lets you trigger actions based on metrics. Communicating to applications what is happening with their infrastructure is not really an operational concern, it should really be seen as an essential IaaS component. So the way I see it, Aodh is the openstack-side, user-facing component that lets you leverage metric information.
4. Suggest adding Tempest to Optimization/policy tools bucket. Also suggest renaming it as validation/optimization/policy tools. Tempest is used by many users as validation tool and we expect customers and distros submit tempest results for interop/refstack.
That's a good point. Wondering if we should not have a "Validation / perf testing" subcategory (that would include Rally and Tempest), distinct from the "optimization/policy" subcategory, as those are really different concerns (optimizing a running cloud vs. externally testing a given deployment). In conclusion, please keep in mind that there is no attempt at categorizing OpenStack components that that will be universally accepted as the correct one. As any mapping exercise, this one is a balancing act between what we show, what we don't show, readability, and correctness. -- Thierry Carrez (ttx)
Thierry, Comments inline. -----Original Message----- From: Thierry Carrez [mailto:thierry@openstack.org] Sent: Wednesday, October 11, 2017 5:26 AM To: Kanevsky, Arkady <Arkady_Kanevsky@DELL.com>; lauren@openstack.org; foundation-board@lists.openstack.org; goldmembers@lists.openstack.org; openstack-tc@lists.openstack.org Subject: Re: [Gold Members] [Foundation Board] OpenStack Deliverables Map -- Feedback Request Arkady.Kanevsky@dell.com wrote:
1. Ironic is both baremetal provisioning and deployment tool. Suggest we replace Bifrost with Bifrost/Ironic.
The deliverables in the "OPENSTACK-LIFECYCLEMANAGEMENT" bucket are the tools that can be used to deploy and/or handle the lifecycle of an OpenStack install. The reason we put Bifrost in that bucket is that it can be used to deploy Ironic standalone. I don't see Ironic as an OpenStack deployment/lifecycle tool, even if it can be used by deployment/lifecycle tools to deploy OpenStack... Could you expand on what you mean ? AK: Ironic can and is used by TripleO to manage server configuration specific to the functionality to be run on a node. That includes setup RAID, BIOS and FW. In the future we want to also be able to update FW/RAID thru Ironic. This makes Ironic a deployment tool and life-cycle management tool.
2. Deployment tools is too restrictive. Suggest renaming it Life-cycle Management. It covers deployment, update, upgrade, etc.
That's a good idea, I agree it's a more complete description for that subcategory.
3. Why is AODH part of Orchestration and not Monitoring Tools.
Aodh was originally put in Monitoring, but we received several pieces of feedback that it would be better placed as an orchestration tool. Not all tools in the Telemetry toolbox are about monitoring. Aodh is a user-facing tool that lets you trigger actions based on metrics. Communicating to applications what is happening with their infrastructure is not really an operational concern, it should really be seen as an essential IaaS component. So the way I see it, Aodh is the openstack-side, user-facing component that lets you leverage metric information. AK: Agree that AODH can be utilize by orchestration but it is not an orchestration in itself. All Monitoring tools are used to trigger some action when certain criteria is met. I view AODH is part of telemetry bucket along with Painko.
4. Suggest adding Tempest to Optimization/policy tools bucket. Also suggest renaming it as validation/optimization/policy tools. Tempest is used by many users as validation tool and we expect customers and distros submit tempest results for interop/refstack.
That's a good point. Wondering if we should not have a "Validation / perf testing" subcategory (that would include Rally and Tempest), distinct from the "optimization/policy" subcategory, as those are really different concerns (optimizing a running cloud vs. externally testing a given deployment). AK: +1 In conclusion, please keep in mind that there is no attempt at categorizing OpenStack components that that will be universally accepted as the correct one. As any mapping exercise, this one is a balancing act between what we show, what we don't show, readability, and correctness. AK: fully agree. -- Thierry Carrez (ttx)
In conclusion, please keep in mind that there is no attempt at categorizing OpenStack components that that will be universally accepted as the correct one. As any mapping exercise, this one is a balancing act between what we show, what we don't show, readability, and correctness.
-- Thierry Carrez (ttx)
Thanks for working on this. I think it is a very useful exercise, and even if it can never be fully complete or comprehensive, I think this at least is able to represent where things fit in the stack and help those newer to OpenStack to get a little better lay of the land. At least a good thought exercise for our own sake as well. Sean
participants (4)
-
Arkady.Kanevsky＠dell.com
-
Lauren Sell
-
Sean McGinnis
-
Thierry Carrez