OpenStack - User contributions [en]

CrossProjectLiaisons

2016-03-31T18:18:59Z

Xarses:

Many of our cross-project teams need focused help for communicating with the other project teams. This page lists the people who have volunteered for that work.

== Oslo ==

There are now more projects consuming code from the Oslo incubator than we have Oslo contributors. That means we are going to need your help to make these migrations happen. We are asking for one person from each project to serve as a liaison between the project and Oslo, and to assist with integrating changes as we move code out of the incubator into libraries.

* The liaison should be active in the project and familiar with the project-specific requirements for having patches accepted, but does not need to be a core reviewer or the PTL.
* The liaison should be prepared to assist with writing and reviewing patches in their project as libraries are adopted, and with discussions of API changes to the libraries to make them easier to use within the project.
* Liaisons should pay attention to [Oslo] tagged messages on the openstack-dev mailing list.
* It is also useful for liaisons to be able to attend the Oslo team meeting ([[Meetings/Oslo]]) to participate in discussions and raise issues for real-time discussion.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || Douglas Mendizábal || redrobot
|-
| Ceilometer || Julien Danjou || jd__
|-
| Cinder || Jay Bryant || jungleboyj
|-
| Congress || Tim Hinrichs || thinrichs
|-
| Cue || Min Pae || sputnik13
|-
| Designate || ||
|-
| Glance || Flavio Percoco || flaper87
|-
| Heat || Thomas Herve || therve
|-
| Horizon || Kirill Zaitsev || kzaitsev_
|-
| Ironic || Lin Tan || lintan
|-
| Keystone || Brant Knudson || bknudson
|-
| Manila || Thomas Bechtold || toabctl
|-
| Murano || Kirill Zaitsev || kzaitsev_
|-
| Neutron || Ihar Hrachyshka || ihrachyshka
|-
| Nova || ChangBo Guo <glongwave@gmail.com> || gcb
|-
| [[Octavia]] || Michael Johnson || johnsom
|-
| Sahara || Andrey Pavlov || AndreyPavlov
|-
| Senlin || Yanyan Hu || Yanyanhu
|-

| Swift || ||
|-
| TripleO || Ben Nemec || bnemec
|-
| Trove || Amrith Kumar || amrith
|-
| Zaqar || Flavio Percoco || flaper87
|-
|}

== Release management ==

The Release Management Liaison is responsible for communication with the Release Management team, attending the weekly 1:1 syncs in #openstack-relmgr-office, keeping milestone plans up to date, and signing off milestone and release tags. That task has been [[PTL_Guide#Interactions_with_the_Release_team|traditionally filled by the PTL]], but they may now delegate this task if they wish.

* By default, the liaison will be the PTL.
* The Release Management Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL.
* The liaison may further delegate work to other subject matter experts

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || Douglas Mendizábal || redrobot
|-
| Ceilometer || gordon chung || gordc
|-
| Cinder || Sean McGinnis || smcginnis
|-
| Congress || Tim Hinrichs || thinrichs
|-
| Designate || Graham Hayes || mugsie
|-
| Glance || Flavio Percoco || flaper87
|-
| Heat || Sergey Kraynev || skraynev
|-
| Horizon || David Lyle || david-lyle
|-
| Ironic || Jim Rollenhagen || jroll
|-
| Keystone || Steve Martinelli || stevemar
|-
| Manila || Ben Swartzlander || bswartz
|-
| Mistral || Lingxian Kong || kong
|-
| Murano ||Kirill Zaitsev || kzaitsev_
|-
| Neutron || Ihar Hrachyshka || ihrachys
|-
| Nova || Sylvain Bauza || bauzas
|-
| Oslo || Davanum Srinivas || dims
|-
| Sahara || Sergey Lukjanov || SergeyLukjanov
|-
| Searchlight || Travis Tripp || TravT
|-
| Senlin || Qiming Teng || Qiming
|-
| Swift || John Dickinson || notmyname
|-
| Trove || Amrith Kumar || amrith
|-
| Zaqar || ||
|}

== QA ==

There are now more projects that are being tested by Tempest, and Grenade or a part deployable by Devstack than we have QA contributors. That means we are going to need your help to keep on top of everything. We are asking for one person from each project to serve as a liaison between the project and QA, and to assist with integrating changes as we move forward.

The liaison should be a core reviewer for the project, but does not need to be the PTL. The liaison should be prepared to assist with writing and reviewing patches that interact with their project, and with discussions of changes to the QA projects to make them easier to use within the project.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || Steve Heyman || hockeynut
|-
| Ceilometer || Chris Dent || cdent
|-
| Cinder || ||
|-
| Glance || Nikhil Komawar || nikhil_k
|-
| Heat || Steve Baker || stevebaker
|-
| Horizon || Timur Sufiev || tsufiev
|-
| Ironic || John Villalovos || jlvillal
|-
| Keystone || David Stanek || dstanek
|-
| Manila || Valeriy Ponomaryov || vponomaryov
|-
| Neutron || Salvatore Orlando || salv-orlando
|-
| Nova || Matt Riedemann || mriedem
|-
| Oslo || Davanum Srinivas || dims
|-
| Sahara || Luigi Toscano || tosky
|-
| Senlin || Haiwei Xu || haiwei-xu
|-
| Swift || ||
|-
| Trove || Craig Vyvial and Nirav Shah || cp16net and nshah
|-
| Zaqar || ||
|}

== Documentation ==

The OpenStack Documentation is centralized on docs.openstack.org but often there's a need for specialty information when reviewing patches or triaging doc bugs. A doc liaison should be available to triage doc bugs when the docs team members don't know enough to triage accurately, and be added to doc reviews that affect your project. You'd be notified through email when you're added either to a doc bug or a doc review. We also would appreciate attendance at the [https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting weekly doc team meeting], We meet weekly in #openstack-meeting every Wednesday at alternating times for different timezones:

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || Constanze Kratel || constanze
|-
| Ceilometer || Ildiko Vancsa || ildikov
|-
| Cinder || Sean Mcginnis || smcginnis
|-
| Congress || ||
|-
| Designate || ||
|-
| Glance || Brian Rosmaita || rosmaita
|-
| Heat || Randall Burt || randallburt
|-
| Horizon || Rob Cresswell || robcresswell
|-
| Ironic || Mitsuhiro SHIGEMATSU || pshige
|-
| Keystone || Lance Bragstad || lbragstad
|-
| Magnum || ||
|-
| Manila || Dustin Schoenbrun || dustins
|-
| Mistral || ||
|-
| Murano || Ekaterina Chernova || katyafervent
|-
| Neutron || Edgar Magana || emagana
|-
| Nova || Joe Gordon or Michael Still || Jog0 or mikal
|-
| Oslo || Doug Hellmann || dhellmann
|-
| Rally || ||
|-
| Sahara || Chad Roberts || crobertsrh
|-
| Senlin || Cindia Blue || lixinhui
|-
| Swift || ||
|-
| Tripleo || ||
|-
| Trove || Laurel Michaels || laurelm
|-
| Zaqar || ||
|}

== Stable Branch ==

The Stable Branch Liaison is responsible for making sure backports are proposed for critical issues in their project, and make sure proposed backports
are reviewed. They are also the contact point for stable branch release managers around point release times.

* By default, the liaison will be the PTL.
* The Stable Branch Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in its PTL election.
* The liaison may further delegate work to other subject matter experts

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Ceilometer || Eoghan Glynn || eglynn
|-
| Cinder || Jay Bryant || jungleboyj
|-
| Glance || Erno Kuvaja || jokke_
|-
| Heat || Zane Bitter || zaneb
|-
| Horizon || Matthias Runge || mrunge
|-
| Ironic || Dmitry Tantsur || dtantsur
|-
| Keystone || Dolph Mathews || dolphm
|-
| Murano || Kirill Zaitsev || kzaitsev_
|-
| Neutron || Ihar Hrachyshka || ihrachys
|-
| Nova || Matt Riedemann || mriedem
|-
| Sahara || Sergey Lukjanov || SergeyLukjanov
|-
| Senlin|| Qiming Teng || Qiming
|-
| Swift || ||
|-
| Trove || Amrith Kumar || amrith
|-
|}

== Vulnerability management ==

The [[Vulnerability Management]] Team needs domain specialists to help assessing the impact of reported issues, coordinate the development of patches, review proposed patches and propose backports. The liaison should be familiar with the [[Vulnerability Management]] process and embargo rules, and have a good grasp of security issues in software design.

* The liaison should be a core reviewer for the project, but does not need to be the PTL.
* By default, the liaison will be the PTL.
* The liaison is the first line of contact for the Vulnerability Management team members
* The liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL
* The liaison may further delegate work to other subject matter experts
* The liaison maintains the members of the $PROJECT-coresec team in Launchpad (which can be given access to embargoed vulnerabilities)

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || Douglas Mendizábal or Charles Neill || redrobot / ccneill
|-
| Ceilometer || Lianhao Lu or Gordon Chung || llu/gordc
|-
| Cinder || ||
|-
| Glance || Stuart McLaren or Nikhil Komawar || mclaren or nikhil_k
|-
| Heat || Steve Hardy || shardy
|-
| Horizon || Lin Hua Cheng || lhcheng
|-
| Ironic || Jim Rollenhagen || jroll
|-
| Keystone || Dolph Mathews || dolphm
|-
| Neutron || Salvatore Orlando || salv-orlando
|-
| Nova || Michael Still || mikal
|-
| Sahara || Michael McCune or Sergey Lukjanov || elmiko or SergeyLukjanov
|-
| Searchlight || Travis Tripp or Steve McLellan || TravT or sjmc7
|-
| Senlin || Qiming Teng || Qiming
|-
| Swift || ||
|-
| Trove || Craig Vyvial or Nikhil Manchanda || cp16net or SlickNik
|-
|}

== API Working Group ==

The [[API_Working_Group|API Working Group]] seeks API subject matter experts for each project to communicate plans for API updates, review API guidelines with their project's view in mind, and review the API Working Group guidelines as they are drafted. The liaison should be familiar with the project's REST API design and future planning for changes to it.

The members of the [http://specs.openstack.org/openstack/api-wg/liaisons.html API Working Group Cross-Project Liaisons] are maintained in our repo. If you want to read the entire list of CPLs or add/remove yourself from the list, you'll need to update the [http://git.openstack.org/cgit/openstack/api-wg/tree/doc/source/liaisons.json liaisons.json] file. If you don't want to make the update yourself, please ask in #openstack-sdks on IRC and someone can make the change for you.

== Logging Working Group ==

The [[LogWorkingGroup|Log Working Group]] seeks experts for each project to assist with making the logging in projects match the new [http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html Logging Guidelines]

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Glance || Erno Kuvaja || jokke_
|-
| Oslo || Doug Hellmann || dhellmann
|-
| Nova || John Garbutt || johnthetubaguy
|-
| Murano || Nikolay Starodubtsev || Nikolay_St
|-
| Sahara || Andrey Pavlov || AndreyPavlov
|}

== Infra ==

These are the project specific groups of people that Infra will look to ACK changes to that project's test configuration. Changes to project-config and devstack-gate should be +1'd by these groups when they are related to their project. Note that in an emergency this may not always be possible and Infra will ask for forgiveness but generally we should look for these +1s.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Glance || Flavio Percoco, Nikhil Komawar|| flaper87, nikhil_k

|-
| Neutron || Kyle Mestery, Armando Migliaccio, Doug Wiegley|| mestery, armax, dougwig
|-
| Documentation || Andreas Jaeger|| AJaeger

|-
| Trove || Nikhil Manchanda || SlickNik

|-
| Sahara || Sergey Lukjanov || SergeyLukjanov

|-
| Fuel || Aleksandra Fedorova, Igor Belikov || bookwar, igorbelikov

|-
| Puppet OpenStack || Emilien Macchi || EmilienM
|}

== Product Working Group ==
The product working group consists of product managers, technologists, and operators from a diverse set of organizations. The group is working to aggregate user stories from the market-focused teams (Enterprise, Telco, etc.) and cross-project functional teams (e.g. logging, upgrades, etc.), partner with the development community on resourcing, and help gather data to generate a multi-release roadmap. Most of the user stories being tracked by this team consists of items that can span multiple releases and usually have cross-project dependencies.

More information about the team can be found on the [[ProductTeam|Product WG wiki]].

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Ceilometer ||Krish Ragurham ||
|-
| Cinder || Shamail Tahir || shamail
|-
| Glance || Nate Ziemann || nate_zman
|-
| Horizon || Carol Barrett || barrett1
|-
| Keystone || ||
|-
| Kolla || Carol Barrett || barrett1
|-
| Magnum || Steve Gordon || sgordon
|-
| Manilla ||Pete Chadwick ||
|-
| Neutron || Mike Cohen, Duane DeCapite || DuaneDeC7
|-
| Nova || Hugh Blemings || hughhalf
|-
| OSClient || Megan Rossetti || MeganR
|-
| Stable Release|| Rochelle Grober || rockig
|-
| Sahara || Ethan Gafford || egafford
|-
| Senlin || Qiming Teng || Qiming
|-
| Swift || Phil Williams || philipw
|-
| Tempest || Arkady Kanevsky || arkady_kanevsky
|-
|}

== I18n ==
I18n team is responsible for making OpenStack ubiquitously accessible to people of all language backgrounds. The team have translators from all over the world to translate OpenStack into different languages.

If you want to communicate with translators in I18n team, send email to openstack-i18n@lists.openstack.org.

* The liaison should be a core reviewer for the project and understand i18n status of the project.
* The liaison should understand project release schedule very well.
* The liaison should notify I18n team happens of important moments in the project release in time. For example, happen of soft string freeze, happen of hard string freeze, and happen of RC1 cutting.
* The liaison should take care of translation patches to the project, and make sure the patches are successfully merged to the final release version. When the translation patch is failed, the liaison should notify I18n team.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Glance || ||
|-
| Keystone || ||
|-
| Neutron || Akihiro Motoki || amotoki
|-
| Nova || Augustina Ragwitz || auggy
|-
| Cinder || ||
|-
| Swift || ||
|-
| Horizon || Doug Fish / Akihiro Motoki || doug-fish / amotoki
|-
| Telemetry || ||
|-
| Designate || Graham Hayes || mugsie
|-
| Heat || ||
|-
| Magnum || Shu Muto || shu-mutou
|-
| Murano || Kirill Zaitsev || kzaitsev_
|-
| Sahara || Chad Roberts || crobertsrh
|-
|}

== Inter-project Liaisons ==

In some cases, it is useful to have liaisons between projects. [http://lists.openstack.org/pipermail/openstack-dev/2015-April/062327.html For example, it is useful for the Nova and Neutron projects to have liaisons, because the projects have complex interactions and dependencies.] Ideally, a cross-project effort should have two members, one from each project, to facilitate communication and knowledge transfer.

{| class="wikitable"
|-
! Projects !! Name !! IRC Handle !! Role
|-
| Nova / Neutron || || ||
|-
| || Sean M. Collins || sc68cal || Neutron liaison for Nova
|-
| Nova / Glance || || ||
|-
| || Flavio Percoco, Mike Fedosin || flaper87, mfedosin || Glance liaison for Nova
|-
| || Jay Pipes || jaypipes || Nova liaison for Glance
|-
| Nova / Cinder || || ||
|-
| || Scott DAngelo || scottda || Cinder liaison for Nova
|-
| || Matt Riedemann || mriedem || Nova liason for Cinder
|-
| Nova / Ironic || John Villalovos || jlvillal || Ironic liaison for Nova
|-
| || Michael Davies || mrda || Ironic liaison for Nova
|-
| Neutron / Ironic || || ||
|-
| || Sukhdev Kapur || sukhdev || Neutron liaison for Ironic
|-
| || Mitsuhiro SHIGEMATSU and Jim Rollenhagen || pshige and jroll || Ironic liaison for Neutron
|-
| Murano / Glance || || ||
|-
| || Alexander Tivelkov || ativelkov || Glance liaison for Murano, Murano liaison for Glance
|-
| Horizon / i18n || || ||
|-
| || Doug Fish || doug-fish || Horizon liaison for i18n
|-
| Sahara / Heat || || ||
|-
| || Vitaly Gridnev || vgridnev || Sahara liaison for Heat
|-
| || TBD || || Heat liaison for Sahara
|-
| Sahara / Trove || || ||
|-
| || Ethan Gafford || egafford || Sahara liaison for Trove
|-
| || Amrith Kumar || amrith || Trove liaison for Sahara
|-
| Fuel / Puppet || || ||
|-
| || Alex Schultz || mwhahaha || Fuel liaison for Puppet
|-
| Fuel / Ironic || || ||
|-
| || Evgeny L || evgenyl || Fuel liaison for Ironic
|-
| Bareon / Ironic || || ||
|-
| || Evgeny L || evgenyl || Bareon liaison for Ironic
|}

=== Etherpads ===

The following is a list of etherpads that are used for inter-project liaisons, and are continuously updated.

Nova - Neutron: https://etherpad.openstack.org/p/nova-neutron

== Cross-Project Spec Liaisons ==

The OpenStack project relies on the cross-project spec liaisons from each participating project to help with coordination and cross-project spec related tasks. See full set of [http://docs.openstack.org/project-team-guide/cross-project.html#cross-project-specification-liaisons responsibilities] The liaison defaults to the PTL, but the PTL can also delegate the responsibilities to someone else on the team by updating this tableː

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Astara|| Adam Gandelman || adam_g
|-
| Barbican || Douglas Mendizabal || redrobot
|-
| Cinder || Kendall Nelson || diablo_rojo
|-
| Congress || Tim Hinrichs || thinrichs
|-
| Designate || Graham hayes || mugsie
|-
| Fuel || Andrew Woodward || xarses
|-
| Glance || Nikhil Komawar || nikhil
|-
| Heat || Rico Lin || ricolin
|-
| Horizon || David Lyle || david-lyle
|-
| Infrastructure || Matthew Wagoner || olaph
|-
| Ironic || Jim Rollenhagen || jroll
|-
| Keystone || Samuel de Medeiros Queiroz || samueldmq
|-
| Magnum || Adrian Otto || adria̠n_otto
|-
| Manila || Ben Swartzlander || bswartz
|-
| Mistral || Renat Akhmerov || rakhmerov
|-
| Murano || Serg Melikyan || smelikyan
|-
| Neutron || Armando Migliaccio || armax
|-
| Nova || Chris Dent || cdent
|-
| Oslo || Davanum Srinivas || dims
|-
| Sahara || Michael McCune or Sergey Lukjanov || elmiko or SergeyLukjanov
|-
| Searchlight || Travis Tripp || TravT
|-
| Senlin || Qiming Teng || Qiming
|-
| Swift || John Dickinson || notmyname
|-
| Telemetry || Gordon Chung || gordc
|-
| Trove || Amrith Kumar || amrith
|-
| Watcher || Susanne Balle || sballe
|-
| Zaqar || Fei Long Wang || flwang

|}

Stackforge Namespace Retirement

2015-09-25T22:17:38Z

Xarses: /* Active Projects to Move */

=== Background ===

The stackforge/ git namespace is being retired, and active projects are being moved to the openstack/ namespace. See this mailing list post for [http://lists.openstack.org/pipermail/openstack-dev/2015-August/071816.html full background]. These changes are scheduled to occur on October 17, 2015.

There are two lists below, one for active projects that should be moved, and a second for inactive projects that should become read-only. Please update them to add your project to the correct list.

=== Active Projects to Move ===
Active stackforge projects that wish to move into the openstack/ namespace should be added to this list. Projects in this list will be automatically moved by the Infrastructure team to openstack/ on October 17. Please note that no other renames can happen during this move -- projects will strictly be moved from stackforge/ to openstack/ with their existing names.

* aeromancer
* anvil
* blazar
* blazar-nova
* ceilometer-powervm
* ceilometer-zvm
* cloud-init
* cloudbase-init
* clouddocs-maven-plugin
* cloudkitty
* cloudkitty-dashboard
* cloudpulse
* cognitive
* compass-adapters
* compass-core
* compass-specs
* compass-web
* compute-hyperv
* doc8
* driverlog
* ec2-api
* faafo
* fuel-agent
* fuel-astute
* fuel-dev-tools
* fuel-devops
* fuel-docs
* fuel-library
* fuel-main
* fuel-mirror
* fuel-nailgun-agent
* fuel-octane
* fuel-ostf
* fuel-ostf-plugin
* fuel-plugin-availability-zones
* fuel-plugin-calamari
* fuel-plugin-calico
* fuel-plugin-ceilometer-redis
* fuel-plugin-cinder-netapp
* fuel-plugin-cisco-aci
* fuel-plugin-contrail
* fuel-plugin-dbaas-trove
* fuel-plugin-detach-database
* fuel-plugin-detach-keystone
* fuel-plugin-detach-rabbitmq
* fuel-plugin-elasticsearch-kibana
* fuel-plugin-external-emc
* fuel-plugin-external-glusterfs
* fuel-plugin-external-zabbix
* fuel-plugin-glance-nfs
* fuel-plugin-ha-fencing
* fuel-plugin-influxdb-grafana
* fuel-plugin-ironic
* fuel-plugin-ldap
* fuel-plugin-lma-collector
* fuel-plugin-lma-infrastructure-alerting
* fuel-plugin-mellanox
* fuel-plugin-midonet
* fuel-plugin-neutron-fwaas
* fuel-plugin-neutron-lbaas
* fuel-plugin-neutron-vpnaas
* fuel-plugin-nova-nfs
* fuel-plugin-nsxv
* fuel-plugin-opendaylight
* fuel-plugin-saltstack
* fuel-plugin-solidfire-cinder
* fuel-plugin-swiftstack
* fuel-plugin-tintri-cinder
* fuel-plugin-tls
* fuel-plugin-vmware-dvs
* fuel-plugin-vxlan
* fuel-plugin-zabbix-monitoring-emc
* fuel-plugin-zabbix-monitoring-extreme-networks
* fuel-plugin-zabbix-snmptrapd
* fuel-plugins
* fuel-provision
* fuel-qa
* fuel-specs
* fuel-stats
* fuel-tasklib
* fuel-upgrade
* fuel-web
* gce-api
* gerrit-dash-creator
* git-upstream
* golang-client
* intel-nfv-ci-tests
* merlin
* monasca-agent
* monasca-api
* monasca-ceilometer
* monasca-common
* monasca-log-api
* monasca-notification
* monasca-persister
* monasca-statsd
* monasca-thresh
* monasca-ui
* monasca-vagrant
* namos
* networking-hyperv
* networking-ovs-dpdk
* networking-zvm
* nova-docker
* nova-powervm
* nova-solver-scheduler
* nova-zvm-virt-driver
* ops-tags-team
* ospurge
* packstack
* puppet-autossh
* puppet-ceph
* puppet-n1k-vsm
* puppet-setproxy
* python-blazarclient
* python-cloudkittyclient
* python-cloudpulseclient
* python-cognitiveclient
* python-fuelclient
* python-monascaclient
* python-openstacksdk
* python-senlinclient
* python-tackerclient
* senlin
* senlin-dashboard
* shaker
* sqlalchemy-migrate
* stackalytics
* swift3
* tacker
* tacker-horizon
* tacker-specs
* telcowg-usecases
* terracotta
* third-party-ci-tools
* tricircle
* vmtp
* wsme
* xenapi-os-testing
* yaql

=== Inactive Projects to Retire ===
Inactive projects that should be retired should be added to this list. These projects will have a commit merged removing their content and replacing it with a message indicating the project is no longer maintained and will become read-only in Gerrit.

* fuel-plugin-availability-zones
* mercador-pub
* mercador-sub
* MRaaS
* openstackdroid
* python-mercadorclient
* rubick
* sahara-guestagent
* libra
* python-libraclient

Stackforge Namespace Retirement

2015-09-25T22:06:10Z

Xarses: /* Active Projects to Move */

=== Background ===

The stackforge/ git namespace is being retired, and active projects are being moved to the openstack/ namespace. See this mailing list post for [http://lists.openstack.org/pipermail/openstack-dev/2015-August/071816.html full background]. These changes are scheduled to occur on October 17, 2015.

There are two lists below, one for active projects that should be moved, and a second for inactive projects that should become read-only. Please update them to add your project to the correct list.

=== Active Projects to Move ===
Active stackforge projects that wish to move into the openstack/ namespace should be added to this list. Projects in this list will be automatically moved by the Infrastructure team to openstack/ on October 17. Please note that no other renames can happen during this move -- projects will strictly be moved from stackforge/ to openstack/ with their existing names.

* aeromancer
* anvil
* blazar
* blazar-nova
* ceilometer-powervm
* ceilometer-zvm
* cloud-init
* cloudbase-init
* clouddocs-maven-plugin
* cloudkitty
* cloudkitty-dashboard
* cloudpulse
* compass-adapters
* compass-core
* compass-specs
* compass-web
* compute-hyperv
* doc8
* driverlog
* ec2-api
* faafo
* fuel-octane
* fuel-plugin-calico
* fuel-plugin-ceilometer-redis
* fuel-plugin-elasticsearch-kibana
* fuel-plugin-external-emc
* fuel-plugin-external-zabbix
* fuel-plugin-ha-fencing
* fuel-plugin-influxdb-grafana
* fuel-plugin-lma-collector
* fuel-plugin-lma-infrastructure-alerting
* fuel-plugin-mellanox
* fuel-plugin-midonet
* fuel-plugin-opendaylight
* fuel-plugin-swiftstack
* fuel-plugin-tintri-cinder
* fuel-plugin-vmware-dvs
* fuel-plugin-zabbix-monitoring-emc
* fuel-plugin-zabbix-monitoring-extreme-networks
* fuel-plugin-zabbix-snmptrapd
* gce-api
* gerrit-dash-creator
* git-upstream
* golang-client
* intel-nfv-ci-tests
* merlin
* monasca-agent
* monasca-api
* monasca-ceilometer
* monasca-common
* monasca-notification
* monasca-persister
* monasca-statsd
* monasca-thresh
* monasca-ui
* monasca-vagrant
* namos
* networking-hyperv
* networking-ovs-dpdk
* networking-zvm
* nova-docker
* nova-powervm
* nova-solver-scheduler
* nova-zvm-virt-driver
* ops-tags-team
* ospurge
* packstack
* puppet-autossh
* puppet-ceph
* puppet-n1k-vsm
* puppet-setproxy
* python-blazarclient
* python-cloudkittyclient
* python-cloudpulseclient
* python-fuelclient
* python-monascaclient
* python-openstacksdk
* python-senlinclient
* python-tackerclient
* senlin
* senlin-dashboard
* shaker
* sqlalchemy-migrate
* stackalytics
* swift3
* tacker
* tacker-horizon
* tacker-specs
* telcowg-usecases
* terracotta
* third-party-ci-tools
* tricircle
* vmtp
* wsme
* xenapi-os-testing
* yaql

=== Inactive Projects to Retire ===
Inactive projects that should be retired should be added to this list. These projects will have a commit merged removing their content and replacing it with a message indicating the project is no longer maintained and will become read-only in Gerrit.

* cognitive
* fuel-plugin-availability-zones
* mercador-pub
* mercador-sub
* MRaaS
* openstackdroid
* python-cognitiveclient
* python-mercadorclient
* rubick
* sahara-guestagent

Fuel/How to contribute

2015-07-15T20:09:48Z

Xarses:

=Join the Fuel team=
=== First steps ===
Read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] and learn how to setup the accounts and git.

Clone the repositories:
* git clone git://github.com/stackforge/fuel-main.git
* git clone git://github.com/stackforge/fuel-web.git
* git clone git://github.com/stackforge/fuel-astute.git
* git clone git://github.com/stackforge/fuel-ostf.git
* git clone git://github.com/stackforge/fuel-library.git
* git clone git://github.com/stackforge/fuel-docs.git

You can [https://review.openstack.org/#/q/project:%255Estackforge/fuel-.*,n,z search gerrit for all reviews related to Fuel], or use the [https://review.openstack.org/#/dashboard/?foreach=%28project%3A^stackforge%2Ffuel-.*%29+status%3Aopen+NOT+label%3AWorkflow%3C%3D-1+NOT+label%3ACode-Review%3C%3D-2&title=Fuel+Inbox&My+Patches+Requiring+Attention=owner%3Aself+%28label%3AVerified-1+OR+label%3ACode-Review-1+OR+label%3AWorkflow%3C%3D-1%29&Fuel+Specs=NOT+label%3AWorkflow%3E%3D1+NOT+owner%3Aself+project%3Astackforge%2Ffuel-specs&Needs+Approval=NOT+label%3AWorkflow%3E%3D1+NOT+label%3AWorkflow%3C%3D-1+NOT+label%3AVerified%3C%3D-1+NOT+owner%3Aself+label%3ACode-Review%3E%3D2+NOT+label%3ACode-Review-1&5+Days+Without+Feedback=NOT+label%3AWorkflow%3E%3D1+NOT+label%3AWorkflow%3C%3D-1+NOT+label%3AVerified%3C%3D-1+NOT+owner%3Aself+NOT+project%3Astackforge%2Ffuel-specs+NOT+label%3ACode-Review%3C%3D2+age%3A5d&No+Negative+Feedback=NOT+label%3AWorkflow%3E%3D1+NOT+label%3AWorkflow%3C%3D-1+NOT+label%3AVerified%3C%3D-1+NOT+owner%3Aself+NOT+project%3Astackforge%2Ffuel-specs+NOT+label%3ACode-Review%3C%3D-1+NOT+label%3ACode-Review%3E%3D2+limit%3A50&Other=NOT+label%3AVerified%3C%3D-1+NOT+owner%3Aself+NOT+project%3Astackforge%2Ffuel-specs+label%3ACode-Review-1+limit%3A20 gerrit dashboard for Fuel] for a prioritized list of open reviews (this URL was generated using [https://github.com/stackforge/gerrit-dash-creator/blob/master/dashboards/fuel.dash Gerrit dashboard generator], you need to be logged into Gerrit for it to work).

Please note that OpenStack Infra uses strict checks on your git commit messages. The most important rules are:
* Keep your commit title short (<80 symbols). It must not end with dot.
* Body of commit message should be separated from title by one empty line
* If patch closes bug, then it must have in a body "Closes-Bug: #12345", where 12345 is your LP bug number
* If patch relates to bug, but doesn't completely solve an issue, then you must use "Related-Bug: #12345"
See the [[GitCommitMessages|Git commit messages]] wiki page for more details.

=How and where to get help=
=== Subscribe to mailing lists ===
* [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack developers mailing list]. If you are hacking on Fuel, or have technical question about Fuel internals, you are very welcome in this ML with subject containing "[Fuel]".
* [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack OpenStack users mailing list]. Fuel traffic is there with subject containing "[Fuel]". You are welcome to ask questions related to Fuel usage, including errors, etc.
* [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce OpenStack announcements mailing list]. Announcements about the OpenStack project like product release information, security advisories, important discussions. This is a low-traffic, read-only list.
* There are even more mailing lists out there, visit [[MailingLists]] to see the other OpenStack related lists.

=== IRC at freenode.net ===
* The general Fuel channel is called "#fuel", and it is logged [http://irclog.perlgeek.de/fuel/ here].
* The Fuel development channel is called "#fuel-dev", and it is logged [http://irclog.perlgeek.de/fuel-dev/ here].

=== Quick reference dev links ===
* Development environment [http://docs.mirantis.com/fuel-dev/develop/env.html http://docs.mirantis.com/fuel-dev/develop/env.html]
* How to build your Fuel ISO [http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso]
* Nailgun development [http://docs.mirantis.com/fuel-dev/develop/nailgun.html http://docs.mirantis.com/fuel-dev/develop/nailgun.html]
* Health Check (OSTF) contributors guide [http://docs.mirantis.com/fuel-dev/develop/ostf_contributors_guide.html http://docs.mirantis.com/fuel-dev/develop/ostf_contributors_guide.html]
* Contributing to Fuel Library (puppet modules) [http://docs.mirantis.com/fuel-dev/develop/module_structure.html http://docs.mirantis.com/fuel-dev/develop/module_structure.html]
* Devops framework - distributed testing of Fuel envs [http://docs.mirantis.com/fuel-dev/devops.html http://docs.mirantis.com/fuel-dev/devops.html]

=Contributing=
Fuel is large project within which Programming, Linux and Networking intersect. It is written in Python, Ruby and JavaScript. It also has a number of build scripts in bash & make. Documentation is written in Sphinx. New contributors are always welcome.

==Fuel library for puppet manifests==
===Adding new puppet modules to fuel-library===
'''Case A. Pulling in changes from an existing module'''

If you are pulling in changes to an existing fork from a module that is the work of another project and is already tracked in separate repo then:
1. Create a review request with a unmodified copy of the upstream module from whichever point you are working from and no other related modifications.
* This review should also contain the commit hash from the upstream repo in the commit message.
* The review should be evaluated to determine its suitability and either rejected (for licensing, code quality, outdated version requested) or accepted without requiring modifications.
* The review should not include code that calls this new module.
2. Any changes necessary to make it work with Fuel should then be proposed as a dependent change(s).

'''Case B. Adding a new module'''

If you are adding a new module that is a work purely for Fuel and will not be tracked in a separate repo then submit incremental reviews that consist of working implementation of features for your module.
If you have features that are necessary, but do not work fully yet, then prevent them from running during the deployment. Once your feature is complete, submit a review to activate the module during deployment.

If you are going to add a new fork of upstream module - please don't do. Instead, follow the upstream module's contribution rules and provide this module as an additional plug-able component for Fuel. This can be done as a part of [[Fuel/Plugins|plug-able architecture]] and distributed as a package. Note, if upstream module doesn't fit your requirements, you should first adapt the module for your needs upstream or, for emergency cases, provide custom patch-sets as a part of module as a Fuel plugin distribution.

Modules with licenses incompatible with Apache 2.0 (GPL, etc.) will not be accepted. *Please pay attention to the license information.*

===Contributing to existing fuel-library modules===
As developers of Puppet modules, we tend to collaborate with the Puppet OpenStack community. As a result, we contribute to upstream modules all of the improvements, fixes and customizations we make to improve Fuel as well. That implies that every contributor must follow Puppet DSL basics, [[Puppet-openstack#Developer_documentation|puppet-openstack dev docs]] and [[Puppet-openstack#Rspec_puppet_tests|Puppet rspec tests requirements]].

The most common and general rule is that upstream modules should be modified only when bugfixes and improvements could benefit everyone in the community. And appropriate patch should be proposed to the upstream project prior to Fuel project.

In other cases (like applying some very specific custom logic or settings) contributor should submit patches to openstack::* classes

Fuel library includes custom modules as well as ones forked from upstream sources. Note that Modulefile (or metadata.json), if any exists, should be used in order to recognize either given module is forked upstream one or not. In case there is no Modulefile in module’s directory, the contributor may submit a patch directly to this module in Fuel library. Otherwise, he or she should submit patch to upstream module first, and once merged or +2 recieved from a core reviewer, the patch should be backported to Fuel library as well. Note that the patch submitted for Fuel library should contain in commit message the upstream commit SHA or link to github pull-request (if the module is not on stackforge) or Change-Id of gerrit patch.

=Fuel development environments=
===VirtualBox===
The quickest way to get started with Fuel is to set up an environment under VirtualBox. This is a great way start testing, for instance by using the nightly builds to try to verify, confirm or triage bugs. A quick-start script and instructions can be found at https://software.mirantis.com/quick-start/.

===Fuel ISO-build and development environment===
Setting up an environment to build the Fuel ISO will allow you to easily build against specific commits in order to do more complicated bug test/confirm/triage/fix work, or augmenting Fuel with new features. In addition to preparing the environment for ISO building, the steps necessary to prepare a dev environment for the other Fuel components (nailgun, astute and doc building) can be found there. Instructions for preparing the environment can be found at http://docs.mirantis.com/fuel-dev/develop/env.html.

===Fuel DevOps environment===
Setting up a Linux machine as a Fuel DevOps environment will allow you to automate the build/verify/test process, in addition to building the ISO and doing other Fuel-related development. Using libvirt, the devops environment is able to deploy multiple complete OpenStack environments on VMs. Instructions for preparing a devops environment can be found at http://docs.mirantis.com/fuel-dev/devops.html.

=Documentation=
There are two types of documentation in Fuel: [http://docs.mirantis.com/fuel-dev/ development] and [http://docs.mirantis.com/ user]. Source code of the development documentation can be found at [https://github.com/stackforge/fuel-web/tree/master/docs fuel-web repository]; users, at [https://github.com/stackforge/fuel-docs fuel-docs repository]. Both repositories use the [http://sphinx-doc.org/rest.html reStructuredText format]. Documentation is treated as source code, we use the same [[Fuel/How_to_contribute#First_steps|development process]] for updating documentation as we do for Fuel code.

=== Writing documentation ===
Keeping the Documentation up to date is hard and it is a critical part in every project. Fuel developers use the OpenStack [https://wiki.openstack.org/wiki/Documentation/DocImpact DocImpact] process to highlight code changes that need to be reflected in documentation. When a patchset should be documented or requires documentation changes, the reviewer should ask the commiter to add 'DocImpact' tag to their commit message, and makes sure the commit message provides enough information about the impact of the code change. When a commit with a DocImpact tag is merged, a new bug will be automatically created and assigned to the Fuel Documentation team. Technical writers then work with the commiter to reflect the commit in the documentation.

A bug generated from a DocImpact commit should be assigned to fuel-docs team until a technical writer picks it up. Technical writer collects information from the original commit author, and adds it to the right documentation areas. It's commit author's responsibility to provide an informative commit message in the first place, to answer technical writer's questions, and to review documentation commits that address that DocImpact bug.

=== Update and expand current documentation ===
Feel free to file bug if you find a problem with the documentation, and provide with a fix for it via same code contribution policy and procedures. There is [http://docs.mirantis.com/fuel-dev/develop/env.html#building-documentation building documentation page] to help with an environment setup for development documentation.

=== Writing release notes ===
==== New features ====
For every blueprint listed on the milestone page in Launchpad (e.g. https://launchpad.net/fuel/+milestone/5.1), find answers to the following questions:
* What is the visible impact of the change for a user?
* Was this previously documented as a Known Issue?

If it is a user visible improvement, add a New Features entry about it. Explain when this feature is important, how it can be enabled, and what are the current expectations and limitations.

If it was a Known Issue before, add a Resolved Issues entry.

==== Known and Resolved issues ====
Scan the release milestone page (e.g. [https://launchpad.net/fuel/+milestone/6.0 fuel 6.0]). Review all bugs targeted for the current milestone that satisfy one of the following conditions:
* "release-notes" tag
* Critical priority
* High priority and "customer-found" tag.

Sort the bugs table on the milestone page by Number from highest to lowest, so that you can see when you've reached the bugs that you have already reviewed. If bug status for the current milestone is Fix Committed or Fix Released, consider it for Resolved Issues list. Find answers to:
* Was this problem present in the previous GA release? (If it was, it will be targeted for at least one previous release series, with target milestone set to a maintenance release in that series.)
* How does one confirm if their environment is affected? (Identify specific configurations affected by the bug, include error messages or other symptoms that distinguish this bug from others.)
* If you're affected, how do you recover?
* What was the root cause and what had to be changed to resolve the issue?

If bug status for the current milestone is Won't Fix and it meets the criteria above, consider it for the Known Issues list. Questions to answer are:
* How does one confirm if their environment is affected?
* Is there a workaround? (How do you prevent this problem from affecting you?)
* What is the recovery procedure?

==== Reviewing the release notes ====
Responsibility for every section of release notes is assigned to a technical writer. The writer identifies features and bugs that have to be reflected in their section. For each feature and bug, the writer finds a responsible software engineer: either feature owner, or committer of the most recent bugfix.

If sufficient description (see question lists above) cannot be derived from bug description, blueprint description and specification, and commit messages of related commits, the writer contacts the engineer privately with a request for more information. When a description of a feature or bug is published in a gerrit review, the writer subscribes the engineer to that review, and once again privately sends a request with a link to the documentation review in Gerrit and instructions on how to identify specific documentation files and lines that this engineer must review (e.g. LP bug number, specific RST file, section header or label, etc.)

Fuel engineers must prioritize such information and review requests so that they are able to respond within one week during normal development process, and within one business day during the period between Hard Code Freeze and GA release. Standard escalation process is used when no response to request for information or request for review is received in time. Technical writer is responsible for tracking status of information and review requests and escalations for their section of release notes.

=Bugs=
===Verify bugs===
This is very easy to get started, but help here is actually very valuable. Especially when it comes to bugfixes which are relevant to only certain types of hardware. When bugfix is merged, bug is automatically moves to "Fix Committed" status. In Fuel, we set "Fix Released" status for a bug only when it was verified by someone else than a developer. You can simple check out [https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=FIXCOMMITTED all fix committed bugs] and start verifying them. It is required to be in fuel-bugs LP group to be able to change bug status. However you can leave a comment in bug report, and it will be enough for bug supervisors to change bug status. By your request, you can be included into fuel-bugs team to manage bugs yourself.

=== Test and report bugs ===
You can always build a developers ISO from master following instructions at http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso. Test different deployment modes, and file bugs. Please do not hesitate to share your findings in IRC for any details you would want to know. Feel free to file bug in a format you want, however it would be great to see a bug in a certain format, with all details in place - to easily reproduce and save a time of developers. You can follow the following simple guidance, which a little bit extend official OpenStack [[Bugs]] page.

The bugs you report for Fuel can be either “Public” or “Private”. Private bugs become visible only for Dev, QA, and Support teams. The guidance is as follows:
* Normally you would want to report a “Public” bug
* However, if a bug contains any sensitive information, or security vulnerability information, please report a “Private” bug

Before creating a new bug, it's always a good idea to check if a bug like that already exists in the project, and update an existing bug instead of creating something that will later have to be discarded as a duplicate. However, it is important to make sure that both bugs are really related, dealing with a duplicate is much easier than untangling several unrelated lines of investigation mixed into one bug. Do not ever reopen bugs with generic catch-all titles like "Horizon crashed" or "HA doesn't work" that can cover whole ranges of root causes. Do not create new bugs with such titles, either: be as specific about the nature of the problem as you can.

Here is how you file a bug:
* Go to https://launchpad.net/fuel
* Select “Report a bug” on the right
* Fill in “Summary” field for a bug. It is going to be the headline. Please be descriptive but short and to the point.
** Bad - "Savanna doesn’t install"
** Good - "Savanna fails to install in HA mode when “Neutron with VLANs” network is selected"
* Enter “Further information”. This is a bug description. It should contain the following sections:
** Steps to reproduce
*** Bad: Run the deployment in HA configuration
*** Good:
***# Create a new cluster
***# Select HA mode, “Neutron with VLANs” for network, and choose to install Savanna
***# Leave defaults the rest of the settings. Run cluster installation
** Expected result:
*** Good: Savanna is deployed, up and running.
** Actual result:
*** Bad: Savanna fails to install.
*** Good: Savanna installation fails with the error message “xxx”. Please see the attached screenshot which shows the errors on “Logs” tab.
** Workaround
*** Bad: Don’t use “Neutron with VLANs”
*** Good: Switch network mode to “Neutron with GRE” for the deployment to complete successfully.
** Impact
*** Bad: Needs to be fixed.
*** Good: deployment cannot be completed, because customer requires us to implement a use case for Savanna and “Neutron with VLANs”. Changing configuration to “Neutron with GRE” is not as acceptable option here so this has to be addressed as soon as possible.
** Description of the environment. Provide enough relevant information:
*** Output of http://fuel-master-node:8000/api/version/
*** Operating System
*** Reference Architecture (HA / non-HA)
*** Network model (Nova-network, Neutron+VLAN, Neutron+GRE, etc.)
*** Related Projects installed (Savanna, Murano, Ceilometer)
* Select visibility for the bug under “This bug contains information that is” field. Either leave it as “Public” (default) or set it to “Private” per the above guidance
* Add attachments under “Extra Options” section
** Logs
** Diagnostic snapshot
** Screenshots
* After everything is entered, select the “Submit bug report” button

=== Confirm and triage bugs ===
Fuel project uses the same bug management practices as in other OpenStack projects. Please follow [[Bugs]] and [[BugTriage]] pages.

When triaging the bugs in the Fuel deployment process (as opposed to bugs in OpenStack components deployed by Fuel), use following additional criteria for bug importance:

* Critical = can't deploy anything and there's no trivial workaround; data loss; or security vulnerability
* High = specific hardware, configurations, or components are unusable and there's no workaround; or everything is broken but there's a workaround
* Medium = specific hardware, configurations, or components are working incorrectly; or is completely unusable but there's a workaround
* Low = minor feature is broken and can be fixed with a trivial workaround; or a cosmetic defect
* Wishlist = not a bug, either close as Won't Fix, or associate with a blueprint (create new blueprint if no existing blueprint covers the feature requested in the bug)

Additional guidelines for User eXperience (UX) issues:

In some cases a bug may cause significant impact to UX in these cases we can use additional criteria to set bug priority
* Critical = Requires massive effort to work around, including un/under-documented commands and edits to config files
* High = Requires modification of config files, interfaces that users aren't expected to use (ie the API when it's _intended_ to work in the CLI / UI (exclusive of interfaces that are intended to only be available via API) or requires custom node yaml (again except when it should exclusively be available)
* Medium: Straight forward commands in the CLI
* Low and Wishlist = as above

Additional guidelines for documentation bugs:

* Critical = following the instructions from documentation can cause outage or data loss
* High = documentation includes information that is not true, or instructions that yield the advertised outcome
* Medium = important information is missing from documentation (e.g. new feature description)
* Low = additional information would improve reader's understanding of a feature
* Wishlist = cosmetic formatting and grammar issues

Also Fuel uses different meaning for two bug states:

* Confirmed = somebody who is not submitter looked into the bug and made sure that it is properly triaged. The person must made sure that milestone, importance and assignee are properly set. Still the bug '''could be not''' reproduced or confirmed as genuine.
* Fix Released = somebody who is not assignee verified that the issue does not reproduce after it was fixed. The status is left for QA to mark bugs as verified after they are fixed.

When triaging bugs, please use the following routine:

# Review all '''New''' bugs.
# Assign each New bug to the release series under development (focus of development according to [https://launchpad.net/fuel/+series Fuel project timeline]) and set corresponding bug status and milestone for that release series.
# Consider changing the bug title to be more specific, replace generic statements like "deployment timeout exceeded" with description of the root cause (if identified) or symptops that are unique for that bug.
# Consider visibility status of the bug. If it contains sensitive information, set it to '''Private'''. If it describes a security vulnerability, set it to '''Private Security'''.
# If the bug does not contain sufficient information as described in [[Fuel/How_to_contribute#Test_and_report_bugs]], request the missing information, and set the bug status to '''Incomplete'''. Add a comment using the following template: ''We didn't receive required details in order to correctly troubleshoot the problem, so we are setting this bug into Incomplete state. Please provide reqested information and we will investigate this issue further. If you think it was incorrectly set to Incomplete, please comment in the bug''.
# If there is sufficient information on how to reproduce the bug and milestone, importance and assignee are properly set, set the status to '''Confirmed'''.
# If there is sufficient information to start implementing a fix, set the status to '''Triaged'''.
# If the root cause of the bug is identified, include it in the bug description.
# Review all '''Incomplete''' bugs
# If an Incomplete bug has new updates, use the same steps as described above for New bugs.
# If an Incomplete bug did not have any updates for '''4 weeks''', close it as '''Invalid'''. Add a comment using the following template: ''This bug was incomplete for more than 4 weeks. We cannot investigate it further so we are setting the status to Invalid. If you think it is not correct, please feel free to provide requested information and reopen the bug, and we will look into it further.''
# During '''Code Freeze''' for a release, review all bugs targeted at that release milestone, make sure it is updated daily by the assignee (or bug reporter if the bug is not assigned to a person).
# If you know that the bug is related to some blueprints, link this bug to these blueprints. To do this, go to corresponding blueprints page and hit 'Link a bug report' link.

Remember that every status change of a bug should be accompanied by a comment explaining the reason why the change was made.

Useful LaunchPad searches and tools:

* [https://bugs.launchpad.net/fuel/+bugs?field.status=NEW&field.project=FUEL New bugs]
* [https://bugs.launchpad.net/fuel/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search Incomplete bugs]
* [https://bugs.launchpad.net/fuel/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search Unassigned bugs]
* [https://bugs.launchpad.net/fuel/+bugs?field.searchtext=&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=choose&field.assignee=fuel-library&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search&orderby=milestone_name&start=0 Bugs in fuel-library, sorted by milestone]
* Launchpad Report Tool with bugs SLA by Mirantis https://launchpad-reports-summary.mirantis.com/project/bugs_lifecycle_report/6.1
* [https://addons.mozilla.org/en-US/firefox/addon/launchpad-helper/?src=cb-dl-created Launchpad Helper for Firefox]
* [https://chrome.google.com/webstore/detail/launchpad-helper/kjelakmoldahcakikjnfebiolcliigah?hl=en Launchpad Helper for Chrome]

=== Fix bugs ===
The most simple and easy way to contribute code into Fuel is to start with bug fixes. First of all, check out [https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.tag=low-hanging-fruit+&field.tags_combinator=ANY bugs with "low-hanging-fruit" tag]. You can also take any other bug. For easier management of bugs, Fuel uses multiple functional groups, and you will see bugs assigned to fuel-python, fuel-library, fuel-qa and other teams. Feel free to pick any of those. It is assigned to group, so group can get an email notification about a bug. Unless it is reassigned to particular engineer to work on that bug, then it means the bug is not taken by anyone yet, so feel free to take it. Bugs with assignee set to a person are not yet imply that someone works on them (but it should in ideal world). If it is even in "in progress" state, feel free to ping a person and ask if he really works on that bug, and feel free to assign yourself otherwise.

=== Backport bugfixes to stable release series ===
When you create a new bug with High or Critical priority or upgrade an existing bug, always check if this bug is present in the supported stable release series (at least one most recent stable release). If it is present there, target it to all affected series (even if you don't expect to be able to eventually backport a fix). If it's not present in stable releases, document that on the bug so that other people don't have to re-check.

When you propose a fix for a bug, always start with fixing it in the master branch. If the fix only applies to the stable branch and is not relevant in master, explain that in the commit message. For a bug targeted for stable release series, cherry-pick the fix commit onto the stable/x.x branch for each series it is targeted for, '''after''' the fix was merged to master (creating backports prematurely leads to possible inconsistency between master and stable/x.x versions of the same commit). Use the same Change-Id and topic (git review -t bug/<id>) to make it easier to track down all backports for that bug. You can also use "Cherry Pick To" button in Gerrit if the commit can be applied to the stable branch without conflicts.

When you approve a bugfix commit for master branch, use the information available so far on the bug and in the review request to review and maybe update backporting status of the bug. Is its priority high enough to need a backport? Is it targeted to all affected release series? Are there backport commits already? If yes, are they up to date with the commit that was merged to master?
* For all series where backport should exist and doesn't, create a backport review request yourself.
* For all other affected series, change bug status to Won't Fix and explain in bug comments.
* Do not merge commits into stable branches until it was merged into master, unless commit message explicitly documents why it doesn't apply to master.

When you find a bug in a stable release, do not simply target it to the next release in that maintenance release series. Instead, target it to the release designated as "current focus" on the [https://launchpad.net/fuel/ Fuel home page in Launchpad]. If it's a High or Critical priority bug, additionally target it to the releases series it was originally found in, and, if applicable, all release series in between.

If a bug is present in a maintenance release and not present in current release series, it should have one of the following statuses in the current release series:
* Incomplete if root cause analysis is not finished
* Fix Committed if root cause analysis shows that the bug is fixed by changes merged after the maintenance release the bug was found in
* Invalid if root cause analysis shows that the bug was introduced by a change specific to this maintenance release series

=Enhancements=
=== Propose enhancements ===

Enhancements for Fuel are proposed using the mechanism of blueprints. The process is very similar to the bugs:

* Select "Register a Blueprint". Typically, you’ll find this link on the right side of the launchpad page.
** Enter a Name for the blueprint. If possible, include the name of the sub-component of fuel as the first word of the name (or just fuel for a broader blueprint), then a very short descriptor using dashes between words. For example, [https://blueprints.launchpad.net/fuel/+spec/ui-declarative-wizard ui-declarative-wizard] or [https://blueprints.launchpad.net/fuel/+spec/fuel-stop-deployment fuel-stop-deployment].
** Enter a Title for the blueprint. The title should describe the feature as clearly as possible in up to 70 characters. This title is displayed in every feature list or report.
* Enter a Summary of the blueprint.
** Summarize the idea of the blueprint in a user story. If you have an existing user story in a public document, include the link.
** If a public document isn’t yet created and the user story is extensive, you can use https://etherpad.openstack.org/ to document the full user story. You can use the Name that you used for the blueprint as the Pad name.
* Propose your blueprint by selecting the milestone in which you plan to complete the blueprint.
* You won’t need to enter any other fields, so now just choose Register Blueprint.

If you’re just entering a new idea without a design, you can leave the specification URL field blank. If you have a design, here is how you get it published and approved:

* Upload a design specification in the "specs/<release>" folder in fuel-specs
** e.g. [https://review.openstack.org/96429 access-control-master-node]
** it should be based on the [http://git.openstack.org/cgit/stackforge/fuel-specs/tree/specs/template.rst template], see the instructions in the template for more details
** get it reviewed by submitting your patch using Gerrit, in the usual way: [http://docs.openstack.org/infra/manual/developers.html#development-workflow Development Workflow]
** at the end of each release, non-completed specs will be removed
** you need to re-submit for the following release, should the blueprint slip

* In order to get your spec approved, it usually requires to get +1 from the following folks:
** All mandatory design reviewers (it's usually people who familiar with the area of the proposed enhancement)
** Topic expert if any (e.g your enhancement somehow affects Fuel Web UI then you need to get +1 from the Fuel Web UI team)
** QA
** For cross-component enhancements, it also requires to have +1 from core of affected components.

* Once your design specification has been approved and merged into fuel-specs git repo:
** Update your blueprint's specification URL to point to the design specification in fuel-specs git
** Note, this should link to git (as in the template link above), not to the gerrit change

When done, drop an email about the new blueprint to the mailing list to attract attention of Fuel developers, who are likely to provide early feedback and request additional information.

Please read [[Blueprints|OpenStack Blueprints]] page for detailed definition of blueprints and their lifecycle.

=== Implement new features ===
To implement a new feature, you will need to address the following:
# File a blueprint, with all required feature details, as described in [[Fuel/Where_to_contribute#Propose_enhancements|Propose enhancements]] section above and on [[Blueprints]] page
# PTL or core developers of Fuel should approve a blueprint, when all required information is provided.
# Please no active contribution unless there is an agreement on design. To get an approval, you can discuss a feature in the mailing list.
# Every new feature must not break other features, and whether work fine with features we had before, or be disabled in combination with features which do not work with the new one. Short list of features to check compatibility with:
#* All distributions (currently CentOS & Ubuntu)
#* Networking (nova-network, Neutron)
#* Combination with other roles on a node. For example, MongoDB role should not be placed with Ceph.
#* Disk partitioning (will it use existing partition or new one needs to be created?)
#* Network verification
# Other requirements for features:
#* logging of services should be done via rsyslog for Fuel Library contributions
#* implementation should be scalable, or otherwise limitations should be clearly stated in a design doc. It is unacceptable to degrade scalability and performance of already existing features.
# Start implementation and propose code changes frequently and by small pieces. This is the only way to successful merge - it is unrealistic to review changesets with 1000+ lines of code.
# Every feature should have a set of tests:
#* [https://github.com/stackforge/fuel-web/tree/master/nailgun/ui_tests CasperJS] and [https://github.com/stackforge/fuel-main/tree/master/fuelweb_ui_test Selenium] tests are for Fuel Web UI
#* [https://github.com/stackforge/fuel-web/tree/master/nailgun/nailgun/test Nailgun uses Python Unit Test framework] for unit and integration tests
#* [https://github.com/stackforge/fuel-astute/tree/master/spec Astute uses RSpec] for unit and integration tests
#* Consider extending [http://docs.mirantis.com/fuel-dev/develop/ostf_contributors_guide.html OSTF tests] for implemented feature
#* [https://github.com/stackforge/fuel-main/tree/master/fuelweb_test System tests], which use [http://docs.mirantis.com/fuel-dev/devops.html Devops framework], are run against an ISO, i.e. when all components are integrated. System tests last for up to 6-8 hours and run every night. As these tests are ran against integrated environment, their result represents a higher interest. Every large feature which has pieces in more than one Fuel component must be covered by system tests.
#* If feature requires special hardware, or special deployment setup, then existing CI should be extended with such hardware and required changes into devops framework. It should be discussed with the Fuel community in mailing list in order to come up with a joint decision.
# Documentation. New features must be well documented in both [[Fuel/Where_to_contribute#Documentation|user and development documentation]].
# Please propose changes for a feature before feature freeze date. Otherwise, changes won't be even reviewed before code freeze, and we will not let changes to land into master before milestone proposed branch is created. This will allow Fuel team to concentrate on stabilization of the current release, and put all the force into squashing bugs. Rules are similar to core OpenStack projects, see [[FeatureFreeze]] and [[ReleaseCycle]].

=Tests=
=== Unit and integration tests for Nailgun ===
[https://github.com/stackforge/fuel-web/tree/master/nailgun/nailgun/test Nailgun uses Python Unit Test framework] for unit and integration tests. Help in writing test is highly appreciated - we always want better coverage! Please checkout [http://docs.mirantis.com/fuel-dev/develop/env.html#setup-for-nailgun-unit-tests how to setup development environment for Nailgun tests], and follow [[Fuel/How_to_Test_Your_Code|How to Test Your Code]] guidance.

= Code review rules =
When contributing code changes to Fuel, please use the [http://docs.openstack.org/infra/manual/developers.html#development-workflow development workflow] and follow [[Fuel/Code_Review_Rules|Fuel specific rules and recommendations]].

Fuel

2014-04-07T23:49:39Z

Xarses: /* Join Fuel team */

= What is Fuel? =

Fuel is an all-in-one control plane for automated hardware discovery, network verification, operating systems provisioning and deployment of OpenStack. It provides user-friendly Web interface for installations management, simplifying OpenStack installation up to a few clicks.

This installer has been battle-tested during 2013 in a number of OpenStack deployments on platforms like as Dell (C6220 & R320), HP (DL380), Supermicro (6027TR-HTRF), Lenovo ThinkServer (RD530) and Cisco UCS-C.

The key features are:
* hardware discovery
* hardware configuration in UI (networks & disk partitioning)
* ability to spin up and manage multiple OpenStack clusters
* support for non-HA and HA OpenStack deployment configurations
* pre-deployment checks and network validation
* post-deployment checks and running a set of tests for validating deployed OpenStack
* view logs in real-time through UI
* support for CentOS and Ubuntu, and it can be extended to support other distributions too
* support for multiple OpenStack distributions

Mirantis uses Fuel as a part of their Openstack related solutions and they are our major contributor. For more details look at http://software.mirantis.com/

=Fuel architecture=
Fuel is not monolithic. It consists of several independent components. Some of those components are Fuel specific components, while others are third-party services like Cobbler, Puppet, Mcollective, etc.
* The heart of Fuel project is Nailgun. Nailgun as other Openstack projects is written in Python programming language. It implements REST API as well as deployment data management. It manage disk volumes configuration data, networks configuration data and any other environment specific data which are necessary for successful deployment. It has required orchestration logic to build instructions for provisioning and deployment in a right order. Nailgun uses SQL database to store its data and AMQP service to interact with workers.
* Another important component codenamed Astute implements Nailgun's workers, and it's function is to run certain actions according to the instructions provided from Nailgun. In fact, Astute is nothing more than just a layer which encapsulates all the details about interaction with a variety of services such as Cobbler, Puppet, shell scripts, etc. and provides universal asynchronous interface to those services. Depending on what we need to do we can either manage service directly via its native protocol (for example XML-RPC protocol is used for Cobbler) or we can use Mcollective agents to perform specific tasks such as launching "puppet apply" on a remote node or running a script. Astute is implemented as Ruby library and it is used in thin manager Naily, which represents AMQP consumer.
* Our provisioning service at the moment is Cobbler. There is a POC ready for move to Ironic, and production version is being implemented.
* Puppet is our only deployment service at the moment. It is possible to create MCollective agent to manage other configuration management frameworks, such as Chef, SaltStack, etc.
* We also have a set of Mcollective agents which allow us to perform specific tasks like hard drives clearing, network connectivity probing etc.
* OSTF (OpenStack Testing Framework, or Health Check) is separated component, which can be easily removed and reused without Fuel. It implements post-deployment verification of OpenStack. It's main goal is to verify maximum of functionality taking minimum of time.

<center>[[File:Fuel-architecture.png|850px]]</center>

=Fuel components=

====Web UI====
To get an idea about what Fuel web user interface looks like you can watch this video http://www.youtube.com/watch?v=PppYpbCg4AU This is the recording of Mike Scherbakov's speech at Openstack Summit in Portland in April 2013. Since that time a lot of new features were added but this video gives good introduction.

====CLI====

[[Fuel CLI|Understanding Environment deployment with Fuel CLI]]

====Nailgun====
This component is written in Python. It provides REST API and manages all the data about Openstack clusters deployment and management. It is the heart of Fuel.

====Astute====
Astute is written in Ruby. It is a wrapper around Mcollective. The majority of its functionality is implemented as Mcollective agents. It is mostly for launching arbitrary commands on remote nodes. For example we use it for launching "puppet apply" in order to install all necessary packages and configure services. Besides, it has driver for interaction with Cobbler.

=Join Fuel team=
==== Greeting ====
If you like the idea of free opensource software, if you like the idea of cloud computing, if you like the idea of making the world better, we certainly want you to join. We try to be as much open as possible. We are always glad to share our own experience as well as to adopt incoming ideas. Join us!

==== Weekly meeting ====
Fuel team holds weekly [https://wiki.openstack.org/wiki/Meetings/Fuel meetings] on Tuesdays at [http://www.worldtimebuddy.com/?qm=1&lid=100&h=100&date=2014-3-27&sln=16-17 1600 UTC] in IRC, at the #openstack-meeting-alt channel. If you have a topic to discuss, you can add it to the [https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda agenda].

==== IRC at freenode.net ====
{| border="1" cellpadding="2" cellspacing="0"
| #fuel
| General channel
|-
| #fuel-dev
| Development channel
|}

==== Source code ====
{| border="1" cellpadding="2" cellspacing="0"
| Build system
| https://github.com/stackforge/fuel-main
|-
| REST API + CLI + UI
| https://github.com/stackforge/fuel-web
|-
| Deployment orchestrator
| https://github.com/stackforge/fuel-astute
|-
| Puppet modules
| https://github.com/stackforge/fuel-library
|-
| User documentation
| https://github.com/stackforge/fuel-docs
|-
| Openstack Healthcheck
| https://github.com/stackforge/fuel-ostf
|}

==== Development related links ====
{| border="1" cellpadding="2" cellspacing="0"
| Launchpad project
| https://launchpad.net/fuel
|-
| Review in progress
| https://review.openstack.org/#/q/status:open+fuel,n,z
|-
| Development documentation
| http://docs.mirantis.com/fuel-dev
|-
| Slides
| https://docs.google.com/file/d/0B5VvW7EEta1WMTdFajRzY0lGbkU
|-
| Feature Design template
| https://docs.google.com/a/mirantis.com/document/d/1KlTTM0X-v9nVxyG1ZSdOEpf_yj4EtzNL1Q9Sd4v5DX0
|}

==== Roadmap ====
* Client python library to make third-party applications to use Fuel
* Pluggable architecture in order to easily add specific functionality
* Patching / Upgrade of Fuel itself
* Patching / Upgrade of Openstack (w/o or w/ minimal downtime)
* Closer integration with other Openstack services

==== Hacking ====
Please review this hacking section for some guidance into some come code contribution practices we use.

===== Adding new modules to fuel-library =====

====== Pulling in an existing module ======

If you are adding a module that is the work of another project and is already tracked in separate repo then:

#. Create a review request with a un-modified copy of the upstream module from what ever point you are working from and _no_ other related modifications.
* This review should also contain the commit hash from the upstream repo in the commit message.
* The review should be looked over for reasons for rejecting the entire module (Like license.)
Forbearing such issues it should be accepted with out requiring modifications.
#. Any changes necessary to make it work with fuel can then be proposed as a dependent change(s)

====== Adding a new module ======

If you are adding a new module that is a work purely for fuel and will not be tracked in a separate repo then

Submit either a complete single review (Large commits will delay review) OR

Submit incremental reviews that consist of working implementation of features for your module. If you have features that are necessary, but do not work fully yet, then prevent them from running during the deployment. Once you are feature complete, submit a review to activate the module during deployment.

==== Keywords ====
openstack deploy deployment havana grizzly cobbler install installation provisioning puppet mcollective tripleo ironic web cli ui opensource centos ubuntu redhat rhel distribution discovering python ruby diskimage-builder

Puppet/ceph-blueprint

2013-11-04T21:03:37Z

Xarses:

== Overview ==

This document is intended to capture requirements for a single [https://launchpad.net/puppet-ceph puppet-ceph module].

Very much like vswitch, Ceph is not exclusively used in the context of OpenStack. There is however a significant community relying on puppet to deploy Ceph in the context of OpenStack, as is shown in the [[#Related_tools_and_implementations inventory|of the existing efforts]] Having a puppet ceph module under the umbrella of the stackforge infrastructure helps federate the efforts while providing a workflow that will improve the overall quality of the module.

* [https://review.openstack.org/#/q/status:open+project:stackforge/puppet-ceph,n,z gerrit review page]
* [https://launchpad.net/puppet-ceph puppet-ceph at launchpad]

== Roadmap ==

Almost each component of this module deserve a discussion and it would take a long time to agree on everything before getting something useful. The following list sets the order in which each module is going to be implemented. Each step must be a useable puppet module, unit tested and including integration tests.

* [[#conf|conf]]
* [[#key|key]]
* [[#mon|mon]]
* [[#osd|osd]]
* [[#pool|pool]]
* [[#rbd|rbd]]

== User Stories ==

=== I want to try this module, heard of ceph, want to see it in action ===

/node/ {
ceph::conf { auth_enable: false };
ceph::mon;
ceph::osd { '/srv/osd1' };
ceph::osd { '/srv/osd2' };
}

* install puppet,
* paste this in site.pp and replace /node/ with the name of your current node,
* puppet apply site.pp ,
* ceph -s and see that it works

=== I want to run benchmarks on three new machines ===

* There are four machines, 3 OSD, 1 MON and one machine that is the client from which the user runs commands.
* install puppetmaster and create site.pp with:

/ceph-default/ {
ceph::conf { 'global':
auth_enable => false,
'mon host' => 'node1'
};
}

/node1/ inherits ceph-default {
ceph::mon;
ceph::osd { disk => 'discover' };
}

/node2/, /node3/ inherits ceph-default {
ceph::osd { disk => 'discover' };
}

/client/ inherits ceph-default {
ceph::client;
}

* ssh client
* rados bench
* interpret the results

=== I want to operate a production cluster ===

$admin_key = 'AQCTg71RsNIHORAAW+O6FCMZWBjmVfMIPk3MhQ=='
$mon_key = 'AQDesGZSsC7KJBAAw+W/Z4eGSQGAIbxWjxjvfw=='
$boostrap_osd_key = 'AQABsWZSgEDmJhAAkAGSOOAJwrMHrM5Pz5On1A=='

/ceph-default/ {
ceph::conf { 'mon host' => 'mon1,mon2,mon3' };
}

/mon[123]/ inherits ceph-default {
ceph::mon { key => $mon_key }
ceph::key { 'client.admin':
secret => $admin_key,
caps_mon => '*',
caps_osd => '*',
inject => true,
}
ceph::key { 'client.bootstrap-osd':
secret => $bootstrap_osd_key,
caps_mon => 'profile bootstrap-osd'
inject => true,
}
}

/osd*/ inherits ceph-default {
ceph::osd { disk => 'discover' };
ceph::key { 'client.bootstrap-osd':
keyring => '/var/lib/ceph/bootstrap-osd/ceph.keyring',
secret => $bootstrap_osd_key,
}
}

/client/ inherits ceph-default {
ceph::key { 'client.admin':
secret => $admin_key
}
ceph::client;
}

* the '''osd*''' nodes only contain disks that are used for OSD and using the '''discover''' option to automatically use new disks and provision them as part of the cluster is acceptable, there is no risk of destroying unrelated data.
* when a node dies, all its disks can be placed in another machines and the OSDs will automatically be re-inserted in the cluster, even if an external journal is used

=== I want to spawn a cluster configured with a puppetmaster as part of a continuous integration effort ===

''Leveraging vagrant, vagrant-openstack, openstack''
* Ceph is used as a backend storage for various use cases
* There are tests to make sure the Ceph cluster was instantiated properly
* There are tests to make sure various other infrastructure components (or products) can use the Ceph cluster

== Requirements ==

=== High level requirements ===

==== No complex cross host orchestration ====

All cross host orchestration should be assumed to be managed outside of Puppet. Provided that it's dependencies have already been configured and are known, each component should support being adding without having to run Puppet on more than one node.

For example

* cinder-volume instances should be configured to join a Ceph cluster simply by running Puppet on that node
* OSD instances should be configured to join a cluster simply by running puppet agent on a node and targeting that role.

All cross host orchestration should be assumed to be managed outside of Puppet. The Puppet implementation should only be concerned with

* what components need to be defined (where these are implemented as classes)
* what data is required for those components (where that data is passed in a class parameters)

==== Supporting versions ====

The Operating System versions supported must be tested with integration on the actual operating system. Although it is fairly to add support for an Operating System, it is prone to regressions if not tested. The per Operating System support strategy mimics the way OpenStack modules do it.

The supported versions of the components that deal with the environment in which Ceph is used ( OpenStack, Cloudstack, Ganeti etc. ) are handled by each component on a case by case basis. There probably is too much heterogeneity to set a rule.

==== Provide sensible defaults ====

If the high level components ( osd + mon + mds + rgw for instance ) are included without any parameter, the result must be a functional Ceph cluster.

==== Architectured to leverage Ceph to its full potential ====

It means talking to the MON when configuring or modifying the cluster, using ceph-disk as a low level tool to create the storage required for an OSD, creating a minimal /etc/ceph/ceph.conf to allow a client to connect to the Ceph cluster. The MON exposes a very rich API ( either via the ceph cli or a REST API ) and it offers a great flexibility to the system administrator. It is unlikely that the first versions of the puppet module captures all of it. But it should be architectured to allow the casual contributor to add a new feature or a new variation without the need to workaround architectural limitations.

The ceph-deploy utility is developed as part of the ceph project, to help people get up to speed as quickly as possible for test and POCs. Alfredo Deza made a compeling argument against using ceph-deploy as a helper for a puppet module. Because it is designed to hide some of the flexibility ceph offers for the sake of simplicity. An inconvenience that is incompatible with the goal of a puppet module designed to accommodate all use cases.

=== Prefer cli over REST ===

The ceph cli is preferred because the [http://ceph.com/docs/next/man/8/ceph-rest-api/ rest-api] requires the installation of an additional daemon.

=== Module versioning ===

Create a branch for each Ceph release ( stable/cuttlefish, stable/dumpling etc. ) and follow the same pattern as the OpenStack modules

=== Support Ceph versions from cuttlefish ===

Do not support Ceph versions released before cuttlefish

== Integration tests ==

All scenarios can probably be covered with 2 virtual machines, 2 interfaces and one disk attached to one of the machines. A number of scenarios can be based on a single machine, using directories instead of disks and a single interface.

* use https://github.com/puppetlabs/rspec-system-puppet and check that it can be used with the vagrant openstack backend https://github.com/cloudbau/vagrant-openstack-plugin
* use openstack by running a script like this with a dedicated tenant to prevent breakage ( see http://ci.openstack.org/third_party.html )
<pre>
export OS_PASSWORD=admin_pass
export OS_AUTH_URL=http://127.0.0.1:5000/v2.0/
export OS_USERNAME=admin
export OS_TENANT_NAME=openstack

ssh -p 29418 review.example.com gerrit stream-events |
while read event ; do
if event is commit ; then
git clone puppet-ceph from gerrit
cd puppet-ceph
bundle exec rake spec:system # https://github.com/puppetlabs/rspec-system-puppet#run-spec-tests
if fail ; then
ssh -p 29418 review.example.com \
gerrit review -m '"Test failed"' --verified=-1 c0ff33
fi
fi
done
</pre>

== Puppet user components ==

This section outlines the roles and well as configuration components that are visible to the puppet user. They must be understandable for the system administrator willing to deploy Ceph for the first time.

=== conf ===

Although the key separator can either be space or underscore, only '''space''' is allowed to help with consistency.

::[[User:Xarses|Xarses]] ([[User talk:Xarses|talk]]) hyphen is a also valid seperator. From my testing i found that the ini_file provider can not tell the difference in keys between "auth supported" and "auth_supported" which will lead to duplicate entries in ceph.conf if we aren't careful.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : since [https://github.com/ceph/ceph-deploy/commit/53f46a8451dd8e10a3b9e8f2b191044f9863ae83 ceph-deploy enforces the use of _] and for the sake of consistency, it is probably better to use undercore instead of space.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : bodep prefers ini, dalgaaf prefers concat, loic does not care but voted ini because there is more expertise, xarses and dmsimard +1 ini, mgagne does not object ini : it is going to be implemented as a provider such as nova_config.

::[[User:Danny Al-Gaaf|Danny Al-Gaaf]] ([[User talk:Danny Al-Gaaf|talk]]) If the ini_file provider has a problems with space and underscore as separator, it would be one more reason to use concat since this would force the type of key separator used in the template.

* '''proposed name''': ceph::conf
* '''purpose''': keeps and writes [http://ceph.com/docs/master/rados/configuration/osd-config-ref/ config] and their options for the top level sections of the ceph config. This includes these sections:
** [global]
** [mon]
** [osd]
** [mds]
* '''interface''': every key that is needed to write the base config ... the whole list would be to long to written down here
* auth_enable - true or false, enables/disables cephx, defaults to true
::If enable is true, set the following in the [global] section of the conf file:

auth cluster required = cephx
auth service required = cephx
auth client required = cephx
auth supported = cephx

::If enable is false, set the following in the [global] section of the conf file:

auth cluster required = none
auth service required = none
auth client required = none
auth supported = none

::It should support [http://ceph.com/docs/master/rados/operations/authentication/#disabling-cephx disabling] or [http://ceph.com/docs/master/rados/operations/authentication/#enabling-cephx enabling] cephx when the values change. If it does not support updating, it must fail when changed on an existing Ceph cluster.

Using a [https://github.com/puppetlabs/puppetlabs-inifile inifile] child provider ( such as [https://github.com/stackforge/puppet-cinder/blob/master/lib/puppet/provider/cinder_config/ini_setting.rb cinder_config] ) a setting would look like

ceph_conf {
'GLOBAL/fsid': value => $fsid;
}

And create '''/etc/ceph/ceph.conf''' such as:

[global]
fsid = 918340183294812038

Improvements to be implemented later:
* If a key/value pair is modified in the *mon*, *osd* or *mds* sections, all daemons are [http://ceph.com/docs/master/rados/configuration/ceph-conf/#runtime-changes notified of the change] with ceph {daemon} tell * ....

=== osd ===

* '''proposed name''': ceph::osd
* '''purpose''': configures a ceph OSD using the ceph-disk helper and update the /etc/ceph/ceph.conf file with [osd.X] sections matching the osd found in /var/lib/ceph/osd
* '''interface''':
** directory/disk - a disk or a directory to be used as a storage for the OSD.
** bootstrap-osd - the bootstrap-osd secret key (optional if cephx = none )
** dmcrypt - options needed to encrypt disks (optional)

The generated [osd.X] section must contain the host and disk so that rcscript run the osd daemon at boot time.

If the directory/disk is set to '''discover''', ceph-disk list is used to find unknown disks or partitions. All unknown disks are prepared with ceph-disk prepare. That effectively allows someone to say : use whatever disks are not in use for ceph and leave the rest alone. An operator would only have to add new disk and way for the next puppet client pass to have them integrated in the cluster. If a disk is removed, the OSD is not launched at boot time and there is nothing to do.

Support [https://github.com/ceph/ceph/blob/v0.61.9/src/ceph-disk#L2027 ceph-disk suppress]

Here is what should happen on a node with at least one OSD
* common to all OSD on the same node:
** the /etc/ceph/ceph.conf file is setup with the IPs of the monitors
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L47 the /var/lib/ceph/bootstrap-osd/{cluster}.bootstrap-osd.keyring] file contains a user/key that is used to to create an OSD. The bootstrap-osd user key is usually the same for all OSD. For instance:
[client.bootstrap-osd]
key = AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
** The user bootstrap-osd with this key with caps to bootstrap an OSD:
$ ceph auth list
...
client.bootstrap-osd
key: AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
caps: [mon] allow profile bootstrap-osd
* for each OSD
** in the same way [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L104 ceph-deploy prepare the disk] call ceph-disk-prepare that will [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1031 set magic partition uuid] and trigger [https://github.com/ceph/ceph/blob/master/udev/95-ceph-osd.rules#L11 udev rules] to [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L453 ceph osd create]. When udev settles, the new osd is integrated into the cluster and uses its own key, created, registered to the MON and stored locally as a side effect of [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1301 --mkkey]. The osd daemon is also run as a side effect of udev detecting the disk and calling [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1414 /etc/init/ceph-osd.conf]. ceph-disk contains a [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L18 high level description of the process]
** '''dmcrypt''' is also handled by the udev logic ( details ??? keys ??? )

At boot time the [https://github.com/ceph/ceph/blob/master/src/upstart/ceph-osd-all-starter.conf#L14 /var/lib/ceph/osd directory is explored] to discover all OSDs that need to be started. Operating systems for which the same logic is not implemented will need an additional script run at boot time to perform the same exploration until the default script is updated to add this capability.

=== mds ===

* '''proposed name''': ceph::mds
* '''purpose''': configures a ceph MDS, setup /etc/ceph/ceph.conf with the MONs IPs, declare the MDS to the cluster via the MON, optionaly set the key to allow the MDS to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user

=== mon ===

Creates the files and keyring supporting a mon, runs the daemon

* '''proposed name''': ceph::mon
* '''purpose''': configures a ceph MON
* '''interface''':
** cluster - cluster name ( defaults to ceph )
** id - the id of the mon
** ip_address - the ip addresses of the mon
** key - the mon. user key

* add a [mon.$id] section to the conf file (depends on ceph::conf to write the base part of the config)
* if auth == cephx
** the mon. key is mandatory and need to be set by the user to be a valid ceph key. The documentation should contain an example key and explanations about how to [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L20 create an auth key].
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L86 writes the keyring]
* installs the packages
* ceph-mon --id 0 --mkfs
* runs the mon daemon

=== rbd ===

* '''proposed name''': ceph::rbd
* '''purpose''': maps and mounts a rbd image, taking care of dependencies (packages, rbd kernel module, /etc/ceph/rbdmap, fstab)
* '''interface''':
** name - the name of the image
** pool - the pool in which the image is
** mount_point - where the image will be mounted
** key - the secret key for the id user
** id - the id of the user
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

=== cephfs ===

* '''proposed name''': ceph::cephfs
* '''purpose''': mounts a cephfs filesystem, taking care of dependencies (e.g, fstab, packages)
* '''interface''':
** Lots - See http://ceph.com/docs/next/man/8/mount.ceph/
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

== Implementor components ==

These components are dependencies of the Puppet user components and can be used by other components. They should be a library of components where the code common to at least two independant components ( think OpenStack and Cloudstack ) is included.

=== repository ===

Inspired by [https://github.com/stackforge/puppet-openstack/blob/master/manifests/repo.pp openstack::repo].

* '''proposed name''': ceph::repo
* '''purpose''': use puppetlabs/apt to configure the official ceph repository so we can install ceph packages
* '''interface''':
** release: target ceph release (cuttlefish, dumpling, etc)

=== ceph client implementation ===

* '''proposed name''': ceph::client
* '''purpose''': setup /etc/ceph/ceph.conf to connect to the Ceph cluster and install the ceph cli
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** client_id - name of the client to find the correct id for key
** keypath - path to the clients key file

=== key ===

Keyring management, authentication. It would be a class to create keys for new users (e.g. a user that can create RBDs or use the Objectstore) which may require special access rights. But would also be used by the other classes like ceph::mon or ceph::osd to place e.g. the shared 'client.admin' or 'mon.' keys.

* '''proposed name''': ceph::key
* '''purpose''': handles ceph keys (cephx), generates keys, creates keyring files, inject keys into or delete keys from the cluster/keyring via ceph and ceph-authtool tools.
* '''interface''':
** secret - key secret
** keyring_path - path to the keyring
** cap_mon/cap_osd/cap_mds - cephx capabilities
** user/group/mode: settings for the keyring file if needed
** inject - options to inject a key into the cluster

See [https://github.com/TelekomCloud/puppet-ceph/blob/rc/eisbrecher/manifests/key.pp key.pp] for an example implementation of this semantic.

=== pool ===

* '''proposed name''': ceph::pool
* '''purpose''': manage operations on the pools in the cluster such as: create/delete pools, set PG/PGP number
* '''interface''':
** pool_name - name of the pool
** create - if to create a new pool
** delete - if to delete an existing pool
** pg_num - number of Placement Groups (PGs) for a pool, if the pool already exists this may increase the number of PGs if the current value is lower
** pgp_num - same as for pg_num
** replica_level - increase or decrease the replica level of a pool

== OpenStack components ==

ceph specific configuration for cinder/glance (already provided by the puppet-cinder and puppet-glance modules in the volume/rdb and backend/rdb classes). RGW Keystone is noted below

:: --[[User:Xarses|xarses]] ([[User talk:Xarses|talk]]) RGW keystone should be included in the ceph module as RGW is the consumer of the keystone service. Unlike cinder/glance where they are consumers of ceph.

== RadosGW components ==

The RadosGW is developped as an integral part of Ceph. It is however not required to deploy a cluster and should be treated as any client application of the cluster.

=== rgw ===

* '''proposed name''': ceph::rgw
* '''purpose''': configures a ceph radosgw , setup /etc/ceph/ceph.conf with the MONs IPs, optionaly set the key to allow the OSD to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user
** rgw_data - the path where the radosgw data should be stored
** fcgi_file - path to the fcgi file e.g. /var/www/s3gw.fcgi
:: [[User:Danny Al-Gaaf|Danny Al-Gaaf]] ([[User talk:Danny Al-Gaaf|talk]]) the monitor_ips are not needed: IMO ceph::conf should provide these information to all other
:: --[[User:Xarses|xarses]] ([[User talk:Xarses|talk]]) agree with Danny; we are missing:
** user - user to run rados as as well as own files
** host - hostname for this ini section
** keyring_path - path to key file
** log_file - where to write logs to
** rgw_dns_name - dns name (may include wildcard ) to use with s3 api calls
** rgw_socket_path - path to socket file
** rgw_print_continue - (bool) if we are going to send 100 codes to the client

:: --[[User:Xarses|xarses]] ([[User talk:Xarses|talk]]) also we should include apache magic here to setup vhost and script-server. in which case we should also support *port* param.

=== rgw kestone ===

* '''proposed name''': ceph::rgw::keystone
* '''purpose''': extends radosgw configuration to be able to retrieve auth from keystone tokens and setup keystone endpoint
* '''interface''':
** rgw_keystone_url - the internal or admin url for keystone
** rgw_keystone_admin_token - the admin token for keystone
** rgw_keystone_accepted_roles - which roles should we accept from keystone
** rgw_keystone_token_cache_size - how many tokens to keep cached, not useful if not using PKI as every token is checked
** rgw_keystone_revocation_interval - interval to check for expired tokens, not useful if not using PKI tokens (if not, set to high value)
** use_pki - (bool) to determine if keystone is using token_format = PKI and if so do PKI signing parts
** nss_db_path - path to NSS < - > keystone tokens db files

=== rgw_user ===

* '''proposed name''': ceph::rgw_user
* '''purpose''': create/remove users and Swift users for the RadosGW S3/Swift API
* '''interface''':
** user - username
** key - secret key (could get generated if needed)
** swift_user - username for the Swift API user
** swift_key - secret key for the Swift API user

== Related tools and implementations ==

* deploy ceph : ceph-deploy

for test / POC purposes
https://github.com/ceph/ceph-deploy

maintainer: Alfredo Deza

* deploy ceph with puppet : puppet-cephdeploy

relies on ceph-deploy
https://github.com/dontalton/puppet-cephdeploy/

maintainer: Don Talton

* deploy ceph with puppet : puppet-ceph

developped in 2012 but still useful, upstream
https://github.com/enovance/puppet-ceph

maintainer: community

fork of puppet-ceph, updated recently
https://github.com/TelekomCloud/puppet-ceph/tree/rc/eisbrecher

maintainer: Deutsche Telekom AG (DTAG)

* ceph + openstack : ceph docs

manual integration
http://ceph.com/docs/next/rbd/rbd-openstack/
maintainer: John Wilkins + Josh Durgin

* ceph + openstack with puppet : stackforge

https://github.com/stackforge/puppet-glance/blob/stable/grizzly/manifests/backend/rbd.pp
https://github.com/stackforge/puppet-cinder/blob/stable/grizzly/manifests/volume/rbd.pp

maintainer: community

* ceph + openstack with puppet : COI

targeting Cisco use case
https://github.com/CiscoSystems/puppet-coe/tree/grizzly/manifests/ceph
http://docwiki.cisco.com/wiki/OpenStack:Ceph-COI-Installation

maintainer : Don Talton + Robert Starmer

* ceph + openstack with puppet : mirantis

in the context of Fuel
https://github.com/Mirantis/fuel/tree/master/deployment/puppet/ceph
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/cinder/manifests/volume/ceph.pp
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/glance/manifests/backend/ceph.pp

maintainer : Andrew Woodward

* openstack with puppet : openstack-installer

data driven approach to deploy OpenStack
https://github.com/CiscoSystems/openstack-installer/

maintainer: Robert Starmer + Dan Bode

Puppet/bp-cinder-volume-multi-backend

2013-10-29T22:15:08Z

Xarses: /* Use two or more cinder-volume backends and assign them to different types */

==Overview==

We should be able to support [[Cinder-multi-backend]]

This moving this way would allow us to support multiple concurent backends.

==user story==

===Use a single cinder-volume backend===
currently you can

class { 'cinder::volume': }

class { 'cinder::volume::iscsi':
iscsi_ip_address => '10.0.0.2',
}

===Use two or more cinder-volume backends and assign them to different types===

class { 'cinder::volume': }

cinder::backend::rbd {'images':
rbd_user => 'images',
rbd_pool => 'images',
}

cinder::backend::iscsi {'local-lvm':
iscsi_ip_address => '10.0.0.2',
}

cinder::volume_type {'standard':
backends => ['images', 'local-lvm']

===Use three or more cinder-volume backends and assign them two to one type and the other to another ===
...

==Requirements==

# must configure as many supported backends as possible
# must be comptible with only defining one single backend
# must configure cinder volume_type [http://www.sebastien-han.fr/blog/2013/04/25/ceph-and-cinder-multi-backend/ example]
# if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)

==Components==

===backends===
===volume_types===

Puppet/bp-cinder-volume-multi-backend

2013-10-29T22:14:47Z

Xarses:

==Overview==

We should be able to support [[Cinder-multi-backend]]

This moving this way would allow us to support multiple concurent backends.

==user story==

===Use a single cinder-volume backend===
currently you can

class { 'cinder::volume': }

class { 'cinder::volume::iscsi':
iscsi_ip_address => '10.0.0.2',
}

===Use two or more cinder-volume backends and assign them to different types===

class { 'cinder::volume': }

cinder::backend::rbd {'images':
rbd_user => 'images',
rbd_pool => 'images',
}

cinder::backend::iscsi {'local-lvm':
iscsi_ip_address => '10.0.0.2',
}

cinder::volume_type {'standard':
backends => ['images', 'local-lvm']

cinder::backend::rbd {'images':
rbd_user => 'images',
rbd_pool => 'images',
type = 'silver',
}

===Use three or more cinder-volume backends and assign them two to one type and the other to another ===
...

==Requirements==

# must configure as many supported backends as possible
# must be comptible with only defining one single backend
# must configure cinder volume_type [http://www.sebastien-han.fr/blog/2013/04/25/ceph-and-cinder-multi-backend/ example]
# if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)

==Components==

===backends===
===volume_types===

Puppet/bp-cinder-volume-multi-backend

2013-10-23T23:08:50Z

Xarses:

==Overview==

We should be able to support [[Cinder-multi-backend]]

This moving this way would allow us to support multiple concurent backends.

==user story==

===Use a single cinder-volume backend===
currently you can

class { 'cinder::volume': }

class { 'cinder::volume::iscsi':
iscsi_ip_address => '10.0.0.2',
}

===Use two or more cinder-volume backends and assign them to different types===

class { 'cinder::volume': }

cinder::backend::rbd {'images':
rbd_user => 'images',
rbd_pool => 'images',
}

cinder::backend::iscsi {'local-lvm':
iscsi_ip_address => '10.0.0.2',
}

cinder::volume_type {'standard':
backends => ['images', 'local-lvm']

alternatly

#init cinder-volume and config
class { '::cinder::volume': }

#different backends have different settings so they should be called alone
cinder::backend::iscsi { 'local-lvm':
iscsi_ip_address => '10.108.1.1',
type => 'bronze',
}

cinder::backend::rbd {'images':
rbd_user => 'images',
rbd_pool => 'images',
type = 'silver',
}

===Use three or more cinder-volume backends and assign them two to one type and the other to another ===
...

==Requirements==

# must configure as many supported backends as possible
# must be comptible with only defining one single backend
# must configure cinder volume_type [http://www.sebastien-han.fr/blog/2013/04/25/ceph-and-cinder-multi-backend/ example]
# if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)

==Components==

===backends===
===volume_types===

Puppet/bp-cinder-volume-multi-backend

2013-10-22T23:46:35Z

Xarses:

Puppet/bp-cinder-volume-multi-backend

2013-10-22T23:30:33Z

Xarses: /* Use two or more cinder-volume backends and assign them to different types */

==Overview==

We should be able to support [https://wiki.openstack.org/wiki/Cinder-multi-backend Cinder-multi-backend]

This moving this way would allow us to support multiple concurent backends.

==user story==

===Use a single cinder-volume backend===
currently you can

class { 'cinder::volume': }

class { 'cinder::volume::iscsi':
iscsi_ip_address => '10.0.0.2',
}

===Use two or more cinder-volume backends and assign them to different types===

class { 'cinder::volume': }

cinder::backend::rbd {'images':
rbd_user => 'images',
rbd_pool => 'images',
}

cinder::backend::iscsi {'local-lvm':
iscsi_ip_address => '10.0.0.2',
}

cinder::type {'standard':
backends => ['images', 'local-lvm']

===Use three or more cinder-volume backends and assign them two to one type and the other to another ===
...

==Requirements==

# must configure as many supported backends as possible
# must be comptible with only defining one single backend
# must configure cinder type [http://www.sebastien-han.fr/blog/2013/04/25/ceph-and-cinder-multi-backend/ example]
# if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)

==Components==

===backends===
===storage_types===

Puppet/bp-cinder-volume-multi-backend

2013-10-22T23:19:30Z

Xarses: /* Use a single cinder-volume backend */

==Overview==

We should be able to support [https://wiki.openstack.org/wiki/Cinder-multi-backend Cinder-multi-backend]

This moving this way would allow us to support multiple concurent backends.

==user story==

===Use a single cinder-volume backend===
currently you can

class { 'cinder::volume': }

class { 'cinder::volume::iscsi':
iscsi_ip_address => '10.0.0.2',
}

===Use two or more cinder-volume backends and assign them to different types===
...

===Use three or more cinder-volume backends and assign them two to one type and the other to another ===
...

==Requirements==

# must configure as many supported backends as possible
# must be comptible with only defining one single backend
# must configure cinder type [http://www.sebastien-han.fr/blog/2013/04/25/ceph-and-cinder-multi-backend/ example]
# if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)

==Components==

===backends===
===storage_types===

Puppet/bp-cinder-volume-multi-backend

2013-10-22T23:17:02Z

Xarses: /* Use a single cinder-volume backend */

==Overview==

We should be able to support [https://wiki.openstack.org/wiki/Cinder-multi-backend Cinder-multi-backend]

This moving this way would allow us to support multiple concurent backends.

==user story==

===Use a single cinder-volume backend===

class { 'cinder::volume': }

class { 'cinder::volume::iscsi':
iscsi_ip_address => '10.0.0.2',
}

===Use two or more cinder-volume backends and assign them to different types===
...

===Use three or more cinder-volume backends and assign them two to one type and the other to another ===
...

==Requirements==

# must configure as many supported backends as possible
# must be comptible with only defining one single backend
# must configure cinder type [http://www.sebastien-han.fr/blog/2013/04/25/ceph-and-cinder-multi-backend/ example]
# if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)

==Components==

===backends===
===storage_types===

Puppet/bp-cinder-volume-multi-backend

2013-10-22T22:52:54Z

Xarses:

==Overview==

We should be able to support [https://wiki.openstack.org/wiki/Cinder-multi-backend Cinder-multi-backend]

This moving this way would allow us to support multiple concurent backends.

==user story==

===Use a single cinder-volume backend===
...

===Use two or more cinder-volume backends and assign them to different types===
...

===Use three or more cinder-volume backends and assign them two to one type and the other to another ===
...

==Requirements==

# must configure as many supported backends as possible
# must be comptible with only defining one single backend
# must configure cinder type [http://www.sebastien-han.fr/blog/2013/04/25/ceph-and-cinder-multi-backend/ example]
# if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)

==Components==

===backends===
===storage_types===

Puppet/bp-cinder-volume-multi-backend

2013-10-22T22:12:07Z

Xarses:

=Blueprint for cinder-volume to support multiple concurent storage drivers=

We should be able to support [https://wiki.openstack.org/wiki/Cinder-multi-backend Cinder-multi-backend]

This page has been created to start tracking discussion on direction prior to implmentation.

Puppet/bp-cinder-volume-multi-backend

2013-10-22T22:10:59Z

Xarses:

=Blueprint for cinder-volume to support multiple concurent storage drivers=

We should be able to support [[https://wiki.openstack.org/wiki/Cinder-multi-backend]]

This page has been created to start tracking discussion on direction prior to implmentation.

Puppet/bp-cinder-volume-multi-backend

2013-10-22T22:08:02Z

Xarses: init

init.

Puppet/ceph-blueprint

2013-10-21T21:01:21Z

Xarses: remove stupid dupes i added

== Overview ==

This document is intended to capture requirements for a single [https://launchpad.net/puppet-ceph puppet-ceph module].

Very much like vswitch, Ceph is not exclusively used in the context of OpenStack. There is however a significant community relying on puppet to deploy Ceph in the context of OpenStack, as is shown in the [#Related_tools_and_implementations|inventory of the existing efforts] Having a puppet ceph module under the umbrella of the stackforge infrastructure helps federate the efforts while providing a workflow that will improve the overall quality of the module.

* [https://review.openstack.org/#/q/status:open+project:stackforge/puppet-ceph,n,z gerrit review page]
* [https://launchpad.net/puppet-ceph puppet-ceph at launchpad]

== Roadmap ==

Almost each component of this module deserve a discussion and it would take a long time to agree on everything before getting something useful. The following list sets the order in which each module is going to be implemented. Each step must be a useable puppet module, unit tested and including integration tests.

* [[#conf|conf]]
* [[#key|key]]
* [[#mon|mon]]
* [[#osd|osd]]
* [[#pool|pool]]
* [[#rbd|rbd]]

== User Stories ==

=== I want to try this module, heard of ceph, want to see it in action ===

/node/ {
ceph::conf { auth_enable: false };
ceph::mon;
ceph::osd { '/srv/osd1' };
ceph::osd { '/srv/osd2' };
}

* install puppet,
* paste this in site.pp and replace /node/ with the name of your current node,
* puppet apply site.pp ,
* ceph -s and see that it works

=== I want to run benchmarks on three new machines ===

* There are four machines, 3 OSD, 1 MON and one machine that is the client from which the user runs commands.
* install puppetmaster and create site.pp with:

/ceph-default/ {
ceph::conf { auth_enable: false };
ceph::conf { 'mon host': 'node1' };
}

/node1/ inherits ceph-default {
ceph::mon;
ceph::osd;
}

/node2/, /node3/ inherits ceph-default {
ceph::osd;
}

/client/ inherits ceph-default {
ceph::client;
}

* ssh client
* rados bench
* interpret the results

=== I want to spawn a cluster configured with a puppetmaster as part of a continuous integration effort ===

''Leveraging vagrant, vagrant-openstack, openstack''
* Ceph is used as a backend storage for various use cases
* There are tests to make sure the Ceph cluster was instantiated properly
* There are tests to make sure various other infrastructure components (or products) can use the Ceph cluster

== Requirements ==

=== High level requirements ===

==== No complex cross host orchestration ====

All cross host orchestration should be assumed to be managed outside of Puppet. Provided that it's dependencies have already been configured and are known, each component should support being adding without having to run Puppet on more than one node.

For example

* cinder-volume instances should be configured to join a Ceph cluster simply by running Puppet on that node
* OSD instances should be configured to join a cluster simply by running puppet agent on a node and targeting that role.

All cross host orchestration should be assumed to be managed outside of Puppet. The Puppet implementation should only be concerned with

* what components need to be defined (where these are implemented as classes)
* what data is required for those components (where that data is passed in a class parameters)

==== Supporting versions ====

The Operating System versions supported must be tested with integration on the actual operating system. Although it is fairly to add support for an Operating System, it is prone to regressions if not tested. The per Operating System support strategy mimics the way OpenStack modules do it.

The supported versions of the components that deal with the environment in which Ceph is used ( OpenStack, Cloudstack, Ganeti etc. ) are handled by each component on a case by case basis. There probably is too much heterogeneity to set a rule.

==== Provide sensible defaults ====

If the high level components ( osd + mon + mds + rgw for instance ) are included without any parameter, the result must be a functional Ceph cluster.

==== Architectured to leverage Ceph to its full potential ====

It means talking to the MON when configuring or modifying the cluster, using ceph-disk as a low level tool to create the storage required for an OSD, creating a minimal /etc/ceph/ceph.conf to allow a client to connect to the Ceph cluster. The MON exposes a very rich API ( either via the ceph cli or a REST API ) and it offers a great flexibility to the system administrator. It is unlikely that the first versions of the puppet module captures all of it. But it should be architectured to allow the casual contributor to add a new feature or a new variation without the need to workaround architectural limitations.

The ceph-deploy utility is developed as part of the ceph project, to help people get up to speed as quickly as possible for test and POCs. Alfredo Deza made a compeling argument against using ceph-deploy as a helper for a puppet module. Because it is designed to hide some of the flexibility ceph offers for the sake of simplicity. An inconvenience that is incompatible with the goal of a puppet module designed to accommodate all use cases.

=== Prefer cli over REST ===

The ceph cli is preferred because the [http://ceph.com/docs/next/man/8/ceph-rest-api/ rest-api] requires the installation of an additional daemon.

=== Module versioning ===

Create a branch for each Ceph release ( stable/cuttlefish, stable/dumpling etc. ) and follow the same pattern as the OpenStack modules

=== Support Ceph versions from cuttlefish ===

Do not support Ceph versions released before cuttlefish

== Integration tests ==

All scenarios can probably be covered with 2 virtual machines, 2 interfaces and one disk attached to one of the machines. A number of scenarios can be based on a single machine, using directories instead of disks and a single interface.

Use https://github.com/puppetlabs/rspec-system-puppet

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : I mean it would have to somehow leverage things ( what ? how ? ) in the openstack-ci infrastructure ?

== Puppet user components ==

This section outlines the roles and well as configuration components that are visible to the puppet user. They must be understandable for the system administrator willing to deploy Ceph for the first time.

=== conf ===

Although the key separator can either be space or underscore, only '''space''' is allowed to help with consistency.

::[[User:Xarses|Xarses]] ([[User talk:Xarses|talk]]) hyphen is a also valid seperator. From my testing i found that the ini_file provider can not tell the difference in keys between "auth supported" and "auth_supported" which will lead to duplicate entries in ceph.conf if we aren't careful.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : since [https://github.com/ceph/ceph-deploy/commit/53f46a8451dd8e10a3b9e8f2b191044f9863ae83 ceph-deploy enforces the use of _] and for the sake of consistency, it is probably better to use undercore instead of space.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : bodep prefers ini, dalgaaf prefers concat, loic does not care but voted ini because there is more expertise, xarses and dmsimard +1 ini, mgagne does not object ini : it is going to be implemented as a provider such as nova_config.

* '''proposed name''': ceph::conf
* '''purpose''': keeps and writes [http://ceph.com/docs/master/rados/configuration/osd-config-ref/ config] and their options for the top level sections of the ceph config. This includes these sections:
** [global]
** [mon]
** [osd]
** [mds]
* '''interface''': every key that is needed to write the base config ... the whole list would be to long to written down here
* auth_enable - true or false, enables/disables cephx, defaults to true
::If enable is true, set the following in the [global] section of the conf file:

auth cluster required = cephx
auth service required = cephx
auth client required = cephx
auth supported = cephx

::If enable is false, set the following in the [global] section of the conf file:

auth cluster required = none
auth service required = none
auth client required = none
auth supported = none

::It should support [http://ceph.com/docs/master/rados/operations/authentication/#disabling-cephx disabling] or [http://ceph.com/docs/master/rados/operations/authentication/#enabling-cephx enabling] cephx when the values change. If it does not support updating, it must fail when changed on an existing Ceph cluster.

Using a [https://github.com/puppetlabs/puppetlabs-inifile inifile] child provider ( such as [https://github.com/stackforge/puppet-cinder/blob/master/lib/puppet/provider/cinder_config/ini_setting.rb cinder_config] ) a setting would look like

ceph_conf {
'GLOBAL/fsid': value => $fsid;
}

And create '''/etc/ceph/ceph.conf''' such as:

[global]
fsid = 918340183294812038

Improvements to be implemented later:
* If a key/value pair is modified in the *mon*, *osd* or *mds* sections, all daemons are [http://ceph.com/docs/master/rados/configuration/ceph-conf/#runtime-changes notified of the change] with ceph {daemon} tell * ....

=== osd ===

* '''proposed name''': ceph::osd
* '''purpose''': configures a ceph OSD using the ceph-disk helper
* '''interface''':
** directory/disk - a disk or a directory to be used as a storage for the OSD (optional)
** bootstrap-osd - the bootstrap-osd secret key (optional if cephx = none )
** dmcrypt - options needed to encrypt disks (optional)

If the directory/disk is omitted, ceph-disk list is used to find unknown disks or partitions. All unknown disks are prepared with ceph-disk prepare. That effectively allows someone to say : use whatever disks are not in use for ceph and leave the rest alone. An operator would only have to add new disk and way for the next puppet client pass to have them integrated in the cluster. If a disk is removed, the OSD is not launched at boot time and there is nothing to do.

Here is what should happen on a node with at least one OSD
* common to all OSD on the same node:
** the /etc/ceph/ceph.conf file is setup with the IPs of the monitors
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L47 the /var/lib/ceph/bootstrap-osd/{cluster}.bootstrap-osd.keyring] file contains a user/key that is used to to create an OSD. The bootstrap-osd user key is usually the same for all OSD. For instance:
[client.bootstrap-osd]
key = AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
** The user bootstrap-osd with this key with caps to bootstrap an OSD:
$ ceph auth list
...
client.bootstrap-osd
key: AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
caps: [mon] allow profile bootstrap-osd
* for each OSD
** in the same way [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L104 ceph-deploy prepare the disk] call ceph-disk-prepare that will [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1031 set magic partition uuid] and trigger [https://github.com/ceph/ceph/blob/master/udev/95-ceph-osd.rules#L11 udev rules] to [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L453 ceph osd create]. When udev settles, the new osd is integrated into the cluster and uses its own key, created, registered to the MON and stored locally as a side effect of [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1301 --mkkey]. The osd daemon is also run as a side effect of udev detecting the disk and calling [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1414 /etc/init/ceph-osd.conf]. ceph-disk contains a [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L18 high level description of the process]
** '''dmcrypt''' is also handled by the udev logic ( details ??? keys ??? )

At boot time the [https://github.com/ceph/ceph/blob/master/src/upstart/ceph-osd-all-starter.conf#L14 /var/lib/ceph/osd directory is explored] to discover all OSDs that need to be started. Operating systems for which the same logic is not implemented will need an additional script run at boot time to perform the same exploration until the default script is updated to add this capability.

=== mds ===

* '''proposed name''': ceph::mds
* '''purpose''': configures a ceph MDS, setup /etc/ceph/ceph.conf with the MONs IPs, declare the MDS to the cluster via the MON, optionaly set the key to allow the MDS to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user

=== mon ===

Creates the files and keyring supporting a mon, runs the daemon

* '''proposed name''': ceph::mon
* '''purpose''': configures a ceph MON
* '''interface''':
** cluster - cluster name ( defaults to ceph )
** id - the id of the mon
** ip_address - the ip addresses of the mon
** key - the mon. user key

* add a [mon.$id] section to the conf file (depends on ceph::conf to write the base part of the config)
* if auth == cephx
** the mon. key is mandatory and need to be set by the user to be a valid ceph key. The documentation should contain an example key and explanations about how to [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L20 create an auth key].
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L86 writes the keyring]
* installs the packages
* ceph-mon --id 0 --mkfs
* runs the mon daemon

=== rbd ===

* '''proposed name''': ceph::rbd
* '''purpose''': maps and mounts a rbd image, taking care of dependencies (packages, rbd kernel module, /etc/ceph/rbdmap, fstab)
* '''interface''':
** name - the name of the image
** pool - the pool in which the image is
** mount_point - where the image will be mounted
** key - the secret key for the id user
** id - the id of the user
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

=== cephfs ===

* '''proposed name''': ceph::cephfs
* '''purpose''': mounts a cephfs filesystem, taking care of dependencies (e.g, fstab, packages)
* '''interface''':
** Lots - See http://ceph.com/docs/next/man/8/mount.ceph/
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

== Implementor components ==

These components are dependencies of the Puppet user components and can be used by other components. They should be a library of components where the code common to at least two independant components ( think OpenStack and Cloudstack ) is included.

=== package ===

Although some distributions include packages for Ceph, it is recommended to install from the packages available from ceph.com http://ceph.com/docs/next/install/. It is not recommended to install the Ceph package provided by the standard repositories. This will change over time and the need to use the repository provided by ceph.com will gradually become less common.

The use of the repositories from ceph.com should be documented in the README.md with a apt {} based example to clarify that the user is expected to get up to date packages repositories.

* Mimic https://github.com/stackforge/puppet-nova/blob/master/manifests/params.pp#L8 for cross distribution package name

=== ceph client implementation ===

* '''proposed name''': ceph::client
* '''purpose''': setup /etc/ceph/ceph.conf to connect to the Ceph cluster and install the ceph cli
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** client_id - name of the client to find the correct id for key
** keypath - path to the clients key file

=== key ===

Keyring management, authentication. It would be a class to create keys for new users (e.g. a user that can create RBDs or use the Objectstore) which may special access rights. But would also be used by the other classes like ceph::mon or ceph::osd to place e.g. the shared 'client.admin' or 'mon.' keys. I would handle here all key related tasks.

* '''proposed name''': ceph::key
* '''purpose''': handles ceph keys (cephx), generates keys, creates keyring files, incject keys into or delete keys from the cluster/keyring via ceph and ceph-authtool tools.
* '''interface''':
** secret - key secret
** keyring_path - path to the keyring
** cap_mon/cap_osd/cap_mds - cephx capabilities
** user/group/mode: settings for the keyring file if needed
** inject - options to inject a key into the cluster

=== pool ===

* '''proposed name''': ceph::pool
* '''purpose''': manage operations on the pools in the cluster such as: create/delete pools, set PG/PGP number
* '''interface''':
** pool_name - name of the pool
** create - if to create a new pool
** delete - if to delete an existing pool
** pg_num - number of Placement Groups (PGs) for a pool, if the pool already exists this may increase the number of PGs if the current value is lower
** pgp_num - same as for pg_num
** replica_level - increase or decrease the replica level of a pool

== OpenStack components ==

ceph specific configuration for cinder/glance (already provided by the puppet-cinder and puppet-glance modules in the volume/rdb and backend/rdb classes)

== RadosGW components ==

The RadosGW is developped as an integral part of Ceph. It is however not required to deploy a cluster and should be treated as any client application of the cluster.

=== rgw ===

* '''proposed name''': ceph::rgw
* '''purpose''': configures a ceph radosgw , setup /etc/ceph/ceph.conf with the MONs IPs, optionaly set the key to allow the OSD to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user
** rgw_data - the path where the radosgw data should be stored
** fcgi_file - path to the fcgi file e.g. /var/www/s3gw.fcgi
:: [[User:Danny Al-Gaaf|Danny Al-Gaaf]] ([[User talk:Danny Al-Gaaf|talk]]) the monitor_ips are not needed: IMO ceph::conf should provide these information to all other

=== rgw_user ===

* '''proposed name''': ceph::rgw_user
* '''purpose''': create/remove users and Swift users for the RadosGW S3/Swift API
* '''interface''':
** user - username
** key - secret key (could get generated if needed)
** swift_user - username for the Swift API user
** swift_key - secret key for the Swift API user

== Related tools and implementations ==

* deploy ceph : ceph-deploy

for test / POC purposes
https://github.com/ceph/ceph-deploy

maintainer: Alfredo Deza

* deploy ceph with puppet : puppet-cephdeploy

relies on ceph-deploy
https://github.com/dontalton/puppet-cephdeploy/

maintainer: Don Talton

* deploy ceph with puppet : puppet-ceph

developped in 2012 but still useful, upstream
https://github.com/enovance/puppet-ceph

maintainer: community

fork of puppet-ceph, updated recently
https://github.com/TelekomCloud/puppet-ceph/tree/rc/eisbrecher

maintainer: Deutsche Telekom AG (DTAG)

* ceph + openstack : ceph docs

manual integration
http://ceph.com/docs/next/rbd/rbd-openstack/
maintainer: John Wilkins + Josh Durgin

* ceph + openstack with puppet : stackforge

https://github.com/stackforge/puppet-glance/blob/stable/grizzly/manifests/backend/rbd.pp
https://github.com/stackforge/puppet-cinder/blob/stable/grizzly/manifests/volume/rbd.pp

maintainer: community

* ceph + openstack with puppet : COI

targeting Cisco use case
https://github.com/CiscoSystems/puppet-coe/tree/grizzly/manifests/ceph
http://docwiki.cisco.com/wiki/OpenStack:Ceph-COI-Installation

maintainer : Don Talton + Robert Starmer

* ceph + openstack with puppet : mirantis

in the context of Fuel
https://github.com/Mirantis/fuel/tree/master/deployment/puppet/ceph
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/cinder/manifests/volume/ceph.pp
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/glance/manifests/backend/ceph.pp

maintainer : Andrew Woodward

* openstack with puppet : openstack-installer

data driven approach to deploy OpenStack
https://github.com/CiscoSystems/openstack-installer/

maintainer: Robert Starmer + Dan Bode

Puppet/ceph-blueprint

2013-10-21T20:59:49Z

Xarses:

== Overview ==

This document is intended to capture requirements for a single [https://launchpad.net/puppet-ceph puppet-ceph module].

Very much like vswitch, Ceph is not exclusively used in the context of OpenStack. There is however a significant community relying on puppet to deploy Ceph in the context of OpenStack, as is shown in the [#Related_tools_and_implementations|inventory of the existing efforts] Having a puppet ceph module under the umbrella of the stackforge infrastructure helps federate the efforts while providing a workflow that will improve the overall quality of the module.

* [https://review.openstack.org/#/q/status:open+project:stackforge/puppet-ceph,n,z gerrit review page]
* [https://launchpad.net/puppet-ceph puppet-ceph at launchpad]

== Roadmap ==

Almost each component of this module deserve a discussion and it would take a long time to agree on everything before getting something useful. The following list sets the order in which each module is going to be implemented. Each step must be a useable puppet module, unit tested and including integration tests.

* [[#conf|conf]]
* [[#key|key]]
* [[#mon|mon]]
* [[#osd|osd]]
* [[#pool|pool]]
* [[#rbd|rbd]]
* [[#radosgw|radosgw]

== User Stories ==

=== I want to try this module, heard of ceph, want to see it in action ===

/node/ {
ceph::conf { auth_enable: false };
ceph::mon;
ceph::osd { '/srv/osd1' };
ceph::osd { '/srv/osd2' };
}

* install puppet,
* paste this in site.pp and replace /node/ with the name of your current node,
* puppet apply site.pp ,
* ceph -s and see that it works

=== I want to run benchmarks on three new machines ===

* There are four machines, 3 OSD, 1 MON and one machine that is the client from which the user runs commands.
* install puppetmaster and create site.pp with:

/ceph-default/ {
ceph::conf { auth_enable: false };
ceph::conf { 'mon host': 'node1' };
}

/node1/ inherits ceph-default {
ceph::mon;
ceph::osd;
}

/node2/, /node3/ inherits ceph-default {
ceph::osd;
}

/client/ inherits ceph-default {
ceph::client;
}

* ssh client
* rados bench
* interpret the results

=== I want to spawn a cluster configured with a puppetmaster as part of a continuous integration effort ===

''Leveraging vagrant, vagrant-openstack, openstack''
* Ceph is used as a backend storage for various use cases
* There are tests to make sure the Ceph cluster was instantiated properly
* There are tests to make sure various other infrastructure components (or products) can use the Ceph cluster

== Requirements ==

=== High level requirements ===

==== No complex cross host orchestration ====

All cross host orchestration should be assumed to be managed outside of Puppet. Provided that it's dependencies have already been configured and are known, each component should support being adding without having to run Puppet on more than one node.

For example

* cinder-volume instances should be configured to join a Ceph cluster simply by running Puppet on that node
* OSD instances should be configured to join a cluster simply by running puppet agent on a node and targeting that role.

All cross host orchestration should be assumed to be managed outside of Puppet. The Puppet implementation should only be concerned with

* what components need to be defined (where these are implemented as classes)
* what data is required for those components (where that data is passed in a class parameters)

==== Supporting versions ====

The Operating System versions supported must be tested with integration on the actual operating system. Although it is fairly to add support for an Operating System, it is prone to regressions if not tested. The per Operating System support strategy mimics the way OpenStack modules do it.

The supported versions of the components that deal with the environment in which Ceph is used ( OpenStack, Cloudstack, Ganeti etc. ) are handled by each component on a case by case basis. There probably is too much heterogeneity to set a rule.

==== Provide sensible defaults ====

If the high level components ( osd + mon + mds + rgw for instance ) are included without any parameter, the result must be a functional Ceph cluster.

==== Architectured to leverage Ceph to its full potential ====

It means talking to the MON when configuring or modifying the cluster, using ceph-disk as a low level tool to create the storage required for an OSD, creating a minimal /etc/ceph/ceph.conf to allow a client to connect to the Ceph cluster. The MON exposes a very rich API ( either via the ceph cli or a REST API ) and it offers a great flexibility to the system administrator. It is unlikely that the first versions of the puppet module captures all of it. But it should be architectured to allow the casual contributor to add a new feature or a new variation without the need to workaround architectural limitations.

The ceph-deploy utility is developed as part of the ceph project, to help people get up to speed as quickly as possible for test and POCs. Alfredo Deza made a compeling argument against using ceph-deploy as a helper for a puppet module. Because it is designed to hide some of the flexibility ceph offers for the sake of simplicity. An inconvenience that is incompatible with the goal of a puppet module designed to accommodate all use cases.

=== Prefer cli over REST ===

The ceph cli is preferred because the [http://ceph.com/docs/next/man/8/ceph-rest-api/ rest-api] requires the installation of an additional daemon.

=== Module versioning ===

Create a branch for each Ceph release ( stable/cuttlefish, stable/dumpling etc. ) and follow the same pattern as the OpenStack modules

=== Support Ceph versions from cuttlefish ===

Do not support Ceph versions released before cuttlefish

== Integration tests ==

All scenarios can probably be covered with 2 virtual machines, 2 interfaces and one disk attached to one of the machines. A number of scenarios can be based on a single machine, using directories instead of disks and a single interface.

Use https://github.com/puppetlabs/rspec-system-puppet

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : I mean it would have to somehow leverage things ( what ? how ? ) in the openstack-ci infrastructure ?

== Puppet user components ==

This section outlines the roles and well as configuration components that are visible to the puppet user. They must be understandable for the system administrator willing to deploy Ceph for the first time.

=== conf ===

Although the key separator can either be space or underscore, only '''space''' is allowed to help with consistency.

::[[User:Xarses|Xarses]] ([[User talk:Xarses|talk]]) hyphen is a also valid seperator. From my testing i found that the ini_file provider can not tell the difference in keys between "auth supported" and "auth_supported" which will lead to duplicate entries in ceph.conf if we aren't careful.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : since [https://github.com/ceph/ceph-deploy/commit/53f46a8451dd8e10a3b9e8f2b191044f9863ae83 ceph-deploy enforces the use of _] and for the sake of consistency, it is probably better to use undercore instead of space.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : bodep prefers ini, dalgaaf prefers concat, loic does not care but voted ini because there is more expertise, xarses and dmsimard +1 ini, mgagne does not object ini : it is going to be implemented as a provider such as nova_config.

* '''proposed name''': ceph::conf
* '''purpose''': keeps and writes [http://ceph.com/docs/master/rados/configuration/osd-config-ref/ config] and their options for the top level sections of the ceph config. This includes these sections:
** [global]
** [mon]
** [osd]
** [mds]
* '''interface''': every key that is needed to write the base config ... the whole list would be to long to written down here
* auth_enable - true or false, enables/disables cephx, defaults to true
::If enable is true, set the following in the [global] section of the conf file:

auth cluster required = cephx
auth service required = cephx
auth client required = cephx
auth supported = cephx

::If enable is false, set the following in the [global] section of the conf file:

auth cluster required = none
auth service required = none
auth client required = none
auth supported = none

::It should support [http://ceph.com/docs/master/rados/operations/authentication/#disabling-cephx disabling] or [http://ceph.com/docs/master/rados/operations/authentication/#enabling-cephx enabling] cephx when the values change. If it does not support updating, it must fail when changed on an existing Ceph cluster.

Using a [https://github.com/puppetlabs/puppetlabs-inifile inifile] child provider ( such as [https://github.com/stackforge/puppet-cinder/blob/master/lib/puppet/provider/cinder_config/ini_setting.rb cinder_config] ) a setting would look like

ceph_conf {
'GLOBAL/fsid': value => $fsid;
}

And create '''/etc/ceph/ceph.conf''' such as:

[global]
fsid = 918340183294812038

Improvements to be implemented later:
* If a key/value pair is modified in the *mon*, *osd* or *mds* sections, all daemons are [http://ceph.com/docs/master/rados/configuration/ceph-conf/#runtime-changes notified of the change] with ceph {daemon} tell * ....

=== osd ===

* '''proposed name''': ceph::osd
* '''purpose''': configures a ceph OSD using the ceph-disk helper
* '''interface''':
** directory/disk - a disk or a directory to be used as a storage for the OSD (optional)
** bootstrap-osd - the bootstrap-osd secret key (optional if cephx = none )
** dmcrypt - options needed to encrypt disks (optional)

If the directory/disk is omitted, ceph-disk list is used to find unknown disks or partitions. All unknown disks are prepared with ceph-disk prepare. That effectively allows someone to say : use whatever disks are not in use for ceph and leave the rest alone. An operator would only have to add new disk and way for the next puppet client pass to have them integrated in the cluster. If a disk is removed, the OSD is not launched at boot time and there is nothing to do.

Here is what should happen on a node with at least one OSD
* common to all OSD on the same node:
** the /etc/ceph/ceph.conf file is setup with the IPs of the monitors
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L47 the /var/lib/ceph/bootstrap-osd/{cluster}.bootstrap-osd.keyring] file contains a user/key that is used to to create an OSD. The bootstrap-osd user key is usually the same for all OSD. For instance:
[client.bootstrap-osd]
key = AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
** The user bootstrap-osd with this key with caps to bootstrap an OSD:
$ ceph auth list
...
client.bootstrap-osd
key: AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
caps: [mon] allow profile bootstrap-osd
* for each OSD
** in the same way [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L104 ceph-deploy prepare the disk] call ceph-disk-prepare that will [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1031 set magic partition uuid] and trigger [https://github.com/ceph/ceph/blob/master/udev/95-ceph-osd.rules#L11 udev rules] to [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L453 ceph osd create]. When udev settles, the new osd is integrated into the cluster and uses its own key, created, registered to the MON and stored locally as a side effect of [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1301 --mkkey]. The osd daemon is also run as a side effect of udev detecting the disk and calling [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1414 /etc/init/ceph-osd.conf]. ceph-disk contains a [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L18 high level description of the process]
** '''dmcrypt''' is also handled by the udev logic ( details ??? keys ??? )

At boot time the [https://github.com/ceph/ceph/blob/master/src/upstart/ceph-osd-all-starter.conf#L14 /var/lib/ceph/osd directory is explored] to discover all OSDs that need to be started. Operating systems for which the same logic is not implemented will need an additional script run at boot time to perform the same exploration until the default script is updated to add this capability.

=== mds ===

* '''proposed name''': ceph::mds
* '''purpose''': configures a ceph MDS, setup /etc/ceph/ceph.conf with the MONs IPs, declare the MDS to the cluster via the MON, optionaly set the key to allow the MDS to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user

=== mon ===

Creates the files and keyring supporting a mon, runs the daemon

* '''proposed name''': ceph::mon
* '''purpose''': configures a ceph MON
* '''interface''':
** cluster - cluster name ( defaults to ceph )
** id - the id of the mon
** ip_address - the ip addresses of the mon
** key - the mon. user key

* add a [mon.$id] section to the conf file (depends on ceph::conf to write the base part of the config)
* if auth == cephx
** the mon. key is mandatory and need to be set by the user to be a valid ceph key. The documentation should contain an example key and explanations about how to [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L20 create an auth key].
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L86 writes the keyring]
* installs the packages
* ceph-mon --id 0 --mkfs
* runs the mon daemon

=== rbd ===

* '''proposed name''': ceph::rbd
* '''purpose''': maps and mounts a rbd image, taking care of dependencies (packages, rbd kernel module, /etc/ceph/rbdmap, fstab)
* '''interface''':
** name - the name of the image
** pool - the pool in which the image is
** mount_point - where the image will be mounted
** key - the secret key for the id user
** id - the id of the user
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

=== cephfs ===

* '''proposed name''': ceph::cephfs
* '''purpose''': mounts a cephfs filesystem, taking care of dependencies (e.g, fstab, packages)
* '''interface''':
** Lots - See http://ceph.com/docs/next/man/8/mount.ceph/
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

=== radosgw ===
* '''proposed name''': ceph::radosgw
* '''purpose''': configures a working radosgw service including a working gw and probably keystone hooks
* '''interface''':
** TBD

== Implementor components ==

These components are dependencies of the Puppet user components and can be used by other components. They should be a library of components where the code common to at least two independant components ( think OpenStack and Cloudstack ) is included.

=== package ===

Although some distributions include packages for Ceph, it is recommended to install from the packages available from ceph.com http://ceph.com/docs/next/install/. It is not recommended to install the Ceph package provided by the standard repositories. This will change over time and the need to use the repository provided by ceph.com will gradually become less common.

The use of the repositories from ceph.com should be documented in the README.md with a apt {} based example to clarify that the user is expected to get up to date packages repositories.

* Mimic https://github.com/stackforge/puppet-nova/blob/master/manifests/params.pp#L8 for cross distribution package name

=== ceph client implementation ===

* '''proposed name''': ceph::client
* '''purpose''': setup /etc/ceph/ceph.conf to connect to the Ceph cluster and install the ceph cli
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** client_id - name of the client to find the correct id for key
** keypath - path to the clients key file

=== key ===

Keyring management, authentication. It would be a class to create keys for new users (e.g. a user that can create RBDs or use the Objectstore) which may special access rights. But would also be used by the other classes like ceph::mon or ceph::osd to place e.g. the shared 'client.admin' or 'mon.' keys. I would handle here all key related tasks.

* '''proposed name''': ceph::key
* '''purpose''': handles ceph keys (cephx), generates keys, creates keyring files, incject keys into or delete keys from the cluster/keyring via ceph and ceph-authtool tools.
* '''interface''':
** secret - key secret
** keyring_path - path to the keyring
** cap_mon/cap_osd/cap_mds - cephx capabilities
** user/group/mode: settings for the keyring file if needed
** inject - options to inject a key into the cluster

=== pool ===

* '''proposed name''': ceph::pool
* '''purpose''': manage operations on the pools in the cluster such as: create/delete pools, set PG/PGP number
* '''interface''':
** pool_name - name of the pool
** create - if to create a new pool
** delete - if to delete an existing pool
** pg_num - number of Placement Groups (PGs) for a pool, if the pool already exists this may increase the number of PGs if the current value is lower
** pgp_num - same as for pg_num
** replica_level - increase or decrease the replica level of a pool

== OpenStack components ==

ceph specific configuration for cinder/glance (already provided by the puppet-cinder and puppet-glance modules in the volume/rdb and backend/rdb classes)

== RadosGW components ==

The RadosGW is developped as an integral part of Ceph. It is however not required to deploy a cluster and should be treated as any client application of the cluster.

=== rgw ===

* '''proposed name''': ceph::rgw
* '''purpose''': configures a ceph radosgw , setup /etc/ceph/ceph.conf with the MONs IPs, optionaly set the key to allow the OSD to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user
** rgw_data - the path where the radosgw data should be stored
** fcgi_file - path to the fcgi file e.g. /var/www/s3gw.fcgi
:: [[User:Danny Al-Gaaf|Danny Al-Gaaf]] ([[User talk:Danny Al-Gaaf|talk]]) the monitor_ips are not needed: IMO ceph::conf should provide these information to all other

=== rgw_user ===

* '''proposed name''': ceph::rgw_user
* '''purpose''': create/remove users and Swift users for the RadosGW S3/Swift API
* '''interface''':
** user - username
** key - secret key (could get generated if needed)
** swift_user - username for the Swift API user
** swift_key - secret key for the Swift API user

== Related tools and implementations ==

* deploy ceph : ceph-deploy

for test / POC purposes
https://github.com/ceph/ceph-deploy

maintainer: Alfredo Deza

* deploy ceph with puppet : puppet-cephdeploy

relies on ceph-deploy
https://github.com/dontalton/puppet-cephdeploy/

maintainer: Don Talton

* deploy ceph with puppet : puppet-ceph

developped in 2012 but still useful, upstream
https://github.com/enovance/puppet-ceph

maintainer: community

fork of puppet-ceph, updated recently
https://github.com/TelekomCloud/puppet-ceph/tree/rc/eisbrecher

maintainer: Deutsche Telekom AG (DTAG)

* ceph + openstack : ceph docs

manual integration
http://ceph.com/docs/next/rbd/rbd-openstack/
maintainer: John Wilkins + Josh Durgin

* ceph + openstack with puppet : stackforge

https://github.com/stackforge/puppet-glance/blob/stable/grizzly/manifests/backend/rbd.pp
https://github.com/stackforge/puppet-cinder/blob/stable/grizzly/manifests/volume/rbd.pp

maintainer: community

* ceph + openstack with puppet : COI

targeting Cisco use case
https://github.com/CiscoSystems/puppet-coe/tree/grizzly/manifests/ceph
http://docwiki.cisco.com/wiki/OpenStack:Ceph-COI-Installation

maintainer : Don Talton + Robert Starmer

* ceph + openstack with puppet : mirantis

in the context of Fuel
https://github.com/Mirantis/fuel/tree/master/deployment/puppet/ceph
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/cinder/manifests/volume/ceph.pp
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/glance/manifests/backend/ceph.pp

maintainer : Andrew Woodward

* openstack with puppet : openstack-installer

data driven approach to deploy OpenStack
https://github.com/CiscoSystems/openstack-installer/

maintainer: Robert Starmer + Dan Bode

Puppet/ceph-blueprint

2013-10-21T20:56:29Z

Xarses: /* Roadmap */

== Overview ==

This document is intended to capture requirements for a single [https://launchpad.net/puppet-ceph puppet-ceph module].

Very much like vswitch, Ceph is not exclusively used in the context of OpenStack. There is however a significant community relying on puppet to deploy Ceph in the context of OpenStack, as is shown in the [#Related_tools_and_implementations|inventory of the existing efforts] Having a puppet ceph module under the umbrella of the stackforge infrastructure helps federate the efforts while providing a workflow that will improve the overall quality of the module.

* [https://review.openstack.org/#/q/status:open+project:stackforge/puppet-ceph,n,z gerrit review page]
* [https://launchpad.net/puppet-ceph puppet-ceph at launchpad]

== Roadmap ==

Almost each component of this module deserve a discussion and it would take a long time to agree on everything before getting something useful. The following list sets the order in which each module is going to be implemented. Each step must be a useable puppet module, unit tested and including integration tests.

* [[#conf|conf]]
* [[#key|key]]
* [[#mon|mon]]
* [[#osd|osd]]
* [[#pool|pool]]
* [[#rbd|rbd]]
* [[#radosgw|radosgw]

== User Stories ==

=== I want to try this module, heard of ceph, want to see it in action ===

/node/ {
ceph::conf { auth_enable: false };
ceph::mon;
ceph::osd { '/srv/osd1' };
ceph::osd { '/srv/osd2' };
}

* install puppet,
* paste this in site.pp and replace /node/ with the name of your current node,
* puppet apply site.pp ,
* ceph -s and see that it works

=== I want to run benchmarks on three new machines ===

* There are four machines, 3 OSD, 1 MON and one machine that is the client from which the user runs commands.
* install puppetmaster and create site.pp with:

/ceph-default/ {
ceph::conf { auth_enable: false };
ceph::conf { 'mon host': 'node1' };
}

/node1/ inherits ceph-default {
ceph::mon;
ceph::osd;
}

/node2/, /node3/ inherits ceph-default {
ceph::osd;
}

/client/ inherits ceph-default {
ceph::client;
}

* ssh client
* rados bench
* interpret the results

=== I want to spawn a cluster configured with a puppetmaster as part of a continuous integration effort ===

''Leveraging vagrant, vagrant-openstack, openstack''
* Ceph is used as a backend storage for various use cases
* There are tests to make sure the Ceph cluster was instantiated properly
* There are tests to make sure various other infrastructure components (or products) can use the Ceph cluster

== Requirements ==

=== High level requirements ===

==== No complex cross host orchestration ====

All cross host orchestration should be assumed to be managed outside of Puppet. Provided that it's dependencies have already been configured and are known, each component should support being adding without having to run Puppet on more than one node.

For example

* cinder-volume instances should be configured to join a Ceph cluster simply by running Puppet on that node
* OSD instances should be configured to join a cluster simply by running puppet agent on a node and targeting that role.

All cross host orchestration should be assumed to be managed outside of Puppet. The Puppet implementation should only be concerned with

* what components need to be defined (where these are implemented as classes)
* what data is required for those components (where that data is passed in a class parameters)

==== Supporting versions ====

The Operating System versions supported must be tested with integration on the actual operating system. Although it is fairly to add support for an Operating System, it is prone to regressions if not tested. The per Operating System support strategy mimics the way OpenStack modules do it.

The supported versions of the components that deal with the environment in which Ceph is used ( OpenStack, Cloudstack, Ganeti etc. ) are handled by each component on a case by case basis. There probably is too much heterogeneity to set a rule.

==== Provide sensible defaults ====

If the high level components ( osd + mon + mds + rgw for instance ) are included without any parameter, the result must be a functional Ceph cluster.

==== Architectured to leverage Ceph to its full potential ====

It means talking to the MON when configuring or modifying the cluster, using ceph-disk as a low level tool to create the storage required for an OSD, creating a minimal /etc/ceph/ceph.conf to allow a client to connect to the Ceph cluster. The MON exposes a very rich API ( either via the ceph cli or a REST API ) and it offers a great flexibility to the system administrator. It is unlikely that the first versions of the puppet module captures all of it. But it should be architectured to allow the casual contributor to add a new feature or a new variation without the need to workaround architectural limitations.

The ceph-deploy utility is developed as part of the ceph project, to help people get up to speed as quickly as possible for test and POCs. Alfredo Deza made a compeling argument against using ceph-deploy as a helper for a puppet module. Because it is designed to hide some of the flexibility ceph offers for the sake of simplicity. An inconvenience that is incompatible with the goal of a puppet module designed to accommodate all use cases.

=== Prefer cli over REST ===

The ceph cli is preferred because the [http://ceph.com/docs/next/man/8/ceph-rest-api/ rest-api] requires the installation of an additional daemon.

=== Module versioning ===

Create a branch for each Ceph release ( stable/cuttlefish, stable/dumpling etc. ) and follow the same pattern as the OpenStack modules

=== Support Ceph versions from cuttlefish ===

Do not support Ceph versions released before cuttlefish

== Integration tests ==

All scenarios can probably be covered with 2 virtual machines, 2 interfaces and one disk attached to one of the machines. A number of scenarios can be based on a single machine, using directories instead of disks and a single interface.

Use https://github.com/puppetlabs/rspec-system-puppet

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : I mean it would have to somehow leverage things ( what ? how ? ) in the openstack-ci infrastructure ?

== Puppet user components ==

This section outlines the roles and well as configuration components that are visible to the puppet user. They must be understandable for the system administrator willing to deploy Ceph for the first time.

=== conf ===

Although the key separator can either be space or underscore, only '''space''' is allowed to help with consistency.

::[[User:Xarses|Xarses]] ([[User talk:Xarses|talk]]) hyphen is a also valid seperator. From my testing i found that the ini_file provider can not tell the difference in keys between "auth supported" and "auth_supported" which will lead to duplicate entries in ceph.conf if we aren't careful.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : since [https://github.com/ceph/ceph-deploy/commit/53f46a8451dd8e10a3b9e8f2b191044f9863ae83 ceph-deploy enforces the use of _] and for the sake of consistency, it is probably better to use undercore instead of space.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : bodep prefers ini, dalgaaf prefers concat, loic does not care but voted ini because there is more expertise, xarses and dmsimard +1 ini, mgagne does not object ini : it is going to be implemented as a provider such as nova_config.

* '''proposed name''': ceph::conf
* '''purpose''': keeps and writes [http://ceph.com/docs/master/rados/configuration/osd-config-ref/ config] and their options for the top level sections of the ceph config. This includes these sections:
** [global]
** [mon]
** [osd]
** [mds]
* '''interface''': every key that is needed to write the base config ... the whole list would be to long to written down here
* auth_enable - true or false, enables/disables cephx, defaults to true
::If enable is true, set the following in the [global] section of the conf file:

auth cluster required = cephx
auth service required = cephx
auth client required = cephx
auth supported = cephx

::If enable is false, set the following in the [global] section of the conf file:

auth cluster required = none
auth service required = none
auth client required = none
auth supported = none

::It should support [http://ceph.com/docs/master/rados/operations/authentication/#disabling-cephx disabling] or [http://ceph.com/docs/master/rados/operations/authentication/#enabling-cephx enabling] cephx when the values change. If it does not support updating, it must fail when changed on an existing Ceph cluster.

Using a [https://github.com/puppetlabs/puppetlabs-inifile inifile] child provider ( such as [https://github.com/stackforge/puppet-cinder/blob/master/lib/puppet/provider/cinder_config/ini_setting.rb cinder_config] ) a setting would look like

ceph_conf {
'GLOBAL/fsid': value => $fsid;
}

And create '''/etc/ceph/ceph.conf''' such as:

[global]
fsid = 918340183294812038

Improvements to be implemented later:
* If a key/value pair is modified in the *mon*, *osd* or *mds* sections, all daemons are [http://ceph.com/docs/master/rados/configuration/ceph-conf/#runtime-changes notified of the change] with ceph {daemon} tell * ....

=== osd ===

* '''proposed name''': ceph::osd
* '''purpose''': configures a ceph OSD using the ceph-disk helper
* '''interface''':
** directory/disk - a disk or a directory to be used as a storage for the OSD (optional)
** bootstrap-osd - the bootstrap-osd secret key (optional if cephx = none )
** dmcrypt - options needed to encrypt disks (optional)

If the directory/disk is omitted, ceph-disk list is used to find unknown disks or partitions. All unknown disks are prepared with ceph-disk prepare. That effectively allows someone to say : use whatever disks are not in use for ceph and leave the rest alone. An operator would only have to add new disk and way for the next puppet client pass to have them integrated in the cluster. If a disk is removed, the OSD is not launched at boot time and there is nothing to do.

Here is what should happen on a node with at least one OSD
* common to all OSD on the same node:
** the /etc/ceph/ceph.conf file is setup with the IPs of the monitors
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L47 the /var/lib/ceph/bootstrap-osd/{cluster}.bootstrap-osd.keyring] file contains a user/key that is used to to create an OSD. The bootstrap-osd user key is usually the same for all OSD. For instance:
[client.bootstrap-osd]
key = AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
** The user bootstrap-osd with this key with caps to bootstrap an OSD:
$ ceph auth list
...
client.bootstrap-osd
key: AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
caps: [mon] allow profile bootstrap-osd
* for each OSD
** in the same way [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L104 ceph-deploy prepare the disk] call ceph-disk-prepare that will [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1031 set magic partition uuid] and trigger [https://github.com/ceph/ceph/blob/master/udev/95-ceph-osd.rules#L11 udev rules] to [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L453 ceph osd create]. When udev settles, the new osd is integrated into the cluster and uses its own key, created, registered to the MON and stored locally as a side effect of [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1301 --mkkey]. The osd daemon is also run as a side effect of udev detecting the disk and calling [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1414 /etc/init/ceph-osd.conf]. ceph-disk contains a [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L18 high level description of the process]
** '''dmcrypt''' is also handled by the udev logic ( details ??? keys ??? )

At boot time the [https://github.com/ceph/ceph/blob/master/src/upstart/ceph-osd-all-starter.conf#L14 /var/lib/ceph/osd directory is explored] to discover all OSDs that need to be started. Operating systems for which the same logic is not implemented will need an additional script run at boot time to perform the same exploration until the default script is updated to add this capability.

=== mds ===

* '''proposed name''': ceph::mds
* '''purpose''': configures a ceph MDS, setup /etc/ceph/ceph.conf with the MONs IPs, declare the MDS to the cluster via the MON, optionaly set the key to allow the MDS to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user

=== mon ===

Creates the files and keyring supporting a mon, runs the daemon

* '''proposed name''': ceph::mon
* '''purpose''': configures a ceph MON
* '''interface''':
** cluster - cluster name ( defaults to ceph )
** id - the id of the mon
** ip_address - the ip addresses of the mon
** key - the mon. user key

* add a [mon.$id] section to the conf file (depends on ceph::conf to write the base part of the config)
* if auth == cephx
** the mon. key is mandatory and need to be set by the user to be a valid ceph key. The documentation should contain an example key and explanations about how to [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L20 create an auth key].
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L86 writes the keyring]
* installs the packages
* ceph-mon --id 0 --mkfs
* runs the mon daemon

=== rbd ===

* '''proposed name''': ceph::rbd
* '''purpose''': maps and mounts a rbd image, taking care of dependencies (packages, rbd kernel module, /etc/ceph/rbdmap, fstab)
* '''interface''':
** name - the name of the image
** pool - the pool in which the image is
** mount_point - where the image will be mounted
** key - the secret key for the id user
** id - the id of the user
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

=== cephfs ===

* '''proposed name''': ceph::cephfs
* '''purpose''': mounts a cephfs filesystem, taking care of dependencies (e.g, fstab, packages)
* '''interface''':
** Lots - See http://ceph.com/docs/next/man/8/mount.ceph/
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

== Implementor components ==

These components are dependencies of the Puppet user components and can be used by other components. They should be a library of components where the code common to at least two independant components ( think OpenStack and Cloudstack ) is included.

=== package ===

Although some distributions include packages for Ceph, it is recommended to install from the packages available from ceph.com http://ceph.com/docs/next/install/. It is not recommended to install the Ceph package provided by the standard repositories. This will change over time and the need to use the repository provided by ceph.com will gradually become less common.

The use of the repositories from ceph.com should be documented in the README.md with a apt {} based example to clarify that the user is expected to get up to date packages repositories.

* Mimic https://github.com/stackforge/puppet-nova/blob/master/manifests/params.pp#L8 for cross distribution package name

=== ceph client implementation ===

* '''proposed name''': ceph::client
* '''purpose''': setup /etc/ceph/ceph.conf to connect to the Ceph cluster and install the ceph cli
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** client_id - name of the client to find the correct id for key
** keypath - path to the clients key file

=== key ===

Keyring management, authentication. It would be a class to create keys for new users (e.g. a user that can create RBDs or use the Objectstore) which may special access rights. But would also be used by the other classes like ceph::mon or ceph::osd to place e.g. the shared 'client.admin' or 'mon.' keys. I would handle here all key related tasks.

* '''proposed name''': ceph::key
* '''purpose''': handles ceph keys (cephx), generates keys, creates keyring files, incject keys into or delete keys from the cluster/keyring via ceph and ceph-authtool tools.
* '''interface''':
** secret - key secret
** keyring_path - path to the keyring
** cap_mon/cap_osd/cap_mds - cephx capabilities
** user/group/mode: settings for the keyring file if needed
** inject - options to inject a key into the cluster

=== pool ===

* '''proposed name''': ceph::pool
* '''purpose''': manage operations on the pools in the cluster such as: create/delete pools, set PG/PGP number
* '''interface''':
** pool_name - name of the pool
** create - if to create a new pool
** delete - if to delete an existing pool
** pg_num - number of Placement Groups (PGs) for a pool, if the pool already exists this may increase the number of PGs if the current value is lower
** pgp_num - same as for pg_num
** replica_level - increase or decrease the replica level of a pool

== OpenStack components ==

ceph specific configuration for cinder/glance (already provided by the puppet-cinder and puppet-glance modules in the volume/rdb and backend/rdb classes)

== RadosGW components ==

The RadosGW is developped as an integral part of Ceph. It is however not required to deploy a cluster and should be treated as any client application of the cluster.

=== rgw ===

* '''proposed name''': ceph::rgw
* '''purpose''': configures a ceph radosgw , setup /etc/ceph/ceph.conf with the MONs IPs, optionaly set the key to allow the OSD to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user
** rgw_data - the path where the radosgw data should be stored
** fcgi_file - path to the fcgi file e.g. /var/www/s3gw.fcgi
:: [[User:Danny Al-Gaaf|Danny Al-Gaaf]] ([[User talk:Danny Al-Gaaf|talk]]) the monitor_ips are not needed: IMO ceph::conf should provide these information to all other

=== rgw_user ===

* '''proposed name''': ceph::rgw_user
* '''purpose''': create/remove users and Swift users for the RadosGW S3/Swift API
* '''interface''':
** user - username
** key - secret key (could get generated if needed)
** swift_user - username for the Swift API user
** swift_key - secret key for the Swift API user

== Related tools and implementations ==

* deploy ceph : ceph-deploy

for test / POC purposes
https://github.com/ceph/ceph-deploy

maintainer: Alfredo Deza

* deploy ceph with puppet : puppet-cephdeploy

relies on ceph-deploy
https://github.com/dontalton/puppet-cephdeploy/

maintainer: Don Talton

* deploy ceph with puppet : puppet-ceph

developped in 2012 but still useful, upstream
https://github.com/enovance/puppet-ceph

maintainer: community

fork of puppet-ceph, updated recently
https://github.com/TelekomCloud/puppet-ceph/tree/rc/eisbrecher

maintainer: Deutsche Telekom AG (DTAG)

* ceph + openstack : ceph docs

manual integration
http://ceph.com/docs/next/rbd/rbd-openstack/
maintainer: John Wilkins + Josh Durgin

* ceph + openstack with puppet : stackforge

https://github.com/stackforge/puppet-glance/blob/stable/grizzly/manifests/backend/rbd.pp
https://github.com/stackforge/puppet-cinder/blob/stable/grizzly/manifests/volume/rbd.pp

maintainer: community

* ceph + openstack with puppet : COI

targeting Cisco use case
https://github.com/CiscoSystems/puppet-coe/tree/grizzly/manifests/ceph
http://docwiki.cisco.com/wiki/OpenStack:Ceph-COI-Installation

maintainer : Don Talton + Robert Starmer

* ceph + openstack with puppet : mirantis

in the context of Fuel
https://github.com/Mirantis/fuel/tree/master/deployment/puppet/ceph
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/cinder/manifests/volume/ceph.pp
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/glance/manifests/backend/ceph.pp

maintainer : Andrew Woodward

* openstack with puppet : openstack-installer

data driven approach to deploy OpenStack
https://github.com/CiscoSystems/openstack-installer/

maintainer: Robert Starmer + Dan Bode

Puppet/ceph-blueprint

2013-10-21T20:23:16Z

Xarses: /* conf */

== Overview ==

This document is intended to capture requirements for a single [https://launchpad.net/puppet-ceph puppet-ceph module].

Very much like vswitch, Ceph is not exclusively used in the context of OpenStack. There is however a significant community relying on puppet to deploy Ceph in the context of OpenStack, as is shown in the [#Related_tools_and_implementations|inventory of the existing efforts] Having a puppet ceph module under the umbrella of the stackforge infrastructure helps federate the efforts while providing a workflow that will improve the overall quality of the module.

* [https://review.openstack.org/#/q/status:open+project:stackforge/puppet-ceph,n,z gerrit review page]
* [https://launchpad.net/puppet-ceph puppet-ceph at launchpad]

== Roadmap ==

Almost each component of this module deserve a discussion and it would take a long time to agree on everything before getting something useful. The following list sets the order in which each module is going to be implemented. Each step must be a useable puppet module, unit tested and including integration tests.

* [[#conf|conf]]
* [[#key|key]]
* [[#mon|mon]]
* [[#osd|osd]]
* [[#pool|pool]]

== User Stories ==

=== I want to try this module, heard of ceph, want to see it in action ===

/node/ {
ceph::conf { auth_enable: false };
ceph::mon;
ceph::osd { '/srv/osd1' };
ceph::osd { '/srv/osd2' };
}

* install puppet,
* paste this in site.pp and replace /node/ with the name of your current node,
* puppet apply site.pp ,
* ceph -s and see that it works

=== I want to run benchmarks on three new machines ===

* There are four machines, 3 OSD, 1 MON and one machine that is the client from which the user runs commands.
* install puppetmaster and create site.pp with:

/ceph-default/ {
ceph::conf { auth_enable: false };
ceph::conf { 'mon host': 'node1' };
}

/node1/ inherits ceph-default {
ceph::mon;
ceph::osd;
}

/node2/, /node3/ inherits ceph-default {
ceph::osd;
}

/client/ inherits ceph-default {
ceph::client;
}

* ssh client
* rados bench
* interpret the results

=== I want to spawn a cluster configured with a puppetmaster as part of a continuous integration effort ===

''Leveraging vagrant, vagrant-openstack, openstack''
* Ceph is used as a backend storage for various use cases
* There are tests to make sure the Ceph cluster was instantiated properly
* There are tests to make sure various other infrastructure components (or products) can use the Ceph cluster

== Requirements ==

=== High level requirements ===

==== No complex cross host orchestration ====

All cross host orchestration should be assumed to be managed outside of Puppet. Provided that it's dependencies have already been configured and are known, each component should support being adding without having to run Puppet on more than one node.

For example

* cinder-volume instances should be configured to join a Ceph cluster simply by running Puppet on that node
* OSD instances should be configured to join a cluster simply by running puppet agent on a node and targeting that role.

All cross host orchestration should be assumed to be managed outside of Puppet. The Puppet implementation should only be concerned with

* what components need to be defined (where these are implemented as classes)
* what data is required for those components (where that data is passed in a class parameters)

==== Supporting versions ====

The Operating System versions supported must be tested with integration on the actual operating system. Although it is fairly to add support for an Operating System, it is prone to regressions if not tested. The per Operating System support strategy mimics the way OpenStack modules do it.

The supported versions of the components that deal with the environment in which Ceph is used ( OpenStack, Cloudstack, Ganeti etc. ) are handled by each component on a case by case basis. There probably is too much heterogeneity to set a rule.

==== Provide sensible defaults ====

If the high level components ( osd + mon + mds + rgw for instance ) are included without any parameter, the result must be a functional Ceph cluster.

==== Architectured to leverage Ceph to its full potential ====

It means talking to the MON when configuring or modifying the cluster, using ceph-disk as a low level tool to create the storage required for an OSD, creating a minimal /etc/ceph/ceph.conf to allow a client to connect to the Ceph cluster. The MON exposes a very rich API ( either via the ceph cli or a REST API ) and it offers a great flexibility to the system administrator. It is unlikely that the first versions of the puppet module captures all of it. But it should be architectured to allow the casual contributor to add a new feature or a new variation without the need to workaround architectural limitations.

The ceph-deploy utility is developed as part of the ceph project, to help people get up to speed as quickly as possible for test and POCs. Alfredo Deza made a compeling argument against using ceph-deploy as a helper for a puppet module. Because it is designed to hide some of the flexibility ceph offers for the sake of simplicity. An inconvenience that is incompatible with the goal of a puppet module designed to accommodate all use cases.

=== Prefer cli over REST ===

The ceph cli is preferred because the [http://ceph.com/docs/next/man/8/ceph-rest-api/ rest-api] requires the installation of an additional daemon.

=== Module versioning ===

Create a branch for each Ceph release ( stable/cuttlefish, stable/dumpling etc. ) and follow the same pattern as the OpenStack modules

=== Support Ceph versions from cuttlefish ===

Do not support Ceph versions released before cuttlefish

== Integration tests ==

All scenarios can probably be covered with 2 virtual machines, 2 interfaces and one disk attached to one of the machines. A number of scenarios can be based on a single machine, using directories instead of disks and a single interface.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : how are the integration test resource provisioned ? Where to look to learn more ?

== Puppet user components ==

This section outlines the roles and well as configuration components that are visible to the puppet user. They must be understandable for the system administrator willing to deploy Ceph for the first time.

=== conf ===

Although the key separator can either be space or underscore, only '''space''' is allowed to help with consistency.

::[[User:Xarses|Xarses]] ([[User talk:Xarses|talk]]) hyphen is a also valid seperator. From my testing i found that the ini_file provider can not tell the difference in keys between "auth supported" and "auth_supported" which will lead to duplicate entries in ceph.conf if we aren't careful.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : since [https://github.com/ceph/ceph-deploy/commit/53f46a8451dd8e10a3b9e8f2b191044f9863ae83 ceph-deploy enforces the use of _] and for the sake of consistency, it is probably better to use undercore instead of space.

::[[User:Dachary|Loic Dachary]] ([[User talk:Dachary|talk]]) : bodep prefers ini, dalgaaf prefers concat, loic does not care but voted ini because there is more expertise, xarses and dmsimard +1 ini, mgagne does not object ini : it is going to be implemented as a provider such as nova_config.

* '''proposed name''': ceph::conf
* '''purpose''': keeps and writes [http://ceph.com/docs/master/rados/configuration/osd-config-ref/ config] and their options for the top level sections of the ceph config. This includes these sections:
** [global]
** [mon]
** [osd]
** [mds]
* '''interface''': every key that is needed to write the base config ... the whole list would be to long to written down here
* auth_enable - true or false, enables/disables cephx, defaults to true
::If enable is true, set the following in the [global] section of the conf file:

auth cluster required = cephx
auth service required = cephx
auth client required = cephx
auth supported = cephx

::If enable is false, set the following in the [global] section of the conf file:

auth cluster required = none
auth service required = none
auth client required = none
auth supported = none

::It should support [http://ceph.com/docs/master/rados/operations/authentication/#disabling-cephx disabling] or [http://ceph.com/docs/master/rados/operations/authentication/#enabling-cephx enabling] cephx when the values change. If it does not support updating, it must fail when changed on an existing Ceph cluster.

Using a [https://github.com/puppetlabs/puppetlabs-inifile inifile] child provider ( such as [https://github.com/stackforge/puppet-cinder/blob/master/lib/puppet/provider/cinder_config/ini_setting.rb cinder_config] ) a setting would look like

ceph_conf {
'GLOBAL/fsid': value => $fsid;
}

And create '''/etc/ceph/ceph.conf''' such as:

[global]
fsid = 918340183294812038

Improvements to be implemented later:
* If a key/value pair is modified in the *mon*, *osd* or *mds* sections, all daemons are [http://ceph.com/docs/master/rados/configuration/ceph-conf/#runtime-changes notified of the change] with ceph {daemon} tell * ....

=== osd ===

* '''proposed name''': ceph::osd
* '''purpose''': configures a ceph OSD using the ceph-disk helper
* '''interface''':
** directory/disk - a disk or a directory to be used as a storage for the OSD (optional)
** bootstrap-osd - the bootstrap-osd secret key (optional if cephx = none )
** dmcrypt - options needed to encrypt disks (optional)

If the directory/disk is omitted, ceph-disk list is used to find unknown disks or partitions. All unknown disks are prepared with ceph-disk prepare. That effectively allows someone to say : use whatever disks are not in use for ceph and leave the rest alone. An operator would only have to add new disk and way for the next puppet client pass to have them integrated in the cluster. If a disk is removed, the OSD is not launched at boot time and there is nothing to do.

Here is what should happen on a node with at least one OSD
* common to all OSD on the same node:
** the /etc/ceph/ceph.conf file is setup with the IPs of the monitors
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L47 the /var/lib/ceph/bootstrap-osd/{cluster}.bootstrap-osd.keyring] file contains a user/key that is used to to create an OSD. The bootstrap-osd user key is usually the same for all OSD. For instance:
[client.bootstrap-osd]
key = AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
** The user bootstrap-osd with this key with caps to bootstrap an OSD:
$ ceph auth list
...
client.bootstrap-osd
key: AQCUg71RYEi7DxAAxlyC1KExxSnNJgim6lmuGA==
caps: [mon] allow profile bootstrap-osd
* for each OSD
** in the same way [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/osd.py#L104 ceph-deploy prepare the disk] call ceph-disk-prepare that will [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1031 set magic partition uuid] and trigger [https://github.com/ceph/ceph/blob/master/udev/95-ceph-osd.rules#L11 udev rules] to [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L453 ceph osd create]. When udev settles, the new osd is integrated into the cluster and uses its own key, created, registered to the MON and stored locally as a side effect of [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1301 --mkkey]. The osd daemon is also run as a side effect of udev detecting the disk and calling [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1414 /etc/init/ceph-osd.conf]. ceph-disk contains a [https://github.com/ceph/ceph/blob/master/src/ceph-disk#L18 high level description of the process]
** '''dmcrypt''' is also handled by the udev logic ( details ??? keys ??? )

At boot time the [https://github.com/ceph/ceph/blob/master/src/upstart/ceph-osd-all-starter.conf#L14 /var/lib/ceph/osd directory is explored] to discover all OSDs that need to be started. Operating systems for which the same logic is not implemented will need an additional script run at boot time to perform the same exploration until the default script is updated to add this capability.

=== mds ===

* '''proposed name''': ceph::mds
* '''purpose''': configures a ceph MDS, setup /etc/ceph/ceph.conf with the MONs IPs, declare the MDS to the cluster via the MON, optionaly set the key to allow the MDS to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user

=== mon ===

Creates the files and keyring supporting a mon, runs the daemon

* '''proposed name''': ceph::mon
* '''purpose''': configures a ceph MON
* '''interface''':
** cluster - cluster name ( defaults to ceph )
** id - the id of the mon
** ip_address - the ip addresses of the mon
** key - the mon. user key

* add a [mon.$id] section to the conf file (depends on ceph::conf to write the base part of the config)
* if auth == cephx
** the mon. key is mandatory and need to be set by the user to be a valid ceph key. The documentation should contain an example key and explanations about how to [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L20 create an auth key].
** [https://github.com/ceph/ceph-deploy/blob/v1.2.7/ceph_deploy/new.py#L86 writes the keyring]
* installs the packages
* ceph-mon --id 0 --mkfs
* runs the mon daemon

=== rbd ===

* '''proposed name''': ceph::rbd
* '''purpose''': maps and mounts a rbd image, taking care of dependencies (packages, rbd kernel module, /etc/ceph/rbdmap, fstab)
* '''interface''':
** name - the name of the image
** pool - the pool in which the image is
** mount_point - where the image will be mounted
** key - the secret key for the id user
** id - the id of the user
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

=== cephfs ===

* '''proposed name''': ceph::cephfs
* '''purpose''': mounts a cephfs filesystem, taking care of dependencies (e.g, fstab, packages)
* '''interface''':
** Lots - See http://ceph.com/docs/next/man/8/mount.ceph/
::[[User:dmsimard|David Moreau Simard]] ([[User talk:David Moreau Simard|talk]]) Should ceph::client be a dependency ?

== Implementor components ==

These components are dependencies of the Puppet user components and can be used by other components. They should be a library of components where the code common to at least two independant components ( think OpenStack and Cloudstack ) is included.

=== package ===

Although some distributions include packages for Ceph, it is recommended to install from the packages available from ceph.com http://ceph.com/docs/next/install/. It is not recommended to install the Ceph package provided by the standard repositories. This will change over time and the need to use the repository provided by ceph.com will gradually become less common.

The use of the repositories from ceph.com should be documented in the README.md with a apt {} based example to clarify that the user is expected to get up to date packages repositories.

* Mimic https://github.com/stackforge/puppet-nova/blob/master/manifests/params.pp#L8 for cross distribution package name

=== ceph client implementation ===

* '''proposed name''': ceph::client
* '''purpose''': setup /etc/ceph/ceph.conf to connect to the Ceph cluster and install the ceph cli
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** client_id - name of the client to find the correct id for key
** keypath - path to the clients key file

=== key ===

Keyring management, authentication. It would be a class to create keys for new users (e.g. a user that can create RBDs or use the Objectstore) which may special access rights. But would also be used by the other classes like ceph::mon or ceph::osd to place e.g. the shared 'client.admin' or 'mon.' keys. I would handle here all key related tasks.

* '''proposed name''': ceph::key
* '''purpose''': handles ceph keys (cephx), generates keys, creates keyring files, incject keys into or delete keys from the cluster/keyring via ceph and ceph-authtool tools.
* '''interface''':
** secret - key secret
** keyring_path - path to the keyring
** cap_mon/cap_osd/cap_mds - cephx capabilities
** user/group/mode: settings for the keyring file if needed
** inject - options to inject a key into the cluster

=== pool ===

* '''proposed name''': ceph::pool
* '''purpose''': manage operations on the pools in the cluster such as: create/delete pools, set PG/PGP number
* '''interface''':
** pool_name - name of the pool
** create - if to create a new pool
** delete - if to delete an existing pool
** pg_num - number of Placement Groups (PGs) for a pool, if the pool already exists this may increase the number of PGs if the current value is lower
** pgp_num - same as for pg_num
** replica_level - increase or decrease the replica level of a pool

== OpenStack components ==

ceph specific configuration for cinder/glance (already provided by the puppet-cinder and puppet-glance modules in the volume/rdb and backend/rdb classes)

== RadosGW components ==

The RadosGW is developped as an integral part of Ceph. It is however not required to deploy a cluster and should be treated as any client application of the cluster.

=== rgw ===

* '''proposed name''': ceph::rgw
* '''purpose''': configures a ceph radosgw , setup /etc/ceph/ceph.conf with the MONs IPs, optionaly set the key to allow the OSD to connect to the MONs
* '''interface''':
** monitor_ips - list of ip addresses used to connect to the monitor servers
** key - the secret key for the id user
** id - the id of the user
** rgw_data - the path where the radosgw data should be stored
** fcgi_file - path to the fcgi file e.g. /var/www/s3gw.fcgi
:: [[User:Danny Al-Gaaf|Danny Al-Gaaf]] ([[User talk:Danny Al-Gaaf|talk]]) the monitor_ips are not needed: IMO ceph::conf should provide these information to all other

=== rgw_user ===

* '''proposed name''': ceph::rgw_user
* '''purpose''': create/remove users and Swift users for the RadosGW S3/Swift API
* '''interface''':
** user - username
** key - secret key (could get generated if needed)
** swift_user - username for the Swift API user
** swift_key - secret key for the Swift API user

== Related tools and implementations ==

* deploy ceph : ceph-deploy

for test / POC purposes
https://github.com/ceph/ceph-deploy

maintainer: Alfredo Deza

* deploy ceph with puppet : puppet-cephdeploy

relies on ceph-deploy
https://github.com/dontalton/puppet-cephdeploy/

maintainer: Don Talton

* deploy ceph with puppet : puppet-ceph

developped in 2012 but still useful, upstream
https://github.com/enovance/puppet-ceph

maintainer: community

fork of puppet-ceph, updated recently
https://github.com/TelekomCloud/puppet-ceph/tree/rc/eisbrecher

maintainer: Deutsche Telekom AG (DTAG)

* ceph + openstack : ceph docs

manual integration
http://ceph.com/docs/next/rbd/rbd-openstack/
maintainer: John Wilkins + Josh Durgin

* ceph + openstack with puppet : stackforge

https://github.com/stackforge/puppet-glance/blob/stable/grizzly/manifests/backend/rbd.pp
https://github.com/stackforge/puppet-cinder/blob/stable/grizzly/manifests/volume/rbd.pp

maintainer: community

* ceph + openstack with puppet : COI

targeting Cisco use case
https://github.com/CiscoSystems/puppet-coe/tree/grizzly/manifests/ceph
http://docwiki.cisco.com/wiki/OpenStack:Ceph-COI-Installation

maintainer : Don Talton + Robert Starmer

* ceph + openstack with puppet : mirantis

in the context of Fuel
https://github.com/Mirantis/fuel/tree/master/deployment/puppet/ceph
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/cinder/manifests/volume/ceph.pp
https://github.com/Mirantis/fuel/blob/master/deployment/puppet/glance/manifests/backend/ceph.pp

maintainer : Andrew Woodward

* openstack with puppet : openstack-installer

data driven approach to deploy OpenStack
https://github.com/CiscoSystems/openstack-installer/

maintainer: Robert Starmer + Dan Bode