OpenStack - User contributions [en]

Category:Icehouse

2014-09-22T23:18:23Z

Ryan Lane:

[[Category:Releases]]

Designate/Old Incubation Application

2013-05-08T17:50:51Z

Ryan Lane: /* Other project developers and qualifications */

== Project codename ==

Moniker

== Summary ==

Moniker DNSaaS Project

== Detailed Description ==

Moniker is a DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

The purpose of the project is provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

Moniker is relevant to the mission by adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. It's relevant to other OpenStack projects by automating the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project ==

=== The current release provides ===

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box
* Command Line Interface
* Python Bindings

=== Future release plans ===

* DNSSEC
* Development of functionality to utilize moniker-sink to process events from Nova and Quantum
* Import/Export of Domains via BIND9 style zone files
* Private/Internal DNS servers

== Location of project source code ==

* [https://launchpad.net/moniker Moniker on Launchpad]
* [https://github.com/stackforge/moniker/ Moniker at StackForge]
* [https://github.com/stackforge/python-monikerclient/ python-monikerclient at StackForge]

== Programming language, required technology dependencies ==

;Language: Python

;Dependencies: flask, message queue, DNS server, database server

== Is project currently open sourced? What license? ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team ==

* Software: Private Beta at HPCS. Implementations at other organizations.
* Team: Working together for six months

== Proposed project technical lead and qualifications ==

;Kiall Mac Innes (kiall): Kiall has worked on OpenStack for ~2 years. He has an extensive understanding of DNS and is the lead author of Moniker.

== Other project developers and qualifications ==

;Simon McCartney (simonmcc): Simon has Extensive DNS, Orchestration, Database, and operation experience.

;Patrick Galbraith (CaptTofu): Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

;Endre Karlson (zykes-): DNS, Linux, Orchestration, Database, Python, Ruby, Billingstack

;Ryan Lane (Ryan_Lane): Experience with operating other OpenStack projects, maintainer of legacy nova dns code and maintainer of DNS code for Wikimedia Labs. Will use Moniker in production soon and will be writing a gdnsd driver.

== Infrastructure requirements (testing, etc) ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8. No additional infrastructure requirements are expected.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Related Links ==

* [http://moniker.readthedocs.org/ Documentation]
* [https://wiki.openstack.org/wiki/Moniker Moniker on OpenStack Wiki]
* [http://openstacksummitapril2013.sched.org/event/c45a03b565d5302b50e3edc1f43756ea#.UXB8nYdxdok Moniker Talk at the Portland Summit]
* [https://docs.google.com/document/d/1UFoAc7E17XivlV7h2PD4SCMeEhLecvPw0GAaoq_JKCk/edit Openstack DNS solutions comparison pre-San Diego Summit]
* [https://etherpad.openstack.org/openstack-dns San Diego Summit Etherpad]

== Status ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T23:16:19Z

Ryan Lane: /* Programming language, required technology dependencies: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

The purpose of the project is provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

Moniker is relevant to the mission by adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. It's relevant to other OpenStack projects by automating the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box
* Command Line Interface
* Python Bindings

== Location of project source code: ==

* [https://launchpad.net/moniker Moniker on Launchpad]
* [https://github.com/stackforge/moniker/ Moniker at StackForge]
* [https://github.com/stackforge/python-monikerclient/ python-monikerclient at StackForge]

== Programming language, required technology dependencies: ==

;Language: Python

;Dependencies: flask, message queue, DNS server, database server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

* Software: Private Beta at HPCS. Implementations at other organizations.
* Team: Working together for six months

== Proposed project technical lead and qualifications: ==

;Kiall Mac Innes (kiall): Kiall has worked on Openstack for 2 years. He has an extensive understanding of DNS and is the lead author of Moniker.

== Other project developers and qualifications: ==

;Simon McCartney (simonmcc) :Simon has Extensive DNS, Orchestration, Database, and operation experience.

;Patrick Galbraith (capttofu): Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

;Endre Karlson (zykes-):

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Related Links ==

* [http://moniker.readthedocs.org/ Documentation]
* [https://wiki.openstack.org/wiki/Moniker Moniker on OpenStack Wiki]
* [http://openstacksummitapril2013.sched.org/event/c45a03b565d5302b50e3edc1f43756ea#.UXB8nYdxdok Moniker Talk at the Portland Summit]
* [https://docs.google.com/document/d/1UFoAc7E17XivlV7h2PD4SCMeEhLecvPw0GAaoq_JKCk/edit Openstack DNS solutions comparison pre-San Diego Summit]
* [https://etherpad.openstack.org/openstack-dns San Diego Summit Etherpad]

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T23:16:06Z

Ryan Lane: /* Programming language, required technology dependencies: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

The purpose of the project is provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

Moniker is relevant to the mission by adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. It's relevant to other OpenStack projects by automating the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box
* Command Line Interface
* Python Bindings

== Location of project source code: ==

* [https://launchpad.net/moniker Moniker on Launchpad]
* [https://github.com/stackforge/moniker/ Moniker at StackForge]
* [https://github.com/stackforge/python-monikerclient/ python-monikerclient at StackForge]

== Programming language, required technology dependencies: ==

;Language: Python
;Dependencies: flask, message queue, DNS server, database server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

* Software: Private Beta at HPCS. Implementations at other organizations.
* Team: Working together for six months

== Proposed project technical lead and qualifications: ==

;Kiall Mac Innes (kiall): Kiall has worked on Openstack for 2 years. He has an extensive understanding of DNS and is the lead author of Moniker.

== Other project developers and qualifications: ==

;Simon McCartney (simonmcc) :Simon has Extensive DNS, Orchestration, Database, and operation experience.

;Patrick Galbraith (capttofu): Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

;Endre Karlson (zykes-):

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Related Links ==

* [http://moniker.readthedocs.org/ Documentation]
* [https://wiki.openstack.org/wiki/Moniker Moniker on OpenStack Wiki]
* [http://openstacksummitapril2013.sched.org/event/c45a03b565d5302b50e3edc1f43756ea#.UXB8nYdxdok Moniker Talk at the Portland Summit]
* [https://docs.google.com/document/d/1UFoAc7E17XivlV7h2PD4SCMeEhLecvPw0GAaoq_JKCk/edit Openstack DNS solutions comparison pre-San Diego Summit]
* [https://etherpad.openstack.org/openstack-dns San Diego Summit Etherpad]

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T23:12:09Z

Ryan Lane: /* Detailed Description: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

The purpose of the project is provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

Moniker is relevant to the mission by adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. It's relevant to other OpenStack projects by automating the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box
* Command Line Interface
* Python Bindings

== Location of project source code: ==

* [https://launchpad.net/moniker Moniker on Launchpad]
* [https://github.com/stackforge/moniker/ Moniker at StackForge]
* [https://github.com/stackforge/python-monikerclient/ python-monikerclient at StackForge]

== Programming language, required technology dependencies: ==

Python, Message Queue, PowerDNS, BIND9 or other DNS server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

* Software: Private Beta at HPCS. Implementations at other organizations.
* Team: Working together for six months

== Proposed project technical lead and qualifications: ==

;Kiall Mac Innes (kiall): Kiall has worked on Openstack for 2 years. He has an extensive understanding of DNS and is the lead author of Moniker.

== Other project developers and qualifications: ==

;Simon McCartney (simonmcc) :Simon has Extensive DNS, Orchestration, Database, and operation experience.

;Patrick Galbraith (capttofu): Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

;Endre Karlson (zykes-):

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Related Links ==

* [http://moniker.readthedocs.org/ Documentation]
* [https://wiki.openstack.org/wiki/Moniker Moniker on OpenStack Wiki]
* [http://openstacksummitapril2013.sched.org/event/c45a03b565d5302b50e3edc1f43756ea#.UXB8nYdxdok Moniker Talk at the Portland Summit]
* [https://docs.google.com/document/d/1UFoAc7E17XivlV7h2PD4SCMeEhLecvPw0GAaoq_JKCk/edit Openstack DNS solutions comparison pre-San Diego Summit]
* [https://etherpad.openstack.org/openstack-dns San Diego Summit Etherpad]

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T23:02:48Z

Ryan Lane: /* Location of project source code: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

=== What is the purpose of the project and vision for it? ===

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

=== Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform: ===

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box
* Command Line Interface
* Python Bindings

== Location of project source code: ==

* [https://github.com/stackforge/moniker/ Moniker at GitHub]
* [https://github.com/stackforge/python-monikerclient/ python-monikerclient at StackForge]

== Programming language, required technology dependencies: ==

Python, Message Queue, PowerDNS, BIND9 or other DNS server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

* Software: Private Beta at HPCS. Implementations at other organizations.
* Team: Working together for six months

== Proposed project technical lead and qualifications: ==

;Kiall Mac Innes (kiall): Kiall has worked on Openstack for 2 years. He has an extensive understanding of DNS and is the lead author of Moniker.

== Other project developers and qualifications: ==

;Simon McCartney (simonmcc) :Simon has Extensive DNS, Orchestration, Database, and operation experience.

;Patrick Galbraith (capttofu): Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

;Endre Karlson (zykes-):

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T23:01:35Z

Ryan Lane: /* Proposed project technical lead and qualifications: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

=== What is the purpose of the project and vision for it? ===

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

=== Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform: ===

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box
* Command Line Interface
* Python Bindings

== Location of project source code: ==

https://github.com/stackforge/moniker/ and https://github.com/stackforge/python-monikerclient/

== Programming language, required technology dependencies: ==

Python, Message Queue, PowerDNS, BIND9 or other DNS server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

* Software: Private Beta at HPCS. Implementations at other organizations.
* Team: Working together for six months

== Proposed project technical lead and qualifications: ==

;Kiall Mac Innes (kiall): Kiall has worked on Openstack for 2 years. He has an extensive understanding of DNS and is the lead author of Moniker.

== Other project developers and qualifications: ==

;Simon McCartney (simonmcc) :Simon has Extensive DNS, Orchestration, Database, and operation experience.

;Patrick Galbraith (capttofu): Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

;Endre Karlson (zykes-):

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T23:01:08Z

Ryan Lane: /* Other project developers and qualifications: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

=== What is the purpose of the project and vision for it? ===

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

=== Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform: ===

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box
* Command Line Interface
* Python Bindings

== Location of project source code: ==

https://github.com/stackforge/moniker/ and https://github.com/stackforge/python-monikerclient/

== Programming language, required technology dependencies: ==

Python, Message Queue, PowerDNS, BIND9 or other DNS server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

* Software: Private Beta at HPCS. Implementations at other organizations.
* Team: Working together for six months

== Proposed project technical lead and qualifications: ==

Kiall Mac Innes (kiall)

Kiall has worked on Openstack for 2 years. He has an extensive understanding of DNS and is the lead author of Moniker.

== Other project developers and qualifications: ==

;Simon McCartney (simonmcc) :Simon has Extensive DNS, Orchestration, Database, and operation experience.

;Patrick Galbraith (capttofu): Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

;Endre Karlson (zykes-):

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T22:59:44Z

Ryan Lane: /* Proposed project technical lead and qualifications: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

=== What is the purpose of the project and vision for it? ===

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

=== Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform: ===

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box

== Location of project source code: ==

https://github.com/stackforge/moniker/

== Programming language, required technology dependencies: ==

Python, Message Queue, PowerDNS, BIND9 or other DNS server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

* Software: Private Beta at HPCS. Implementations at other organizations.
* Team: Working together for six months

== Proposed project technical lead and qualifications: ==

Kiall Mac Innes (kiall)

Kiall has worked on Openstack for 2 years. He has an extensive understanding of DNS and is the lead author of Moniker.

== Other project developers and qualifications: ==

Simon McCartney (simonmcc)

Simon has Extensive DNS, Orchestration, Database, and operation experience.

Patrick Galbraith (capttofu)

Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

Endre Karlson (zykes-)

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T22:59:28Z

Ryan Lane: /* Level of maturity of software and team: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

=== What is the purpose of the project and vision for it? ===

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

=== Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform: ===

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box

== Location of project source code: ==

https://github.com/stackforge/moniker/

== Programming language, required technology dependencies: ==

Python, Message Queue, PowerDNS, BIND9 or other DNS server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

* Software: Private Beta at HPCS. Implementations at other organizations.
* Team: Working together for six months

== Proposed project technical lead and qualifications: ==

Kiall Mac Innes (kiall)

Kiall has worked on Openstack for 2 years. He has an extensive understand of DNS and is the lead author of Moniker

== Other project developers and qualifications: ==

Simon McCartney (simonmcc)

Simon has Extensive DNS, Orchestration, Database, and operation experience.

Patrick Galbraith (capttofu)

Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

Endre Karlson (zykes-)

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T22:58:58Z

Ryan Lane: /* Level of maturity of software and team: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

=== What is the purpose of the project and vision for it? ===

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

=== Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform: ===

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box

== Location of project source code: ==

https://github.com/stackforge/moniker/

== Programming language, required technology dependencies: ==

Python, Message Queue, PowerDNS, BIND9 or other DNS server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

;Software:: Private Beta at HPCS. Implementations at other organizations.
;Team:: Working together for six months

== Proposed project technical lead and qualifications: ==

Kiall Mac Innes (kiall)

Kiall has worked on Openstack for 2 years. He has an extensive understand of DNS and is the lead author of Moniker

== Other project developers and qualifications: ==

Simon McCartney (simonmcc)

Simon has Extensive DNS, Orchestration, Database, and operation experience.

Patrick Galbraith (capttofu)

Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

Endre Karlson (zykes-)

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T22:58:45Z

Ryan Lane: /* Level of maturity of software and team: */

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

=== What is the purpose of the project and vision for it? ===

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

=== Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform: ===

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project: ==

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box

== Location of project source code: ==

https://github.com/stackforge/moniker/

== Programming language, required technology dependencies: ==

Python, Message Queue, PowerDNS, BIND9 or other DNS server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

;Software: Private Beta at HPCS. Implementations at other organizations.
;Team: Working together for six months

== Proposed project technical lead and qualifications: ==

Kiall Mac Innes (kiall)

Kiall has worked on Openstack for 2 years. He has an extensive understand of DNS and is the lead author of Moniker

== Other project developers and qualifications: ==

Simon McCartney (simonmcc)

Simon has Extensive DNS, Orchestration, Database, and operation experience.

Patrick Galbraith (capttofu)

Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

Endre Karlson (zykes-)

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Status: ==

To be completed by PPB

Designate/Old Incubation Application

2013-04-18T22:57:24Z

Ryan Lane:

== Project codename: ==

Moniker

== Summary: ==

Moniker DNSaaS Project

== Detailed Description: ==

Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

=== What is the purpose of the project and vision for it? ===

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

=== Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform: ===

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

== Basic roadmap for the project ==:

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box

== Location of project source code: ==

https://github.com/stackforge/moniker/

== Programming language, required technology dependencies: ==

Python, Message Queue, PowerDNS, BIND9 or other DNS server

== Is project currently open sourced? What license?: ==

Yes, under the Apache 2.0 license.

== Level of maturity of software and team: ==

Software: Private Beta at HPCS. Implementations at other organizations.
Team: Working together for six months

== Proposed project technical lead and qualifications: ==

Kiall Mac Innes (kiall)

Kiall has worked on Openstack for 2 years. He has an extensive understand of DNS and is the lead author of Moniker

== Other project developers and qualifications: ==

Simon McCartney (simonmcc)

Simon has Extensive DNS, Orchestration, Database, and operation experience.

Patrick Galbraith (capttofu)

Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

Endre Karlson (zykes-)

== Infrastructure requirements (testing, etc): ==

Currently on StackForge using Gerrit and Jenkins to runs the unit test suite and pyflakes plus pep8.

== Have all current contributors agreed to the OpenStack CLA? ==

Yes.

== Status: ==

To be completed by PPB

Designate

2013-04-18T22:51:37Z

Ryan Lane: /* Status */

= Overview =

Moniker provides DNSaaS services for [[OpenStack]]:
* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS and Bind9 out of the box

= Status =

[[Moniker Incubation Application|Applying for incubation]]

= Source =
[https://github.com/stackforge/moniker StackForge GitHub]

[https://launchpad.net/moniker Launchpad]

[http://moniker.readthedocs.org Python documentation]

[http://wiki.openstack.org/GerritWorkflow Contributing]

= Design Discussions =

[[Moniker/Deployment|Agent Based design implications on deployment options]]

[[Category:Related Projects]]

Designate/Old Incubation Application

2013-04-18T22:50:26Z

Ryan Lane: Ryan Lane moved page MonikerIncubationApplication to Moniker Incubation Application

'''Project codename''': Moniker

'''Summary''' (one sentence abstract of the project): Moniker DNSaaS Project

'''Detailed Description''': Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

What is the purpose of the project and vision for it?

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform:

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

'''Basic roadmap for the project''':

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box

'''Location of project source code''':

https://github.com/stackforge/moniker/

'''Programming language, required technology dependencies''':

Python, Message Queue, PowerDNS, BIND9 or other DNS server

'''Is project currently open sourced? What license?''':

Yes, under the Apache 2.0 license.

'''Level of maturity of software and team''':

Software: Private Beta at HPCS. Implementations at other organizations
Team: Working together for six months

'''Proposed project technical lead and qualifications''':

Kiall Mac Innes

Kiall has worked on Openstack for 2 years. He has an extensive understand of DNS and is the lead author of Moniker

'''Other project developers and qualifications''':

Simon McCartney

Simon has Extensive DNS, Orchestration, Database, and operation experience.

Patrick Galbraith

Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

'''Infrastructure requirements (testing, etc)''':

Currently on Stackforge using Gerrit and Jenkins which runs the unit test suite and pyflakes plus pep8.

'''Have all current contributors agreed to the OpenStack CLA?'''

Yes

'''Status''': To be completed by PPB

MonikerIncubationApplication

2013-04-18T22:50:26Z

Ryan Lane: Ryan Lane moved page MonikerIncubationApplication to Moniker Incubation Application

#REDIRECT [[Moniker Incubation Application]]

Designate

2013-04-18T22:49:54Z

Ryan Lane: /* Status */

= Overview =

Moniker provides DNSaaS services for [[OpenStack]]:
* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS and Bind9 out of the box

= Status =

[[MonikerIncubationApplication|Applying for incubation]]

= Source =
[https://github.com/stackforge/moniker StackForge GitHub]

[https://launchpad.net/moniker Launchpad]

[http://moniker.readthedocs.org Python documentation]

[http://wiki.openstack.org/GerritWorkflow Contributing]

= Design Discussions =

[[Moniker/Deployment|Agent Based design implications on deployment options]]

[[Category:Related Projects]]

Designate

2013-04-18T22:48:13Z

Ryan Lane: Reverted edits by CaptTofu (talk) to last revision by Ryan Lane

= Overview =

Moniker provides DNSaaS services for [[OpenStack]]:
* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS and Bind9 out of the box

= Status =
The project has not yet reached an official status. There are two options at this time:
* Incubation process
* Integrate the Quantum project

= Source =
[https://github.com/stackforge/moniker StackForge GitHub]

[https://launchpad.net/moniker Launchpad]

[http://moniker.readthedocs.org Python documentation]

[http://wiki.openstack.org/GerritWorkflow Contributing]

= Design Discussions =

[[Moniker/Deployment|Agent Based design implications on deployment options]]

[[Category:Related Projects]]

Designate/Old Incubation Application

2013-04-18T22:47:48Z

Ryan Lane: Created page with "'''Project codename''': Moniker '''Summary''' (one sentence abstract of the project): Moniker DNSaaS Project '''Detailed Description''': Moniker is a an DNS as-a-service pro..."

'''Project codename''': Moniker

'''Summary''' (one sentence abstract of the project): Moniker DNSaaS Project

'''Detailed Description''': Moniker is a an DNS as-a-service project. It is intended to be used to provide DNS service from the entry point of creating, updating, maintaining and deleting DNS data using the Moniker API, to providing DNS resolution for users. It is a very modular project, allowing for the use of whatever DNS server and organization demands, or the database where DNS data is stored. It is also intended to work in conjunction with other components such as Nova.

What is the purpose of the project and vision for it?

To provide managed DNS for the Openstack Ecosystem using a REST API or Moniker Sink which consumes events from Nova or Quantum, or any other service that has events that would necessitate DNS changes. It also will replace Nova DNS bindings and provide much more robust and full-featured DNS functionality. Also, advanced DNS record support will be added such as DNSSEC.

Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform:

Moniker is adding a missing piece of data-center functionality, namely, one of the most ubiquitous services, DNS. Moniker will automate the name resolution changes required for the creation and deletion of Nova instances or other components.

'''Basic roadmap for the project''':

The current release provides:

* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS, MySQLBind, and Bind out of the box

'''Location of project source code''':

https://github.com/stackforge/moniker/

'''Programming language, required technology dependencies''':

Python

'''Is project currently open sourced? What license?''':

Apache

'''Level of maturity of software and team''':

Software: Private Beta at HPCS. Implementations at other organizations
Team: Working together for six months

'''Proposed project technical lead and qualifications''':

Kiall Mac Innes

Kiall has worked on Openstack for 2 years. He has an extensive understand of DNS and is the lead author of Moniker

'''Other project developers and qualifications''':

Simon McCartney

Simon has Extensive DNS, Orchestration, Database, and operation experience.

Patrick Galbraith

Patrick Galbraith has extensive database, operational and has worked on various aspects of Openstack and related projects (Red Dwarf)

'''Infrastructure requirements (testing, etc)''':

Currently on Stackforge using Gerrit and Jenkins which runs the unit test suite and pyflakes plus pep8.

'''Have all current contributors agreed to the OpenStack CLA?'''

Yes

'''Status''': To be completed by PPB

Designate

2013-04-18T22:15:11Z

Ryan Lane:

= Overview =

Moniker provides DNSaaS services for [[OpenStack]]:
* REST API for domain/record management
* Multi-tenant
* Integrated with Keystone for authentication
* Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)
* Support for PowerDNS and Bind9 out of the box

= Status =
The project has not yet reached an official status. There are two options at this time:
* Incubation process
* Integrate the Quantum project

= Source =
[https://github.com/stackforge/moniker StackForge GitHub]

[https://launchpad.net/moniker Launchpad]

[http://moniker.readthedocs.org Python documentation]

[http://wiki.openstack.org/GerritWorkflow Contributing]

= Design Discussions =

[[Moniker/Deployment|Agent Based design implications on deployment options]]

[[Category:Related Projects]]

User:Ryan Lane

2013-03-27T21:50:09Z

Ryan Lane:

User:Ryan Lane

2013-03-27T21:48:37Z

Ryan Lane: Created page with "[http://google.com test]"

[http://google.com test]

MediaWiki:Common.css

2013-03-27T21:38:00Z

Ryan Lane:

/* CSS placed here will be applied to all skins */

@font-face {
font-family: 'PT Sans';
font-style: normal;
font-weight: 400;
src: local('PT Sans'), local('PTSans-Regular'), url(https://themes.googleusercontent.com/static/fonts/ptsans/v4/LKf8nhXsWg5ybwEGXk8UBQ.woff) format('woff');
}

body.page-Main_Page h1.firstHeading {
display: none;
}

#pt-createaccount, #pt-login {
display: none
}

body {
background-color: #FFFFFF;
font-family: Arial Unicode MS, Arial, sans-serif;
background-image: display:none;
}

h1, h2, h3, h4 {
font-family: 'PT Sans', sans-serif;
}

CLA

2013-03-08T21:54:53Z

Ryan Lane: Redirected page to How To Contribute#Contributors License Agreement

#REDIRECT [[How To Contribute#Contributors License Agreement]]

MediaWiki:Strapping.css

2013-02-19T00:13:42Z

Ryan Lane:

#pt-openidlogin
{
background-image: none !important;
}

#n-Wiki {
border-bottom: 3px solid #cf2f19;
color: #cf2f19;
}

.navbar .nav > li > a {
padding-right: 5px;
padding-left: 5px;
}

#p-logo {
padding-right: 15px;
}

MediaWiki:Strapping.css

2013-02-19T00:11:03Z

Ryan Lane:

#pt-openidlogin
{
background-image: none !important;
}

#n-Wiki {
border-bottom: 3px solid #cf2f19;
color: #cf2f19;
}

.navbar .nav > li > a {
padding-right: 5px;
padding-left: 5px;
}

MediaWiki:Strapping.css

2013-02-19T00:10:37Z

Ryan Lane:

#pt-openidlogin
{
background-image: none !important;
}

#n-Wiki {
border-bottom: 3px solid #cf2f19;
color: #cf2f19;
}

.navbar .nav > li > a {
padding-right: 10px;
padding-left: 10px;
}

Main Page

2013-02-18T00:15:39Z

Ryan Lane:

<div id="mf-index">{{:Header}}
<br />
'''The OpenStack [[Open]] Source Cloud Mission:''' to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.<br />
<br />
----
<table border=0 width=100%><tr valign=top>
<td>
=== Computing ===
[[File:Openstack-compute-icon.png]]

OpenStack Compute ('''[[Nova]]''')

OpenStack Image service ('''[[Glance]]''')
</td><td>
=== Networking ===
[[File:Openstack-networking-icon.png]]

OpenStack Networking ('''[[Quantum]]''')
</td><td>
=== Storing ===
[[File:Openstack-object-storage-icon.png]]

OpenStack Object Storage ('''[[Swift]]''')

OpenStack Block Storage ('''[[Cinder]]''')
</td></tr></table>
<br />
----
<table border=0 width=100%><tr valign=top>
<td>
==== Common Projects ====
* OpenStack Dashboard ('''[[Horizon]]''')
* OpenStack Identity ('''[[Keystone]]''')
* OpenStack Common Library ('''[[Oslo]]''')
* [[Documentation]]
* List of OpenStack [[Projects|projects]]
* All OpenStack [[Releases|releases]]

==== Contribute to OpenStack ====
* '''[[How To Contribute]]'''
* Sign the [[CLA|Contributor agreement]]
* [[Release Cycle|Explanation of the Release cycle]]
* [[Getting The Code|Getting the Code]]
* [[Gerrit Workflow|Submitting Code (Gerrit Workflow)]]
* [https://review.openstack.org/ Gerrit code review system]
* [https://jenkins.openstack.org/ Jenkins continuous integration system]
* [http://status.openstack.org/release/ Status of current development release]
</td><td>
==== Community ====
* [[Open]] - What openness means to us
* [[Governance]] - How OpenStack is governed
* [[Teams]] - Join them!
* [[People|Who we are]]
* [[Meetings|Online Meetings]]
* [[Summit|Design Summits]]
* [[OpenStack User Groups]]

==== Resources ====
* [[Mailing Lists|OpenStack Mailing Lists]]
* [[IRC|IRC channels]]
* [[How To Use The Wiki|How to use this wiki]]
* [http://www.openstack.org/blog/category/newsletter/ OpenStack Blog], with [http://www.openstack.org/blog/category/newsletter/ weekly newsletters]
* [http://planet.openstack.org/ Planet OpenStack] - Blogs about OpenStack
* [http://forums.openstack.org/ OpenStack forums]
* [[Bloggers Tips]] - Technical Tips about OpenStack
* [[Project Resources|Other resources]]
</td>
</tr></table>
__NOTOC__
__NOEDITSECTION__
</div>

Neutron

2013-02-17T23:50:02Z

Ryan Lane:

= OpenStack Networking ("Quantum") =

{| border="1" cellpadding="2" cellspacing="0"
| Administrator Guide
|-
| API Developer Doc (v2)
|-
| Source code
|-
| Bug tracker
|-
| Blueprints
|}

== Related projects ==
* [https://launchpad.net/python-quantumclient Python Quantum client]
* Quantum Admin and API documentation in [https://launchpad.net/openstack-manuals OpenStack Manuals]

== What is Quantum? ==

Quantum is an [https://wiki.openstack.org OpenStack] project to provide "networking as a service" between interface devices (e.g., vNICs) managed by other Openstack services (e.g., nova).

Starting in the Folsom release, Quantum is a core and supported part of the [https://wiki.openstack.org OpenStack] platform (for Essex, we were an "incubated" project, which means use is suggested only for those who really know what they're doing with Quantum).

If you're a networking geek and like to hack on [https://wiki.openstack.org OpenStack], please join!

More Info:
* [http://www.slideshare.net/danwent/openstack-quantum-intro-os-meetup-32612 Overview of Quantum] (slides) (3/12)
* [https://www.youtube.com/watch?v=_I1SrO2QBpg Quantum Project Overview + Update from Grizzly Summit] (video) (10/12)
* [http://www.infoq.com/presentations/Quantum-Virtual-Networks-for-OpenStack Video Quantum Overview] (3/12)
* [http://wiki.openstack.org/Quantum?action=AttachFile&do=get&target=quantum-technical-archicture.ppt Slides on Technical Architecture of Quantum] (9/12)

== Why Quantum? ==

* Give cloud tenants an API to build rich networking topologies, and configure advanced network policies in the cloud.
** Example: create multi-tier web application topology
* Enable innovation plugins (open and closed source) that introduce advanced network capabilities
** Example: use L2-in-L3 tunneling to avoid VLAN limits, provide end-to-end QoS guarantees, used monitoring protocols like [[NetFlow]].
* Let anyone build advanced network services (open and closed source) that plug into Openstack tenant networks.
** Examples: LB-aaS, VPN-aaS, firewall-aaS, IDS-aaS, data-center-interconnect-aaS.

== Using Quantum ==

Following the instructions in the [http://docs.openstack.org/incubation/openstack-network/admin/content/ Quantum Administrator Guide] to use Quantum with OpenStack Nova.

Forget documentation, I just want to get the code!: [https://launchpad.net/quantum/+download Quantum Downloads]

Detailed information for programming against v2.0 of the Quantum web services API is available in the [http://docs.openstack.org/api/openstack-network/2.0/content/ Quantum API Guide]

If you are looking for information on using Quantum with devstack, please see: [[QuantumDevstack]] .

Quantum lets you use a set of different backends called "plugins" that work with a growing variety of networking technologies. These plugins may be distributed as part of the main Quantum release, or separately.

The set of plugins included in the main Quantum distribution and supported by the Quantum community include:

* [http://www.openvswitch.org Open vSwitch] Plugin
* [http://wiki.openstack.org/cisco-quantum Cisco UCS/Nexus] Plugin
* [http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin Linux Bridge] Plugin
* [http://www.nicira.com Nicira Network Virtualization Platform (NVP)] Plugin
* [http://www.osrg.net/ryu/using_with_openstack.html Ryu OpenFlow Controller] Plugin
* [[Quantum NEC OpenFlow Plugin|NEC OpenFlow]] Plugin
* [http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin Big Switch OpenFlow Controller Plugin]
* [http://www.cloudbase.it/quantum-hyper-v-plugin/ Cloudbase Hyper-V] Plugin

Additional plugins are available from other sources:

* [http://floodlight.openflowhub.org/quantum-and-openstack/ Floodlight OpenFlow Controller] Plugin
* [https://github.com/midokura/midonet-openstack MidoNet] Plugin
* [http://www.extremenetworks.com Extreme Networks] Plugin
* (NEW) [https://github.com/ruijie/rgos_quantum_plugin Ruijie Networks] Plugin
* [https://github.com/brocade/brocade Brocade Quantum Plugin] Brocade Quantum Plugin

If you have your own plugin, feel free to add it to this list.

== Current Project Status ==

The 2012.2 "Folsom" release includes:

* v2.0 of the Quantum API, including support for L2 networking and IP Address Management (IPAM)
* Integration with Keystone for API authentication
* API Extensibility Framework, including extensions for:
** "provider network", which maps Quantum L2 networks to a specific VLAN in the physical data center
** "L3 routers", which supports a basic L3 router construct to route between L2 networks, and provide a gateway to external networks with support for SNAT and floating IPs.
* Updated API Client Library and CLI, including support for filtering.
* Horizon GUI support for:
** Quantum network and subnet creation/deletion
** Booting VMs on specific Quantum networks.
* Several plugins:
** [http://www.openvswitch.org Open vSwitch] Plugin
** [http://wiki.openstack.org/cisco-quantum Cisco UCS/Nexus] Plugin
** [http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin Linux Bridge] Plugin
** [http://www.nicira.com Nicira Network Virtualization Platform (NVP)] Plugin
** [http://www.osrg.net/ryu/using_with_openstack.html Ryu OpenFlow Controller] Plugin
** (NEW) [http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin NEC OpenFlow] Plugin

== Participate ==

To get code, ask questions, view blueprints, etc, see: [https://launchpad.net/quantum/ Quantum Launchpad Page]

See [[QuantumDevelopment]] for some (rough) guides on how to contribute code to Quantum, including how to add your own plugin.

If you would like to participate, please send mail to the main openstack-dev list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

You can also attend our regular IRC meetings, which start one hour after the main openstack meeting, on the same #openstack-meeting channel: http://wiki.openstack.org/Network/Meetings

Check out [[QuantumStarterBugs]] for ideas on easy bugs or starter projects you might tackle. Or just start playing with [[QuantumDevstack]] and come up with your own ideas!

Neutron

2013-02-17T23:49:16Z

Ryan Lane: /* Using Quantum */

= OpenStack Networking ("Quantum") =

{| border="1" cellpadding="2" cellspacing="0"
| Administrator Guide
|-
| API Developer Doc (v2)
|-
| Source code
|-
| Bug tracker
|-
| Blueprints
|}

== Related projects ==
* [https://launchpad.net/python-quantumclient Python Quantum client]
* Quantum Admin and API documentation in [https://launchpad.net/openstack-manuals OpenStack Manuals]

== What is Quantum? ==

Quantum is an [https://wiki.openstack.org OpenStack] project to provide "networking as a service" between interface devices (e.g., vNICs) managed by other Openstack services (e.g., nova).

Starting in the Folsom release, Quantum is a core and supported part of the [https://wiki.openstack.org OpenStack] platform (for Essex, we were an "incubated" project, which means use is suggested only for those who really know what they're doing with Quantum).

If you're a networking geek and like to hack on [https://wiki.openstack.org OpenStack], please join!

More Info:
* [http://www.slideshare.net/danwent/openstack-quantum-intro-os-meetup-32612 Overview of Quantum ] (slides) (3/12)
* [https://www.youtube.com/watch?v=_I1SrO2QBpg Quantum Project Overview + Update from Grizzly Summit ] (video) (10/12)
* [http://www.infoq.com/presentations/Quantum-Virtual-Networks-for-OpenStack Video Quantum Overview ] (3/12)
* [http://wiki.openstack.org/Quantum?action=AttachFile&do=get&target=quantum-technical-archicture.ppt Slides on Technical Architecture of Quantum] (9/12)

== Why Quantum? ==

* Give cloud tenants an API to build rich networking topologies, and configure advanced network policies in the cloud.
** Example: create multi-tier web application topology
* Enable innovation plugins (open and closed source) that introduce advanced network capabilities
** Example: use L2-in-L3 tunneling to avoid VLAN limits, provide end-to-end QoS guarantees, used monitoring protocols like [[NetFlow]].
* Let anyone build advanced network services (open and closed source) that plug into Openstack tenant networks.
** Examples: LB-aaS, VPN-aaS, firewall-aaS, IDS-aaS, data-center-interconnect-aaS.

== Using Quantum ==

Following the instructions in the [http://docs.openstack.org/incubation/openstack-network/admin/content/ Quantum Administrator Guide] to use Quantum with OpenStack Nova.

Forget documentation, I just want to get the code!: [https://launchpad.net/quantum/+download Quantum Downloads]

Detailed information for programming against v2.0 of the Quantum web services API is available in the [http://docs.openstack.org/api/openstack-network/2.0/content/ Quantum API Guide]

If you are looking for information on using Quantum with devstack, please see: [[QuantumDevstack]] .

Quantum lets you use a set of different backends called "plugins" that work with a growing variety of networking technologies. These plugins may be distributed as part of the main Quantum release, or separately.

The set of plugins included in the main Quantum distribution and supported by the Quantum community include:

* [http://www.openvswitch.org Open vSwitch] Plugin
* [http://wiki.openstack.org/cisco-quantum Cisco UCS/Nexus] Plugin
* [http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin Linux Bridge] Plugin
* [http://www.nicira.com Nicira Network Virtualization Platform (NVP)] Plugin
* [http://www.osrg.net/ryu/using_with_openstack.html Ryu OpenFlow Controller] Plugin
* [[Quantum NEC OpenFlow Plugin|NEC OpenFlow]] Plugin
* [http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin Big Switch OpenFlow Controller Plugin]
* [http://www.cloudbase.it/quantum-hyper-v-plugin/ Cloudbase Hyper-V] Plugin

Additional plugins are available from other sources:

* [http://floodlight.openflowhub.org/quantum-and-openstack/ Floodlight OpenFlow Controller] Plugin
* [https://github.com/midokura/midonet-openstack MidoNet] Plugin
* [http://www.extremenetworks.com Extreme Networks] Plugin
* (NEW) [https://github.com/ruijie/rgos_quantum_plugin Ruijie Networks] Plugin
* [https://github.com/brocade/brocade Brocade Quantum Plugin] Brocade Quantum Plugin

If you have your own plugin, feel free to add it to this list.

== Current Project Status ==

The 2012.2 "Folsom" release includes:

* v2.0 of the Quantum API, including support for L2 networking and IP Address Management (IPAM)
* Integration with Keystone for API authentication
* API Extensibility Framework, including extensions for:
** "provider network", which maps Quantum L2 networks to a specific VLAN in the physical data center
** "L3 routers", which supports a basic L3 router construct to route between L2 networks, and provide a gateway to external networks with support for SNAT and floating IPs.
* Updated API Client Library and CLI, including support for filtering.
* Horizon GUI support for:
** Quantum network and subnet creation/deletion
** Booting VMs on specific Quantum networks.
* Several plugins:
** [http://www.openvswitch.org Open vSwitch ] Plugin
** [http://wiki.openstack.org/cisco-quantum Cisco UCS/Nexus] Plugin
** [http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin Linux Bridge] Plugin
** [http://www.nicira.com Nicira Network Virtualization Platform (NVP) ] Plugin
** [http://www.osrg.net/ryu/using_with_openstack.html Ryu OpenFlow Controller ] Plugin
** (NEW) [http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin NEC OpenFlow ] Plugin

== Participate ==

To get code, ask questions, view blueprints, etc, see: [https://launchpad.net/quantum/ Quantum Launchpad Page]

See [[QuantumDevelopment]] for some (rough) guides on how to contribute code to Quantum, including how to add your own plugin.

If you would like to participate, please send mail to the main openstack-dev list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

You can also attend our regular IRC meetings, which start one hour after the main openstack meeting, on the same #openstack-meeting channel: http://wiki.openstack.org/Network/Meetings

Check out [[QuantumStarterBugs]] for ideas on easy bugs or starter projects you might tackle. Or just start playing with [[QuantumDevstack]] and come up with your own ideas!

Neutron

2013-02-17T23:48:45Z

Ryan Lane: /* Using Quantum */

= OpenStack Networking ("Quantum") =

{| border="1" cellpadding="2" cellspacing="0"
| Administrator Guide
|-
| API Developer Doc (v2)
|-
| Source code
|-
| Bug tracker
|-
| Blueprints
|}

== Related projects ==
* [https://launchpad.net/python-quantumclient Python Quantum client]
* Quantum Admin and API documentation in [https://launchpad.net/openstack-manuals OpenStack Manuals]

== What is Quantum? ==

Quantum is an [https://wiki.openstack.org OpenStack] project to provide "networking as a service" between interface devices (e.g., vNICs) managed by other Openstack services (e.g., nova).

Starting in the Folsom release, Quantum is a core and supported part of the [https://wiki.openstack.org OpenStack] platform (for Essex, we were an "incubated" project, which means use is suggested only for those who really know what they're doing with Quantum).

If you're a networking geek and like to hack on [https://wiki.openstack.org OpenStack], please join!

More Info:
* [http://www.slideshare.net/danwent/openstack-quantum-intro-os-meetup-32612 Overview of Quantum ] (slides) (3/12)
* [https://www.youtube.com/watch?v=_I1SrO2QBpg Quantum Project Overview + Update from Grizzly Summit ] (video) (10/12)
* [http://www.infoq.com/presentations/Quantum-Virtual-Networks-for-OpenStack Video Quantum Overview ] (3/12)
* [http://wiki.openstack.org/Quantum?action=AttachFile&do=get&target=quantum-technical-archicture.ppt Slides on Technical Architecture of Quantum] (9/12)

== Why Quantum? ==

* Give cloud tenants an API to build rich networking topologies, and configure advanced network policies in the cloud.
** Example: create multi-tier web application topology
* Enable innovation plugins (open and closed source) that introduce advanced network capabilities
** Example: use L2-in-L3 tunneling to avoid VLAN limits, provide end-to-end QoS guarantees, used monitoring protocols like [[NetFlow]].
* Let anyone build advanced network services (open and closed source) that plug into Openstack tenant networks.
** Examples: LB-aaS, VPN-aaS, firewall-aaS, IDS-aaS, data-center-interconnect-aaS.

== Using Quantum ==

Following the instructions in the [http://docs.openstack.org/incubation/openstack-network/admin/content/ Quantum Administrator Guide] to use Quantum with OpenStack Nova.

Forget documentation, I just want to get the code!: [https://launchpad.net/quantum/+download Quantum Downloads]

Detailed information for programming against v2.0 of the Quantum web services API is available in the [http://docs.openstack.org/api/openstack-network/2.0/content/ Quantum API Guide]

If you are looking for information on using Quantum with devstack, please see: [[QuantumDevstack]] .

Quantum lets you use a set of different backends called "plugins" that work with a growing variety of networking technologies. These plugins may be distributed as part of the main Quantum release, or separately.

The set of plugins included in the main Quantum distribution and supported by the Quantum community include:

* [http://www.openvswitch.org Open vSwitch] Plugin
* [http://wiki.openstack.org/cisco-quantum Cisco UCS/Nexus] Plugin
* [http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin Linux Bridge] Plugin
* [http://www.nicira.com Nicira Network Virtualization Platform (NVP)] Plugin
* [http://www.osrg.net/ryu/using_with_openstack.html Ryu OpenFlow Controller ] Plugin
* [[Quantum NEC OpenFlow Plugin|NEC OpenFlow]] Plugin
* [http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin Big Switch OpenFlow Controller Plugin]
* [http://www.cloudbase.it/quantum-hyper-v-plugin/ Cloudbase Hyper-V] Plugin

Additional plugins are available from other sources:

* [http://floodlight.openflowhub.org/quantum-and-openstack/ Floodlight OpenFlow Controller] Plugin
* [https://github.com/midokura/midonet-openstack MidoNet] Plugin
* [http://www.extremenetworks.com Extreme Networks] Plugin
* (NEW) [https://github.com/ruijie/rgos_quantum_plugin Ruijie Networks] Plugin
* [https://github.com/brocade/brocade Brocade Quantum Plugin] Brocade Quantum Plugin

If you have your own plugin, feel free to add it to this list.

== Current Project Status ==

The 2012.2 "Folsom" release includes:

* v2.0 of the Quantum API, including support for L2 networking and IP Address Management (IPAM)
* Integration with Keystone for API authentication
* API Extensibility Framework, including extensions for:
** "provider network", which maps Quantum L2 networks to a specific VLAN in the physical data center
** "L3 routers", which supports a basic L3 router construct to route between L2 networks, and provide a gateway to external networks with support for SNAT and floating IPs.
* Updated API Client Library and CLI, including support for filtering.
* Horizon GUI support for:
** Quantum network and subnet creation/deletion
** Booting VMs on specific Quantum networks.
* Several plugins:
** [http://www.openvswitch.org Open vSwitch ] Plugin
** [http://wiki.openstack.org/cisco-quantum Cisco UCS/Nexus] Plugin
** [http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin Linux Bridge] Plugin
** [http://www.nicira.com Nicira Network Virtualization Platform (NVP) ] Plugin
** [http://www.osrg.net/ryu/using_with_openstack.html Ryu OpenFlow Controller ] Plugin
** (NEW) [http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin NEC OpenFlow ] Plugin

== Participate ==

To get code, ask questions, view blueprints, etc, see: [https://launchpad.net/quantum/ Quantum Launchpad Page]

See [[QuantumDevelopment]] for some (rough) guides on how to contribute code to Quantum, including how to add your own plugin.

If you would like to participate, please send mail to the main openstack-dev list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

You can also attend our regular IRC meetings, which start one hour after the main openstack meeting, on the same #openstack-meeting channel: http://wiki.openstack.org/Network/Meetings

Check out [[QuantumStarterBugs]] for ideas on easy bugs or starter projects you might tackle. Or just start playing with [[QuantumDevstack]] and come up with your own ideas!

Ceilometer/Graduation

2013-02-17T23:33:32Z

Ryan Lane: Text replace - "DreamHost" to "DreamHost"

== Why we think we're ready ==
* Deployed and in use at many sites
** DreamHost
** eNovance
** [[CloudWatt]]
** AT&T
** etc...
* Robust multi purpose architecture recently extended to support multiple publishing channels, thus allowing ceilometer to become a metrics source for other tools apart from metering
* Successfully passed the challlenge of being adopted by 3 related projects which have agreed to join or use ceilometer:
** Synaps
** Healthnmon
** [[StackTach]]
* Delivered Folsom within 2 weeks of release, prior to incubation
* Successfully delivered the G2 milestone aligned with the overall project release cycle
* Good integration with all core projects now, including Swift
* Built up a diverse and sustainable core developer community, affiliated to multiple organizations
* Followed openstack community best practices from the outset

== Is our architecture stable? ==
Discussion with Healthnmon and sandywalsh have been deep and involved. We believe their suggestions are still obtainable with only slight modifications to Ceilometer architecture without changing the fundamentals. The main challenge was to explain the reasoning behind our choices which, while different in their approach of the problem of collecting metrics from other projects, provides a solution which:
* allows lean collection of metrics from supporting projects that send events on the Oslo bus
* permits regular fetching of data via a pull mechanism for non-notification-generating projects (i.e. Swift)
* allows more intrusive data collection for non-supported projects via an optional agent mechanism
The same measurements can then be retrieved at different intervals and republished to multiple destinations though a YAML-based configuration mechanism, thus allowing seamless integration of multiple projects around Ceilometer without forcing the use of a single database and API.

There are still some aspects of the architecture that are still emerging (such as database schemas for metadata/rich data and aggregation) and all groups have committed to working on a mutually acceptable solution.

== Testimonials ==
* Rackspace
** Rackspace has committed considerable resources to taking the lessons learned from developing and deploying [[StackTach]] into Ceilometer ([[StackTach]] will be twilighted once comparable functionality is available). Rax has documented some of their discussion points (here: http://wiki.openstack.org/RaxCeilometerRequirements) and we will working through those in the public channels.
* Healthnmon
* Red Hat
** Red Hat has committed two core developers to the project during the Grizzly release cycle, concentrating on rationalizing the nova interaction model, helping shape the v2 API, packaging for Fedora/EPEL/RHEL, and laying the groundwork for metrics & monitoring support. We expect this committment to continue into the Havana cycle.

BenCherian

2013-02-17T23:33:31Z

Ryan Lane: Text replace - "DreamHost" to "DreamHost"

Hi [[OpenStackers]],

My name is Ben Cherian and I'm the GM of Emerging Technologies at DreamHost...which basically means my business unit is in charge of "cloudy" products. Feel free to contact me if you'd like to talk. BTW, we're hiring!!

- Ben

email: ben@dreamhost.com

twitter: http://twitter.com/bencherian

linkedin: http://www.linkedin.com/in/bcherian

WeeklyNewsletter

2013-02-17T23:33:31Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

= [[OpenStack]] Weekly Newsletter & Data =
This section contains weekly data (and link to weekly newsletter) being tracked as part of the Weekly Newsletter. Raw data is provided along with graphs. If you feel that the community needs to track other data items, please add them to this page or contact stefano@openstack.org . Please be aware that I update the three files below every Friday by about Noon PST.

== Weekly Newsletter ==
=== 2011 Weekly Newsletter Links ===
* January 1 - 7, 2011: http://www.openstack.org/blog/2011/01/openstack-weekly-newsletter-january-1-7/
* January 7 - 14, 2011: http://www.openstack.org/blog/2011/01/openstack-weekly-newsletter-january-7-14/
* January 14 - 21, 2011: http://www.openstack.org/blog/2011/01/openstack-weekly-newsletter-january-14-21/
* January 21 - 28, 2011: http://www.openstack.org/blog/2011/01/openstack-weekly-newsletter-january-21-28/
* January 29 - Feb 4, 2011: http://www.openstack.org/blog/2011/02/openstack-weekly-newsletter-january-29-february-4/
* February 11 - 18, 2011: http://www.openstack.org/blog/2011/02/community-weekly-update-take-2/
* February 18 - 25, 2011: http://www.openstack.org/blog/2011/02/community-weekly-newsletter-february-18-25/
* February 26 - March 4, 2011: [http://www.openstack.org/blog/2011/03/community-weekly-newsletter-february-28-–-march-4/ http://www.openstack.org/blog/2011/03/community-weekly-newsletter-february-28-%e2%80%93-march-4/]
* March 5 - March 11, 2011: http://www.openstack.org/blog/2011/03/community-weekly-newsletter-march-5-march-11/
* March 12 - March 18, 2011: http://www.openstack.org/blog/2011/03/community-weekly-newsletter-march-12-18/
* March 19 - March 25, 2011: http://www.openstack.org/blog/2011/03/community-weekly-newsletter-march-19-25/
* March 26 - April 1, 2011: http://www.openstack.org/blog/2011/04/community-weekly-newsletter-march-25-april-1/
* April 1 - April 8, 2011: http://www.openstack.org/blog/2011/04/community-weekly-newsletter-april-2-8/
* April 9 - April 15, 2011: http://www.openstack.org/blog/2011/04/community-weekly-newsletter-april-9-15/
* April 16 - April 22, 2011: http://www.openstack.org/blog/2011/04/community-weekly-newsletter-april-15-22/
* April 29 - May 6, 2011: http://www.openstack.org/blog/2011/05/community-weekly-newsletter-april-29-may-6/
* May 7 - May 13, 2011: http://www.openstack.org/blog/2011/05/community-weekly-newsletter-may-7-13/
* May 14 - May 20, 2011: http://www.openstack.org/blog/2011/05/community-weekly-newsletter-may-13-20/
* May 21 - May 27, 2011: http://www.openstack.org/blog/2011/05/community-weekly-newsletter-may-20-27/
* May 28 - June 3, 2011: http://www.openstack.org/blog/2011/06/community-weekly-newsletter-may-27-june-3/
* June 17 - June 24, 2011: http://www.openstack.org/blog/2011/06/community-weekly-newsletter-june-17-24/
* June 24 - July 1, 2011: http://ow.ly/5uWp8
* July 1 - July 8, 2011: http://www.openstack.org/blog/2011/07/weekly-community-newsletter-july-1-july-8/
* July 8 - 15, 2011: http://www.openstack.org/blog/2011/07/community-weekly-newsletter-july-8-15/
* July 29 - August 5, 2011: http://www.openstack.org/blog/2011/08/community-weekly-newsletter-july-29-august-5/
* August 6 - August 12, 2011: http://www.openstack.org/blog/2011/08/community-weekly-newslettter-august-5-12/
* August 12 - August 19, 2011: http://www.openstack.org/blog/2011/08/community-weekly-review-august-12-19/
* August 19 - August 26, 2011: http://www.openstack.org/blog/2011/08/community-weekly-review-august-19-26/
* September 2 - September 9, 2011: http://www.openstack.org/blog/2011/09/community-weekly-review-september-2-9/
* September 9 - September 16, 2011 http://www.openstack.org/blog/2011/09/community-weekly-review-september-10-16/
* September 16 - September 23, 2011 http://www.openstack.org/blog/2011/09/community-weekly-review-september-17-23/

=== 2010 Weekly Newsletter Page ===
* 2010 Weekly Newsletters (Nov 6 - Dec 31, 2010) - http://wiki.openstack.org/2010_Newsletters

== Community Data Tracking ==
Data being tracked:

* Twitter
** #openstack Tweets and Re-tweets
** openstack Tweets
* Bugs
** New, Open, In-Process, Critical, High Importance, Patched
* Blueprint
** Total, Essential, High, Medium, Low, Undefined
* Website (Openstack.org)
** Visits, Pageviews, New Visits %
** #1 Page, #2 Page, #3 Page, #4 Page, #5 Page (% total hits)
* Mailing Lists (openstack-lists.org) [Membership Numbers]
** Announce, [[AdvisoryBoard]], Operators, Partner, Event, Puppet, Chef, Marketing
* Social Networks [Membership Numbers[
** Facebook Openstack, LinkedIn Openstack, Ohloh.net Swift, Ohloh.net NOVA

=== 2011 Community Data Tracking ===
Raw Files:

* [[attachment:2011 Data Tracking (Excel)]] - (not updated)
* [[attachment:2011 Data Tracking (OpenOffice)]]

=== 2010 Community Data Tracking ===
Two files are available containing the raw data:

* [[attachment:2010 Data Tracking (OpenOffice)]]
* [[attachment:2010 Data Tracking (Excel)]]

Tracked data is graphed over time to show trends, etc. For those of you with Excel access, the Data Tracking file in Excel contains all the graphs. For those of you using [[OpenOffice]], please review the pdf file below showing the latest graphs.

* [[attachment:2010 Data Graphs (pdf)]]

Governance/Proposed/Ceilometer

2013-02-17T23:33:31Z

Ryan Lane: Text replace - "DreamHost" to "DreamHost"

== Ceilometer Incubator Application ==
'''Project codename''': Ceilometer

'''Summary''' (one sentence abstract of the project): New objective since the Grizzly summit: The project aims to become the infrastructure for all measurements within OpenStack.

Previous mission statement: The project aims to deliver a unique point of contact for billing systems to aquire all meters they need to establish customer billing, across all current and future OpenStack core components.

'''Detailed Description''':

What is the purpose of the project and vision for it?

* Provide efficient collection of metering data, in terms of CPU and network costs.
* Allow deployers to integrate with the metering system directly or by replacing components.
* Data may be collected by monitoring notifications sent from existing services or by polling the infrastructure.
* Allow deployers to configure the type of data collected to meet their operating requirements.
* The data collected by the metering system is made visible to some users through a REST API.
* The metering messages are signed and non repudiable (http://en.wikipedia.org/wiki/Non-repudiation)
* The project is for collecting resource usage data related to billing, but does ''not'' include any facility for recording customer billing details or actually charging customers or for transforming collected data into billing items.

Describe the relevance of the project to other OpenStack projects and the OpenStack mission to provide a ubiquitous cloud computing platform:

* Currently each production cloud deployed using OpenStack needs to re-implement it's own metering solution as OpenStack does not deliver a standard way to provide this to billing engines
* As each implements its own solution, there is
** a massive amount of effort that is being duplicated
** no standard way to collect information across OpenStack projects
** potential patches to collect unavailable information, specific to each cloud deployment, that are hard to maintain.
* What public cloud does not need to bill for its usage?
* What private cloud does not need, at least, to be able to inform its users of their use and cost?
* Access to metering information (and standardization of it) is a common requirement of cloud end users

'''Basic roadmap for the project''':

* v1 delivered with Folsom with all functions required to collect base metering info and provide standard API access
* v2 delivered with G as an incubated project with (subject to variation)
** End-User API access to own metering information
** Integration of information summary as an Horizon plugin
** New agents for other OpenStack components (Quantum Engines? Heat? etc...)
** Extension of the framework for measurements in general (see [http://etherpad.openstack.org/ceilometer-design session design notes])
* Move to core for H
* See also [[EfficientMetering/RoadMap]]

'''Location of project source code''':

* https://launchpad.net/ceilometer
* https://github.com/stackforge/ceilometer

'''Programming language, required technology dependencies''':

* Python
* Depends on openstack-common
* Agents depend on respective OpenStack project they cover

'''Is project currently open sourced? What license?''':

* Apache 2 licensed

'''Level of maturity of software and team''':

* High

'''Proposed project technical lead and qualifications''':

* Currently led by nijaba, following august's project elections
* nijaba is Canonical's Cloud Product Manager, some of his contribution can be found at https://wiki.ubuntu.com/NicolasBarcet

'''Other project developers and qualifications''':

* dhellmann works at DreamHost, is a Member of the Python Foundation and some of his work is listed at http://www.doughellmann.com/projects/index.html
* jd worked at eNovance on OpenStack, more details can be found at http://julien.danjou.info/freelance#cv (note this [http://julien.danjou.info/blog/2012/openstack-swift-consistency-analysis excellent analysis about swift eventual consistency and bottlenecks])
* dachary is eNovance's research officer, more details can be found at [http://en.wikipedia.org/wiki/Loïc_Dachary http://en.wikipedia.org/wiki/Lo%C3%AFc_Dachary]
* eglynn works at RedHat
* jaypipes & jtran works at AT&T
* spn works at Dell

'''Infrastructure requirements (testing, etc)''':

* Already integrated with gerrit and jenkins. Tests cases required for each submit.

'''Have all current contributors agreed to the OpenStack CLA?'''

* Yes

'''What is the integration status of this project with other [[OpenStack]] projects?'''
{| border="1" cellpadding="2" cellspacing="0"
| '''Project'''
| '''Status'''
|-
| Nova
| Complete
|-
| Swift
| Discussion
|-
| Keystone
| Complete
|-
| Glance
| Complete
|-
| Horizon
| Future
|-
| Cinder
| Complete
|-
| Quantum
| Complete
|}

'''Status''': To be completed by PPB

JonathanLaCour

2013-02-17T23:33:31Z

Ryan Lane: Text replace - "DreamHost" to "DreamHost"

Howdy, cloudy.

I'm Jonathan [[LaCour]], the Vice President of Software Development at DreamHost. I manage the team that makes our products tick!

UnifiedInstrumentationMetering

2013-02-17T23:33:31Z

Ryan Lane: Text replace - "DreamHost" to "DreamHost"

= Unified Instrumentation and Metering =

Last edit: -- [[SandyWalsh]]

== Overview ==

With <code><nowiki>Ceilometer</nowiki></code>, <code><nowiki>Tach</nowiki></code> and <code><nowiki>[[StackTach]]</nowiki></code>, there are some very cool initiatives going on around instrumentation and metering/monitoring within [[OpenStack]] today.

However, due to the incredible speed of development within [[OpenStack]] many of these efforts have been performed in isolation from each other. Now, we are reaching a level of maturity which demands we stop reinventing the wheel and agree upon some shared infrastructure. This need is necessary for a variety of reasons:

# We want to make it easier for new projects to build on the existing [[OpenStack]] notification message bus.
# Less code is good. We shouldn't need three different workers for extracting notifications from [[OpenStack]].
# Notifications are large and there's a lot of them. We only want to process and store that data once.
# Archiving of data is a common problem, we shouldn't need several different ways of doing it.

In this document we'll talk about the State-of-Art with respect to Instrumentation/Metering/Monitoring (IMM) with [[OpenStack]] today and where we might go with it.

Required reading / viewing:
* http://www.openstack.org/summit/san-diego-2012/openstack-summit-sessions/presentation/what-about-billing-an-introduction-to-ceilometer
* http://www.sandywalsh.com/2012/10/debugging-openstack-with-stacktach-and.html
* https://etherpad.openstack.org/grizzly-common-instrumentation (good summary of instrumentation needs)

= Instrumentation vs Metering/Monitoring =

At the very base of this discussion is having a clear understanding of the difference between Instrumentation and Metering/Monitoring.

== Instrumentation ==
Think of instrumentation as the way they test electronics in-circuit. While the device is running, probes are attached to the circuit board and measurements are taken.

[[Image:instrumentation.png]]

There are some key things to consider in this analogy:
* Every technician may want to place their probes in different locations.
* Probes might be placed for long term measuring or transient ("I wonder if ... " scenarios)
* The circuit does not have to change for the testing probes to be placed. No other groups or departments had to be involved for this instrumentation to occur.
* The same probe technology can be used on other circuit boards. Likewise, our instrumentation probe-placement technology should not just be geared towards Nova. It should also work with all other parts of [[OpenStack]].
* When the circuit changes our probe placement may have to change. We have to be aware of that.
* The probes aren't perfect. They might slip off or have a spotty connection. We're looking for trends here, identifying when things are slow or flaky.
* With respect to Python, we may be interested in stack traces as well. Not just single function timings/counts.

== Metering / Monitoring ==
Metering is watching usage of the system, usually for the purposes of Billing. Monitoring is watching the system for critical system changes, performance and accuracy, usually for things like SLA's.

Think of your power meter. You can go outside and watch the dial spin and confirm your monthly bill jives with what the meter is reporting.

[[Image:metering.png]]

The important aspects of metering and monitoring:
* These events/measurements are critical. We cannot risk dropping an event.
* We need to ensure these events are consistent between releases. Their consistency should be considered of equal importance as [[OpenStack]] API consistency.
* We have no idea how people are going to want to use these events, but we can safely assume there will be a lots of other groups interested in them. We don't want these groups talking to the production [[OpenStack]] deployments directly.
* These events may not be nearly as frequent as the instrumentation messages, but they will be a lot larger since the entire context of the message needs to be included (''which'' instance, ''which'' image, ''which'' user, etc)

= The State-of-the-Art =

So, where are we?

== Instrumentation Today ==

There is no formal instrumentation solution for [[OpenStack]] today (other than logging). Logging is insufficient because it's:
* unstructured text
* too much effort to scan, parse and correlate across servers
* requires code changes to collect new information

Rackspace has being using a cocktail of [https://github.com/ohthree/tach Tach], [https://github.com/etsy/statsd Statsd], [http://graphite.wikidot.com/ Graphite] and [http://www.nagios.org/ Nagios] to great success for close to a year.

[[Image:instrumentation_arch.gif]]

Tach is a library that collects timing/count data from anywhere in a Python program. It's not specific to [[OpenStack]], but it has pre-canned config files for the main [[OpenStack]] services. Tach hooks into a programming using monkey-patching and has a concept of Metrics and Notifiers. The Metrics are user-extensible hooks that pull data from the code. The Notifiers take the collected data and send it somewhere. Currently there are Metrics drivers for execution time and counts as well as Notifiers for Statsd, Graphite directly, print and log files. ([[SandyWalsh]] has been working on a replacement for Tach, called [https://github.com/SandyWalsh/scrutinize Scrutinize] which adds cProfile support and easier configuration. It's almost ready for prime-time.)

Tach is launched as: <code><nowiki>tach tach.conf nova-compute nova.conf</nowiki></code> ... so it easily integrates with existing deployments.

The powerful features of statsd are:
* UDP based messaging, so production is not at risk if the collectors die.
* In-memory rollup/aggregate of measurements that get relayed to Graphite. This greatly enhances scalability.
* Written in node.js = fast, fast, fast.

== Monitoring/Metering Today ==

Certainly the face of Monitoring and Metering within [[OpenStack]] today is [https://launchpad.net/ceilometer Ceilometer] ... I'll just refer you to that project for more details.

But there are others. Within Rackspace we use [https://github.com/rackspace/yagi YAGI] to consume the notifications and send them to our internal billing system. Specifically, this data is sent to [http://atomhopper.org/ AtomHopper] where it is turned into an Atom feed for other consumers (one of which is billing). YAGI used to have [https://code.google.com/p/pubsubhubbub/ PubSubHubBub] support, but that's gone dormant due to other motivators. Now, [[AtomHopper]] is the redistribution system of choice. Sadly, [[AtomHopper]] is Java-based, so it may not work well within the [[OpenStack]] ecosystem, per se. The YAGI Worker uses [https://github.com/ask/carrot/ carrot] and has been highly reliable in all of our environments, but there has been discussion of moving to [http://pypi.python.org/pypi/kombu kombu].

[[StackTach]] is a debugging/monitoring tool based on [[OpenStack]] notifications and it too has its own Worker. It is kombu-based and is currently used in production. We've had lots of problems making the stacktach worker reliable but we think the problem has been with combining a threading model with eventlet. Our new scheme uses the multiprocessing library with per-rabbit workers. This is currently being stress tested, stay tuned. We've tried a variety of other schemes and library combinations with little success (more detail if needed). Note: this ''should'' work fine since it's the same scheme Nova uses internally.

[[StackTach]] is quickly moving into Metrics, SLA and Monitoring territory with version 2 and the inclusion of Stacky (the command line interface to [[StackTach]])

[[Image:notifications.gif]]

= The Layers =

With every architecture there are different layers of abstraction/functionality.

IMM has:
* ''low-level'' components that directly interface with [[OpenStack]] via monkeypatching or notification consumption.
* ''mid-level'' components that collect, aggregate and redistribute this collected data to other consumers
* ''high-level'' components that act as the presentation layer.

We currently have overlap on all levels.

[[Image:layers.gif]]

== Unifying the Low Level ==

There is really no way to unify the instrumentation collection with the metrics collection infrastructure within [[OpenStack]]. As stated in the introduction, these are very different animals.

With respect to Monitoring and Metering (notification consumption), the obvious candidate is the notification worker. Using a list of queues in the rabbit notifier is not a solution, it's a big load on the rabbit server.

''Note: we're also using AMQP incorrectly for notifications. Events are published to an Exchange and different queues can be created for different consumers. Currently, [[OpenStack]] creates a different Exchange for each notification destination. This should simply a bug that should be fixed.''

This is the low-hanging fruit. Creating a scalable worker that can work in a multi-rabbit (multi-cell, mult-region) deployment. It should support a pluggable scheme for handling the collected data and support failover/redundancy. The worker has to be fast/reliable enough to keep the notification queue empty since this is easily the fastest growing queue (neck and neck with the cells capacity update queue :)

The worker should be a separate repository so others can use it standalone.

Also, the Ceilometer worker doesn't need to use all of the nova-common code. This is very simple program and can be handled with a single file.

== Unifying the Mid-Level ==

[[Image:architecture.gif]]

=== A Common Database for Collected Data ===

For metering and monitoring, both [[StackTach]] and Ceilometer have a database to store the notifications. [[StackTach]] uses a SQL-based database, while Ceilometer uses a key-value database (Mongo). Each notification is large and contains about ten columns that are required to have fast lookup:
* Deployment ID
* Tenant ID
* UUID
* Request ID
* Timestamp
* Instance State
* Instance Task
* Publisher
* Host ID
* Event name

Additionally the entire JSON payload should be stored for the event for consumers that need something specific.

I have no recommendation on which db to use, but perhaps some load testing should be performed to see how well each works. The important thing is, the entire event gets stored.

However, as these events get collected, there are often additional tables that need to get updated which contain aggregated/summarized information from the events. While these operations could be done in a batch fashion in a separate database it's likely more efficient to provide a means for other applications to hook into the data collection and update these tables in real-time. This is what [[StackTach]] does and it greatly reduces the post-processing required. It does, however, come at a cost of additional processing when event storage is being performed (an expensive operation). Something like Ceilometer's secondary publishing step seems a good solution here, but I think it should be based on an [[AtomHopper]]/PSHB approach vs something proprietary. We should discuss what redistribution system looks like in greater detail.

In the diagram above Ext1, Ext2, Ext3 are user-plugins for doing special aggregation work. (not for sending to the redistribution system, another plugin mechanism could handle that)

For instrumentation, as mentioned above, the statsd in-memory database is a perfect solution here. Probably not much to improve on here.

=== A Common Event Redistribution System ===

As mentioned earlier, we use [[AtomHopper]] internally (and YAGI w/PSHB previously), but it would be nice to use an off-the-shelf framework, ideally something Python-based. This too should be a separate repo and, ideally, optional.

In the DreamHost use case, The Dude should consume from the [[AtomHopper]] feed based on webhooks vs. having to poll the Ceilometer API for updates.

=== Alerts / Set Points / Thresholds ===

Personally, I don't think this belongs in the Middle Layer ... external components should define/monitor/control these.

== Unifying the Top Layer ==
Every client is different, trying to service the needs of each user with a common user interface might be tricky. [[StackTach]] started as a debugging tool and targets that audience. A Billing tool will need a very different UI.

There are lots of off-the-shelf products available for the presentation of instrumentation data, we shouldn't need to reinvent that wheel.

[[StackTach]] and Stacky should both consume from the Ceilometer API.

== Other Improvements ==

* Remove the Compute service that Ceilometer uses and integrate the existing fanout compute notifications into the data collected by the workers. There's no need for yet-another-worker. That said, I'm sure there are specific things that certain deployments will need that aren't covered by this and the existing Ceilometer collector system will still be needed.
* [[StackTach]] has taken major steps in optimizing its REST interface to facilitate caching. The data in the middle layer is largely read-only and there are far more readers than writers. The Ceilometer API should consider these improvements (if it's not dealt with already and I missed it)

People

2013-02-17T23:33:31Z

Ryan Lane: Text replace - "DreamHost" to "DreamHost"

= Translation for IRC nicknames =
Each name is linked to a bio page for that individual. Please add yourself
{| border="1" cellpadding="2" cellspacing="0"
| '''IRC Nickname'''
| '''Real Name'''
| '''Company or Role'''
|-
| _0x44
| [[_0x44|Christopher MacGown]]
| Piston Cloud Founder, Nova Core Team member, Former Ozone developer
|-
| adiantum
| [[IlyaAlekseyev]]
| Nova Developer
|-
| ameade
| Alex Meade
| Ozone Developer
|-
| amotoki
| Akihiro Motoki
| Quantum developer, NEC
|-
| andrewbogott
| [[andrewbogott|Andrew Bogott]]
| Developer, Wikimedia Foundation
|-
| annegentle
| [[AnneGentle|Anne Gentle]]
| [[OpenStack]] Technical Writer
|-
| anotherjesse
| [[JesseAndrews|Jesse Andrews]]
| [[AnsoLabs]] co-founder, Nebula chief architect
|-
| alekibango
| [[David Pravec]]
| Free and Open Source Software Specialist
|-
| armmer
| [[armmer|Jason Meridth (JM)]]
| Ozone Developer
|-
| [[ArseneRei]]
| Stephon Striplin
| Developer, DreamHost
|-
| [http://adam.younglogic.com ayoung]
| Adam Young
| Senior Software Engineer, Red Hat
|-
| cleverdevil
| [[JonathanLaCour|Jonathan LaCour]]
| Vice President, Software Development, DreamHost
|-
| bcwaldon
| Brian Waldon
| Rackspace Cloud Builders Developer
|-
| bencherian
| [[BenCherian|Ben Cherian]]
| General Manager, Emerging Technologies, DreamHost
|-
| berendt
| [[ChristianBerendt|Christian Berendt]]
| Consultant/Developer, B1 Systems
|-
| BK_man
| [[AndreyBrindeyev|Andrey Brindeyev]]
| Grid Dynamics International
|-
| blamar
| Brian Lamar
| Ozone Developer
|-
| btorch
| [[btorch|Marcelo Martins]]
| Swift System Engineer
|-
| carlp
| [[carlp|Carl Perry]]
| System Administrator, DreamHost (New Dream Network)
|-
| cerberus
| [[cerberus|Matt Dietz]]
| Ozone Developer
|-
| chemikadze
| [[NikolaySokolov|Nikolay Sokolov]]
| [[GridDynamics]] Developer
|-
| chidical
| [[chidical|Chidi Alams]]
| Systems Engineer
|-
| chmouel
| [[Chmouel|Chmouel Boudjnah]]
| Rackspace Developer
|-
| colinnich
| Colin Nicholson
| Software Developer, iomart group
|-
| comstud
| [[comstud|Chris Behrens]]
| Ozone Developer
|-
| creiht
| [[creiht|Chuck Thier]]
| Swift Developer
|-
| dabo
| [[dabo|Ed Leafe]]
| Ozone Developer
|-
| dachary
| [[dachary|Loic Dachary]]
| [http://enovance.com/ eNovance] CRO and [https://alioth.debian.org/projects/openstack/ Debian GNU/Linux packager]
|-
| davidhadas
| David Hadas
| Swift, IBM Research
|-
| danwent
| Dan Wendlandt
| Quantum developer, PTL
|-
| dendrobates
| [[RickClark|Rick Clark]]
| [[OpenStack]] Project Lead & Chief Architect
|-
| devcamcar
| [[DevinCarlen|Devin Carlen]]
| Founder of Nebula Inc, Nova Core Member, PTL Horizon, [[OpenStack]] POC
|-
| dhellmann
| [[DougHellmann|Doug Hellmann]]
| DreamHost
|-
| dtroyer
| Dean Troyer
| Rackspace Cloudbuilders
|-
| dubs
| [[CoryWright|Cory Wright]]
| Ozone Developer
|-
| DuncanT
| Duncan Thomas
| HP - Nova and Nova-volume team
|-
| eday
| [[eday|Eric Day]]
| Open Source Architect / Developer
|-
| egallen
| [[egallen|Erwan Gallen]]
| CTO, Zinux
|-
| emagana
| Edgar Magana
| Technical Lead, Cisco - CTO Cloud Computing
|-
| exlt
| [[exlt|Michael Shuler]]
| Swift Systems Engineer
|-
| garyk
| Gary Kotton
| Red Hat
|-
| gholt
| [[gholt|Greg Holt]]
| Swift Developer
|-
| glange
| [[glange|Greg Lange]]
| Swift Developer
|-
| glenc
| [[GlenCampbell|Glen Campbell]]
| Architect/Analyst
|-
| gongys
| Yong Sheng Gong
| IBM
|-
| gundlach
| [[gundlach|Michael Gundlach]]
| Ozone Developer
|-
| h1nch
| [[h1nch|John Hincher]]
| Systems Engineer
|-
| heckj
| [[JosephHeck|Joe Heck]]
| Developer / Systems Engineer
|-
| ironcamel
| Naveed Massjouni
| Ozone Developer
|-
| jaypipes
| [[jaypipes|Jay Pipes]]
| Open Source Architect / Developer
|-
| jc_smith
| [[jcsmith|Jean-Christophe "JC" Smith]]
| Architect
|-
| jeblair
| [[JamesBlair|James Blair]]
| Developer and CI Infrastructure
|-
| jk0
| [[jk0|Josh Kearney]]
| Ozone Developer
|-
| johnthetubaguy
| [[johngarbutt|John Garbutt]]
| Senior Software Developer, Citrix Systems
|-
| johnpur
| [[JohnPurrier|John Purrier]]
| [[OpenStack]]/Rackspace liaison
|-
| joshuamckenty
| [[joshuamckenty|Joshua McKenty]]
| Piston Cloud Founder, Nova Core Team member, [[OpenStack]] POC, formerly NASA Nebula Architect
|-
| koolhead17
| Atul Jha
| App Specialist, Csscorp
|-
| kpepple
| [[KenPepple|Ken Pepple]]
| Consultant / Architect / Developer
|-
| KMarsh
| Kyle Marsh
| Developer, DreamHost
|-
| [[LinuxJedi]]
| [[LinuxJedi|Andrew Hutchings]]
| Developer Infrastructure and Software Engineer, HP
|-
| littleidea
| [[littleidea|Andrew Clay Shafer]]
| Cloudscaling
|-
| letterj
| [[letterj|Jay Payne]]
| Data Catalyst
|-
| lloydde
| [[lloydde|Lloyd Dewolf]]
| Piston Cloud, Director of Customer Care
|-
| lorin1
| [[LorinHochstein|Lorin Hochstein]]
| Lead Architect, Nimbis Services
|-
| Mandell
| [[mdegerne|Mandell Degerness]]
| Piston Cloud, Systems Analyst
|-
| maoy
| [[maoy|Yun Mao]]
| AT&T Labs - Research, Researcher
|-
| markmc
| [[markmc|Mark McLoughlin]]
| Principal Software Engineer, Red Hat
|-
| [[MarkAtwood]]
| [[MarkAtwood|Mark Atwood]]
| Director - Open Source Evangelism, HP
|-
| markvoelker
| [[markvoelker|Mark Voelker]]
| Software Development Manager, Cisco
|-
| markwash
| Mark Washenberger
| Ozone Developer
|-
| matiu
| [[matiu|Matthew Sherborne]]
| Nova Dev - Rackspace
|-
| mattt
| [[mattt|Matt Thompson]]
| Systems Engineer
|-
| mattray
| [[Matt Ray]]
| Senior Technical Evangelist, Opscode
|-
| mestery
| Kyle Mestery
| Quantum developer
|-
| mikal
| [[Michael Still]]
| Canonical
|-
| mnot
| [[mnottingham|Mark Nottingham]]
| Rackspace
|-
| morellon
| [[Thiago Morello]]
| Locaweb
|-
| mtaylor
| [[MontyTaylor|Monty Taylor]]
| Developer Infrastructure and CI Manager, HP
|-
| murkk
| [[murkk|Chris Blumentritt]]
| Ozone Systems Engineer
|-
| n0ano
| [[n0ano|Don Dugger]]
| Software engineer, Intel
|-
| ncode
| [[Juliano Martinez]]
| Locaweb
|-
| ndipanov
| Nikola Đipanov
| Red Hat
|-
| notmyname
| [[notmyname|John Dickinson]]
| Swift Developer
|-
| nelson
| [[nelson|Russ Nelson]]
| Wikipedia Contractor
|-
| oubiwann
| [[oubiwann|Duncan McGreggor]]
| Cloud Engineering Manager, DreamHost
|-
| ozstacker
| [[ozstacker|Tristan Goode]]
| Australian [[OpenStack]] User Group Co-Ordinator, CEO Aptira
|-
| pandemicsyn
| [[pandemicsyn|Florian Hines]]
| Swift Engineering Monkey
|-
| patrocinio
| Eduardo Patrocinio
| IBM
|-
| pixelbeat
| [[p-draigbrady|Pádraig Brady]]
| Red Hat, Nove core team member
|-
| pknouff
| Philip Knouff
| Ozone Developer
|-
| [[PotHix]]
| Willian Molinari
| Locaweb
|-
| pvo
| [[pvo|Paul Voccio]]
| Ozone Manager
|-
| blakeyeager
| [[blakeyeager|Blake Yeager]]
| Product Manager, Rackspace Cloud
|-
| rackerhacker
| [[major|Major Hayden]]
| Systems Engineer
|-
| rainya
| Rainya Mosher
| Ozone SDLC Project Manager
|-
| Razique
| [[RaziqueMahroua|Razique Mahroua]]
| Nevrotic Openstacker and Technical Writer
|-
| rbergeron
| [[RobynBergeron|Robyn Bergeron]]
| Fedora Marketing & Cloud Person
|-
| redbo
| [[redbo|Michael Barton]]
| Swift Developer
|-
| reed
| [[StefanoMaffulli|Stefano Maffulli]]
| OpenStack Community Manager
|-
| reldan
| [[reldan|Eldar Nugaev]]
| Software Developer
|-
| russellb
| [[russellb|Russell Bryant]]
| Red Hat
|-
| salv-orlando
| [[SalvatoreOrlando|Salvatore Orlando]]
| Quantum Core Dev
|-
| sandywalsh
| [[sandywalsh|Sandy Walsh]]
| Core developer (Rackspace - Ozone)
|-
| sarob
| [[sarob|Sean Roberts]]
| Infrastructure Strategy Yahoo!
|-
| sdague
| [[sdague|Sean Dague]]
| Developer, IBM
|-
| sirp
| [[sirp|Rick Harris]]
| Ozone Developer
|-
| s0mik
| [[s0mik|Somik Behera]]
| [[OpenStack]] Quantum Founding Member, Quantum Core Developer, Product@Nicira, Former VMware Core Developer
|-
| soren
| [[soren|Soren Hansen]]
| Open Source Architect / Developer
|-
| spy
| [[ant|Antony Messerli]]
| Ozone Systems Engineer
|-
| termie
| [[termie|Andy Smith]]
| Nova Developer
|-
| thingee
| Mike Perez
| Developer, DreamHost
|-
| toanster
| Toan Nguyen
| [[OpenStack]] Software Development Manager, Rackspace
|-
| tonywolf
| [[Wolf|Tony Wolf]]
| Ozone Business Analyst
|-
| ttx
| [[ThierryCarrez|Thierry Carrez]]
| OpenStack Release Manager
|-
| tylesmit
| Tyler Smith
| Cisco Developer
|-
| vishy
| [[vishy|Vish Ishaya]]
| Nova Project Technical Lead
|-
| winston-d
| Zhiteng Huang
| Performance Engineer, Intel
|-
| wowdd1
| Zhao Dan
| Developer
|}

KMarsh

2013-02-17T23:33:26Z

Ryan Lane: Text replace - "DreamHost" to "DreamHost"

== KMarsh ==
Developer, DreamHost

Email: <<[[MailTo]](kyle.marsh AT SPAMFREE dreamhost DOT com)>>


...

----
[[Category:Homepage]]

EfficientMetering/PTLElectionProcess/DougHellmann

2013-02-17T23:33:25Z

Ryan Lane: Text replace - "DreamHost" to "DreamHost"

= Doug Hellmann =

{{https://dl.dropbox.com/u/7152077/doug-hellmann-320.jpg}}

== Personal Bio ==

Doug Hellmann is currently a Senior Cloud Developer with New Dream Network, LLC (DreamHost). He has been programming in Python since version 1.4, and has worked on a variety of Unix and non-Unix platforms for projects in fields such as mapping, medical news publishing, banking, and data center automation. Doug is a member of the Python Software Foundation, and served as its Communications Director from 2010-2012. After a year as a regular columnist for Python Magazine, he served as Editor-in-Chief from 2008-2009. Since 2007, Doug has published the popular "Python Module of the Week" series on his blog, and that material served as the basis for his 2011 book ''The Python Standard Library By Example''. He lives in Athens, Georgia.

== [[OpenStack]] Bio ==

I started contributing to [[OpenStack]] just before the Folsom summit this spring. In that time, I have contributed patches to nova, common, devstack, the unified CLI, and ceilometer. Although most of the work I have done has been on ceilometer, I also have core reviewer privileges for common and the unified CLI.

== Questions ==

1. '''Since the last elections, what areas have you focused on and what contributions have you made in order to improve your project?'''

Ceilometer is a new project, begun after the Folsom summit. I have been involved at every stage, from requirements gathering, to design, to the ongoing implementation.

Outside of ceilometer I have been working on the new unified command line project. I created the library cliff, which is serving as the basis for creating new command plugins to be run through the common main program.

I contributed some documentation patches to nova, as well as some enhancements to the RPC API based on requirements from ceilometer.

I have done a lot of code reviews for openstack-common, and want to continue finding parts of all of the [[OpenStack]] components that can be reused.

2. '''What are the most pressing/important issues facing your project?'''

We have been taking a "tracer bullet" approach to implement ceilometer, and are almost at the point where metering data flows end-to-end. Building an API server to query the data store is the last step to having a complete data path. After we have the API server, or possibly even while we are building it, we should work on more developer-oriented documentation so we can increase the size of the team able to build plugins and agents for collecting data and saving it to other databases. That work will involve collaborating with the other [[OpenStack]] projects, and we have already begun approaching them to discuss integration in general terms. We also need to develop some integration testing plans and create installation and administration documentation for end-users.

3. '''What is your relationship to [[OpenStack]] & why is its success important to you and/or your company?'''

I am a developer at DreamHost, an [[OpenStack]] Foundation Gold Level founding member. We are using [[OpenStack]] to build a public cloud offering as the next phase of our evolution as a hosting company.

== Links ==

* DreamHost: http://www.dreamhost.com
* blog: http://blog.doughellmann.com
* Twitter: @doughellmann

OpenStackUsersGroup/EssexGlobalHackIn

2013-02-17T23:33:24Z

Ryan Lane: Text replace - "DreamHost" to "DreamHost"

= Essex [[OpenStack]] Global Hack-In =
Facilator: Lloyd Dewolf of Piston Cloud Computing, lloydostack@gmail.com , and Tristan Goode of Aptira.

Essex is a release focused on improving the integrity of [[OpenStack]], so our first Global Hack-In is right at the start of the [[EssexReleaseSchedule|release candidate cycle]], the '''start of March''', 2012. The event is focused on testing and getting familiar with the release and exploring areas outside of your expertise.

Collaborators will be working on resolving high priority bugs, and exploring, reviewing and testing [[OpenStack]] Essex.

Activities might include:

* Bug Triage
* Patch Review
* Peer Code Review
* Ad-hoc Testing of use cases
* Test Automation

== Global ==
This will be a loosely coupled, highly cohesive global event ;-)

There will be a dedicated #openstack-event IRC channel on Freenode.

Each event will be organized and ran by the local development user communities in the manner that best suits the local communities. Although, overlapping the timing of the events is desirable, more important is that the timing of the events serve the locals.

== Running an Event ==
Hosting organizations should expect 15-40 contributors to work at the host's office collaborate on resolving high priority bugs, and exploring, reviewing and testing [[OpenStack]] Essex.

The host team should be made up of a site facilitator and a technical host.

* The '''site facilitator''' is responsible for making sure the doors are open (security notified), the lights are on, the temperature is comfortable, washrooms are decent, and there is food and drink.
* The '''technical host''' at a minimum someone who is familiar with [http://devstack.org/ devstack] and has submitted a valid bug report to [[OpenStack]], so they can at least organize people's exploration and testing around the area they've investigated before.
* Many hands make light work. It's a great idea to have a backup, and collaborators.

== Planned Events ==
{| border="1" cellpadding="2" cellspacing="0"
|< >|UTC
| Duration (hours)
| Location
| URL
| Local Time
| Site Facilitator
|-
| 23:00, Feb 28
| 4
| Gold Coast, Australia
| [http://www.meetup.com/gctechspace/events/53379082/ http://www.meetup.com/gctechspace/events/53379082/]
| 9:00
| Lucas Brandt of Gold Coast Techspace
|-
| 6:00, March 1
| 4
| Sydney, Australia
| [http://aosug.openstack.org.au/ http://aosug.openstack.org.au]
| 17:00
| Peter Millar
|-
| 6:00, March 1
| 4
| Melbourne, Australia
| [http://aosug.openstack.org.au/ http://aosug.openstack.org.au]
| 17:00
| Martin Paulo
|-
| 15:00, March 1
| 5
| Madrid, Spain
| [[spain-openstack-user-group [AT] googlegroups.com]]
| 16:00 CET
| [[StackOps]]
|-
| 15:00, March 1
| 8
| Atlanta, GA, USA
| [http://www.meetup.com/openstack-atlanta/events/54250222/ Meetup info]
| 10:00 EST
| Duncan [[McGreggor]] of DreamHost
|-
| 16:00, March 1
| 9
| Fort Collins, CO, USA
| [http://www.meetup.com/OpenStack-Colorado/events/53636912/ Colorado OpenStack Global Hack In]
| 09:00 MDT
| Canonical (David Medberry)
|-
| 19:00
| 6
| 3751 Arias st, 7th floor, Capital Federal, Buenos Aires, Argentina
| http://groups.google.com/group/openstack-argentina/browse_thread/thread/6230f9f345a01587?hl=es
| 14:00-20:00
| Leandro Reox of [[MercadoLibre]]
|-
| 19:00
| 6
| San Francisco, USA
| http://www.meetup.com/openstack/events/52682022/
| 11:00-17:00
| Dallas Kashuba of DreamHost
|-
| 19:00
| 6
| Silicon Valley, USA
| http://www.meetup.com/openstack/events/52682572/
| 11:00-17:00
| Sean Roberts of Yahoo
|-
| 6:00, March 2
| 4
| Mirantis Offices: Moscow, Russia; Saratov Russia
| [https://www.facebook.com/notes/mirantis-it/openstack-global-hack-in/332528836782841 Announce on Facebook]
| 10:00am MSK (UTC+4)
| Oleg Gelbukh of Mirantis
|-
| 15:00, March 8
| 6
| Burlington, MA
| [http://www.meetup.com/Openstack-Boston/events/53635802/ Meetup info]
| 10:00am EST
| Andi Abes@Dell

Nzweep

2013-02-17T23:33:21Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

== Nick van der Zweep ==

== Personal Bio ==

I work for Cloud Cruiser as VP of Products and Strategy. Cloud Cruiser provides a cost analytics platform that allows enterprises to control, analyze and optimize their costs to achieve the low cost promise of the cloud

== Links ==

* LinkedIn: http://www.linkedin.com/in/nickvanderzweep

Sc360

2013-02-17T23:33:21Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

== Sergios Charalambous ==
'''Name: '''Sergios Charalambous

'''Nationality:''' Cypriot

'''Email:''' sc360@kent.ac.uk or scharala@cisco.com

LinkedIn: http://www.linkedin.com/profile/view?id=77521617&trk=tab_pro

I currently work for Cisco as a part time remote worker and also study Information Technology in University of Kent. I will graduate in May 2013.

'''Goals:'''

* Contribute to [[OpenStack]].
* Create a community for [[OpenStack]] in Cyprus

----
[[Category:Homepage]]

Lloydostack

2013-02-17T23:33:12Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

== lloydostack ==

Name: Lloyd Dewolf

Launchpad: https://launchpad.net/~lloydde

Contributions: [http://www.meetup.com/openstack/ SF Bay OpenStack meetup co-organizer], excellent bug reporter

=== Job ===

Company: [http://www.pistoncloud.com/ Piston Cloud Computing]

Title: Director of Customer Care

LinkedIn: http://www.linkedin.com/in/lloydde

Email: lloydostack@gmail.com

=== Wiki Edits of Interest ===

[[Training]]

----
[[Category:Homepage]]

Russellb

2013-02-17T23:33:10Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

== Russell Bryant ==

Email: <<[[MailTo]](rbryant AT SPAMFREE redhat DOT com)>>

Twitter: [http://www.twitter.com/russellbryant @russellbryant]

LinkedIn: [http://www.linkedin.com/in/russellbryant Russell Bryant]

Sergios Charalambous

2013-02-17T23:33:10Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

== Sergios Charalambous ==
Name: Sergios Charalambous

Nationality: Cypriot

Email: sc360@kent.ac.uk or scharala@cisco.com

LinkedIn: http://www.linkedin.com/profile/view?id=77521617&trk=tab_pro

I currently work for Cisco as a part time remote worker and also study Information Technology in University of Kent. I will graduate in May 2013.

Goals:

Contribute to [[OpenStack]].

Create a community for [[OpenStack]] in Cyprus

...

----
[[Category:Homepage]]

EfficientMetering/PTLElectionProcess/NickBarcet

2013-02-17T23:33:08Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

= Nick Barcet =

{{https://lh3.googleusercontent.com/-qMK3DsDmIfw/AAAAAAAAAAI/AAAAAAAAAIw/gZ0kwQ3Xc0w/s48-c-k/photo.jpg}}

a.k.a: Nicolas, nijaba

== Personal Bio ==
I'm a Free Software and Culture Evangelist, Consultant, Product Manager, and sometime hacker for the last 12 years. I contribute some resources to free software groups, such as [http://www.april.org/ APRIL (french FSF)], [http://www.laquadrature.net/ La Quadrature du Net] and am a Director of the [http://www.opencloudinitiative.org/ Open Cloud Initiative].

I work for Canonical as Ubuntu Cloud Product Manager and am more specifically in charge of Canonical's and Ubuntu's work around [[OpenStack]]. See details on [https://wiki.ubuntu.com/NicolasBarcet my work on Ubuntu here].

== [[OpenStack]] Bio ==

Soren, Thierry, Rick and I started thinking about what it would take to make great Cloud IaaS in 2009, and it's been great to see this vision come to life. I've been involved in [[OpenStack]] since it's very beginning (July 2010 summit in Austin) and have contributed to translation, architecture discussions and evangelism of [[OpenStack]] since then.

== Questions ==

1. '''What areas have you focused on and what contributions have you made in order to improve Ceilometer?'''

I've been collecting requirements, assembling a first architecture proposal, presented the project at the last summit and co-lead the project until now.

2. '''What are the most pressing/important issues facing Ceilometer?'''

Now that we have laid a sound architecture for the projects, we need to:
* finish the instrumentation of all core [[OpenStack]] project
* Implement the API
* Document deployment and options
so that distributions can start packaging it and people start using it.

3. '''What is your relationship to [[OpenStack]] & why is its success important to you?'''

As an individual, [[OpenStack]] represents the coming to life of a dream started a few years ago, as well as the fastest growing [[OpenSource]] project I have seen.

As a professional, its is my job to ensure that [[OpenStack]] meets the requirements of our users, and I am working hard on this!

== Links ==

* Website: http://nicolas.barcet.com
* LinkedIn: http://www.linkedin.com/in/nbarcet
* Twitter: [http://twitter.com/nijaba @nijaba]

2010 CommunityData

2013-02-17T23:33:08Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

= 2010 Community Data =
Two files are available containing the raw data:

* [[attachment:2010 Data Tracking (OpenOffice)]]
* [[attachment:2010 Data Tracking (Excel)]]

Data being tracked:

* Twitter
** #openstack Tweets and Re-tweets
** openstack Tweets
* Bugs
** New, Open, In-Process, Critical, High Importance, Patched
* Blueprint
** Total, Essential, High, Medium, Low, Undefined
* Website (Openstack.org)
** Visits, Pageviews, New Visits %
** #1 Page, #2 Page, #3 Page, #4 Page, #5 Page (% total hits)
* Mailing Lists (openstack-lists.org) [Membership Numbers]
** Announce, [[AdvisoryBoard]], Operators, Partner, Event, Puppet, Chef, Marketing
* Social Networks [Membership Numbers[
** Facebook Openstack, LinkedIn Openstack, Ohloh.net Swift, Ohloh.net NOVA

== Graphs ==

Tracked data is graphed over time to show trends, etc. For those of you with Excel access, the Data Tracking file in Excel contains all the graphs. For those of you using [[OpenOffice]], please review the pdf file below showing the latest graphs.

* [[attachment:2010 Data Graphs (pdf)]]

Governance/Foundation/EDCandidateCommittee

2013-02-17T23:33:06Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

= Executive Director Candidate Committee =
== Concluding Recommendation; Letter to members and contributors ==
July 30, 2012

Dear [[OpenStack]] members and contributors,

One of the first important tasks for the [[OpenStack]] Foundation Board of Directors, once elected, is to appoint the first Executive Director of the Foundation. The Executive Director will act as Chief Executive Officer of the Foundation and shall, subject to the direction of the Board of Directors, have general supervision, direction and control of the business and the officers of the Foundation.

In anticipation of the Foundation being formed and the Board being appointed and elected, and in order to smooth the transition to operating as a Foundation, the 19 companies who publicly committed to be Platinum and Gold members formed a committee in May 2012 to conduct a process to define a job description, invite applications, interview candidates, and select a candidate to recommend to the Board (once formed) for the Executive Director role.

After a diligent and inclusive process by the committee, which included preparing and posting a comprehensive job description, receiving and reviewing over 40 applications, and panel style interviews of 5 short-listed candidates, the Executive Director search committee has recommended Jonathan Bryce for the Executive Director position.

The recommendation of Jonathan Bryce as Executive Director will be considered at the first meeting of the Board of the Foundation, anticipated to be held on August 28th, 2012 after the completion of Board member appointments and elections. The process the committee developed and used to arrive at its recommendation is outlined on this wiki page. The job description containing a complete listing of the job criteria and detailed job responsibilities is also contained within this wiki page.

Sincerely,

Committee Members

* Alan Clark (chair)
* Boris Renski
* Brian Stevens
* Cliff Young
* Eileen Evans
* Ewan Mellor
* Jim Curry
* Jon Mittelhauser
* Sean Roberts
* Simon Anderson
* Tim Bell
* Todd Moore
* Tristan Goode
* Winston Damarillo

----
== Background and Process ==
Based on action items resulting from the May 9th F2F a Executive Director Candidate committee is being formed to formulate the criteria, to vet possible candidates for the role and to provide a recommendation to the Foundation board. The efforts of the committee will result in ensuring that all are on the same page with the roles, responsibilities, priorities and goals for the ED. Writing these down will be a very good thing for the ED and for the members. While it is the responsibility of the Board to place the ED, this committee can in the interim go through the steps enabling the Board to immediately act. Also having the persons on the committee, who will potentially be the board helps assure that the board will adopt the committees results and recommendations.

The committee members are:

* Alan Clark (chair)
* Boris Renski
* Brian Stevens
* Cliff Young
* Eileen Evans
* Ewan Mellor
* Jim Curry
* Cole Crawford replaced by Jon Mittelhauser
* Sean Roberts
* Simon Anderson
* Tim Bell
* Todd Moore
* Tristan Goode
* Winston Damarillo
* Lauren Sell (For communications)

The output of this committee effort is a candidate recommendation to the board for approval along with a recommendation for the first year incentive goals.

All work will be posted and updated on this wiki page.

The following is the Committee's steps/schedule that align with the Drafting Committees time line.
{| border="1" cellpadding="2" cellspacing="0"
|-
| May 23-30
|-
| May 30
|-
| June 6
|-
| June 11
|-
| June 14
|-
| June 22
|-
| June 27
|-
| July 9 - 13
|-
| July 18
|-
| August 28
|}

----
== Job Description and Candidate Criteria ==
The

[[OpenStackFoundation]] is an independent body being established to provide shared resources to help achieve the

[[OpenStackMission]] of Protecting, Empowering, and Promoting

[[OpenStacksoftware]] and the community around it, including users, developers and the entire ecosystem.

Community wide goals the Foundation will help achieve are:

* Make [[OpenStack]] a ubiquitous cloud operating system
* Deliver high quality software releases that companies can rely on to run their business
* Ensure interoperability among [[OpenStack]] clouds
* Nurture a healthy community, with broad participation and a sharp focus on the [[OpenStack]] Mission
* Grow the ecosystem around [[OpenStack]] to strengthen the platform and provide opportunity
* Build and protect the [[OpenStack]] brand to the benefit of the community's participants
* Ensure that the [[OpenStack]] community is excited about the [[OpenStack]] vision and future direction

=== THE EXECUTIVE DIRECTOR ROLE ===
The Executive Director will have a very high profile role in the open source software community, the cloud computing industry, and the software industry generally. The [[OpenStack]] Foundation will be one of the highest profile emerging open source software Foundations in the world, and the Executive Director will have a unique opportunity to facilitate the growth of a global community, together building the next big platform in cloud computing.

The day-to-day operations of the Foundation will be overseen by the Executive Director, who will report to the Board of Directors of the Foundation, and who may hire staff as needed to meet the goals of the Foundation. Employed and non-employed personnel may be used to carry out the work of the Foundation. The employed staff is expected to be a small, focused team tasked with coordinating resources from the larger community in an independent way (e.g. community management, marketing and event management, ensuring access to common infrastructure).

Employed staff will report direct to the Executive Director. It is anticipated that employed staff may be distributed around the US and world.

Non-employed personnel may still occupy official offices without being on the payroll. Even though they may be employed by a participating company, Gold Member, or Platinum Member, they should attempt to act in the best interests of [[OpenStack]] as a whole when performing their duties. Additional outside professionals, such as an independent attorney, may also be used as needed. Where possible, the Foundation also enables self-service and broad access to community resources and assets.

=== AUTHORITY ===
The Executive Director is ultimately responsible for the overall management of the Foundation and all aspects of the Foundation’s operations. By the authority delegated by the Board of Directors, the Executive Director will have full discretionary power to execute the by-laws, policies, and directives of the Board of Directors of the Foundation.

The formation documents of the Foundation are being developed alongside the search process for an Executive Director, and candidates will be kept informed of the by-laws and organization structure of the Foundation as it gets finalized, including sections specifying the Executive Director’s authority.

=== RESPONSIBILITIES ===
The Executive Director has overall responsibility to ensure that the Mission and objectives of the Foundation are clearly defined and broadly understood, and that Foundation activities are directed towards the successful achievement of stated goals & objectives. The Executive Director reports to the Board of Directors and has primary responsibilities of supervision of Foundation programs and Foundation employees and setting the overall tone and vision for the Foundation.

As Project Director, the Executive Director has the day-to-day responsibility of managing the Foundation. The Executive assumes the overall leadership role in guiding all strategy, administrative, fiscal, and community-oriented program activities as delineated by the policies adopted by the Board of Directors and the Technical Committee. The Executive Director will be responsible for the following specific areas of the Foundation:

Promotion of the [[OpenStack]] Mission

Co-ordination of and Collaboration between the Board of Directors, and between key member groups and individuals

Program Planning, Development, and Evaluation

Fiscal Management

Environment

People

Confidential Records and Files

Reports

Other Duties as Assigned

=== RESPONSIBILITIES: A. Planning, Development, And Implementation ===
It is the Executive Director's responsibility to plan and develop programs as funded by the members and approved by the Board of Directors. The main planning, development, and implementation functions include:

# Planning and executing promotion and partnering activities to ensure that [[OpenStack]] becomes the leading cloud platform adopted by enterprise and service providers worldwide.
# Community development activities to ensure a robust and broad community participation and contribution to [[OpenStack]].
# Public relations, including all requests for technical assistance.
# Cooperation with the organizations in development of a course of the organizational objectives.
# Development of agreements with companies and participating partners.
# Working closely with the appropriate funding sources to ensure the long term viability of the Foundation.
# Preparing grants and contracts for initial or continued funding for approval by the Board.
# Developing and implementing evaluations of program goals, and objectives.
# Developing goals and objectives for consideration by the Board.
# Provide Board with updated program and mission changes. Further implementation and guidance of the Executive Director's duties and responsibilities will be found in the by-laws of the corporation.

=== RESPONSIBILITIES: B. Fiscal Management ===
The Executive Director shall assist, advise, and act for the Board of Directors in the following:

# Develop an annual budget for review and approval by the Board; ensure that expenditures are within the budgeted amounts; and prepare budget revisions as needed through the year.
# Establish and maintain a fudiciary responsibility including cash management & accounting policies set forth and approved by the Foundation Board of Directors.
# Authorize purchase orders, vouchers, and payments within parameters set in the by-laws.
# Maintain an inventory of the Foundation’s property and protect all such property.
# Administer contracts as approved by the Board.
# Manage an annual audit of the Foundations books & records.

=== RESPONSIBILITIES: C. Environment ===
The Executive Director is responsible for ensuring the following environmental standards are met:

# Establishment of an environment that enhances the positive self-image of the staff and preserves human dignity.
# Equipping and maintaining an environment that ensures the health and safety of staff.
# Ensuring documentation of planned programs consistent at all times with the needs of members for Foundation promotion activities. .

=== RESPONSIBILITIES: D. People ===
The Executive Director shall is authorized to transact all people actions subject to the Personnel Policies and Procedures (Personnel Manual), and to report such actions as necessary to the Board. The Executive Director is responsible for:

# Recruitment, hiring, staffing, and supervision of personnel.
# Being available for counseling of staff.
# Ensuring that performance evaluations of all staff are completed according to the Personnel Manual.
# Determining the need for travel and training of all employees, and approval or denial of staff travel and training requests consistent with the travel and training budget approved by the Board.
# Promotion, demotion, disciplinary action, and exit interviews, in accordance with the Personnel Manual.
# Annual review and update of Personnel Manual and all job descriptions for Board consideration.

=== RESPONSIBILITIES: E. Confidential Records and Files ===
All records, reports, and other materials relating to shall be kept in a locked file under the direction of the Executive Director. The responsibility for keeping accurate and complete records as prescribed by law.

=== RESPONSIBILITIES: F. Reports ===
The Executive Director is responsible for all reports required by members or the Board of Directors. Such reports include, but are not limited to, the following:

# Monthly narrative (Executive Director's Report)
# Monthly statistical reports
# Quarterly progress evaluation
# Minutes of all staff meetings
# Quality assurance reports
# Copies of all state, federal, and local inspection reports

=== RESPONSIBILITIES: G. Other Duties as Assigned ===
The Executive Director shall perform other duties as prescribed by the Board of Directors.

=== DELEGATION OF AUTHORITY ===
The Executive Director may delegate duties, responsibilities, and authority to carry out functions within the parameters of the Personnel Manual.

=== TERMS OF EMPLOYMENT ===
* Exempt, professional management position; work hours flexible, depending on the needs of the job.
* 50%+ travel anticipated.
* Foundation’s Employee Handbook takes effect on date of hire.
* Salary: dependent on experience and education.

=== QUALIFICATIONS / SELECTION CRITERIA: ===
# Working knowledge of [[OpenStack]] and the [[OpenStack]] community preferred.
# Strong domain knowledge in cloud platforms and architectures.
# MBA/MPA or Bachelor’s degree in Business or Public Administration, and/or Bachelor’s and/or Master’s degree in Computer Science preferred.
# Experience in administration of voluntee or non-profit organizations, with open source software experience preferred.
# Candidates will demonstrate strong skills in fiscal management, resource development and maintenance, organizational and program planning, and public relations.
# Previous experience working with volunteers and knowledge and understanding of technology.
# Track record of effectively leading an international scale organization composed of community volunteers, corporate sponsors, institutional affiliations and industry associations with proven success in developing and influencing collaborative relationships.
# Demonstrated ability to earn the trust and respect of diverse groups of people.
# Excellent sense of professionalism, judgment and diplomacy to manage situations and determine appropriate course of action.
# Past success working with a Board of Directors with the ability to cultivate existing board member relationships.
# Excellence in organizational management with the ability to coach staff, manage and develop high-performance teams, set and achieve strategic objectives, and manage a budget.
# Strong written and verbal communication skills: a persuasive and passionate communicator with excellent interpersonal and multidisciplinary project skills.
# Strong marketing, public relations, and fundraising experience with the ability to engage a wide range of stakeholders and cultures.

==== A pdf and .doc copy of the posted Executive Director candidate criteria and job description: Executive_Director_OpenStack_Job_Description_Draft_06_11_2012.[pdf ====
----
== [[OpenStack]] Foundation Executive Director Candidate Sourcing Process ==
To ensure that the process be as transparant and fair as possible for all candidates and members, the committee developed and adopted the following process for discovering and interviewing candidates

1. Objective:

The objective of this document is to outline the process to be followed by the members of the [[OpenStack]] Foundation executive committee to source and pre-selecting the candidates for the executive director role. Depending on the number of credible candidates available for the position, the process may need to be calibrated on the ongoing basis. The end goal of the process is to identify several candidates for the executive director and present the candidates to the foundation board. It is understood by all members of the committee that, once formed, the foundation board will be responsible for making the final appointment of the executive director.

2. Responsible Party:

Executive committee members acknowledge the necessity of identifying a single, responsible party to drive the sourcing process, while keeping it transparent all members of the committee. It is agreed that Alan Clark will be responsible for organizing and executing the sourcing process. The rest of the committee members will observe and participate during certain stages.

3. Sourcing Process Steps:

Executive director sourcing process will consist of the following steps:

* Producing a job description
* Sourcing a pool of resumes
* Selecting the candidates for a phone screening
* Committee recommendation
* Board Review & Approval

4. Producing a job description:

In producing the description, committee members have researched job descriptions for comparable positions in other non-profit organizations with a mandate that is similar to the [[OpenStack]] foundation. Committee members have also considered the mission of the [[OpenStack]] foundation, as well as, discussions pertaining to executive director role that took place during earlier gold and platinum member meetings. Taking into the account all of above, executive committee members have collaboratively produced a job description by engaging in a series of open discussions conducted over the phone.

5. Sourcing Resumes:

It is agreed that Alan Clark will source the resumes by advertising the agreed upon job description in a number of places, such as LinkedIn.com, [[CareerBuilder]].com and www.openstack.org/jobs. If the initial postings do not provide the calibar of candidates desired by the committee, Lloyd Wendt of Idetecht Solutions will be engaged to recruit for the position. Lloyd has reviewed the job description and has confirmed that he is willing to personally handle the assignment for a flat fee. The committee determined some sense of confidentiality and personal contact needs to be conveyed to the Candidates. We will therefore limit the initial exposure of the candidate information to the committee members. Candidates will submit their resumes to Alanclark@openstack.org Alan Clark is responsible for aggregating all resumes in a single place, accessible to all committee members. As the resume sourcing process continues, Alan will update all committee members on a regular basis (at least once a week) with respect to the status of the sourcing process i.e. places the position is being advertised, resume flow, any emerging issues/ considerations etc. Resume sourcing process will go on until committee members have come to an agreement that there are enough credible candidates available or until the executive director has been recruited by the board.

6. Selecting Candidates for Phone Interviews:

Initiation of the phone screenings does not imply that the process of sourcing the candidate resumes should stop. Sourcing and screening will proceed in parallel. Once some number of credible executive director candidates has been established, Alan Clark will initiate the process of identifying the candidates to be screened by phone. Executive committee members will convene via [[WebEx]] / phone conference to openly discuss the candidates and agree on those to be screened. More than one meeting may be necessary; follow-on email discussion may also be warranted. It is expected that committee members will unanimously agree on which resumes are worthy of the phone screening through this open discussion. If disagreements happen to arise, executive committee members will conduct a formal vote. The exact structure of the voting process may vary, depending on the final number and quality of the candidates being considered. Therefore, it will be agreed upon by the committee members when there is more clarity on this matter.

7. Conducting Phone Screenings Prior to conducting the screenings:

Alan Clark will put together a list of standard screening questions to be asked of the candidates. Alan will circulate the list of questions among all committee members and will give sufficient opportunity for comments and suggestions. If required, a phone discussion between committee may be organized by Alan to finalize the list of questions. Alan Clark will negotiate the screening times with the candidates and announce the time to all committee members. Committee member participation in the screenings is highly encouraged, but is optional. It is expected that the screenings will be conducted via [[WebEx]] or phone conference. The screening sessions will be recorded and made available by Alan Clark for all committee members to review offline. During the screening sessions, it is expected that Alan Clark will lead the interview with the agreed upon script of questions while all other participating committee members will listen on mute. Candidates will be explicitly notified about being recorded for offline review purposes. Upon Alan completing the scripted questions part of the interview, the screening will be open to all committee members for a period of 15-20 minutes.

8. Committee Recommendation

Upon completion of the phone interviews, Alan Clark will request of all committee members to provide their opinion (in private via email) regarding the best candidates and a runner up candidate. Having received and aggregated the information, Alan will publicly share the aggregated results of the opinions of committee members without openly revealing the details of individual votes and comments. The committee will convene in person at OSCON to openly discuss the aggregate results. It is assumed that the agreement regarding the top candidate will be easy to achieve. However, should any disagreements arise, a formal voting process will be put in place by the executive committee and executed upon at the said meeting. Those, unwilling to go public about their initial recommendation have the right to abstain from voting. As a result of the meeting at OSCON ED sourcing committee produce a recommendation for the top candidate. The recommendation will be drafted by Alan and ratified by ED sourcing committee members.

9. Board Review and Approval

All materials produced as the results of the steps described above, including the job description, candidate resumes, recordings of the candidate interviews and ED Sourcing recommendation will be packaged and passed on to the board members (once the board is formed). The board will then scrutinize the materials and will make the final decision on candidate hire. As always, it is expected that the board will be able to easily come to a unanimous decision. However, should disagreements arise among board members, a formal voting process will be instituted by the board.

CommunityMetrics

2013-02-17T23:33:05Z

Ryan Lane: Text replace - "LinkedIn" to "LinkedIn"

= Measuring [[OpenStack]] Developers Community =
We want to measure ''engagement'' of [[OpenStack]]'s developers and users in the community.

== What is engagement? ==
* Community engagement is the degree to which an individual is active with other individuals and groups around particular community events and issues. In [[OpenStack]] case, the engagement we want to measure is the level of activity of each participant (developer or user) with other developers/users/groups around code development, bug reporting/triaging/fixing and blueprints, documentation and general ''socialization''.We want to measure facts in each of those areas and define dimensions for each of these facts. Facts and dimensions will go in a datawarehouse on top of which there will be reports to dissect and analyze data.Questions we want to ask to the system * What actions are being taken by members, where is activity happening?
* How to differentiate between developers and code deployers and cloud integrators? Segmentation of "who's who?"
* Can we find our community on a particular platform such as LinkedIn or Twitter?
* How influential is a particular person?
* If a community member blogs, are they answering questions on certain channels?
* for docs: is the doc useful, did you find the info you were looking for?
* for code: did you find the code, was it easy/hard to contribute?
* for social interaction: did you find your answer? was the answer you gave useful?
* for developers: understand the use cases
* Multichannel integration: is this guy on twitter the same as the blogger the same as the mlist

=== Socialization ===
Socialization in this case is about all activities to support other people in the community, users or new developers. One proxy to measure this fact is participation of developers to mailing lists, chats and forums.

==== Facts to track ====
(does it make sense to put the channel as one dimension or is it better to track messages to the different lists, irc, etc as different facts?

* Message

=== Code development ===
==== Facts to track ====
* [[CommunityMetrics/Code|Commits]]
* [[CommunityMetrics/Reviews|Code Reviews]]

More details on

=== Issue tracking + blueprints ===
[Use http://sourceforge.net/projects/qareports/ as foundation to build upon?]

==== Facts to track: ====
* Issues and Issue changes, ''Blueprints and Blueprint changes''

<u>Issues measures</u> * Issues: Number of Issues (the total of which should match the number of bugs managed by your Issue tracking system)
* Days Since Creation: The number of days from the Time Created to the most recent change. Note: this is NOT calculated using the current date when running the report. The logical defintion is “Most Recent Time Changed - Date” “Time Created”

<u>Issue Changes measures</u> * Changes: The number of “Issue Changes.” This the total number of times an Issue was “changed”
* Actual Issues: Number of actual Issues (think “distinct count on actual issue Ids”). If an Issue was changed multiple time at the intersection point it will only count ONCE in this number.
* Opened: Indicates how many Changes were from a Should Count Net Open = false state (Closed, Resolved) to a Should Count Net Open = true state (Reopened, In Progress). This will “increment” the Net Open value by one.
* Resolved:Indicates how many Changes were from a Should Count Net Open = true state to a Should Count Net Open = false state. This will “decrement” the Net Open value by one.
* Net Open: The aggregated balance of opened and resolved values to determine the “net.” If “Opened” = 10, and “Closed” = 15, Net Open = 5. If Opened = 5 and Closed = 0, then Net Open = 5.
* Starting Net Open:The “running” balance at the beginning of this Time period. If the report is at the Month level, this will be the “Net Open” balance at “balance” at the beginning of the month. Note: Uses “Time Changed” for determining starting and ending periods.
* Ending Net Open:Starting Net Open + Net Open. If the balance at the beginning of the year was 100, and Net Open is 5, then the Ending Net Open = 95. Note: Uses “Time Changed” for determining starting and ending periods.
* Days Since Creation: The number of days from Time Created to Time Changed. The number days “into the issue” this change occurred.
* Elapsed Days: The number of days since the last Issue Change for this Issue. This is useful for calculating total number of issue days spent in statuses, assigned to particular persons, etc.
* Net Open: The aggregated balance of opened and resolved values to determine the “net.” If “Opened” = 10, and “Closed” = 15, Net Open = 5. If Opened = 5 and Closed = 0, then Net Open = 5.
* Starting Net Open:The “running” balance at the beginning of this Time period. If the report is at the Month level, this will be the “Net Open” balance at “balance” at the beginning of the month. Note: Uses “Time Changed” for determining starting and ending periods.
* Ending Net Open:Starting Net Open + Net Open. If the balance at the beginning of the year was 100, and Net Open is 5, then the Ending Net Open = 95. Note: Uses “Time Changed” for determining starting and ending periods.
* Days Since Creation: The number of days from Time Created to Time Changed. The number days “into the issue” this change occurred.
* Elapsed Days: The number of days since the last Issue Change for this Issue. This is useful for calculating total number of issue days spent in statuses, assigned to particular persons, etc.

=== Documentation ===
[We should treat this as code and track similar things]

==== Facts to track: ====
* Edit (similar concept as patch for code)