openstack/governance
Code Issues Proposed changes
4540bc2e15
governance/reference/projects.yaml

2660 lines
72 KiB
YAML
Raw Normal View History

Add TC/PTL results from 2025.1 election Also clear out existing TC roles and prepare for nominations. Depends-On: Id5847c7c37d556b11932dae542f4aaeb699cf7ec Change-Id: I7760c815d032c7aaff9956588b6ce5c1fb7b4750
2024-09-19 23:17:25 +09:00
---
Adjutant official project status Adjuant is a service built to help manage certain elements of operations processes by providing micro APIs around complex underlying workflow. It started life as a system to manage sign ups to a public cloud, and grew into a more generic and flexible system into which deployers can add useful APIs for their users to consume. The project history can be found on the docs[1], as well as some guide lines which explain what the scope of the project is, and how we manage how vague it is[2]. Then there is a section going over what is built into Adjutant[3]. The project was built to be integrated from the beginning with OpenStack, using KeystoneMiddleware for auth, will be moving to oslo policy in the near future, and we hope to switch to using the OpenStackSDK for all OpenStack API interactions. Adjutant meets all of the new project requirements easily. The source is Apache License 2.0, and all libraries used are opensource. While the project was started internally at Catalyst we use Launchpad for bug and blueprints tracking and all of us are developers already working upstream with OpenStack. Code review and gated testing is done on the OpenStack infrastructure, and the goal is always to support features in other projects first (see guide-lines doc[2]). We want to build Adjutant to be useful to the community and have taken care to build ways to keep company specific logic out of the service by providing plugin mechanisms. Catalyst Cloud[4] is a company dedicated to opensource, and we always prefer working with others to achieve a goal that works for everyone rather than writing internal only solutions. Almost all our work is opensource where applicable, and we are active in the community. Catalyst Cloud runs Adjutant in production (very near to master), and we know of at least another company using it for password resets, as well as interest from a few more. For Catalyst Cloud it handles our full automated sign up process, and we run almost all of the default Tasks as defined in the core codebase for user management. [1]: https://adjutant.readthedocs.io/en/latest/history.html [2]: https://adjutant.readthedocs.io/en/latest/guide-lines.html [3]: https://adjutant.readthedocs.io/en/latest/features.html [4]: https://catalystcloud.nz/ Change-Id: I0d119fa26b7ed8969870ad0c3f405e0ac3df98e3
2018-03-16 13:41:10 +13:00
adjutant:
ptl:
Appoint Dale as Adjutant PTL Dale raised the late candidacy for Adjutant PTL 2023.1 cycle. - https://review.opendev.org/c/openstack/election/+/857258 - https://etherpad.opendev.org/p/2023.1-leaderless As we are using the release number, updating the project list schema for appointment field. Change-Id: I2e821e0c2b574efbf392feef66af1df699be74df
2022-09-22 13:07:42 -05:00
name: Dale Smith
irc: dalees
email: dale@catalystcloud.nz
Appoint Adrian Turjak as Adjutant PTL Adrian confirmed to serve as Adjutant PTL. - http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2020-04-03.log.html#t2020-04-03T01:53:24 Change-Id: I525ac49d50564fd8ba8f816ec5d979763f8a5fc2
2020-04-03 11:27:43 -05:00
appointed:
- victoria
Appoint Adrian Turjak as Adjutant PTL Adrian Turjak mentioned about missing the elections and confirmed to server as Adjutant PTL position for Yoga Cycle - https://etherpad.opendev.org/p/yoga-leaderless Change-Id: Icc66ef0d8a30414028578d794e65c29c94fdf415
2021-09-08 09:39:06 -05:00
- yoga
Appoint Dale Smith as Adjutant PTL Change-Id: Ic7fd9887111c6c1acd58ead1452a67cac599fa4a
2022-07-13 15:10:49 +12:00
- zed
Consider release version as string in projects data We need to use the release version as string, so updating the PTL 'appointment' field and the data in projects.yaml Change-Id: Ib097517f514e68246fb6e27b83e98a1f3f6b8eed
2023-03-10 18:14:20 -06:00
- '2023.1'
Adjutant official project status Adjuant is a service built to help manage certain elements of operations processes by providing micro APIs around complex underlying workflow. It started life as a system to manage sign ups to a public cloud, and grew into a more generic and flexible system into which deployers can add useful APIs for their users to consume. The project history can be found on the docs[1], as well as some guide lines which explain what the scope of the project is, and how we manage how vague it is[2]. Then there is a section going over what is built into Adjutant[3]. The project was built to be integrated from the beginning with OpenStack, using KeystoneMiddleware for auth, will be moving to oslo policy in the near future, and we hope to switch to using the OpenStackSDK for all OpenStack API interactions. Adjutant meets all of the new project requirements easily. The source is Apache License 2.0, and all libraries used are opensource. While the project was started internally at Catalyst we use Launchpad for bug and blueprints tracking and all of us are developers already working upstream with OpenStack. Code review and gated testing is done on the OpenStack infrastructure, and the goal is always to support features in other projects first (see guide-lines doc[2]). We want to build Adjutant to be useful to the community and have taken care to build ways to keep company specific logic out of the service by providing plugin mechanisms. Catalyst Cloud[4] is a company dedicated to opensource, and we always prefer working with others to achieve a goal that works for everyone rather than writing internal only solutions. Almost all our work is opensource where applicable, and we are active in the community. Catalyst Cloud runs Adjutant in production (very near to master), and we know of at least another company using it for password resets, as well as interest from a few more. For Catalyst Cloud it handles our full automated sign up process, and we run almost all of the default Tasks as defined in the core codebase for user management. [1]: https://adjutant.readthedocs.io/en/latest/history.html [2]: https://adjutant.readthedocs.io/en/latest/guide-lines.html [3]: https://adjutant.readthedocs.io/en/latest/features.html [4]: https://catalystcloud.nz/ Change-Id: I0d119fa26b7ed8969870ad0c3f405e0ac3df98e3
2018-03-16 13:41:10 +13:00
irc-channel: openstack-adjutant
service: Operations Processes automation
mission: >
To provide an extensible API framework for exposing to users an
organization's automated business processes relating to account management
across OpenStack and external systems, that can be adapted to the unique
requirements of an organization's processes.
url: http://adjutant.readthedocs.io/
deliverables:
adjutant:
repos:
- openstack/adjutant
adjutant-ui:
repos:
- openstack/adjutant-ui
python-adjutantclient:
repos:
- openstack/python-adjutantclient
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
barbican:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Close Antelope Elections Reflects election result to governance repo : https://review.opendev.org/c/openstack/election/+/858532 Change-Id: Ic4f80855d784f9bf104f0f982fc8f265544d961f
2022-09-20 23:24:42 +09:00
name: Grzegorz Grasza
irc: xek
email: xek@redhat.com
Appoint Douglas Mendizabal as Barbican PTL Douglas confirmed to serve as Barbican PTL. - https://review.opendev.org/#/c/716316/ Change-Id: I2d528a4d95eb79ecc5338b8e93f0119f07de6bbb
2020-04-03 11:37:56 -05:00
appointed:
- victoria
Appoint Douglas Mendizábal as Barbican PTL Douglas Mendizábal updated in TC meeting on late candidacy for Barbican PTL position of Xena Cycle - http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-03-11-15.00.log.html#l-230 Change-Id: I29e6e1dba661452fbed4239e4ee9e464504b08c1
2021-03-11 13:26:52 -06:00
- xena
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-barbican
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Key Manager service
use ">" to indicate multiline mission statements ">" indicates to YAML that the multiline string which follows is intended to ignore the line breaks contained within. Also includes some related whitespace cleanup. Change-Id: I6403c1d5663f9575c0d6ada2f1e672e743e451f3
2014-07-23 10:40:47 -05:00
mission: >
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
To produce a secret storage and generation system capable of providing key
management for services wishing to enable encryption features.
url: https://wiki.openstack.org/wiki/Barbican
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
barbican:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/barbican
Move ansible-role-XXX-hsm projects to Barbican team As discussed in a recent OpenStack Ansible meeting [0], the Barbican team would like make versioned releases of the Ansible roles used to manage Hardware Security Modules (HSMs). This patch moves two of the HSM roles into their own deliverables under the Barbican team. [0] http://eavesdrop.openstack.org/meetings/openstack_ansible_meeting/2020/openstack_ansible_meeting.2020-08-11-16.05.log.html Change-Id: I19026ba1cc6e4e8376946765a03a756394e4c09c
2020-08-25 15:26:47 -05:00
ansible-role-atos-hsm:
repos:
- openstack/ansible-role-atos-hsm
Rename ansible-role-lunasa-hsm deliverable This patch renames the deliverable for ansible-role-lunasa-hsm to make the release automation happy. It appears that the inital release patch is failing because of this mistmatch. Needed-By: I6b84d7092010872283ed79be9f0c7a0c6aed9f18 Change-Id: I4029dabd3de8468e50da10aedda3b82b3c08e72b
2020-05-27 14:38:57 -05:00
ansible-role-lunasa-hsm:
Add ansible role for managing Luna SA HSM This patch adds a new ansible role used to manage client software for the Gemalto Luna SA Hardware Security Module (HSM). This role is used in TripleO to install HSM client software on Controller nodes to enable the PCKS#11 backend for Barbican. Change-Id: Ifb1c1f3ac87caf93d8e1d673b4c07753ca72fe93 Depends-On: Id694007e7da55f92952b1f55474a7f87bfdb3339
2020-04-20 16:27:23 -05:00
repos:
- openstack/ansible-role-lunasa-hsm
Move ansible-role-XXX-hsm projects to Barbican team As discussed in a recent OpenStack Ansible meeting [0], the Barbican team would like make versioned releases of the Ansible roles used to manage Hardware Security Modules (HSMs). This patch moves two of the HSM roles into their own deliverables under the Barbican team. [0] http://eavesdrop.openstack.org/meetings/openstack_ansible_meeting/2020/openstack_ansible_meeting.2020-08-11-16.05.log.html Change-Id: I19026ba1cc6e4e8376946765a03a756394e4c09c
2020-08-25 15:26:47 -05:00
ansible-role-thales-hsm:
repos:
- openstack/ansible-role-thales-hsm
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
barbican-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/barbican-specs
Add barbican repo for tempest tests As described in the tempest documentation [1] the recommended way for plugins are seperate branchless repos outside the project repo. [1]: http://docs.openstack.org/developer/tempest/plugin.html#standalone-plugin-vs-in-repo-plugin Depends-On: Ib5d7fec7a992013d0a479a25cb72e819b30b45bd Change-Id: I1b88d17e91648e0f1f76a951dc5f8c99008c2f18
2016-11-30 09:23:23 +01:00
barbican-tempest-plugin:
repos:
- openstack/barbican-tempest-plugin
Add openstack/barbican-ui Depends-On: I5687c25113c2f821c2d29df0c190b04b631f56c1 Change-Id: If6f64ae6e275e5e235ef0a41f5266fe209db3da4
2019-10-15 07:45:24 -05:00
barbican-ui:
repos:
- openstack/barbican-ui
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-barbicanclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-barbicanclient
Blazar - Resource Reservation Service The mission of Blazar project[1] is to provide resource reservations in OpenStack clouds for virtual resouces and physical resources. Blazar ensures cloud users can deploy their resources during specific time frames, using reservations. Blazar creates reservations when it recieves requests from cloud users about future usages of resources. It finds out if the clouds can accommodate the usage requests in the reservation time frame. A request can define reservations of various kinds of resources, such as virtual resources (Nova instances or Cinder volumes) as well as physical resources (Nova hypervisor or Cinder storage). The features of Blazar are interesting varied kind of OpenStack clouds users, such as Scientific WGs and Enterprise as well as OPNFV Promise. The active team members are coming from each area, and its development cycle is neutral for all area. Additionally, Blazar tends to solve some problems described in the user story[2] defined by the Product WGs. The development cycle of the team is following OpenStack patterns. The team think operator feedbacks are much important to improve Blazar project and its community. So the priorities for each cycle have been decided based on not only development requests but operator feedbacks. The Blazar code is not implemented from scratch by the current active members. Blazar project was founded at the Icehouse cycle, but inactive between Kilo and Newton. At Barcelona Summit, the current members, some are the real users of Blazar in production and others are operators of NFV who need Blazar, gathered and started to revive Blazar project. Blazar project and the team follow the 4 opens: * Open Source: The Blazar source code[3], specifications[4] and documentation[5] are completely open source. All are released under the Apache 2.0 licence. * Open Design: The team openly works for all activities. For release milestones, the team discussed problems Blazar was facing, work items the team was targeting, and project's priorities in etherpad[6], [7]. Additionally, the team had meetings in both PTG[7] and Boston Summit[8]. * Open Development: All Blazar code is reviewed and hosted in OpenStack CI[9]. The CI supports unit tests and Tempest scenario test. All blueprint and bugs are tracked by Launchpad[10]. * Open Community: All new design and bugs are open in Blazar Launchpad[10]. The team weekly IRC meeting[11] is held in a IRC channel for OpenStack projects and #openstack-blazar channel is open to everyone who want to discuss Blazar-related topics. 1. https://wiki.openstack.org/wiki/Blazar 2. http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/capacity_management.html 3. https://github.com/openstack/blazar 4. https://github.com/openstack/blazar/tree/master/doc/source/devref 5. http://blazar.readthedocs.io/en/latest/ 6. https://etherpad.openstack.org/p/Blazar_status_2016 7. https://etherpad.openstack.org/p/blazar-ptg-pike 8. https://etherpad.openstack.org/p/blazar-boston-summit 9. https://review.openstack.org/#/q/status:open+blazar 10. https://launchpad.net/blazar 11. http://eavesdrop.openstack.org/#Blazar_Team_Meeting Change-Id: I7473dc15b553195dbbe2665ade9ecf6a8bc21839
2017-07-12 18:00:26 +09:00
blazar:
ptl:
Update with results from the Stein PTL election Change-Id: I632b203af1e7a7fca5124bed735b38d61b43b7ab
2018-08-08 12:54:10 +10:00
name: Pierre Riteau
irc: priteau
email: pierre@stackhpc.com
Blazar - Resource Reservation Service The mission of Blazar project[1] is to provide resource reservations in OpenStack clouds for virtual resouces and physical resources. Blazar ensures cloud users can deploy their resources during specific time frames, using reservations. Blazar creates reservations when it recieves requests from cloud users about future usages of resources. It finds out if the clouds can accommodate the usage requests in the reservation time frame. A request can define reservations of various kinds of resources, such as virtual resources (Nova instances or Cinder volumes) as well as physical resources (Nova hypervisor or Cinder storage). The features of Blazar are interesting varied kind of OpenStack clouds users, such as Scientific WGs and Enterprise as well as OPNFV Promise. The active team members are coming from each area, and its development cycle is neutral for all area. Additionally, Blazar tends to solve some problems described in the user story[2] defined by the Product WGs. The development cycle of the team is following OpenStack patterns. The team think operator feedbacks are much important to improve Blazar project and its community. So the priorities for each cycle have been decided based on not only development requests but operator feedbacks. The Blazar code is not implemented from scratch by the current active members. Blazar project was founded at the Icehouse cycle, but inactive between Kilo and Newton. At Barcelona Summit, the current members, some are the real users of Blazar in production and others are operators of NFV who need Blazar, gathered and started to revive Blazar project. Blazar project and the team follow the 4 opens: * Open Source: The Blazar source code[3], specifications[4] and documentation[5] are completely open source. All are released under the Apache 2.0 licence. * Open Design: The team openly works for all activities. For release milestones, the team discussed problems Blazar was facing, work items the team was targeting, and project's priorities in etherpad[6], [7]. Additionally, the team had meetings in both PTG[7] and Boston Summit[8]. * Open Development: All Blazar code is reviewed and hosted in OpenStack CI[9]. The CI supports unit tests and Tempest scenario test. All blueprint and bugs are tracked by Launchpad[10]. * Open Community: All new design and bugs are open in Blazar Launchpad[10]. The team weekly IRC meeting[11] is held in a IRC channel for OpenStack projects and #openstack-blazar channel is open to everyone who want to discuss Blazar-related topics. 1. https://wiki.openstack.org/wiki/Blazar 2. http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/capacity_management.html 3. https://github.com/openstack/blazar 4. https://github.com/openstack/blazar/tree/master/doc/source/devref 5. http://blazar.readthedocs.io/en/latest/ 6. https://etherpad.openstack.org/p/Blazar_status_2016 7. https://etherpad.openstack.org/p/blazar-ptg-pike 8. https://etherpad.openstack.org/p/blazar-boston-summit 9. https://review.openstack.org/#/q/status:open+blazar 10. https://launchpad.net/blazar 11. http://eavesdrop.openstack.org/#Blazar_Team_Meeting Change-Id: I7473dc15b553195dbbe2665ade9ecf6a8bc21839
2017-07-12 18:00:26 +09:00
irc-channel: openstack-blazar
service: Resource reservation service
mission: >
Blazar's goal is to provide resource reservations in
OpenStack clouds for different resource types, both
virtual (instances, volumes, etc) and physical (hosts,
storage, etc.).
url: https://wiki.openstack.org/wiki/Blazar
deliverables:
blazar:
repos:
- openstack/blazar
Add blazar-specs repository This commit also orders Blazar deliverables alphabetically. Change-Id: I8407cb2a7347a119733f6eb7dcb8bf69698c6eab Depends-On: https://review.openstack.org/602783
2018-10-22 16:54:32 +01:00
blazar-dashboard:
repos:
- openstack/blazar-dashboard
Blazar - Resource Reservation Service The mission of Blazar project[1] is to provide resource reservations in OpenStack clouds for virtual resouces and physical resources. Blazar ensures cloud users can deploy their resources during specific time frames, using reservations. Blazar creates reservations when it recieves requests from cloud users about future usages of resources. It finds out if the clouds can accommodate the usage requests in the reservation time frame. A request can define reservations of various kinds of resources, such as virtual resources (Nova instances or Cinder volumes) as well as physical resources (Nova hypervisor or Cinder storage). The features of Blazar are interesting varied kind of OpenStack clouds users, such as Scientific WGs and Enterprise as well as OPNFV Promise. The active team members are coming from each area, and its development cycle is neutral for all area. Additionally, Blazar tends to solve some problems described in the user story[2] defined by the Product WGs. The development cycle of the team is following OpenStack patterns. The team think operator feedbacks are much important to improve Blazar project and its community. So the priorities for each cycle have been decided based on not only development requests but operator feedbacks. The Blazar code is not implemented from scratch by the current active members. Blazar project was founded at the Icehouse cycle, but inactive between Kilo and Newton. At Barcelona Summit, the current members, some are the real users of Blazar in production and others are operators of NFV who need Blazar, gathered and started to revive Blazar project. Blazar project and the team follow the 4 opens: * Open Source: The Blazar source code[3], specifications[4] and documentation[5] are completely open source. All are released under the Apache 2.0 licence. * Open Design: The team openly works for all activities. For release milestones, the team discussed problems Blazar was facing, work items the team was targeting, and project's priorities in etherpad[6], [7]. Additionally, the team had meetings in both PTG[7] and Boston Summit[8]. * Open Development: All Blazar code is reviewed and hosted in OpenStack CI[9]. The CI supports unit tests and Tempest scenario test. All blueprint and bugs are tracked by Launchpad[10]. * Open Community: All new design and bugs are open in Blazar Launchpad[10]. The team weekly IRC meeting[11] is held in a IRC channel for OpenStack projects and #openstack-blazar channel is open to everyone who want to discuss Blazar-related topics. 1. https://wiki.openstack.org/wiki/Blazar 2. http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/capacity_management.html 3. https://github.com/openstack/blazar 4. https://github.com/openstack/blazar/tree/master/doc/source/devref 5. http://blazar.readthedocs.io/en/latest/ 6. https://etherpad.openstack.org/p/Blazar_status_2016 7. https://etherpad.openstack.org/p/blazar-ptg-pike 8. https://etherpad.openstack.org/p/blazar-boston-summit 9. https://review.openstack.org/#/q/status:open+blazar 10. https://launchpad.net/blazar 11. http://eavesdrop.openstack.org/#Blazar_Team_Meeting Change-Id: I7473dc15b553195dbbe2665ade9ecf6a8bc21839
2017-07-12 18:00:26 +09:00
blazar-nova:
repos:
- openstack/blazar-nova
Add blazar-specs repository This commit also orders Blazar deliverables alphabetically. Change-Id: I8407cb2a7347a119733f6eb7dcb8bf69698c6eab Depends-On: https://review.openstack.org/602783
2018-10-22 16:54:32 +01:00
blazar-specs:
Mark blazar-specs release-management: none Recently-added blazar-specs failed to mention that deliverable does not need release management. Change-Id: Ia5409b947c40418157a6d4c99169302047bf1454
2018-11-28 13:20:19 +01:00
release-management: none
Add blazar-specs repository This commit also orders Blazar deliverables alphabetically. Change-Id: I8407cb2a7347a119733f6eb7dcb8bf69698c6eab Depends-On: https://review.openstack.org/602783
2018-10-22 16:54:32 +01:00
repos:
- openstack/blazar-specs
Added blazar-tempest-plugin to blazar project Depends-On: I65728962e5a95ab706f5c2d3b2a275f5c3d052d4 Change-Id: I605d09b6e278e921faba2c3f44b3adde63e65287
2017-12-18 14:51:32 +05:30
blazar-tempest-plugin:
repos:
- openstack/blazar-tempest-plugin
Blazar - Resource Reservation Service The mission of Blazar project[1] is to provide resource reservations in OpenStack clouds for virtual resouces and physical resources. Blazar ensures cloud users can deploy their resources during specific time frames, using reservations. Blazar creates reservations when it recieves requests from cloud users about future usages of resources. It finds out if the clouds can accommodate the usage requests in the reservation time frame. A request can define reservations of various kinds of resources, such as virtual resources (Nova instances or Cinder volumes) as well as physical resources (Nova hypervisor or Cinder storage). The features of Blazar are interesting varied kind of OpenStack clouds users, such as Scientific WGs and Enterprise as well as OPNFV Promise. The active team members are coming from each area, and its development cycle is neutral for all area. Additionally, Blazar tends to solve some problems described in the user story[2] defined by the Product WGs. The development cycle of the team is following OpenStack patterns. The team think operator feedbacks are much important to improve Blazar project and its community. So the priorities for each cycle have been decided based on not only development requests but operator feedbacks. The Blazar code is not implemented from scratch by the current active members. Blazar project was founded at the Icehouse cycle, but inactive between Kilo and Newton. At Barcelona Summit, the current members, some are the real users of Blazar in production and others are operators of NFV who need Blazar, gathered and started to revive Blazar project. Blazar project and the team follow the 4 opens: * Open Source: The Blazar source code[3], specifications[4] and documentation[5] are completely open source. All are released under the Apache 2.0 licence. * Open Design: The team openly works for all activities. For release milestones, the team discussed problems Blazar was facing, work items the team was targeting, and project's priorities in etherpad[6], [7]. Additionally, the team had meetings in both PTG[7] and Boston Summit[8]. * Open Development: All Blazar code is reviewed and hosted in OpenStack CI[9]. The CI supports unit tests and Tempest scenario test. All blueprint and bugs are tracked by Launchpad[10]. * Open Community: All new design and bugs are open in Blazar Launchpad[10]. The team weekly IRC meeting[11] is held in a IRC channel for OpenStack projects and #openstack-blazar channel is open to everyone who want to discuss Blazar-related topics. 1. https://wiki.openstack.org/wiki/Blazar 2. http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/capacity_management.html 3. https://github.com/openstack/blazar 4. https://github.com/openstack/blazar/tree/master/doc/source/devref 5. http://blazar.readthedocs.io/en/latest/ 6. https://etherpad.openstack.org/p/Blazar_status_2016 7. https://etherpad.openstack.org/p/blazar-ptg-pike 8. https://etherpad.openstack.org/p/blazar-boston-summit 9. https://review.openstack.org/#/q/status:open+blazar 10. https://launchpad.net/blazar 11. http://eavesdrop.openstack.org/#Blazar_Team_Meeting Change-Id: I7473dc15b553195dbbe2665ade9ecf6a8bc21839
2017-07-12 18:00:26 +09:00
python-blazarclient:
repos:
- openstack/python-blazarclient
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
cinder:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Add PTL results from the 2024.2/Dalmatian election Depends-On: If6c157efebc58d1fbe32a61a64f209b4102ac5c8 Change-Id: Ic74bfc853d2d9d045d4c589e1fd6c50afa608423
2024-03-22 09:00:21 +09:00
name: Jon Bernard
irc: No nick supplied
email: jobernar@redhat.com
Add IRC channels to team pages Include the name of the IRC channel and a link to the IRC channel logs where the channel is known. Change-Id: Id6c54a89b040a76a6da2a6f48dbdce7515d2d867
2015-05-29 18:20:33 +00:00
irc-channel: openstack-cinder
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Block Storage service
use ">" to indicate multiline mission statements ">" indicates to YAML that the multiline string which follows is intended to ignore the line breaks contained within. Also includes some related whitespace cleanup. Change-Id: I6403c1d5663f9575c0d6ada2f1e672e743e451f3
2014-07-23 10:40:47 -05:00
mission: >
To implement services and libraries to provide on-demand, self-service
access to Block Storage resources via abstraction and automation on top of
other block storage devices.
Initial structure and reference documents Create initial repository structure and add the following reference documents: - charter: The authoritative copy of the TC charter (copied from wiki) - members: Current TC members with election expiration - programs.yaml: List of official programs including PTLs, codenames, mission statements... - extra-atcs: List of people being granted an ATC exception Change-Id: Ia2df3bf0808af8cfa306092442160d5ecb14dfb0
2013-08-30 18:09:28 +02:00
url: https://wiki.openstack.org/wiki/Cinder
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
cinder:
repos:
- openstack/cinder
cinder-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
- openstack/cinder-specs
Add cinder-tempest-plugin to Cinder Create a new repository for cinder tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: I45371a167016cd22e1c4a80775aaf4cea469d35b Implements: blueprint goal-split-tempest-plugin Change-Id: I2b0d3c4a80cdc9c38226f125c16a0c98c18f524d
2017-07-22 07:06:12 -04:00
cinder-tempest-plugin:
repos:
- openstack/cinder-tempest-plugin
Add cinderlib Change-Id: I41416c73a9b1475cce38c234cc65e276f72f8f78 Depends-On: I071250d10218751fb2a134b17afd95185c9b49f9
2019-02-18 18:44:04 +01:00
cinderlib:
Deprecate cinderlib This has been announced on the openstack-discuss mailing list: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/L6HJW55SEUL4NYQVOESJ22KFDW5SGZAE/ Needed-by: I081cd363117671eaab6a3193094d5872f9820354 Needed-by: I4722b869033ad1bd357e36c4a258b6d3ea61f5d6 Needed-by: I28b777dccbcd15b0960ac3fe3e95021633fa8dd7 Needed-by: If2b9a82cddb20543b176ee22765049db257c89b9 Needed-by: I1143e5e5ccf8103e386fe1ce614a554e7f152d9a Change-Id: Ib186ac5830e5920e264d79be946995e63e960426
2023-12-10 12:56:48 -05:00
deprecated: '2024.1'
release-management: deprecated
Add cinderlib Change-Id: I41416c73a9b1475cce38c234cc65e276f72f8f78 Depends-On: I071250d10218751fb2a134b17afd95185c9b49f9
2019-02-18 18:44:04 +01:00
repos:
- openstack/cinderlib
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
os-brick:
repos:
- openstack/os-brick
Add Cinder's python-brick-cinderclient-ext library to cinder Blueprint: use-cinder-without-nova This adds the new cinder project python-brick-cinderclient-ext as a subproject of Cinder Related patch: Ifbf1ee3883e81713f665daf8ed8e6ca587206b81 Change-Id: I0c5d36bb1be9d435e15a5aac024bd969258cbdbb
2015-11-09 14:28:21 +02:00
python-brick-cinderclient-ext:
repos:
- openstack/python-brick-cinderclient-ext
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
python-cinderclient:
repos:
- openstack/python-cinderclient
Add rbd-iscsi-client to cinder project Add the rbd-iscsi-client repo to the cinder project. It will follow the independent release model. rbd-iscsi-client was added to global-requirements by commit 2ce1a5eaab. The cinder project is assuming maintenance of the library. Depends-on: Icac3f5f74b2fca06c8b25fa78d895bbb710ea308 Change-Id: I8f968adcc827cc7171c8310a585d3c79aba12940
2021-01-26 15:26:00 -05:00
rbd-iscsi-client:
repos:
- openstack/rbd-iscsi-client
CloudKitty application for Big Tent This is a request to add CloudKitty [1] to the Big Tent. CloudKitty is a rating as a Service component aimed at easing integration of OpenStack with existing billing systems. It consumes data from metric systems (ceilometer for example) and with the help of rating plugins and client defined rules, generates prices for the different services. The project is fully licensed under the Apache 2.0 license, and has been actively promoted during the last 2 cycles including a presentation at Vancouver summit, and another on stage presentation. Stéphane Albert is currently acting as PTL. He has been working on the project since the first POC shown at the OpenStack Summit Atlanta. We plan on holding an official PTL election around the Tokyo summit. All code changes are approved by the core members. CloudKitty code is submitted and reviewed using the OpenStack infrastructure and gated through gerrit[2][3][4]. We are starting to use both dev and operators mailing list in order to give the community a way to provide feedback, keep up with our progress and intentions. Meanwhile we have been heavily using IRC for cooperation. The #cloudkitty IRC channel on freenode is logged and the channel is notified of such logging [5]. Community members, core developers and users gather here to discuss about the future of the project as well as questions regarding usage. We have recently booked a slot on #openstack-meeting-3 in for our regular meetings. CloudKitty has been initiated by a single company but since then we have received several patches, and reviews from exterior contributors both originating from different companies and unaffiliated. Actually the whole design of CloudKitty has been improved and decided during regular IRC meetings that have been held by contibutors from many companies in order to reflect their needs and usages. We are aware that CloudKitty has been used in production by several Cloud User (both Cloud Public or Private) for several months. [1]https://wiki.openstack.org/wiki/CloudKitty [2]https://review.openstack.org/#/q/project:stackforge/cloudkitty,n,z [3]https://review.openstack.org/#/q/project:stackforge/python-cloudkittyclient,n,z [4]https://review.openstack.org/#/q/project:stackforge/cloudkitty-dashboard,n,z [5]http://eavesdrop.openstack.org/irclogs/%23cloudkitty/ Change-Id: I1864953db026832e8c40707e212db0ef179fe480
2015-09-18 17:27:54 +02:00
cloudkitty:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Appoint Rafael Weingartner as CloudKitty PTL Appoint Rafael Weingartner as CloudKitty PTL for the Wallaby cycle, based on their late self-nomination: http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017678.html Change-Id: I5c7635cd2c12b9869a422f20b498cb11473ebea9
2020-10-14 15:22:22 +02:00
name: Rafael Weingartner
Record Wallaby Cycle PTL and TC election results This reflects the results of the elections held for PTL and TC positions in October 2020. Depends-On: https://review.opendev.org/757967 Change-Id: I037de61dddf30d9febfea5e819603040e0ccddd2
2020-10-14 00:43:41 +00:00
irc: No nick supplied
Close Xena Elections Depends-On: https://review.opendev.org/c/openstack/election/+/779845 Change-Id: Ideda5fbd4479f9c7821ff03838d6130dd723fa49
2021-03-10 09:32:23 -08:00
email: rafael@apache.org
Appoint Justin Ferrieu as cloudkitty PTL Justin confirmed to serve as cloudkitty PTL: - http://lists.openstack.org/pipermail/openstack-discuss/2020-April/013800.html Change-Id: I11709970f9ebe2b30eab65197fef36d843ba8ccf
2020-04-03 11:43:14 -05:00
appointed:
- victoria
Appoint Rafael Weingartner as CloudKitty PTL Appoint Rafael Weingartner as CloudKitty PTL for the Wallaby cycle, based on their late self-nomination: http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017678.html Change-Id: I5c7635cd2c12b9869a422f20b498cb11473ebea9
2020-10-14 15:22:22 +02:00
- wallaby
CloudKitty application for Big Tent This is a request to add CloudKitty [1] to the Big Tent. CloudKitty is a rating as a Service component aimed at easing integration of OpenStack with existing billing systems. It consumes data from metric systems (ceilometer for example) and with the help of rating plugins and client defined rules, generates prices for the different services. The project is fully licensed under the Apache 2.0 license, and has been actively promoted during the last 2 cycles including a presentation at Vancouver summit, and another on stage presentation. Stéphane Albert is currently acting as PTL. He has been working on the project since the first POC shown at the OpenStack Summit Atlanta. We plan on holding an official PTL election around the Tokyo summit. All code changes are approved by the core members. CloudKitty code is submitted and reviewed using the OpenStack infrastructure and gated through gerrit[2][3][4]. We are starting to use both dev and operators mailing list in order to give the community a way to provide feedback, keep up with our progress and intentions. Meanwhile we have been heavily using IRC for cooperation. The #cloudkitty IRC channel on freenode is logged and the channel is notified of such logging [5]. Community members, core developers and users gather here to discuss about the future of the project as well as questions regarding usage. We have recently booked a slot on #openstack-meeting-3 in for our regular meetings. CloudKitty has been initiated by a single company but since then we have received several patches, and reviews from exterior contributors both originating from different companies and unaffiliated. Actually the whole design of CloudKitty has been improved and decided during regular IRC meetings that have been held by contibutors from many companies in order to reflect their needs and usages. We are aware that CloudKitty has been used in production by several Cloud User (both Cloud Public or Private) for several months. [1]https://wiki.openstack.org/wiki/CloudKitty [2]https://review.openstack.org/#/q/project:stackforge/cloudkitty,n,z [3]https://review.openstack.org/#/q/project:stackforge/python-cloudkittyclient,n,z [4]https://review.openstack.org/#/q/project:stackforge/cloudkitty-dashboard,n,z [5]http://eavesdrop.openstack.org/irclogs/%23cloudkitty/ Change-Id: I1864953db026832e8c40707e212db0ef179fe480
2015-09-18 17:27:54 +02:00
irc-channel: cloudkitty
service: Rating service
mission: >
CloudKitty is a rating component for OpenStack. Its goal is to process data
from different metric backends and implement rating rule creation. Its role
is to fit in-between the raw metrics from OpenStack and the billing system
of a provider for chargeback purposes.
url: https://wiki.openstack.org/wiki/CloudKitty
deliverables:
cloudkitty:
repos:
Fixed old references to stackforge for cloudkitty Closes-Bug: #1514012 Change-Id: Ia44bf4c8c9d9d5f48b64b5a0180ca983446ceb16
2015-11-07 22:36:04 +09:00
- openstack/cloudkitty
CloudKitty application for Big Tent This is a request to add CloudKitty [1] to the Big Tent. CloudKitty is a rating as a Service component aimed at easing integration of OpenStack with existing billing systems. It consumes data from metric systems (ceilometer for example) and with the help of rating plugins and client defined rules, generates prices for the different services. The project is fully licensed under the Apache 2.0 license, and has been actively promoted during the last 2 cycles including a presentation at Vancouver summit, and another on stage presentation. Stéphane Albert is currently acting as PTL. He has been working on the project since the first POC shown at the OpenStack Summit Atlanta. We plan on holding an official PTL election around the Tokyo summit. All code changes are approved by the core members. CloudKitty code is submitted and reviewed using the OpenStack infrastructure and gated through gerrit[2][3][4]. We are starting to use both dev and operators mailing list in order to give the community a way to provide feedback, keep up with our progress and intentions. Meanwhile we have been heavily using IRC for cooperation. The #cloudkitty IRC channel on freenode is logged and the channel is notified of such logging [5]. Community members, core developers and users gather here to discuss about the future of the project as well as questions regarding usage. We have recently booked a slot on #openstack-meeting-3 in for our regular meetings. CloudKitty has been initiated by a single company but since then we have received several patches, and reviews from exterior contributors both originating from different companies and unaffiliated. Actually the whole design of CloudKitty has been improved and decided during regular IRC meetings that have been held by contibutors from many companies in order to reflect their needs and usages. We are aware that CloudKitty has been used in production by several Cloud User (both Cloud Public or Private) for several months. [1]https://wiki.openstack.org/wiki/CloudKitty [2]https://review.openstack.org/#/q/project:stackforge/cloudkitty,n,z [3]https://review.openstack.org/#/q/project:stackforge/python-cloudkittyclient,n,z [4]https://review.openstack.org/#/q/project:stackforge/cloudkitty-dashboard,n,z [5]http://eavesdrop.openstack.org/irclogs/%23cloudkitty/ Change-Id: I1864953db026832e8c40707e212db0ef179fe480
2015-09-18 17:27:54 +02:00
python-cloudkittyclient:
repos:
Fixed old references to stackforge for cloudkitty Closes-Bug: #1514012 Change-Id: Ia44bf4c8c9d9d5f48b64b5a0180ca983446ceb16
2015-11-07 22:36:04 +09:00
- openstack/python-cloudkittyclient
CloudKitty application for Big Tent This is a request to add CloudKitty [1] to the Big Tent. CloudKitty is a rating as a Service component aimed at easing integration of OpenStack with existing billing systems. It consumes data from metric systems (ceilometer for example) and with the help of rating plugins and client defined rules, generates prices for the different services. The project is fully licensed under the Apache 2.0 license, and has been actively promoted during the last 2 cycles including a presentation at Vancouver summit, and another on stage presentation. Stéphane Albert is currently acting as PTL. He has been working on the project since the first POC shown at the OpenStack Summit Atlanta. We plan on holding an official PTL election around the Tokyo summit. All code changes are approved by the core members. CloudKitty code is submitted and reviewed using the OpenStack infrastructure and gated through gerrit[2][3][4]. We are starting to use both dev and operators mailing list in order to give the community a way to provide feedback, keep up with our progress and intentions. Meanwhile we have been heavily using IRC for cooperation. The #cloudkitty IRC channel on freenode is logged and the channel is notified of such logging [5]. Community members, core developers and users gather here to discuss about the future of the project as well as questions regarding usage. We have recently booked a slot on #openstack-meeting-3 in for our regular meetings. CloudKitty has been initiated by a single company but since then we have received several patches, and reviews from exterior contributors both originating from different companies and unaffiliated. Actually the whole design of CloudKitty has been improved and decided during regular IRC meetings that have been held by contibutors from many companies in order to reflect their needs and usages. We are aware that CloudKitty has been used in production by several Cloud User (both Cloud Public or Private) for several months. [1]https://wiki.openstack.org/wiki/CloudKitty [2]https://review.openstack.org/#/q/project:stackforge/cloudkitty,n,z [3]https://review.openstack.org/#/q/project:stackforge/python-cloudkittyclient,n,z [4]https://review.openstack.org/#/q/project:stackforge/cloudkitty-dashboard,n,z [5]http://eavesdrop.openstack.org/irclogs/%23cloudkitty/ Change-Id: I1864953db026832e8c40707e212db0ef179fe480
2015-09-18 17:27:54 +02:00
cloudkitty-dashboard:
repos:
Fixed old references to stackforge for cloudkitty Closes-Bug: #1514012 Change-Id: Ia44bf4c8c9d9d5f48b64b5a0180ca983446ceb16
2015-11-07 22:36:04 +09:00
- openstack/cloudkitty-dashboard
Add specs repository for CloudKitty Change-Id: Ie5656a789a9af999c713d39954320f73d2965a0c Depends-On: Ie76b6383b946242b77c4175957a05c25eebe972a
2016-11-23 17:23:12 +01:00
cloudkitty-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add specs repository for CloudKitty Change-Id: Ie5656a789a9af999c713d39954320f73d2965a0c Depends-On: Ie76b6383b946242b77c4175957a05c25eebe972a
2016-11-23 17:23:12 +01:00
repos:
- openstack/cloudkitty-specs
Add CloudKitty Tempest plugin Add a repo for the CloudKitty tempest plugin. Depends-On: I4be1ea94e023d36327a0ca19f07b6af3cbec59a0 Change-Id: Ie4396ee9a204fd9607e1ec65481be9fd4194b2ca
2017-10-31 14:39:47 +01:00
cloudkitty-tempest-plugin:
repos:
- openstack/cloudkitty-tempest-plugin
Cyborg Application For Official Projects First of all thanks for TC audience for our project update at PTG. The overview slide presented at the meeting could be found here[0]. **What is Cyborg** Cyborg is a new project that aims to provide a general management framework for accelerators[1], such as FPGA, GPU, ARM SoCs, NVMe SSDs,DPDK/SPDK,eBPF/XDP and so forth, basically any types of dedicated hardware/software that designed specifically to accelerate the performance of the general computing infrastructure. **Motivation** The motivation behind Cyborg projects orginally came from NFV in Telco, and later on more from Scientific WG on HPC and public cloud providers who want to provide FPGA/GPU instances. Details of the requirement for Cyborg could be found in the slide[0] **Two Important Facts** - Cyborg is started from scratch within the community, which means there was no code dump from vendor and we wrote every specs and code implement- ation from zero in an OpenStack way. - Every decision in Cyborg project is done through election/voting, even the project name was voted from team members. **One More Fun Fact** * We have the LONGEST team meeting in OpenStack (meeting starts late in China timezone and often left open since the organizer passed out on desk, we are working hard to improve on that :) ) **Functionality** Cyborg's two main jobs are resource discovery and life cycle management, which means Cyborg leaves the functionality of scheduling entirely to Nova when the user needs a virtual machine deployment, or Kubernetes/Mesos /Docker if the user needs container solution running on baremetal. **Cross Projects Relationship** As mentioned above, Cyborg interacts with Nova via Placement. Cyborg does not reinvent any wheels or tries to drop in to replace any current modules. It heavily relies on working with the current OpenStack structure. Nova's FPGA/GPU support is very critical for Cyborg to be able to work for VM related deployments. In short, after cyborg-agent performed resource discovery operation via various drivers it connects to, it reports the accelerator resource info to Placement. Placement will then provide an aggregate view of both general and accelerator resource for Nova scheduler. When Nova successfully spawn an instance on a compute node with accelerator, nova will notify cyborg and cyborg-api will notify cyborg-db to change the resource status from "available" to "in use", similar to the Nova-Cinder interaction for volume. Cyborg has constant discussion with the Nova/Placement team and we will continue to do so in Queens and following cycles to make sure we got an awesome collaboration. Cyborg has also very good relationship with the Scientific WG and OPNFV DPACC project. We gathered inputs/requirements from these groups. **Scenario/Usage** To put it very simply, if you have just one type of accelerator, you could just use what Nova provides for PCI-passthrough functionalities. If you have more than one types of accelerators, or you have one type of accelerator but you want fine grained control, then you probably needs Cyborg on the side to help you manage them, working alongside Nova. **Community Principle Compliance** Cyborg project follows the core principle of "Four Opens" within OpenStack Community: * Open Source This goes without saying, all the Cyborg source code could be found at OpenStack repo[2] or its github mirror[3], including feature codes, documentations[4] and tests[5]. Apache Lisence 2.0 is applied as usual. * Open Design As mentioned above, Cyborg is designed from ground up within the community. We have weekly team meetings[6] at #openstack-cyborg and public available/ searchable meeting logs[7]. We have organized PTG design sessions for each of the past ones[8][9]. We have also used [acceleration] or [cyborg] for mailinglist discussion. * Open Community Cyborg has a truely diverse team composition with no single vendor dominance[10]. PTL of Cyborg comes from Huawei and current two core reviewers come from RedHat and Lenovo. We have also gone through election/voting for these positions[11][12]. * Open Development All of the Cyborg pacthes could be found here[13]. We have a implicit policy of the core that landed the patch should comes from a different company of the ones that submit the patches. We try to review the patches as thorough as possible and we are honored to have people from other team help reviewing, for example[14][15]. Cyborg team also tries to utilize all the available community infrastructure, e.g CI/CD[16] The Cyborg project team has been doing everything according to the community's tradition and best practices. Although it is far from perfect, we believe it is on the right track. We also believe that by putting Cyborg under official governance, it will show OpenStack's capability on heterogeneous computing that provides the foundation for AI, Machine Learning, HPC, NFV and many other cutting-edge technologies. 0. https://docs.google.com/presentation/d/1RyDDVMBsQndN-Qo_JInnHaj_oCY6zwT_3ky_gk1nJMo/edit?usp=sharing 1. https://wiki.openstack.org/wiki/Cyborg 2. https://review.openstack.org/gitweb?p=openstack/cyborg.git;a=summary 3. https://github.com/openstack/cyborg 4. https://github.com/openstack/cyborg/tree/master/doc/source 5. https://github.com/openstack/cyborg/tree/master/cyborg/tests 6. https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting 7. https://wiki.openstack.org/wiki/Cyborg/MeetingLogs 8. https://etherpad.openstack.org/p/cyborg-ptg-pike 9. https://etherpad.openstack.org/p/cyborg-queens-ptg 10. http://stackalytics.com/?project_type=openstack-others&module=cyborg&metric=person-day&release=all 11. https://openstack.nimeyo.com/113991/openstack-cyborg-nominate-rushil-justin-kilpatrick-reviewers 12. https://openstack.nimeyo.com/117806/openstack-dev-cyborg-queens-ptl-candidacy?show=117812 13. https://review.openstack.org/#/q/project:openstack/cyborg 14. https://review.openstack.org/#/c/448228/ 15. https://review.openstack.org/#/c/445814/ 16. https://review.openstack.org/#/c/504141/ Change-Id: If0679c80f72f48cbe5fbc50c0a182661e97793fe Signed-off-by: zhipengh <huangzhipeng@huawei.com>
2017-09-13 16:04:01 -06:00
cyborg:
ptl:
Add PTL results from the 2024.2/Dalmatian election Depends-On: If6c157efebc58d1fbe32a61a64f209b4102ac5c8 Change-Id: Ic74bfc853d2d9d045d4c589e1fd6c50afa608423
2024-03-22 09:00:21 +09:00
name: alex song
Appoint Alex Song as PTL of Cyborg Change-Id: I98e699c5a8f8163667640796e7fcd8b786666378
2023-11-01 15:15:25 +08:00
irc: songwenping
email: songwenping@inspur.com
Appoint Sundar Nadathur as Cyborg PTL Change-Id: I30d35695b35b002cdf2fb2826b3d1a7d76509250 Signed-off-by: Graham Hayes <gr@ham.ie>
2019-09-05 15:30:03 +01:00
appointed:
- ussuri
Appoint Xinran Wang as Cyborg PTL Xinran Wang sent their late candidacy for Cyborg PTL position of Xena Cycle - https://review.opendev.org/c/openstack/election/+/779911 Change-Id: If778b0e878a00b9498a75a5ef74bd78574854ddc
2021-03-11 13:22:43 -06:00
- xena
Add TC/PTL results from 2025.1 election Also clear out existing TC roles and prepare for nominations. Depends-On: Id5847c7c37d556b11932dae542f4aaeb699cf7ec Change-Id: I7760c815d032c7aaff9956588b6ce5c1fb7b4750
2024-09-19 23:17:25 +09:00
- '2024.1'
Cyborg Application For Official Projects First of all thanks for TC audience for our project update at PTG. The overview slide presented at the meeting could be found here[0]. **What is Cyborg** Cyborg is a new project that aims to provide a general management framework for accelerators[1], such as FPGA, GPU, ARM SoCs, NVMe SSDs,DPDK/SPDK,eBPF/XDP and so forth, basically any types of dedicated hardware/software that designed specifically to accelerate the performance of the general computing infrastructure. **Motivation** The motivation behind Cyborg projects orginally came from NFV in Telco, and later on more from Scientific WG on HPC and public cloud providers who want to provide FPGA/GPU instances. Details of the requirement for Cyborg could be found in the slide[0] **Two Important Facts** - Cyborg is started from scratch within the community, which means there was no code dump from vendor and we wrote every specs and code implement- ation from zero in an OpenStack way. - Every decision in Cyborg project is done through election/voting, even the project name was voted from team members. **One More Fun Fact** * We have the LONGEST team meeting in OpenStack (meeting starts late in China timezone and often left open since the organizer passed out on desk, we are working hard to improve on that :) ) **Functionality** Cyborg's two main jobs are resource discovery and life cycle management, which means Cyborg leaves the functionality of scheduling entirely to Nova when the user needs a virtual machine deployment, or Kubernetes/Mesos /Docker if the user needs container solution running on baremetal. **Cross Projects Relationship** As mentioned above, Cyborg interacts with Nova via Placement. Cyborg does not reinvent any wheels or tries to drop in to replace any current modules. It heavily relies on working with the current OpenStack structure. Nova's FPGA/GPU support is very critical for Cyborg to be able to work for VM related deployments. In short, after cyborg-agent performed resource discovery operation via various drivers it connects to, it reports the accelerator resource info to Placement. Placement will then provide an aggregate view of both general and accelerator resource for Nova scheduler. When Nova successfully spawn an instance on a compute node with accelerator, nova will notify cyborg and cyborg-api will notify cyborg-db to change the resource status from "available" to "in use", similar to the Nova-Cinder interaction for volume. Cyborg has constant discussion with the Nova/Placement team and we will continue to do so in Queens and following cycles to make sure we got an awesome collaboration. Cyborg has also very good relationship with the Scientific WG and OPNFV DPACC project. We gathered inputs/requirements from these groups. **Scenario/Usage** To put it very simply, if you have just one type of accelerator, you could just use what Nova provides for PCI-passthrough functionalities. If you have more than one types of accelerators, or you have one type of accelerator but you want fine grained control, then you probably needs Cyborg on the side to help you manage them, working alongside Nova. **Community Principle Compliance** Cyborg project follows the core principle of "Four Opens" within OpenStack Community: * Open Source This goes without saying, all the Cyborg source code could be found at OpenStack repo[2] or its github mirror[3], including feature codes, documentations[4] and tests[5]. Apache Lisence 2.0 is applied as usual. * Open Design As mentioned above, Cyborg is designed from ground up within the community. We have weekly team meetings[6] at #openstack-cyborg and public available/ searchable meeting logs[7]. We have organized PTG design sessions for each of the past ones[8][9]. We have also used [acceleration] or [cyborg] for mailinglist discussion. * Open Community Cyborg has a truely diverse team composition with no single vendor dominance[10]. PTL of Cyborg comes from Huawei and current two core reviewers come from RedHat and Lenovo. We have also gone through election/voting for these positions[11][12]. * Open Development All of the Cyborg pacthes could be found here[13]. We have a implicit policy of the core that landed the patch should comes from a different company of the ones that submit the patches. We try to review the patches as thorough as possible and we are honored to have people from other team help reviewing, for example[14][15]. Cyborg team also tries to utilize all the available community infrastructure, e.g CI/CD[16] The Cyborg project team has been doing everything according to the community's tradition and best practices. Although it is far from perfect, we believe it is on the right track. We also believe that by putting Cyborg under official governance, it will show OpenStack's capability on heterogeneous computing that provides the foundation for AI, Machine Learning, HPC, NFV and many other cutting-edge technologies. 0. https://docs.google.com/presentation/d/1RyDDVMBsQndN-Qo_JInnHaj_oCY6zwT_3ky_gk1nJMo/edit?usp=sharing 1. https://wiki.openstack.org/wiki/Cyborg 2. https://review.openstack.org/gitweb?p=openstack/cyborg.git;a=summary 3. https://github.com/openstack/cyborg 4. https://github.com/openstack/cyborg/tree/master/doc/source 5. https://github.com/openstack/cyborg/tree/master/cyborg/tests 6. https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting 7. https://wiki.openstack.org/wiki/Cyborg/MeetingLogs 8. https://etherpad.openstack.org/p/cyborg-ptg-pike 9. https://etherpad.openstack.org/p/cyborg-queens-ptg 10. http://stackalytics.com/?project_type=openstack-others&module=cyborg&metric=person-day&release=all 11. https://openstack.nimeyo.com/113991/openstack-cyborg-nominate-rushil-justin-kilpatrick-reviewers 12. https://openstack.nimeyo.com/117806/openstack-dev-cyborg-queens-ptl-candidacy?show=117812 13. https://review.openstack.org/#/q/project:openstack/cyborg 14. https://review.openstack.org/#/c/448228/ 15. https://review.openstack.org/#/c/445814/ 16. https://review.openstack.org/#/c/504141/ Change-Id: If0679c80f72f48cbe5fbc50c0a182661e97793fe Signed-off-by: zhipengh <huangzhipeng@huawei.com>
2017-09-13 16:04:01 -06:00
irc-channel: openstack-cyborg
service: Accelerator Life Cycle Management
mission: >
To provide a general management framework for accelerators (FPGA,GPU,SoC,
NVMe SSD,DPDK/SPDK,eBPF/XDP ...)
url: https://wiki.openstack.org/wiki/Cyborg
deliverables:
cyborg:
repos:
- openstack/cyborg
Add Cyborg-specs repository to the governance repository Change-Id: Id38deb86dde3dcd99f9147122705127b47cb4f66 Depends-On: https://review.openstack.org/553975
2018-03-17 19:16:58 +08:00
cyborg-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add Cyborg-specs repository to the governance repository Change-Id: Id38deb86dde3dcd99f9147122705127b47cb4f66 Depends-On: https://review.openstack.org/553975
2018-03-17 19:16:58 +08:00
repos:
- openstack/cyborg-specs
Add python-cyborgclient repository to the governance repository Depends-On: https://review.openstack.org/555707 Change-Id: Ic8d8fd6bc3c763a3d98476d7bd968c9955c32986
2018-03-23 09:16:32 +00:00
python-cyborgclient:
repos:
- openstack/python-cyborgclient
Add cyborg-tempest-plugin repository to the governance repository Depends-On:https://review.opendev.org/#/c/657764/ Change-Id: I0a95bb44b6d2df02ae249908e18d45a11257d076
2019-05-08 02:38:51 -07:00
cyborg-tempest-plugin:
repos:
- openstack/cyborg-tempest-plugin
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
designate:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Record Wallaby Cycle PTL and TC election results This reflects the results of the elections held for PTL and TC positions in October 2020. Depends-On: https://review.opendev.org/757967 Change-Id: I037de61dddf30d9febfea5e819603040e0ccddd2
2020-10-14 00:43:41 +00:00
name: Michael Johnson
irc: johnsom
email: johnsomor@gmail.com
Appointing Nicolas Bock as Designate PTL Signed-Off By: Alexandra Settle <asettle@suse.com> SIgned-Off By: Graham Hayes <gr@ham.ie> Change-Id: I0669fd18f90a8a0f6fa97428da9a49a8b033c94a
2019-09-18 12:57:12 +01:00
appointed:
- ussuri
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
service: DNS service
add designate team's irc channel Change-Id: I906ba5b98aef443cce71cdbfc1739a06f817d954 Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2016-03-18 09:46:05 -04:00
irc-channel: openstack-dns
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
mission: >
To provide scalable, on demand, self service access to authoritative DNS
services, in technology-agnostic manner.
url: https://wiki.openstack.org/wiki/Designate
deliverables:
designate:
repos:
- openstack/designate
Move Designate-Dashbaord to its own deliverable To keep in line with other dashboard plugins move designate-dashboard to its own deliverable, and add the type:horizon-plugin Change-Id: I74902138936e566b79500dcddd1a2aab5b550bd2
2016-06-24 18:18:44 +01:00
designate-dashboard:
repos:
- openstack/designate-dashboard
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
designate-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/designate-specs
Add openstack/designate-tempest to Designate project Change-Id: I17daf5d31396bbcd02b1c791f232807b22786be5 Depends-On: Ica5c6156e6ae38e02167b9be7fc9bc7520723204
2016-04-04 17:14:06 +01:00
designate-tempest-plugin:
repos:
- openstack/designate-tempest-plugin
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-designateclient:
repos:
- openstack/python-designateclient
Freezer application to join the Big Tent Mission and Vision: To provide tools for managing backup/restore and disaster recovery. Full version available here [0]. The temporary PTL is Fausto Marzi. Starting from April a new PTL will be elected by using the standard OpenStack mechanism and timeline [1] The #openstack-freezer IRC channel on freenode is logged and the channel is notified of such logging [2]. Our public meeting logs are stored [3]. Many design aspect has been defined at the Vancouver Summit [4]. The project uses public code reviews on the OpenStack infrastructure. A part the first 2-3 months of the project creation, Freezer has been using the +2/+A process requiring two unique core reviewers to review a patch. Our gating runs pep8, pylint and other unittest and integration tests. In the last weeks a Devstack plugin was also implemented [5]. Currently there is a dedicated Team working on Freezer from one of the top 3 Company contributors in OpenStack. There are also external contributors to the project [6]. As this is a new project the number of contributors is not huge, but there is a strong interest everywhere and the feedback from the community was always positive and encouraging. Freezer uses IRC and OpenStack related ML for all the communications. We are doing all our best to make this project useful and successfull for the whole OpenStack Community. Freezer Project repositories: - https://github.com/openstack/freezer/ - https://github.com/openstack/freezer-api - https://github.com/openstack/freezer-web-ui [0] https://etherpad.openstack.org/p/freezer-manifesto [1] https://wiki.openstack.org/wiki/PTL_Elections_April_2015 [2] http://eavesdrop.openstack.org/irclogs/%23openstack-freezer/ [3] https://etherpad.openstack.org/p/freezer_meetings [4] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/freezer-the-openstack-back-up-as-a-service-platform [5] https://review.openstack.org/#/c/233683/ [6] http://stackalytics.com/?project_type=openstack-others&release=all&metric=commits&module=freezer Change-Id: Ice43efe6f1e6691d44730ec38f38479780af49a8
2015-10-27 11:04:42 +00:00
freezer:
Re-initiate the DPL model for Freezer project Due to decision for resetting DPL model each cycle, I'm opting-in for the DPL model for Freezer project for the next cycle as well. Change-Id: I521eaeef9eecf549fbf376c05ddaef3a15ca34c6
2024-08-08 18:35:51 +02:00
leadership_type: distributed
liaisons:
release:
- name: Dmitriy Rabotyagov
irc: noonedeadpunk
email: noonedeadpunk@gmail.com
tact-sig:
- name: Dmitriy Rabotyagov
irc: noonedeadpunk
email: noonedeadpunk@gmail.com
security:
- name: Alvaro Soto
irc: khyr0n
email: alsotoes@gmail.com
tc-liaison:
- name: Ghanshyam Mann
irc: gmann
email: gmann@ghanshyammann.com
- name: Dmitriy Rabotyagov
irc: noonedeadpunk
email: noonedeadpunk@gmail.com
mark Changcai Geng as appointed PTL for Freezer This differentiates the appointment from a regular election. Change-Id: I756ffc7e4e6555a3deb94cc101fc41eddc615e80 Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2018-08-13 13:40:21 -04:00
appointed:
- stein
Appoint ge cong as Freezer PTL ge cong confirmed to lead Freezer project as PTL for zed cycle - https://etherpad.opendev.org/p/zed-leaderless Change-Id: I6995670a346a30fccd44ebb87271d20840c08694
2022-02-27 19:19:35 -06:00
- zed
Freezer application to join the Big Tent Mission and Vision: To provide tools for managing backup/restore and disaster recovery. Full version available here [0]. The temporary PTL is Fausto Marzi. Starting from April a new PTL will be elected by using the standard OpenStack mechanism and timeline [1] The #openstack-freezer IRC channel on freenode is logged and the channel is notified of such logging [2]. Our public meeting logs are stored [3]. Many design aspect has been defined at the Vancouver Summit [4]. The project uses public code reviews on the OpenStack infrastructure. A part the first 2-3 months of the project creation, Freezer has been using the +2/+A process requiring two unique core reviewers to review a patch. Our gating runs pep8, pylint and other unittest and integration tests. In the last weeks a Devstack plugin was also implemented [5]. Currently there is a dedicated Team working on Freezer from one of the top 3 Company contributors in OpenStack. There are also external contributors to the project [6]. As this is a new project the number of contributors is not huge, but there is a strong interest everywhere and the feedback from the community was always positive and encouraging. Freezer uses IRC and OpenStack related ML for all the communications. We are doing all our best to make this project useful and successfull for the whole OpenStack Community. Freezer Project repositories: - https://github.com/openstack/freezer/ - https://github.com/openstack/freezer-api - https://github.com/openstack/freezer-web-ui [0] https://etherpad.openstack.org/p/freezer-manifesto [1] https://wiki.openstack.org/wiki/PTL_Elections_April_2015 [2] http://eavesdrop.openstack.org/irclogs/%23openstack-freezer/ [3] https://etherpad.openstack.org/p/freezer_meetings [4] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/freezer-the-openstack-back-up-as-a-service-platform [5] https://review.openstack.org/#/c/233683/ [6] http://stackalytics.com/?project_type=openstack-others&release=all&metric=commits&module=freezer Change-Id: Ice43efe6f1e6691d44730ec38f38479780af49a8
2015-10-27 11:04:42 +00:00
irc-channel: openstack-freezer
Standardizes name of freezer service to match conventions Change-Id: I2ed591dd824ec789bb26e9ac727b14c5e4f06ce3 Reference: http://governance.openstack.org/reference/service-project-naming.html#service-name-guidelines
2015-11-25 07:39:33 -06:00
service: Backup, Restore, and Disaster Recovery service
Freezer application to join the Big Tent Mission and Vision: To provide tools for managing backup/restore and disaster recovery. Full version available here [0]. The temporary PTL is Fausto Marzi. Starting from April a new PTL will be elected by using the standard OpenStack mechanism and timeline [1] The #openstack-freezer IRC channel on freenode is logged and the channel is notified of such logging [2]. Our public meeting logs are stored [3]. Many design aspect has been defined at the Vancouver Summit [4]. The project uses public code reviews on the OpenStack infrastructure. A part the first 2-3 months of the project creation, Freezer has been using the +2/+A process requiring two unique core reviewers to review a patch. Our gating runs pep8, pylint and other unittest and integration tests. In the last weeks a Devstack plugin was also implemented [5]. Currently there is a dedicated Team working on Freezer from one of the top 3 Company contributors in OpenStack. There are also external contributors to the project [6]. As this is a new project the number of contributors is not huge, but there is a strong interest everywhere and the feedback from the community was always positive and encouraging. Freezer uses IRC and OpenStack related ML for all the communications. We are doing all our best to make this project useful and successfull for the whole OpenStack Community. Freezer Project repositories: - https://github.com/openstack/freezer/ - https://github.com/openstack/freezer-api - https://github.com/openstack/freezer-web-ui [0] https://etherpad.openstack.org/p/freezer-manifesto [1] https://wiki.openstack.org/wiki/PTL_Elections_April_2015 [2] http://eavesdrop.openstack.org/irclogs/%23openstack-freezer/ [3] https://etherpad.openstack.org/p/freezer_meetings [4] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/freezer-the-openstack-back-up-as-a-service-platform [5] https://review.openstack.org/#/c/233683/ [6] http://stackalytics.com/?project_type=openstack-others&release=all&metric=commits&module=freezer Change-Id: Ice43efe6f1e6691d44730ec38f38479780af49a8
2015-10-27 11:04:42 +00:00
mission: >
Rewording Freezer mission Now the freezer mission is more coincise and clear, according to feedback and conversation with TC. Change-Id: I36c3f61edd1413cb6c80f4b8b24701d4a06a3c2d
2015-12-07 14:56:20 +00:00
To provide integrated tools for backing up and restoring cloud data in
multiple use cases, including disaster recovery. These resources include
file systems, server instances, volumes, and databases.
Freezer application to join the Big Tent Mission and Vision: To provide tools for managing backup/restore and disaster recovery. Full version available here [0]. The temporary PTL is Fausto Marzi. Starting from April a new PTL will be elected by using the standard OpenStack mechanism and timeline [1] The #openstack-freezer IRC channel on freenode is logged and the channel is notified of such logging [2]. Our public meeting logs are stored [3]. Many design aspect has been defined at the Vancouver Summit [4]. The project uses public code reviews on the OpenStack infrastructure. A part the first 2-3 months of the project creation, Freezer has been using the +2/+A process requiring two unique core reviewers to review a patch. Our gating runs pep8, pylint and other unittest and integration tests. In the last weeks a Devstack plugin was also implemented [5]. Currently there is a dedicated Team working on Freezer from one of the top 3 Company contributors in OpenStack. There are also external contributors to the project [6]. As this is a new project the number of contributors is not huge, but there is a strong interest everywhere and the feedback from the community was always positive and encouraging. Freezer uses IRC and OpenStack related ML for all the communications. We are doing all our best to make this project useful and successfull for the whole OpenStack Community. Freezer Project repositories: - https://github.com/openstack/freezer/ - https://github.com/openstack/freezer-api - https://github.com/openstack/freezer-web-ui [0] https://etherpad.openstack.org/p/freezer-manifesto [1] https://wiki.openstack.org/wiki/PTL_Elections_April_2015 [2] http://eavesdrop.openstack.org/irclogs/%23openstack-freezer/ [3] https://etherpad.openstack.org/p/freezer_meetings [4] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/freezer-the-openstack-back-up-as-a-service-platform [5] https://review.openstack.org/#/c/233683/ [6] http://stackalytics.com/?project_type=openstack-others&release=all&metric=commits&module=freezer Change-Id: Ice43efe6f1e6691d44730ec38f38479780af49a8
2015-10-27 11:04:42 +00:00
url: https://wiki.openstack.org/wiki/Freezer
deliverables:
freezer:
repos:
- openstack/freezer
- openstack/freezer-api
Add specs repo to Freezer Depends-On: I81bd93d2140f0f8945ca54c5d93b0f0da5985932 Change-Id: I1011485f6037597623499249fc1009299f21c5fb
2016-03-02 09:26:13 +00:00
freezer-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add specs repo to Freezer Depends-On: I81bd93d2140f0f8945ca54c5d93b0f0da5985932 Change-Id: I1011485f6037597623499249fc1009299f21c5fb
2016-03-02 09:26:13 +00:00
repos:
- openstack/freezer-specs
Added freezer-tempest-plugin repo for freezer Change-Id: I8454d2b6949d8f54156fc0f6f1317603e7edec7f Depends-On: I9f3b200700363810a61ebf12dfe4eed1f4613be4
2017-06-19 12:46:46 +01:00
freezer-tempest-plugin:
repos:
- openstack/freezer-tempest-plugin
Freezer application to join the Big Tent Mission and Vision: To provide tools for managing backup/restore and disaster recovery. Full version available here [0]. The temporary PTL is Fausto Marzi. Starting from April a new PTL will be elected by using the standard OpenStack mechanism and timeline [1] The #openstack-freezer IRC channel on freenode is logged and the channel is notified of such logging [2]. Our public meeting logs are stored [3]. Many design aspect has been defined at the Vancouver Summit [4]. The project uses public code reviews on the OpenStack infrastructure. A part the first 2-3 months of the project creation, Freezer has been using the +2/+A process requiring two unique core reviewers to review a patch. Our gating runs pep8, pylint and other unittest and integration tests. In the last weeks a Devstack plugin was also implemented [5]. Currently there is a dedicated Team working on Freezer from one of the top 3 Company contributors in OpenStack. There are also external contributors to the project [6]. As this is a new project the number of contributors is not huge, but there is a strong interest everywhere and the feedback from the community was always positive and encouraging. Freezer uses IRC and OpenStack related ML for all the communications. We are doing all our best to make this project useful and successfull for the whole OpenStack Community. Freezer Project repositories: - https://github.com/openstack/freezer/ - https://github.com/openstack/freezer-api - https://github.com/openstack/freezer-web-ui [0] https://etherpad.openstack.org/p/freezer-manifesto [1] https://wiki.openstack.org/wiki/PTL_Elections_April_2015 [2] http://eavesdrop.openstack.org/irclogs/%23openstack-freezer/ [3] https://etherpad.openstack.org/p/freezer_meetings [4] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/freezer-the-openstack-back-up-as-a-service-platform [5] https://review.openstack.org/#/c/233683/ [6] http://stackalytics.com/?project_type=openstack-others&release=all&metric=commits&module=freezer Change-Id: Ice43efe6f1e6691d44730ec38f38479780af49a8
2015-10-27 11:04:42 +00:00
freezer-web-ui:
repos:
- openstack/freezer-web-ui
Add python-freezerclient repo Change-Id: I0d2ca6623c81185ab8443ade7d0234e4ded63d7f Depends-On: I8441d5bf0e3dcbb679eb39ad29bf89cd957f37c4
2016-03-21 10:28:15 +00:00
python-freezerclient:
repos:
- openstack/python-freezerclient
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
glance:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Close Antelope Elections Reflects election result to governance repo : https://review.opendev.org/c/openstack/election/+/858532 Change-Id: Ic4f80855d784f9bf104f0f982fc8f265544d961f
2022-09-20 23:24:42 +09:00
name: Pranali Deore
irc: pdeore
email: pdeore@redhat.com
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-glance
service: Image service
Add mission statement for project 'Heat' Change-Id: I1e43f6c532b189fbc0ceb3187e1bc320f3aa5a7f
2015-02-09 15:02:52 +01:00
mission: >
Update Glance mission statement It was announced that the existing Glance artifact code would be spun out to a new project, "Glare": http://lists.openstack.org/pipermail/openstack-dev/2016-August/100862.html Since generic 'data assets' (Heat templates, etc.) will be artifacts served by Glare, not Glance, it makes sense to update the mission statement. Change-Id: I71f1f3326c5223a7d95b70bcf6cbd6c5e8bba6bf
2016-08-11 12:28:53 +00:00
To provide services and associated libraries to store, browse, share,
distribute and manage bootable disk images, other data closely associated
with initializing compute resources, and metadata definitions.
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
url: https://wiki.openstack.org/wiki/Glance
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
glance:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/glance
glance-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/glance-specs
Add glance-tempest-plugin to Glance Creating new repository for glance tempest plugin Depends-On: I2f112fca07bb175fa947e15e8bb7729a11de9029 Change-Id: I91841f491bd75a8d53a5dc1f551bf091f5c9178e
2020-12-18 06:11:50 +00:00
glance-tempest-plugin:
repos:
- openstack/glance-tempest-plugin
Change glance-store name to match launchpad project When glance-store was created in launchpad [1], we could not create a project with '_' in it's name due to launchpad constraints. This commit modifies the reference to reflect the name of the project to match that of the launchpad name. This is also important as the release team refers to the project to match the launchpad name and then asks for the repo name separately. `glance-store` launchpad project uses openstack/glance_store repo [2] for it's development. This governance change is thus required to unblock release of the glance_store library. Release team README [3] referring launchpad project name requirement as of July 18th 2016. [1] https://bugs.launchpad.net/glance-store [2] http://git.openstack.org/cgit/openstack/glance_store/ [3] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n153 Change-Id: Idd3f57672466b894d4f33be1a22a4e725e562970
2016-07-18 14:37:09 -04:00
glance-store:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/glance_store
Add os-test-images under glance Change-Id: I9a4356ad250d16e8189eaaffc4da47c3fd2b640c Depends-On: https://review.opendev.org/c/openstack/project-config/+/925043
2024-07-26 12:10:23 -07:00
os-test-images:
repos:
- openstack/os-test-images
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-glanceclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-glanceclient
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
heat:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Update with 2023.2 Election results. Updates PTLs and TC members as per: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032240.html Also removes chair and vice-chair roles as this is a new TC Change-Id: I2aef6f364afeecc8bd48ce5e9fa64457c582b610
2023-02-16 11:16:15 +11:00
name: Takashi Kajinami
irc: tkajinam
Update email address of Takashi Kajinami Change-Id: I488bcaa723cc950a60d088e22afc62eb2bee75c7
2023-10-13 12:16:20 +09:00
email: kajinamit@oss.nttdata.com
Appoint Rico Lin as Heat PTL Rico Lin confirmed to server as Heat PTL position for Yoga Cycle - https://etherpad.opendev.org/p/yoga-leaderless Change-Id: I34c64b29a4075f5c938e61c72909099eb1b878b8
2021-09-08 09:44:05 -05:00
appointed:
- yoga
Appoint Rico as Heat PTL Rico volunteer to lead Heat projetc for Zed cycle - https://etherpad.opendev.org/p/zed-leaderless Change-Id: I8bfc04b646cbeefbcbf768d6e8b255c39f13bee8
2022-02-27 18:46:56 -06:00
- zed
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: heat
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Orchestration service
use ">" to indicate multiline mission statements ">" indicates to YAML that the multiline string which follows is intended to ignore the line breaks contained within. Also includes some related whitespace cleanup. Change-Id: I6403c1d5663f9575c0d6ada2f1e672e743e451f3
2014-07-23 10:40:47 -05:00
mission: >
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
To orchestrate composite cloud applications using a declarative
unify REST word Representational State Transfer, by official definition the abbreviation should be *REST* not *ReST*. We should make it unified. Change-Id: I103aec138a8354a18bca6d08d88612f14b5efd99
2015-08-26 09:16:04 +08:00
template format through an OpenStack-native REST API.
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
url: https://wiki.openstack.org/wiki/Heat
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
heat:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/heat
Add heat-agents project Change-Id: Ic4da0a84282edfe77f78bb3806c26b4f342489cc Depends-On: I38cf809ac6891a6b644adefc0bb06edb1b1cc800
2017-01-03 15:19:30 +01:00
heat-agents:
repos:
- openstack/heat-agents
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
heat-cfntools:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/heat-cfntools
Add heat-dashboard to heat project Orchestraion (heat) support will be split out from the main horizon repo and maintained in the new repository under heat team. Change-Id: I71610da41505d7131ac864380d21fcb8d040b457 Depends-On: I12710886c8f98786179538a9a5dc4bacead3761a
2017-09-15 03:38:20 +09:00
heat-dashboard:
repos:
- openstack/heat-dashboard
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
heat-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/heat-specs
Add heat-tempest-plugin repo Depends-On: I8c1d6a8e78abebc2da9c94c1a2ff8597ad836a0f Change-Id: I37401c8b52d26aa939174639fe8426af988e0108
2017-11-14 13:42:28 +05:30
heat-tempest-plugin:
repos:
- openstack/heat-tempest-plugin
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
heat-templates:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/heat-templates
python-heatclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-heatclient
Move os-(apply|collect|refresh)-config to Heat's governance These agents are required to use the SoftwareDeployment resource in heat so should be maintained beyond TripleO's retirement. The feature was developed to be used by TripleO historically, but even TripleO reduced its dependency on these agents, so maintaining the agents within Heat makes more sense now. See the below mailing list post as well. https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032359.html Change-Id: I6de75eba7232c05649b8364ce6fd0d7b4bb1dd2c
2023-02-22 14:11:55 +09:00
os-apply-config:
repos:
- openstack/os-apply-config
os-collect-config:
repos:
- openstack/os-collect-config
os-refresh-config:
repos:
- openstack/os-refresh-config
Move yaql to Heat's governance The yaql library has been maintained under murano's governance, but the murano project has been inactive for several cycles. Because this library is used by heat and mistral, we have to maintain it as long as these two projects are maintained. This proposes moving the yaql project to heat's governance as the first step. Later we'll update the core reviewer of the repository so that both heat team and mistral team can maintain it. This transition was earlier proposed in the mailing list[1] but we haven't received any feedback from the murano project, unfortunately. [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/KFTPG45LEB5QYY4NELA7EQJ56MSOWULK/ Change-Id: If5d3ed3a8314a8f650cd90416b53e02a84e4ed44
2023-12-19 23:50:09 +09:00
yaql:
repos:
- openstack/yaql
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
horizon:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Add PTL results from the 2024.2/Dalmatian election Depends-On: If6c157efebc58d1fbe32a61a64f209b4102ac5c8 Change-Id: Ic74bfc853d2d9d045d4c589e1fd6c50afa608423
2024-03-22 09:00:21 +09:00
name: Tatiana Ovchinnikova
irc: tmazur
email: t.v.ovtchinnikova@gmail.com
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-horizon
service: Dashboard
use ">" to indicate multiline mission statements ">" indicates to YAML that the multiline string which follows is intended to ignore the line breaks contained within. Also includes some related whitespace cleanup. Change-Id: I6403c1d5663f9575c0d6ada2f1e672e743e451f3
2014-07-23 10:40:47 -05:00
mission: >
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
To provide an extensible unified web based user interface for all
OpenStack services.
url: https://wiki.openstack.org/wiki/Horizon
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
horizon:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/horizon
Add new project UI Cookiecutter underneath Horizon This adds the new ui-cookiecutter repos to horizon governance. Change-Id: Ic95395770392dad0631d43740e15add41092e332 Depends-On: I17d0693dd8a2cc5179bf6b41d5e58d8edbf812b9
2016-11-17 16:17:33 +09:00
ui-cookiecutter:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add new project UI Cookiecutter underneath Horizon This adds the new ui-cookiecutter repos to horizon governance. Change-Id: Ic95395770392dad0631d43740e15add41092e332 Depends-On: I17d0693dd8a2cc5179bf6b41d5e58d8edbf812b9
2016-11-17 16:17:33 +09:00
repos:
- openstack/ui-cookiecutter
Add xstatic projects to Horizon Horizon packages many of its dependencies with xstatic hosted on pypi, and they (mostly) have respective openstack projects for community review. These should be listed as valid openstack projects within governance. Change-Id: Ie03bc7bd5c4f6f9c9133e45ad3b1d37f83cb224b
2015-11-14 10:58:53 +00:00
xstatic-angular:
repos:
- openstack/xstatic-angular
xstatic-angular-bootstrap:
repos:
- openstack/xstatic-angular-bootstrap
Add xstatic-angular-fileupload as Horizon team deliverables xstatic-angular-fileupload pypi is used by Horizon. Horizon team discussed this topic in the horizon weekly meeting and decided to move it under the horizon deliverables and keep them under the OpenStack namespace [1]. We also check with moinwiki contributor and they are not using this pypi project [2]. [1] https://meetings.opendev.org/irclogs/%23openstack-horizon/%23openstack-horizon.2023-02-01.log.html#t2023-02-01T16:09:57 [2] https://github.com/moinwiki/moin/issues/1326#issuecomment-1380310586 Needed-By: https://review.opendev.org/c/openstack/project-config/+/873843 Change-Id: I8a1c1afdad7f2768e80c1efc5cdbcd914abc8e71
2023-02-15 12:37:06 +05:30
xstatic-angular-fileupload:
repos:
- openstack/xstatic-angular-fileupload
Add xstatic projects to Horizon Horizon packages many of its dependencies with xstatic hosted on pypi, and they (mostly) have respective openstack projects for community review. These should be listed as valid openstack projects within governance. Change-Id: Ie03bc7bd5c4f6f9c9133e45ad3b1d37f83cb224b
2015-11-14 10:58:53 +00:00
xstatic-angular-gettext:
repos:
- openstack/xstatic-angular-gettext
xstatic-angular-lrdragndrop:
repos:
- openstack/xstatic-angular-lrdragndrop
Add xstatic-** to horizon project To remove all embedded js copies from heat-dashboard, we need these xstatic packages projects. Change-Id: I404ec19472f1ede2c3d9c1d41eabd5710ffb21cd Depends-On: I4ed1ba3686e6e26aaf570980072344ce40977db4
2018-03-12 21:03:35 +09:00
xstatic-angular-material:
repos:
- openstack/xstatic-angular-material
xstatic-angular-notify:
repos:
- openstack/xstatic-angular-notify
Add xstatic projects to Horizon Horizon packages many of its dependencies with xstatic hosted on pypi, and they (mostly) have respective openstack projects for community review. These should be listed as valid openstack projects within governance. Change-Id: Ie03bc7bd5c4f6f9c9133e45ad3b1d37f83cb224b
2015-11-14 10:58:53 +00:00
xstatic-angular-smart-table:
repos:
- openstack/xstatic-angular-smart-table
Add xstatic-** to horizon project To remove all embedded js copies from heat-dashboard, we need these xstatic packages projects. Change-Id: I404ec19472f1ede2c3d9c1d41eabd5710ffb21cd Depends-On: I4ed1ba3686e6e26aaf570980072344ce40977db4
2018-03-12 21:03:35 +09:00
xstatic-angular-uuid:
repos:
- openstack/xstatic-angular-uuid
xstatic-angular-vis:
repos:
- openstack/xstatic-angular-vis
Add xstatic projects to Horizon Horizon packages many of its dependencies with xstatic hosted on pypi, and they (mostly) have respective openstack projects for community review. These should be listed as valid openstack projects within governance. Change-Id: Ie03bc7bd5c4f6f9c9133e45ad3b1d37f83cb224b
2015-11-14 10:58:53 +00:00
xstatic-bootstrap-datepicker:
repos:
- openstack/xstatic-bootstrap-datepicker
xstatic-bootstrap-scss:
repos:
- openstack/xstatic-bootstrap-scss
xstatic-bootswatch:
repos:
- openstack/xstatic-bootswatch
xstatic-d3:
repos:
- openstack/xstatic-d3
xstatic-hogan:
repos:
- openstack/xstatic-hogan
Add xstatic-** to horizon project To remove all embedded js copies from heat-dashboard, we need these xstatic packages projects. Change-Id: I404ec19472f1ede2c3d9c1d41eabd5710ffb21cd Depends-On: I4ed1ba3686e6e26aaf570980072344ce40977db4
2018-03-12 21:03:35 +09:00
xstatic-filesaver:
repos:
- openstack/xstatic-filesaver
Add xstatic projects to Horizon Horizon packages many of its dependencies with xstatic hosted on pypi, and they (mostly) have respective openstack projects for community review. These should be listed as valid openstack projects within governance. Change-Id: Ie03bc7bd5c4f6f9c9133e45ad3b1d37f83cb224b
2015-11-14 10:58:53 +00:00
xstatic-jasmine:
repos:
- openstack/xstatic-jasmine
xstatic-jquery-migrate:
repos:
- openstack/xstatic-jquery-migrate
xstatic-jquery.quicksearch:
repos:
- openstack/xstatic-jquery.quicksearch
xstatic-jquery.tablesorter:
repos:
- openstack/xstatic-jquery.tablesorter
Add xstatic-** to horizon project To remove all embedded js copies from heat-dashboard, we need these xstatic packages projects. Change-Id: I404ec19472f1ede2c3d9c1d41eabd5710ffb21cd Depends-On: I4ed1ba3686e6e26aaf570980072344ce40977db4
2018-03-12 21:03:35 +09:00
xstatic-js-yaml:
repos:
- openstack/xstatic-js-yaml
Add xstatic projects to Horizon Horizon packages many of its dependencies with xstatic hosted on pypi, and they (mostly) have respective openstack projects for community review. These should be listed as valid openstack projects within governance. Change-Id: Ie03bc7bd5c4f6f9c9133e45ad3b1d37f83cb224b
2015-11-14 10:58:53 +00:00
xstatic-jsencrypt:
repos:
Correct spelling of xstatic-jsencrypt repo This is a minor spelling correction, to align the projects list entry with the reality in our infrastructure. Change-Id: Ic844e970308e0dd94e5a6d970578306233f646e5
2016-01-09 14:14:43 +00:00
- openstack/xstatic-jsencrypt
Add xstatic-** to horizon project To remove all embedded js copies from heat-dashboard, we need these xstatic packages projects. Change-Id: I404ec19472f1ede2c3d9c1d41eabd5710ffb21cd Depends-On: I4ed1ba3686e6e26aaf570980072344ce40977db4
2018-03-12 21:03:35 +09:00
xstatic-json2yaml:
repos:
- openstack/xstatic-json2yaml
Add xstatic projects to Horizon Horizon packages many of its dependencies with xstatic hosted on pypi, and they (mostly) have respective openstack projects for community review. These should be listed as valid openstack projects within governance. Change-Id: Ie03bc7bd5c4f6f9c9133e45ad3b1d37f83cb224b
2015-11-14 10:58:53 +00:00
xstatic-magic-search:
repos:
- openstack/xstatic-magic-search
xstatic-mdi:
repos:
- openstack/xstatic-mdi
xstatic-rickshaw:
repos:
- openstack/xstatic-rickshaw
xstatic-roboto-fontface:
repos:
- openstack/xstatic-roboto-fontface
xstatic-spin:
repos:
- openstack/xstatic-spin
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
ironic:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Add PTL results from the 2024.2/Dalmatian election Depends-On: If6c157efebc58d1fbe32a61a64f209b4102ac5c8 Change-Id: Ic74bfc853d2d9d045d4c589e1fd6c50afa608423
2024-03-22 09:00:21 +09:00
name: Riccardo Pittau
irc: rpittau
email: elfosardo@gmail.com
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-ironic
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Bare Metal service
use ">" to indicate multiline mission statements ">" indicates to YAML that the multiline string which follows is intended to ignore the line breaks contained within. Also includes some related whitespace cleanup. Change-Id: I6403c1d5663f9575c0d6ada2f1e672e743e451f3
2014-07-23 10:40:47 -05:00
mission: >
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
To produce an OpenStack service and associated libraries capable of
managing and provisioning physical machines, and to do this in a
security-aware and fault-tolerant manner.
url: https://wiki.openstack.org/wiki/Ironic
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
bifrost:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/bifrost
ironic:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/ironic
ironic-inspector:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/ironic-inspector
Add ironic-inspector-specs under the ironic team The ironic-inspector subteam decided to have its own specs process. Within the ML discussion [1] people showed preference to having a separate repo instead of co-existing in ironic-specs. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-November/079850.html Change-Id: Ied5135ac33f3d74a0146226ba242609b184d0bc1
2015-11-24 16:02:05 +01:00
ironic-inspector-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add ironic-inspector-specs under the ironic team The ironic-inspector subteam decided to have its own specs process. Within the ML discussion [1] people showed preference to having a separate repo instead of co-existing in ironic-specs. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-November/079850.html Change-Id: Ied5135ac33f3d74a0146226ba242609b184d0bc1
2015-11-24 16:02:05 +01:00
repos:
- openstack/ironic-inspector-specs
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
ironic-lib:
repos:
- openstack/ironic-lib
Add ironic-prometheus-exporter Depends-On: I3fe01ec5465e4ddc1eb7966beca96823c2dbda4b Change-Id: I396e0f8732370dcba1c8b04932b85380a236929e
2019-06-14 16:55:02 +02:00
ironic-prometheus-exporter:
repos:
- openstack/ironic-prometheus-exporter
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
ironic-python-agent:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/ironic-python-agent
New repository request: ironic-python-agent-builder This change requests adding a new repository ironic-python-agent-builder under the Bare metal project. It will contain scripts and DIB element(s) to build an ironic-python-agent image. Change-Id: I9a17d0b2dd666024f3cf6794ca52612a5b35c7f0
2017-06-23 14:44:37 +02:00
ironic-python-agent-builder:
repos:
- openstack/ironic-python-agent-builder
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
ironic-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/ironic-specs
Add tempest plugins to ironic project This adds the new ironic-tempest-plugin and ironic-inspector-tempest-plugin repos to ironic governance, as the beginning of the effort to split our tempest plugins to a separate repo. Depends-On: I0fdb88d588608538720e4f3e1381930df8dd9a6f Change-Id: I3e426c2f19eb00965eb7eb48b32f9b5e6c797307
2016-11-15 10:03:49 -05:00
ironic-tempest-plugin:
repos:
- openstack/ironic-tempest-plugin
Added new repository to governance for Ironic plugin Depends on: I8a9745ffa90107447d5c0d45557660f5ac5911bb Change-Id: I7c92bd97b944ea4a357642b972add81f25231205
2015-12-08 16:35:52 +00:00
ironic-ui:
repos:
- openstack/ironic-ui
Add openstack/metalsmith to ironic Metalsmith is a Python library that allows simplified access to the Bare Metal API. On the PTG in Denver it was agreed [1] to accept it to the ironic project governance. [1] https://etherpad.openstack.org/p/ironic-stein-ptg Change-Id: I786cb3dc833cfe0b1aa0b5301b3fce5a37ba0a2f
2018-09-12 18:07:02 +02:00
metalsmith:
repos:
- openstack/metalsmith
Add openstack/molteniron to ironic governance In the last ironic team meeting[0], the core team unanimously agreed molteniron[1] belongs in the ironic governance, per our rules around that.[2] Add it. Molteniron is a tool similar to nodepool to reserve baremetal machines for use by a CI that tests ironic. The CI does *not* run on these machines; rather they are used as physical resources to test ironic with real hardware. An ironic deployment + nodepool is not sufficient for this, as the test system needs access to the out of band controller (IPMI, iLO, DRAC, etc), and in an ironic deployment ironic controls that instead. This is in use by at least one third party CI, and others have plans to use it. [0] http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-11-14-17.00.html [1] http://git.openstack.org/cgit/openstack/molteniron/ [2] http://docs.openstack.org/developer/ironic/dev/governance.html Change-Id: I7d5b2b9b1fc1a471461ccb81bf55211e6414bf59
2016-11-15 15:32:38 -05:00
molteniron:
molteniron does not make releases This project was never supposed to have any releases, it's a tool that was used by 3rd Party CI in Ironic. Set the release-management key so that it gets properly ignored by the release management team. Change-Id: I707de0df26a69fdbcbf76078e9c8a6a86f1247f2
2021-01-07 18:39:12 +01:00
release-management: none
Add openstack/molteniron to ironic governance In the last ironic team meeting[0], the core team unanimously agreed molteniron[1] belongs in the ironic governance, per our rules around that.[2] Add it. Molteniron is a tool similar to nodepool to reserve baremetal machines for use by a CI that tests ironic. The CI does *not* run on these machines; rather they are used as physical resources to test ironic with real hardware. An ironic deployment + nodepool is not sufficient for this, as the test system needs access to the out of band controller (IPMI, iLO, DRAC, etc), and in an ironic deployment ironic controls that instead. This is in use by at least one third party CI, and others have plans to use it. [0] http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-11-14-17.00.html [1] http://git.openstack.org/cgit/openstack/molteniron/ [2] http://docs.openstack.org/developer/ironic/dev/governance.html Change-Id: I7d5b2b9b1fc1a471461ccb81bf55211e6414bf59
2016-11-15 15:32:38 -05:00
repos:
- openstack/molteniron
Add networking-baremetal under Ironic governance Networking-baremetal is officially supported project by Ironic community that keeps Neutron plugin required for Ironic/Neutron integration. Was decided on Networking/Baremetal cross-project session in Atlanta [0]. [0] https://etherpad.openstack.org/p/pike-ptg-ironic-neutron Change-Id: I3b6a22f2947b5515c24af56e05da496736220466 Depends-On: Ieaf8eec060fea65201fbafca2877683146d0623b
2017-02-28 21:44:19 +02:00
networking-baremetal:
repos:
- openstack/networking-baremetal
Add networking-generic-switch under ironic this project has become an essential part of ironic testing, and ironic community would like to formally pull it under OpenStack baremetal program. For more rationale and discussion see this ML thread: http://lists.openstack.org/pipermail/openstack-dev/2017-November/124519.html Change-Id: Ie08c9ef029e29845c766d9c10329817124954e16
2017-11-21 17:19:06 +02:00
networking-generic-switch:
repos:
- openstack/networking-generic-switch
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-ironic-inspector-client:
repos:
- openstack/python-ironic-inspector-client
python-ironicclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-ironicclient
Add sushy under Ironic governance Sushy is a Python library to communicate with Redfish based systems (http://www.dmtf.org/standards/redfish) which is currently being used to create a "redfish" driver/hardware type for Ironic. In the upstream meeting on 2017-03-13 it was discussed whether we want to include it under the Ironic's governance or not [0] and the conclusion is yes, we want it to be part of the governance. [0] http://eavesdrop.openstack.org/meetings/ironic/2017/ironic.2017-03-13-17.00.log.html#l-362 Change-Id: I8bc6d02653be8c34eea3dbe768ab45a68aed1d11
2017-03-13 18:03:20 +00:00
sushy:
repos:
- openstack/sushy
Add sushy-tools under Ironic governance This patch is adding a new repository called "sushy-tools" under the Ironic governance. The sushy library is already part of it and the new repository is meant to hold the tools to support the development and testing of that library. Depends-On: I2ff0299072e86dcf394e438ed2b6e443156a54e8 Change-Id: I880d9058408792f0c5d9f6531ae8ea06e06229ea
2017-03-28 13:33:01 +01:00
sushy-tools:
repos:
- openstack/sushy-tools
Add tenks under Ironic governance This patch is adding a new repository called "tenks" under the Ironic governance. Tenks provides tools for managing virtual bare metal nodes, for use in development and testing environments. Depends-On: Iada90b335677ab2d82ac7a2d493ce6d02eb91a13 Change-Id: I7df185529ded2817b77b11c5479df30e4574c1e7
2018-09-06 12:27:56 +01:00
tenks:
repos:
- openstack/tenks
Add VirtualBMC project under Ironic VirtualBMC is a utility that allows virtual/fake BMCs to be created handling the IPMI commands and converting it to calls to the python-libvirt library. The project was created to allow drivers using the IPMI protocol to be tested in the Ironic gate. Change-Id: I24349ce1b5c0332157f1bf8bd0613338a15495e4 Depends-On: Idf02cb28316be1846bb5fa1988c3d47ce6f9c54c
2016-04-19 17:33:37 +01:00
virtualbmc:
repos:
- openstack/virtualbmc
Ironic program adopting x/virtualpdu VirtualPDU cores no longer maintain it, and gave Ironic cores access and permission to take it over. This change officially adopts it as an OpenStack project under Ironic. We will correct this to reference openstack/virtualpdu once the repository move is complete. Change-Id: I2700f0803fa47c3907f889273d34483bfc9ac54f
2023-03-02 13:03:09 -08:00
virtualpdu:
repos:
Fix virtualpdu repo namespace x/virtualpdu repo has been renamed to openstack/virtualpdu - https://review.opendev.org/c/openstack/project-config/+/876231 fixing it in governance record. Change-Id: Ia2430061f5dd751d2db52a898b2976a9a094e892
2023-04-06 20:20:57 -05:00
- openstack/virtualpdu
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
keystone:
Revert "Switch Keystone to DPL" This reverts commit 48a02a308e73eb0c2fc57c758b23e1b1c25f66bb. Reason for revert: For the current election cycle Z we have a candidate who wishes to run for PTL. As a result, keystone will look to switching back from the DPL model back to PTL driven. Change-Id: I673e7bfd360b438abb2fd7f66b32c225c566c4d1
2022-02-14 20:34:57 +00:00
ptl:
Appoint Dave as Keystone PTL Dave raised the late candidacy for Keystone PTL 2023.1 cycle. - https://review.opendev.org/c/openstack/election/+/856297 - https://etherpad.opendev.org/p/2023.1-leaderless Change-Id: I5ca77302cf70ba25cfe77cc48191c312938dea86
2022-09-22 13:26:03 -05:00
name: Dave Wilde
irc: d34dh0r53
email: dwilde@redhat.com
appointed:
Consider release version as string in projects data We need to use the release version as string, so updating the PTL 'appointment' field and the data in projects.yaml Change-Id: Ib097517f514e68246fb6e27b83e98a1f3f6b8eed
2023-03-10 18:14:20 -06:00
- '2023.1'
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-keystone
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Identity service
use ">" to indicate multiline mission statements ">" indicates to YAML that the multiline string which follows is intended to ignore the line breaks contained within. Also includes some related whitespace cleanup. Change-Id: I6403c1d5663f9575c0d6ada2f1e672e743e451f3
2014-07-23 10:40:47 -05:00
mission: >
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
To facilitate API client authentication, service discovery, distributed
multi-tenant authorization, and auditing.
url: https://wiki.openstack.org/wiki/Keystone
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
keystone:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/keystone
keystone-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/keystone-specs
Add keystone-tempest-plugins to keystone project Create a new repository for keystone's tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: I0fc551d38aa7243a02eed39b663a21e88f2ad713 Change-Id: Idd4eef295abf3f495559f7b70e98f2d7ce1050d2
2017-05-29 22:09:43 +02:00
keystone-tempest-plugin:
repos:
- openstack/keystone-tempest-plugin
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
keystoneauth:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/keystoneauth
keystonemiddleware:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/keystonemiddleware
pycadf:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/pycadf
python-keystoneclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-keystoneclient
Add ldappool to the keystone managed projects The ldappool project was adopted by several memebers of the keystone development team. This commit formally adds the project to the list of keystone-managed openstack projects. This will allow us to manage releases the same way we do with the other libraries we manage. Change-Id: Ic7b7b693dfb36ca29a8499e2bb3956145ec3c098
2017-05-25 19:31:35 +00:00
ldappool:
repos:
- openstack/ldappool
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
kolla:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Update projects.yaml for Yoga PTLs This reflects the election results of Yoga PTLs confirmed by election officials. Depends-On: I243e74e51ec23709e33c3ad4ece2ca80cbadf20a Change-Id: I27baf08559b02c8b803b257fda77cbadcc531cc6 Signed-off-by: Andy McCrae <andy.mccrae@gmail.com> Signed-off-by: Ian Y. Choi <ianyrchoi@gmail.com> Signed-off-by: Helena Spease <helena@openinfra.dev> Signed-off-by: Amy Marrich <spotz@demarco.com> Signed-off-by: Belmiro Moreira <moreira.belmiro.email.lists@gmail.com>
2021-09-08 20:32:02 +09:00
name: Michal Nasiadka
irc: mnasiadka
email: mnasiadka@gmail.com
Fix kolla irc channel Kolla recently moved to #openstack-kolla, see I89097ae0dbacc16bf5e94c1df75f81087d6f9404. Adjust kolla IRC entry for this. Change-Id: I2cc294449fa96497d2ceefd37ed07a60c2907eef
2016-04-08 16:26:22 +02:00
irc-channel: openstack-kolla
Provide short description for cryptic team names Looking at https://governance.openstack.org/tc/reference/projects/index.html certain team names are not self-explaining. The "service" field is generally used to clarify in a short description what the team provides. This patch adds short descriptions for the teams where the name is not self-explaining (including "requirements" which can be confusing at first glance). Change-Id: I24fce9a46cfed8ebf2dfcb4fd7cf5ac87bf2500b
2019-11-20 12:14:56 +01:00
service: Containerised deployment of OpenStack
Kolla application for Big Tent Kolla spent 4 IRC meeting hours defining the Kolla mission here [1]. Our mission is clear and well defined. Kolla provides production-ready containers and deployment tools for operating OpenStack clouds. The project uses the ASL 2.0 as declared in the code base [2]. The PTL was chosen by election to be Steven Dake using the standard OpenStack mechanism [3]. The #kolla IRC channel on freenode is logged and the channel is notified of such logging [4]. Our public meeting schedule was decided by vote at [5] and all meeting logs are stored at our wiki. The project uses public code reviews on the OpenStack infrastructure. Kolla has been using the +2/+A process requiring two unique core reviewers to review a patch since project inception. Our project does not permit exceptions to the +2/+A process and we have never approved a patch without two core reviews. Our gating runs pep8, bashate, and other YAML/JSON syntax checking. The Kolla team builds all images as a functional CI job to validate our builds. In nearly every IRC meeting for the Liberty cycle continuous integration has been our second topic of discussion. The PTL serves as liaison between the Kolla community and other projects for example coordinating our container content with James Slagle, the TripleO PTL. Because Kolla deploys most OpenStack namespaced server projects, we must coordinate and cooperate with nearly every server project in OpenStack. The project has openly worked with members of the TripleO community to integrate kolla/containers into TripleO. Several PoC patches exist demonstrating TripleO and Kolla integration [6]. During Paris ODS, we had a one hour design session recorded here [7]. The Kolla team had an open design session at Vancouver ODS during Ansible Collaboration day. TripleO hosted several Kolla design sessions at Vancouver ODS. We discuss all work in the open, mostly using IRC. Based upon open communication between the Kolla core reveiwer and developement team, the PTL presented the long-term vision for Kolla during Liberty ODS [8]. Kolla uses IRC very heavily because everyone is very active on IRC. As a result the Kolla core reviewer team often makes quick decisions. Our core reviewer team is distributed around the world, so we use the mailing list to communicate long term planning objectives. A recent example of such is the recently held Kolla-Palooza midcycle meetup on July 28th and July 29th, 2015. We use the mailing list by prefixing e-mails to openstack-dev@lists.openstack.org with [kolla] for long term planning rather than short term decision making. Kolla has a high degree of diversity in both reviews [9] and commits [10] with our largest percentage of contributions originating from unaffiliated contributors. [1] https://etherpad.openstack.org/p/kolla-manifesto [2] https://github.com/stackforge/kolla/blob/master/LICENSE [3] https://wiki.openstack.org/wiki/Kolla/PTL_Elections_March_2015 [4] http://eavesdrop.openstack.org/irclogs/%23kolla/ [5] https://wiki.openstack.org/wiki/Meetings/Kolla [6] https://review.openstack.org/#/c/178840/ [7] https://etherpad.openstack.org/p/kolla-design [8] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/thanks-docker-the-pro-and-039s-and-con-and-039s-of-containerizing-your-openstack-services [9] http://stackalytics.com/?project_type=all&module=kolla [10] http://stackalytics.com/?project_type=all&module=kolla&metric=commits Change-Id: If6e30574235e61ea6850e364d5ac7d11bc0ee2b4
2015-07-28 14:37:28 -07:00
mission: >
To provide production-ready containers and deployment tools for operating
OpenStack clouds.
url: https://wiki.openstack.org/wiki/Kolla
deliverables:
Add ansible-collection-kolla repo to Kolla project This repository will contain an Ansible collection for common code shared between Kolla deliverables. Depends-On: https://review.opendev.org/c/openstack/project-config/+/819326 Change-Id: I78cbded7cb9cc0161d8807a10a2098aa77818d4d
2021-11-25 14:45:24 +00:00
ansible-collection-kolla:
repos:
- openstack/ansible-collection-kolla
Kolla application for Big Tent Kolla spent 4 IRC meeting hours defining the Kolla mission here [1]. Our mission is clear and well defined. Kolla provides production-ready containers and deployment tools for operating OpenStack clouds. The project uses the ASL 2.0 as declared in the code base [2]. The PTL was chosen by election to be Steven Dake using the standard OpenStack mechanism [3]. The #kolla IRC channel on freenode is logged and the channel is notified of such logging [4]. Our public meeting schedule was decided by vote at [5] and all meeting logs are stored at our wiki. The project uses public code reviews on the OpenStack infrastructure. Kolla has been using the +2/+A process requiring two unique core reviewers to review a patch since project inception. Our project does not permit exceptions to the +2/+A process and we have never approved a patch without two core reviews. Our gating runs pep8, bashate, and other YAML/JSON syntax checking. The Kolla team builds all images as a functional CI job to validate our builds. In nearly every IRC meeting for the Liberty cycle continuous integration has been our second topic of discussion. The PTL serves as liaison between the Kolla community and other projects for example coordinating our container content with James Slagle, the TripleO PTL. Because Kolla deploys most OpenStack namespaced server projects, we must coordinate and cooperate with nearly every server project in OpenStack. The project has openly worked with members of the TripleO community to integrate kolla/containers into TripleO. Several PoC patches exist demonstrating TripleO and Kolla integration [6]. During Paris ODS, we had a one hour design session recorded here [7]. The Kolla team had an open design session at Vancouver ODS during Ansible Collaboration day. TripleO hosted several Kolla design sessions at Vancouver ODS. We discuss all work in the open, mostly using IRC. Based upon open communication between the Kolla core reveiwer and developement team, the PTL presented the long-term vision for Kolla during Liberty ODS [8]. Kolla uses IRC very heavily because everyone is very active on IRC. As a result the Kolla core reviewer team often makes quick decisions. Our core reviewer team is distributed around the world, so we use the mailing list to communicate long term planning objectives. A recent example of such is the recently held Kolla-Palooza midcycle meetup on July 28th and July 29th, 2015. We use the mailing list by prefixing e-mails to openstack-dev@lists.openstack.org with [kolla] for long term planning rather than short term decision making. Kolla has a high degree of diversity in both reviews [9] and commits [10] with our largest percentage of contributions originating from unaffiliated contributors. [1] https://etherpad.openstack.org/p/kolla-manifesto [2] https://github.com/stackforge/kolla/blob/master/LICENSE [3] https://wiki.openstack.org/wiki/Kolla/PTL_Elections_March_2015 [4] http://eavesdrop.openstack.org/irclogs/%23kolla/ [5] https://wiki.openstack.org/wiki/Meetings/Kolla [6] https://review.openstack.org/#/c/178840/ [7] https://etherpad.openstack.org/p/kolla-design [8] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/thanks-docker-the-pro-and-039s-and-con-and-039s-of-containerizing-your-openstack-services [9] http://stackalytics.com/?project_type=all&module=kolla [10] http://stackalytics.com/?project_type=all&module=kolla&metric=commits Change-Id: If6e30574235e61ea6850e364d5ac7d11bc0ee2b4
2015-07-28 14:37:28 -07:00
kolla:
repos:
- openstack/kolla
Add kolla-ansible as a deliverable to governance repository Many folks in the broader open source ecosystem have a strong desire for Kolla to make OpenStack containers available as a standalone repository. Agred upon by vote in this upstream mailing list thread: http://lists.openstack.org/pipermail/openstack-dev/2016-September/103721.html Depends-On: I09b365d456735b1e1b7696ed323a21b27f1c642a Change-Id: If1353efd76611128bc7e6dd5b8c52c5a23d4322a
2016-11-12 16:56:05 -07:00
kolla-ansible:
repos:
- openstack/kolla-ansible
Add kayobe as a kolla deliverable As agreed on openstack-discuss [1]. The project repo renames will be performed separately. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007250.html Change-Id: I522211d34cfed2f11c39490313e3b447520f1f6d
2019-07-05 09:15:27 +01:00
kayobe:
repos:
Fix linters job ``tox -elinters`` is failing currently because it can't find some recently added projects which apparently need to have their paths adjusted with ``sed s;x/;openstack/``. Change-Id: I3ec992527a052bf6800c23a381f7af2365e47a62
2019-09-16 11:41:18 -04:00
- openstack/kayobe
- openstack/kayobe-config
- openstack/kayobe-config-dev
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
magnum:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Close Antelope Elections Reflects election result to governance repo : https://review.opendev.org/c/openstack/election/+/858532 Change-Id: Ic4f80855d784f9bf104f0f982fc8f265544d961f
2022-09-20 23:24:42 +09:00
name: Jake Yip
irc: jakeyip
Update jakeyip email Change-Id: I99e4adff37623d87d7a11bd3c1546ec2ca0d9a1f
2024-02-15 21:16:21 +11:00
email: jake.yip@ardc.edu.au
Appoint Spyros as Magnum PTL Spyros raised the late candidacy for Magnum Zed cycle PTL - https://review.opendev.org/c/openstack/election/+/829537 - https://etherpad.opendev.org/p/zed-leaderless Change-Id: Ic57bb224234a7965fd2c2011f9808ed41f6808ff
2022-02-27 18:28:55 -06:00
appointed:
- zed
Update IRC channel for magnum The project uses #openstack-containers now, update reference. Change-Id: I6c52814f8512c12fb5d841d68f4186d5dd0596f9
2015-11-04 10:38:36 +01:00
irc-channel: openstack-containers
Update Magnum Description and Mission At our Newton design summit in Austin, our community reached a consensus to narrow the scope of the Magnum project to focus on integrating container orchestration engines (COEs) with OpenStack, and making them easy to create, manage, and delete in an OpenStack cloud with full multi-tenancy support. API features intended to uniformly create, manage, and delete individual containers across any COE will be removed from Magnum's API, and may be re-introduced as a separate project with a new name. This change is justified by the recognition that we have two distinct groups of stakeholders who value different goals for different reasons. Conflation of refining a common COE abstraction, and deep integration of each COE for native API deployment/management within Magnum has proven to be problematic. We will solve this conflation by clarifying a narrow scope for Magnum, and allowing another project to pursue a common COE abstraction. This allows each group of stakeholders to focus on their mutual interests. Change-Id: I6682e78827e168a517d3d91e536f9d3fd0ec6c6a
2016-04-30 00:21:22 +00:00
service: Container Infrastructure Management service
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
mission: >
Update Magnum Description and Mission At our Newton design summit in Austin, our community reached a consensus to narrow the scope of the Magnum project to focus on integrating container orchestration engines (COEs) with OpenStack, and making them easy to create, manage, and delete in an OpenStack cloud with full multi-tenancy support. API features intended to uniformly create, manage, and delete individual containers across any COE will be removed from Magnum's API, and may be re-introduced as a separate project with a new name. This change is justified by the recognition that we have two distinct groups of stakeholders who value different goals for different reasons. Conflation of refining a common COE abstraction, and deep integration of each COE for native API deployment/management within Magnum has proven to be problematic. We will solve this conflation by clarifying a narrow scope for Magnum, and allowing another project to pursue a common COE abstraction. This allows each group of stakeholders to focus on their mutual interests. Change-Id: I6682e78827e168a517d3d91e536f9d3fd0ec6c6a
2016-04-30 00:21:22 +00:00
To provide a set of services for provisioning, scaling, and managing
container orchestration engines.
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
url: https://wiki.openstack.org/wiki/Magnum
deliverables:
magnum:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/magnum
Add magnum-capi-helm to Magnum project This repository will contain Magnum CAPI Helm driver code. It has been agreed on weekly meeting - see [1]. [1]: https://meetings.opendev.org/meetings/magnum/2024/magnum.2024-02-28-09.00.html Depends-On: https://review.opendev.org/c/openstack/project-config/+/910239 Change-Id: I9d76b8fdb29257dc0cceebe85fc3e8ccb4b2d912
2024-02-26 16:57:20 +01:00
magnum-capi-helm:
repos:
- openstack/magnum-capi-helm
Add magnum-capi-helm-charts to Magnum project This repository will contain Helm charts that are used by the new Cluster API driver. Depends-On: https://review.opendev.org/c/openstack/project-config/+/893117 Change-Id: I656d220e5341c04572d5d0968a494b7cacecdeda
2023-08-30 12:48:58 +12:00
magnum-capi-helm-charts:
repos:
- openstack/magnum-capi-helm-charts
Add magnum-specs repo See I81d62b4feed6629877719ac7ea4529cc1c3346b4 Change-Id: If8686420db4a6517526649258556e27d0da0f61b
2016-11-19 10:57:23 -06:00
magnum-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add magnum-specs repo See I81d62b4feed6629877719ac7ea4529cc1c3346b4 Change-Id: If8686420db4a6517526649258556e27d0da0f61b
2016-11-19 10:57:23 -06:00
repos:
- openstack/magnum-specs
Add magnum-tempest-plugin to magnum project Create a new repository for magnum's tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: Ieb348f3fc976388e7a10f9e2e1e252734aaace12 Change-Id: If16bf83389f9dadcb0856c9fc8fce25513c7b41b
2017-09-06 16:32:16 +05:30
magnum-tempest-plugin:
repos:
- openstack/magnum-tempest-plugin
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
magnum-ui:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/magnum-ui
python-magnumclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-magnumclient
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
manila:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Close Zed PTL Elections Change-Id: I1ff1ef20ea9d3da8e8123d5c2ddef2d10a45a9ef
2022-02-24 16:35:09 -06:00
name: Carlos Silva
irc: carloss
email: ces.eduardo98@gmail.com
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-manila
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Shared File Systems service
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
mission: >
To provide a set of services for management of shared file systems
in a multitenant cloud environment, similar to how OpenStack provides
for block-based storage management through the Cinder project.
url: https://wiki.openstack.org/wiki/Manila
deliverables:
manila:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/manila
manila-image-elements:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/manila-image-elements
Add manila-specs repo Change-Id: I498e4de49922c87ace4aeb22ea81072b2998e14f Depends-On: I106fe89890f0d587a2ac5c6e3e14a237c1bcc7c2
2016-05-03 10:18:07 -04:00
manila-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add manila-specs repo Change-Id: I498e4de49922c87ace4aeb22ea81072b2998e14f Depends-On: I106fe89890f0d587a2ac5c6e3e14a237c1bcc7c2
2016-05-03 10:18:07 -04:00
repos:
- openstack/manila-specs
Add manila-tempest-plugin to manila project Create a new repository for Manila's tempest plugin to fulfill Queens goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: Ib39840eba27de4dcb0e81bc191619057002ac5d8 Change-Id: Iaf7537322e17623d7fca9a4fc1944d19a249b22f
2017-09-27 16:41:40 +01:00
manila-tempest-plugin:
repos:
- openstack/manila-tempest-plugin
Add manila-test-image to governance Manila-test-image is an infrastructure project for test and development of Manila. It's part of the Manila project but not intended to ship with Manila. Change-Id: I76ab79d1b92000aee08775a2b535273424aeb828
2016-11-03 12:48:18 -04:00
manila-test-image:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add manila-test-image to governance Manila-test-image is an infrastructure project for test and development of Manila. It's part of the Manila project but not intended to ship with Manila. Change-Id: I76ab79d1b92000aee08775a2b535273424aeb828
2016-11-03 12:48:18 -04:00
repos:
- openstack/manila-test-image
Change ownership of manila-ui plugin Originally manila-ui was a subproject of horizon but it seems to make more sense for it to be owned by the Manila project because the Manila PTL is responsible for releases. Change-Id: If929f70194b741010a3671185f25d44ff69adb1d
2016-06-06 08:48:55 -04:00
manila-ui:
repos:
- openstack/manila-ui
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-manilaclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-manilaclient
Masakari - Instances High Availability Service Mission: Provide instances high availability service for OpenStack clouds by automatically recover the instances from failures. We are mainly focus on solve the problems addressed in High Availability for Virtual Machines Development Proposal [1]. Project History: Engineers from NTT started this project on github [2] in Jul 2015 under Apache License 2.0. Newton design Summit in Austin, Masakari team and OpenStack HA team discussed how to implement this feature in OpenStack [3]. As Masakari team agreed to re-architecte masakari, we started a new project openstack/masakari [4] and re-architect and rebuild the [2] with OpenStack standards. We continually discussed this topic in OpenStack HA team [5] and we present our plane to moving into a converged upstream solution for-instances high-availability in Boston Summit [6]. Masakari is an essential component of this solution. Satisfaction of new projects requirements: Masakari projects follow the 4 opens, * Open Source: All Masakari source codes, specifications, and documentations are use Apache License 2.0. All library dependencies allow for unrestricted distribution and deployment. * Open Community: We holds weekly IRC meetings in #openstack-meeting and weekly agenda, meeting time, and link for previous meeting logs are in our wiki page[7]. We are also available in #openstack-masakari IRC channel for daily discussion. All the channels are open for anyone to interact with Masakari team. * Open Development: Masakari uses Gerrit for code reviews and Launchpad for bugs and blueprints tracking [8]. Project core team checks all the changes before merging them. The project is integrated with the Openstack CI, and runs pep8, py27, and py35 jobs. Masakari is implemented using libraries and technologies adopted by other existing OpenStack projects. * Open Design: The Masakari team has been publicly discussed project direction, issues, work items and priorities in etherpad [9-11] and in the weekly IRC meetings. We use masakari-specs [12] to discuss design specifications for all Masakari projects. We also use openstack-dev ML with prefix [masakari] for project discussion. Masakari is compatible with OpenStack APIs, and uses Keystone middleware to integrate with OpenStack Identity. The Masakari team is happy to participate in any goals specified by the TC, and meet any policies that the TC requires all projects to meet. [1] http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html [2] https://github.com/ntt-sic/masakari [3] https://etherpad.openstack.org/p/newton-instance-ha [4] https://github.com/openstack/masakari [5] https://wiki.openstack.org/wiki/Meetings/HATeamMeeting [6] https://www.openstack.org/videos/boston-2017/high-availability-for-instances-moving-to-a-converged-upstream-solution [7] https://wiki.openstack.org/wiki/Meetings/Masakari [8] https://wiki.openstack.org/wiki/Masakari#Code_and_Bug.2FFeature_trackers [9] https://etherpad.openstack.org/p/ocata-priorities-masakari [10] https://etherpad.openstack.org/p/masakari-pike-workitems [11] https://etherpad.openstack.org/p/masakari-queens-workitems [12] https://review.openstack.org/#/q/project:openstack/masakari-specs Change-Id: I99f7bfbf785f79d235a51ca8acc8810c4805694c
2017-09-02 01:09:20 +09:00
masakari:
ptl:
Update with 2023.2 Election results. Updates PTLs and TC members as per: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032240.html Also removes chair and vice-chair roles as this is a new TC Change-Id: I2aef6f364afeecc8bd48ce5e9fa64457c582b610
2023-02-16 11:16:15 +11:00
name: sam sue
irc: No nick supplied
email: suzhengwei@inspur.com
Appoint Sampath Priyankara as masakari PTL Sam confirmed to serve as masakari PTL: http://lists.openstack.org/pipermail/openstack-discuss/2020-April/013773.html Change-Id: I8a80139ff2ac872ca222eff2e9e383f8b5110181
2020-04-03 11:48:30 -05:00
appointed:
[masakari] Transfer PTL role to suzhengwei Due to a shift in my priorities and being unable to dedicate enough time, I am transferring the PTL role to suzhengwei. suzhengwei has been lately the main contributor to the Masakari project, working on the major features that were introduced in the last few cycles. I have already obtained his approval by mail. Do note his contributions so far were using a different mail address (sugar-2008@163.com) but I have been asked to use the Inspur one as it is currently preferred. Change-Id: I3744b19e91c90ef46f2855c810f40f61ffb8a9a2
2022-01-13 08:18:01 +00:00
- yoga
Appoint suzhengwei as Masakari PTL suzhengwei candidacy for zed cycle could not be validated due to different email address in OIF membership - https://review.opendev.org/c/openstack/election/+/829154 - https://etherpad.opendev.org/p/zed-leaderless Change-Id: I43b76e47d36b3700982edb760f402a2a684d6175
2022-02-27 18:22:00 -06:00
- zed
Consider release version as string in projects data We need to use the release version as string, so updating the PTL 'appointment' field and the data in projects.yaml Change-Id: Ib097517f514e68246fb6e27b83e98a1f3f6b8eed
2023-03-10 18:14:20 -06:00
- '2023.1'
Masakari - Instances High Availability Service Mission: Provide instances high availability service for OpenStack clouds by automatically recover the instances from failures. We are mainly focus on solve the problems addressed in High Availability for Virtual Machines Development Proposal [1]. Project History: Engineers from NTT started this project on github [2] in Jul 2015 under Apache License 2.0. Newton design Summit in Austin, Masakari team and OpenStack HA team discussed how to implement this feature in OpenStack [3]. As Masakari team agreed to re-architecte masakari, we started a new project openstack/masakari [4] and re-architect and rebuild the [2] with OpenStack standards. We continually discussed this topic in OpenStack HA team [5] and we present our plane to moving into a converged upstream solution for-instances high-availability in Boston Summit [6]. Masakari is an essential component of this solution. Satisfaction of new projects requirements: Masakari projects follow the 4 opens, * Open Source: All Masakari source codes, specifications, and documentations are use Apache License 2.0. All library dependencies allow for unrestricted distribution and deployment. * Open Community: We holds weekly IRC meetings in #openstack-meeting and weekly agenda, meeting time, and link for previous meeting logs are in our wiki page[7]. We are also available in #openstack-masakari IRC channel for daily discussion. All the channels are open for anyone to interact with Masakari team. * Open Development: Masakari uses Gerrit for code reviews and Launchpad for bugs and blueprints tracking [8]. Project core team checks all the changes before merging them. The project is integrated with the Openstack CI, and runs pep8, py27, and py35 jobs. Masakari is implemented using libraries and technologies adopted by other existing OpenStack projects. * Open Design: The Masakari team has been publicly discussed project direction, issues, work items and priorities in etherpad [9-11] and in the weekly IRC meetings. We use masakari-specs [12] to discuss design specifications for all Masakari projects. We also use openstack-dev ML with prefix [masakari] for project discussion. Masakari is compatible with OpenStack APIs, and uses Keystone middleware to integrate with OpenStack Identity. The Masakari team is happy to participate in any goals specified by the TC, and meet any policies that the TC requires all projects to meet. [1] http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html [2] https://github.com/ntt-sic/masakari [3] https://etherpad.openstack.org/p/newton-instance-ha [4] https://github.com/openstack/masakari [5] https://wiki.openstack.org/wiki/Meetings/HATeamMeeting [6] https://www.openstack.org/videos/boston-2017/high-availability-for-instances-moving-to-a-converged-upstream-solution [7] https://wiki.openstack.org/wiki/Meetings/Masakari [8] https://wiki.openstack.org/wiki/Masakari#Code_and_Bug.2FFeature_trackers [9] https://etherpad.openstack.org/p/ocata-priorities-masakari [10] https://etherpad.openstack.org/p/masakari-pike-workitems [11] https://etherpad.openstack.org/p/masakari-queens-workitems [12] https://review.openstack.org/#/q/project:openstack/masakari-specs Change-Id: I99f7bfbf785f79d235a51ca8acc8810c4805694c
2017-09-02 01:09:20 +09:00
irc-channel: openstack-masakari
Use "service" for consistency in team listing Looking at https://governance.openstack.org/tc/reference/projects/index.html there is inconsistent capitalization in the short description used in parenthesis. We should standardize on "service" unless used in a "-as-a-Service" case. Change-Id: I2e6325b391264e36358b57d5878b250526e93a8d
2019-11-20 12:13:49 +01:00
service: Instances High Availability service
Masakari - Instances High Availability Service Mission: Provide instances high availability service for OpenStack clouds by automatically recover the instances from failures. We are mainly focus on solve the problems addressed in High Availability for Virtual Machines Development Proposal [1]. Project History: Engineers from NTT started this project on github [2] in Jul 2015 under Apache License 2.0. Newton design Summit in Austin, Masakari team and OpenStack HA team discussed how to implement this feature in OpenStack [3]. As Masakari team agreed to re-architecte masakari, we started a new project openstack/masakari [4] and re-architect and rebuild the [2] with OpenStack standards. We continually discussed this topic in OpenStack HA team [5] and we present our plane to moving into a converged upstream solution for-instances high-availability in Boston Summit [6]. Masakari is an essential component of this solution. Satisfaction of new projects requirements: Masakari projects follow the 4 opens, * Open Source: All Masakari source codes, specifications, and documentations are use Apache License 2.0. All library dependencies allow for unrestricted distribution and deployment. * Open Community: We holds weekly IRC meetings in #openstack-meeting and weekly agenda, meeting time, and link for previous meeting logs are in our wiki page[7]. We are also available in #openstack-masakari IRC channel for daily discussion. All the channels are open for anyone to interact with Masakari team. * Open Development: Masakari uses Gerrit for code reviews and Launchpad for bugs and blueprints tracking [8]. Project core team checks all the changes before merging them. The project is integrated with the Openstack CI, and runs pep8, py27, and py35 jobs. Masakari is implemented using libraries and technologies adopted by other existing OpenStack projects. * Open Design: The Masakari team has been publicly discussed project direction, issues, work items and priorities in etherpad [9-11] and in the weekly IRC meetings. We use masakari-specs [12] to discuss design specifications for all Masakari projects. We also use openstack-dev ML with prefix [masakari] for project discussion. Masakari is compatible with OpenStack APIs, and uses Keystone middleware to integrate with OpenStack Identity. The Masakari team is happy to participate in any goals specified by the TC, and meet any policies that the TC requires all projects to meet. [1] http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html [2] https://github.com/ntt-sic/masakari [3] https://etherpad.openstack.org/p/newton-instance-ha [4] https://github.com/openstack/masakari [5] https://wiki.openstack.org/wiki/Meetings/HATeamMeeting [6] https://www.openstack.org/videos/boston-2017/high-availability-for-instances-moving-to-a-converged-upstream-solution [7] https://wiki.openstack.org/wiki/Meetings/Masakari [8] https://wiki.openstack.org/wiki/Masakari#Code_and_Bug.2FFeature_trackers [9] https://etherpad.openstack.org/p/ocata-priorities-masakari [10] https://etherpad.openstack.org/p/masakari-pike-workitems [11] https://etherpad.openstack.org/p/masakari-queens-workitems [12] https://review.openstack.org/#/q/project:openstack/masakari-specs Change-Id: I99f7bfbf785f79d235a51ca8acc8810c4805694c
2017-09-02 01:09:20 +09:00
mission: >
Provide instances high availability service for OpenStack
typo in masakari mission statement Change-Id: Icd65f072d03ea4b79aabe536823ffb6ef5f384f5 Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2017-09-20 12:42:27 -04:00
clouds by automatically recovering the instances from failures.
Masakari - Instances High Availability Service Mission: Provide instances high availability service for OpenStack clouds by automatically recover the instances from failures. We are mainly focus on solve the problems addressed in High Availability for Virtual Machines Development Proposal [1]. Project History: Engineers from NTT started this project on github [2] in Jul 2015 under Apache License 2.0. Newton design Summit in Austin, Masakari team and OpenStack HA team discussed how to implement this feature in OpenStack [3]. As Masakari team agreed to re-architecte masakari, we started a new project openstack/masakari [4] and re-architect and rebuild the [2] with OpenStack standards. We continually discussed this topic in OpenStack HA team [5] and we present our plane to moving into a converged upstream solution for-instances high-availability in Boston Summit [6]. Masakari is an essential component of this solution. Satisfaction of new projects requirements: Masakari projects follow the 4 opens, * Open Source: All Masakari source codes, specifications, and documentations are use Apache License 2.0. All library dependencies allow for unrestricted distribution and deployment. * Open Community: We holds weekly IRC meetings in #openstack-meeting and weekly agenda, meeting time, and link for previous meeting logs are in our wiki page[7]. We are also available in #openstack-masakari IRC channel for daily discussion. All the channels are open for anyone to interact with Masakari team. * Open Development: Masakari uses Gerrit for code reviews and Launchpad for bugs and blueprints tracking [8]. Project core team checks all the changes before merging them. The project is integrated with the Openstack CI, and runs pep8, py27, and py35 jobs. Masakari is implemented using libraries and technologies adopted by other existing OpenStack projects. * Open Design: The Masakari team has been publicly discussed project direction, issues, work items and priorities in etherpad [9-11] and in the weekly IRC meetings. We use masakari-specs [12] to discuss design specifications for all Masakari projects. We also use openstack-dev ML with prefix [masakari] for project discussion. Masakari is compatible with OpenStack APIs, and uses Keystone middleware to integrate with OpenStack Identity. The Masakari team is happy to participate in any goals specified by the TC, and meet any policies that the TC requires all projects to meet. [1] http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html [2] https://github.com/ntt-sic/masakari [3] https://etherpad.openstack.org/p/newton-instance-ha [4] https://github.com/openstack/masakari [5] https://wiki.openstack.org/wiki/Meetings/HATeamMeeting [6] https://www.openstack.org/videos/boston-2017/high-availability-for-instances-moving-to-a-converged-upstream-solution [7] https://wiki.openstack.org/wiki/Meetings/Masakari [8] https://wiki.openstack.org/wiki/Masakari#Code_and_Bug.2FFeature_trackers [9] https://etherpad.openstack.org/p/ocata-priorities-masakari [10] https://etherpad.openstack.org/p/masakari-pike-workitems [11] https://etherpad.openstack.org/p/masakari-queens-workitems [12] https://review.openstack.org/#/q/project:openstack/masakari-specs Change-Id: I99f7bfbf785f79d235a51ca8acc8810c4805694c
2017-09-02 01:09:20 +09:00
url: https://wiki.openstack.org/wiki/Masakari
deliverables:
masakari:
repos:
- openstack/masakari
masakari-monitors:
repos:
- openstack/masakari-monitors
masakari-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Masakari - Instances High Availability Service Mission: Provide instances high availability service for OpenStack clouds by automatically recover the instances from failures. We are mainly focus on solve the problems addressed in High Availability for Virtual Machines Development Proposal [1]. Project History: Engineers from NTT started this project on github [2] in Jul 2015 under Apache License 2.0. Newton design Summit in Austin, Masakari team and OpenStack HA team discussed how to implement this feature in OpenStack [3]. As Masakari team agreed to re-architecte masakari, we started a new project openstack/masakari [4] and re-architect and rebuild the [2] with OpenStack standards. We continually discussed this topic in OpenStack HA team [5] and we present our plane to moving into a converged upstream solution for-instances high-availability in Boston Summit [6]. Masakari is an essential component of this solution. Satisfaction of new projects requirements: Masakari projects follow the 4 opens, * Open Source: All Masakari source codes, specifications, and documentations are use Apache License 2.0. All library dependencies allow for unrestricted distribution and deployment. * Open Community: We holds weekly IRC meetings in #openstack-meeting and weekly agenda, meeting time, and link for previous meeting logs are in our wiki page[7]. We are also available in #openstack-masakari IRC channel for daily discussion. All the channels are open for anyone to interact with Masakari team. * Open Development: Masakari uses Gerrit for code reviews and Launchpad for bugs and blueprints tracking [8]. Project core team checks all the changes before merging them. The project is integrated with the Openstack CI, and runs pep8, py27, and py35 jobs. Masakari is implemented using libraries and technologies adopted by other existing OpenStack projects. * Open Design: The Masakari team has been publicly discussed project direction, issues, work items and priorities in etherpad [9-11] and in the weekly IRC meetings. We use masakari-specs [12] to discuss design specifications for all Masakari projects. We also use openstack-dev ML with prefix [masakari] for project discussion. Masakari is compatible with OpenStack APIs, and uses Keystone middleware to integrate with OpenStack Identity. The Masakari team is happy to participate in any goals specified by the TC, and meet any policies that the TC requires all projects to meet. [1] http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html [2] https://github.com/ntt-sic/masakari [3] https://etherpad.openstack.org/p/newton-instance-ha [4] https://github.com/openstack/masakari [5] https://wiki.openstack.org/wiki/Meetings/HATeamMeeting [6] https://www.openstack.org/videos/boston-2017/high-availability-for-instances-moving-to-a-converged-upstream-solution [7] https://wiki.openstack.org/wiki/Meetings/Masakari [8] https://wiki.openstack.org/wiki/Masakari#Code_and_Bug.2FFeature_trackers [9] https://etherpad.openstack.org/p/ocata-priorities-masakari [10] https://etherpad.openstack.org/p/masakari-pike-workitems [11] https://etherpad.openstack.org/p/masakari-queens-workitems [12] https://review.openstack.org/#/q/project:openstack/masakari-specs Change-Id: I99f7bfbf785f79d235a51ca8acc8810c4805694c
2017-09-02 01:09:20 +09:00
repos:
- openstack/masakari-specs
python-masakariclient:
repos:
- openstack/python-masakariclient
Add project repository Added masakari-dashboard repository under masakari project. Depends-On: Ia86bd9522e0f8e8d00324757e03956407c595ba5 Change-Id: I39e2c62c0c4c1ca87855824c367e8d9f84224848
2017-10-31 13:32:48 +05:30
masakari-dashboard:
repos:
- openstack/masakari-dashboard
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
mistral:
Revert "Adopting the DPL governance model for Mistral" This reverts commit cfba0f3435a84608983c0c860347d301312f9a9e. Reason for revert : For the new cycle Bobcat, there is at least one candidacy made for Mistral PTL position. Change-Id: I5dca14695dbf476dfea7e7e1757070389c74a1c5
2023-02-09 13:29:23 +00:00
ptl:
Adding Axel Vanzaghi as PTL for Mistral Change-Id: I1248cb432286c25911803eda9a28e23a3573cfed
2024-09-04 13:24:13 +00:00
name: Axel Vanzaghi
irc: avanzaghi
email: avanzaghi.osf@axellink.fr
Adding Axel Vanzaghi as PTL candidate for mistral Change-Id: Ib86c9fd387e145c958d21e8ba1c14555e309616b
2023-12-05 09:59:07 +00:00
appointed:
- '2024.1'
Adding Axel Vanzaghi as PTL for Mistral Change-Id: I1248cb432286c25911803eda9a28e23a3573cfed
2024-09-04 13:24:13 +00:00
- '2025.1'
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-mistral
service: Workflow service
mission: >
Provide a simple YAML-based language to write workflows (tasks and
transition rules) and a service that allows to upload them, modify, run
them at scale and in a highly available manner, manage and monitor
workflow execution state and state of individual tasks.
url: https://wiki.openstack.org/wiki/Mistral
deliverables:
mistral:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/mistral
Make mistral-dashboard a separate deliverable mistral-dashboard is the only horizon plugin which is not marked as horizon plugin in the releases repo now as mistral-dashboard is released as part of the mistral deliverable. Note that deliverables defined in releases repo should match deliverables defined in the governance repo and the release team suggested to update the deliverable definition in the governance repo first (with ACK from the mistral team). By making mistral-dashboard a separate deliberable, we can mark mistral-dashboard as horizon plugin (via the release repo). Consumers can find mistral-dashboard in the "Horizon Plugins" section in releases.openstack.org. In addition, the horizon team uses deliverable files in the release repo to recognize the list of the horizon plugins so making mistral-dashboard a separate deliverable would help the horizon team. A dashboard implementation is usually not tightly coupled with a corresponding server side implementation, so I believe changing it to a separate deliverable would have no side effect and the mistral team can continue the current release model. Change-Id: I0f93bac85965e6774c500c3580d86ccad0b49f4e
2019-12-23 13:36:30 +09:00
mistral-dashboard:
repos:
- openstack/mistral-dashboard
Adding mistral specs repo After discussion with Mistral core team, we decided to adopt the specification approval process, like other official projects. Change-Id: I7da1ffaee454383704beb94b0c2bc9786dd1846f
2015-11-09 10:06:37 +08:00
mistral-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Adding mistral specs repo After discussion with Mistral core team, we decided to adopt the specification approval process, like other official projects. Change-Id: I7da1ffaee454383704beb94b0c2bc9786dd1846f
2015-11-09 10:06:37 +08:00
repos:
- openstack/mistral-specs
Add mistral-tempest-plugin to mistral project Create a new repository for mistral's tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: I61ba384e25c860d245efe042d0bfc92cb6af89ea Change-Id: I26e55c2414325530178d125b385a6fa634ef954a
2017-12-02 18:27:23 +05:30
mistral-tempest-plugin:
repos:
- openstack/mistral-tempest-plugin
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-mistralclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-mistralclient
Add mistral-lib to governance list mistral-lib contains data types, exceptions, functions and utilities common to Mistral, python-mistralclient and mistral-extra repositories. This library also contains the public interfaces for 3rd party integration (e.g. Actions API, YAQL functions API, etc.) Other projects such as tripleo-common will denpend on mistral-lib to define its own customized mistral actions. mistral-lib needs to be in governance list for release. Depends-On: I374b51c6c8991e59304afd402dad9f1364e71770 Change-Id: I6c6a7b1a5f50db67f8dc7cdc359112e484bc225b
2017-04-07 13:10:28 +12:00
mistral-lib:
repos:
- openstack/mistral-lib
Make 'mistral-extra' a separate deliverable * 'mistral-extra' repo is now becoming an independent deliverable related to Mistral. We've already moved OpenStack actions over to 'mistral-extra' and ripping them out from the main 'mistral-repo'. So 'mistral-extra' should now be a separate dependency for projects (e.g. TripleO) that want to use OpenStack actions. We're also planning to put more things into this repository like other types of actions or YAQL functions, common utilities used for developing actions, management tools etc. Change-Id: Id265f6d8a73166f25ae24c18b7f52f5f9aa3baeb
2020-02-21 11:37:11 +07:00
mistral-extra:
repos:
- openstack/mistral-extra
Adding Monasca to OpenStack Monasca provides a multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution for metrics. Metrics can be published to the Monasca API, stored and queried. Alarms can be created and notifications, such as email, can be sent when alarms transition state. Support for complex event processing and logging is in progress. Monasca builds an extensible platform for advanced monitoring services that can be used by both operators and tenants to gain operational insight and visibilty, ensuring availabilty and stability. All code has been developed under an Apache 2.0 license and has no restrictions on distribution or deployment. All Monasca code is submitted and reviewed through OpenStack Gerrit [1]. The Monasca project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [10]. Monasca integrates in with several OpenStack projects and services. The Monasca API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Keystone middleware is used by the Monasca API. The Monasca project is in the process of integrating with Ceilometer by using the Ceilometer data collection pipeline as well as the Ceilometer API via a Ceilometer to Monasca storage driver, which will enable Monasca to consume OpenStack notifications from other OpenStack services [5]. A monitoring panel has been developer for Horizon. An integration with Heat for auto-scaling support is under active development. Monasca has been running weekly meetings from the start of the project. Meetings are held on Tuesday's at 9:00 AM MST and are open to anyone that wants to attend. Currently, the Monasca PTL is Roland Hochmuth. Regular elections will be held to elect new PTLs and core members. Monasca was initially discussed at the Atlanta Summit. The first Monasca mid-cycle meetup was held in August 2014 at which three companies attended. At the Paris Summit a session on Monsca was held. In addition, at the Paris Summit, there as a design summit session held to discuss areas for collaboration between Ceilometer and Monasca. A Monasca Liberty mid-cycle meetup was held on August 7-8, 2015, and included six companies [9]. Monasca is planning on holding Monasca specific sessions at the Tokyo Summit as well as joint sessions with other OpenStack projects. Monasca is interested in developing integrations with Ceilometer, Heat, Mistral, Congress and others. There have been several local meetups on Monasca in 2015, including Austin, TX, Boulder, CO, and San Francisco, CA. Monasca has an extensive set of documentation. Overall documentation and links to documentation are at the Monasca Wiki [2]. The Monasca API is documented [3]. The optional Monasca Agent is documented [4]. Monasca has several official deployment solutions available. Ansible roles are available [6]. Puppet modules are available via the openstack organization [7]. Monasca also has a turn-key development environment based on Vagrant, Devstack and Ansible [8]. Monasca integrates with DevStack via a Monasca plugin [11] for DevStack. Tempest tests for Monasca [12] are also available. Monasca is continually deployed to test and production environments off of master branch and maintains a very high level of quality. The first major release of Monasca was tagged for Kilo. The second major release of Monasca will be tagged for Liberty. [1]: https://review.openstack.org/#/q/status:open+monasca,n,z [2]: https://wiki.openstack.org/wiki/Monasca [3]: http://git.openstack.org/cgit/openstack/monasca-api/tree/docs/ monasca-api-spec.md [4]: https://git.openstack.org/openstack/monasca-agent [5]: https://git.openstack.org/openstack/monasca-ceilometer [6]: https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca [7]: https://git.openstack.org/openstack/puppet-monasca [8]: https://git.openstack.org/openstack/monasca-vagrant [9]: https://etherpad.openstack.org/p/monasca_liberty_mid_cycle [10]: https://bugs.launchpad.net/monasca [11]: https://git.openstack.org/openstack/monasca-api/devstack [12]: https://git.openstack.org/openstack/monasca-api/monasca_tempest_tests Change-Id: I04eeb7651167ca2712f525af3f5b2b5d45dacb5f
2015-08-14 08:55:56 -06:00
monasca:
ptl:
Add PTL results from the 2024.2/Dalmatian election Depends-On: If6c157efebc58d1fbe32a61a64f209b4102ac5c8 Change-Id: Ic74bfc853d2d9d045d4c589e1fd6c50afa608423
2024-03-22 09:00:21 +09:00
name: Hasan Acar
Add results from the 2024.1/Caracal election Also clear out existing TC roles and prepare for nominations. Change-Id: I54020dd551b6b84969d783193e19d181cfe9c156
2023-09-21 14:22:53 +10:00
irc: No nick supplied
Add PTL results from the 2024.2/Dalmatian election Depends-On: If6c157efebc58d1fbe32a61a64f209b4102ac5c8 Change-Id: Ic74bfc853d2d9d045d4c589e1fd6c50afa608423
2024-03-22 09:00:21 +09:00
email: hasan.acar@tubitak.gov.tr
Appoint Martin Chacon Piza as Monasca PTL Martin Chacon Piza sent their late candidacy for Monasca PTL position of Xena Cycle - https://review.opendev.org/c/openstack/election/+/779632 Change-Id: I2659940850083e4510c6780e4c39e725b8b6fbae
2021-03-11 13:19:06 -06:00
appointed:
- xena
Appoint Martin Chacon Piza as Monasca PTL Martin Chacon Piza raised late candidacy to server as Monasca PTL position for Yoga Cycle - https://review.opendev.org/c/openstack/election/+/806145 - https://etherpad.opendev.org/p/yoga-leaderless Change-Id: I378ba0c53dd3a4ff6e91d904979891967051886a
2021-09-08 09:47:56 -05:00
- yoga
Appoint Martin as Monasca PTL Martin raised late candidacy for Monasca Zed cycle PTL - https://review.opendev.org/c/openstack/election/+/830129 - https://etherpad.opendev.org/p/zed-leaderless Change-Id: I861e276ca7a043fdee70762590120b706e737b9c
2022-02-27 19:07:34 -06:00
- zed
Appoint Hasan Acar as Monasca PTL Change-Id: Ib7cecb432004736242bdfec5e83793bdff0fe215
2023-05-05 06:14:54 +00:00
- '2023.2'
Adding Monasca to OpenStack Monasca provides a multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution for metrics. Metrics can be published to the Monasca API, stored and queried. Alarms can be created and notifications, such as email, can be sent when alarms transition state. Support for complex event processing and logging is in progress. Monasca builds an extensible platform for advanced monitoring services that can be used by both operators and tenants to gain operational insight and visibilty, ensuring availabilty and stability. All code has been developed under an Apache 2.0 license and has no restrictions on distribution or deployment. All Monasca code is submitted and reviewed through OpenStack Gerrit [1]. The Monasca project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [10]. Monasca integrates in with several OpenStack projects and services. The Monasca API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Keystone middleware is used by the Monasca API. The Monasca project is in the process of integrating with Ceilometer by using the Ceilometer data collection pipeline as well as the Ceilometer API via a Ceilometer to Monasca storage driver, which will enable Monasca to consume OpenStack notifications from other OpenStack services [5]. A monitoring panel has been developer for Horizon. An integration with Heat for auto-scaling support is under active development. Monasca has been running weekly meetings from the start of the project. Meetings are held on Tuesday's at 9:00 AM MST and are open to anyone that wants to attend. Currently, the Monasca PTL is Roland Hochmuth. Regular elections will be held to elect new PTLs and core members. Monasca was initially discussed at the Atlanta Summit. The first Monasca mid-cycle meetup was held in August 2014 at which three companies attended. At the Paris Summit a session on Monsca was held. In addition, at the Paris Summit, there as a design summit session held to discuss areas for collaboration between Ceilometer and Monasca. A Monasca Liberty mid-cycle meetup was held on August 7-8, 2015, and included six companies [9]. Monasca is planning on holding Monasca specific sessions at the Tokyo Summit as well as joint sessions with other OpenStack projects. Monasca is interested in developing integrations with Ceilometer, Heat, Mistral, Congress and others. There have been several local meetups on Monasca in 2015, including Austin, TX, Boulder, CO, and San Francisco, CA. Monasca has an extensive set of documentation. Overall documentation and links to documentation are at the Monasca Wiki [2]. The Monasca API is documented [3]. The optional Monasca Agent is documented [4]. Monasca has several official deployment solutions available. Ansible roles are available [6]. Puppet modules are available via the openstack organization [7]. Monasca also has a turn-key development environment based on Vagrant, Devstack and Ansible [8]. Monasca integrates with DevStack via a Monasca plugin [11] for DevStack. Tempest tests for Monasca [12] are also available. Monasca is continually deployed to test and production environments off of master branch and maintains a very high level of quality. The first major release of Monasca was tagged for Kilo. The second major release of Monasca will be tagged for Liberty. [1]: https://review.openstack.org/#/q/status:open+monasca,n,z [2]: https://wiki.openstack.org/wiki/Monasca [3]: http://git.openstack.org/cgit/openstack/monasca-api/tree/docs/ monasca-api-spec.md [4]: https://git.openstack.org/openstack/monasca-agent [5]: https://git.openstack.org/openstack/monasca-ceilometer [6]: https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca [7]: https://git.openstack.org/openstack/puppet-monasca [8]: https://git.openstack.org/openstack/monasca-vagrant [9]: https://etherpad.openstack.org/p/monasca_liberty_mid_cycle [10]: https://bugs.launchpad.net/monasca [11]: https://git.openstack.org/openstack/monasca-api/devstack [12]: https://git.openstack.org/openstack/monasca-api/monasca_tempest_tests Change-Id: I04eeb7651167ca2712f525af3f5b2b5d45dacb5f
2015-08-14 08:55:56 -06:00
irc-channel: openstack-monasca
service: Monitoring
mission: >
To provide a multi-tenant, highly scalable, performant, fault-tolerant
monitoring-as-a-service solution for metrics, complex event processing
and logging. To build an extensible platform for advanced monitoring
services that can be used by both operators and tenants to gain
operational insight and visibility, ensuring availability and stability.
url: https://wiki.openstack.org/wiki/Monasca
deliverables:
Update Monasca deliverables and release tags Change-Id: I575a097306d720673c069dbe531804a698472acc
2016-02-01 13:58:26 -07:00
monasca-api:
Adding Monasca to OpenStack Monasca provides a multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution for metrics. Metrics can be published to the Monasca API, stored and queried. Alarms can be created and notifications, such as email, can be sent when alarms transition state. Support for complex event processing and logging is in progress. Monasca builds an extensible platform for advanced monitoring services that can be used by both operators and tenants to gain operational insight and visibilty, ensuring availabilty and stability. All code has been developed under an Apache 2.0 license and has no restrictions on distribution or deployment. All Monasca code is submitted and reviewed through OpenStack Gerrit [1]. The Monasca project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [10]. Monasca integrates in with several OpenStack projects and services. The Monasca API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Keystone middleware is used by the Monasca API. The Monasca project is in the process of integrating with Ceilometer by using the Ceilometer data collection pipeline as well as the Ceilometer API via a Ceilometer to Monasca storage driver, which will enable Monasca to consume OpenStack notifications from other OpenStack services [5]. A monitoring panel has been developer for Horizon. An integration with Heat for auto-scaling support is under active development. Monasca has been running weekly meetings from the start of the project. Meetings are held on Tuesday's at 9:00 AM MST and are open to anyone that wants to attend. Currently, the Monasca PTL is Roland Hochmuth. Regular elections will be held to elect new PTLs and core members. Monasca was initially discussed at the Atlanta Summit. The first Monasca mid-cycle meetup was held in August 2014 at which three companies attended. At the Paris Summit a session on Monsca was held. In addition, at the Paris Summit, there as a design summit session held to discuss areas for collaboration between Ceilometer and Monasca. A Monasca Liberty mid-cycle meetup was held on August 7-8, 2015, and included six companies [9]. Monasca is planning on holding Monasca specific sessions at the Tokyo Summit as well as joint sessions with other OpenStack projects. Monasca is interested in developing integrations with Ceilometer, Heat, Mistral, Congress and others. There have been several local meetups on Monasca in 2015, including Austin, TX, Boulder, CO, and San Francisco, CA. Monasca has an extensive set of documentation. Overall documentation and links to documentation are at the Monasca Wiki [2]. The Monasca API is documented [3]. The optional Monasca Agent is documented [4]. Monasca has several official deployment solutions available. Ansible roles are available [6]. Puppet modules are available via the openstack organization [7]. Monasca also has a turn-key development environment based on Vagrant, Devstack and Ansible [8]. Monasca integrates with DevStack via a Monasca plugin [11] for DevStack. Tempest tests for Monasca [12] are also available. Monasca is continually deployed to test and production environments off of master branch and maintains a very high level of quality. The first major release of Monasca was tagged for Kilo. The second major release of Monasca will be tagged for Liberty. [1]: https://review.openstack.org/#/q/status:open+monasca,n,z [2]: https://wiki.openstack.org/wiki/Monasca [3]: http://git.openstack.org/cgit/openstack/monasca-api/tree/docs/ monasca-api-spec.md [4]: https://git.openstack.org/openstack/monasca-agent [5]: https://git.openstack.org/openstack/monasca-ceilometer [6]: https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca [7]: https://git.openstack.org/openstack/puppet-monasca [8]: https://git.openstack.org/openstack/monasca-vagrant [9]: https://etherpad.openstack.org/p/monasca_liberty_mid_cycle [10]: https://bugs.launchpad.net/monasca [11]: https://git.openstack.org/openstack/monasca-api/devstack [12]: https://git.openstack.org/openstack/monasca-api/monasca_tempest_tests Change-Id: I04eeb7651167ca2712f525af3f5b2b5d45dacb5f
2015-08-14 08:55:56 -06:00
repos:
- openstack/monasca-api
Update Monasca deliverables and release tags Change-Id: I575a097306d720673c069dbe531804a698472acc
2016-02-01 13:58:26 -07:00
monasca-log-api:
Record Deprecation cycle for monasca-ceilometer monasca-log-api Both of these repos have been deprecated in the Ussuri cycle - https://review.opendev.org/c/openstack/monasca-ceilometer/+/720319 - https://review.opendev.org/c/openstack/monasca-log-api/+/704519 ML ref: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019892.html Though we did clean deprecation in Wallaby cycle but as actual deprecation happened in the Ussuri and no release after Train we should record deprecation cycle as Ussuri. Change-Id: I13ad212d2c66999a8628e6f44d052d6b07dfc510
2021-03-29 09:08:03 -05:00
deprecated: ussuri
release-management: deprecated
Update Monasca deliverables and release tags Change-Id: I575a097306d720673c069dbe531804a698472acc
2016-02-01 13:58:26 -07:00
repos:
Add monasca-log-api to Monasca project Change-Id: Icb33a786d641f1be693a4927285e1c9b374ae7ed
2015-12-03 09:10:56 +01:00
- openstack/monasca-log-api
Add monasca-events-api Add monasca-events-api to monasca project. Change-Id: I219fc4d5ce70e9871a1f2d6bd8748763c6ee52e7
2017-08-07 10:49:21 +02:00
monasca-events-api:
repos:
- openstack/monasca-events-api
Add monasca-specs repository Change-Id: Id0cbaa7d7367b1e9f30a838caf1c5400bb1ea279 Depends-On: I1c566fb4a9d2570988b9a90f6e8a1dd4bc0b9e6b
2017-08-31 13:39:43 +02:00
monasca-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add monasca-specs repository Change-Id: Id0cbaa7d7367b1e9f30a838caf1c5400bb1ea279 Depends-On: I1c566fb4a9d2570988b9a90f6e8a1dd4bc0b9e6b
2017-08-31 13:39:43 +02:00
repos:
- openstack/monasca-specs
Update Monasca deliverables and release tags Change-Id: I575a097306d720673c069dbe531804a698472acc
2016-02-01 13:58:26 -07:00
monasca-notification:
repos:
- openstack/monasca-notification
monasca-persister:
repos:
Adding Monasca to OpenStack Monasca provides a multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution for metrics. Metrics can be published to the Monasca API, stored and queried. Alarms can be created and notifications, such as email, can be sent when alarms transition state. Support for complex event processing and logging is in progress. Monasca builds an extensible platform for advanced monitoring services that can be used by both operators and tenants to gain operational insight and visibilty, ensuring availabilty and stability. All code has been developed under an Apache 2.0 license and has no restrictions on distribution or deployment. All Monasca code is submitted and reviewed through OpenStack Gerrit [1]. The Monasca project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [10]. Monasca integrates in with several OpenStack projects and services. The Monasca API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Keystone middleware is used by the Monasca API. The Monasca project is in the process of integrating with Ceilometer by using the Ceilometer data collection pipeline as well as the Ceilometer API via a Ceilometer to Monasca storage driver, which will enable Monasca to consume OpenStack notifications from other OpenStack services [5]. A monitoring panel has been developer for Horizon. An integration with Heat for auto-scaling support is under active development. Monasca has been running weekly meetings from the start of the project. Meetings are held on Tuesday's at 9:00 AM MST and are open to anyone that wants to attend. Currently, the Monasca PTL is Roland Hochmuth. Regular elections will be held to elect new PTLs and core members. Monasca was initially discussed at the Atlanta Summit. The first Monasca mid-cycle meetup was held in August 2014 at which three companies attended. At the Paris Summit a session on Monsca was held. In addition, at the Paris Summit, there as a design summit session held to discuss areas for collaboration between Ceilometer and Monasca. A Monasca Liberty mid-cycle meetup was held on August 7-8, 2015, and included six companies [9]. Monasca is planning on holding Monasca specific sessions at the Tokyo Summit as well as joint sessions with other OpenStack projects. Monasca is interested in developing integrations with Ceilometer, Heat, Mistral, Congress and others. There have been several local meetups on Monasca in 2015, including Austin, TX, Boulder, CO, and San Francisco, CA. Monasca has an extensive set of documentation. Overall documentation and links to documentation are at the Monasca Wiki [2]. The Monasca API is documented [3]. The optional Monasca Agent is documented [4]. Monasca has several official deployment solutions available. Ansible roles are available [6]. Puppet modules are available via the openstack organization [7]. Monasca also has a turn-key development environment based on Vagrant, Devstack and Ansible [8]. Monasca integrates with DevStack via a Monasca plugin [11] for DevStack. Tempest tests for Monasca [12] are also available. Monasca is continually deployed to test and production environments off of master branch and maintains a very high level of quality. The first major release of Monasca was tagged for Kilo. The second major release of Monasca will be tagged for Liberty. [1]: https://review.openstack.org/#/q/status:open+monasca,n,z [2]: https://wiki.openstack.org/wiki/Monasca [3]: http://git.openstack.org/cgit/openstack/monasca-api/tree/docs/ monasca-api-spec.md [4]: https://git.openstack.org/openstack/monasca-agent [5]: https://git.openstack.org/openstack/monasca-ceilometer [6]: https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca [7]: https://git.openstack.org/openstack/puppet-monasca [8]: https://git.openstack.org/openstack/monasca-vagrant [9]: https://etherpad.openstack.org/p/monasca_liberty_mid_cycle [10]: https://bugs.launchpad.net/monasca [11]: https://git.openstack.org/openstack/monasca-api/devstack [12]: https://git.openstack.org/openstack/monasca-api/monasca_tempest_tests Change-Id: I04eeb7651167ca2712f525af3f5b2b5d45dacb5f
2015-08-14 08:55:56 -06:00
- openstack/monasca-persister
Add monasca-tempest-plugin to monasca project Create a new repository for monasca's tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: Ifd8429e4ef96034a804514e71852e11829340a87 Change-Id: Ibb1c5975c8618df060e3c2791a7ac186d0e31335
2017-12-09 19:10:29 +05:30
monasca-tempest-plugin:
repos:
- openstack/monasca-tempest-plugin
Update Monasca deliverables and release tags Change-Id: I575a097306d720673c069dbe531804a698472acc
2016-02-01 13:58:26 -07:00
monasca-thresh:
repos:
Adding Monasca to OpenStack Monasca provides a multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution for metrics. Metrics can be published to the Monasca API, stored and queried. Alarms can be created and notifications, such as email, can be sent when alarms transition state. Support for complex event processing and logging is in progress. Monasca builds an extensible platform for advanced monitoring services that can be used by both operators and tenants to gain operational insight and visibilty, ensuring availabilty and stability. All code has been developed under an Apache 2.0 license and has no restrictions on distribution or deployment. All Monasca code is submitted and reviewed through OpenStack Gerrit [1]. The Monasca project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [10]. Monasca integrates in with several OpenStack projects and services. The Monasca API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Keystone middleware is used by the Monasca API. The Monasca project is in the process of integrating with Ceilometer by using the Ceilometer data collection pipeline as well as the Ceilometer API via a Ceilometer to Monasca storage driver, which will enable Monasca to consume OpenStack notifications from other OpenStack services [5]. A monitoring panel has been developer for Horizon. An integration with Heat for auto-scaling support is under active development. Monasca has been running weekly meetings from the start of the project. Meetings are held on Tuesday's at 9:00 AM MST and are open to anyone that wants to attend. Currently, the Monasca PTL is Roland Hochmuth. Regular elections will be held to elect new PTLs and core members. Monasca was initially discussed at the Atlanta Summit. The first Monasca mid-cycle meetup was held in August 2014 at which three companies attended. At the Paris Summit a session on Monsca was held. In addition, at the Paris Summit, there as a design summit session held to discuss areas for collaboration between Ceilometer and Monasca. A Monasca Liberty mid-cycle meetup was held on August 7-8, 2015, and included six companies [9]. Monasca is planning on holding Monasca specific sessions at the Tokyo Summit as well as joint sessions with other OpenStack projects. Monasca is interested in developing integrations with Ceilometer, Heat, Mistral, Congress and others. There have been several local meetups on Monasca in 2015, including Austin, TX, Boulder, CO, and San Francisco, CA. Monasca has an extensive set of documentation. Overall documentation and links to documentation are at the Monasca Wiki [2]. The Monasca API is documented [3]. The optional Monasca Agent is documented [4]. Monasca has several official deployment solutions available. Ansible roles are available [6]. Puppet modules are available via the openstack organization [7]. Monasca also has a turn-key development environment based on Vagrant, Devstack and Ansible [8]. Monasca integrates with DevStack via a Monasca plugin [11] for DevStack. Tempest tests for Monasca [12] are also available. Monasca is continually deployed to test and production environments off of master branch and maintains a very high level of quality. The first major release of Monasca was tagged for Kilo. The second major release of Monasca will be tagged for Liberty. [1]: https://review.openstack.org/#/q/status:open+monasca,n,z [2]: https://wiki.openstack.org/wiki/Monasca [3]: http://git.openstack.org/cgit/openstack/monasca-api/tree/docs/ monasca-api-spec.md [4]: https://git.openstack.org/openstack/monasca-agent [5]: https://git.openstack.org/openstack/monasca-ceilometer [6]: https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca [7]: https://git.openstack.org/openstack/puppet-monasca [8]: https://git.openstack.org/openstack/monasca-vagrant [9]: https://etherpad.openstack.org/p/monasca_liberty_mid_cycle [10]: https://bugs.launchpad.net/monasca [11]: https://git.openstack.org/openstack/monasca-api/devstack [12]: https://git.openstack.org/openstack/monasca-api/monasca_tempest_tests Change-Id: I04eeb7651167ca2712f525af3f5b2b5d45dacb5f
2015-08-14 08:55:56 -06:00
- openstack/monasca-thresh
Update Monasca deliverables and release tags Change-Id: I575a097306d720673c069dbe531804a698472acc
2016-02-01 13:58:26 -07:00
monasca-common:
repos:
Adding Monasca to OpenStack Monasca provides a multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution for metrics. Metrics can be published to the Monasca API, stored and queried. Alarms can be created and notifications, such as email, can be sent when alarms transition state. Support for complex event processing and logging is in progress. Monasca builds an extensible platform for advanced monitoring services that can be used by both operators and tenants to gain operational insight and visibilty, ensuring availabilty and stability. All code has been developed under an Apache 2.0 license and has no restrictions on distribution or deployment. All Monasca code is submitted and reviewed through OpenStack Gerrit [1]. The Monasca project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [10]. Monasca integrates in with several OpenStack projects and services. The Monasca API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Keystone middleware is used by the Monasca API. The Monasca project is in the process of integrating with Ceilometer by using the Ceilometer data collection pipeline as well as the Ceilometer API via a Ceilometer to Monasca storage driver, which will enable Monasca to consume OpenStack notifications from other OpenStack services [5]. A monitoring panel has been developer for Horizon. An integration with Heat for auto-scaling support is under active development. Monasca has been running weekly meetings from the start of the project. Meetings are held on Tuesday's at 9:00 AM MST and are open to anyone that wants to attend. Currently, the Monasca PTL is Roland Hochmuth. Regular elections will be held to elect new PTLs and core members. Monasca was initially discussed at the Atlanta Summit. The first Monasca mid-cycle meetup was held in August 2014 at which three companies attended. At the Paris Summit a session on Monsca was held. In addition, at the Paris Summit, there as a design summit session held to discuss areas for collaboration between Ceilometer and Monasca. A Monasca Liberty mid-cycle meetup was held on August 7-8, 2015, and included six companies [9]. Monasca is planning on holding Monasca specific sessions at the Tokyo Summit as well as joint sessions with other OpenStack projects. Monasca is interested in developing integrations with Ceilometer, Heat, Mistral, Congress and others. There have been several local meetups on Monasca in 2015, including Austin, TX, Boulder, CO, and San Francisco, CA. Monasca has an extensive set of documentation. Overall documentation and links to documentation are at the Monasca Wiki [2]. The Monasca API is documented [3]. The optional Monasca Agent is documented [4]. Monasca has several official deployment solutions available. Ansible roles are available [6]. Puppet modules are available via the openstack organization [7]. Monasca also has a turn-key development environment based on Vagrant, Devstack and Ansible [8]. Monasca integrates with DevStack via a Monasca plugin [11] for DevStack. Tempest tests for Monasca [12] are also available. Monasca is continually deployed to test and production environments off of master branch and maintains a very high level of quality. The first major release of Monasca was tagged for Kilo. The second major release of Monasca will be tagged for Liberty. [1]: https://review.openstack.org/#/q/status:open+monasca,n,z [2]: https://wiki.openstack.org/wiki/Monasca [3]: http://git.openstack.org/cgit/openstack/monasca-api/tree/docs/ monasca-api-spec.md [4]: https://git.openstack.org/openstack/monasca-agent [5]: https://git.openstack.org/openstack/monasca-ceilometer [6]: https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca [7]: https://git.openstack.org/openstack/puppet-monasca [8]: https://git.openstack.org/openstack/monasca-vagrant [9]: https://etherpad.openstack.org/p/monasca_liberty_mid_cycle [10]: https://bugs.launchpad.net/monasca [11]: https://git.openstack.org/openstack/monasca-api/devstack [12]: https://git.openstack.org/openstack/monasca-api/monasca_tempest_tests Change-Id: I04eeb7651167ca2712f525af3f5b2b5d45dacb5f
2015-08-14 08:55:56 -06:00
- openstack/monasca-common
monasca-ui:
repos:
- openstack/monasca-ui
python-monascaclient:
repos:
- openstack/python-monascaclient
monasca-agent:
repos:
- openstack/monasca-agent
monasca-statsd:
repos:
- openstack/monasca-statsd
monasca-ceilometer:
Record Deprecation cycle for monasca-ceilometer monasca-log-api Both of these repos have been deprecated in the Ussuri cycle - https://review.opendev.org/c/openstack/monasca-ceilometer/+/720319 - https://review.opendev.org/c/openstack/monasca-log-api/+/704519 ML ref: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019892.html Though we did clean deprecation in Wallaby cycle but as actual deprecation happened in the Ussuri and no release after Train we should record deprecation cycle as Ussuri. Change-Id: I13ad212d2c66999a8628e6f44d052d6b07dfc510
2021-03-29 09:08:03 -05:00
deprecated: ussuri
release-management: deprecated
Adding Monasca to OpenStack Monasca provides a multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution for metrics. Metrics can be published to the Monasca API, stored and queried. Alarms can be created and notifications, such as email, can be sent when alarms transition state. Support for complex event processing and logging is in progress. Monasca builds an extensible platform for advanced monitoring services that can be used by both operators and tenants to gain operational insight and visibilty, ensuring availabilty and stability. All code has been developed under an Apache 2.0 license and has no restrictions on distribution or deployment. All Monasca code is submitted and reviewed through OpenStack Gerrit [1]. The Monasca project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [10]. Monasca integrates in with several OpenStack projects and services. The Monasca API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Keystone middleware is used by the Monasca API. The Monasca project is in the process of integrating with Ceilometer by using the Ceilometer data collection pipeline as well as the Ceilometer API via a Ceilometer to Monasca storage driver, which will enable Monasca to consume OpenStack notifications from other OpenStack services [5]. A monitoring panel has been developer for Horizon. An integration with Heat for auto-scaling support is under active development. Monasca has been running weekly meetings from the start of the project. Meetings are held on Tuesday's at 9:00 AM MST and are open to anyone that wants to attend. Currently, the Monasca PTL is Roland Hochmuth. Regular elections will be held to elect new PTLs and core members. Monasca was initially discussed at the Atlanta Summit. The first Monasca mid-cycle meetup was held in August 2014 at which three companies attended. At the Paris Summit a session on Monsca was held. In addition, at the Paris Summit, there as a design summit session held to discuss areas for collaboration between Ceilometer and Monasca. A Monasca Liberty mid-cycle meetup was held on August 7-8, 2015, and included six companies [9]. Monasca is planning on holding Monasca specific sessions at the Tokyo Summit as well as joint sessions with other OpenStack projects. Monasca is interested in developing integrations with Ceilometer, Heat, Mistral, Congress and others. There have been several local meetups on Monasca in 2015, including Austin, TX, Boulder, CO, and San Francisco, CA. Monasca has an extensive set of documentation. Overall documentation and links to documentation are at the Monasca Wiki [2]. The Monasca API is documented [3]. The optional Monasca Agent is documented [4]. Monasca has several official deployment solutions available. Ansible roles are available [6]. Puppet modules are available via the openstack organization [7]. Monasca also has a turn-key development environment based on Vagrant, Devstack and Ansible [8]. Monasca integrates with DevStack via a Monasca plugin [11] for DevStack. Tempest tests for Monasca [12] are also available. Monasca is continually deployed to test and production environments off of master branch and maintains a very high level of quality. The first major release of Monasca was tagged for Kilo. The second major release of Monasca will be tagged for Liberty. [1]: https://review.openstack.org/#/q/status:open+monasca,n,z [2]: https://wiki.openstack.org/wiki/Monasca [3]: http://git.openstack.org/cgit/openstack/monasca-api/tree/docs/ monasca-api-spec.md [4]: https://git.openstack.org/openstack/monasca-agent [5]: https://git.openstack.org/openstack/monasca-ceilometer [6]: https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca [7]: https://git.openstack.org/openstack/puppet-monasca [8]: https://git.openstack.org/openstack/monasca-vagrant [9]: https://etherpad.openstack.org/p/monasca_liberty_mid_cycle [10]: https://bugs.launchpad.net/monasca [11]: https://git.openstack.org/openstack/monasca-api/devstack [12]: https://git.openstack.org/openstack/monasca-api/monasca_tempest_tests Change-Id: I04eeb7651167ca2712f525af3f5b2b5d45dacb5f
2015-08-14 08:55:56 -06:00
repos:
- openstack/monasca-ceilometer
Add openstack/monasca-transform project The monasca-transform project is a new component in Monasca that will aggregate and transform metrics. For example, it will consume metrics for Swift from the Monasca metrics topic and count the total number of times a container or object is accessed and group them by project. Then it will publish the aggregated metric to the Kafka metrics topic where the rest of the existing Monasca components will be used to store, alarm and notify. Change-Id: I9227a6afb468e05aaeb939930b872d1c64f79551 Depends-On: I7826768e174a229bc184ea38d75d212ac957e26c
2016-04-04 13:41:40 -06:00
monasca-transform:
Record monasca-transform deprecation This project have been tagged as deprecated 6 months ago however it still appear as maintained/released in the governance repo and therefore it is reflected as maintained on the release side too. - https://review.opendev.org/c/openstack/monasca-transform/+/751984/ - http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016814.html This is basically doing last step of repo deprecation - https://docs.openstack.org/project-team-guide/repository.html#step-4-mark-the-repository-as-deprecated-in-the-governance-repository Change-Id: Iccc5b6b03432fa1585c695762504bd1407cdf45f
2021-03-29 09:33:27 -05:00
deprecated: victoria
release-management: deprecated
Add openstack/monasca-transform project The monasca-transform project is a new component in Monasca that will aggregate and transform metrics. For example, it will consume metrics for Swift from the Monasca metrics topic and count the total number of times a container or object is accessed and group them by project. Then it will publish the aggregated metric to the Kafka metrics topic where the rest of the existing Monasca components will be used to store, alarm and notify. Change-Id: I9227a6afb468e05aaeb939930b872d1c64f79551 Depends-On: I7826768e174a229bc184ea38d75d212ac957e26c
2016-04-04 13:41:40 -06:00
repos:
- openstack/monasca-transform
Add openstack/monasca-grafana-datasource project The monasca-grafana-datasource project is a new component in Monasca that will add support for Monasca as a datasource to Grafana. Change-Id: I55e0b5a7c5cc732b688a7b7c679c69598ea70311 Depends-On: I7b673d9680e6b92e234bf46d0ac66b13f6bf8ce9
2016-07-12 14:28:49 -06:00
monasca-grafana-datasource:
repos:
- openstack/monasca-grafana-datasource
Add monasca-kibana-plugin project Change-Id: I4d87657636b74465c01063d399898852693ba024 Depends-On: Idf2b6e36a507052da88dc7bbf89c9dbe983c66b4
2017-01-16 16:15:48 +01:00
monasca-kibana-plugin:
repos:
- openstack/monasca-kibana-plugin
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
neutron:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Add results from the 2024.1/Caracal election Also clear out existing TC roles and prepare for nominations. Change-Id: I54020dd551b6b84969d783193e19d181cfe9c156
2023-09-21 14:22:53 +10:00
name: Brian Haley
irc: haleyb
email: haleyb.dev@gmail.com
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-neutron
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Networking service
use ">" to indicate multiline mission statements ">" indicates to YAML that the multiline string which follows is intended to ignore the line breaks contained within. Also includes some related whitespace cleanup. Change-Id: I6403c1d5663f9575c0d6ada2f1e672e743e451f3
2014-07-23 10:40:47 -05:00
mission: >
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
To implement services and associated libraries to provide on-demand,
scalable, and technology-agnostic network abstraction.
url: https://wiki.openstack.org/wiki/Neutron
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
Add networking-bagpipe to the Neutron repository list Change-Id: I369a261987e841ef93d4b076620f5066a41b7d24 Signed-off-by: Kyle Mestery <mestery@mestery.com>
2015-11-12 11:17:29 -05:00
networking-bagpipe:
repos:
- openstack/networking-bagpipe
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
networking-bgpvpn:
repos:
- openstack/networking-bgpvpn
networking-midonet:
Deprecate networking-midonet project As per discussion in [1], we need to deprecate networking-midonet as official Neutron stadium project due to lack of maintainers. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021400.html Change-Id: I56a8767fc5cff25a6605c9e9a1c03d1d7f04140d
2021-03-30 08:58:09 +02:00
deprecated: wallaby
release-management: deprecated
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
- openstack/networking-midonet
networking-odl:
Add TC/PTL results from 2025.1 election Also clear out existing TC roles and prepare for nominations. Depends-On: Id5847c7c37d556b11932dae542f4aaeb699cf7ec Change-Id: I7760c815d032c7aaff9956588b6ce5c1fb7b4750
2024-09-19 23:17:25 +09:00
deprecated: '2023.2'
Deprecation of networking-odl The decision was taken during a Neutron team meeting and communicated via mailing list [1]. Due to the lack of mantainers, this project is deprecated during Bobcat (2023.3) release. [1]https://lists.openstack.org/pipermail/openstack-discuss/2023-March/033003.html Change-Id: If6b6348bf91ed33cc9e63f8394de4279ae8ef9e7
2023-05-23 20:32:19 +02:00
release-management: deprecated
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
- openstack/networking-odl
networking-sfc:
repos:
- openstack/networking-sfc
Revisit the Neutron list of repos LBaaS, FWaaS, VPNaaS and Dynamic Routing are listed as part of the Neutron deliverable. These components have always been meant to be optionally deployed, and like the other deliverables, they should be described individually. As a result, they each get their own tags depending on the level of compliance with the tag definition. Change-Id: I3e86210ffbeceec8783b58120367fb8cd8f162dc
2016-05-31 11:16:36 -07:00
neutron-fwaas:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
- openstack/neutron-fwaas
Revisit the Neutron list of repos LBaaS, FWaaS, VPNaaS and Dynamic Routing are listed as part of the Neutron deliverable. These components have always been meant to be optionally deployed, and like the other deliverables, they should be described individually. As a result, they each get their own tags depending on the level of compliance with the tag definition. Change-Id: I3e86210ffbeceec8783b58120367fb8cd8f162dc
2016-05-31 11:16:36 -07:00
neutron:
repos:
- openstack/neutron
neutron-dynamic-routing:
repos:
- openstack/neutron-dynamic-routing
Add neutron-lib repository to neutron project. Related spec: https://review.openstack.org/#/c/239792/ Change-Id: I16d9fbe570e05946bbc430907d85e11e45098f06
2015-10-30 10:00:37 +09:00
neutron-lib:
repos:
- openstack/neutron-lib
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
neutron-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
- openstack/neutron-specs
Add neutron-tempest-plugin to neutron project Create a new repository for Neutron's tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: I5a6f049f9d0857408caa5b80028e1a64bfb190e4 Change-Id: I62130c54a6ca111eed7cc828f5fe0df388095bc0
2017-09-09 15:08:54 +05:30
neutron-tempest-plugin:
repos:
- openstack/neutron-tempest-plugin
Add ovn-octavia-provider project The Neutron community decided to merge Networking-ovn project tree to Neutron tree [0]. This change requires an extract of the OVN Octavia provider driver to a separate repository. This patch adds the 'openstack/ovn-octavia-provider' repository to the Neutron project. [0] https://review.opendev.org/#/c/658414/ Depends-On: https://review.openstack.org/#/c/697076/ Change-Id: Ie7c407eb5eea48491131344118d47155704f9c91
2019-12-03 15:17:36 +01:00
ovn-octavia-provider:
repos:
- openstack/ovn-octavia-provider
Add ovsdbapp project The ovsdb api code from Neutron is used in at least 4 other projects, so it makes sense to move it into its own project. neutron_lib isn't a good fit because this code depends on Python code from the OVS project and users of neutron_lib shouldn't be forced to install OVS. Change-Id: Idf3dcca7e94fad49725fa427fbf874c674fdfd6a Depends-On: Icd9be59f8c4e41801e30734d332c572e08680087
2017-02-24 16:35:11 -05:00
ovsdbapp:
repos:
- openstack/ovsdbapp
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-neutronclient:
repos:
- openstack/python-neutronclient
Add neutron-fwaas-dashboard to neutron project neutron-fwaas support will be split out from the main horizon repo and maintained in the new repository under neutron(-fwaas) team. Depends-On: I667d4906ae540a5cf5d92918ea097df46acba7a3 Change-Id: Iccd493aa10cf5829f193c5157a55dc4f1d65f7fc
2017-06-16 22:43:23 +09:00
neutron-fwaas-dashboard:
repos:
- openstack/neutron-fwaas-dashboard
Update list of Neutron governed projects After latest assesment [1], openstack/neutron-vpnaas has been deemed fit to re-join the Neutron governance [1] https://review.openstack.org/#/c/506012 Change-Id: I8c89a62566fdb332450b07448e96058933852675
2017-12-11 16:28:24 -06:00
neutron-vpnaas:
repos:
- openstack/neutron-vpnaas
neutron-vpnaas-dashboard:
repos:
- openstack/neutron-vpnaas-dashboard
Add openstack/os-ken to neutron Neutron uses extensively the RYU framework (https://osrg.github.io/ryu/) in its openflow related code. The group maintaining RYU has advised the Neutron team that maintenance work will not continue after the end of 2018. According to the discussion at Vancouver Summit, the general consensus is to fork the RYU library under openstack namespace. Neutron team will be responsible to maintain the fork. To avoid confusion between the fork and the original library, the neutron team picks a different name for the fork, which is "os-ken". Depends-On: I1f94028a883eeba75d6697a4bcc4373a16569feb Implements blueprint: ryu-framework-maintenace-transition Change-Id: I4d320175dd1ab7dd66cbd8e5432c8f407bad75a5
2018-08-02 18:15:52 +00:00
os-ken:
repos:
- openstack/os-ken
Add tap-as-a-service to Neutron governed projects tap-as-a-service and tap-as-a-service-tempest-plugin moved from x/ namespace to openstack/ and under Neutron governance. Change-Id: Iafc55044e60d81ae2a460327cab20c3f861184a4 Depends-On: https://review.opendev.org/c/openstack/project-config/+/790093
2021-07-29 09:35:48 +02:00
tap-as-a-service:
repos:
- openstack/tap-as-a-service
Add ovn-bgp-agent to Neutron governed projects During the Bobcat PTG it was discussed and accepted the inclusion of the ovn-bgp-agent project under the Neutron governance. Depends-On: https://review.opendev.org/c/openstack/project-config/+/879456 Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com> Change-Id: Ib41769b65d3f67645d4c862f7c75119b16a02311
2023-04-04 14:24:51 +01:00
ovn-bgp-agent:
repos:
- openstack/ovn-bgp-agent
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
nova:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Update projects.yaml for Yoga PTLs This reflects the election results of Yoga PTLs confirmed by election officials. Depends-On: I243e74e51ec23709e33c3ad4ece2ca80cbadf20a Change-Id: I27baf08559b02c8b803b257fda77cbadcc531cc6 Signed-off-by: Andy McCrae <andy.mccrae@gmail.com> Signed-off-by: Ian Y. Choi <ianyrchoi@gmail.com> Signed-off-by: Helena Spease <helena@openinfra.dev> Signed-off-by: Amy Marrich <spotz@demarco.com> Signed-off-by: Belmiro Moreira <moreira.belmiro.email.lists@gmail.com>
2021-09-08 20:32:02 +09:00
name: Sylvain Bauza
irc: bauzas
email: sbauza@redhat.com
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-nova
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Compute service
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
mission: >
To implement services and associated libraries to provide massively
scalable, on demand, self service access to compute resources, including
bare metal, virtual machines, and containers.
url: https://wiki.openstack.org/wiki/Nova
deliverables:
nova:
repos:
- openstack/nova
nova-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/nova-specs
python-novaclient:
repos:
- openstack/python-novaclient
os-vif: add openstack/os-vif repository under Nova team os-vif is a project to define an object model and plugin system to integrate OpenStack network providers (eg Neutron) and OpenStack compute providers (eg Nova) It will be developed jointly by representatives from both the Nova and Neutron teams, but for the sake of governance Nova is set as the owner. Change-Id: Ife95bea0cba68901a8c820c4f32a9782d5735beb Depends-on: Ifc2c1a3198075aafc3fd97f0c5355eb27ba8bc19
2015-11-11 13:18:14 +00:00
os-vif:
repos:
- openstack/os-vif
Move Placement under Nova's governance As it was discussed on the Wallaby PTG[1][2] it was agreed that the Placement project is moved back under Nova due to not having separate leadership available for Placement[3]. [1] https://etherpad.opendev.org/p/nova-wallaby-ptg [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/017927.html Change-Id: Id06cd403ebe6441b074b71ae89f6fdbcdecdb703
2020-11-02 14:20:45 +01:00
placement:
repos:
- openstack/placement
os-traits:
repos:
- openstack/os-traits
osc-placement:
repos:
- openstack/osc-placement
os-resource-classes:
repos:
- openstack/os-resource-classes
Add project Octavia to OpenStack big-tent This involves merging neutron-lbaas into the Octavia project and migrating Octavia out of the neutron stadium, making Octavia the Load Balancing As A Service (LBaaS) project for OpenStack. Specs for exactly how this is going to happen are linked as depends-on. The 'neutron-lbaas' repo will exist during the transition, and eventually be retired with no impact on operators/end users beyond packaging. Change-Id: Ia807a5ad36859a0228aed76c307a97dec8494b7c Depends-On: I5303b04ec2ca5acd525d9b5137f012515a8dc1df Depends-On: I9bc348c6f86f868ec5e9ab2be2ae49947bfbacdc
2016-11-17 15:03:15 -07:00
octavia:
ptl:
Close Xena Elections Depends-On: https://review.opendev.org/c/openstack/election/+/779845 Change-Id: Ideda5fbd4479f9c7821ff03838d6130dd723fa49
2021-03-10 09:32:23 -08:00
name: Gregory Thiemonge
irc: gthiemonge
email: gthiemon@redhat.com
Appoint Adam Harwell as Octavia PTL Appoint Adam Harwell as Octavia PTL for the Wallaby cycle, as he volunteered on IRC during discussions around Octavia's leadership. Change-Id: Ie9f59e5c4c031f097580199bb596f5df4a718f25
2020-10-14 15:25:49 +02:00
appointed:
- wallaby
Add project Octavia to OpenStack big-tent This involves merging neutron-lbaas into the Octavia project and migrating Octavia out of the neutron stadium, making Octavia the Load Balancing As A Service (LBaaS) project for OpenStack. Specs for exactly how this is going to happen are linked as depends-on. The 'neutron-lbaas' repo will exist during the transition, and eventually be retired with no impact on operators/end users beyond packaging. Change-Id: Ia807a5ad36859a0228aed76c307a97dec8494b7c Depends-On: I5303b04ec2ca5acd525d9b5137f012515a8dc1df Depends-On: I9bc348c6f86f868ec5e9ab2be2ae49947bfbacdc
2016-11-17 15:03:15 -07:00
irc-channel: openstack-lbaas
Adding docs to octavia project This patch adds the docs links to the octavia project. It also clarifies the service to match the service type we were asked to use[1]. [1] https://review.openstack.org/#/c/434999/ Change-Id: I8d1ca01c4069f199857ef5565f9a225009df5cc7
2017-06-28 16:32:11 -07:00
service: Load-balancer service
Add project Octavia to OpenStack big-tent This involves merging neutron-lbaas into the Octavia project and migrating Octavia out of the neutron stadium, making Octavia the Load Balancing As A Service (LBaaS) project for OpenStack. Specs for exactly how this is going to happen are linked as depends-on. The 'neutron-lbaas' repo will exist during the transition, and eventually be retired with no impact on operators/end users beyond packaging. Change-Id: Ia807a5ad36859a0228aed76c307a97dec8494b7c Depends-On: I5303b04ec2ca5acd525d9b5137f012515a8dc1df Depends-On: I9bc348c6f86f868ec5e9ab2be2ae49947bfbacdc
2016-11-17 15:03:15 -07:00
mission: >
To provide scalable, on demand, self service access to load-balancer
services, in technology-agnostic manner.
url: https://wiki.openstack.org/wiki/Octavia
deliverables:
octavia:
repos:
- openstack/octavia
octavia-dashboard:
repos:
Add octavia git repos for pike This patch sets up additional octavia git repositories for activities planned for pike. 1. Add python-octaviaclient repo for the octavia OpenStack client. 2. Add octavia-tempest-plugin to allow work to start in pike to clean up the octavia tempest tests and move to the tempest plugin model. 3. Add octavia-dashboard for the octavia horizon plugin. This will make the rename/transition for packagers easier by having a legacy and go-forward repository for the horizon plugin. The I18n work done in ocata will directly apply to the new octavia-dashboard code. Change-Id: I6f6bf2ef7e1028e672fd555e5ed250a70e5c4b77
2017-03-01 11:30:51 -08:00
- openstack/octavia-dashboard
octavia-tempest-plugin:
repos:
- openstack/octavia-tempest-plugin
python-octaviaclient:
repos:
- openstack/python-octaviaclient
Adding openstack/octavia-lib project The Octavia team decided at the PTG that we need to create a new repo, octavia-lib, to provide a library for Octavia provider drivers. This patch adds the 'openstack/octavia-lib' repository to the Octavia project. Depends-On: https://review.openstack.org/#/c/604889/ Change-Id: Iaf7d78ef7cb081e2425d7771fd10713ce6627181
2018-09-24 12:34:18 -07:00
octavia-lib:
repos:
- openstack/octavia-lib
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
OpenStack Charms:
ptl:
Appoint James Page as OpenStack Charms PTL As there was no candidate for OpenStack Charms PTL in the 2024.2 election, I hereby volunteer to take up this role. Change-Id: Ic7d3a5fc4c93d19f490064ae29a2920f58bf23e8
2024-06-11 09:23:43 +01:00
name: James Page
irc: jamespage
email: james.page@canonical.com
Appoint Frode Nordahl as OpenStack Charms PTL Appoint Frode Nordahl as OpenStack Charms PTL for the Wallaby cycle, based on their late self-nomination: http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017686.html Change-Id: I66704e3fa31912a50b2c34dd6964e485d549c7da
2020-10-14 15:18:51 +02:00
appointed:
- wallaby
Appoint Alex as OpenStack Charms PTL Alex raised late candidacy for Charms Zed cycle PTL - https://review.opendev.org/c/openstack/election/+/829676 - https://etherpad.opendev.org/p/zed-leaderless Change-Id: I35673e859282cc9c2a98404052c5e391a6ca252e
2022-02-27 18:44:11 -06:00
- zed
Consider release version as string in projects data We need to use the release version as string, so updating the PTL 'appointment' field and the data in projects.yaml Change-Id: Ib097517f514e68246fb6e27b83e98a1f3f6b8eed
2023-03-10 18:14:20 -06:00
- '2023.1'
- '2023.2'
Appoint James Page as OpenStack Charms PTL As there was no candidate for OpenStack Charms PTL in the 2024.2 election, I hereby volunteer to take up this role. Change-Id: Ic7d3a5fc4c93d19f490064ae29a2920f58bf23e8
2024-06-11 09:23:43 +01:00
- '2024.2'
Add irc-channel for charms The channel #openstack-charms is used by the charms team, let's document it. Change-Id: I1f782397efa13dde5d4720532eb75f155257719a
2016-10-11 14:22:51 +02:00
irc-channel: openstack-charms
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
service: Juju Charms for deployment of OpenStack
mission: >
Develop and maintain Juju Charms for deploying and managing
OpenStack services.
Update docs URLs With the reorg on docs.o.o, the projects publish to new places, adjust all URLs. Also, use https everywhere. Change-Id: I28422350e3e37fb4a9b3905e9ed36e3f98fe0c58
2017-08-22 19:08:18 +02:00
url: https://docs.openstack.org/charm-guide/latest/
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
deliverables:
Add Ceph Charm Shared Lib Adding a shared library to consolidate the ceph charm code into one place. Change-Id: I0ad8931391627e54e53108f8621fbad95dffbc5f
2016-09-07 08:45:49 -07:00
charms.ceph:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Ceph Charm Shared Lib Adding a shared library to consolidate the ceph charm code into one place. Change-Id: I0ad8931391627e54e53108f8621fbad95dffbc5f
2016-09-07 08:45:49 -07:00
repos:
- openstack/charms.ceph
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charms.openstack:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charms.openstack
Add charm-aodh to OpenStack Charms project Add the new Aodh charm to the OpenStack Charms project. Change-Id: Ia9007a8df86ce0a50f117cc20b4ef28cf7fc0fc0 Depends-On: I4dcb020366b2c94a4ed2fdda28669699da9694c1
2016-07-13 11:47:28 +01:00
charm-aodh:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add charm-aodh to OpenStack Charms project Add the new Aodh charm to the OpenStack Charms project. Change-Id: Ia9007a8df86ce0a50f117cc20b4ef28cf7fc0fc0 Depends-On: I4dcb020366b2c94a4ed2fdda28669699da9694c1
2016-07-13 11:47:28 +01:00
repos:
- openstack/charm-aodh
Add barbican charm and barbican-softhsm charm Add the new barbican and barbican-softhsm charms to the OpenStack Charms project. Change-Id: I725ca81468de3cd81e1be44313aefc5cc1360cd7 Depends-On: I4a9f46da5555dd7b27ff5610c3c34e3d23896d2b
2016-07-14 19:48:12 +00:00
charm-barbican:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add barbican charm and barbican-softhsm charm Add the new barbican and barbican-softhsm charms to the OpenStack Charms project. Change-Id: I725ca81468de3cd81e1be44313aefc5cc1360cd7 Depends-On: I4a9f46da5555dd7b27ff5610c3c34e3d23896d2b
2016-07-14 19:48:12 +00:00
repos:
- openstack/charm-barbican
charm-barbican-softhsm:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add barbican charm and barbican-softhsm charm Add the new barbican and barbican-softhsm charms to the OpenStack Charms project. Change-Id: I725ca81468de3cd81e1be44313aefc5cc1360cd7 Depends-On: I4a9f46da5555dd7b27ff5610c3c34e3d23896d2b
2016-07-14 19:48:12 +00:00
repos:
- openstack/charm-barbican-softhsm
Add new charm repositories These charms and interfaces are direct and indirect dependencies for the on-going Octavia charm work. Also amends the ``release-management`` key for the ``charm-octavia`` entry. Change-Id: I2448ed051340ec879542f1e954a8a72c6334838b Depends-On: Ia5bab981b806cb9ca6316b0d9fa7f61456434334
2018-11-06 13:36:44 +01:00
charm-barbican-vault:
release-management: external
repos:
- openstack/charm-barbican-vault
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-ceilometer:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-ceilometer
charm-ceilometer-agent:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-ceilometer-agent
Add Ceph Dashboard charm to OpenStack charms Add new charm that provides the Ceph Dashboard. Depends-On: I56528e76e52dc3a8ae2be0818e248290971fc516 Change-Id: I1221a6ec640d3b3f31a7a26e739e0b6f78324997
2021-06-24 14:47:00 +01:00
charm-ceph-dashboard:
release-management: external
repos:
- openstack/charm-ceph-dashboard
Add Ceph iSCSI charm to OpenStack charms Add Ceph iSCSI charm and corresponding interfaces to OpenStack Charms. Depends-On: I9e385c4206aa6e9a7315099f10c4b2b1530f3e13 Change-Id: I8d2e1af0b03cc68d161ab0ff6f7f631c513ddca6
2020-08-03 15:10:58 +01:00
charm-ceph-iscsi:
release-management: external
repos:
- openstack/charm-ceph-iscsi
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-ceph-mon:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-ceph-mon
Add Ganesha based Ceph NFS Charm Add a new charm that provides CephFS backed NFS shares via the Ganesha service. Change-Id: I75d6105546249d96a211c9607e5ccdaea7736e20 Depends-On: I1111ab9eb53581eec3536b7385c0570dbf4f00ce
2022-03-28 12:16:09 +02:00
charm-ceph-nfs:
release-management: external
repos:
- openstack/charm-ceph-nfs
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-ceph-osd:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-ceph-osd
Add Ceph FS Charm Adding a Ceph FS charm to the charm collection. This will enable users to easily deploy Ceph's MDS server to their cluster. Change-Id: If0c6e917960f8bdb244f07dbe446dc601d7fea6a
2016-10-24 14:57:31 -07:00
charm-ceph-fs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Ceph FS Charm Adding a Ceph FS charm to the charm collection. This will enable users to easily deploy Ceph's MDS server to their cluster. Change-Id: If0c6e917960f8bdb244f07dbe446dc601d7fea6a
2016-10-24 14:57:31 -07:00
repos:
- openstack/charm-ceph-fs
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-ceph-radosgw:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-ceph-radosgw
Add ``ceph-rbd-mirror`` charm and dependencies Change-Id: I027ba8b86ada15f67be823a4955b165853a21d12 Depends-On: Ica61a89c9b6a7fa7ccc1f38f5c7f614f692552d7
2019-02-25 14:02:47 +03:00
charm-ceph-rbd-mirror:
release-management: external
repos:
- openstack/charm-ceph-rbd-mirror
Add ceph-proxy charm Add ceph-proxy charm to the OpenStack charms. Change-Id: I76c062fc8709a51444e541b013f375a79af2b412
2017-03-03 11:41:04 -03:00
charm-ceph-proxy:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add ceph-proxy charm Add ceph-proxy charm to the OpenStack charms. Change-Id: I76c062fc8709a51444e541b013f375a79af2b412
2017-03-03 11:41:04 -03:00
repos:
- openstack/charm-ceph-proxy
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-cinder:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-cinder
charm-cinder-backup:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-cinder-backup
Add ``charm-cinder-backup-swift-proxy`` charm Depends-On: Ia5e5b0933e5b2e5b9865624a4bcb77ba7b2f3eac Change-Id: I8c1dc32ae71ad2261e0a676186458613cd7e151d
2019-11-29 16:25:20 +01:00
charm-cinder-backup-swift-proxy:
release-management: external
repos:
- openstack/charm-cinder-backup-swift-proxy
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-cinder-ceph:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-cinder-ceph
Add the cinder-lvm charm to Openstack charms This charm implements an LVM backend for cinder, acting as a subordinate charm. Change-Id: Ib2c481faa02a289c24c945378682e28b40fa6f33 Depends-On: Ief7d7bc7fbb5b7c0028ead2d507d28700b54ac71
2021-09-02 15:34:10 -03:00
charm-cinder-lvm:
release-management: external
repos:
- openstack/charm-cinder-lvm
Add the cinder-netapp charm to Openstack charms This charm implements a netapp backend for cinder, acting as a subordinate charm. Change-Id: I55b594524c3b5481df2247498f3258169c740f4a Depends-On: I6eaec0ee3ed73672c9b1677adad8d692fce29efc
2021-09-14 17:50:41 -03:00
charm-cinder-netapp:
release-management: external
repos:
- openstack/charm-cinder-netapp
Add cinder-nfs charm to OpenStack charms Add new charm that provides the NFS backend support to the OpenStack Cinder service. Depends-On: I71010276b9b35cb67e3717002377707e1435f9f9 Change-Id: Ib05a81ccf9f3fe80937d4f2c5f2ce339f8df1ade
2023-04-04 18:03:17 +00:00
charm-cinder-nfs:
release-management: external
repos:
- openstack/charm-cinder-nfs
Add the cinder-nimblestorage charm to Openstack charms This charm implements a nimblestorage backend for cinder, acting as a subordinate charm. Depends-On: I93aa9fe3ab089bbeae2b87881bfc931f4ddf0204 Change-Id: I25f5c4e5a209e77352a449129895cd33935190cc
2022-01-13 10:35:08 -04:00
charm-cinder-nimblestorage:
release-management: external
repos:
- openstack/charm-cinder-nimblestorage
New charm for cinder integration with Purestorage Add cinder-purestorage charm for integrating a charmed OpenStack deploy with a purestorage array. Depends-On: Ic4d8e6637e154089b45705865d0b1f9dd9524aee Change-Id: Ic0d803959327a6460f092f121e555192951b908e
2019-09-02 14:48:41 +01:00
charm-cinder-purestorage:
release-management: external
repos:
- openstack/charm-cinder-purestorage
Add the cinder-solidfire charm to Openstack charms This charm implements a solidfire backend for cinder, acting as a subordinate charm. Depends-On: I523074a9578bf5f327608de0a4144a0597a65287 Change-Id: Ia0b48d3e399965a6e138ea18c447eafd6009385c
2022-01-07 10:03:32 -04:00
charm-cinder-solidfire:
release-management: external
repos:
- openstack/charm-cinder-solidfire
Add the cinder-three-par charm to Openstack charms This charm implements a 3PAR backend for cinder, acting as a subordinate charm. Change-Id: I16075836abd321d53089d123a711c586b7597a5c Depends-On: I14c6bd857a09cab07546def009c654738b085c46
2022-04-13 20:24:57 -03:00
charm-cinder-three-par:
release-management: external
repos:
- openstack/charm-cinder-three-par
Add Cinder Dell EMC PowerStore charm Change-Id: I5a0d9e3687f5759180c475aaea72c267707b1e99
2022-06-21 13:50:09 +09:30
charm-cinder-dell-emc-powerstore:
release-management: external
repos:
- openstack/charm-cinder-dell-emc-powerstore
Add cinder ibm storwize charm Change-Id: I78570fd5ce4c28a02fbecb8a19a550196e417bb3
2022-06-21 14:15:26 +09:30
charm-cinder-ibm-storwize-svc:
release-management: external
repos:
- openstack/charm-cinder-ibm-storwize-svc
Add the cinder-infinidat charm to Openstack charms This charm implements Infinidat backend for Cinder, acting as a subordinate charm. Depends-On: Ie4c09e4b93baa3d395877b4a3f28829e9a8716cf Change-Id: I33b90b5dc9e23f146f1d0fc256317a72bd7e0630
2022-11-08 04:59:23 +03:00
charm-cinder-infinidat:
release-management: external
repos:
- openstack/charm-cinder-infinidat
Add new charm Cloudkitty Add Cloudkitty to the charms collection Change-Id: Ib66e153406258598d2f7f842291d4a96631e86ac Depends-on: If38d077a9c93b2e19a449923ef2dac3dac32b747
2016-12-06 11:38:34 +01:00
charm-cloudkitty:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add new charm Cloudkitty Add Cloudkitty to the charms collection Change-Id: Ib66e153406258598d2f7f842291d4a96631e86ac Depends-on: If38d077a9c93b2e19a449923ef2dac3dac32b747
2016-12-06 11:38:34 +01:00
repos:
- openstack/charm-cloudkitty
charms: Add deployment guide Add new charm deployment guide for the OpenStack Charms project. Change-Id: I2307f9bfa39c92422bad8ca94917d5be414c5b61 Depends-On: Ic48e3e6a487303fdd126501206ab76d69e6801fa
2017-07-13 15:31:10 +01:00
charm-deployment-guide:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
charms: Add deployment guide Add new charm deployment guide for the OpenStack Charms project. Change-Id: I2307f9bfa39c92422bad8ca94917d5be414c5b61 Depends-On: Ic48e3e6a487303fdd126501206ab76d69e6801fa
2017-07-13 15:31:10 +01:00
repos:
- openstack/charm-deployment-guide
Add designate charms to OpenStack Charms project Add the new designate and designate-bind charms to the OpenStack Charms project. Depends-On: Ib6cf1ef7c25d71fbe819c19e8a071c1ef0a0ce8a Change-Id: Iff2c511592e424a1780b946a46e54f99bfa98a4b
2016-07-13 12:15:45 +01:00
charm-designate:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add designate charms to OpenStack Charms project Add the new designate and designate-bind charms to the OpenStack Charms project. Depends-On: Ib6cf1ef7c25d71fbe819c19e8a071c1ef0a0ce8a Change-Id: Iff2c511592e424a1780b946a46e54f99bfa98a4b
2016-07-13 12:15:45 +01:00
repos:
- openstack/charm-designate
charm-designate-bind:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add designate charms to OpenStack Charms project Add the new designate and designate-bind charms to the OpenStack Charms project. Depends-On: Ib6cf1ef7c25d71fbe819c19e8a071c1ef0a0ce8a Change-Id: Iff2c511592e424a1780b946a46e54f99bfa98a4b
2016-07-13 12:15:45 +01:00
repos:
- openstack/charm-designate-bind
charms: Add Gnocchi charm and supporting interfaces Add the new Gnocchi charm and supporting charm interfaces to the OpenStack Charms project. Change-Id: I8029883cabe875060487e0a731d3c3f44af645dc Depends-On: Ibcb7ebd25ed5f646aaf1323beeb9acc87a8d07f6
2017-08-02 10:34:21 +01:00
charm-gnocchi:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
charms: Add Gnocchi charm and supporting interfaces Add the new Gnocchi charm and supporting charm interfaces to the OpenStack Charms project. Change-Id: I8029883cabe875060487e0a731d3c3f44af645dc Depends-On: Ibcb7ebd25ed5f646aaf1323beeb9acc87a8d07f6
2017-08-02 10:34:21 +01:00
repos:
- openstack/charm-gnocchi
New charm and interface for placement split Add placement charm and interface that allow for placement API to be split from nova-cloud-controller charm. Depends-On: https://review.opendev.org/686251 Change-Id: I3a73d93656b9d1d0cb63ebbb6095df8f49d357ca
2019-10-02 18:54:16 +00:00
charm-placement:
release-management: external
repos:
- openstack/charm-placement
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-glance:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-glance
charms: add Glance Simplestreams Sync charm Depends-On: I1bdeabb3a19c591efb188745521a56ecc95b3338 Change-Id: I1cc45f59bb8e89e4f0990312137ee87712b5a4ef
2018-05-08 12:55:53 -05:00
charm-glance-simplestreams-sync:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
charms: add Glance Simplestreams Sync charm Depends-On: I1bdeabb3a19c591efb188745521a56ecc95b3338 Change-Id: I1cc45f59bb8e89e4f0990312137ee87712b5a4ef
2018-05-08 12:55:53 -05:00
repos:
- openstack/charm-glance-simplestreams-sync
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-guide:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-guide
charm-hacluster:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-hacluster
charm-heat:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-heat
Add the infinidat-tools subordinate charm to OpenStack charms Add new charm that installs Infinidat tools to the units that need talk to Infinidat via iSCSI protocol - cinder and nova. Depends-On: I51107d5483bf2326941bac720b495cdf3cfb0e8d Change-Id: I081928fd0e789cca793ce1575127ceec46c906be
2022-11-09 00:14:59 +03:00
charm-infinidat-tools:
release-management: external
repos:
- openstack/charm-infinidat-tools
Add new charm repositories These charms and interfaces are direct and indirect dependencies for the on-going Octavia charm work. Also amends the ``release-management`` key for the ``charm-octavia`` entry. Change-Id: I2448ed051340ec879542f1e954a8a72c6334838b Depends-On: Ia5bab981b806cb9ca6316b0d9fa7f61456434334
2018-11-06 13:36:44 +01:00
charm-interface-barbican-secrets:
release-management: external
repos:
- openstack/charm-interface-barbican-secrets
charms: Add Neutron Dynamic Routing charm Add the new Neutron Dynamic Routing charm and supporting bgp interface to the OpenStack Charms project. Depends-On: I470b1611b60e44f3c404ea7cf4e02ba15ddc1f22 Change-Id: Ieaaba46748dec27229e8f6fa51776ee149e3ee9a
2018-04-24 15:49:20 -07:00
charm-interface-bgp:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
charms: Add Neutron Dynamic Routing charm Add the new Neutron Dynamic Routing charm and supporting bgp interface to the OpenStack Charms project. Depends-On: I470b1611b60e44f3c404ea7cf4e02ba15ddc1f22 Change-Id: Ieaaba46748dec27229e8f6fa51776ee149e3ee9a
2018-04-24 15:49:20 -07:00
repos:
- openstack/charm-interface-bgp
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
charm-interface-bind-rndc:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-bind-rndc
charms: Add Gnocchi charm and supporting interfaces Add the new Gnocchi charm and supporting charm interfaces to the OpenStack Charms project. Change-Id: I8029883cabe875060487e0a731d3c3f44af645dc Depends-On: Ibcb7ebd25ed5f646aaf1323beeb9acc87a8d07f6
2017-08-02 10:34:21 +01:00
charm-interface-ceph-client:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
charms: Add Gnocchi charm and supporting interfaces Add the new Gnocchi charm and supporting charm interfaces to the OpenStack Charms project. Change-Id: I8029883cabe875060487e0a731d3c3f44af645dc Depends-On: Ibcb7ebd25ed5f646aaf1323beeb9acc87a8d07f6
2017-08-02 10:34:21 +01:00
repos:
- openstack/charm-interface-ceph-client
Add Ceph MDS Interface Add the Ceph MDS charm interface to the OpenStack charms. Depends-On: I63765409f2950862a92366f6b8f3deb01784cb9c Change-Id: I780ff274f4148c4f36b31cff10929eb987bc75d0
2017-02-06 11:04:10 -08:00
charm-interface-ceph-mds:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Ceph MDS Interface Add the Ceph MDS charm interface to the OpenStack charms. Depends-On: I63765409f2950862a92366f6b8f3deb01784cb9c Change-Id: I780ff274f4148c4f36b31cff10929eb987bc75d0
2017-02-06 11:04:10 -08:00
repos:
- openstack/charm-interface-ceph-mds
Add ``ceph-rbd-mirror`` charm and dependencies Change-Id: I027ba8b86ada15f67be823a4955b165853a21d12 Depends-On: Ica61a89c9b6a7fa7ccc1f38f5c7f614f692552d7
2019-02-25 14:02:47 +03:00
charm-interface-ceph-rbd-mirror:
release-management: external
repos:
- openstack/charm-interface-ceph-rbd-mirror
Add Cinder Storage charm interface Add new cinder storage charm interface. Depends-On: Ia5a4df2ed604e330e7df3c8d71b817a18819457d Change-Id: I27917160a8a645fbcc1285864b846bbea8474295
2019-01-16 15:28:01 +00:00
charm-interface-cinder-backend:
release-management: external
repos:
- openstack/charm-interface-cinder-backend
Add ``charm-cinder-backup-swift-proxy`` charm Depends-On: Ia5e5b0933e5b2e5b9865624a4bcb77ba7b2f3eac Change-Id: I8c1dc32ae71ad2261e0a676186458613cd7e151d
2019-11-29 16:25:20 +01:00
charm-interface-cinder-backup:
release-management: external
repos:
- openstack/charm-interface-cinder-backup
Add new charm repositories These charms and interfaces are direct and indirect dependencies for the on-going Octavia charm work. Also amends the ``release-management`` key for the ``charm-octavia`` entry. Change-Id: I2448ed051340ec879542f1e954a8a72c6334838b Depends-On: Ia5bab981b806cb9ca6316b0d9fa7f61456434334
2018-11-06 13:36:44 +01:00
charm-interface-dashboard-plugin:
release-management: external
repos:
- openstack/charm-interface-dashboard-plugin
Add charm-interface-designate project This patchset adds charm-interface-designate project. Depends-On: I21b9b5c11a490b32a8a63eead1446a2ad5e804c1 Change-Id: I7ce6acd13693850ee59ad3863c4baa2803d4913c Related-Bug: #1704769
2017-11-02 15:52:51 +01:00
charm-interface-designate:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add charm-interface-designate project This patchset adds charm-interface-designate project. Depends-On: I21b9b5c11a490b32a8a63eead1446a2ad5e804c1 Change-Id: I7ce6acd13693850ee59ad3863c4baa2803d4913c Related-Bug: #1704769
2017-11-02 15:52:51 +01:00
repos:
- openstack/charm-interface-designate
charms: Add Gnocchi charm and supporting interfaces Add the new Gnocchi charm and supporting charm interfaces to the OpenStack Charms project. Change-Id: I8029883cabe875060487e0a731d3c3f44af645dc Depends-On: Ibcb7ebd25ed5f646aaf1323beeb9acc87a8d07f6
2017-08-02 10:34:21 +01:00
charm-interface-gnocchi:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
charms: Add Gnocchi charm and supporting interfaces Add the new Gnocchi charm and supporting charm interfaces to the OpenStack Charms project. Change-Id: I8029883cabe875060487e0a731d3c3f44af645dc Depends-On: Ibcb7ebd25ed5f646aaf1323beeb9acc87a8d07f6
2017-08-02 10:34:21 +01:00
repos:
- openstack/charm-interface-gnocchi
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
charm-interface-hacluster:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-hacluster
Add Ironic charms to OpenStack charms Add the Ironic charms and corresponding interface to OpenStack Charms. Change-Id: Ia3ef6f29ca5d2a0173536dcf1d2bea12be54f7c0 Depends-On: I1cb2bd4b28b8486e6b10e8d32ebd9bfe1761bb94
2020-09-24 13:37:08 +00:00
charm-interface-ironic-api:
release-management: external
repos:
- openstack/charm-interface-ironic-api
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
charm-interface-keystone:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-keystone
Add Keystone Admin charm interface Add the keystone admin charm interface to the OpenStack charms. Change-Id: I13fa3b4642d99979921d284f9ec36641c1c9a4dd Depends-On: I29af4c09cbf10b05da94af9be610d22e6a1d8cf0
2017-01-16 13:15:01 +00:00
charm-interface-keystone-admin:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Keystone Admin charm interface Add the keystone admin charm interface to the OpenStack charms. Change-Id: I13fa3b4642d99979921d284f9ec36641c1c9a4dd Depends-On: I29af4c09cbf10b05da94af9be610d22e6a1d8cf0
2017-01-16 13:15:01 +00:00
repos:
- openstack/charm-interface-keystone-admin
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
charm-interface-keystone-credentials:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-keystone-credentials
charms: Add charm for keystone ldap support Add charm for Keystone v3 LDAP support and associated charm interface. Depends-On: I8cf50d2d7eec53d81cbfb12deb50b7f47255f344 Change-Id: Ia0c530504ddc253e9fcd7991c46f1da25c70220e
2017-02-09 11:59:16 +00:00
charm-interface-keystone-domain-backend:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
charms: Add charm for keystone ldap support Add charm for Keystone v3 LDAP support and associated charm interface. Depends-On: I8cf50d2d7eec53d81cbfb12deb50b7f47255f344 Change-Id: Ia0c530504ddc253e9fcd7991c46f1da25c70220e
2017-02-09 11:59:16 +00:00
repos:
- openstack/charm-interface-keystone-domain-backend
Add new Keystone SAML Mellon charm repositories These charms and interfaces are direct and indirect dependencies for Keystone SAML Mellon charm. Depends-On: I7078ae5ddf1a21d7d1d3ab7cbc213e6c08a43ce8 Change-Id: I85988d445e6a41c926c9fbb60c2fcc3898225db8
2019-04-30 16:39:32 -07:00
charm-interface-keystone-fid-service-provider:
release-management: external
repos:
- openstack/charm-interface-keystone-fid-service-provider
Add charm-interface-keystone-notifications project This patch adds charm-interface-keytone-notifications project to enable the use of identity-notifications relation in reactive charms. Depends-On: https://review.opendev.org/703691 Change-Id: Icb52677918301c128a82e1f124db9e0e8759e9be
2020-01-21 17:41:41 -03:00
charm-interface-keystone-notifications:
release-management: external
repos:
- openstack/charm-interface-keystone-notifications
Add Magpie charm to OpenStack charms Add Magpie charm and corresponding interface to OpenStack Charms. Depends-On: I6c8d9a7eaff4003afbe14b8dfaa58f59f619fa9f Change-Id: Ia0482284f1d1a18f65437c6d2391a363a7ed8f18
2020-11-16 10:57:50 +00:00
charm-interface-magpie:
release-management: external
repos:
- openstack/charm-interface-magpie
Add charm-manila-generic and interface This patchset adds the charm-manila-generic which is to configure the manila charm to use the generic interface. The charm-interface-manila-plugin which connects backend configuration charms to manila. Change-Id: I810d9737fe67a04f63edd9a5d333b34f937f2405 Depends-On: I5e0fbcf4f192905c275f93422841ecce07b114a5
2016-10-18 10:23:23 +00:00
charm-interface-manila-plugin:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add charm-manila-generic and interface This patchset adds the charm-manila-generic which is to configure the manila charm to use the generic interface. The charm-interface-manila-plugin which connects backend configuration charms to manila. Change-Id: I810d9737fe67a04f63edd9a5d333b34f937f2405 Depends-On: I5e0fbcf4f192905c275f93422841ecce07b114a5
2016-10-18 10:23:23 +00:00
repos:
- openstack/charm-interface-manila-plugin
New charms & interfaces for MySQL8 Add mysql-router and mysql-innodb-cluster charms for clustering with MySQL 8. Also add interfaces for both charms. Depends-On: Icb9e9c6f9c61de406b9e010d66160a5c1d75b61b Change-Id: Id3e0516c838efd653834aeeed8fbe3a40dcaabc4
2019-10-11 14:39:43 -07:00
charm-interface-mysql-innodb-cluster:
release-management: external
repos:
- openstack/charm-interface-mysql-innodb-cluster
charm-interface-mysql-router:
release-management: external
repos:
- openstack/charm-interface-mysql-router
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
charm-interface-mysql-shared:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-mysql-shared
Add new charm repositories These charms and interfaces are direct and indirect dependencies for the on-going Octavia charm work. Also amends the ``release-management`` key for the ``charm-octavia`` entry. Change-Id: I2448ed051340ec879542f1e954a8a72c6334838b Depends-On: Ia5bab981b806cb9ca6316b0d9fa7f61456434334
2018-11-06 13:36:44 +01:00
charm-interface-neutron-load-balancer:
release-management: external
repos:
- openstack/charm-interface-neutron-load-balancer
Add cells charm and interfaces Add new nova-cell-controller charm and two associated interfaces. Depends-On: If73c0d836eea55dc9e64ad9b9cffc6521eb4d928 Change-Id: I9f00124ccaea66e1555bbb548386c187165c3cf0
2018-10-09 08:40:43 +01:00
charm-interface-nova-cell:
Mark recent Charm deliverables externally-released Recent additions to the Charms repositories failed to mention that they are externally-released (directly to the Charm store) rather than being handled by the release management team. Change-Id: I5744bf77ebf1cfac721b374597d9b1e1af520631
2018-11-28 13:17:36 +01:00
release-management: external
Add cells charm and interfaces Add new nova-cell-controller charm and two associated interfaces. Depends-On: If73c0d836eea55dc9e64ad9b9cffc6521eb4d928 Change-Id: I9f00124ccaea66e1555bbb548386c187165c3cf0
2018-10-09 08:40:43 +01:00
repos:
- openstack/charm-interface-nova-cell
charm-interface-nova-compute:
Mark recent Charm deliverables externally-released Recent additions to the Charms repositories failed to mention that they are externally-released (directly to the Charm store) rather than being handled by the release management team. Change-Id: I5744bf77ebf1cfac721b374597d9b1e1af520631
2018-11-28 13:17:36 +01:00
release-management: external
Add cells charm and interfaces Add new nova-cell-controller charm and two associated interfaces. Depends-On: If73c0d836eea55dc9e64ad9b9cffc6521eb4d928 Change-Id: I9f00124ccaea66e1555bbb548386c187165c3cf0
2018-10-09 08:40:43 +01:00
repos:
- openstack/charm-interface-nova-compute
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
charm-interface-neutron-plugin:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-neutron-plugin
Add neutron-plugin-api-subordinate charm interface Add the new neutron-plugin-api-subordinate charm interface to the OpenStack Charms project. Depends-On: Ie67f5c0285a8237489354f49cf98a0a2b939971d Change-Id: I984391bbdd29b08d7694dc160333640ada58d889
2016-09-19 10:39:01 +00:00
charm-interface-neutron-plugin-api-subordinate:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add neutron-plugin-api-subordinate charm interface Add the new neutron-plugin-api-subordinate charm interface to the OpenStack Charms project. Depends-On: Ie67f5c0285a8237489354f49cf98a0a2b939971d Change-Id: I984391bbdd29b08d7694dc160333640ada58d889
2016-09-19 10:39:01 +00:00
repos:
- openstack/charm-interface-neutron-plugin-api-subordinate
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
charm-interface-odl-controller-api:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-odl-controller-api
charm-interface-openstack-ha:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-openstack-ha
charm-interface-ovsdb-manager:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-ovsdb-manager
New charms & interface for Masakari integration Add masakari, masakari-monitors and pacemaker-remote charms. Also new pacemaker-remote interface. These are all used to support instance HA in a charm deploy. Depends-On: I86c4e446f97e6d4d79f2d9e864c5f4d9f155edce Change-Id: I4e8679e09daede3a3f271262189a279a83c7cb4c
2019-04-03 13:44:10 +01:00
charm-interface-pacemaker-remote:
release-management: external
repos:
- openstack/charm-interface-pacemaker-remote
New charm and interface for placement split Add placement charm and interface that allow for placement API to be split from nova-cloud-controller charm. Depends-On: https://review.opendev.org/686251 Change-Id: I3a73d93656b9d1d0cb63ebbb6095df8f49d357ca
2019-10-02 18:54:16 +00:00
charm-interface-placement:
release-management: external
repos:
- openstack/charm-interface-placement
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
charm-interface-rabbitmq:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-interface-rabbitmq
Add service-control charm interface Add the new service-control charm interface to the OpenStack Charms project. Depends-On: I671d7b3857747c85df21e088a9df2ad3e20244fb Change-Id: I28ceb1ab8da63897207cb0cefb233ef8e0e61d23
2016-08-31 11:37:38 +00:00
charm-interface-service-control:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add service-control charm interface Add the new service-control charm interface to the OpenStack Charms project. Depends-On: I671d7b3857747c85df21e088a9df2ad3e20244fb Change-Id: I28ceb1ab8da63897207cb0cefb233ef8e0e61d23
2016-08-31 11:37:38 +00:00
repos:
- openstack/charm-interface-service-control
Add new Keystone SAML Mellon charm repositories These charms and interfaces are direct and indirect dependencies for Keystone SAML Mellon charm. Depends-On: I7078ae5ddf1a21d7d1d3ab7cbc213e6c08a43ce8 Change-Id: I85988d445e6a41c926c9fbb60c2fcc3898225db8
2019-04-30 16:39:32 -07:00
charm-interface-websso-fid-service-provider:
release-management: external
repos:
- openstack/charm-interface-websso-fid-service-provider
Add charm-ironic Change-Id: I4d90e32fa094f71142f7375a56ebc805054483c2 Depends-On: I05e1e22e78af6aebeb3e6cdf20d591b562f216a4
2018-01-07 11:53:32 -05:00
charm-ironic:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add charm-ironic Change-Id: I4d90e32fa094f71142f7375a56ebc805054483c2 Depends-On: I05e1e22e78af6aebeb3e6cdf20d591b562f216a4
2018-01-07 11:53:32 -05:00
repos:
- openstack/charm-ironic
Add Ironic charms to OpenStack charms Add the Ironic charms and corresponding interface to OpenStack Charms. Change-Id: Ia3ef6f29ca5d2a0173536dcf1d2bea12be54f7c0 Depends-On: I1cb2bd4b28b8486e6b10e8d32ebd9bfe1761bb94
2020-09-24 13:37:08 +00:00
charm-ironic-api:
release-management: external
repos:
- openstack/charm-ironic-api
charm-ironic-conductor:
release-management: external
repos:
- openstack/charm-ironic-conductor
Add Ironic Dashboard charm to OpenStack charms Add new charm that enables Ironic UI plugin for Horizon. Depends-On: If79026fba4b7553fd541f6dc6dd039cf2af8da89 Change-Id: Ibae2dbf032bed1179e17d513281a3cf068fa068f
2023-03-02 16:13:12 -03:00
charm-ironic-dashboard:
release-management: external
repos:
- openstack/charm-ironic-dashboard
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-keystone:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-keystone
Add Keystone Kerberos charm to OpenStack charms Add new charm that provides Keystone the ability to authenticate with a Kerberos server. Depends-On: Iad535a9b963a3308d11d314484eb2c5d11e2008f Change-Id: I0a3d96268157b056685e954ee8bd2103a32e6e63
2020-07-29 16:07:54 +02:00
charm-keystone-kerberos:
release-management: external
repos:
- openstack/charm-keystone-kerberos
charms: Add charm for keystone ldap support Add charm for Keystone v3 LDAP support and associated charm interface. Depends-On: I8cf50d2d7eec53d81cbfb12deb50b7f47255f344 Change-Id: Ia0c530504ddc253e9fcd7991c46f1da25c70220e
2017-02-09 11:59:16 +00:00
charm-keystone-ldap:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
charms: Add charm for keystone ldap support Add charm for Keystone v3 LDAP support and associated charm interface. Depends-On: I8cf50d2d7eec53d81cbfb12deb50b7f47255f344 Change-Id: Ia0c530504ddc253e9fcd7991c46f1da25c70220e
2017-02-09 11:59:16 +00:00
repos:
- openstack/charm-keystone-ldap
Add Keystone OpenID Connect charm to OpenStack charms Add new charm that enables Keystone to support OpenID Connect via Federation. Depends-On: Ic758858db00a72a136e21c18f452df07f4ea74c2 Change-Id: I1b7495f0a5010f9768845882a6e072b5be3f18b9
2022-09-13 13:31:38 -03:00
charm-keystone-openidc:
release-management: external
repos:
- openstack/charm-keystone-openidc
Add new Keystone SAML Mellon charm repositories These charms and interfaces are direct and indirect dependencies for Keystone SAML Mellon charm. Depends-On: I7078ae5ddf1a21d7d1d3ab7cbc213e6c08a43ce8 Change-Id: I85988d445e6a41c926c9fbb60c2fcc3898225db8
2019-04-30 16:39:32 -07:00
charm-keystone-saml-mellon:
release-management: external
repos:
- openstack/charm-keystone-saml-mellon
Add ``ceph-rbd-mirror`` charm and dependencies Change-Id: I027ba8b86ada15f67be823a4955b165853a21d12 Depends-On: Ica61a89c9b6a7fa7ccc1f38f5c7f614f692552d7
2019-02-25 14:02:47 +03:00
charm-layer-ceph:
release-management: external
repos:
- openstack/charm-layer-ceph
Add Ceph base layer Add the Ceph base layer to the Openstack charms. Depends-On: Ia8f07517c82ad6305d3a7497f313143f78d50174 Change-Id: I7b2e54f297769245b7b9b2069eb2661c1a09373b
2017-02-06 11:17:50 -08:00
charm-layer-ceph-base:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Ceph base layer Add the Ceph base layer to the Openstack charms. Depends-On: Ia8f07517c82ad6305d3a7497f313143f78d50174 Change-Id: I7b2e54f297769245b7b9b2069eb2661c1a09373b
2017-02-06 11:17:50 -08:00
repos:
- openstack/charm-layer-ceph-base
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
charm-layer-openstack:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-layer-openstack
charm-layer-openstack-api:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-layer-openstack-api
charm-layer-openstack-principle:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add layers and interfaces to OpenStack Charms A number of new repositories have been setup in the last week to support landing of a number of new reactive/layered charms for Designate, Barbican and Aodh. This change includes these repositories as part of the OpenStack Charms project. Change-Id: I745fabd285b165a0dbfd69ab4b41bddaf9e0fcc3
2016-07-13 15:00:14 +01:00
repos:
- openstack/charm-layer-openstack-principle
Add Magnum charms to OpenStack charms Add new charms that provides the OpenStack Magnum service and its dashboard. Depends-On: I9faa96360bdc3eebb12f88f5f53d0ae13e0e398b Change-Id: I0649a57fb69510f0f6223854f2066411409c3e56
2021-03-12 10:53:32 +01:00
charm-magnum:
release-management: external
repos:
- openstack/charm-magnum
charm-magnum-dashboard:
release-management: external
repos:
- openstack/charm-magnum-dashboard
Add Magpie charm to OpenStack charms Add Magpie charm and corresponding interface to OpenStack Charms. Depends-On: I6c8d9a7eaff4003afbe14b8dfaa58f59f619fa9f Change-Id: Ia0482284f1d1a18f65437c6d2391a363a7ed8f18
2020-11-16 10:57:50 +00:00
charm-magpie:
release-management: external
repos:
- openstack/charm-magpie
Add charm-manila Add charm for Manila, the fileshare service for Openstack. Change-Id: Iac26a3e7a9c6cd71232eb75dc4a91560b3abcdb9 Depends-On: Ie9a439ea3f0098be132418b8e368fa79011350ba
2016-08-25 20:09:40 +00:00
charm-manila:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add charm-manila Add charm for Manila, the fileshare service for Openstack. Change-Id: Iac26a3e7a9c6cd71232eb75dc4a91560b3abcdb9 Depends-On: Ie9a439ea3f0098be132418b8e368fa79011350ba
2016-08-25 20:09:40 +00:00
repos:
- openstack/charm-manila
Add Manila dashboard charm to OpenStack charms Add new charm that provides Manila insights to the OpenStack Dashboard (Horizon) service. Depends-On: I892ad71c30c01b83256e301b3e77cdb814d9c3a5 Change-Id: I843ff4c67a2077cb204f49d354db8e14a49fd9e4
2021-03-16 13:41:41 +01:00
charm-manila-dashboard:
release-management: external
repos:
- openstack/charm-manila-dashboard
Add Pure Storage Manila flashblade charm to OpenStack charms Add a new charm that provides the Pure Storage Flashblade support to the Manila charm. Depends-On: I20cd5c3323701c59306ef13b15c7fd63c241f118 Change-Id: I2e664d58d90a94d573adfbdb4dfa5fd73515bd40
2023-09-06 14:11:23 +01:00
charm-manila-flashblade:
release-management: external
repos:
- openstack/charm-manila-flashblade
New charm for manila-ganesha Add manila-ganesha charm to enable the CephFS Ganesha backend for the manila charm Depends-On: I0c20c3c227f4436a087601eef186e2f04348d40c Change-Id: I1398552c487a8e7a7a500269de055ad1a7874e22
2019-11-08 09:49:19 +08:00
charm-manila-ganesha:
release-management: external
repos:
- openstack/charm-manila-ganesha
Add charm-manila-generic and interface This patchset adds the charm-manila-generic which is to configure the manila charm to use the generic interface. The charm-interface-manila-plugin which connects backend configuration charms to manila. Change-Id: I810d9737fe67a04f63edd9a5d333b34f937f2405 Depends-On: I5e0fbcf4f192905c275f93422841ecce07b114a5
2016-10-18 10:23:23 +00:00
charm-manila-generic:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add charm-manila-generic and interface This patchset adds the charm-manila-generic which is to configure the manila charm to use the generic interface. The charm-interface-manila-plugin which connects backend configuration charms to manila. Change-Id: I810d9737fe67a04f63edd9a5d333b34f937f2405 Depends-On: I5e0fbcf4f192905c275f93422841ecce07b114a5
2016-10-18 10:23:23 +00:00
repos:
- openstack/charm-manila-generic
Add Manila-NetApp backend charm to OpenStack charms Add new charm that provides the NetApp backend support to the OpenStack Manila service. Depends-On: Ib843838e452f934ff86e9367d9a7d94ce1731076 Change-Id: Idffb0ed019b4759a1680cb407c6c9ebcfbdae33d
2021-03-11 14:58:18 +01:00
charm-manila-netapp:
release-management: external
repos:
- openstack/charm-manila-netapp
Add the manila-infinidat charm to Openstack charms This charm implements Infinidat backend for Manila, acting as a subordinate charm. Depends-On: Iff96fbd4d01fd8eb2bbcfb7080244d7a40811434 Change-Id: I932b805e0f7d44040bad9c28ca4799f243f651af
2022-11-09 01:43:26 +03:00
charm-manila-infinidat:
release-management: external
repos:
- openstack/charm-manila-infinidat
New charms & interface for Masakari integration Add masakari, masakari-monitors and pacemaker-remote charms. Also new pacemaker-remote interface. These are all used to support instance HA in a charm deploy. Depends-On: I86c4e446f97e6d4d79f2d9e864c5f4d9f155edce Change-Id: I4e8679e09daede3a3f271262189a279a83c7cb4c
2019-04-03 13:44:10 +01:00
charm-masakari:
release-management: external
repos:
- openstack/charm-masakari
charm-masakari-monitors:
release-management: external
repos:
- openstack/charm-masakari-monitors
New charms & interfaces for MySQL8 Add mysql-router and mysql-innodb-cluster charms for clustering with MySQL 8. Also add interfaces for both charms. Depends-On: Icb9e9c6f9c61de406b9e010d66160a5c1d75b61b Change-Id: Id3e0516c838efd653834aeeed8fbe3a40dcaabc4
2019-10-11 14:39:43 -07:00
charm-mysql-innodb-cluster:
release-management: external
repos:
- openstack/charm-mysql-innodb-cluster
charm-mysql-router:
release-management: external
repos:
- openstack/charm-mysql-router
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-neutron-api:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-neutron-api
Add Neutron Arista plugin charm to OpenStack charms Add new charm that provides the Arista ML2 Plugin support to the OpenStack Neutron API service. Change-Id: Iec8fb33c35d113fdd01978fc537c4109c42f37e4 Depends-On: Ic2fbc63b57f390a8ff9a49d54fbde6a9af47be21
2020-06-24 12:02:59 +02:00
charm-neutron-api-plugin-arista:
release-management: external
repos:
- openstack/charm-neutron-api-plugin-arista
Add Ironic charms to OpenStack charms Add the Ironic charms and corresponding interface to OpenStack Charms. Change-Id: Ia3ef6f29ca5d2a0173536dcf1d2bea12be54f7c0 Depends-On: I1cb2bd4b28b8486e6b10e8d32ebd9bfe1761bb94
2020-09-24 13:37:08 +00:00
charm-neutron-api-plugin-ironic:
release-management: external
repos:
- openstack/charm-neutron-api-plugin-ironic
Add ``charm-neutron-api-plugin-ovn`` charm Depends-On: Ic01915d85c0978bd962f9159f5a2ddfc7a53e787 Change-Id: Ief1de4be550c852ba6daa9c5f25ff06a2dffb3db
2019-10-10 16:58:34 +02:00
charm-neutron-api-plugin-ovn:
release-management: external
repos:
- openstack/charm-neutron-api-plugin-ovn
charms: Add Neutron Dynamic Routing charm Add the new Neutron Dynamic Routing charm and supporting bgp interface to the OpenStack Charms project. Depends-On: I470b1611b60e44f3c404ea7cf4e02ba15ddc1f22 Change-Id: Ieaaba46748dec27229e8f6fa51776ee149e3ee9a
2018-04-24 15:49:20 -07:00
charm-neutron-dynamic-routing:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
charms: Add Neutron Dynamic Routing charm Add the new Neutron Dynamic Routing charm and supporting bgp interface to the OpenStack Charms project. Depends-On: I470b1611b60e44f3c404ea7cf4e02ba15ddc1f22 Change-Id: Ieaaba46748dec27229e8f6fa51776ee149e3ee9a
2018-04-24 15:49:20 -07:00
repos:
- openstack/charm-neutron-dynamic-routing
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-neutron-gateway:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-neutron-gateway
charm-neutron-openvswitch:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-neutron-openvswitch
Add cells charm and interfaces Add new nova-cell-controller charm and two associated interfaces. Depends-On: If73c0d836eea55dc9e64ad9b9cffc6521eb4d928 Change-Id: I9f00124ccaea66e1555bbb548386c187165c3cf0
2018-10-09 08:40:43 +01:00
charm-nova-cell-controller:
Mark recent Charm deliverables externally-released Recent additions to the Charms repositories failed to mention that they are externally-released (directly to the Charm store) rather than being handled by the release management team. Change-Id: I5744bf77ebf1cfac721b374597d9b1e1af520631
2018-11-28 13:17:36 +01:00
release-management: external
Add cells charm and interfaces Add new nova-cell-controller charm and two associated interfaces. Depends-On: If73c0d836eea55dc9e64ad9b9cffc6521eb4d928 Change-Id: I9f00124ccaea66e1555bbb548386c187165c3cf0
2018-10-09 08:40:43 +01:00
repos:
- openstack/charm-nova-cell-controller
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-nova-cloud-controller:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-nova-cloud-controller
charm-nova-compute:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-nova-compute
Add NVidia vGPU plugin charm to OpenStack charms Add new charm that provides the NVidia vGPU support to the OpenStack Nova service. Depends-On: I77e0823d405280a0a067eacb2ab03571c8db7fb4 Change-Id: I45b09e63bb6d8674f61dcc4a3a60952d9465ddf9
2021-11-30 14:17:04 +01:00
charm-nova-compute-nvidia-vgpu:
release-management: external
repos:
- openstack/charm-nova-compute-nvidia-vgpu
Add nova-compute-proxy and tempest charms Include charm-nova-compute and charm-tempest in governances as official OpenStack Charms. Change-Id: I8209dc4faf357fb675ac5455e7fe5895aa7a6bfd Depends-On: I9202938ab2111c1d8911ea613be3c7688cb67352
2016-10-31 10:52:49 +00:00
charm-nova-compute-proxy:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add nova-compute-proxy and tempest charms Include charm-nova-compute and charm-tempest in governances as official OpenStack Charms. Change-Id: I8209dc4faf357fb675ac5455e7fe5895aa7a6bfd Depends-On: I9202938ab2111c1d8911ea613be3c7688cb67352
2016-10-31 10:52:49 +00:00
repos:
- openstack/charm-nova-compute-proxy
charms: Add repository for Octavia charm Depends-On: I1a9526a3a56661cd66e1f9cc8ef09a55cc132d00 Change-Id: Id16f496caecbf08bf787b863e15cb8ffd1f08a0e
2018-10-05 16:38:43 +02:00
charm-octavia:
Add new charm repositories These charms and interfaces are direct and indirect dependencies for the on-going Octavia charm work. Also amends the ``release-management`` key for the ``charm-octavia`` entry. Change-Id: I2448ed051340ec879542f1e954a8a72c6334838b Depends-On: Ia5bab981b806cb9ca6316b0d9fa7f61456434334
2018-11-06 13:36:44 +01:00
release-management: external
charms: Add repository for Octavia charm Depends-On: I1a9526a3a56661cd66e1f9cc8ef09a55cc132d00 Change-Id: Id16f496caecbf08bf787b863e15cb8ffd1f08a0e
2018-10-05 16:38:43 +02:00
repos:
- openstack/charm-octavia
Add new charm repositories These charms and interfaces are direct and indirect dependencies for the on-going Octavia charm work. Also amends the ``release-management`` key for the ``charm-octavia`` entry. Change-Id: I2448ed051340ec879542f1e954a8a72c6334838b Depends-On: Ia5bab981b806cb9ca6316b0d9fa7f61456434334
2018-11-06 13:36:44 +01:00
charm-octavia-dashboard:
release-management: external
repos:
- openstack/charm-octavia-dashboard
Add ``octavia-diskimage-retrofit`` charm Depends-On: I72801354fe248a063a7fce233cc3cf28ef630ec9 Change-Id: I9c28b64001c71ab455c95615a51e0ce0b1236931
2019-06-20 15:07:16 +02:00
charm-octavia-diskimage-retrofit:
release-management: external
repos:
- openstack/charm-octavia-diskimage-retrofit
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-openstack-dashboard:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-openstack-dashboard
Add openstack-loadbalancer charm and interfaces Add new charm that provides loadbalancing to Openstack API services. Add new interfaces which support the new loadbalancer and Ceph Depends-On: Ief7b70bf2d3fedcd5b193e7e718e3deb2a52fc89 Change-Id: I804171fb4521372713c51cd99715643a7763866e
2021-09-08 09:31:26 +01:00
charm-openstack-loadbalancer:
release-management: external
repos:
- openstack/charm-openstack-loadbalancer
Add Ceph iSCSI charm to OpenStack charms Add Ceph iSCSI charm and corresponding interfaces to OpenStack Charms. Depends-On: I9e385c4206aa6e9a7315099f10c4b2b1530f3e13 Change-Id: I8d2e1af0b03cc68d161ab0ff6f7f631c513ddca6
2020-08-03 15:10:58 +01:00
charm-ops-interface-ceph-client:
release-management: external
repos:
- openstack/charm-ops-interface-ceph-client
Add openstack-loadbalancer charm and interfaces Add new charm that provides loadbalancing to Openstack API services. Add new interfaces which support the new loadbalancer and Ceph Depends-On: Ief7b70bf2d3fedcd5b193e7e718e3deb2a52fc89 Change-Id: I804171fb4521372713c51cd99715643a7763866e
2021-09-08 09:31:26 +01:00
charm-ops-interface-ceph-iscsi-admin-access:
release-management: external
repos:
- openstack/charm-ops-interface-ceph-iscsi-admin-access
charm-ops-interface-openstack-loadbalancer:
release-management: external
repos:
- openstack/charm-ops-interface-openstack-loadbalancer
Add Ceph iSCSI charm to OpenStack charms Add Ceph iSCSI charm and corresponding interfaces to OpenStack Charms. Depends-On: I9e385c4206aa6e9a7315099f10c4b2b1530f3e13 Change-Id: I8d2e1af0b03cc68d161ab0ff6f7f631c513ddca6
2020-08-03 15:10:58 +01:00
charm-ops-interface-tls-certificates:
release-management: external
repos:
- openstack/charm-ops-interface-tls-certificates
charm-ops-openstack:
release-management: external
repos:
- openstack/charm-ops-openstack
New charms & interface for Masakari integration Add masakari, masakari-monitors and pacemaker-remote charms. Also new pacemaker-remote interface. These are all used to support instance HA in a charm deploy. Depends-On: I86c4e446f97e6d4d79f2d9e864c5f4d9f155edce Change-Id: I4e8679e09daede3a3f271262189a279a83c7cb4c
2019-04-03 13:44:10 +01:00
charm-pacemaker-remote:
release-management: external
repos:
- openstack/charm-pacemaker-remote
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
charm-percona-cluster:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-percona-cluster
charm-rabbitmq-server:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-rabbitmq-server
charm-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-specs
charm-swift-proxy:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-swift-proxy
charm-swift-storage:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add Juju Charms for OpenStack The OpenStack Charms team would like to have the Juju Charms for deploying OpenStack recognised as an OpenStack Project. OpenStack charm development was moved under the OpenStack umbrella around 4 months ago; charms are developed under the standard git/gerrit workflow, with unit and pep8 testing done on OpenStack Infrastructure, and multi-unit charm functional testing done via a 3rd party CI integration using the Ubuntu Openstack CI system hosted by Canonical. The majority of core contribution is currently undertaken by Canonical, however a number of SDN and storage vendors (PLUMgrid, Calico, Nuage, Midonet) have their own charms and have made contributions to the integration of their features into the core OpenStack charms. CloudBase have also made a number of contributions to enable support for Microsoft Hyper-V as part of a Juju deployed OpenStack Cloud. Charms have been re-licensed under Apache 2.0 with the consent of contributors (see openstack-dev ML thread). Note that most charms contain a sync of the charmhelpers project - this project has also re-licensed to Apache 2.0. The charmhelpers module is not specific to OpenStack so will not be migrated to the OpenStack project. Change-Id: If5bac316bd209f96322325660e97fce140446115
2015-09-17 16:30:34 +01:00
repos:
- openstack/charm-swift-storage
Add nova-compute-proxy and tempest charms Include charm-nova-compute and charm-tempest in governances as official OpenStack Charms. Change-Id: I8209dc4faf357fb675ac5455e7fe5895aa7a6bfd Depends-On: I9202938ab2111c1d8911ea613be3c7688cb67352
2016-10-31 10:52:49 +00:00
charm-tempest:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: external
Add nova-compute-proxy and tempest charms Include charm-nova-compute and charm-tempest in governances as official OpenStack Charms. Change-Id: I8209dc4faf357fb675ac5455e7fe5895aa7a6bfd Depends-On: I9202938ab2111c1d8911ea613be3c7688cb67352
2016-10-31 10:52:49 +00:00
repos:
- openstack/charm-tempest
Add TrilioVault Charms to OpenStack Charms Add new charms for deployment of TrilioVault, a backup solution for OpenStack Clouds, to the OpenStack Charms project. Change-Id: I1c27cf58f5dea38a62761350cf809ebb9b88a9bc Depends-On: Ia3714f7d6919b8cb4a0317abd0e927a716ea86a6
2020-04-16 17:00:45 +01:00
charm-trilio-data-mover:
release-management: external
repos:
- openstack/charm-trilio-data-mover
charm-trilio-dm-api:
release-management: external
repos:
- openstack/charm-trilio-dm-api
charm-trilio-horizon-plugin:
release-management: external
repos:
- openstack/charm-trilio-horizon-plugin
charm-trilio-wlm:
release-management: external
repos:
- openstack/charm-trilio-wlm
Add charm-vault to Charms governance Charm-vault has been an official member of the OpenStack Charms project for some time, but was left out of governance in the past for a few reasons. These reasons have recently been re-evaluated by the team and the conclusion has been to include this charm in governance. Change-Id: I5b147d2845d27d982c97abf18275fcff798a516d
2019-05-23 09:34:09 +02:00
charm-vault:
release-management: external
repos:
Some repos were renamed, update reference files A couple of repos were renamed or moved from one org to another, follow renames in reference docs. Depends-On: https://review.opendev.org/657155 Depends-On: https://review.opendev.org/662432 Depends-On: https://review.opendev.org/657277 Depends-On: https://review.opendev.org/661682 Depends-On: https://review.opendev.org/659489 Depends-On: https://review.opendev.org/644584 Change-Id: I1a5102a6faec5d8d4995f477aa2089295ddfd63c
2019-05-31 17:52:47 +02:00
- openstack/charm-vault
New charm for watcher Add watcher charm to support charmed OpenStack Watcher Depends-On: Ic526595e4eac0e530eeb7603a88165b9616e0d17 Change-Id: Iba68b49c1eedd29afaca67bc3c2ed2f716da7a57 Signed-off-by: Stamatis Katsaounis <skatsaounis@admin.grnet.gr>
2020-01-11 12:22:01 +02:00
charm-watcher:
release-management: external
repos:
- openstack/charm-watcher
Add watcher dashboard charm repository This charm is indirect dependency for the on-going Watcher charm work. Depends-On: Ie9f0748b3f04cb31458531e4fa09741ddc33854e Change-Id: Iec17108e3e3f21973f557c5a379685908def0c31 Signed-off-by: Stamatis Katsaounis <skatsaounis@admin.grnet.gr>
2020-01-17 15:20:36 +02:00
charm-watcher-dashboard:
release-management: external
repos:
- openstack/charm-watcher-dashboard
Add project for managing zuul jobs for charms Add a project for defining the zuul jobs for testing charms. Depends-On: I69a9c9f388371a7a8ad1c7fe5cfc8f6c444d4f45 Change-Id: I07ace283a8255f106c141d7bea06618f802e3b51
2022-10-12 09:40:53 +01:00
charm-zuul-jobs:
release-management: external
repos:
- openstack/charm-zuul-jobs
OpenStack-Helm - Helm charts for OpenStack The mission of OpenStack-Helm[1] is to provide a collection of Helm charts that simply, resiliently, and flexibly deploy OpenStack and related services on Kubernetes. It allows the Helm client to be used directly to deploy OpenStack components, and as such is comarable to OpenStack-Ansible (providing playbooks for Ansible) or Puppet OpenStack (providing modules for Puppet). The project leverages native Kubernetes constructs and allows OpenStack projects to be installed in combinations and configurations per unique operator use cases. OpenStack-Helm has a goal to facilitate pushbutton automated deployments, and rolling upgrades with no impact to tenant workloads. There is a one-to-one correspondence between OpenStack projects and Helm charts, and charts are fully independent of one another. This allows for use cases from traditional OpenStack clouds, to deployment of standalone components, and combinations in between. The project provides reasonable, usable configuration by default, and allows for deployment-time overrides of individual values or a chart's entire values config. Dependent service endpoints (e.g. the Keystone API) default to Kubernetes cluster-internal DNS names, but can be overridden to point at external instances. Multiple, alternate SDN and SDS solutions will be integrated, and can be configured at deploy-time. The choice of container images is configurable as well, and can be mixed and matched on a chart-by-chart basis per operator needs. The project aims to be production-grade out-of-box, including configuration for highly available services, resilient storage for the control plane (e.g. Ceph), and security features such as cluster-internal TLS. OpenStack-Helm will follow the OpenStack independent release model[2], and will ensure Helm charts integrate with an OpenStack release once it is released. The team plans to change to cycle-trailing releases when ready, but will need to close the gap between Newton (current-state) and master first. In the meantime, it will model the cycle-trailing branch strategy as it catches up. The team is interested in feedback on this plan and advice from the TC. A number of OpenStack deployment projects pave the way for OpenStack-Helm, including OpenStack Ansible[3], Kolla-Kubernetes[4], OpenStack-Chef[5], and Puppet OpenStack [6]. OpenStack-Helm occupies a unique space in its exclusive use of Kubernetes-native constructs during the deployment process, including Helm packaging and gotpl templating. This tradeoff enables it to be as lightweight and simple as possible, at the expense of operator choice of deployment toolsets. The project team is eager to work with other OpenStack deployment projects to solve common needs and share learnings. The OpenStack-Helm project and the team follow the Four Opens: * Open Source: The project source code[7], specifications[8] and documentation[9] are open source and are developed in the community under the Apache 2.0 license. * Open Design: Design decisions are discussed and formalized via specifications, as well as openly discussed in the IRC chat room[10] and the team meetings[11]. The team had informal meetings at the Atlanta and Denver PTGs, as well as a presentation[12], hands-on workshop, and a related cross-project Forum at the Boston Summit. More of each are planned for Sydney. * Open Development: All OpenStack-Helm code is reviewed and hosted in OpenStack Infra[7]. blueprints and bugs are tracked by Launchpad[13]. Quality gates are run to ensure OpenStack deploys and runs with every patch set, and integration of standard Rally and Tempest tests is underway. * Open Community: The project team and core reviewer team[14] represent multiple employers, and are eager to groom new team members. Project discussions and Q&A are frequently held in the public IRC chat room, and all are welcome. 1. https://wiki.openstack.org/wiki/Openstack-helm 2. https://releases.openstack.org/reference/release_models.html 3. https://wiki.openstack.org/wiki/OpenStackAnsible 4. https://wiki.openstack.org/wiki/Kolla 5. https://wiki.openstack.org/wiki/Chef 6. https://docs.openstack.org/puppet-openstack-guide/latest/ 7. https://git.openstack.org/cgit/openstack/openstack-helm/ 8. https://git.openstack.org/cgit/openstack/openstack-helm/tree/doc/source/specs 9. http://openstack-helm.readthedocs.io/ 10. http://eavesdrop.openstack.org/irclogs/%23openstack-helm/ 11. http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-5/%23openstack-meeting-5.2017-10-03.log.html 12. https://www.openstack.org/videos/search?search=openstack-helm 13. https://launchpad.net/openstack-helm 14. https://review.openstack.org/#/admin/groups/1749,members Change-Id: I70995640b6b760e7bfd7f1ec407b8004c855203f
2017-10-11 13:49:05 -05:00
OpenStack-Helm:
ptl:
Update with 2023.2 Election results. Updates PTLs and TC members as per: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032240.html Also removes chair and vice-chair roles as this is a new TC Change-Id: I2aef6f364afeecc8bd48ce5e9fa64457c582b610
2023-02-16 11:16:15 +11:00
name: Vladimir Kozhukalov
Add openstack-helm PTLs missing irc nick name Change-Id: I31bf409253de99d3e76b8cd576b45ed007398498
2023-05-30 20:33:32 +03:00
irc: kozhukalov
Update with 2023.2 Election results. Updates PTLs and TC members as per: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032240.html Also removes chair and vice-chair roles as this is a new TC Change-Id: I2aef6f364afeecc8bd48ce5e9fa64457c582b610
2023-02-16 11:16:15 +11:00
email: kozhukalov@gmail.com
OpenStack-Helm - Helm charts for OpenStack The mission of OpenStack-Helm[1] is to provide a collection of Helm charts that simply, resiliently, and flexibly deploy OpenStack and related services on Kubernetes. It allows the Helm client to be used directly to deploy OpenStack components, and as such is comarable to OpenStack-Ansible (providing playbooks for Ansible) or Puppet OpenStack (providing modules for Puppet). The project leverages native Kubernetes constructs and allows OpenStack projects to be installed in combinations and configurations per unique operator use cases. OpenStack-Helm has a goal to facilitate pushbutton automated deployments, and rolling upgrades with no impact to tenant workloads. There is a one-to-one correspondence between OpenStack projects and Helm charts, and charts are fully independent of one another. This allows for use cases from traditional OpenStack clouds, to deployment of standalone components, and combinations in between. The project provides reasonable, usable configuration by default, and allows for deployment-time overrides of individual values or a chart's entire values config. Dependent service endpoints (e.g. the Keystone API) default to Kubernetes cluster-internal DNS names, but can be overridden to point at external instances. Multiple, alternate SDN and SDS solutions will be integrated, and can be configured at deploy-time. The choice of container images is configurable as well, and can be mixed and matched on a chart-by-chart basis per operator needs. The project aims to be production-grade out-of-box, including configuration for highly available services, resilient storage for the control plane (e.g. Ceph), and security features such as cluster-internal TLS. OpenStack-Helm will follow the OpenStack independent release model[2], and will ensure Helm charts integrate with an OpenStack release once it is released. The team plans to change to cycle-trailing releases when ready, but will need to close the gap between Newton (current-state) and master first. In the meantime, it will model the cycle-trailing branch strategy as it catches up. The team is interested in feedback on this plan and advice from the TC. A number of OpenStack deployment projects pave the way for OpenStack-Helm, including OpenStack Ansible[3], Kolla-Kubernetes[4], OpenStack-Chef[5], and Puppet OpenStack [6]. OpenStack-Helm occupies a unique space in its exclusive use of Kubernetes-native constructs during the deployment process, including Helm packaging and gotpl templating. This tradeoff enables it to be as lightweight and simple as possible, at the expense of operator choice of deployment toolsets. The project team is eager to work with other OpenStack deployment projects to solve common needs and share learnings. The OpenStack-Helm project and the team follow the Four Opens: * Open Source: The project source code[7], specifications[8] and documentation[9] are open source and are developed in the community under the Apache 2.0 license. * Open Design: Design decisions are discussed and formalized via specifications, as well as openly discussed in the IRC chat room[10] and the team meetings[11]. The team had informal meetings at the Atlanta and Denver PTGs, as well as a presentation[12], hands-on workshop, and a related cross-project Forum at the Boston Summit. More of each are planned for Sydney. * Open Development: All OpenStack-Helm code is reviewed and hosted in OpenStack Infra[7]. blueprints and bugs are tracked by Launchpad[13]. Quality gates are run to ensure OpenStack deploys and runs with every patch set, and integration of standard Rally and Tempest tests is underway. * Open Community: The project team and core reviewer team[14] represent multiple employers, and are eager to groom new team members. Project discussions and Q&A are frequently held in the public IRC chat room, and all are welcome. 1. https://wiki.openstack.org/wiki/Openstack-helm 2. https://releases.openstack.org/reference/release_models.html 3. https://wiki.openstack.org/wiki/OpenStackAnsible 4. https://wiki.openstack.org/wiki/Kolla 5. https://wiki.openstack.org/wiki/Chef 6. https://docs.openstack.org/puppet-openstack-guide/latest/ 7. https://git.openstack.org/cgit/openstack/openstack-helm/ 8. https://git.openstack.org/cgit/openstack/openstack-helm/tree/doc/source/specs 9. http://openstack-helm.readthedocs.io/ 10. http://eavesdrop.openstack.org/irclogs/%23openstack-helm/ 11. http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-5/%23openstack-meeting-5.2017-10-03.log.html 12. https://www.openstack.org/videos/search?search=openstack-helm 13. https://launchpad.net/openstack-helm 14. https://review.openstack.org/#/admin/groups/1749,members Change-Id: I70995640b6b760e7bfd7f1ec407b8004c855203f
2017-10-11 13:49:05 -05:00
service: Helm charts for OpenStack services
irc-channel: openstack-helm
mission: >
To provide a collection of Helm charts that simply, resiliently,
and flexibly deploy OpenStack and related services on Kubernetes.
Fold LOCI into OpenStack-Helm LOCI has less contributors than in the past, and it makes sense to fold LOCI into one of its main users, OpenStack-Helm, rather than abandonning the project. Change-Id: Idc757dc1aa4edbed757ab715f92ea8278135a14a
2020-04-10 10:04:18 +02:00
OpenStack-Helm also produces lighweight OCI container images agnostic of
the deployment tooling for OpenStack.
OpenStack-Helm - Helm charts for OpenStack The mission of OpenStack-Helm[1] is to provide a collection of Helm charts that simply, resiliently, and flexibly deploy OpenStack and related services on Kubernetes. It allows the Helm client to be used directly to deploy OpenStack components, and as such is comarable to OpenStack-Ansible (providing playbooks for Ansible) or Puppet OpenStack (providing modules for Puppet). The project leverages native Kubernetes constructs and allows OpenStack projects to be installed in combinations and configurations per unique operator use cases. OpenStack-Helm has a goal to facilitate pushbutton automated deployments, and rolling upgrades with no impact to tenant workloads. There is a one-to-one correspondence between OpenStack projects and Helm charts, and charts are fully independent of one another. This allows for use cases from traditional OpenStack clouds, to deployment of standalone components, and combinations in between. The project provides reasonable, usable configuration by default, and allows for deployment-time overrides of individual values or a chart's entire values config. Dependent service endpoints (e.g. the Keystone API) default to Kubernetes cluster-internal DNS names, but can be overridden to point at external instances. Multiple, alternate SDN and SDS solutions will be integrated, and can be configured at deploy-time. The choice of container images is configurable as well, and can be mixed and matched on a chart-by-chart basis per operator needs. The project aims to be production-grade out-of-box, including configuration for highly available services, resilient storage for the control plane (e.g. Ceph), and security features such as cluster-internal TLS. OpenStack-Helm will follow the OpenStack independent release model[2], and will ensure Helm charts integrate with an OpenStack release once it is released. The team plans to change to cycle-trailing releases when ready, but will need to close the gap between Newton (current-state) and master first. In the meantime, it will model the cycle-trailing branch strategy as it catches up. The team is interested in feedback on this plan and advice from the TC. A number of OpenStack deployment projects pave the way for OpenStack-Helm, including OpenStack Ansible[3], Kolla-Kubernetes[4], OpenStack-Chef[5], and Puppet OpenStack [6]. OpenStack-Helm occupies a unique space in its exclusive use of Kubernetes-native constructs during the deployment process, including Helm packaging and gotpl templating. This tradeoff enables it to be as lightweight and simple as possible, at the expense of operator choice of deployment toolsets. The project team is eager to work with other OpenStack deployment projects to solve common needs and share learnings. The OpenStack-Helm project and the team follow the Four Opens: * Open Source: The project source code[7], specifications[8] and documentation[9] are open source and are developed in the community under the Apache 2.0 license. * Open Design: Design decisions are discussed and formalized via specifications, as well as openly discussed in the IRC chat room[10] and the team meetings[11]. The team had informal meetings at the Atlanta and Denver PTGs, as well as a presentation[12], hands-on workshop, and a related cross-project Forum at the Boston Summit. More of each are planned for Sydney. * Open Development: All OpenStack-Helm code is reviewed and hosted in OpenStack Infra[7]. blueprints and bugs are tracked by Launchpad[13]. Quality gates are run to ensure OpenStack deploys and runs with every patch set, and integration of standard Rally and Tempest tests is underway. * Open Community: The project team and core reviewer team[14] represent multiple employers, and are eager to groom new team members. Project discussions and Q&A are frequently held in the public IRC chat room, and all are welcome. 1. https://wiki.openstack.org/wiki/Openstack-helm 2. https://releases.openstack.org/reference/release_models.html 3. https://wiki.openstack.org/wiki/OpenStackAnsible 4. https://wiki.openstack.org/wiki/Kolla 5. https://wiki.openstack.org/wiki/Chef 6. https://docs.openstack.org/puppet-openstack-guide/latest/ 7. https://git.openstack.org/cgit/openstack/openstack-helm/ 8. https://git.openstack.org/cgit/openstack/openstack-helm/tree/doc/source/specs 9. http://openstack-helm.readthedocs.io/ 10. http://eavesdrop.openstack.org/irclogs/%23openstack-helm/ 11. http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-5/%23openstack-meeting-5.2017-10-03.log.html 12. https://www.openstack.org/videos/search?search=openstack-helm 13. https://launchpad.net/openstack-helm 14. https://review.openstack.org/#/admin/groups/1749,members Change-Id: I70995640b6b760e7bfd7f1ec407b8004c855203f
2017-10-11 13:49:05 -05:00
url: https://wiki.openstack.org/wiki/Openstack-helm
deliverables:
openstack-helm:
OpenStack-Helm does not require release management So far OpenStack-Helm has not used release management and is more continuously released. While that may change in the future, let's document that for now in governance. Change-Id: I17878d95f8b005316661d83ec8030c8d626f5800
2020-02-04 18:34:43 +01:00
release-management: external
OpenStack-Helm - Helm charts for OpenStack The mission of OpenStack-Helm[1] is to provide a collection of Helm charts that simply, resiliently, and flexibly deploy OpenStack and related services on Kubernetes. It allows the Helm client to be used directly to deploy OpenStack components, and as such is comarable to OpenStack-Ansible (providing playbooks for Ansible) or Puppet OpenStack (providing modules for Puppet). The project leverages native Kubernetes constructs and allows OpenStack projects to be installed in combinations and configurations per unique operator use cases. OpenStack-Helm has a goal to facilitate pushbutton automated deployments, and rolling upgrades with no impact to tenant workloads. There is a one-to-one correspondence between OpenStack projects and Helm charts, and charts are fully independent of one another. This allows for use cases from traditional OpenStack clouds, to deployment of standalone components, and combinations in between. The project provides reasonable, usable configuration by default, and allows for deployment-time overrides of individual values or a chart's entire values config. Dependent service endpoints (e.g. the Keystone API) default to Kubernetes cluster-internal DNS names, but can be overridden to point at external instances. Multiple, alternate SDN and SDS solutions will be integrated, and can be configured at deploy-time. The choice of container images is configurable as well, and can be mixed and matched on a chart-by-chart basis per operator needs. The project aims to be production-grade out-of-box, including configuration for highly available services, resilient storage for the control plane (e.g. Ceph), and security features such as cluster-internal TLS. OpenStack-Helm will follow the OpenStack independent release model[2], and will ensure Helm charts integrate with an OpenStack release once it is released. The team plans to change to cycle-trailing releases when ready, but will need to close the gap between Newton (current-state) and master first. In the meantime, it will model the cycle-trailing branch strategy as it catches up. The team is interested in feedback on this plan and advice from the TC. A number of OpenStack deployment projects pave the way for OpenStack-Helm, including OpenStack Ansible[3], Kolla-Kubernetes[4], OpenStack-Chef[5], and Puppet OpenStack [6]. OpenStack-Helm occupies a unique space in its exclusive use of Kubernetes-native constructs during the deployment process, including Helm packaging and gotpl templating. This tradeoff enables it to be as lightweight and simple as possible, at the expense of operator choice of deployment toolsets. The project team is eager to work with other OpenStack deployment projects to solve common needs and share learnings. The OpenStack-Helm project and the team follow the Four Opens: * Open Source: The project source code[7], specifications[8] and documentation[9] are open source and are developed in the community under the Apache 2.0 license. * Open Design: Design decisions are discussed and formalized via specifications, as well as openly discussed in the IRC chat room[10] and the team meetings[11]. The team had informal meetings at the Atlanta and Denver PTGs, as well as a presentation[12], hands-on workshop, and a related cross-project Forum at the Boston Summit. More of each are planned for Sydney. * Open Development: All OpenStack-Helm code is reviewed and hosted in OpenStack Infra[7]. blueprints and bugs are tracked by Launchpad[13]. Quality gates are run to ensure OpenStack deploys and runs with every patch set, and integration of standard Rally and Tempest tests is underway. * Open Community: The project team and core reviewer team[14] represent multiple employers, and are eager to groom new team members. Project discussions and Q&A are frequently held in the public IRC chat room, and all are welcome. 1. https://wiki.openstack.org/wiki/Openstack-helm 2. https://releases.openstack.org/reference/release_models.html 3. https://wiki.openstack.org/wiki/OpenStackAnsible 4. https://wiki.openstack.org/wiki/Kolla 5. https://wiki.openstack.org/wiki/Chef 6. https://docs.openstack.org/puppet-openstack-guide/latest/ 7. https://git.openstack.org/cgit/openstack/openstack-helm/ 8. https://git.openstack.org/cgit/openstack/openstack-helm/tree/doc/source/specs 9. http://openstack-helm.readthedocs.io/ 10. http://eavesdrop.openstack.org/irclogs/%23openstack-helm/ 11. http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-5/%23openstack-meeting-5.2017-10-03.log.html 12. https://www.openstack.org/videos/search?search=openstack-helm 13. https://launchpad.net/openstack-helm 14. https://review.openstack.org/#/admin/groups/1749,members Change-Id: I70995640b6b760e7bfd7f1ec407b8004c855203f
2017-10-11 13:49:05 -05:00
repos:
- openstack/openstack-helm
New Repo - OpenStack-Helm Images This PS adds a new repo for the OpenStack-Helm project. This repo will house the dockerfiles that are spread throughout the openstack-helm, openstack-helm-addons and openstack-helm-infra repos. Depends-On: https://review.openstack.org/#/c/611892 Change-Id: I50d43a0f4511c361941aab286ed8ce068ad2ddb0 Signed-off-by: Pete Birley <pete@port.direct>
2018-10-19 09:53:15 -05:00
openstack-helm-images:
OpenStack-Helm does not require release management So far OpenStack-Helm has not used release management and is more continuously released. While that may change in the future, let's document that for now in governance. Change-Id: I17878d95f8b005316661d83ec8030c8d626f5800
2020-02-04 18:34:43 +01:00
release-management: external
New Repo - OpenStack-Helm Images This PS adds a new repo for the OpenStack-Helm project. This repo will house the dockerfiles that are spread throughout the openstack-helm, openstack-helm-addons and openstack-helm-infra repos. Depends-On: https://review.openstack.org/#/c/611892 Change-Id: I50d43a0f4511c361941aab286ed8ce068ad2ddb0 Signed-off-by: Pete Birley <pete@port.direct>
2018-10-19 09:53:15 -05:00
repos:
- openstack/openstack-helm-images
OpenStack-Helm - Helm charts for OpenStack The mission of OpenStack-Helm[1] is to provide a collection of Helm charts that simply, resiliently, and flexibly deploy OpenStack and related services on Kubernetes. It allows the Helm client to be used directly to deploy OpenStack components, and as such is comarable to OpenStack-Ansible (providing playbooks for Ansible) or Puppet OpenStack (providing modules for Puppet). The project leverages native Kubernetes constructs and allows OpenStack projects to be installed in combinations and configurations per unique operator use cases. OpenStack-Helm has a goal to facilitate pushbutton automated deployments, and rolling upgrades with no impact to tenant workloads. There is a one-to-one correspondence between OpenStack projects and Helm charts, and charts are fully independent of one another. This allows for use cases from traditional OpenStack clouds, to deployment of standalone components, and combinations in between. The project provides reasonable, usable configuration by default, and allows for deployment-time overrides of individual values or a chart's entire values config. Dependent service endpoints (e.g. the Keystone API) default to Kubernetes cluster-internal DNS names, but can be overridden to point at external instances. Multiple, alternate SDN and SDS solutions will be integrated, and can be configured at deploy-time. The choice of container images is configurable as well, and can be mixed and matched on a chart-by-chart basis per operator needs. The project aims to be production-grade out-of-box, including configuration for highly available services, resilient storage for the control plane (e.g. Ceph), and security features such as cluster-internal TLS. OpenStack-Helm will follow the OpenStack independent release model[2], and will ensure Helm charts integrate with an OpenStack release once it is released. The team plans to change to cycle-trailing releases when ready, but will need to close the gap between Newton (current-state) and master first. In the meantime, it will model the cycle-trailing branch strategy as it catches up. The team is interested in feedback on this plan and advice from the TC. A number of OpenStack deployment projects pave the way for OpenStack-Helm, including OpenStack Ansible[3], Kolla-Kubernetes[4], OpenStack-Chef[5], and Puppet OpenStack [6]. OpenStack-Helm occupies a unique space in its exclusive use of Kubernetes-native constructs during the deployment process, including Helm packaging and gotpl templating. This tradeoff enables it to be as lightweight and simple as possible, at the expense of operator choice of deployment toolsets. The project team is eager to work with other OpenStack deployment projects to solve common needs and share learnings. The OpenStack-Helm project and the team follow the Four Opens: * Open Source: The project source code[7], specifications[8] and documentation[9] are open source and are developed in the community under the Apache 2.0 license. * Open Design: Design decisions are discussed and formalized via specifications, as well as openly discussed in the IRC chat room[10] and the team meetings[11]. The team had informal meetings at the Atlanta and Denver PTGs, as well as a presentation[12], hands-on workshop, and a related cross-project Forum at the Boston Summit. More of each are planned for Sydney. * Open Development: All OpenStack-Helm code is reviewed and hosted in OpenStack Infra[7]. blueprints and bugs are tracked by Launchpad[13]. Quality gates are run to ensure OpenStack deploys and runs with every patch set, and integration of standard Rally and Tempest tests is underway. * Open Community: The project team and core reviewer team[14] represent multiple employers, and are eager to groom new team members. Project discussions and Q&A are frequently held in the public IRC chat room, and all are welcome. 1. https://wiki.openstack.org/wiki/Openstack-helm 2. https://releases.openstack.org/reference/release_models.html 3. https://wiki.openstack.org/wiki/OpenStackAnsible 4. https://wiki.openstack.org/wiki/Kolla 5. https://wiki.openstack.org/wiki/Chef 6. https://docs.openstack.org/puppet-openstack-guide/latest/ 7. https://git.openstack.org/cgit/openstack/openstack-helm/ 8. https://git.openstack.org/cgit/openstack/openstack-helm/tree/doc/source/specs 9. http://openstack-helm.readthedocs.io/ 10. http://eavesdrop.openstack.org/irclogs/%23openstack-helm/ 11. http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-5/%23openstack-meeting-5.2017-10-03.log.html 12. https://www.openstack.org/videos/search?search=openstack-helm 13. https://launchpad.net/openstack-helm 14. https://review.openstack.org/#/admin/groups/1749,members Change-Id: I70995640b6b760e7bfd7f1ec407b8004c855203f
2017-10-11 13:49:05 -05:00
openstack-helm-infra:
OpenStack-Helm does not require release management So far OpenStack-Helm has not used release management and is more continuously released. While that may change in the future, let's document that for now in governance. Change-Id: I17878d95f8b005316661d83ec8030c8d626f5800
2020-02-04 18:34:43 +01:00
release-management: external
OpenStack-Helm - Helm charts for OpenStack The mission of OpenStack-Helm[1] is to provide a collection of Helm charts that simply, resiliently, and flexibly deploy OpenStack and related services on Kubernetes. It allows the Helm client to be used directly to deploy OpenStack components, and as such is comarable to OpenStack-Ansible (providing playbooks for Ansible) or Puppet OpenStack (providing modules for Puppet). The project leverages native Kubernetes constructs and allows OpenStack projects to be installed in combinations and configurations per unique operator use cases. OpenStack-Helm has a goal to facilitate pushbutton automated deployments, and rolling upgrades with no impact to tenant workloads. There is a one-to-one correspondence between OpenStack projects and Helm charts, and charts are fully independent of one another. This allows for use cases from traditional OpenStack clouds, to deployment of standalone components, and combinations in between. The project provides reasonable, usable configuration by default, and allows for deployment-time overrides of individual values or a chart's entire values config. Dependent service endpoints (e.g. the Keystone API) default to Kubernetes cluster-internal DNS names, but can be overridden to point at external instances. Multiple, alternate SDN and SDS solutions will be integrated, and can be configured at deploy-time. The choice of container images is configurable as well, and can be mixed and matched on a chart-by-chart basis per operator needs. The project aims to be production-grade out-of-box, including configuration for highly available services, resilient storage for the control plane (e.g. Ceph), and security features such as cluster-internal TLS. OpenStack-Helm will follow the OpenStack independent release model[2], and will ensure Helm charts integrate with an OpenStack release once it is released. The team plans to change to cycle-trailing releases when ready, but will need to close the gap between Newton (current-state) and master first. In the meantime, it will model the cycle-trailing branch strategy as it catches up. The team is interested in feedback on this plan and advice from the TC. A number of OpenStack deployment projects pave the way for OpenStack-Helm, including OpenStack Ansible[3], Kolla-Kubernetes[4], OpenStack-Chef[5], and Puppet OpenStack [6]. OpenStack-Helm occupies a unique space in its exclusive use of Kubernetes-native constructs during the deployment process, including Helm packaging and gotpl templating. This tradeoff enables it to be as lightweight and simple as possible, at the expense of operator choice of deployment toolsets. The project team is eager to work with other OpenStack deployment projects to solve common needs and share learnings. The OpenStack-Helm project and the team follow the Four Opens: * Open Source: The project source code[7], specifications[8] and documentation[9] are open source and are developed in the community under the Apache 2.0 license. * Open Design: Design decisions are discussed and formalized via specifications, as well as openly discussed in the IRC chat room[10] and the team meetings[11]. The team had informal meetings at the Atlanta and Denver PTGs, as well as a presentation[12], hands-on workshop, and a related cross-project Forum at the Boston Summit. More of each are planned for Sydney. * Open Development: All OpenStack-Helm code is reviewed and hosted in OpenStack Infra[7]. blueprints and bugs are tracked by Launchpad[13]. Quality gates are run to ensure OpenStack deploys and runs with every patch set, and integration of standard Rally and Tempest tests is underway. * Open Community: The project team and core reviewer team[14] represent multiple employers, and are eager to groom new team members. Project discussions and Q&A are frequently held in the public IRC chat room, and all are welcome. 1. https://wiki.openstack.org/wiki/Openstack-helm 2. https://releases.openstack.org/reference/release_models.html 3. https://wiki.openstack.org/wiki/OpenStackAnsible 4. https://wiki.openstack.org/wiki/Kolla 5. https://wiki.openstack.org/wiki/Chef 6. https://docs.openstack.org/puppet-openstack-guide/latest/ 7. https://git.openstack.org/cgit/openstack/openstack-helm/ 8. https://git.openstack.org/cgit/openstack/openstack-helm/tree/doc/source/specs 9. http://openstack-helm.readthedocs.io/ 10. http://eavesdrop.openstack.org/irclogs/%23openstack-helm/ 11. http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-5/%23openstack-meeting-5.2017-10-03.log.html 12. https://www.openstack.org/videos/search?search=openstack-helm 13. https://launchpad.net/openstack-helm 14. https://review.openstack.org/#/admin/groups/1749,members Change-Id: I70995640b6b760e7bfd7f1ec407b8004c855203f
2017-10-11 13:49:05 -05:00
repos:
- openstack/openstack-helm-infra
Add openstack-helm-plugin git repository The repository is to contain the code of the OSH plugin for Helm CLI tool. Helm allows users install plugins from git repos but it assumes cloning the whole git repo to the user's machine which is not desirable. This repo will contain only a small portion of the OSH code which provides some convenience to users when they deploy Openstack using OSH charts. Depends-On: I1ec3e19c0dd8c83382e803525dd0b9612cfa75f8 Change-Id: Ib4b5e3baa22f87a19b3f75952eb8b587acd8283b
2024-04-16 12:30:55 -05:00
openstack-helm-plugin:
release-management: external
repos:
- openstack/openstack-helm-plugin
Fold LOCI into OpenStack-Helm LOCI has less contributors than in the past, and it makes sense to fold LOCI into one of its main users, OpenStack-Helm, rather than abandonning the project. Change-Id: Idc757dc1aa4edbed757ab715f92ea8278135a14a
2020-04-10 10:04:18 +02:00
loci:
release-management: none
repos:
- openstack/loci
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
OpenStackAnsible:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Record Wallaby Cycle PTL and TC election results This reflects the results of the elections held for PTL and TC positions in October 2020. Depends-On: https://review.opendev.org/757967 Change-Id: I037de61dddf30d9febfea5e819603040e0ccddd2
2020-10-14 00:43:41 +00:00
name: Dmitriy Rabotyagov
irc: noonedeadpunk
Update Dmitriy Rabotyagov email Change-Id: I100805fae27c75fa13ed52892115bbdb1e12b0d6
2022-04-27 08:18:42 +02:00
email: noonedeadpunk@gmail.com
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Ansible playbooks and roles for deployment
Add irc-channel for OpenStackAnsible The ansible folks hang out at #openstack-ansible, let's make it official. Change-Id: I8edcfe58241b2b693f2a961c5d20bcaa28661da0
2015-12-14 20:08:43 +01:00
irc-channel: openstack-ansible
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
mission: >
Deploying OpenStack from source in a way that makes it scalable
while also being simple to operate, upgrade, and grow.
url: https://wiki.openstack.org/wiki/OpenStackAnsible
deliverables:
Add config_template to OpenStack-Ansible The config_template is curated by the OpenStack-Ansible group until we find out a better place, or there are more people interested by it. Depends-On: https://review.openstack.org/#/c/546678/ Change-Id: I7cbf22fff1c483f23c59cae4d9e6669f4c857f04
2018-02-21 16:14:08 +00:00
ansible-config_template:
repos:
- openstack/ansible-config_template
Reorganise OpenStack-Ansible deliverables It does not make sense anymore for OpenStack-Ansible to consider all its roles within the same deliverable as openstack-ansible. OpenStack-Ansible is frequently tagged, while roles don't need tagging, as they are only consumed by their SHAs. All the repositories following the same branch/release strategy are now grouped into a single deliverable: openstack-ansible-roles. Repositories not following this strategy (i.e. repositories with only a 'master' branch or retired repositories) will not be part of the 'openstack-ansible-roles' deliverable. Change-Id: I4a528a035d44061d8cec530d6181bbaa40065f27
2018-08-07 14:14:46 +02:00
openstack-ansible:
Add new roles to OpenStack-Ansible Two new roles have been asked by the community: a way to deploy zun, and a way to use qpid dispatch router instead of rabbitmq. This patch includes both new roles, as we usually do: They will be separate of the openstack-ansible main deliverable, like other roles before it. Depends-On: https://review.openstack.org/#/c/572551/ Change-Id: I5fb2f24d2eecd38de793a1e739e14614b488e01d
2018-06-05 22:26:19 +02:00
repos:
Reorganise OpenStack-Ansible deliverables It does not make sense anymore for OpenStack-Ansible to consider all its roles within the same deliverable as openstack-ansible. OpenStack-Ansible is frequently tagged, while roles don't need tagging, as they are only consumed by their SHAs. All the repositories following the same branch/release strategy are now grouped into a single deliverable: openstack-ansible-roles. Repositories not following this strategy (i.e. repositories with only a 'master' branch or retired repositories) will not be part of the 'openstack-ansible-roles' deliverable. Change-Id: I4a528a035d44061d8cec530d6181bbaa40065f27
2018-08-07 14:14:46 +02:00
- openstack/openstack-ansible
openstack-ansible-roles:
Add python_venv_build ansible role to OSA deliverables In OpenStack-Ansible python venvs are built, packaged and consumed at run-time. Currently this uses the same code across multiple roles. This role will be used by OpenStack-Ansible to replace the duplicated code in every OSA role but could also be used by any other project who may wish to. The role is registered as an independent deliverable as it is not expected to require frequent releasing. Depends-On: https://review.openstack.org/553392 Change-Id: Ic4bad4c0cebe018c4a27e0cc79faf9186b7707de
2018-03-15 13:05:51 +00:00
repos:
Add frrouting route under OpenStack-Ansible governance In order to provide deployment for ovn-bgp-driver we'd need to also be able to deploy FRR as a dependency. There's already a role under Vexxhost namespace, though they do not intend to provide any further maintenance of the role. Thus we are moving the repo under OpenStack-Ansible governance. Depends-On: https://review.opendev.org/c/openstack/project-config/+/910018 Change-Id: Idf88d6d3a7fa1da1f28e45a5ada6fd20ccb77aef
2024-02-23 18:40:39 +01:00
- openstack/ansible-role-frrouting
Add ansible-role-httpd repo to OSA-owned projects In order to unify approach on handling Apache Web server deployment and configuration team come up with idea to produce a separate role for that as we have failed with finding existing one which would meet our intended "pluggable" design. Based on that a new repo/project is needed as we intend to make resulting role not opinionated and re-usable outside of OSA scope. Depends-On: https://review.opendev.org/c/openstack/project-config/+/935693 Change-Id: I2da92910e2897da10283bb93fcb6309c70d09d6e
2024-11-19 18:57:27 +01:00
- openstack/ansible-role-httpd
Reorganise OpenStack-Ansible deliverables It does not make sense anymore for OpenStack-Ansible to consider all its roles within the same deliverable as openstack-ansible. OpenStack-Ansible is frequently tagged, while roles don't need tagging, as they are only consumed by their SHAs. All the repositories following the same branch/release strategy are now grouped into a single deliverable: openstack-ansible-roles. Repositories not following this strategy (i.e. repositories with only a 'master' branch or retired repositories) will not be part of the 'openstack-ansible-roles' deliverable. Change-Id: I4a528a035d44061d8cec530d6181bbaa40065f27
2018-08-07 14:14:46 +02:00
- openstack/ansible-role-qdrouterd
Create ansible-role-pki repo This role aims to manage SSL certificate issue process - ie generation of self-signed certificates or distribution of user provided ones Depends-On: https://review.opendev.org/c/openstack/project-config/+/773385 Change-Id: I5b2d06a428738b29a1e2d583950a5e33a2ce4cdb
2021-02-01 14:55:56 +02:00
- openstack/ansible-role-pki
Add ProxySQL repository for OpenStack-Ansible We aim to switch balancing of MariaDB that is part of the deployment to ProxySQL and want to make a separate role for that which could be also used outside of the OSA. Depends-On: https://review.opendev.org/c/openstack/project-config/+/817271 Change-Id: I87f9978cbbc1bfc664828b7b674efe96690654b3
2021-11-09 17:54:15 +02:00
- openstack/ansible-role-proxysql
Add python_venv_build ansible role to OSA deliverables In OpenStack-Ansible python venvs are built, packaged and consumed at run-time. Currently this uses the same code across multiple roles. This role will be used by OpenStack-Ansible to replace the duplicated code in every OSA role but could also be used by any other project who may wish to. The role is registered as an independent deliverable as it is not expected to require frequent releasing. Depends-On: https://review.openstack.org/553392 Change-Id: Ic4bad4c0cebe018c4a27e0cc79faf9186b7707de
2018-03-15 13:05:51 +00:00
- openstack/ansible-role-python_venv_build
Add systemd roles to OpenStack-Ansible The systemd_mount and systemd_service roles are a way for OpenStack-Ansible to not repeat ourselves in the code. It can also be used by other members of the openstack community, and is therefore not mapped to our main deliverable. We are still curating it in our group: these roles will be important for deploying a cloud with openstack-ansible. Depends-On: https://review.openstack.org/#/c/552861 Change-Id: I098ccc03ff2e4a4bcb65e1f376f2c712b10c9c25
2018-03-14 10:12:23 +00:00
- openstack/ansible-role-systemd_mount
- openstack/ansible-role-systemd_networkd
- openstack/ansible-role-systemd_service
Add ansible-role-uwsgi to projects Since ansible-role-uwsgi project is intended to be used as a part of OpenStack-Ansible at the first place, it has been added to the referenced projects. Depends-On: https://review.opendev.org/676191 Change-Id: I347efbe6fa84122e240d947716208bbff5048af3
2019-08-13 16:38:03 +03:00
- openstack/ansible-role-uwsgi
Create repo for Hashicorp Vault deployment As part of implementation of the spec [1] we aim to offer basic Vault deployment out of the box as a tooling required for providing such kind of feature. [1] https://specs.openstack.org/openstack/openstack-ansible-specs/specs/xena/protecting-plaintext-configs.html Depends-On: https://review.opendev.org/c/openstack/project-config/+/799822 Change-Id: Iaa3ad26f4bbaa4c3693b16a87e7d938862c59ab0
2021-07-07 16:24:18 +03:00
- openstack/ansible-role-vault
Add zookeeper role under OpenStack-Ansible governance During last PTG there was decision to provide coordination service with OSA deployment. Depends-On: https://review.opendev.org/c/openstack/project-config/+/863158 Change-Id: I0885701b160819f0ce3760163d67bf9e3a385fbf
2022-11-01 17:46:53 +01:00
- openstack/ansible-role-zookeeper
Add ansible-hardening into our deliverables ansible-hardening has superseded openstack-ansible-security. It follows the same delivery model, and should therefore be included into the openstack-ansible deliverable, instead of being independant. That would simplify our "aggregated release" vision. Change-Id: I930bdd2b6f1b0bdd55799ad222186b8569a2a51c
2017-09-29 10:08:10 +00:00
- openstack/ansible-hardening
Added new projects for OpenStack-Ansible This updates governance for new roles that will be coming online as the OpenStack-Ansible moves to break out our roles from the main repo. Implements: blueprint independent-role-repositories Depends-On: Ibfd5e745b7c5836b1c421b06ff8ef1e122c14108 Change-Id: I63a999bdfae487f05e9918a2817433c6e026e79f Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
2015-11-11 09:46:16 -06:00
- openstack/openstack-ansible-apt_package_pinning
Add ceph_client and haproxy_server repositories to OSA These repositories have been carved out of the openstack/openstack-ansible repository in order to improve testing and facilitate better re-use. Depends-On: Ib383b46a4de86b2343be5414c4f39105d3f746b1 Change-Id: I0d0093d439e6f36a4c09baffe8490f7e341d8177
2016-08-21 16:27:54 +01:00
- openstack/openstack-ansible-ceph_client
Added new projects for OpenStack-Ansible This updates governance for new roles that will be coming online as the OpenStack-Ansible moves to break out our roles from the main repo. Change-Id: I86b614926c136e9296444e1904f6624b31c4c5e8 Implements: blueprint independent-role-repositories Depends-On: Ia7509050693d81a4b3e01898ea4d5a6bfac3d598 Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
2015-12-09 10:50:34 -06:00
- openstack/openstack-ansible-galera_server
Add ceph_client and haproxy_server repositories to OSA These repositories have been carved out of the openstack/openstack-ansible repository in order to improve testing and facilitate better re-use. Depends-On: Ib383b46a4de86b2343be5414c4f39105d3f746b1 Change-Id: I0d0093d439e6f36a4c09baffe8490f7e341d8177
2016-08-21 16:27:54 +01:00
- openstack/openstack-ansible-haproxy_server
Added new projects for OpenStack-Ansible This updates governance for new roles that will be coming online as the OpenStack-Ansible moves to break out our roles from the main repo. Implements: blueprint independent-role-repositories Depends-On: Ibfd5e745b7c5836b1c421b06ff8ef1e122c14108 Change-Id: I63a999bdfae487f05e9918a2817433c6e026e79f Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
2015-11-11 09:46:16 -06:00
- openstack/openstack-ansible-lxc_container_create
- openstack/openstack-ansible-lxc_hosts
Added new projects for OpenStack-Ansible This updates governance for new roles that will be coming online as the OpenStack-Ansible moves to break out our roles from the main repo. Change-Id: I86b614926c136e9296444e1904f6624b31c4c5e8 Implements: blueprint independent-role-repositories Depends-On: Ia7509050693d81a4b3e01898ea4d5a6bfac3d598 Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
2015-12-09 10:50:34 -06:00
- openstack/openstack-ansible-memcached_server
Added new projects for OpenStack-Ansible This updates governance for new roles that will be coming online as the OpenStack-Ansible moves to break out our roles from the main repo. Implements: blueprint independent-role-repositories Depends-On: Ibfd5e745b7c5836b1c421b06ff8ef1e122c14108 Change-Id: I63a999bdfae487f05e9918a2817433c6e026e79f Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
2015-11-11 09:46:16 -06:00
- openstack/openstack-ansible-openstack_hosts
Add additional OpenStack project repositories to OpenStack-Ansible This patch updates governance for new repositories implemented in the OpenStack-Ansible Project which implement the remaining OpenStack projects currently supported. Change-Id: I3f209979e965f21c021a8c4dedbe76270307b9cb Depends-On: I791d6c7721ed1e7ca2ae8631699fca24a1f917cf
2016-02-25 08:51:23 +00:00
- openstack/openstack-ansible-openstack_openrc
Reorganise OpenStack-Ansible deliverables It does not make sense anymore for OpenStack-Ansible to consider all its roles within the same deliverable as openstack-ansible. OpenStack-Ansible is frequently tagged, while roles don't need tagging, as they are only consumed by their SHAs. All the repositories following the same branch/release strategy are now grouped into a single deliverable: openstack-ansible-roles. Repositories not following this strategy (i.e. repositories with only a 'master' branch or retired repositories) will not be part of the 'openstack-ansible-roles' deliverable. Change-Id: I4a528a035d44061d8cec530d6181bbaa40065f27
2018-08-07 14:14:46 +02:00
- openstack/openstack-ansible-ops
Add openstack-ansible-os_adjutant repo As of adding adjutant deployment to openstack-ansible, we need to create another repo for it. Depends-On: https://review.opendev.org/736142 Change-Id: I84d20c9046e647daeaa3377d45d85b87389a8b5d
2020-06-17 12:26:21 +03:00
- openstack/openstack-ansible-os_adjutant
Consolidate integrated OSA repositories into one deliverable OpenStack-Ansible prepares a full set of integrated roles and playbooks from multiple repositories into one deliverable. All releases are done using the same tag number at the same time. This patch consolidates each of these into a single deliverable instead of considering each repository as a separate deliverable. Change-Id: I291ff553efd96c3dee5d36cb803140e66be2a40e
2016-06-07 15:41:58 +01:00
- openstack/openstack-ansible-os_aodh
Move os_designate & os_barbican into OSA deliverable The Designate and Barbican roles are now included as part of the OpenStack-Ansible integrated deliverable for the Ocata release. This patch moves the repository entries to reflect this change. Change-Id: I41bb2fb3c82f2e4ac04e3f58014cb11c46c72ab2
2016-11-16 10:20:01 +00:00
- openstack/openstack-ansible-os_barbican
Reorganise OpenStack-Ansible deliverables It does not make sense anymore for OpenStack-Ansible to consider all its roles within the same deliverable as openstack-ansible. OpenStack-Ansible is frequently tagged, while roles don't need tagging, as they are only consumed by their SHAs. All the repositories following the same branch/release strategy are now grouped into a single deliverable: openstack-ansible-roles. Repositories not following this strategy (i.e. repositories with only a 'master' branch or retired repositories) will not be part of the 'openstack-ansible-roles' deliverable. Change-Id: I4a528a035d44061d8cec530d6181bbaa40065f27
2018-08-07 14:14:46 +02:00
- openstack/openstack-ansible-os_blazar
Consolidate integrated OSA repositories into one deliverable OpenStack-Ansible prepares a full set of integrated roles and playbooks from multiple repositories into one deliverable. All releases are done using the same tag number at the same time. This patch consolidates each of these into a single deliverable instead of considering each repository as a separate deliverable. Change-Id: I291ff553efd96c3dee5d36cb803140e66be2a40e
2016-06-07 15:41:58 +01:00
- openstack/openstack-ansible-os_ceilometer
- openstack/openstack-ansible-os_cinder
Reorganise OpenStack-Ansible deliverables It does not make sense anymore for OpenStack-Ansible to consider all its roles within the same deliverable as openstack-ansible. OpenStack-Ansible is frequently tagged, while roles don't need tagging, as they are only consumed by their SHAs. All the repositories following the same branch/release strategy are now grouped into a single deliverable: openstack-ansible-roles. Repositories not following this strategy (i.e. repositories with only a 'master' branch or retired repositories) will not be part of the 'openstack-ansible-roles' deliverable. Change-Id: I4a528a035d44061d8cec530d6181bbaa40065f27
2018-08-07 14:14:46 +02:00
- openstack/openstack-ansible-os_cloudkitty
Move os_designate & os_barbican into OSA deliverable The Designate and Barbican roles are now included as part of the OpenStack-Ansible integrated deliverable for the Ocata release. This patch moves the repository entries to reflect this change. Change-Id: I41bb2fb3c82f2e4ac04e3f58014cb11c46c72ab2
2016-11-16 10:20:01 +00:00
- openstack/openstack-ansible-os_designate
Consolidate integrated OSA repositories into one deliverable OpenStack-Ansible prepares a full set of integrated roles and playbooks from multiple repositories into one deliverable. All releases are done using the same tag number at the same time. This patch consolidates each of these into a single deliverable instead of considering each repository as a separate deliverable. Change-Id: I291ff553efd96c3dee5d36cb803140e66be2a40e
2016-06-07 15:41:58 +01:00
- openstack/openstack-ansible-os_glance
Move os_gnocchi & os_magnum roles into the OSA deliverable The Gnocchi and Magnum roles are included as part of the OpenStack-Ansible integrated deliverable for the Newton release. This patch moves the repository entries to reflect this. Change-Id: Ia37309a784ac97b8ff3e4f445addfdd2b2f68efa
2016-08-16 16:43:53 +01:00
- openstack/openstack-ansible-os_gnocchi
Consolidate integrated OSA repositories into one deliverable OpenStack-Ansible prepares a full set of integrated roles and playbooks from multiple repositories into one deliverable. All releases are done using the same tag number at the same time. This patch consolidates each of these into a single deliverable instead of considering each repository as a separate deliverable. Change-Id: I291ff553efd96c3dee5d36cb803140e66be2a40e
2016-06-07 15:41:58 +01:00
- openstack/openstack-ansible-os_heat
- openstack/openstack-ansible-os_horizon
- openstack/openstack-ansible-os_ironic
- openstack/openstack-ansible-os_keystone
Move os_gnocchi & os_magnum roles into the OSA deliverable The Gnocchi and Magnum roles are included as part of the OpenStack-Ansible integrated deliverable for the Newton release. This patch moves the repository entries to reflect this. Change-Id: Ia37309a784ac97b8ff3e4f445addfdd2b2f68efa
2016-08-16 16:43:53 +01:00
- openstack/openstack-ansible-os_magnum
Add os_manila role to openstack-ansible Depends-On: I79cdb50333d65c575e1ae5e4eaa1005faf140aee Change-Id: I491997a36dfe7e1d2db1347b68d6410cff483633
2018-10-06 07:52:49 -04:00
- openstack/openstack-ansible-os_manila
Reorganise OpenStack-Ansible deliverables It does not make sense anymore for OpenStack-Ansible to consider all its roles within the same deliverable as openstack-ansible. OpenStack-Ansible is frequently tagged, while roles don't need tagging, as they are only consumed by their SHAs. All the repositories following the same branch/release strategy are now grouped into a single deliverable: openstack-ansible-roles. Repositories not following this strategy (i.e. repositories with only a 'master' branch or retired repositories) will not be part of the 'openstack-ansible-roles' deliverable. Change-Id: I4a528a035d44061d8cec530d6181bbaa40065f27
2018-08-07 14:14:46 +02:00
- openstack/openstack-ansible-os_masakari
Add os_mistral role to OpenStack-Ansible This patch aims to add os_mistral to the OpenStack-Ansible project. Depends-On: Ic5cab9cfbdc7b396d23d836224e38ffb5e3af3ba Change-Id: I82d372d7b93e87c41531f6483473ed223b2058f8
2019-02-04 16:40:02 -05:00
- openstack/openstack-ansible-os_mistral
Revive os_monasca Since we got a maintainer that is interested in revivng os_monasca role it was decided to revive os_monasca and get it maintained again. Depends-On: https://review.opendev.org/c/openstack/project-config/+/765799 Change-Id: Iff5b8a47a5418024e0d03070d62df43753cb09e0
2020-12-07 14:32:34 +02:00
- openstack/openstack-ansible-os_monasca
- openstack/openstack-ansible-os_monasca-agent
Consolidate integrated OSA repositories into one deliverable OpenStack-Ansible prepares a full set of integrated roles and playbooks from multiple repositories into one deliverable. All releases are done using the same tag number at the same time. This patch consolidates each of these into a single deliverable instead of considering each repository as a separate deliverable. Change-Id: I291ff553efd96c3dee5d36cb803140e66be2a40e
2016-06-07 15:41:58 +01:00
- openstack/openstack-ansible-os_neutron
- openstack/openstack-ansible-os_nova
Add roles into openstack-ansible deliverable Molteniron, octavia, and Tacker are delivered by default with OpenStack-Ansible. They follow the same delivery model, and should therefore be included into the openstack-ansible deliverable, instead of being independant. This is in-line with our "aggregated release" vision. Change-Id: I56940c1ad57d13408e3c708c12cb10dccccd84e7
2018-02-21 11:21:40 +00:00
- openstack/openstack-ansible-os_octavia
Add os_placement role to OpenStack-Ansible This patch aims to add os_placement to the OpenStack_Ansible project. Depends-On: https://review.openstack.org/#/c/614896/ Change-Id: Iddd50b7108361ab225ba52fa858e9200282f88f7
2018-11-02 13:32:58 +00:00
- openstack/openstack-ansible-os_placement
Move os_rally and os_sahara repositories into OSA deliverable The Rally and Sahara roles are now included as part of the OpenStack-Ansible integrated deliverable for the Newton release. This patch moves the repository entries to reflect this. Change-Id: I6a84868911b80bbb38f8cbf9e63518b5402c5e95
2016-08-30 15:07:37 +01:00
- openstack/openstack-ansible-os_rally
Add Skyline repository for OpenStack-Ansible Depends-On: https://review.opendev.org/c/openstack/project-config/+/863165 Change-Id: I5687eb246b518f9881d0df0a466936359d515e14
2022-11-01 18:14:28 +01:00
- openstack/openstack-ansible-os_skyline
Consolidate integrated OSA repositories into one deliverable OpenStack-Ansible prepares a full set of integrated roles and playbooks from multiple repositories into one deliverable. All releases are done using the same tag number at the same time. This patch consolidates each of these into a single deliverable instead of considering each repository as a separate deliverable. Change-Id: I291ff553efd96c3dee5d36cb803140e66be2a40e
2016-06-07 15:41:58 +01:00
- openstack/openstack-ansible-os_swift
Add roles into openstack-ansible deliverable Molteniron, octavia, and Tacker are delivered by default with OpenStack-Ansible. They follow the same delivery model, and should therefore be included into the openstack-ansible deliverable, instead of being independant. This is in-line with our "aggregated release" vision. Change-Id: I56940c1ad57d13408e3c708c12cb10dccccd84e7
2018-02-21 11:21:40 +00:00
- openstack/openstack-ansible-os_tacker
Consolidate integrated OSA repositories into one deliverable OpenStack-Ansible prepares a full set of integrated roles and playbooks from multiple repositories into one deliverable. All releases are done using the same tag number at the same time. This patch consolidates each of these into a single deliverable instead of considering each repository as a separate deliverable. Change-Id: I291ff553efd96c3dee5d36cb803140e66be2a40e
2016-06-07 15:41:58 +01:00
- openstack/openstack-ansible-os_tempest
Move os_trove into OSA deliverable The Trove role is now included as part of the OpenStack-Ansible integrated deliverable for the Ocata release. This patch moves the repository entries to reflect this move. Change-Id: I8bc89f1d4a36ef9db160d015de9176ce65dc4b20
2016-10-20 13:00:06 +01:00
- openstack/openstack-ansible-os_trove
Reorganise OpenStack-Ansible deliverables It does not make sense anymore for OpenStack-Ansible to consider all its roles within the same deliverable as openstack-ansible. OpenStack-Ansible is frequently tagged, while roles don't need tagging, as they are only consumed by their SHAs. All the repositories following the same branch/release strategy are now grouped into a single deliverable: openstack-ansible-roles. Repositories not following this strategy (i.e. repositories with only a 'master' branch or retired repositories) will not be part of the 'openstack-ansible-roles' deliverable. Change-Id: I4a528a035d44061d8cec530d6181bbaa40065f27
2018-08-07 14:14:46 +02:00
- openstack/openstack-ansible-os_zun
Consolidate integrated OSA repositories into one deliverable OpenStack-Ansible prepares a full set of integrated roles and playbooks from multiple repositories into one deliverable. All releases are done using the same tag number at the same time. This patch consolidates each of these into a single deliverable instead of considering each repository as a separate deliverable. Change-Id: I291ff553efd96c3dee5d36cb803140e66be2a40e
2016-06-07 15:41:58 +01:00
- openstack/openstack-ansible-plugins
- openstack/openstack-ansible-rabbitmq_server
- openstack/openstack-ansible-repo_server
Reorganise OpenStack-Ansible deliverables It does not make sense anymore for OpenStack-Ansible to consider all its roles within the same deliverable as openstack-ansible. OpenStack-Ansible is frequently tagged, while roles don't need tagging, as they are only consumed by their SHAs. All the repositories following the same branch/release strategy are now grouped into a single deliverable: openstack-ansible-roles. Repositories not following this strategy (i.e. repositories with only a 'master' branch or retired repositories) will not be part of the 'openstack-ansible-roles' deliverable. Change-Id: I4a528a035d44061d8cec530d6181bbaa40065f27
2018-08-07 14:14:46 +02:00
- openstack/openstack-ansible-tests
Deprecate OpenStack-Ansible nspawn repositories Since nspawn support has been removed with [1] we now start repositories deprecation process. [1] https://review.opendev.org/c/openstack/openstack-ansible/+/782569 Depends-On: https://review.opendev.org/c/openstack/project-config/+/797727 Change-Id: Ia3a00c8794d6fd7a1d5c405d9f93480990c37a72
2021-06-23 20:42:08 +03:00
openstack-ansible-nspawn_containers:
deprecated: wallaby
release-management: deprecated
repos:
- openstack/openstack-ansible-nspawn_container_create
- openstack/openstack-ansible-nspawn_hosts
Deprecate openstack-ansible-galera_client role Depends-On: https://review.opendev.org/c/openstack/project-config/+/765783 Change-Id: Ibecd340cd4548fb2111cb12c01550e9be296805e
2020-12-07 12:58:42 +02:00
openstack-ansible-galera_client:
deprecated: victoria
release-management: deprecated
repos:
- openstack/openstack-ansible-galera_client
Deprecate os_congress project Depends-On: https://review.opendev.org/742532 Change-Id: Ifbb169c5909ade254d79bc903bb145a9306bf533
2020-07-22 23:13:55 +03:00
openstack-ansible-os_congress:
deprecated: victoria
release-management: deprecated
repos:
- openstack/openstack-ansible-os_congress
Add os_karbor to OpenStack-Ansible The os_karbor repository is now curated by the OpenStack-Ansible community. Change-Id: I465da438762f3b675febd10009270ba6add8f27f Depends-On: Ia73f41427ab9360db057e1ce710f7b92375e0d3d
2017-04-12 15:59:10 +01:00
openstack-ansible-os_karbor:
Abandoned Ansible deliverables do not need relmgt A number of Ansible deliverables are abandoned and may be retired in the near future. As such they do not need release management, and should be marked release-management:deprecated. Change-Id: I0fdb2d0e54f9cb7b64145138ca8e22a147de9883
2018-12-12 15:05:32 +01:00
release-management: deprecated
Add os_karbor to OpenStack-Ansible The os_karbor repository is now curated by the OpenStack-Ansible community. Change-Id: I465da438762f3b675febd10009270ba6add8f27f Depends-On: Ia73f41427ab9360db057e1ce710f7b92375e0d3d
2017-04-12 15:59:10 +01:00
repos:
- openstack/openstack-ansible-os_karbor
Deprecate os-panko role Since upstream Panko project has retired, we deprecating role for it. Since we might want to get some patches in for stable branches, we're deprecating role instead of retiring it. Depends-On: https://review.opendev.org/c/openstack/project-config/+/799808 Change-Id: Idefe36d87dcd573884158b0885df163f9dc18334
2021-07-07 15:53:13 +03:00
openstack-ansible-os_panko:
deprecated: Xena
release-management: deprecated
repos:
- openstack/openstack-ansible-os_panko
Deprecate openstack-ansible rsyslog roles Rsyslog roles are not used actively by OSA code and were hardly maintained recently, thus we fully remove their usage and deprecate Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/861886 Change-Id: If8b6bc069dc105d3c630567769bc4df8fce642eb
2022-10-31 16:24:56 +01:00
openstack-ansible-rsyslog:
deprecated: Zed
release-management: deprecated
repos:
- openstack/openstack-ansible-rsyslog_server
- openstack/openstack-ansible-rsyslog_client
Added new projects for OpenStack-Ansible This updates governance for new roles that will be coming online as the OpenStack-Ansible moves to break out our roles from the main repo. Implements: blueprint independent-role-repositories Depends-On: Ibfd5e745b7c5836b1c421b06ff8ef1e122c14108 Change-Id: I63a999bdfae487f05e9918a2817433c6e026e79f Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
2015-11-11 09:46:16 -06:00
openstack-ansible-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Added new projects for OpenStack-Ansible This updates governance for new roles that will be coming online as the OpenStack-Ansible moves to break out our roles from the main repo. Implements: blueprint independent-role-repositories Depends-On: Ibfd5e745b7c5836b1c421b06ff8ef1e122c14108 Change-Id: I63a999bdfae487f05e9918a2817433c6e026e79f Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
2015-11-11 09:46:16 -06:00
repos:
- openstack/openstack-ansible-specs
Rename shade team to OpenStackSDK Align the name to be similar to OpenStackClient and to be clear what the team does. This doesn't indicate Python, even though the mission is currently limited to python. I don't believe there is a large appetite to move non-python OpenStack SDK work into OpenStack directly, but at such a time as such interest is shown, we could either rename the team again (fairly low-cost) or consider whether being a combined effort makes sense. In any case, this best describes the state of the world today. Change-Id: Ic7415e25c4f04f49f0feb538348254355830c846
2017-11-28 13:59:33 -06:00
OpenStackSDK:
ptl:
Record Wallaby Cycle PTL and TC election results This reflects the results of the elections held for PTL and TC positions in October 2020. Depends-On: https://review.opendev.org/757967 Change-Id: I037de61dddf30d9febfea5e819603040e0ccddd2
2020-10-14 00:43:41 +00:00
name: Artem Goncharov
irc: gtema
email: artem.goncharov@gmail.com
Appoint Monty Taylor as openstacksdk PTL Monty missed the election season due to PTO, but is willing to continue as openstacksdks PTL. Change-Id: I6eedbbafede5c3f41dcfba4ac9b6bb026166fa99
2019-09-16 10:25:43 +02:00
appointed:
- ussuri
Rename shade team to OpenStackSDK Align the name to be similar to OpenStackClient and to be clear what the team does. This doesn't indicate Python, even though the mission is currently limited to python. I don't believe there is a large appetite to move non-python OpenStack SDK work into OpenStack directly, but at such a time as such interest is shown, we could either rename the team again (fairly low-cost) or consider whether being a combined effort makes sense. In any case, this best describes the state of the world today. Change-Id: Ic7415e25c4f04f49f0feb538348254355830c846
2017-11-28 13:59:33 -06:00
irc-channel: openstack-sdks
Merge SDK and OSC teams The teams already share an IRC channel and already share a purpose in life. In OSC we have a current goal of swapping out client implementation for SDK, and SDK is already ensuring that it does what it needs to do to facilitate that goal. The teams also already share PTG space, and have requested a shared set of time at the upcoming Denver PTG. Really the separation is historical not practical at this point, and these days having the additional layers of governance is not super useful. Dean has also indicated in IRC that he is not going to be able to continue working on OSC: http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2020-03-02.log.html#t2020-03-02T17:59:06 We obviously hope that the universe conspires to change that, but we all have to accept the sad truth. Change-Id: Ib1088af1e56e083ee20e8b1623ec7d0fb4335334
2020-03-04 09:29:17 -06:00
service: Multi-cloud Python SDK and CLI for End Users
Rename shade team to OpenStackSDK Align the name to be similar to OpenStackClient and to be clear what the team does. This doesn't indicate Python, even though the mission is currently limited to python. I don't believe there is a large appetite to move non-python OpenStack SDK work into OpenStack directly, but at such a time as such interest is shown, we could either rename the team again (fairly low-cost) or consider whether being a combined effort makes sense. In any case, this best describes the state of the world today. Change-Id: Ic7415e25c4f04f49f0feb538348254355830c846
2017-11-28 13:59:33 -06:00
mission: >
Add OpenAPI related projects under the OpenStackSDK - add `codegenerator` repository used to generate OpenAPI specs from service sources and client API bindings from the OpenAPI - add `openapi` repository with documents describing OpenStack flavouring of OpenAPI and Sphinx extension to render them similar to os-api-ref - slightly adapt the overall team mission to better match the reality Depends-On: https://review.opendev.org/c/openstack/project-config/+/910580 Change-Id: I3513c3363eed62155291f2d9bf094bf07725df64
2024-02-29 09:32:11 +01:00
To provide a unified multi-cloud aware SDK and CLI for the OpenStack
Merge SDK and OSC teams The teams already share an IRC channel and already share a purpose in life. In OSC we have a current goal of swapping out client implementation for SDK, and SDK is already ensuring that it does what it needs to do to facilitate that goal. The teams also already share PTG space, and have requested a shared set of time at the upcoming Denver PTG. Really the separation is historical not practical at this point, and these days having the additional layers of governance is not super useful. Dean has also indicated in IRC that he is not going to be able to continue working on OSC: http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2020-03-02.log.html#t2020-03-02T17:59:06 We obviously hope that the universe conspires to change that, but we all have to accept the sad truth. Change-Id: Ib1088af1e56e083ee20e8b1623ec7d0fb4335334
2020-03-04 09:29:17 -06:00
REST API exposing both the full set of low-level APIs as well as curated higher
Add OpenAPI related projects under the OpenStackSDK - add `codegenerator` repository used to generate OpenAPI specs from service sources and client API bindings from the OpenAPI - add `openapi` repository with documents describing OpenStack flavouring of OpenAPI and Sphinx extension to render them similar to os-api-ref - slightly adapt the overall team mission to better match the reality Depends-On: https://review.opendev.org/c/openstack/project-config/+/910580 Change-Id: I3513c3363eed62155291f2d9bf094bf07725df64
2024-02-29 09:32:11 +01:00
level business logic. Ensure end user is having necessary tools to work
with OpenStack based clouds.
Rename python-openstacksdk to openstacksdk Change-Id: Idb27b651d626bc1579517cae53779aaabb361cb8
2018-03-23 08:47:16 -05:00
url: https://docs.openstack.org/openstacksdk/latest/
Rename shade team to OpenStackSDK Align the name to be similar to OpenStackClient and to be clear what the team does. This doesn't indicate Python, even though the mission is currently limited to python. I don't believe there is a large appetite to move non-python OpenStack SDK work into OpenStack directly, but at such a time as such interest is shown, we could either rename the team again (fairly low-cost) or consider whether being a combined effort makes sense. In any case, this best describes the state of the world today. Change-Id: Ic7415e25c4f04f49f0feb538348254355830c846
2017-11-28 13:59:33 -06:00
deliverables:
Merge SDK and OSC teams The teams already share an IRC channel and already share a purpose in life. In OSC we have a current goal of swapping out client implementation for SDK, and SDK is already ensuring that it does what it needs to do to facilitate that goal. The teams also already share PTG space, and have requested a shared set of time at the upcoming Denver PTG. Really the separation is historical not practical at this point, and these days having the additional layers of governance is not super useful. Dean has also indicated in IRC that he is not going to be able to continue working on OSC: http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2020-03-02.log.html#t2020-03-02T17:59:06 We obviously hope that the universe conspires to change that, but we all have to accept the sad truth. Change-Id: Ib1088af1e56e083ee20e8b1623ec7d0fb4335334
2020-03-04 09:29:17 -06:00
cliff:
repos:
- openstack/cliff
Add OpenAPI related projects under the OpenStackSDK - add `codegenerator` repository used to generate OpenAPI specs from service sources and client API bindings from the OpenAPI - add `openapi` repository with documents describing OpenStack flavouring of OpenAPI and Sphinx extension to render them similar to os-api-ref - slightly adapt the overall team mission to better match the reality Depends-On: https://review.opendev.org/c/openstack/project-config/+/910580 Change-Id: I3513c3363eed62155291f2d9bf094bf07725df64
2024-02-29 09:32:11 +01:00
codegenerator:
repos:
- openstack/codegenerator
openapi:
repos:
- openstack/openapi
Merge SDK and OSC teams The teams already share an IRC channel and already share a purpose in life. In OSC we have a current goal of swapping out client implementation for SDK, and SDK is already ensuring that it does what it needs to do to facilitate that goal. The teams also already share PTG space, and have requested a shared set of time at the upcoming Denver PTG. Really the separation is historical not practical at this point, and these days having the additional layers of governance is not super useful. Dean has also indicated in IRC that he is not going to be able to continue working on OSC: http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2020-03-02.log.html#t2020-03-02T17:59:06 We obviously hope that the universe conspires to change that, but we all have to accept the sad truth. Change-Id: Ib1088af1e56e083ee20e8b1623ec7d0fb4335334
2020-03-04 09:29:17 -06:00
openstackclient:
repos:
- openstack/openstackclient
Rename python-openstacksdk to openstacksdk Change-Id: Idb27b651d626bc1579517cae53779aaabb361cb8
2018-03-23 08:47:16 -05:00
openstacksdk:
Rename shade team to OpenStackSDK Align the name to be similar to OpenStackClient and to be clear what the team does. This doesn't indicate Python, even though the mission is currently limited to python. I don't believe there is a large appetite to move non-python OpenStack SDK work into OpenStack directly, but at such a time as such interest is shown, we could either rename the team again (fairly low-cost) or consider whether being a combined effort makes sense. In any case, this best describes the state of the world today. Change-Id: Ic7415e25c4f04f49f0feb538348254355830c846
2017-11-28 13:59:33 -06:00
repos:
Rename python-openstacksdk to openstacksdk Change-Id: Idb27b651d626bc1579517cae53779aaabb361cb8
2018-03-23 08:47:16 -05:00
- openstack/openstacksdk
Move os-client-config to OpenStackSDK from OpenStackClient team OpenStackClient is not the only user of os-client-config, its future is being merged into OpenStackSDK and this repo will exist as a compatibility shim following that release. It should live there next to shade, which has a similar future. Change-Id: Idc87dca22f0845b3b44cdfd2d89e570d8d0594f8
2017-11-30 10:56:33 -06:00
os-client-config:
repos:
- openstack/os-client-config
Rename shade team to OpenStackSDK Align the name to be similar to OpenStackClient and to be clear what the team does. This doesn't indicate Python, even though the mission is currently limited to python. I don't believe there is a large appetite to move non-python OpenStack SDK work into OpenStack directly, but at such a time as such interest is shown, we could either rename the team again (fairly low-cost) or consider whether being a combined effort makes sense. In any case, this best describes the state of the world today. Change-Id: Ic7415e25c4f04f49f0feb538348254355830c846
2017-11-28 13:59:33 -06:00
os-service-types:
repos:
- openstack/os-service-types
Merge SDK and OSC teams The teams already share an IRC channel and already share a purpose in life. In OSC we have a current goal of swapping out client implementation for SDK, and SDK is already ensuring that it does what it needs to do to facilitate that goal. The teams also already share PTG space, and have requested a shared set of time at the upcoming Denver PTG. Really the separation is historical not practical at this point, and these days having the additional layers of governance is not super useful. Dean has also indicated in IRC that he is not going to be able to continue working on OSC: http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2020-03-02.log.html#t2020-03-02T17:59:06 We obviously hope that the universe conspires to change that, but we all have to accept the sad truth. Change-Id: Ib1088af1e56e083ee20e8b1623ec7d0fb4335334
2020-03-04 09:29:17 -06:00
osc-lib:
repos:
- openstack/osc-lib
python-openstackclient:
repos:
- openstack/python-openstackclient
Rename shade team to OpenStackSDK Align the name to be similar to OpenStackClient and to be clear what the team does. This doesn't indicate Python, even though the mission is currently limited to python. I don't believe there is a large appetite to move non-python OpenStack SDK work into OpenStack directly, but at such a time as such interest is shown, we could either rename the team again (fairly low-cost) or consider whether being a combined effort makes sense. In any case, this best describes the state of the world today. Change-Id: Ic7415e25c4f04f49f0feb538348254355830c846
2017-11-28 13:59:33 -06:00
requestsexceptions:
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/requestsexceptions
Rename shade team to OpenStackSDK Align the name to be similar to OpenStackClient and to be clear what the team does. This doesn't indicate Python, even though the mission is currently limited to python. I don't believe there is a large appetite to move non-python OpenStack SDK work into OpenStack directly, but at such a time as such interest is shown, we could either rename the team again (fairly low-cost) or consider whether being a combined effort makes sense. In any case, this best describes the state of the world today. Change-Id: Ic7415e25c4f04f49f0feb538348254355830c846
2017-11-28 13:59:33 -06:00
shade:
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/shade
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
oslo:
Reset the DPL model for oslo project As per the DPL model policy, we need to reset the DPL model and its liaisons every cycle[1]. As per process, oslo team either needs to opt-in the DPL model for the next cycle or have the PTL in coming election. [1] https://governance.openstack.org/tc/reference/distributed-project-leadership.html#dpl-model-liaison-duration Change-Id: Id7eac2122dd1197564636a8a5f96e5d328113897
2025-01-16 11:26:09 -08:00
ptl:
name: APPOINTMENT NEEDED
irc: No nick supplied
email: example@example.org
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-oslo
service: Common libraries
mission: >
To produce a set of python libraries containing code shared by OpenStack
projects. The APIs provided by these libraries should be high quality,
stable, consistent, documented and generally applicable.
url: https://wiki.openstack.org/wiki/Oslo
deliverables:
automaton:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/automaton
Move castellan under Oslo governance The Barbican team would like to move Castellan under Oslo. The hope is to send a clear signal to everyone that castellan is the preferred library for their key manager needs and sufficiently abstracts hard dependency to barbican and attract new folks with alternate implementations. http://lists.openstack.org/pipermail/openstack-dev/2017-March/114335.html http://eavesdrop.openstack.org/meetings/barbican/2017/barbican.2017-03-20-20.00.txt Change-Id: I571dc981a198fcde1a8bdf626ce159b860d452aa
2017-03-23 09:18:10 -04:00
castellan:
repos:
- openstack/castellan
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
cookiecutter:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/cookiecutter
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
debtcollector:
repos:
- openstack/debtcollector
devstack-plugin-amqp1:
Making devstack-plugin-(amqp1|kafka) branchless The QA team pointed out to us that usually devstack plugins are branchless [1] (and tagless but that's already the case here). They haven't been branched since ussuri, we think that we simply missed to retire them few series ago. I think that's the right moment to do a little spring cleaning. Let's drop these deliverables. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021526.html Change-Id: I7df2166cdd4b9266287d47d90c3cd49d6d122c71
2021-04-02 10:14:01 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/devstack-plugin-amqp1
Add devstack-plugin-kafka project Change-Id: Ic9a17b62569bc1829d46e94b1a05f8c43bfac287 Depends-On: I9851e3c894bbbda03c488153a9d8f88709d93384 Implements: blueprint adding-kafka-support
2015-11-19 04:23:23 +09:00
devstack-plugin-kafka:
Making devstack-plugin-(amqp1|kafka) branchless The QA team pointed out to us that usually devstack plugins are branchless [1] (and tagless but that's already the case here). They haven't been branched since ussuri, we think that we simply missed to retire them few series ago. I think that's the right moment to do a little spring cleaning. Let's drop these deliverables. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021526.html Change-Id: I7df2166cdd4b9266287d47d90c3cd49d6d122c71
2021-04-02 10:14:01 +02:00
release-management: none
Add devstack-plugin-kafka project Change-Id: Ic9a17b62569bc1829d46e94b1a05f8c43bfac287 Depends-On: I9851e3c894bbbda03c488153a9d8f88709d93384 Implements: blueprint adding-kafka-support
2015-11-19 04:23:23 +09:00
repos:
- openstack/devstack-plugin-kafka
Add etcd3gw to Oslo Per [1] and [2]. [1] https://github.com/dims/etcd3-gateway/issues/29 [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016470.html Depends-On: https://review.opendev.org/747185 Change-Id: I8ff74b63f17c89089428793e7155a413bef94fb9
2020-08-20 16:39:13 +02:00
etcd3gw:
repos:
- openstack/etcd3gw
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
futurist:
repos:
- openstack/futurist
Adoption of microversion-parse by Oslo team A recent review of the OpenStack namespace yielded a library that no project team owns, and yet is specific to openstack and present in global-requirements: microversion-parse. After discussing it with cdent, and since it is openstack-specific and depended on by most openstack projects, it feels like Oslo would be a good home for it. It would follow an "independent" release model and I don't think it would trigger much updates or maintenance. Change-Id: I50f543083b2d1286d4fcf9896b22ef42ad763c04
2019-10-21 16:11:42 +02:00
microversion-parse:
repos:
- openstack/microversion-parse
Initiate process of migrating Documentation project to a SIG The first step of this is moving the code deliverables to Oslo. This has already been discussed with the Oslo PTL. Change-Id: If7ad13546aae99d97562e99dda5b4e114e0659ac Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2019-05-04 10:35:39 -06:00
openstack-doc-tools:
repos:
- openstack/openstack-doc-tools
openstackdocstheme:
repos:
- openstack/openstackdocstheme
os-api-ref:
repos:
- openstack/os-api-ref
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
oslo-cookiecutter:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/oslo-cookiecutter
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
oslo-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo-specs
oslo.cache:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.cache
oslo.concurrency:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.concurrency
oslo.config:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.config
oslo.context:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.context
oslo.db:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.db
oslo.i18n:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.i18n
Create a new project called oslo.limit This commit creates a new oslo library called oslo.limit to help services enforce quota based on limit information stored in keystone. Depends-On: I1bdb05189fa0346426cb36d4a3d5fe458eb69871 Change-Id: I46d5d16f29a4a613c96f01023c89e94b39abf2dd
2018-03-07 15:13:40 +00:00
oslo.limit:
repos:
- openstack/oslo.limit
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
oslo.log:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.log
oslo.messaging:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.messaging
Add repository for oslo.metrics Following [1], initial code for oslo.metrics should soon be proposed. Let's create a repository in OpenDev to host that code. [1] https://specs.openstack.org/openstack/oslo-specs/specs/ussuri/oslo-metrics.html Depends-On: https://review.opendev.org/725847 Change-Id: I454700e72ba8c9a7a59e69c97011884ea5b7ae15
2020-05-06 14:39:04 +02:00
oslo.metrics:
repos:
- openstack/oslo.metrics
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
oslo.middleware:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.middleware
oslo.policy:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.policy
Add oslo.privsep to Oslo team repository list Change-Id: Iee80b90cc17b9e8b856c9cacd544c83ca3d20b06 Depends-On: Iee84120f4da14ee3d441933a0e03a67c22fce8d1
2015-07-22 17:50:15 +10:00
oslo.privsep:
repos:
- openstack/oslo.privsep
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
oslo.reports:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.reports
oslo.rootwrap:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.rootwrap
oslo.serialization:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.serialization
oslo.service:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.service
Create new non-released oslo managed oslo.tools repository This repository and subproject will be for useful tools extracted from the oslo incubator and used by various folks in the oslo community (as well as the ptl). Its creation will allow for completion of the retirement of the oslo-incubator repo. Depends-On: Id5ed1a47c9bf1e4b25557b8ce802ef01694a2780 Change-Id: I818886696aee39c2fef786f21c59202b4ced1dbe
2016-05-12 14:38:20 -07:00
oslo.tools:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Create new non-released oslo managed oslo.tools repository This repository and subproject will be for useful tools extracted from the oslo incubator and used by various folks in the oslo community (as well as the ptl). Its creation will allow for completion of the retirement of the oslo-incubator repo. Depends-On: Id5ed1a47c9bf1e4b25557b8ce802ef01694a2780 Change-Id: I818886696aee39c2fef786f21c59202b4ced1dbe
2016-05-12 14:38:20 -07:00
repos:
- openstack/oslo.tools
Add oslo.upgradecheck This will be used to house the common code for the upgrade check commands. Change-Id: Ia5368412e73833100e07c3c1f279efdb21b2a8e5 Depends-On: https://review.openstack.org/602493
2018-09-13 22:39:02 +00:00
oslo.upgradecheck:
repos:
- openstack/oslo.upgradecheck
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
oslo.utils:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.utils
oslo.versionedobjects:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.versionedobjects
oslo.vmware:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslo.vmware
oslotest:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/oslotest
Add OSprofiler project OSprofiler is now part of Oslo: https://review.openstack.org/#/c/103825/ Change-Id: I8f1ec10bf9252efd1429a24b6ef1a9de1230f782
2016-01-12 17:54:13 -08:00
osprofiler:
repos:
- openstack/osprofiler
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
pbr:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/pbr
feature-classification: a common lib for FeatCl frameworks Create a new repo to contain the frameworks for feature classification. So that all projects can use the frameworks for their own implementations. Based on discussions found here: https://review.openstack.org/#/c/330027/ Depends-On: I914c23ba4298c91583bbb54de4bf3cfe092ef9e6 Change-Id: I5117c2f49860ce68b52035d95bd90684c6122924
2017-04-02 11:18:50 -05:00
sphinx-feature-classification:
repos:
- openstack/sphinx-feature-classification
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
stevedore:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/stevedore
taskflow:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/taskflow
tooz:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/tooz
Initiate process of migrating Documentation project to a SIG The first step of this is moving the code deliverables to Oslo. This has already been discussed with the Oslo PTL. Change-Id: If7ad13546aae99d97562e99dda5b4e114e0659ac Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2019-05-04 10:35:39 -06:00
whereto:
repos:
- openstack/whereto
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
Puppet OpenStack:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Close Zed PTL Elections Change-Id: I1ff1ef20ea9d3da8e8123d5c2ddef2d10a45a9ef
2022-02-24 16:35:09 -06:00
name: Takashi Kajinami
irc: tkajinam
Update email address of Takashi Kajinami Change-Id: I488bcaa723cc950a60d088e22afc62eb2bee75c7
2023-10-13 12:16:20 +09:00
email: kajinamit@oss.nttdata.com
Appoint Tobias Urdin as Puppet OpenStack PTL Tobias Urdin raised late candidacy to server as Puppet OpenStack PTL position for Yoga Cycle - https://review.opendev.org/c/openstack/election/+/806099 - https://etherpad.opendev.org/p/yoga-leaderless Change-Id: Ibbfa92e9ed38faf393954a293203167ca23edc2a
2021-09-08 09:58:47 -05:00
appointed:
- yoga
Add Puppet OpenStack project IRC channel name Change-Id: Ia598373a1346be8bef8cefe34d0f8d8827c7f6b4
2021-09-08 10:24:33 -05:00
irc-channel: puppet-openstack
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Puppet modules for deployment
Adding the Puppet modules to OpenStack The Puppet modules for OpenStack bring scalable and reliable IT automation to OpenStack cloud deployments. They enable system administrators to automate any lifecycle stage of their OpenStack infrastructure. The code base has existed for more than 3 years in the stackforge code namespace. The contributors come from various companies including Puppet Labs, Red Hat, iWeb, Time Warner Cable, Aptira, Mirantis and more. Our meetings are weekly, on IRC, and our roadmap is transparent and managed on Launchpad again using standard OpenStack community practices [1]. Our group wanted to elect and only one (me) applied [2] so we have a PTL of this project. This patch is an official request to be part of the big tent and become an official project. [1] https://wiki.openstack.org/wiki/Puppet [2] https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg49290.html Change-Id: Ic6257647916e8fabf9f7032f2db2415696078ce7
2015-04-01 20:25:24 -04:00
mission: >
The Puppet modules for OpenStack bring scalable and reliable IT automation
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
to OpenStack cloud deployments.
Update docs URLs With the reorg on docs.o.o, the projects publish to new places, adjust all URLs. Also, use https everywhere. Change-Id: I28422350e3e37fb4a9b3905e9ed36e3f98fe0c58
2017-08-22 19:08:18 +02:00
url: https://docs.openstack.org/puppet-openstack-guide/latest/
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
projects/puppet: add puppet-aodh Ceilometer has now its own project for Alarming, that contains specific configuration files, services, endpoints, etc. It requires a new Puppet module to be created and be part of Puppet OpenStack modules. Depends-On: Iaf64f4d1d2e52e671032091efab0494f6ce59a4f Change-Id: I7d1804e1c9234a097c3369558c427b03e364bfc4
2015-09-10 12:57:56 -04:00
puppet-aodh:
repos:
- openstack/puppet-aodh
Create puppet-barbican repository Puppet module to deploy Barbican [1] which is a project part of the big tent [2]. [1] https://wiki.openstack.org/wiki/Barbican [2] http://governance.openstack.org/reference/projects/barbican.html Change-Id: I8b7095c7e95abe51b3ce31a30135b8117c4d6a64
2015-09-30 17:47:24 -04:00
puppet-barbican:
repos:
- openstack/puppet-barbican
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-ceilometer:
repos:
- openstack/puppet-ceilometer
Add puppet-ceph under puppet-openstack group puppet-ceph has gained alot of support and maintenance from the puppet-openstack team and it's time to move into the tent with them Change-Id: I94206165d8626329c153e2abaa49bd9ae4793ed2
2016-03-31 12:57:24 -07:00
puppet-ceph:
repos:
- openstack/puppet-ceph
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-cinder:
repos:
- openstack/puppet-cinder
projects/puppet: add puppet-cloudkitty Cloudkitty is a rating service for Openstack. This repo contains the Puppet module for Cloudkitty. Change-Id: I93b44128cc0f51f22956eb93faabc74651129ef5 Depends-On: Ie771a2257fe751a45a299f7e8f49375629d8d16c
2016-09-27 17:53:08 +02:00
puppet-cloudkitty:
repos:
- openstack/puppet-cloudkitty
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-designate:
repos:
- openstack/puppet-designate
puppet-glance:
repos:
- openstack/puppet-glance
puppet-gnocchi:
repos:
- openstack/puppet-gnocchi
puppet-heat:
repos:
- openstack/puppet-heat
puppet-horizon:
repos:
- openstack/puppet-horizon
puppet-ironic:
repos:
- openstack/puppet-ironic
puppet-keystone:
repos:
- openstack/puppet-keystone
Create puppet-magnum repository Commit adding information for a new puppet-magnum project. Change-Id: I91df8dd52ddfe257266e5e205085b43a31af9c67
2015-10-29 18:22:03 +00:00
puppet-magnum:
repos:
- openstack/puppet-magnum
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-manila:
repos:
- openstack/puppet-manila
puppet-mistral:
repos:
- openstack/puppet-mistral
puppet-neutron:
repos:
- openstack/puppet-neutron
puppet-nova:
repos:
- openstack/puppet-nova
Add puppet-octavia to Puppet OpenStack family Octavia is Neutron sub-project which aims to bring scalable load-balancing in OpenStack. Puppet OpenStack group will write the Puppet module to deploy it. This patch adds it in reference/projects.yaml officially. Change-Id: I14736e34eb506ddc3a9d961fc65c2093a91d994c
2016-01-26 18:37:46 -05:00
puppet-octavia:
repos:
- openstack/puppet-octavia
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-openstack-cookiecutter:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
- openstack/puppet-openstack-cookiecutter
Create puppet-openstack-guide Currently Puppet OpenStack documention is hosted on Wiki [1] and we would like to use RST and Gerrit to manage documentation in future, like other projects, so we can leave Wiki. On each existing Wiki page of Puppet OpenStack, we'll give the new URL so we don't break indexes. [1] https://wiki.openstack.org/wiki/Puppet Change-Id: I8a42fd763913775834c9e621ca7582199705773d
2016-03-23 16:09:19 -04:00
puppet-openstack-guide:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Create puppet-openstack-guide Currently Puppet OpenStack documention is hosted on Wiki [1] and we would like to use RST and Gerrit to manage documentation in future, like other projects, so we can leave Wiki. On each existing Wiki page of Puppet OpenStack, we'll give the new URL so we don't break indexes. [1] https://wiki.openstack.org/wiki/Puppet Change-Id: I8a42fd763913775834c9e621ca7582199705773d
2016-03-23 16:09:19 -04:00
repos:
- openstack/puppet-openstack-guide
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-openstack-integration:
repos:
- openstack/puppet-openstack-integration
puppet-openstack_extras:
repos:
- openstack/puppet-openstack_extras
Add puppet-openstack_spec_helper repo to Puppet OpenStack project puppet-openstack_spec_helper will be a Gem library consummed by Puppet OpenStack modules. It will be first use to put common code used to configure beaker-rspec but it could become later a common library used by our modules to realize common tasks specific to OpenStack CI. Change-Id: I1e0ae76f4e2a2d88c2daa7918b79eebe3e0010d0
2015-09-29 16:01:02 -04:00
puppet-openstack_spec_helper:
repos:
- openstack/puppet-openstack_spec_helper
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-openstacklib:
repos:
- openstack/puppet-openstacklib
Add puppet-oslo to Puppet OpenStack family Some recent open discussions on the openstack-dev mailing list made us think we should configure Oslo bits with a dedicated Puppet module instead of having duplicate code in our modules. This patch aims to add puppet-oslo to the Puppet OpenStack family. This module will be compliant, tested, documented and released like other modules. Change-Id: I9ba072a828bd09137a65b2e0b2c4b7a98345e807
2016-01-21 10:43:15 -05:00
puppet-oslo:
repos:
- openstack/puppet-oslo
Add puppet-ovn to Puppet OpenStack networking-ovn is a project part of OpenStack Neutron: http://docs.openstack.org/developer/networking-ovn/readme.html "OVN provides virtual networking for Open vSwitch and is a component of the Open vSwitch project. This project provides integration between OpenStack Neutron and OVN." Red Hat started to work on a Puppet module that installs & configures OVN services, on top of Open-vSwitch: https://github.com/redhat-cip/puppet-ovn We would like to move it to OpenStack under Puppet OpenStack tent. Why not deploying OVN with puppet-vswitch? OVN is a part of the OVS project. It's even in the same git repo as OVS right now. OVN consists of some new daemons and databases. It's optional components that you may enable on top of OVS. But openstack/puppet-vswitch abstracts away the vswitch details in its interface, so puppet-ovn would likely consume puppet-vswitch. Change-Id: Idd8dc346b8368c926a5f2fc5c2cc8c34376f30f5
2016-03-09 09:47:48 -05:00
puppet-ovn:
repos:
- openstack/puppet-ovn
Add puppet-placement to deploy OpenStack Placement This is a new service that we'll deploy with an indiviual module. Depends-On: Iaa49c42eb41a0826b2499d3210144131e067eb72 Change-Id: Ib72426d8722c066c63e661eca879338835028a34
2018-09-15 11:36:31 -06:00
puppet-placement:
repos:
- openstack/puppet-placement
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-swift:
repos:
- openstack/puppet-swift
puppet-tempest:
repos:
- openstack/puppet-tempest
puppet-trove:
repos:
- openstack/puppet-trove
Add puppet-vitrage to Puppet team Depends-On: I39d3e09336b220a623dffddc66060f49e64a3ebc Change-Id: I8bec7a2d639f63d8379162e982385f626f77f6f4
2015-12-06 08:59:45 +02:00
puppet-vitrage:
repos:
- openstack/puppet-vitrage
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-vswitch:
repos:
- openstack/puppet-vswitch
Add puppet-watcher to Puppet OpenStack "Watcher provides a flexible and scalable resource optimization service for multi-tenant OpenStack-based clouds. Watcher provides a complete optimization loop—including everything from a metrics receiver, complex event processor and profiler, optimization processor and an action plan applier. This provides a robust framework to realize a wide range of cloud optimization goals, including the reduction of data center operating costs, increased system performance via intelligent virtual machine migration, increased energy efficiency." More information about Watcher project: https://launchpad.net/watcher OVH started to work on the Puppet watcher module that installs and configures Watcher services. We would like to move it to OpenStack under Puppet OpenStack tent. Change-Id: I35dac80b993661389d8b7f87405c05ef1c6ae567
2016-05-30 13:50:33 +00:00
puppet-watcher:
repos:
- openstack/puppet-watcher
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
puppet-zaqar:
repos:
- openstack/puppet-zaqar
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
Quality Assurance:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Close Xena Elections Depends-On: https://review.opendev.org/c/openstack/election/+/779845 Change-Id: Ideda5fbd4479f9c7821ff03838d6130dd723fa49
2021-03-10 09:32:23 -08:00
name: Martin Kopec
Add some PTLs missing irc nick name Change-Id: Ia9a13c10c36f400fb95719a20566c3d826264c9a
2021-09-08 10:21:35 -05:00
irc: kopecmartin
Close Xena Elections Depends-On: https://review.opendev.org/c/openstack/election/+/779845 Change-Id: Ideda5fbd4479f9c7821ff03838d6130dd723fa49
2021-03-10 09:32:23 -08:00
email: mkopec@redhat.com
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-qa
Adding the Chef cookbooks to OpenStack This in the commit to added the Chef cookbooks to the OpenStack name space. Our meetings and office hours are twice weekly[1], on IRC, and our roadmap is as transparent and managed on Launchpad again using standard OpenStack community practices[3]. As of 2015-04-27 our community has decided to depreciate the Monday Hangout in favor for IRC. The youtube channel[2] will be there for historical tracking, but we will leverage the IRC logging here[4]. This patch is an official request to be part of the big tent and become an official project. [1] https://wiki.openstack.org/wiki/Chef/GettingStarted#Communication [2] https://www.youtube.com/channel/UCPQhSl-wxgWJH6_r7pk5PbQ/videos [3] https://wiki.openstack.org/wiki/Chef [4] http://eavesdrop.openstack.org/meetings/openstack_chef/ Change-Id: I18f507da315951352e31a9d1be2aeb0e40c9d085
2015-04-17 13:33:21 -05:00
mission: >
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
Develop, maintain, and initiate tools and plans to ensure the upstream
stability and quality of OpenStack, and its release readiness at any point
during the release cycle.
url: https://wiki.openstack.org/wiki/QA
deliverables:
bashate:
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/bashate
Add coverage2sql to Quality Assurance Change-Id: I2b6ec416f1dd0320e0e5336917a786ef36f957ab Depends-On: I8b0aa6c70f79d8552cc3113d5714e53587b08866
2016-11-07 14:58:48 +09:00
coverage2sql:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add coverage2sql to Quality Assurance Change-Id: I2b6ec416f1dd0320e0e5336917a786ef36f957ab Depends-On: I8b0aa6c70f79d8552cc3113d5714e53587b08866
2016-11-07 14:58:48 +09:00
repos:
- openstack/coverage2sql
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
devstack:
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/devstack
Add devstack-plugin-ceph under QA Change-Id: Icf12023ae000dd974cb6893c681be2bdf2a7ad83
2016-03-03 16:04:34 -05:00
devstack-plugin-ceph:
repos:
- openstack/devstack-plugin-ceph
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
devstack-plugin-cookiecutter:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/devstack-plugin-cookiecutter
Add repo: devstack-plugin-open-cas Caching software open-cas is needed in volume local cache feature. Repo devstack-plugin-open-cas is to configure open-cas for devstack. open-cas: https://open-cas.github.io/ Nova Spec: https://review.opendev.org/#/c/689070/ Cinder Spec: https://review.opendev.org/#/c/684556/ Depends-On: https://review.opendev.org/#/c/711878/ Change-Id: I54b5a420519386f74b525946c6b54d228df86520 Signed-off-by: Liang Fang <liang.a.fang@intel.com>
2020-03-09 18:45:24 +08:00
devstack-plugin-open-cas:
release-management: none
repos:
- openstack/devstack-plugin-open-cas
Add devstack-plugin-prometheus repo to Quality Assurance repos Currently prometheus installation is done by sg-core devstack plugin. sg-core devstack plugin[1] was used by ceilometer project. Recently we have added prometheus datasource support in watcher project. We also need to install pushgateway and node exporter for testing. Since sg-core devstack plugin repo is meant for sg-core related stuff. So we will removing prometheus installation from sg-core devstack plugin and moving it to new devstack-plugin-prometheus repo. devstack-plugin-prometheus repo will contain all the bits for installation and configuration for prometheus, alert-manager, node-exporter and pushgateway. It will be used by ceilometer and watcher project and maintained by QA, watcher and ceilometer devs. Links: [1]. https://github.com/openstack-k8s-operators/sg-core/ Depends-On: https://review.opendev.org/c/openstack/project-config/+/939952 Change-Id: I9df2d7c9a009893ee45f237d4e7e96f720e6a807 Signed-off-by: Chandan Kumar (raukadah) <chkumar@redhat.com>
2025-01-23 16:59:33 +05:30
devstack-plugin-prometheus:
release-management: none
repos:
- openstack/devstack-plugin-prometheus
Add devstack-tools repo Change-Id: Ie839911cc03b44158bd11ebb7434549ec8a72863 Depends-On: Iac181a38dfa93a4822a8dacee6cb98dd116ffb5b
2017-01-18 10:33:33 -05:00
devstack-tools:
repos:
- openstack/devstack-tools
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
devstack-vagrant:
Clarify release management for QA deliverables devstack-vagrant does not need release management (the tool is more continuously released). devstack-plugin-ceph does not need release management either, as it does not do releases nor uses cycle branches. Change-Id: I2989e3c468ab8c9d9aab0f40f38c0dde755aa394
2018-12-05 10:23:38 +01:00
release-management: none
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/devstack-vagrant
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
eslint-config-openstack:
repos:
- openstack/eslint-config-openstack
grenade:
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/grenade
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
hacking:
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/hacking
Create new QA project karma-subunit-reporter This creates a new project for karma-subunit-reporter, a plugin for JavaScript tests using the Karma runner to report results in subunit format. Change-Id: I6e3b7e1ccf1fc67be0ef113eca44934606f5aac3 Depends-On: Ied7810e7ca0725ffe6ec834919c1cae8f11bb2d8
2016-06-09 14:57:54 -06:00
karma-subunit-reporter:
repos:
- openstack/karma-subunit-reporter
Add os-performance-tools to QA team These utilities will be used to ensure performance is measured in the gate. Please see I2019afa4ef4b6247b9dd2139f4df98196370f4fe for the repository addition to infra. Change-Id: I07aa364324f5b50d9c1b90053aef716a6226d282 Implements: bp counter-inspection
2015-12-05 09:30:11 -08:00
os-performance-tools:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add os-performance-tools to QA team These utilities will be used to ensure performance is measured in the gate. Please see I2019afa4ef4b6247b9dd2139f4df98196370f4fe for the repository addition to infra. Change-Id: I07aa364324f5b50d9c1b90053aef716a6226d282 Implements: bp counter-inspection
2015-12-05 09:30:11 -08:00
repos:
- openstack/os-performance-tools
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
os-testr:
repos:
- openstack/os-testr
qa-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
- openstack/qa-specs
Add new OpenStack QA project StackViz. StackViz is a performance and debugging visualization utility for DevStack and Tempest. Additional information can be found at the current repository location: https://github.com/timothyb89/stackviz Change-Id: Iafceb928f69358bc2473f0924e2e4a9f343e957d Depends-On: I0ce2f722f4d1ae3b864bebf7c56b5711a915476d
2015-08-26 16:40:32 -06:00
stackviz:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add new OpenStack QA project StackViz. StackViz is a performance and debugging visualization utility for DevStack and Tempest. Additional information can be found at the current repository location: https://github.com/timothyb89/stackviz Change-Id: Iafceb928f69358bc2473f0924e2e4a9f343e957d Depends-On: I0ce2f722f4d1ae3b864bebf7c56b5711a915476d
2015-08-26 16:40:32 -06:00
repos:
- openstack/stackviz
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
tempest:
repos:
- openstack/tempest
Add tempest-plugin-cookiecutter to QA This is a new project to create a cookiecutter template repo for use in creating tempest-plugin repos. Change-Id: I5c7c7fc2ba274b651954c27b0acce3d6ebd0a57d
2015-08-03 10:52:40 +02:00
tempest-plugin-cookiecutter:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add tempest-plugin-cookiecutter to QA This is a new project to create a cookiecutter template repo for use in creating tempest-plugin repos. Change-Id: I5c7c7fc2ba274b651954c27b0acce3d6ebd0a57d
2015-08-03 10:52:40 +02:00
repos:
Fix repo path for tempest-plugin-cookiecutter The tempest-plugin-cookiecutter repo was created under the openstack namespace instead of openstack-dev. This commit just updates the path in projects.yaml to reflect reality. Change-Id: I8b3ee307d1565b615e1f76f997edd60ff41c28d7 Depends-On: Ieb97af5837888ba4b0aab4d7dda37e7796f9f0f0
2015-09-25 15:42:12 -04:00
- openstack/tempest-plugin-cookiecutter
Add tempest-stress in Quality Assurance tempest-stress is to perform stress testing of cloud using tempest. This framework used to be in tempest earlier but due to tempest scope it had been moved out of tempest tree. During queens PTG (even earlier) we discussed to make it in separate repo. Depends-On: I063303642f5c99e4ca95d0e02c2360a003688ad6 Change-Id: Ib6fb2eac8568f6e86aae24782bfa6d9cca4fe54c
2018-01-12 01:38:26 +00:00
tempest-stress:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add tempest-stress in Quality Assurance tempest-stress is to perform stress testing of cloud using tempest. This framework used to be in tempest earlier but due to tempest scope it had been moved out of tempest tree. During queens PTG (even earlier) we discussed to make it in separate repo. Depends-On: I063303642f5c99e4ca95d0e02c2360a003688ad6 Change-Id: Ib6fb2eac8568f6e86aae24782bfa6d9cca4fe54c
2018-01-12 01:38:26 +00:00
repos:
- openstack/tempest-stress
Add devstack-plugin-container to QA team The repo devstack-plugin-container is a devstack plugin for installing container engines such as Docker. This plugin is currently used by a few official services such as Zun, Kuryr-libnetwork, Kuryr-kubernetes, and Fuxi. This patch proposes to include devstack-plugin-container as a deliverable of QA team. Change-Id: I474bf587c0a9c9c560fbe4fde108940df379e863
2018-02-05 16:01:57 +00:00
devstack-plugin-container:
repos:
- openstack/devstack-plugin-container
Add devstack-plugin-nfs project under QA devstack-plugin-nfs is devstack plugin to configure the NFS backend. We are going to bring this plugin under QA project. Detail discussion: http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013048.html Depends-On: https://review.opendev.org/#/c/711834/ Change-Id: Ib37815eb7fc917ce7258010b82301d0cfef803e1
2020-03-07 20:56:01 -06:00
devstack-plugin-nfs:
release-management: none
repos:
- openstack/devstack-plugin-nfs
Add whitebox-tempest-plugin under QA Tempest defines its scope as only what is accessible through the various REST APIs. Some cloud features cannot be properly tested when using only the REST API. The whitebox-tempest-plugin is a Tempest plugin whose scope explicitly requires peeking behind the curtain. In other words, if a feature or behavior can be fully tested using only a REST API, such a test does not belong in whitebox-tempest-plugin. On the other hand, if fully testing a feature or behavior requires accessing the control plane like a human operator or admin would, such a test belongs in whitebox-tempest plugin. This patch adds whitebox under Quality Assurance. Depends-on: https://review.opendev.org/#/c/714478/ Change-Id: I2b99fc02d15dc62d7c166beaa555ea9577a2013b
2020-03-23 11:44:53 -04:00
whitebox-tempest-plugin:
repos:
- openstack/whitebox-tempest-plugin
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
rally:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Add PTL results from the 2024.2/Dalmatian election Depends-On: If6c157efebc58d1fbe32a61a64f209b4102ac5c8 Change-Id: Ic74bfc853d2d9d045d4c589e1fd6c50afa608423
2024-03-22 09:00:21 +09:00
name: Andrey Kurilin
Appoint Andriy Kurilin as Rally PTL Change-Id: Ibff2a527917d0afe2922cc95bdd41b68dba0f82e
2023-03-21 12:24:44 +01:00
irc: andreykurilin
email: andr.kurilin@gmail.com
Appoint Andrey Kurilin as Rally PTL Andrey confirmed to serve as Rally PTL: https://review.opendev.org/#/c/716525/ Change-Id: I557d3d1f9da3d96508530b3ba7371689bcc77dea
2020-04-03 11:59:17 -05:00
appointed:
- victoria
Appoint Andriy Kurilin as Rally PTL Change-Id: I3cdbfdf8f351431d9b5a25e5651190bf36fb48bd
2023-03-21 12:24:44 +01:00
- '2023.2'
Appoint Andriy Kurilin as Rally PTL Change-Id: Ibff2a527917d0afe2922cc95bdd41b68dba0f82e
2023-03-21 12:24:44 +01:00
- '2024.1'
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-rally
service: Benchmark service
mission: >
To provide a framework for performance analysis and benchmarking of
individual OpenStack components as well as full production OpenStack
cloud deployments.
url: https://wiki.openstack.org/wiki/Rally
deliverables:
rally:
repos:
- openstack/rally
Align Rally deliverables with real releases The way Rally deliverables are described in governance does not match the reality of how they are released. Currently in openstack/releases: - openstack/rally is released[1] separately from openstack/rally-openstack[2] - openstack/performance-docs is not released at all This change corrects governance documentation so that it maps to the reality. [1] https://opendev.org/openstack/releases/src/branch/master/deliverables/_independent/rally.yaml [2] https://opendev.org/openstack/releases/src/branch/master/deliverables/_independent/rally-openstack.yaml Change-Id: Ida4a8250067523833a85773bf1da8931f2fa3a5a
2019-12-18 15:17:57 +01:00
rally-openstack:
repos:
[rally] Add a separate repo for OpenStack plugins Depends-On: I4269ae2cae08ef7784ca1d5c107cace101a1209e Change-Id: Ib6ac80994cbc72af5b1a85a17e22431cc0821311
2018-02-19 15:24:21 +02:00
- openstack/rally-openstack
Align Rally deliverables with real releases The way Rally deliverables are described in governance does not match the reality of how they are released. Currently in openstack/releases: - openstack/rally is released[1] separately from openstack/rally-openstack[2] - openstack/performance-docs is not released at all This change corrects governance documentation so that it maps to the reality. [1] https://opendev.org/openstack/releases/src/branch/master/deliverables/_independent/rally.yaml [2] https://opendev.org/openstack/releases/src/branch/master/deliverables/_independent/rally-openstack.yaml Change-Id: Ida4a8250067523833a85773bf1da8931f2fa3a5a
2019-12-18 15:17:57 +01:00
performance-docs:
release-management: none
repos:
Add performance-docs under Rally project Depends-On: I1dc27f77d72babdfef2d63abef52cef50454c01e Change-Id: I8978af21f49e18ccd1f9b8de848f507eb7d4f962
2015-12-03 13:54:50 +03:00
- openstack/performance-docs
Redefine Release Management team mission With the spin-off of the Stable branch maintenance subteam into its own independent team, it makes sense to revisit the mission of the Release Management team. The old "Release Cycle Management" team used to regroup the Release team, the Stable branch team and the Vulnerability Management team. Now it's only the Release team left, so we should also rename it to the name that everyone is calling us anyway ("Release Management"). Also update the IRC channel and the wiki landing page. Change-Id: I71b77d350dea2d2e697e6c59792d38a0274bda28
2015-12-09 17:52:56 +01:00
Release Management:
Add Release Managmenet DPL and liaisons names Change-Id: Ia63fe1b1c8b384a2cf04db8dfb3193f17f2e837d
2024-08-09 14:08:25 +02:00
leadership_type: distributed
Redefine Release Management team mission With the spin-off of the Stable branch maintenance subteam into its own independent team, it makes sense to revisit the mission of the Release Management team. The old "Release Cycle Management" team used to regroup the Release team, the Stable branch team and the Vulnerability Management team. Now it's only the Release team left, so we should also rename it to the name that everyone is calling us anyway ("Release Management"). Also update the IRC channel and the wiki landing page. Change-Id: I71b77d350dea2d2e697e6c59792d38a0274bda28
2015-12-09 17:52:56 +01:00
irc-channel: openstack-release
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
mission: >
Redefine Release Management team mission With the spin-off of the Stable branch maintenance subteam into its own independent team, it makes sense to revisit the mission of the Release Management team. The old "Release Cycle Management" team used to regroup the Release team, the Stable branch team and the Vulnerability Management team. Now it's only the Release team left, so we should also rename it to the name that everyone is calling us anyway ("Release Management"). Also update the IRC channel and the wiki landing page. Change-Id: I71b77d350dea2d2e697e6c59792d38a0274bda28
2015-12-09 17:52:56 +01:00
Coordinating the release of OpenStack deliverables, by defining the
overall development cycle, release models, publication processes,
versioning rules and tools, then enabling project teams to produce
their own releases.
url: https://wiki.openstack.org/wiki/Release_Management
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
deliverables:
add release-test repository under the release team Change-Id: Ib6b4d77d249f0e1aa0b0c7a6b69d3b60a1c8a301 Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2016-02-10 16:02:45 -05:00
release-test:
repos:
Fix repo for release-test release-test is in openstack/release-test, not openstack-infra/release-test Change-Id: I125619ae39ac710dfddc246fca5639752eb6046c
2016-03-21 15:35:28 -07:00
- openstack/release-test
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
releases:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
- openstack/releases
Add reno project to release management team Reno is a new tool for managing release notes being developed by the release management team. Depends-On: Ie469f451bcb9611603a688f692e053f13c11bf3a (infra import) Change-Id: I3ac2cdec32801324065412e0df98462e7920aeb9
2015-09-03 13:04:47 +00:00
reno:
repos:
- openstack/reno
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
specs-cookiecutter:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
Update repository namespaces for OpenDev migration As of the OpenDev migration yesterday, a number of repositories moved out of the "openstack" Git namespace to others like "opendev", "osf" or "x". This change simply reflects the name changes, but does not remove any official deliverables from official OpenStack governance (there will be subsequent changes for that). Change-Id: I86925a8f1f9eb57c94f1a4734c9395532ca24778
2019-04-20 20:48:07 +00:00
- openstack/specs-cookiecutter
Add Release Managmenet DPL and liaisons names Change-Id: Ia63fe1b1c8b384a2cf04db8dfb3193f17f2e837d
2024-08-09 14:08:25 +02:00
liaisons:
release:
- name: Thierry Carrez
irc: ttx
email: thierry@openstack.org
- name: Elod Illes
irc: elodilles
email: elod.illes@est.tech
- name: Jens Harbott
irc: frickler
email: frickler@offenerstapel.de
tact-sig:
- name: Jeremy Stanley
irc: fungi
email: fungi@yuggoth.org
security:
- name: Thierry Carrez
irc: ttx
email: thierry@openstack.org
tc-liaison:
- name: Ghanshyam Mann
irc: gmann
email: gmann@ghanshyammann.com
Add the newly create Requiremnts team to projects.yaml Change-Id: I8f275bf6b72e303f791e82f9213e0f5bd039943a
2016-08-22 13:23:21 +10:00
requirements:
Switch requirements to distributed leadership The purpose of this change is to make it explicit that "team leadership" for the requirements team is equally shared between the 2 named individuals. While this is more of a co-PTL model we're leveraging the distibuted team leadership model adopted by the TC resolution[1] [1] https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html Change-Id: Ib6c4c4f4a45f42e4daaa910cd728f946e72ff75c
2022-08-25 18:22:15 -07:00
leadership_type: distributed
Add the newly create Requiremnts team to projects.yaml Change-Id: I8f275bf6b72e303f791e82f9213e0f5bd039943a
2016-08-22 13:23:21 +10:00
irc-channel: openstack-requirements
Provide short description for cryptic team names Looking at https://governance.openstack.org/tc/reference/projects/index.html certain team names are not self-explaining. The "service" field is generally used to clarify in a short description what the team provides. This patch adds short descriptions for the teams where the name is not self-explaining (including "requirements" which can be confusing at first glance). Change-Id: I24fce9a46cfed8ebf2dfcb4fd7cf5ac87bf2500b
2019-11-20 12:14:56 +01:00
service: Common dependency management
Add the newly create Requiremnts team to projects.yaml Change-Id: I8f275bf6b72e303f791e82f9213e0f5bd039943a
2016-08-22 13:23:21 +10:00
mission: >
Add 'library convergence' to Requirements mission The current Requirements team mission is failing to mention an important aspect of the team job, which is to try to get the dependencies to converge toward the best-maintained library where there are multiple variants used to get the same functionality. Change-Id: I987bb346c666e41825dccc9b17eed42920d59361
2016-08-31 11:07:20 +02:00
Coordinating and converging the libraries used by OpenStack projects,
while ensuring that all libraries are compatible both technically and
from a licensing standpoint.
Add the newly create Requiremnts team to projects.yaml Change-Id: I8f275bf6b72e303f791e82f9213e0f5bd039943a
2016-08-22 13:23:21 +10:00
url: https://wiki.openstack.org/wiki/Requirements
deliverables:
requirements:
repos:
- openstack/requirements
Switch requirements to distributed leadership The purpose of this change is to make it explicit that "team leadership" for the requirements team is equally shared between the 2 named individuals. While this is more of a co-PTL model we're leveraging the distibuted team leadership model adopted by the TC resolution[1] [1] https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html Change-Id: Ib6c4c4f4a45f42e4daaa910cd728f946e72ff75c
2022-08-25 18:22:15 -07:00
liaisons:
release:
- name: Matthew Thode
irc: prometheanfire
email: mthode@mthode.org
- name: Tony Breeds
irc: tonyb
email: tony@bakeyournoodle.com
tact-sig:
- name: Matthew Thode
irc: prometheanfire
email: mthode@mthode.org
- name: Tony Breeds
irc: tonyb
email: tony@bakeyournoodle.com
security:
- name: Matthew Thode
irc: prometheanfire
email: mthode@mthode.org
- name: Tony Breeds
irc: tonyb
email: tony@bakeyournoodle.com
Add TC liaison in DPL model implementation As per new policy, TC liaison is mandatory for all DPL model projects, this change adds the same in its implementation. Also, assigning the same for existing DPL projects. All new request to the DPL model should have TC liaions as required. Change-Id: Ib6067a45002bad0d2ee658de96ebe79aa86e223a
2024-06-03 11:07:41 -07:00
tc-liaison:
- name: Ghanshyam Mann
irc: gmann
email: gmann@ghanshyammann.com
- name: Dmitriy Rabotyagov
irc: noonedeadpunk
email: noonedeadpunk@gmail.com
Add Skyline as an official project Skyline is an OpenStack dashboard optimized by UI and UE. It has a modern technology stack and ecology, is easier for developers to maintain and operate by users, and has higher concurrency performance. Here are two videos to preview Skyline: - Skyline technical overview[1]. - Skyline dashboard operating demo[2]. Skyline has the following technical advantages: 1. Separation of concerns, front-end focus on functional design and user experience, back-end focus on data logic. 2. Embrace modern browser technology and ecology: React, Ant Design, and Mobx. 3. Most functions directly call OpenStack-API, the call chain is simple, the logic is clearer, and the API responds quickly. 4. Use React component to process rendering, the page display process is fast and smooth, bringing users a better UI and UE experience. At present, Skyline has completed the function development of OpenStack core component, as well as most of the functions of VPNaaS, Octavia and other components. corresponding automated test jobs[3][4] are also integrated on Zuul, and there is good code coverage. Devstack deployment integration has also been completed, and integration of kolla and kolla-ansible will complete pending patch[5][6] after Skyline becomes an official project. Skyline’s next roadmap will be to cover all existing functions of Horizon and complete the page development of other OpenStack components. [1] https://www.youtube.com/watch?v=Ro8tROYKDlE [2] https://www.youtube.com/watch?v=pFAJLwzxv0A [3] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-apiserver [4] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-console [5] https://review.opendev.org/c/openstack/kolla/+/810796 [6] https://review.opendev.org/c/openstack/kolla-ansible/+/810566 Change-Id: Ib91a241c64351c5e69023b2523408c75b80ff74d
2021-10-14 23:42:20 +08:00
skyline:
ptl:
Appoint Wenxiang Wu as PTL of Skyline Change-Id: Ie872862ff6c8e0b19171a1a7ef19bc5f5effc37b
2024-04-05 10:35:11 +08:00
name: Wenxiang Wu
irc: wu_wenxiang
email: wu.wenxiang@99cloud.net
Appoint Wenxiang as Skyline PTL Wenxiang raised the late candidacy for Skyline Zed cycle PTL - https://etherpad.opendev.org/p/zed-leaderless Change-Id: Ic41c2832cbb2030eb70f0422d830f20a798c35c8
2022-02-27 18:49:14 -06:00
appointed:
- zed
Add TC/PTL results from 2025.1 election Also clear out existing TC roles and prepare for nominations. Depends-On: Id5847c7c37d556b11932dae542f4aaeb699cf7ec Change-Id: I7760c815d032c7aaff9956588b6ce5c1fb7b4750
2024-09-19 23:17:25 +09:00
- '2024.1'
- '2024.2'
Add Skyline as an official project Skyline is an OpenStack dashboard optimized by UI and UE. It has a modern technology stack and ecology, is easier for developers to maintain and operate by users, and has higher concurrency performance. Here are two videos to preview Skyline: - Skyline technical overview[1]. - Skyline dashboard operating demo[2]. Skyline has the following technical advantages: 1. Separation of concerns, front-end focus on functional design and user experience, back-end focus on data logic. 2. Embrace modern browser technology and ecology: React, Ant Design, and Mobx. 3. Most functions directly call OpenStack-API, the call chain is simple, the logic is clearer, and the API responds quickly. 4. Use React component to process rendering, the page display process is fast and smooth, bringing users a better UI and UE experience. At present, Skyline has completed the function development of OpenStack core component, as well as most of the functions of VPNaaS, Octavia and other components. corresponding automated test jobs[3][4] are also integrated on Zuul, and there is good code coverage. Devstack deployment integration has also been completed, and integration of kolla and kolla-ansible will complete pending patch[5][6] after Skyline becomes an official project. Skyline’s next roadmap will be to cover all existing functions of Horizon and complete the page development of other OpenStack components. [1] https://www.youtube.com/watch?v=Ro8tROYKDlE [2] https://www.youtube.com/watch?v=pFAJLwzxv0A [3] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-apiserver [4] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-console [5] https://review.opendev.org/c/openstack/kolla/+/810796 [6] https://review.opendev.org/c/openstack/kolla-ansible/+/810566 Change-Id: Ib91a241c64351c5e69023b2523408c75b80ff74d
2021-10-14 23:42:20 +08:00
irc-channel: openstack-skyline
service: Dashboard
mission: >
Skyline is an OpenStack dashboard optimized by UI and UX.
It has a modern technology stack and ecosystem, is easier for
developers to maintain and operate by users, and has higher
concurrency performance.
url: https://wiki.openstack.org/wiki/Skyline
deliverables:
skyline-apiserver:
repos:
Rename skyline project repo skyline repo are renamed now - https://review.opendev.org/c/openstack/project-config/+/822222/3 Update those in projects.yaml file. Change-Id: I185ddb3289c8bd1077eb1560c6d39bc8730c9a53
2022-01-24 21:32:52 -06:00
- openstack/skyline-apiserver
Add Skyline as an official project Skyline is an OpenStack dashboard optimized by UI and UE. It has a modern technology stack and ecology, is easier for developers to maintain and operate by users, and has higher concurrency performance. Here are two videos to preview Skyline: - Skyline technical overview[1]. - Skyline dashboard operating demo[2]. Skyline has the following technical advantages: 1. Separation of concerns, front-end focus on functional design and user experience, back-end focus on data logic. 2. Embrace modern browser technology and ecology: React, Ant Design, and Mobx. 3. Most functions directly call OpenStack-API, the call chain is simple, the logic is clearer, and the API responds quickly. 4. Use React component to process rendering, the page display process is fast and smooth, bringing users a better UI and UE experience. At present, Skyline has completed the function development of OpenStack core component, as well as most of the functions of VPNaaS, Octavia and other components. corresponding automated test jobs[3][4] are also integrated on Zuul, and there is good code coverage. Devstack deployment integration has also been completed, and integration of kolla and kolla-ansible will complete pending patch[5][6] after Skyline becomes an official project. Skyline’s next roadmap will be to cover all existing functions of Horizon and complete the page development of other OpenStack components. [1] https://www.youtube.com/watch?v=Ro8tROYKDlE [2] https://www.youtube.com/watch?v=pFAJLwzxv0A [3] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-apiserver [4] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-console [5] https://review.opendev.org/c/openstack/kolla/+/810796 [6] https://review.opendev.org/c/openstack/kolla-ansible/+/810566 Change-Id: Ib91a241c64351c5e69023b2523408c75b80ff74d
2021-10-14 23:42:20 +08:00
skyline-console:
repos:
Rename skyline project repo skyline repo are renamed now - https://review.opendev.org/c/openstack/project-config/+/822222/3 Update those in projects.yaml file. Change-Id: I185ddb3289c8bd1077eb1560c6d39bc8730c9a53
2022-01-24 21:32:52 -06:00
- openstack/skyline-console
Storlets to become official - Proposed governance change [1] Has a summary as well detailed desciption of all that the team has done following the comments given in August. The below is the original commit message describing the project (with some necessary updates). The project offers the ability to run user defined functions within Openstack Swift nodes. For more info please refer to the docs (built from source) here: http://storlets.readthedocs.io/en/latest/ The project combines a Swift middleware together with Docker to execute the user defined Java/Python programs inside a container, which in turn runs on Swift nodes. In addition the repository has several sample storlets used for functional tests (as well as examples). Open Source: License: Apache 2.0 license. Libraries: On top of what swift requires, storlets make use of docker, OpenJDK JRE-8 plus standard Java libs. Non standard java libs that we use are: - simple-json (Apache 2.0 lic) - logback-classic, logback-core (EPL v1.0 and the LGPL 2.1) - slf4j-api (MIT lic) Open Community: We are currently 5 active contributors, 1 from IBM, 3 from NTT and this commit author (independent developer) we hold weekly meetings in #openstack-meetings, with agenda posted in [2] Open Development: The project is integrated with the Openstack CI, and was created according to Openstack "Project Creator's Guide". We work closely with the Swift team, and one of our cores is also a core in Swift. Yours truly was elected to be the first PTL by the team. Our current and near term goals are documented in our wiki. Open Design: So far our design meetings were alongside those of Swift. Otherwise, most of the work is done through Gerrit and our IRC channel. In addition we have the [storlets] prefix within the openstack-dev ML. Interoperability: Our user facing APIs are actually an extension of Swift’s API (http://storlets.readthedocs.io/en/latest/api/overview_api.html) To the best of my understanding, storlets being a Swift extension do not pose any authentication restriction or integration issues. Testing interface: We have regular unit/functional/python style tests running with every review request. We generate a source tar ball of the python code as part of the deployment scripts, and generate documentation. The project has been presented in the Paris, Tokyo and Barcelona summits. Reasoning about languages used: We use Python, Java and C. Java and Python are used as the programming language for storlets. That is, the user defined code running inside the Docker container on the storage node can be Java or Python. Java is widly used in the Big-Data analytics world as well as in the media world (as demonstrated in our Paris and Barcelona talks). Similar to OpenStack SDK we would like to support a set of bindings and we are currently working on a Python 'binding'. We use C for passing fds between Swift and the Dockered storlet, and only for that purpose. Unfortunately, neither python 2.7 nor Java have support of passing fds between processes (over UDS). This feature is crucial for us as we want to keep the Docker container isolated as much as possible. Apparently, python 3.x does have such support, but seems that on the Java side we will still need the C code. Python is used for the Swift middleware. The middleware intercepts Swift requests that wish to invoke a storlet on some data and routes the data to/from the storlet. JRE Dependency: We are now using OpenJDK. Is this being implemented anywhere else: There have been https://zerovm.readthedocs.io/zerocloud/overview.html However, after being aquired by Rackspace they have 'disappeared'. We have tried to design storlets so that different runtime sandboxes are pluggable with Docker containers being our first implementation of a runtime sandbox. Having said that, as long as we have only one implementation, this design has not been put to the test. There is also what has been a proprietary solution and now opensourced https://www.joyent.com/manta Joyent was aquired by Samsung this year. [1] https://etherpad.openstack.org/p/storlets-big-tent [2] https://wiki.openstack.org/wiki/Meetings/Storlets Change-Id: Icf9dd346c731dd7378ba9015bd3cbc31e4246a6a
2016-08-10 10:22:34 +03:00
storlets:
ptl:
Update projects.yaml for Victoria PTLs This reflects the election results of Victoria PTLs confirmed by election officials. Depends-On: I6b9bb279952200df8e9aafb49756ebce6ecd1c8d Change-Id: I5ba004d6af2f9edb1707a6811fe25a2accc18467 Signed-off-by: Andy McCrae <andy.mccrae@gmail.com> Signed-off-by: Ian Y. Choi <ianyrchoi@gmail.com> Signed-off-by: Kendall Nelson <knelson@openstack.org> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
2020-04-03 15:57:32 +09:00
name: Takashi Kajinami
irc: tkajinam
Update email address of Takashi Kajinami Change-Id: I488bcaa723cc950a60d088e22afc62eb2bee75c7
2023-10-13 12:16:20 +09:00
email: kajinamit@oss.nttdata.com
Storlets to become official - Proposed governance change [1] Has a summary as well detailed desciption of all that the team has done following the comments given in August. The below is the original commit message describing the project (with some necessary updates). The project offers the ability to run user defined functions within Openstack Swift nodes. For more info please refer to the docs (built from source) here: http://storlets.readthedocs.io/en/latest/ The project combines a Swift middleware together with Docker to execute the user defined Java/Python programs inside a container, which in turn runs on Swift nodes. In addition the repository has several sample storlets used for functional tests (as well as examples). Open Source: License: Apache 2.0 license. Libraries: On top of what swift requires, storlets make use of docker, OpenJDK JRE-8 plus standard Java libs. Non standard java libs that we use are: - simple-json (Apache 2.0 lic) - logback-classic, logback-core (EPL v1.0 and the LGPL 2.1) - slf4j-api (MIT lic) Open Community: We are currently 5 active contributors, 1 from IBM, 3 from NTT and this commit author (independent developer) we hold weekly meetings in #openstack-meetings, with agenda posted in [2] Open Development: The project is integrated with the Openstack CI, and was created according to Openstack "Project Creator's Guide". We work closely with the Swift team, and one of our cores is also a core in Swift. Yours truly was elected to be the first PTL by the team. Our current and near term goals are documented in our wiki. Open Design: So far our design meetings were alongside those of Swift. Otherwise, most of the work is done through Gerrit and our IRC channel. In addition we have the [storlets] prefix within the openstack-dev ML. Interoperability: Our user facing APIs are actually an extension of Swift’s API (http://storlets.readthedocs.io/en/latest/api/overview_api.html) To the best of my understanding, storlets being a Swift extension do not pose any authentication restriction or integration issues. Testing interface: We have regular unit/functional/python style tests running with every review request. We generate a source tar ball of the python code as part of the deployment scripts, and generate documentation. The project has been presented in the Paris, Tokyo and Barcelona summits. Reasoning about languages used: We use Python, Java and C. Java and Python are used as the programming language for storlets. That is, the user defined code running inside the Docker container on the storage node can be Java or Python. Java is widly used in the Big-Data analytics world as well as in the media world (as demonstrated in our Paris and Barcelona talks). Similar to OpenStack SDK we would like to support a set of bindings and we are currently working on a Python 'binding'. We use C for passing fds between Swift and the Dockered storlet, and only for that purpose. Unfortunately, neither python 2.7 nor Java have support of passing fds between processes (over UDS). This feature is crucial for us as we want to keep the Docker container isolated as much as possible. Apparently, python 3.x does have such support, but seems that on the Java side we will still need the C code. Python is used for the Swift middleware. The middleware intercepts Swift requests that wish to invoke a storlet on some data and routes the data to/from the storlet. JRE Dependency: We are now using OpenJDK. Is this being implemented anywhere else: There have been https://zerovm.readthedocs.io/zerocloud/overview.html However, after being aquired by Rackspace they have 'disappeared'. We have tried to design storlets so that different runtime sandboxes are pluggable with Docker containers being our first implementation of a runtime sandbox. Having said that, as long as we have only one implementation, this design has not been put to the test. There is also what has been a proprietary solution and now opensourced https://www.joyent.com/manta Joyent was aquired by Samsung this year. [1] https://etherpad.openstack.org/p/storlets-big-tent [2] https://wiki.openstack.org/wiki/Meetings/Storlets Change-Id: Icf9dd346c731dd7378ba9015bd3cbc31e4246a6a
2016-08-10 10:22:34 +03:00
irc-channel: openstack-storlets
service: Compute inside Object Storage service
mission: >
To enable a user friendly, cost effective scalable and secure way for
executing storage centric user defined functions near the data within
OpenStack Swift
url: https://wiki.openstack.org/wiki/Storlets
deliverables:
storlets:
repos:
- openstack/storlets
Propose Sunbeam as a new OpenStack project Sunbeam builds on the experience of deploying OpenStack using the OpenStack Charms project providing a new approach to the deployment and operation of an OpenStack cloud which is more contained and lighter-weight in terms of resource consumption for the OpenStack components. Juju and Charms remain a core component of this project; Kubernetes is targetted as a substrate for the majority of the control plane with data plane components such as the hypervisor still residing directly on the underlying servers - a best of both worlds approach. OCI containers are used for delivery of the K8S workloads and Snap packages are used for components that are installed directly on servers. MicroK8S and Ubuntu are the initial deployment targets for Sunbeam but due to the containerised approach for workload deployment it would be possible to target other Kubernetes distributions and operating systems in the future if the community wished to move in that direction. Currently the Juju charms that support Sunbeam are part of the OpenStack Charms project but there is no dependency between the two sets of charms; by placing the Sunbeam charms and other future project components including an expanded set of charms, supporting snaps and documentation under a separate project we make it clear that this is a distinct, separate effort from the objectives of the OpenStack Charms project and avoid confusion for the community around both projects. The OpenStack Charms project will continue to deliver support for new OpenStack releases while Sunbeam incubates into a production grade solution for the deployment and operation of OpenStack. An upgrade path between OpenStack Charm deployed clouds and Sunbeam is also on the longer term roadmap. Change-Id: Ia8ae01a073d5fb0ce5f8e4e73a18d0913a49e556
2023-04-20 09:51:47 +01:00
sunbeam:
ptl:
Add TC/PTL results from 2025.1 election Also clear out existing TC roles and prepare for nominations. Depends-On: Id5847c7c37d556b11932dae542f4aaeb699cf7ec Change-Id: I7760c815d032c7aaff9956588b6ce5c1fb7b4750
2024-09-19 23:17:25 +09:00
name: Guillaume Boutry
irc: gboutry
email: guillaume.boutry@canonical.com
Appoint James Page as PTL of Sunbeam Change-Id: Ib74015fe5712e45e0c520f9f46c986005458c029
2023-09-26 20:27:42 +01:00
appointed:
Add TC/PTL results from 2025.1 election Also clear out existing TC roles and prepare for nominations. Depends-On: Id5847c7c37d556b11932dae542f4aaeb699cf7ec Change-Id: I7760c815d032c7aaff9956588b6ce5c1fb7b4750
2024-09-19 23:17:25 +09:00
- '2024.1'
Propose Sunbeam as a new OpenStack project Sunbeam builds on the experience of deploying OpenStack using the OpenStack Charms project providing a new approach to the deployment and operation of an OpenStack cloud which is more contained and lighter-weight in terms of resource consumption for the OpenStack components. Juju and Charms remain a core component of this project; Kubernetes is targetted as a substrate for the majority of the control plane with data plane components such as the hypervisor still residing directly on the underlying servers - a best of both worlds approach. OCI containers are used for delivery of the K8S workloads and Snap packages are used for components that are installed directly on servers. MicroK8S and Ubuntu are the initial deployment targets for Sunbeam but due to the containerised approach for workload deployment it would be possible to target other Kubernetes distributions and operating systems in the future if the community wished to move in that direction. Currently the Juju charms that support Sunbeam are part of the OpenStack Charms project but there is no dependency between the two sets of charms; by placing the Sunbeam charms and other future project components including an expanded set of charms, supporting snaps and documentation under a separate project we make it clear that this is a distinct, separate effort from the objectives of the OpenStack Charms project and avoid confusion for the community around both projects. The OpenStack Charms project will continue to deliver support for new OpenStack releases while Sunbeam incubates into a production grade solution for the deployment and operation of OpenStack. An upgrade path between OpenStack Charm deployed clouds and Sunbeam is also on the longer term roadmap. Change-Id: Ia8ae01a073d5fb0ce5f8e4e73a18d0913a49e556
2023-04-20 09:51:47 +01:00
irc-channel: openstack-sunbeam
service: Deployment and operational tooling for OpenStack
mission: >
To enable deployment and operation of OpenStack at any scale - from a
single node to small scale edge deployments and large scale clouds
containing many 1000's of hypervisors - leveraging a hybrid deployment
model using Juju to manage both Kubernetes components and machine based
components through the use of charms.
Retire all single charm repositories The sunbeam-charms mono-repo now replaces all individual charm repositories - remove from the Sunbeam project. Update validate-legacy.py to deal with repositories which don't use a default branch of 'master'. Change-Id: Id5e72114e73a765285c99a21e23c4d6eaa3c15ea
2023-12-12 11:21:04 +00:00
url: https://opendev.org/openstack/sunbeam-charms/src/branch/main/ops-sunbeam/README.rst
Propose Sunbeam as a new OpenStack project Sunbeam builds on the experience of deploying OpenStack using the OpenStack Charms project providing a new approach to the deployment and operation of an OpenStack cloud which is more contained and lighter-weight in terms of resource consumption for the OpenStack components. Juju and Charms remain a core component of this project; Kubernetes is targetted as a substrate for the majority of the control plane with data plane components such as the hypervisor still residing directly on the underlying servers - a best of both worlds approach. OCI containers are used for delivery of the K8S workloads and Snap packages are used for components that are installed directly on servers. MicroK8S and Ubuntu are the initial deployment targets for Sunbeam but due to the containerised approach for workload deployment it would be possible to target other Kubernetes distributions and operating systems in the future if the community wished to move in that direction. Currently the Juju charms that support Sunbeam are part of the OpenStack Charms project but there is no dependency between the two sets of charms; by placing the Sunbeam charms and other future project components including an expanded set of charms, supporting snaps and documentation under a separate project we make it clear that this is a distinct, separate effort from the objectives of the OpenStack Charms project and avoid confusion for the community around both projects. The OpenStack Charms project will continue to deliver support for new OpenStack releases while Sunbeam incubates into a production grade solution for the deployment and operation of OpenStack. An upgrade path between OpenStack Charm deployed clouds and Sunbeam is also on the longer term roadmap. Change-Id: Ia8ae01a073d5fb0ce5f8e4e73a18d0913a49e556
2023-04-20 09:51:47 +01:00
deliverables:
sunbeam-charms:
release-management: external
repos:
Create mono repo for sunbeam charms Currently each sunbeam charm is in its own repo. This approach is going to be replaced by having a single monolithic repo that will contain all the sunbeam charms. Depends-On: I79e5efca77a49b1cd2b0706d37a39cbbab4a19dd Change-Id: Ie72e31f8375371b87c97d9264aa4b92344efa0d9
2023-11-06 11:26:52 +00:00
- openstack/sunbeam-charms
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
swift:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Appoint Tim Burke as PTL for Swift Change-Id: I66bb16432b09fd3d111c288a8a11be8d4710e20e
2024-09-10 20:50:22 -07:00
name: Tim Burke
irc: timburke
email: tburke@nvidia.com
Appoint Tim Burke as Swift PTL Tim confirmed to serve as Swift PTL: https://review.opendev.org/#/c/716379/ Change-Id: Ifd004ef0acf37f92d001a24ac2a0949395379e78
2020-04-03 12:05:15 -05:00
appointed:
- victoria
Consider release version as string in projects data We need to use the release version as string, so updating the PTL 'appointment' field and the data in projects.yaml Change-Id: Ib097517f514e68246fb6e27b83e98a1f3f6b8eed
2023-03-10 18:14:20 -06:00
- '2023.1'
- '2023.2'
Appoint Tim Burke as PTL for Swift Change-Id: I66bb16432b09fd3d111c288a8a11be8d4710e20e
2024-09-10 20:50:22 -07:00
- '2025.1'
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-swift
Applies naming guidelines to service object - Uses case and naming guideance to revise reference. - Consider these as returning in a service catalog as "type" when a user asks for a service catalog. Change-Id: I230235638c73c072bf86d76b9c991cb209029f64
2015-07-14 12:15:21 -05:00
service: Object Storage service
Add Swift mission into governance Swift is one of the few projects to not have a mission. Without this patch, it will be impossible to enforce a schema validation on the presence of a mission. This is a problem as we could use the mission field for some different purposes, like o.o website. This fixes it by providing some content extracted from the wiki of Swift. Change-Id: I8f64b16248b3ea4dbf7a376a90a20a735b745ab3
2019-08-08 13:51:39 +02:00
mission: >
Provide software for storing and retrieving lots of data
with a simple API. Built for scale and optimized for durability,
availability, and concurrency across the entire data set.
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
url: https://wiki.openstack.org/wiki/Swift
deliverables:
Add liberasurecode and pyeclib as Swift team deliverables This more-accurately reflects the realities that: - the primary developers for these projects are Swift developers and - the primary consumer of these projects is Swift Change-Id: I333393e0304844e30983f89c82eabcad11487be2
2019-05-04 12:40:30 -07:00
liberasurecode:
release-management: none
repos:
Some repos were renamed, update reference files A couple of repos were renamed or moved from one org to another, follow renames in reference docs. Depends-On: https://review.opendev.org/657155 Depends-On: https://review.opendev.org/662432 Depends-On: https://review.opendev.org/657277 Depends-On: https://review.opendev.org/661682 Depends-On: https://review.opendev.org/659489 Depends-On: https://review.opendev.org/644584 Change-Id: I1a5102a6faec5d8d4995f477aa2089295ddfd63c
2019-05-31 17:52:47 +02:00
- openstack/liberasurecode
Add liberasurecode and pyeclib as Swift team deliverables This more-accurately reflects the realities that: - the primary developers for these projects are Swift developers and - the primary consumer of these projects is Swift Change-Id: I333393e0304844e30983f89c82eabcad11487be2
2019-05-04 12:40:30 -07:00
pyeclib:
release-management: none
repos:
Some repos were renamed, update reference files A couple of repos were renamed or moved from one org to another, follow renames in reference docs. Depends-On: https://review.opendev.org/657155 Depends-On: https://review.opendev.org/662432 Depends-On: https://review.opendev.org/657277 Depends-On: https://review.opendev.org/661682 Depends-On: https://review.opendev.org/659489 Depends-On: https://review.opendev.org/644584 Change-Id: I1a5102a6faec5d8d4995f477aa2089295ddfd63c
2019-05-31 17:52:47 +02:00
- openstack/pyeclib
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-swiftclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-swiftclient
swift:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/swift
swift-bench:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/swift-bench
Applying Tacker for Big Tent Tacker is an OpenStack ecosystem project with a mission to build NFV Orchestration services for OpenStack. Tacker intends to support life-cycle management of Network Services and Virtual Network Functions (VNF). This service is designed to be compatible with the ETSI NFV Architecture Framework [1]. NFV Orchestration consists of two major components - VNF Manager and NFV Orchestrator. This project envisions to build both of these components under the OpenStack platform. The VNF Manager (VNFM) handles the life-cycle management of VNFs. It would instantiate VNFs on an OpenStack VIM and facilitate configuration, monitoring, healing and scaling of the VMs backing the VNF. Tacker plans to use many existing OpenStack services to realize these features. NFV Orchestrator (NFVO) provides end-to-end Network Service Orchestration. NFVO would in turn use VNFM component to stand up the VNFs composed in a Network Service. NFVO will also render VNF Forwarding Graphs (VNFFG) using a Service Function Chaining (SFC) API across the instantiated VNFs. Tacker intends to use Neutron's networking-sfc API [2] for this purpose. NFV work flows are typically described using templates. The current template schema of choice is TOSCA which is based on OASIS Standard [3]. At this moment TOSCA has the leading mindshare across VNF vendors and operators. Tacker project is working closely with OASIS TOSCA NFV standards group to shape the evolution of its Simple Profile for NFV [4]. The project is also leveraging and contributing to the Heat Translator's tosca-parser work [5]. Beyond TOSCA other templating schemes can be introduced in the future. Tacker started as a ServiceVM project under Neutron during the Atlanta Summit(2014). The evolution was slow and the interest totally dropped after the neutron vendor plugin decomposition. However the project had code assets for a template based lifecycle management of ServiceVMs. The remaining Tacker team members met in early 2015, brainstormed and eventually decided to pivot to ETSI NFV Orchestration use case. ETSI NFV envisions an Information Model based Orchestration and Life Cycle management of Virtual Network Functions. Since then Tacker developer community grew over the last three cycles and now getting contributions from a diverse set of participants [6] [7]. Tacker is also now actively collaborating with downstream OPNFV Projects like SFC [8], Parser [9] and Multisite [10]. Tacker functionality has been demonstrated in both OpenStack Vancouver and Tokyo Summits and in the recent OPNFV Summit. Tacker project strictly follows the Four Opens [11] suggested by OpenStack Foundation. Tacker code has been developed under an Apache 2.0 license. All code is submitted and reviewed through OpenStack Gerrit. The project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [12]. The project obeys the coordinated project interfaces, including tox, pbr, global-requirements, etc. Tacker gate now runs pep8, py27, docs tasks and a dsvm functional test. In summary, before Tacker, operators are expected to string together custom solutions using Heat, Ceilometer, etc. to achieve similar functionality. Tacker reduces such duplicate and complex effort in the industry by bringing together a community of NFV operators and VNF vendors to collaborate and build out a template based workflow engine and a higher level OpenStack "NFV Orchestration" API. [1] https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf [2] http://docs.openstack.org/developer/networking-sfc/ [3] https://www.oasis-open.org/committees/tosca/ [4] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html [5] https://github.com/openstack/tosca-parser [6] http://stackalytics.openstack.org/?project_type=openstack-others&module=tacker&metric=patches [7] http://stackalytics.com/report/contribution/tacker/90 [8] https://wiki.opnfv.org/service_function_chaining [9] https://wiki.opnfv.org/parser [10] https://wiki.opnfv.org/multisite [11] https://github.com/openstack/governance/blob/master/reference/opens.rst [12] https://launchpad.net/tacker [13] http://git.openstack.org/cgit/openstack/tacker [14] http://git.openstack.org/cgit/openstack/python-tackerclient [15] http://git.openstack.org/cgit/openstack/tacker-horizon [16] http://git.openstack.org/cgit/openstack/tacker-specs Change-Id: Idd7e9e8e4d428f9de28d8527e2f459b8ab8b8288
2016-02-04 00:12:41 +00:00
tacker:
ptl:
Appoint Yasufumi Ogawa as Tacker PTL Update Tacker PTL to show my candidancy. - http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014044.html I've worked for telcom industry for 17 years as a researcher in NTT R&D division. I have an experience of maintainer for driving a sub-project of DPDK which is introduced for realizing high-performance connectivity between VMs and containers [1]. I've also contributed to opendev from DPDK side by providing a plugin for the feature and making feedbacks [2][3]. For Tacker, I've made efforts for bug fixing and reviewing to accelerate the development for Ussuri release. We will target to refine the implementation to comply with ESTI standard aiming to become defact, and to cover container usecases including Kubernetes. [1] http://git.dpdk.org/apps/spp/ [2] https://opendev.org/x/networking-spp [3] https://www.openstack.org/summit/vancouver-2018/summit-schedule/speakers/12562 Change-Id: Ib8be004bbf1dab70f7d67c86e59564096b500295
2020-04-11 04:34:34 +09:00
name: Yasufumi Ogawa
irc: yasufum
email: yasufum.o@gmail.com
appointed:
- victoria
Applying Tacker for Big Tent Tacker is an OpenStack ecosystem project with a mission to build NFV Orchestration services for OpenStack. Tacker intends to support life-cycle management of Network Services and Virtual Network Functions (VNF). This service is designed to be compatible with the ETSI NFV Architecture Framework [1]. NFV Orchestration consists of two major components - VNF Manager and NFV Orchestrator. This project envisions to build both of these components under the OpenStack platform. The VNF Manager (VNFM) handles the life-cycle management of VNFs. It would instantiate VNFs on an OpenStack VIM and facilitate configuration, monitoring, healing and scaling of the VMs backing the VNF. Tacker plans to use many existing OpenStack services to realize these features. NFV Orchestrator (NFVO) provides end-to-end Network Service Orchestration. NFVO would in turn use VNFM component to stand up the VNFs composed in a Network Service. NFVO will also render VNF Forwarding Graphs (VNFFG) using a Service Function Chaining (SFC) API across the instantiated VNFs. Tacker intends to use Neutron's networking-sfc API [2] for this purpose. NFV work flows are typically described using templates. The current template schema of choice is TOSCA which is based on OASIS Standard [3]. At this moment TOSCA has the leading mindshare across VNF vendors and operators. Tacker project is working closely with OASIS TOSCA NFV standards group to shape the evolution of its Simple Profile for NFV [4]. The project is also leveraging and contributing to the Heat Translator's tosca-parser work [5]. Beyond TOSCA other templating schemes can be introduced in the future. Tacker started as a ServiceVM project under Neutron during the Atlanta Summit(2014). The evolution was slow and the interest totally dropped after the neutron vendor plugin decomposition. However the project had code assets for a template based lifecycle management of ServiceVMs. The remaining Tacker team members met in early 2015, brainstormed and eventually decided to pivot to ETSI NFV Orchestration use case. ETSI NFV envisions an Information Model based Orchestration and Life Cycle management of Virtual Network Functions. Since then Tacker developer community grew over the last three cycles and now getting contributions from a diverse set of participants [6] [7]. Tacker is also now actively collaborating with downstream OPNFV Projects like SFC [8], Parser [9] and Multisite [10]. Tacker functionality has been demonstrated in both OpenStack Vancouver and Tokyo Summits and in the recent OPNFV Summit. Tacker project strictly follows the Four Opens [11] suggested by OpenStack Foundation. Tacker code has been developed under an Apache 2.0 license. All code is submitted and reviewed through OpenStack Gerrit. The project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [12]. The project obeys the coordinated project interfaces, including tox, pbr, global-requirements, etc. Tacker gate now runs pep8, py27, docs tasks and a dsvm functional test. In summary, before Tacker, operators are expected to string together custom solutions using Heat, Ceilometer, etc. to achieve similar functionality. Tacker reduces such duplicate and complex effort in the industry by bringing together a community of NFV operators and VNF vendors to collaborate and build out a template based workflow engine and a higher level OpenStack "NFV Orchestration" API. [1] https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf [2] http://docs.openstack.org/developer/networking-sfc/ [3] https://www.oasis-open.org/committees/tosca/ [4] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html [5] https://github.com/openstack/tosca-parser [6] http://stackalytics.openstack.org/?project_type=openstack-others&module=tacker&metric=patches [7] http://stackalytics.com/report/contribution/tacker/90 [8] https://wiki.opnfv.org/service_function_chaining [9] https://wiki.opnfv.org/parser [10] https://wiki.opnfv.org/multisite [11] https://github.com/openstack/governance/blob/master/reference/opens.rst [12] https://launchpad.net/tacker [13] http://git.openstack.org/cgit/openstack/tacker [14] http://git.openstack.org/cgit/openstack/python-tackerclient [15] http://git.openstack.org/cgit/openstack/tacker-horizon [16] http://git.openstack.org/cgit/openstack/tacker-specs Change-Id: Idd7e9e8e4d428f9de28d8527e2f459b8ab8b8288
2016-02-04 00:12:41 +00:00
irc-channel: tacker
service: NFV Orchestration service
mission: >
To implement Network Function Virtualization (NFV) Orchestration services
and libraries for end-to-end life-cycle management of Network Services
and Virtual Network Functions (VNFs).
url: https://wiki.openstack.org/wiki/Tacker
deliverables:
tacker:
repos:
- openstack/tacker
Change tacker-horizon to type horizon-plugin tacker-horizon repo brings in horizon dashboard functionality for tacker project. This patchset now correctly marks that of type:horizon-plugin. Change-Id: Ibd5f7903354ed070914635dce64fde68b2d3e814
2016-08-04 16:29:09 -07:00
tacker-horizon:
repos:
- openstack/tacker-horizon
Applying Tacker for Big Tent Tacker is an OpenStack ecosystem project with a mission to build NFV Orchestration services for OpenStack. Tacker intends to support life-cycle management of Network Services and Virtual Network Functions (VNF). This service is designed to be compatible with the ETSI NFV Architecture Framework [1]. NFV Orchestration consists of two major components - VNF Manager and NFV Orchestrator. This project envisions to build both of these components under the OpenStack platform. The VNF Manager (VNFM) handles the life-cycle management of VNFs. It would instantiate VNFs on an OpenStack VIM and facilitate configuration, monitoring, healing and scaling of the VMs backing the VNF. Tacker plans to use many existing OpenStack services to realize these features. NFV Orchestrator (NFVO) provides end-to-end Network Service Orchestration. NFVO would in turn use VNFM component to stand up the VNFs composed in a Network Service. NFVO will also render VNF Forwarding Graphs (VNFFG) using a Service Function Chaining (SFC) API across the instantiated VNFs. Tacker intends to use Neutron's networking-sfc API [2] for this purpose. NFV work flows are typically described using templates. The current template schema of choice is TOSCA which is based on OASIS Standard [3]. At this moment TOSCA has the leading mindshare across VNF vendors and operators. Tacker project is working closely with OASIS TOSCA NFV standards group to shape the evolution of its Simple Profile for NFV [4]. The project is also leveraging and contributing to the Heat Translator's tosca-parser work [5]. Beyond TOSCA other templating schemes can be introduced in the future. Tacker started as a ServiceVM project under Neutron during the Atlanta Summit(2014). The evolution was slow and the interest totally dropped after the neutron vendor plugin decomposition. However the project had code assets for a template based lifecycle management of ServiceVMs. The remaining Tacker team members met in early 2015, brainstormed and eventually decided to pivot to ETSI NFV Orchestration use case. ETSI NFV envisions an Information Model based Orchestration and Life Cycle management of Virtual Network Functions. Since then Tacker developer community grew over the last three cycles and now getting contributions from a diverse set of participants [6] [7]. Tacker is also now actively collaborating with downstream OPNFV Projects like SFC [8], Parser [9] and Multisite [10]. Tacker functionality has been demonstrated in both OpenStack Vancouver and Tokyo Summits and in the recent OPNFV Summit. Tacker project strictly follows the Four Opens [11] suggested by OpenStack Foundation. Tacker code has been developed under an Apache 2.0 license. All code is submitted and reviewed through OpenStack Gerrit. The project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [12]. The project obeys the coordinated project interfaces, including tox, pbr, global-requirements, etc. Tacker gate now runs pep8, py27, docs tasks and a dsvm functional test. In summary, before Tacker, operators are expected to string together custom solutions using Heat, Ceilometer, etc. to achieve similar functionality. Tacker reduces such duplicate and complex effort in the industry by bringing together a community of NFV operators and VNF vendors to collaborate and build out a template based workflow engine and a higher level OpenStack "NFV Orchestration" API. [1] https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf [2] http://docs.openstack.org/developer/networking-sfc/ [3] https://www.oasis-open.org/committees/tosca/ [4] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html [5] https://github.com/openstack/tosca-parser [6] http://stackalytics.openstack.org/?project_type=openstack-others&module=tacker&metric=patches [7] http://stackalytics.com/report/contribution/tacker/90 [8] https://wiki.opnfv.org/service_function_chaining [9] https://wiki.opnfv.org/parser [10] https://wiki.opnfv.org/multisite [11] https://github.com/openstack/governance/blob/master/reference/opens.rst [12] https://launchpad.net/tacker [13] http://git.openstack.org/cgit/openstack/tacker [14] http://git.openstack.org/cgit/openstack/python-tackerclient [15] http://git.openstack.org/cgit/openstack/tacker-horizon [16] http://git.openstack.org/cgit/openstack/tacker-specs Change-Id: Idd7e9e8e4d428f9de28d8527e2f459b8ab8b8288
2016-02-04 00:12:41 +00:00
python-tackerclient:
repos:
- openstack/python-tackerclient
tacker-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Applying Tacker for Big Tent Tacker is an OpenStack ecosystem project with a mission to build NFV Orchestration services for OpenStack. Tacker intends to support life-cycle management of Network Services and Virtual Network Functions (VNF). This service is designed to be compatible with the ETSI NFV Architecture Framework [1]. NFV Orchestration consists of two major components - VNF Manager and NFV Orchestrator. This project envisions to build both of these components under the OpenStack platform. The VNF Manager (VNFM) handles the life-cycle management of VNFs. It would instantiate VNFs on an OpenStack VIM and facilitate configuration, monitoring, healing and scaling of the VMs backing the VNF. Tacker plans to use many existing OpenStack services to realize these features. NFV Orchestrator (NFVO) provides end-to-end Network Service Orchestration. NFVO would in turn use VNFM component to stand up the VNFs composed in a Network Service. NFVO will also render VNF Forwarding Graphs (VNFFG) using a Service Function Chaining (SFC) API across the instantiated VNFs. Tacker intends to use Neutron's networking-sfc API [2] for this purpose. NFV work flows are typically described using templates. The current template schema of choice is TOSCA which is based on OASIS Standard [3]. At this moment TOSCA has the leading mindshare across VNF vendors and operators. Tacker project is working closely with OASIS TOSCA NFV standards group to shape the evolution of its Simple Profile for NFV [4]. The project is also leveraging and contributing to the Heat Translator's tosca-parser work [5]. Beyond TOSCA other templating schemes can be introduced in the future. Tacker started as a ServiceVM project under Neutron during the Atlanta Summit(2014). The evolution was slow and the interest totally dropped after the neutron vendor plugin decomposition. However the project had code assets for a template based lifecycle management of ServiceVMs. The remaining Tacker team members met in early 2015, brainstormed and eventually decided to pivot to ETSI NFV Orchestration use case. ETSI NFV envisions an Information Model based Orchestration and Life Cycle management of Virtual Network Functions. Since then Tacker developer community grew over the last three cycles and now getting contributions from a diverse set of participants [6] [7]. Tacker is also now actively collaborating with downstream OPNFV Projects like SFC [8], Parser [9] and Multisite [10]. Tacker functionality has been demonstrated in both OpenStack Vancouver and Tokyo Summits and in the recent OPNFV Summit. Tacker project strictly follows the Four Opens [11] suggested by OpenStack Foundation. Tacker code has been developed under an Apache 2.0 license. All code is submitted and reviewed through OpenStack Gerrit. The project maintains a core team that approves all changes. Bugs are filed, reviewed and tracked in Launchpad [12]. The project obeys the coordinated project interfaces, including tox, pbr, global-requirements, etc. Tacker gate now runs pep8, py27, docs tasks and a dsvm functional test. In summary, before Tacker, operators are expected to string together custom solutions using Heat, Ceilometer, etc. to achieve similar functionality. Tacker reduces such duplicate and complex effort in the industry by bringing together a community of NFV operators and VNF vendors to collaborate and build out a template based workflow engine and a higher level OpenStack "NFV Orchestration" API. [1] https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf [2] http://docs.openstack.org/developer/networking-sfc/ [3] https://www.oasis-open.org/committees/tosca/ [4] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html [5] https://github.com/openstack/tosca-parser [6] http://stackalytics.openstack.org/?project_type=openstack-others&module=tacker&metric=patches [7] http://stackalytics.com/report/contribution/tacker/90 [8] https://wiki.opnfv.org/service_function_chaining [9] https://wiki.opnfv.org/parser [10] https://wiki.opnfv.org/multisite [11] https://github.com/openstack/governance/blob/master/reference/opens.rst [12] https://launchpad.net/tacker [13] http://git.openstack.org/cgit/openstack/tacker [14] http://git.openstack.org/cgit/openstack/python-tackerclient [15] http://git.openstack.org/cgit/openstack/tacker-horizon [16] http://git.openstack.org/cgit/openstack/tacker-specs Change-Id: Idd7e9e8e4d428f9de28d8527e2f459b8ab8b8288
2016-02-04 00:12:41 +00:00
repos:
- openstack/tacker-specs
Move heat-translator and tosca-parser to tacker's governance We agreed with this migration because - tosca-parser is now maintained effectively by the tacker team instead of the heat team. - heat-translator can be a generic template translator but it has supported only TOSCA template and is effectively tosca template translator. [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032303.html Change-Id: I47cc2024a904df621879fa60a0e4cdb371fee64f
2023-03-02 11:48:24 +09:00
heat-translator:
repos:
- openstack/heat-translator
tosca-parser:
repos:
- openstack/tosca-parser
Sort projects.yaml Change-Id: Ic087ccc0628f5488f3e81fc0462e18af082a61d3
2015-12-08 09:15:48 +09:00
Telemetry:
ptl:
Add results from the 2024.1/Caracal election Also clear out existing TC roles and prepare for nominations. Change-Id: I54020dd551b6b84969d783193e19d181cfe9c156
2023-09-21 14:22:53 +10:00
name: Erno Kuvaja
irc: jokke_
email: jokke@usr.fi
Appoint Trinh Nguyen as Telemetry PTL Telemetry did not have any PTL candidate in the required candidacy timeframe and as a result has triggered the leaderless team process. Trinh Nguyen volunteered to take the role, while Lingxian Kong and Rong Zhu promised resources to help: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003897.html Change-Id: I71615aa714edcd0b821e46f153ad6481cd0c4c20
2019-03-21 11:50:24 +01:00
appointed:
- train
Sort projects.yaml Change-Id: Ic087ccc0628f5488f3e81fc0462e18af082a61d3
2015-12-08 09:15:48 +09:00
irc-channel: openstack-telemetry
service: Telemetry service
mission: >
To reliably collect measurements of the utilization of the physical and
virtual resources comprising deployed clouds, persist these data for
subsequent retrieval and analysis, and trigger actions when defined
criteria are met.
url: https://wiki.openstack.org/wiki/Telemetry
deliverables:
aodh:
repos:
- openstack/aodh
ceilometer:
repos:
- openstack/ceilometer
Change the name of the ceilometer-specs to telemetry-specs In M release, the name of the ceilometer-specs has been changed to the 'telemetry-specs'. So does the git repo. The change set: https://review.openstack.org/#/c/248897/ Change-Id: I4c4f4536d1f93ed31e733f1e88c1e36dd1183047 Closes-Bug: #1550119
2016-02-26 02:50:08 -05:00
telemetry-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Sort projects.yaml Change-Id: Ic087ccc0628f5488f3e81fc0462e18af082a61d3
2015-12-08 09:15:48 +09:00
repos:
Change the name of the ceilometer-specs to telemetry-specs In M release, the name of the ceilometer-specs has been changed to the 'telemetry-specs'. So does the git repo. The change set: https://review.openstack.org/#/c/248897/ Change-Id: I4c4f4536d1f93ed31e733f1e88c1e36dd1183047 Closes-Bug: #1550119
2016-02-26 02:50:08 -05:00
- openstack/telemetry-specs
Sort projects.yaml Change-Id: Ic087ccc0628f5488f3e81fc0462e18af082a61d3
2015-12-08 09:15:48 +09:00
ceilometermiddleware:
repos:
- openstack/ceilometermiddleware
add python-aodhclient to telemetry we have aodh service for alarming. we now have python-aodhclient rather than overloading ceilometerclient Change-Id: I21a6d2d038d9aabd0a1c2e777b9f9223b5b56d38 Depends-On: Change-Id: I11cc63a3fb987c457595220d91315fdadcf41a12
2015-12-18 17:04:16 -05:00
python-aodhclient:
repos:
- openstack/python-aodhclient
Add python-observabilityclient Add the observabilityclient to the Telemetry project to enable communication with prometheus. Depends-On: Iddc93c4a78358eda0b823afff968c604457d50fc Change-Id: I42bba543880436457d825fcd09318f7850bd28c1
2023-09-13 14:22:17 +02:00
python-observabilityclient:
repos:
- openstack/python-observabilityclient
Add telemetry-tempest-plugin to telemetry project Create a new repository for telemetry's tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". It contains tempest plugin for all Telemetry projects. Depends-On: I533e3edb6102ea871a5c0bf72299fb0da7a13c52 Change-Id: Ie9e5b48ccdacb4cea08f1525d23348f7398c9dbf
2017-12-09 21:07:56 +05:30
telemetry-tempest-plugin:
repos:
- openstack/telemetry-tempest-plugin
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
trove:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Add TC/PTL results from 2025.1 election Also clear out existing TC roles and prepare for nominations. Depends-On: Id5847c7c37d556b11932dae542f4aaeb699cf7ec Change-Id: I7760c815d032c7aaff9956588b6ce5c1fb7b4750
2024-09-19 23:17:25 +09:00
name: wu chunyang
Appoint ChunYang Wu as PTL of Trove Change-Id: I681af797d245a2cea9d91f944573ba332bbde1b1
2024-05-27 14:17:09 +08:00
irc: wuchunyang
email: wchy1001@gmail.com
mark appointed PTLs for Stein The PTLs for packaging-rpm and trove were appointed for Stein, so we should record that info. See Idf78e00c59d10528a2b4950f8baa93c6731973ea Change-Id: I62cdea4baaa5606de6cf101154323d8a2a0e0fbf Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2018-08-13 13:45:06 -04:00
appointed:
- stein
Appoint Wu Chunyang as Trove PTL Wu Chunyang volutneer to maintain the Trove as PTL for zed cycle - http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027654.html Change-Id: I4f569f445bd4addd6544cfe9b068b33a471fd5b5
2022-03-10 11:25:57 -06:00
- zed
Appoint Wuchunyang as Trove PTL Change-Id: Iefc5c9187a4ad4b63a4ca4de1baf5fe0a863d5a6
2023-12-05 11:01:43 +08:00
- '2024.1'
Appoint ChunYang Wu as PTL of Trove Change-Id: I681af797d245a2cea9d91f944573ba332bbde1b1
2024-05-27 14:17:09 +08:00
- '2024.2'
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-trove
service: Database service
Add Solum to OpenStack Projects List Solum has achived a level of stability and maturity where all of its contributors feel it is ready to join OpenStack. Solum's mission is to make cloud services easier to consume and integrate with your application development process. Adoption of Solum will lead to more application developers using OpenStack as a cloud platform. It is directly built on OpenStack infrastructure services including Heat, Keystone, Glance, and Swift. Through Heat it also uses Nova, and soon will also use Magnum. Solum conforms to each of our four opens: Open Source ----------- Apache v2.0 License, no dependencies restrict deployment or redistribution. Open Development ---------------- We use Stackforge, including Gerrit for all code reviews with a test driven gate. The PTL is available as a liason for cross-project teams. We integrate with other projects in OpenStack to prevent overlap in our efforts. Solum conforms completely to the OpenStack development style. Open Design ----------- Our project direction is discussed openly in pubic forums including at multiple design summits and midcycle meetups. We use the openstack-dev mailing list to discuss issues. Open Community -------------- Solum's PTL is chosen by the community in open elections. We hold weekly IRC meetings in official OpenStack meeting channels. We are OpenStack API interoperable, using keystone middleware for discovery and authentication. We have an active team of dedicated contributors who are committed to the success of the project. Change-Id: Id74222381910f006a5a69f9e3746101bd4a32e12
2015-06-12 06:21:19 +00:00
mission: >
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
To provide scalable and reliable Cloud Database as a Service functionality
for both relational and non-relational database engines, and to continue to
improve its fully-featured and extensible open source framework.
url: https://wiki.openstack.org/wiki/Trove
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-troveclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-troveclient
trove:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/trove
Adding trove-dashboard to trove Trove's Horizon content is moving from integrated in Horizon to a standalone Horizon plugin that will be managed by the Trove team. Depends-On: I158eac980f767a4b8cd43294e8cc215fbb1586f3 Change-Id: Ief3829b45987dfb4078c78428f5f699912542868
2015-12-11 10:52:32 -07:00
trove-dashboard:
repos:
- openstack/trove-dashboard
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
trove-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/trove-specs
Add trove-tempest-plugin under trove project Depends-On: Ica9e407fdcbe5fb81d0eac21af598194fdffed6f Change-Id: I9197e1b21b81a458017acabf91c2b2e8c9aebf9d
2017-12-11 20:44:01 +05:30
trove-tempest-plugin:
repos:
- openstack/trove-tempest-plugin
Venus official project status Venus is a unified log management module, according to the keyrequirements of OpenStack in log storage, retrieval, analysis and so on. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation etc.. Venus can help operator or maintainer to improve the level of platform management and the goal of the project is to make log retrieval no longer difficult, to make log typical error warnings become a reality. Venus project has been contributed to OpenStack Community in November 2020. At that time, functions such as collection, retrieval, and error statistics of platform log and service log were developed. In order to make the venus project easier and more practical, the functions of venus have been enriched and improved in the past six monthsas follows: 1. Improved and standardized the completed code, added some test codes[1]. 2. Venus-dashboard plug-in [2] based on Horizon is developed, which can provide operators with a log retrieval page, and the function is still being improved. 3. To make the deployment more versatile, besides deploy with devstack, kolla-based venus deployment script is submit[3]. 4. The typical log errors of the openstack platform are being collected, and the alarm function is also under development. The offline promotion of venus is also continuing. Venus is shared on Hackathon in April 2021, and attracted the interest of companies such as China Unicom, who express their requirements of Venus. At the upcoming OpenInfra Days China, Venus will to be promote so that more users and developers can known and use. In the future, in addition to improving existing functions, algorithms will be added to log fault location to enable Venus to play a greater role in intelligent operation and maintenance. [1] https://review.opendev.org/q/project:inspur/venus [2] https://review.opendev.org/q/project:inspur/venus-dashboard [3] https://review.opendev.org/q/topic:%22venus%22+(status:open%20OR%20status:merged) [4] ML discussion: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html Change-Id: Id82df49a776537bcd38b49a7f95fc0c10bc2f925
2021-08-17 14:27:09 +08:00
venus:
ptl:
Appoint Eric Zhang as PTL of Venus Change-Id: I901cdeb77ac237acd75bf9148962b7e19879fed2
2023-11-01 02:33:02 +00:00
name: Eric Zhang
Add PTL results from the 2024.2/Dalmatian election Depends-On: If6c157efebc58d1fbe32a61a64f209b4102ac5c8 Change-Id: Ic74bfc853d2d9d045d4c589e1fd6c50afa608423
2024-03-22 09:00:21 +09:00
irc: No nick supplied
Appoint Eric Zhang as PTL of Venus Change-Id: I901cdeb77ac237acd75bf9148962b7e19879fed2
2023-11-01 02:33:02 +00:00
email: zhanglf01@inspur.com
Appoint pangliye as Venus PTL pangliye confirmed to lead the Venus as PTL for Zed cycle - https://etherpad.opendev.org/p/zed-leaderless Change-Id: I7cf819a1ebbaf8edfb2b574577eb90f5ce7a9750
2022-02-27 18:55:50 -06:00
appointed:
- zed
Consider release version as string in projects data We need to use the release version as string, so updating the PTL 'appointment' field and the data in projects.yaml Change-Id: Ib097517f514e68246fb6e27b83e98a1f3f6b8eed
2023-03-10 18:14:20 -06:00
- '2023.1'
Appoint Eric Zhang as PTL of Venus Change-Id: I901cdeb77ac237acd75bf9148962b7e19879fed2
2023-11-01 02:33:02 +00:00
- '2024.1'
Venus official project status Venus is a unified log management module, according to the keyrequirements of OpenStack in log storage, retrieval, analysis and so on. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation etc.. Venus can help operator or maintainer to improve the level of platform management and the goal of the project is to make log retrieval no longer difficult, to make log typical error warnings become a reality. Venus project has been contributed to OpenStack Community in November 2020. At that time, functions such as collection, retrieval, and error statistics of platform log and service log were developed. In order to make the venus project easier and more practical, the functions of venus have been enriched and improved in the past six monthsas follows: 1. Improved and standardized the completed code, added some test codes[1]. 2. Venus-dashboard plug-in [2] based on Horizon is developed, which can provide operators with a log retrieval page, and the function is still being improved. 3. To make the deployment more versatile, besides deploy with devstack, kolla-based venus deployment script is submit[3]. 4. The typical log errors of the openstack platform are being collected, and the alarm function is also under development. The offline promotion of venus is also continuing. Venus is shared on Hackathon in April 2021, and attracted the interest of companies such as China Unicom, who express their requirements of Venus. At the upcoming OpenInfra Days China, Venus will to be promote so that more users and developers can known and use. In the future, in addition to improving existing functions, algorithms will be added to log fault location to enable Venus to play a greater role in intelligent operation and maintenance. [1] https://review.opendev.org/q/project:inspur/venus [2] https://review.opendev.org/q/project:inspur/venus-dashboard [3] https://review.opendev.org/q/topic:%22venus%22+(status:open%20OR%20status:merged) [4] ML discussion: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html Change-Id: Id82df49a776537bcd38b49a7f95fc0c10bc2f925
2021-08-17 14:27:09 +08:00
irc-channel: openstack-venus
service: Log management service
mission: >
Venus is a unified log management module, according to the key
requirements of OpenStack in log storage, retrieval, analysis
and so on. This module can provide a one-stop solution to log
collection, cleaning, indexing, analysis, alarm, visualization,
report generation etc..
url: https://wiki.openstack.org/wiki/Venus
deliverables:
venus:
repos:
Update venus repos The repos were renamed recently and the governance repo has to follow. Change-Id: I85ff706e1d9493c204e0fb62054f63f5e36ba44c
2021-10-25 08:45:22 +00:00
- openstack/venus
Venus official project status Venus is a unified log management module, according to the keyrequirements of OpenStack in log storage, retrieval, analysis and so on. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation etc.. Venus can help operator or maintainer to improve the level of platform management and the goal of the project is to make log retrieval no longer difficult, to make log typical error warnings become a reality. Venus project has been contributed to OpenStack Community in November 2020. At that time, functions such as collection, retrieval, and error statistics of platform log and service log were developed. In order to make the venus project easier and more practical, the functions of venus have been enriched and improved in the past six monthsas follows: 1. Improved and standardized the completed code, added some test codes[1]. 2. Venus-dashboard plug-in [2] based on Horizon is developed, which can provide operators with a log retrieval page, and the function is still being improved. 3. To make the deployment more versatile, besides deploy with devstack, kolla-based venus deployment script is submit[3]. 4. The typical log errors of the openstack platform are being collected, and the alarm function is also under development. The offline promotion of venus is also continuing. Venus is shared on Hackathon in April 2021, and attracted the interest of companies such as China Unicom, who express their requirements of Venus. At the upcoming OpenInfra Days China, Venus will to be promote so that more users and developers can known and use. In the future, in addition to improving existing functions, algorithms will be added to log fault location to enable Venus to play a greater role in intelligent operation and maintenance. [1] https://review.opendev.org/q/project:inspur/venus [2] https://review.opendev.org/q/project:inspur/venus-dashboard [3] https://review.opendev.org/q/topic:%22venus%22+(status:open%20OR%20status:merged) [4] ML discussion: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html Change-Id: Id82df49a776537bcd38b49a7f95fc0c10bc2f925
2021-08-17 14:27:09 +08:00
venus-specs:
release-management: none
repos:
Update venus repos The repos were renamed recently and the governance repo has to follow. Change-Id: I85ff706e1d9493c204e0fb62054f63f5e36ba44c
2021-10-25 08:45:22 +00:00
- openstack/venus-specs
Venus official project status Venus is a unified log management module, according to the keyrequirements of OpenStack in log storage, retrieval, analysis and so on. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation etc.. Venus can help operator or maintainer to improve the level of platform management and the goal of the project is to make log retrieval no longer difficult, to make log typical error warnings become a reality. Venus project has been contributed to OpenStack Community in November 2020. At that time, functions such as collection, retrieval, and error statistics of platform log and service log were developed. In order to make the venus project easier and more practical, the functions of venus have been enriched and improved in the past six monthsas follows: 1. Improved and standardized the completed code, added some test codes[1]. 2. Venus-dashboard plug-in [2] based on Horizon is developed, which can provide operators with a log retrieval page, and the function is still being improved. 3. To make the deployment more versatile, besides deploy with devstack, kolla-based venus deployment script is submit[3]. 4. The typical log errors of the openstack platform are being collected, and the alarm function is also under development. The offline promotion of venus is also continuing. Venus is shared on Hackathon in April 2021, and attracted the interest of companies such as China Unicom, who express their requirements of Venus. At the upcoming OpenInfra Days China, Venus will to be promote so that more users and developers can known and use. In the future, in addition to improving existing functions, algorithms will be added to log fault location to enable Venus to play a greater role in intelligent operation and maintenance. [1] https://review.opendev.org/q/project:inspur/venus [2] https://review.opendev.org/q/project:inspur/venus-dashboard [3] https://review.opendev.org/q/topic:%22venus%22+(status:open%20OR%20status:merged) [4] ML discussion: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html Change-Id: Id82df49a776537bcd38b49a7f95fc0c10bc2f925
2021-08-17 14:27:09 +08:00
venus-dashboard:
repos:
Update venus repos The repos were renamed recently and the governance repo has to follow. Change-Id: I85ff706e1d9493c204e0fb62054f63f5e36ba44c
2021-10-25 08:45:22 +00:00
- openstack/venus-dashboard
Venus official project status Venus is a unified log management module, according to the keyrequirements of OpenStack in log storage, retrieval, analysis and so on. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation etc.. Venus can help operator or maintainer to improve the level of platform management and the goal of the project is to make log retrieval no longer difficult, to make log typical error warnings become a reality. Venus project has been contributed to OpenStack Community in November 2020. At that time, functions such as collection, retrieval, and error statistics of platform log and service log were developed. In order to make the venus project easier and more practical, the functions of venus have been enriched and improved in the past six monthsas follows: 1. Improved and standardized the completed code, added some test codes[1]. 2. Venus-dashboard plug-in [2] based on Horizon is developed, which can provide operators with a log retrieval page, and the function is still being improved. 3. To make the deployment more versatile, besides deploy with devstack, kolla-based venus deployment script is submit[3]. 4. The typical log errors of the openstack platform are being collected, and the alarm function is also under development. The offline promotion of venus is also continuing. Venus is shared on Hackathon in April 2021, and attracted the interest of companies such as China Unicom, who express their requirements of Venus. At the upcoming OpenInfra Days China, Venus will to be promote so that more users and developers can known and use. In the future, in addition to improving existing functions, algorithms will be added to log fault location to enable Venus to play a greater role in intelligent operation and maintenance. [1] https://review.opendev.org/q/project:inspur/venus [2] https://review.opendev.org/q/project:inspur/venus-dashboard [3] https://review.opendev.org/q/topic:%22venus%22+(status:open%20OR%20status:merged) [4] ML discussion: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html Change-Id: Id82df49a776537bcd38b49a7f95fc0c10bc2f925
2021-08-17 14:27:09 +08:00
python-venusclient:
repos:
Update venus repos The repos were renamed recently and the governance repo has to follow. Change-Id: I85ff706e1d9493c204e0fb62054f63f5e36ba44c
2021-10-25 08:45:22 +00:00
- openstack/python-venusclient
Venus official project status Venus is a unified log management module, according to the keyrequirements of OpenStack in log storage, retrieval, analysis and so on. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation etc.. Venus can help operator or maintainer to improve the level of platform management and the goal of the project is to make log retrieval no longer difficult, to make log typical error warnings become a reality. Venus project has been contributed to OpenStack Community in November 2020. At that time, functions such as collection, retrieval, and error statistics of platform log and service log were developed. In order to make the venus project easier and more practical, the functions of venus have been enriched and improved in the past six monthsas follows: 1. Improved and standardized the completed code, added some test codes[1]. 2. Venus-dashboard plug-in [2] based on Horizon is developed, which can provide operators with a log retrieval page, and the function is still being improved. 3. To make the deployment more versatile, besides deploy with devstack, kolla-based venus deployment script is submit[3]. 4. The typical log errors of the openstack platform are being collected, and the alarm function is also under development. The offline promotion of venus is also continuing. Venus is shared on Hackathon in April 2021, and attracted the interest of companies such as China Unicom, who express their requirements of Venus. At the upcoming OpenInfra Days China, Venus will to be promote so that more users and developers can known and use. In the future, in addition to improving existing functions, algorithms will be added to log fault location to enable Venus to play a greater role in intelligent operation and maintenance. [1] https://review.opendev.org/q/project:inspur/venus [2] https://review.opendev.org/q/project:inspur/venus-dashboard [3] https://review.opendev.org/q/topic:%22venus%22+(status:open%20OR%20status:merged) [4] ML discussion: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html Change-Id: Id82df49a776537bcd38b49a7f95fc0c10bc2f925
2021-08-17 14:27:09 +08:00
venus-tempest-plugin:
repos:
Update venus repos The repos were renamed recently and the governance repo has to follow. Change-Id: I85ff706e1d9493c204e0fb62054f63f5e36ba44c
2021-10-25 08:45:22 +00:00
- openstack/venus-tempest-plugin
Add project Vitrage to OpenStack big-tent This is a request to add the Vitrage project[1] to the Big Tent. Vitrage aims to be the OpenStack RCA (Root Cause Analysis) Engine for organizing, analyzing and expanding OpenStack alarms & events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected. Vitrage provides an holistic and complete view of the cloud, with a clear visualization of the physical-to-virtual (and soon the applicative) layers. Vitrage receives information from various OpenStack data sources (Aodh, Nova, Cinder and Neutron), as well as from external data sources (like Nagios, and in the future Zabbix) and combines it in a topology graph database. This topology is used to deduce that certain problems in the physical layer should cause problems in the virtual layer; to trigger corresponding alarms; to modify (currently only in Vitrage) resources states; and to reflect the causal relationship of the alarms in the cloud. Vitrage development started right after Mitaka Summit, where we had meetings with other OpenStack projects (like Ceilometer/Aodh), presented to them Vitrage ideas, verified that there was no overlap between our projects, and got their blessing. Vitrage follows OpenStack guidelines and “four opens” from day one. Vitrage code and specifications are entirely open source. The project is fully licensed under the Apache 2.0 license, and the project uses public code reviews in gerrit. The code can be found here[2][3][4][5]. Vitrage gate runs docs, pep8, python27, python34 and tempest tests. The #openstack-vitrage IRC channel on freenode is logged [6]. Vitrage team holds weekly IRC meetings on OpenStack official meeting channel, which is logged as well[7]. Openstack-dev mailing list is used to publicly discuss Vitrage related issues. Vitrage wiki page[1] consists of high-level and low-level design documents, presentations and demos. OpenStack launchpad[8] is used to manage blueprints and bugs. We started the process of Newton design discussions right after Austin Summit. We perform these discussions in the IRC meetings, in the mailing list, and in etherpads[9][10] created for this purpose. Vitrage was presented in two sessions in Austin Summit[11][12], as well as in demos in the marketplace. In addition, Aodh-Vitrage integration was discussed in Aodh design session[13][14]. One Aodh fix was already made to enable this integration[15]. Other integrations, with Monasca and Congress, were discussed during the summit, and we are continuing such discussions in the mailing list. In addition to OpenStack community, Vitrage is also involved in OPNFV projects. Vitrage is considered a reference implementation for OPNFV Doctor Inspector component [16][17], as well as for OPNFV PinPoint[18] project. Vitrage is about to be presented, together with OPNFV Doctor and with OpenStack Congress, in OPNFV Summit in Berlin[19]. Vitrage demo is going to be presented in Doctor POC booth. For the past six months, since Vitrage development began, we have been encouraging interaction and cooperation with other projects and contributors in OpenStack. To date, a few companies and projects have worked with us on formulating requirements as well as contributed code. We are working hard at involving additional players in Vitrage, to help drive its feature set so that it supports a wide range of needs from the community. To summarize, Vitrage fills a real need in OpenStack. Vitrage holistic and complete view that includes all of the layers of the cloud, as well as its alarm analysis and correlation, is currently lacking in OpenStack. As Vitrage enhances OpenStack capabilities, raises a lot of interest in the community, and is developed by OpenStack standards, we believe it belongs to the big tent. [1] https://wiki.openstack.org/wiki/Vitrage [2] https://github.com/openstack/vitrage [3] https://github.com/openstack/vitrage-dashboard [4] https://github.com/openstack/python-vitrageclient [5] https://github.com/openstack/vitrage-specs [6] http://eavesdrop.openstack.org/irclogs/%23openstack-vitrage/ [7] http://eavesdrop.openstack.org/meetings/vitrage/ [8] https://launchpad.net/vitrage [9] https://etherpad.openstack.org/p/vitrage-newton-planning [10] https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design [11] https://www.youtube.com/watch?v=9Qw5coTLgMo [12] https://www.youtube.com/watch?v=ey68KNKXc5c [13] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9203 [14] https://etherpad.openstack.org/p/newton-telemetry-vitrage [15] https://review.openstack.org/#/c/314683/ [16] https://wiki.opnfv.org/display/doctor/Doctor+Home [17] https://jira.opnfv.org/browse/DOCTOR-57 [18] https://wiki.opnfv.org/display/pinpoint/Pinpoint+Home [19] https://www.eventscribe.com/2016/OPNFV/aaSearchByDay.asp?h=Full%20Schedule&BCFO=P|G see “Failure Inspection in Doctor using Vitrage and Congress” Change-Id: I47f7302da3d35a4620fc910c38384b4b4c71de7d
2016-05-24 08:03:53 +00:00
vitrage:
ptl:
Appoint Dmitriy Rabotyagov as Vitrage PTL Change-Id: I0599f7e2cc0bd9f0f0cd234e613822447c4b9dba
2023-05-03 13:12:13 +02:00
name: Dmitriy Rabotyagov
irc: noonedeadpunk
email: noonedeadpunk@gmail.com
appointed:
- '2023.2'
Add project Vitrage to OpenStack big-tent This is a request to add the Vitrage project[1] to the Big Tent. Vitrage aims to be the OpenStack RCA (Root Cause Analysis) Engine for organizing, analyzing and expanding OpenStack alarms & events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected. Vitrage provides an holistic and complete view of the cloud, with a clear visualization of the physical-to-virtual (and soon the applicative) layers. Vitrage receives information from various OpenStack data sources (Aodh, Nova, Cinder and Neutron), as well as from external data sources (like Nagios, and in the future Zabbix) and combines it in a topology graph database. This topology is used to deduce that certain problems in the physical layer should cause problems in the virtual layer; to trigger corresponding alarms; to modify (currently only in Vitrage) resources states; and to reflect the causal relationship of the alarms in the cloud. Vitrage development started right after Mitaka Summit, where we had meetings with other OpenStack projects (like Ceilometer/Aodh), presented to them Vitrage ideas, verified that there was no overlap between our projects, and got their blessing. Vitrage follows OpenStack guidelines and “four opens” from day one. Vitrage code and specifications are entirely open source. The project is fully licensed under the Apache 2.0 license, and the project uses public code reviews in gerrit. The code can be found here[2][3][4][5]. Vitrage gate runs docs, pep8, python27, python34 and tempest tests. The #openstack-vitrage IRC channel on freenode is logged [6]. Vitrage team holds weekly IRC meetings on OpenStack official meeting channel, which is logged as well[7]. Openstack-dev mailing list is used to publicly discuss Vitrage related issues. Vitrage wiki page[1] consists of high-level and low-level design documents, presentations and demos. OpenStack launchpad[8] is used to manage blueprints and bugs. We started the process of Newton design discussions right after Austin Summit. We perform these discussions in the IRC meetings, in the mailing list, and in etherpads[9][10] created for this purpose. Vitrage was presented in two sessions in Austin Summit[11][12], as well as in demos in the marketplace. In addition, Aodh-Vitrage integration was discussed in Aodh design session[13][14]. One Aodh fix was already made to enable this integration[15]. Other integrations, with Monasca and Congress, were discussed during the summit, and we are continuing such discussions in the mailing list. In addition to OpenStack community, Vitrage is also involved in OPNFV projects. Vitrage is considered a reference implementation for OPNFV Doctor Inspector component [16][17], as well as for OPNFV PinPoint[18] project. Vitrage is about to be presented, together with OPNFV Doctor and with OpenStack Congress, in OPNFV Summit in Berlin[19]. Vitrage demo is going to be presented in Doctor POC booth. For the past six months, since Vitrage development began, we have been encouraging interaction and cooperation with other projects and contributors in OpenStack. To date, a few companies and projects have worked with us on formulating requirements as well as contributed code. We are working hard at involving additional players in Vitrage, to help drive its feature set so that it supports a wide range of needs from the community. To summarize, Vitrage fills a real need in OpenStack. Vitrage holistic and complete view that includes all of the layers of the cloud, as well as its alarm analysis and correlation, is currently lacking in OpenStack. As Vitrage enhances OpenStack capabilities, raises a lot of interest in the community, and is developed by OpenStack standards, we believe it belongs to the big tent. [1] https://wiki.openstack.org/wiki/Vitrage [2] https://github.com/openstack/vitrage [3] https://github.com/openstack/vitrage-dashboard [4] https://github.com/openstack/python-vitrageclient [5] https://github.com/openstack/vitrage-specs [6] http://eavesdrop.openstack.org/irclogs/%23openstack-vitrage/ [7] http://eavesdrop.openstack.org/meetings/vitrage/ [8] https://launchpad.net/vitrage [9] https://etherpad.openstack.org/p/vitrage-newton-planning [10] https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design [11] https://www.youtube.com/watch?v=9Qw5coTLgMo [12] https://www.youtube.com/watch?v=ey68KNKXc5c [13] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9203 [14] https://etherpad.openstack.org/p/newton-telemetry-vitrage [15] https://review.openstack.org/#/c/314683/ [16] https://wiki.opnfv.org/display/doctor/Doctor+Home [17] https://jira.opnfv.org/browse/DOCTOR-57 [18] https://wiki.opnfv.org/display/pinpoint/Pinpoint+Home [19] https://www.eventscribe.com/2016/OPNFV/aaSearchByDay.asp?h=Full%20Schedule&BCFO=P|G see “Failure Inspection in Doctor using Vitrage and Congress” Change-Id: I47f7302da3d35a4620fc910c38384b4b4c71de7d
2016-05-24 08:03:53 +00:00
irc-channel: openstack-vitrage
service: RCA (Root Cause Analysis) service
mission: >
To organize, analyze and visualize OpenStack alarms & events, yield
insights regarding the root cause of problems and deduce their existence
before they are directly detected.
url: https://wiki.openstack.org/wiki/Vitrage
deliverables:
vitrage:
repos:
- openstack/vitrage
vitrage-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add project Vitrage to OpenStack big-tent This is a request to add the Vitrage project[1] to the Big Tent. Vitrage aims to be the OpenStack RCA (Root Cause Analysis) Engine for organizing, analyzing and expanding OpenStack alarms & events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected. Vitrage provides an holistic and complete view of the cloud, with a clear visualization of the physical-to-virtual (and soon the applicative) layers. Vitrage receives information from various OpenStack data sources (Aodh, Nova, Cinder and Neutron), as well as from external data sources (like Nagios, and in the future Zabbix) and combines it in a topology graph database. This topology is used to deduce that certain problems in the physical layer should cause problems in the virtual layer; to trigger corresponding alarms; to modify (currently only in Vitrage) resources states; and to reflect the causal relationship of the alarms in the cloud. Vitrage development started right after Mitaka Summit, where we had meetings with other OpenStack projects (like Ceilometer/Aodh), presented to them Vitrage ideas, verified that there was no overlap between our projects, and got their blessing. Vitrage follows OpenStack guidelines and “four opens” from day one. Vitrage code and specifications are entirely open source. The project is fully licensed under the Apache 2.0 license, and the project uses public code reviews in gerrit. The code can be found here[2][3][4][5]. Vitrage gate runs docs, pep8, python27, python34 and tempest tests. The #openstack-vitrage IRC channel on freenode is logged [6]. Vitrage team holds weekly IRC meetings on OpenStack official meeting channel, which is logged as well[7]. Openstack-dev mailing list is used to publicly discuss Vitrage related issues. Vitrage wiki page[1] consists of high-level and low-level design documents, presentations and demos. OpenStack launchpad[8] is used to manage blueprints and bugs. We started the process of Newton design discussions right after Austin Summit. We perform these discussions in the IRC meetings, in the mailing list, and in etherpads[9][10] created for this purpose. Vitrage was presented in two sessions in Austin Summit[11][12], as well as in demos in the marketplace. In addition, Aodh-Vitrage integration was discussed in Aodh design session[13][14]. One Aodh fix was already made to enable this integration[15]. Other integrations, with Monasca and Congress, were discussed during the summit, and we are continuing such discussions in the mailing list. In addition to OpenStack community, Vitrage is also involved in OPNFV projects. Vitrage is considered a reference implementation for OPNFV Doctor Inspector component [16][17], as well as for OPNFV PinPoint[18] project. Vitrage is about to be presented, together with OPNFV Doctor and with OpenStack Congress, in OPNFV Summit in Berlin[19]. Vitrage demo is going to be presented in Doctor POC booth. For the past six months, since Vitrage development began, we have been encouraging interaction and cooperation with other projects and contributors in OpenStack. To date, a few companies and projects have worked with us on formulating requirements as well as contributed code. We are working hard at involving additional players in Vitrage, to help drive its feature set so that it supports a wide range of needs from the community. To summarize, Vitrage fills a real need in OpenStack. Vitrage holistic and complete view that includes all of the layers of the cloud, as well as its alarm analysis and correlation, is currently lacking in OpenStack. As Vitrage enhances OpenStack capabilities, raises a lot of interest in the community, and is developed by OpenStack standards, we believe it belongs to the big tent. [1] https://wiki.openstack.org/wiki/Vitrage [2] https://github.com/openstack/vitrage [3] https://github.com/openstack/vitrage-dashboard [4] https://github.com/openstack/python-vitrageclient [5] https://github.com/openstack/vitrage-specs [6] http://eavesdrop.openstack.org/irclogs/%23openstack-vitrage/ [7] http://eavesdrop.openstack.org/meetings/vitrage/ [8] https://launchpad.net/vitrage [9] https://etherpad.openstack.org/p/vitrage-newton-planning [10] https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design [11] https://www.youtube.com/watch?v=9Qw5coTLgMo [12] https://www.youtube.com/watch?v=ey68KNKXc5c [13] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9203 [14] https://etherpad.openstack.org/p/newton-telemetry-vitrage [15] https://review.openstack.org/#/c/314683/ [16] https://wiki.opnfv.org/display/doctor/Doctor+Home [17] https://jira.opnfv.org/browse/DOCTOR-57 [18] https://wiki.opnfv.org/display/pinpoint/Pinpoint+Home [19] https://www.eventscribe.com/2016/OPNFV/aaSearchByDay.asp?h=Full%20Schedule&BCFO=P|G see “Failure Inspection in Doctor using Vitrage and Congress” Change-Id: I47f7302da3d35a4620fc910c38384b4b4c71de7d
2016-05-24 08:03:53 +00:00
repos:
- openstack/vitrage-specs
Add vitrage-tempest-plugin to vitrage project Create a new repository for vitrage's tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: Ifcf71f2991b437530d2e508383b70130db6538bd Change-Id: Icbce511cb3ca3fbc2857dc43d5b09bb749492864
2017-12-09 17:24:38 +05:30
vitrage-tempest-plugin:
repos:
- openstack/vitrage-tempest-plugin
Add project Vitrage to OpenStack big-tent This is a request to add the Vitrage project[1] to the Big Tent. Vitrage aims to be the OpenStack RCA (Root Cause Analysis) Engine for organizing, analyzing and expanding OpenStack alarms & events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected. Vitrage provides an holistic and complete view of the cloud, with a clear visualization of the physical-to-virtual (and soon the applicative) layers. Vitrage receives information from various OpenStack data sources (Aodh, Nova, Cinder and Neutron), as well as from external data sources (like Nagios, and in the future Zabbix) and combines it in a topology graph database. This topology is used to deduce that certain problems in the physical layer should cause problems in the virtual layer; to trigger corresponding alarms; to modify (currently only in Vitrage) resources states; and to reflect the causal relationship of the alarms in the cloud. Vitrage development started right after Mitaka Summit, where we had meetings with other OpenStack projects (like Ceilometer/Aodh), presented to them Vitrage ideas, verified that there was no overlap between our projects, and got their blessing. Vitrage follows OpenStack guidelines and “four opens” from day one. Vitrage code and specifications are entirely open source. The project is fully licensed under the Apache 2.0 license, and the project uses public code reviews in gerrit. The code can be found here[2][3][4][5]. Vitrage gate runs docs, pep8, python27, python34 and tempest tests. The #openstack-vitrage IRC channel on freenode is logged [6]. Vitrage team holds weekly IRC meetings on OpenStack official meeting channel, which is logged as well[7]. Openstack-dev mailing list is used to publicly discuss Vitrage related issues. Vitrage wiki page[1] consists of high-level and low-level design documents, presentations and demos. OpenStack launchpad[8] is used to manage blueprints and bugs. We started the process of Newton design discussions right after Austin Summit. We perform these discussions in the IRC meetings, in the mailing list, and in etherpads[9][10] created for this purpose. Vitrage was presented in two sessions in Austin Summit[11][12], as well as in demos in the marketplace. In addition, Aodh-Vitrage integration was discussed in Aodh design session[13][14]. One Aodh fix was already made to enable this integration[15]. Other integrations, with Monasca and Congress, were discussed during the summit, and we are continuing such discussions in the mailing list. In addition to OpenStack community, Vitrage is also involved in OPNFV projects. Vitrage is considered a reference implementation for OPNFV Doctor Inspector component [16][17], as well as for OPNFV PinPoint[18] project. Vitrage is about to be presented, together with OPNFV Doctor and with OpenStack Congress, in OPNFV Summit in Berlin[19]. Vitrage demo is going to be presented in Doctor POC booth. For the past six months, since Vitrage development began, we have been encouraging interaction and cooperation with other projects and contributors in OpenStack. To date, a few companies and projects have worked with us on formulating requirements as well as contributed code. We are working hard at involving additional players in Vitrage, to help drive its feature set so that it supports a wide range of needs from the community. To summarize, Vitrage fills a real need in OpenStack. Vitrage holistic and complete view that includes all of the layers of the cloud, as well as its alarm analysis and correlation, is currently lacking in OpenStack. As Vitrage enhances OpenStack capabilities, raises a lot of interest in the community, and is developed by OpenStack standards, we believe it belongs to the big tent. [1] https://wiki.openstack.org/wiki/Vitrage [2] https://github.com/openstack/vitrage [3] https://github.com/openstack/vitrage-dashboard [4] https://github.com/openstack/python-vitrageclient [5] https://github.com/openstack/vitrage-specs [6] http://eavesdrop.openstack.org/irclogs/%23openstack-vitrage/ [7] http://eavesdrop.openstack.org/meetings/vitrage/ [8] https://launchpad.net/vitrage [9] https://etherpad.openstack.org/p/vitrage-newton-planning [10] https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design [11] https://www.youtube.com/watch?v=9Qw5coTLgMo [12] https://www.youtube.com/watch?v=ey68KNKXc5c [13] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9203 [14] https://etherpad.openstack.org/p/newton-telemetry-vitrage [15] https://review.openstack.org/#/c/314683/ [16] https://wiki.opnfv.org/display/doctor/Doctor+Home [17] https://jira.opnfv.org/browse/DOCTOR-57 [18] https://wiki.opnfv.org/display/pinpoint/Pinpoint+Home [19] https://www.eventscribe.com/2016/OPNFV/aaSearchByDay.asp?h=Full%20Schedule&BCFO=P|G see “Failure Inspection in Doctor using Vitrage and Congress” Change-Id: I47f7302da3d35a4620fc910c38384b4b4c71de7d
2016-05-24 08:03:53 +00:00
python-vitrageclient:
repos:
- openstack/python-vitrageclient
vitrage-dashboard:
repos:
- openstack/vitrage-dashboard
Add xstatic-* projects for vitrage-dashboard Current vitrage-dashboard repo has multiple embedded js copies. However these embeded js copies are not allowed by Horizon's official contributor guide. This change aimes to make these js copies to xstatic packages which can be installed by pip and remove all of embedded js copies from vitrage-dashboard repo. Projects: - xstatic-dagre - xstatic-dagre-d3 - xstatic-graphlib - xstatic-lodash - xstatic-moment - xstatic-moment-timezone Change-Id: Ic5506ed6831454b222984f859f829de3cdd6f95c Depends-On: I92fef30261a4c17523682fe9c9b3483a759cf500
2020-02-21 19:22:56 +01:00
xstatic-dagre:
repos:
- openstack/xstatic-dagre
xstatic-dagre-d3:
repos:
- openstack/xstatic-dagre-d3
xstatic-graphlib:
repos:
- openstack/xstatic-graphlib
xstatic-lodash:
repos:
- openstack/xstatic-lodash
xstatic-moment:
repos:
- openstack/xstatic-moment
xstatic-moment-timezone:
repos:
- openstack/xstatic-moment-timezone
Add project Watcher to OpenStack big-tent Mission Alignment: Watcher's goal is to provide a flexible and scalable resource optimization service for multi-tenant OpenStack-based clouds. Watcher does this with a robust framework that can be configured to achieve a wide range of cloud optimization goals, including the reduction of data center operating costs, increased system performance via intelligent virtual machine migration, increased energy efficiency — and more! Watcher builds an extensible platform for advanced optimization services that can be used by operators to reduce the TCO of their infrastructure. The Watcher project maintains a core team for both code and specs that approves all changes. The Watcher API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Watcher uses Telemetry as the default backend for metrics collection and plans to integrate Monasca during the Newton cycle. An integration with Congress is currently under discussion [4]. Currently, the Watcher PTL is Antoine Cabot (acabot). Regular elections are held to elect new PTLs and core members. Watcher was initially discussed at the Vancouver Summit. The first Watcher mid-cycle meetup was held in January 2016, which three companies attended [6]. Watcher has an extensive set of documentation. Overall documentation and links to documentation are at the Watcher Wiki [7]. The Watcher API is documented [8]. Watcher provides a turn-key development environment based on Devstack [9]. Watcher is continually deployed to test and production environments off of master branch and maintains a very high level of quality. Following the 4 opens : Open Source: Watcher is 100% open source under an Apache 2.0 license, everything from implementation to design to future features and roadmap are happening and shared openly and presented in various meetups and documents. Open Community: We are working closely with the community to share use cases and problems and decide on future priorites for the project. We welcome any feedback and any desire to help us shape Watcher future by others. Open Development: All Watcher code and specs are being reviewed in OpenStack CI [1] [2]. Watcher has a core team which openly discuss all issues. Watcher support gate tests which run unit tests/fullstack/tempest and Rally tests. Bugs are managed by OpenStack launchpad [3]. Open Design: All designs and specs are published for review and managed in OpenStack launchpad [3]. Watcher conducts a weekly IRC meeting to discuss all designs and future roadmap [5]. Watcher repository consists of many documentation and diagrams explaining the current design and code and also future roadmap and ideas. Everything is discussed openly on the Watcher IRC channel (which is logged [10]) or the ML. [1] https://review.openstack.org/#/q/project:openstack/watcher [2] https://review.openstack.org/#/q/project:openstack/watcher-specs [3] https://launchpad.net/watcher [4] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093826.html [5] http://eavesdrop.openstack.org/meetings/watcher/ [6] https://etherpad.openstack.org/p/mitaka-watcher-midcycle [7] https://wiki.openstack.org/wiki/Watcher [8] http://factory.b-com.com/www/watcher/doc/watcher/webapi/v1.html [9] http://factory.b-com.com/www/watcher/doc/watcher/dev/devstack.html [10] http://eavesdrop.openstack.org/irclogs/%23openstack-watcher/ Change-Id: Ia948b4532748928134eb2cba3046dae498f4d206
2016-05-25 14:11:05 +02:00
watcher:
Adopt DPL model for watcher 2025.2 This change updates the liaison list and reselects the distributed leadership type Change-Id: I00e0e421d92df4db9b3e6382c761e20083330a2b
2025-01-24 19:32:22 +00:00
leadership_type: distributed
liaisons:
release:
- name: Sean Mooney
irc: sean-k-mooney
email: smooney@redhat.com
tact-sig:
- name: Marios Andreou
irc: marios
email: marios@redhat.com
- name: Chandan Kumar
irc: chandankumar
email: chkumar@redhat.com
security:
- name: Dan Smith
irc: dansmith
email: danms@danplanet.com
tc-liaison:
- name: Ghanshyam Mann
irc: gmann
email: gmann@ghanshyammann.com
Add project Watcher to OpenStack big-tent Mission Alignment: Watcher's goal is to provide a flexible and scalable resource optimization service for multi-tenant OpenStack-based clouds. Watcher does this with a robust framework that can be configured to achieve a wide range of cloud optimization goals, including the reduction of data center operating costs, increased system performance via intelligent virtual machine migration, increased energy efficiency — and more! Watcher builds an extensible platform for advanced optimization services that can be used by operators to reduce the TCO of their infrastructure. The Watcher project maintains a core team for both code and specs that approves all changes. The Watcher API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Watcher uses Telemetry as the default backend for metrics collection and plans to integrate Monasca during the Newton cycle. An integration with Congress is currently under discussion [4]. Currently, the Watcher PTL is Antoine Cabot (acabot). Regular elections are held to elect new PTLs and core members. Watcher was initially discussed at the Vancouver Summit. The first Watcher mid-cycle meetup was held in January 2016, which three companies attended [6]. Watcher has an extensive set of documentation. Overall documentation and links to documentation are at the Watcher Wiki [7]. The Watcher API is documented [8]. Watcher provides a turn-key development environment based on Devstack [9]. Watcher is continually deployed to test and production environments off of master branch and maintains a very high level of quality. Following the 4 opens : Open Source: Watcher is 100% open source under an Apache 2.0 license, everything from implementation to design to future features and roadmap are happening and shared openly and presented in various meetups and documents. Open Community: We are working closely with the community to share use cases and problems and decide on future priorites for the project. We welcome any feedback and any desire to help us shape Watcher future by others. Open Development: All Watcher code and specs are being reviewed in OpenStack CI [1] [2]. Watcher has a core team which openly discuss all issues. Watcher support gate tests which run unit tests/fullstack/tempest and Rally tests. Bugs are managed by OpenStack launchpad [3]. Open Design: All designs and specs are published for review and managed in OpenStack launchpad [3]. Watcher conducts a weekly IRC meeting to discuss all designs and future roadmap [5]. Watcher repository consists of many documentation and diagrams explaining the current design and code and also future roadmap and ideas. Everything is discussed openly on the Watcher IRC channel (which is logged [10]) or the ML. [1] https://review.openstack.org/#/q/project:openstack/watcher [2] https://review.openstack.org/#/q/project:openstack/watcher-specs [3] https://launchpad.net/watcher [4] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093826.html [5] http://eavesdrop.openstack.org/meetings/watcher/ [6] https://etherpad.openstack.org/p/mitaka-watcher-midcycle [7] https://wiki.openstack.org/wiki/Watcher [8] http://factory.b-com.com/www/watcher/doc/watcher/webapi/v1.html [9] http://factory.b-com.com/www/watcher/doc/watcher/dev/devstack.html [10] http://eavesdrop.openstack.org/irclogs/%23openstack-watcher/ Change-Id: Ia948b4532748928134eb2cba3046dae498f4d206
2016-05-25 14:11:05 +02:00
irc-channel: openstack-watcher
service: Infrastructure Optimization service
mission: >
Watcher's goal is to provide a flexible and scalable resource optimization
service for multi-tenant OpenStack-based clouds.
url: https://wiki.openstack.org/wiki/Watcher
deliverables:
watcher:
repos:
- openstack/watcher
watcher-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Add project Watcher to OpenStack big-tent Mission Alignment: Watcher's goal is to provide a flexible and scalable resource optimization service for multi-tenant OpenStack-based clouds. Watcher does this with a robust framework that can be configured to achieve a wide range of cloud optimization goals, including the reduction of data center operating costs, increased system performance via intelligent virtual machine migration, increased energy efficiency — and more! Watcher builds an extensible platform for advanced optimization services that can be used by operators to reduce the TCO of their infrastructure. The Watcher project maintains a core team for both code and specs that approves all changes. The Watcher API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Watcher uses Telemetry as the default backend for metrics collection and plans to integrate Monasca during the Newton cycle. An integration with Congress is currently under discussion [4]. Currently, the Watcher PTL is Antoine Cabot (acabot). Regular elections are held to elect new PTLs and core members. Watcher was initially discussed at the Vancouver Summit. The first Watcher mid-cycle meetup was held in January 2016, which three companies attended [6]. Watcher has an extensive set of documentation. Overall documentation and links to documentation are at the Watcher Wiki [7]. The Watcher API is documented [8]. Watcher provides a turn-key development environment based on Devstack [9]. Watcher is continually deployed to test and production environments off of master branch and maintains a very high level of quality. Following the 4 opens : Open Source: Watcher is 100% open source under an Apache 2.0 license, everything from implementation to design to future features and roadmap are happening and shared openly and presented in various meetups and documents. Open Community: We are working closely with the community to share use cases and problems and decide on future priorites for the project. We welcome any feedback and any desire to help us shape Watcher future by others. Open Development: All Watcher code and specs are being reviewed in OpenStack CI [1] [2]. Watcher has a core team which openly discuss all issues. Watcher support gate tests which run unit tests/fullstack/tempest and Rally tests. Bugs are managed by OpenStack launchpad [3]. Open Design: All designs and specs are published for review and managed in OpenStack launchpad [3]. Watcher conducts a weekly IRC meeting to discuss all designs and future roadmap [5]. Watcher repository consists of many documentation and diagrams explaining the current design and code and also future roadmap and ideas. Everything is discussed openly on the Watcher IRC channel (which is logged [10]) or the ML. [1] https://review.openstack.org/#/q/project:openstack/watcher [2] https://review.openstack.org/#/q/project:openstack/watcher-specs [3] https://launchpad.net/watcher [4] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093826.html [5] http://eavesdrop.openstack.org/meetings/watcher/ [6] https://etherpad.openstack.org/p/mitaka-watcher-midcycle [7] https://wiki.openstack.org/wiki/Watcher [8] http://factory.b-com.com/www/watcher/doc/watcher/webapi/v1.html [9] http://factory.b-com.com/www/watcher/doc/watcher/dev/devstack.html [10] http://eavesdrop.openstack.org/irclogs/%23openstack-watcher/ Change-Id: Ia948b4532748928134eb2cba3046dae498f4d206
2016-05-25 14:11:05 +02:00
repos:
- openstack/watcher-specs
Add watcher-tempest-plugin to watcher project Create new repository for watcher's tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: I0f227f3b6317b44e2299b3ccbd26e29679f401e9 Change-Id: I4acb68a5f46f1d12b1e74d2203ff61357460eab7
2017-08-01 13:51:16 +03:00
watcher-tempest-plugin:
repos:
- openstack/watcher-tempest-plugin
Add project Watcher to OpenStack big-tent Mission Alignment: Watcher's goal is to provide a flexible and scalable resource optimization service for multi-tenant OpenStack-based clouds. Watcher does this with a robust framework that can be configured to achieve a wide range of cloud optimization goals, including the reduction of data center operating costs, increased system performance via intelligent virtual machine migration, increased energy efficiency — and more! Watcher builds an extensible platform for advanced optimization services that can be used by operators to reduce the TCO of their infrastructure. The Watcher project maintains a core team for both code and specs that approves all changes. The Watcher API uses Keystone for authentication and multi-tenancy. Oslo libraries are used by all components where applicable. Watcher uses Telemetry as the default backend for metrics collection and plans to integrate Monasca during the Newton cycle. An integration with Congress is currently under discussion [4]. Currently, the Watcher PTL is Antoine Cabot (acabot). Regular elections are held to elect new PTLs and core members. Watcher was initially discussed at the Vancouver Summit. The first Watcher mid-cycle meetup was held in January 2016, which three companies attended [6]. Watcher has an extensive set of documentation. Overall documentation and links to documentation are at the Watcher Wiki [7]. The Watcher API is documented [8]. Watcher provides a turn-key development environment based on Devstack [9]. Watcher is continually deployed to test and production environments off of master branch and maintains a very high level of quality. Following the 4 opens : Open Source: Watcher is 100% open source under an Apache 2.0 license, everything from implementation to design to future features and roadmap are happening and shared openly and presented in various meetups and documents. Open Community: We are working closely with the community to share use cases and problems and decide on future priorites for the project. We welcome any feedback and any desire to help us shape Watcher future by others. Open Development: All Watcher code and specs are being reviewed in OpenStack CI [1] [2]. Watcher has a core team which openly discuss all issues. Watcher support gate tests which run unit tests/fullstack/tempest and Rally tests. Bugs are managed by OpenStack launchpad [3]. Open Design: All designs and specs are published for review and managed in OpenStack launchpad [3]. Watcher conducts a weekly IRC meeting to discuss all designs and future roadmap [5]. Watcher repository consists of many documentation and diagrams explaining the current design and code and also future roadmap and ideas. Everything is discussed openly on the Watcher IRC channel (which is logged [10]) or the ML. [1] https://review.openstack.org/#/q/project:openstack/watcher [2] https://review.openstack.org/#/q/project:openstack/watcher-specs [3] https://launchpad.net/watcher [4] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093826.html [5] http://eavesdrop.openstack.org/meetings/watcher/ [6] https://etherpad.openstack.org/p/mitaka-watcher-midcycle [7] https://wiki.openstack.org/wiki/Watcher [8] http://factory.b-com.com/www/watcher/doc/watcher/webapi/v1.html [9] http://factory.b-com.com/www/watcher/doc/watcher/dev/devstack.html [10] http://eavesdrop.openstack.org/irclogs/%23openstack-watcher/ Change-Id: Ia948b4532748928134eb2cba3046dae498f4d206
2016-05-25 14:11:05 +02:00
python-watcherclient:
repos:
- openstack/python-watcherclient
watcher-dashboard:
repos:
- openstack/watcher-dashboard
Applies project team name capitalization guidelines - In some cases, left capitalization, please check against guidelines at http://governance.openstack.org/reference/service-project-naming.html Change-Id: I20b32c03799f3a246f01d22dafcaf09ad11a2357
2015-09-02 10:47:14 -05:00
zaqar:
change projects schema to support more ptl contact data Change-Id: I3e8c9eebd9b6c506f84bdad4fe9e7c010d0fe344
2015-10-13 20:05:21 +00:00
ptl:
Close Antelope Elections Reflects election result to governance repo : https://review.opendev.org/c/openstack/election/+/858532 Change-Id: Ic4f80855d784f9bf104f0f982fc8f265544d961f
2022-09-20 23:24:42 +09:00
name: Hao Wang
Update with 2023.2 Election results. Updates PTLs and TC members as per: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032240.html Also removes chair and vice-chair roles as this is a new TC Change-Id: I2aef6f364afeecc8bd48ce5e9fa64457c582b610
2023-02-16 11:16:15 +11:00
irc: wanghao
Appoint Wang as Zaqar PTL Wang raised the late candidacy for the Zaqar Zed cycle PTL - https://review.opendev.org/c/openstack/election/+/830106 - https://etherpad.opendev.org/p/zed-leaderless Change-Id: Ie4db1cbd39ebe76e6d5b488d7c6c49cc427a4ce9
2022-02-27 19:04:43 -06:00
email: sxmatch1986@gmail.com
Appoint Weng Hao as Zaqar PTL Zaqar did not have any PTL candidate in the required candidacy timeframe and as a result has triggered the leaderless team process. The PTL for the Stein cycle, Weng Hao, sent an email explaining that he missed the deadline and would like to continue as Zaqar PTL: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003760.html Change-Id: I0aa268c9cf9b5a43f9b77c218a1658aa29b781b3
2019-03-21 11:44:35 +01:00
appointed:
- train
Appoint wang hao as Zaqar PTL Wang confirmed to serve as Zaqar PTL. Change-Id: I1b0aad1bdb93cb348852c380a64b330e7fdcd14c
2020-04-03 12:07:57 -05:00
- victoria
Appoint Hao Wang as Zaqar PTL Hao Wang sent their late candidacy for Zaqar PTL position of Xena Cycle - https://review.opendev.org/c/openstack/election/+/780150 Change-Id: Iae2a1382e9932d55dcb1d2be5c917d80f2fab96d
2021-03-12 09:18:59 -06:00
- xena
Appoint Wang as Zaqar PTL Wang raised the late candidacy for the Zaqar Zed cycle PTL - https://review.opendev.org/c/openstack/election/+/830106 - https://etherpad.opendev.org/p/zed-leaderless Change-Id: Ie4db1cbd39ebe76e6d5b488d7c6c49cc427a4ce9
2022-02-27 19:04:43 -06:00
- zed
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
irc-channel: openstack-zaqar
service: Message service
RPM distribution packaging of OpenStack Host all packaging git repos for rpm based distributions in the /openstack namespace in order to have gating and review of changes to the packaging close to the actual OpenStack development. Change-Id: I608651414fadc0206910d2720d8d14be51a5c8af
2015-06-14 22:59:03 +02:00
mission: >
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
To produce an OpenStack messaging service that affords a
variety of distributed application patterns in an efficient,
scalable and highly-available manner, and to create and maintain
associated Python libraries and documentation.
url: https://wiki.openstack.org/wiki/Zaqar
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
deliverables:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
python-zaqarclient:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/python-zaqarclient
zaqar:
Introduce the "deliverables" concept Our current projects.yaml file lists project teams and git repositories associated to those. However, things we publish as a single "thing" may be represented by multiple code repositories. For example, a "neutron" release is actually made of openstack/neutron and openstack/neutron-*aas. A "sahara" release is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those are all tagged at the same time with the same version number, and published together as a single "deliverable". This change proposes to encode this layer in the projects.yaml file. It also proposes to apply tags to the deliverable level rather than at git repository level. Tags are meant to apply to things that are consumed by our users, not to the technical pieces that help us build those things. Note that for most projects have single-repo deliverables and won't really look different. See Sahara and Neutron in the proposed file to see examples of multi-repo deliverables. Since this introduces a breaking change in the file format, we also take the opportunity to simplify the YAML format: since tags no longer have attributes they can be listed as an array rather than as a dictionary, sparing us the useless "name:" part. Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
2015-07-16 15:57:12 +02:00
repos:
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
- openstack/zaqar
zaqar-specs:
Indicate relmgt style for each deliverable The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, this change introduces a "release-management:" key to the deliverable entries. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. But the key could also contain: - release-management: none (the deliverable does not need any release management, it does not use tags or series branches) - release-management: external (the deliverable is published on a separate publication platform, and its release is managed by its project team directly; this should be limited to corner cases like deployment tools) This change applies the key to already-known exceptions. Change-Id: I8ffe1de25cc3252a2d9e6acb21f24934c313cfcb Task: 22262
2018-10-25 12:39:22 +02:00
release-management: none
Reorder file alphabetically Since we generate a giant merge conflict with the introduction of "deliverables" in the previous commit, take the opportunity to reorder the file alphabetically. This will reduce future conflicts when new projects add themselves at the end of the file. Change-Id: I762d2874a8cb6e809b0d07452cbbd5e858eec67c
2015-07-28 12:11:57 +02:00
repos:
- openstack/zaqar-specs
Add zaqar-tempest-plugin to zaqar project Create a new repository for zaqar's tempest plugin to fulfill Queens Goal "Split Tempest Plugins into Separate Repos/Projects". Depends-On: I992848bc584a6522babb1e190a0ad52eaf3dd5ee Change-Id: I208f7e10b689d7bd71cc8c2d47ed01b858b17338
2017-09-06 21:41:01 +05:30
zaqar-tempest-plugin:
repos:
- openstack/zaqar-tempest-plugin
Add zaqar-ui to openstack namespace in the Zaqar project Depends-On: I7a26537b93f7563c37a5a0de95258ec1224a44c6 Change-Id: Ie327157a7c66ecadfac1865098bdc49e4626ef85
2015-11-24 06:58:45 +13:00
zaqar-ui:
repos:
- openstack/zaqar-ui
Add project Zun to OpenStack big-tent Addition of the Zun Project - a collaboration of 22 engineers from 12 affiliations [1] to bring prevailing container technologies to Openstack. Zun was originated from Magnum, but became an independent project based on the decision made by the community in the OpenStack Austin design summit [2]. After the split, Zun focuses on providing container service for OpenStack, while Magnum focus on deployment and management of Container Orchestration Engines (COEs). Zun aligns with the OpenStack Mission by providing an OpenStack-native container service backed by various container technologies. Zun directly builds on existing OpenStack services, such as Nova, Neutron, Glance, Keystone, Horizon, and potentially more. Zun uses the Apache v2.0 license. All library dependencies allow for unrestricted distribution and deployment. Our PTL is chosen by our contributors [3], and holds weekly IRC meetings in #openstack-meeting and are logged [4][5]. We are also available in #openstack-zun to for daily discussion and as a way for users to interact with our developers openly. Zun provides a level and open collaboration playing field because it doesn't benefit a specific vendor or contributors from a specific vendor. Zun uses Gerrit for code reviews [6][7][8], and Launchpad [9][10] for bugs and blueprints tracking. Our code is automatically tested by the OpenStack CI infrastructure. Our PTL serves as a contact for cross-project teams in OpenStack. We make extensive use of existing software, and have not deliberately reproduced functionality that already exists in other ecosystem projects. Zun doesn't compete with COEs, such as Swarm, Mesos, or Kubernetes, but instead offers a pluggable architecture for vendors to plugin COEs of their choice. We are open to integrate prevailing container technologies that help OpenStack operators offer application containers to their cloud users. Project direction has been publicly discussed at the Austin and Barcelona OpenStack Design Summit, and in the weekly IRC meetings. We also use the openstack-dev ML for project discussion. Zun is compatible with OpenStack APIs, and uses Keystone middleware to integrate with OpenStack Identity. There are numerous active contributors from several affiliations who have significant contribution to Zun. The Zun team is happy to participate in any goals specified by the TC, and meet any policies that the TC requires all projects to meet. [1] http://stackalytics.com/?project_type=openstack-others&release=all&metric=commits&module=zun [2] https://etherpad.openstack.org/p/newton-magnum-unified-abstraction [3] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107887.html [4] http://eavesdrop.openstack.org/meetings/zun/2016/ [5] http://eavesdrop.openstack.org/meetings/higgins/2016/ [6] https://review.openstack.org/#/q/project:openstack/zun [7] https://review.openstack.org/#/q/project:openstack/python-zunclient [8] https://review.openstack.org/#/q/project:openstack/zun-ui [9] https://launchpad.net/zun [10] https://launchpad.net/zun-ui Change-Id: I9c75496f7b40d3fb78e8c4c92e6bfc2bc161e52f
2016-11-24 16:07:49 -06:00
zun:
ptl:
Appoint hongbin as Zun PTL hongbin volunteer to lead the Zun project for the 2023.1 cycle - https://review.opendev.org/c/openstack/governance/+/858980 Change-Id: Ic38ac5bd82203efa0e32171058a0508a4e3509c6
2022-10-07 19:55:34 -05:00
name: Hongbin Lu
Add PTL results from the 2024.2/Dalmatian election Depends-On: If6c157efebc58d1fbe32a61a64f209b4102ac5c8 Change-Id: Ic74bfc853d2d9d045d4c589e1fd6c50afa608423
2024-03-22 09:00:21 +09:00
irc: No nick supplied
Appoint hongbin as Zun PTL hongbin volunteer to lead the Zun project for the 2023.1 cycle - https://review.opendev.org/c/openstack/governance/+/858980 Change-Id: Ic38ac5bd82203efa0e32171058a0508a4e3509c6
2022-10-07 19:55:34 -05:00
email: hongbin034@gmail.com
Appoint Shengqin Feng as Zun PTL Shengqin Feng sent email about their late candidacy for Zun PTL position of Xena Cycle - http://lists.openstack.org/pipermail/openstack-discuss/2021-March/020998.html Change-Id: I55c67f9c14a744bf258221f47d91f5aac8afef02
2021-03-11 13:08:39 -06:00
appointed:
- xena
Appoint FengShengqin as Zun PTL FengShengqin raised candidacy to server as Zun PTL position for Yoga Cycle but that was not valid as per the current requirements. - https://review.opendev.org/c/openstack/election/+/805380 - https://etherpad.opendev.org/p/yoga-leaderless Change-Id: I563794e3834f1af90d1e24f4b94fa12f28fd2cef
2021-09-08 10:08:43 -05:00
- yoga
Appoint FengShengqin as Zun PTL FengShengqin raised candidacy as Zun PTL position for Zed Cycle but that was not valid as per the current requirements. - https://review.opendev.org/c/openstack/election/+/828402 - https://etherpad.opendev.org/p/zed-leaderless Change-Id: I92c2f00edf1f400590253cce8d3a599e544dc009
2022-02-27 17:48:23 -06:00
- zed
Consider release version as string in projects data We need to use the release version as string, so updating the PTL 'appointment' field and the data in projects.yaml Change-Id: Ib097517f514e68246fb6e27b83e98a1f3f6b8eed
2023-03-10 18:14:20 -06:00
- '2023.1'
Add project Zun to OpenStack big-tent Addition of the Zun Project - a collaboration of 22 engineers from 12 affiliations [1] to bring prevailing container technologies to Openstack. Zun was originated from Magnum, but became an independent project based on the decision made by the community in the OpenStack Austin design summit [2]. After the split, Zun focuses on providing container service for OpenStack, while Magnum focus on deployment and management of Container Orchestration Engines (COEs). Zun aligns with the OpenStack Mission by providing an OpenStack-native container service backed by various container technologies. Zun directly builds on existing OpenStack services, such as Nova, Neutron, Glance, Keystone, Horizon, and potentially more. Zun uses the Apache v2.0 license. All library dependencies allow for unrestricted distribution and deployment. Our PTL is chosen by our contributors [3], and holds weekly IRC meetings in #openstack-meeting and are logged [4][5]. We are also available in #openstack-zun to for daily discussion and as a way for users to interact with our developers openly. Zun provides a level and open collaboration playing field because it doesn't benefit a specific vendor or contributors from a specific vendor. Zun uses Gerrit for code reviews [6][7][8], and Launchpad [9][10] for bugs and blueprints tracking. Our code is automatically tested by the OpenStack CI infrastructure. Our PTL serves as a contact for cross-project teams in OpenStack. We make extensive use of existing software, and have not deliberately reproduced functionality that already exists in other ecosystem projects. Zun doesn't compete with COEs, such as Swarm, Mesos, or Kubernetes, but instead offers a pluggable architecture for vendors to plugin COEs of their choice. We are open to integrate prevailing container technologies that help OpenStack operators offer application containers to their cloud users. Project direction has been publicly discussed at the Austin and Barcelona OpenStack Design Summit, and in the weekly IRC meetings. We also use the openstack-dev ML for project discussion. Zun is compatible with OpenStack APIs, and uses Keystone middleware to integrate with OpenStack Identity. There are numerous active contributors from several affiliations who have significant contribution to Zun. The Zun team is happy to participate in any goals specified by the TC, and meet any policies that the TC requires all projects to meet. [1] http://stackalytics.com/?project_type=openstack-others&release=all&metric=commits&module=zun [2] https://etherpad.openstack.org/p/newton-magnum-unified-abstraction [3] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107887.html [4] http://eavesdrop.openstack.org/meetings/zun/2016/ [5] http://eavesdrop.openstack.org/meetings/higgins/2016/ [6] https://review.openstack.org/#/q/project:openstack/zun [7] https://review.openstack.org/#/q/project:openstack/python-zunclient [8] https://review.openstack.org/#/q/project:openstack/zun-ui [9] https://launchpad.net/zun [10] https://launchpad.net/zun-ui Change-Id: I9c75496f7b40d3fb78e8c4c92e6bfc2bc161e52f
2016-11-24 16:07:49 -06:00
irc-channel: openstack-zun
service: Containers service
mission: >
To provide an OpenStack containers service that integrates with various
container technologies for managing application containers on OpenStack.
url: https://wiki.openstack.org/wiki/Zun
deliverables:
python-zunclient:
repos:
- openstack/python-zunclient
zun:
repos:
- openstack/zun
Add zun-tempest-plugin repository to Zun project Change-Id: Ib079f7e84afb998d521b01e6ee3ad6b828b8c3f8 Depends-On: Ic7f4af2904a04116c4bbe8d401d74e5068646855
2017-09-06 11:29:03 -04:00
zun-tempest-plugin:
repos:
- openstack/zun-tempest-plugin
Add project Zun to OpenStack big-tent Addition of the Zun Project - a collaboration of 22 engineers from 12 affiliations [1] to bring prevailing container technologies to Openstack. Zun was originated from Magnum, but became an independent project based on the decision made by the community in the OpenStack Austin design summit [2]. After the split, Zun focuses on providing container service for OpenStack, while Magnum focus on deployment and management of Container Orchestration Engines (COEs). Zun aligns with the OpenStack Mission by providing an OpenStack-native container service backed by various container technologies. Zun directly builds on existing OpenStack services, such as Nova, Neutron, Glance, Keystone, Horizon, and potentially more. Zun uses the Apache v2.0 license. All library dependencies allow for unrestricted distribution and deployment. Our PTL is chosen by our contributors [3], and holds weekly IRC meetings in #openstack-meeting and are logged [4][5]. We are also available in #openstack-zun to for daily discussion and as a way for users to interact with our developers openly. Zun provides a level and open collaboration playing field because it doesn't benefit a specific vendor or contributors from a specific vendor. Zun uses Gerrit for code reviews [6][7][8], and Launchpad [9][10] for bugs and blueprints tracking. Our code is automatically tested by the OpenStack CI infrastructure. Our PTL serves as a contact for cross-project teams in OpenStack. We make extensive use of existing software, and have not deliberately reproduced functionality that already exists in other ecosystem projects. Zun doesn't compete with COEs, such as Swarm, Mesos, or Kubernetes, but instead offers a pluggable architecture for vendors to plugin COEs of their choice. We are open to integrate prevailing container technologies that help OpenStack operators offer application containers to their cloud users. Project direction has been publicly discussed at the Austin and Barcelona OpenStack Design Summit, and in the weekly IRC meetings. We also use the openstack-dev ML for project discussion. Zun is compatible with OpenStack APIs, and uses Keystone middleware to integrate with OpenStack Identity. There are numerous active contributors from several affiliations who have significant contribution to Zun. The Zun team is happy to participate in any goals specified by the TC, and meet any policies that the TC requires all projects to meet. [1] http://stackalytics.com/?project_type=openstack-others&release=all&metric=commits&module=zun [2] https://etherpad.openstack.org/p/newton-magnum-unified-abstraction [3] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107887.html [4] http://eavesdrop.openstack.org/meetings/zun/2016/ [5] http://eavesdrop.openstack.org/meetings/higgins/2016/ [6] https://review.openstack.org/#/q/project:openstack/zun [7] https://review.openstack.org/#/q/project:openstack/python-zunclient [8] https://review.openstack.org/#/q/project:openstack/zun-ui [9] https://launchpad.net/zun [10] https://launchpad.net/zun-ui Change-Id: I9c75496f7b40d3fb78e8c4c92e6bfc2bc161e52f
2016-11-24 16:07:49 -06:00
zun-ui:
repos:
- openstack/zun-ui
Move openstack/kuryr and openstack/kuryr-libnetwork to Zun Kuryr is going to become unmaintained but kuryr-libnetwork is a hard dependency for Zun. Change-Id: I6230bbe3906e8250ef30e848fe1197278afbdc39
2024-04-30 03:53:39 +00:00
kuryr:
repos:
- openstack/kuryr
kuryr-libnetwork:
repos:
- openstack/kuryr-libnetwork
Copy Permalink