settingsLogin | Registersettings

[Foundation Board] OpenStack Deliverables Map -- Feedback Request

0 votes

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-WueddI/edit#slide=id.g253b34e9c2_0_24 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
asked Oct 11, 2017 in openstack-board by Lauren_Sell (2,240 points)   5

5 Responses

0 votes

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-WueddI/edit#slide=id.g253b34e9c2_0_24 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


Foundation-board mailing list
Foundation-board@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board

responded Oct 9, 2017 by Lauren_Sell (2,240 points)   5
0 votes

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


Foundation-board mailing list
Foundation-board@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board
responded Oct 10, 2017 by Arkady.Kanevsky_at_d (1,480 points)   1
0 votes

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)


Foundation-board mailing list
Foundation-board@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board
responded Oct 11, 2017 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

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)


Foundation-board mailing list
Foundation-board@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board
responded Oct 11, 2017 by Arkady.Kanevsky_at_d (1,480 points)   1
0 votes

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


Foundation-board mailing list
Foundation-board@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board
responded Oct 11, 2017 by Sean_McGinnis (11,820 points)   2 3 5
...