https://wiki.openstack.org/w/api.php?action=feedcontributions&user=Jesse+Noller&feedformat=atomOpenStack - User contributions [en]2024-03-29T10:39:28ZUser contributionsMediaWiki 1.28.2https://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=42853Meetings/PythonOpenStackSDK2014-02-20T18:07:59Z<p>Jesse Noller: /* Weekly Python-OpenStackSDK Team Meeting */</p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in [[PythonOpenStackSDK]], we will be holding public meetings weekly in on freenode in #openstack-meeting-3 at 19:00 UTC Please feel free to add items to the agenda below with your name and we'll cover them. The meeting will last 1 hour.<br />
<br />
<br />
== Agenda for 2014-03-02 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Current public API designs & interfaces<br />
* Internal HTTP client architecture<br />
* State of blueprints<br />
* PTL<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=42852Meetings/PythonOpenStackSDK2014-02-20T18:07:41Z<p>Jesse Noller: /* Weekly Python-OpenStackSDK Team Meeting */</p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in [[PythonOpenStackSDK]], we will be holding public meetings weekly in on freenode in #openstack-meeting-3 at 19:00 UTC Please feel free to add items to the agenda below with your name and we'll cover them. The meeting will last 1 hour.<br />
<br />
if you would like to attend, please fill out the doodle: http://doodle.com/qe6v2ssr28x8urqe<br />
<br />
<br />
== Agenda for 2014-03-02 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Current public API designs & interfaces<br />
* Internal HTTP client architecture<br />
* State of blueprints<br />
* PTL<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=41924SDK-Development/PythonOpenStackSDK2014-02-11T20:29:17Z<p>Jesse Noller: /* IRC */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances, it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The python-openstacksdk project proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation, it becomes very easy to derive a unified CLI, such as openstackclient, or specialized per-service CLI tools. However, it is important that the definition of SDK -- the compilation of the APIs and developer functions -- and CLI tools stay separate as it is easy to conflate the idea of "clients," which is the state we have today. <br />
<br />
Once the initial work to create the python-openstacksdk is complete; the next stage would be to collapse the individual python-* clients and use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
'''What's in an SDK?''':<br />
<br />
An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:<br />
* Documentation aimed at users consuming the SDK and system.<br />
* Clear examples of usage, including functioning, executable examples.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators or Developers. These are developers looking to '''consume''' a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds. The commands they use should follow a consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/stackforge/python-openstacksdk<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints || https://launchpad.net/unifiedsdk<br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* Verified mocks/stubs for testing at all layers.<br />
* python-requests based REST client (built as "requests first").<br />
* Minimize external dependencies. This includes inter-openstack-project dependencies.<br />
* Do not dictate a concurrency paradigm. Ensure that the design is sound, but allow users to use gevent/threads/asyncio/etc.<br />
* Ensure thread safety. Avoid the use of and modification of global objects.<br />
* Documentation must be assumption free. The target audience are not intimately familiar with the internals or designs of the services exposed by the SDK. <br />
* Jargon free. APIs should go by program names ("compute", "storage", "messaging"), rather than the project names ("nova", "swift", "marconi") to ensure the library is accessible to people without significant OpenStack familiarity.<br />
* Vendors / Hosts of OpenStack Clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations, and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator". The client (Layer 4) code for keystoneclient might be in openstack.api.auth, but it would be able to be as advanced as it would like from an api standpoint, and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools/distutils "[http://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins entry points]" for plugins or vendor additions. Doing so prevents single binary builds on Windows and other platforms.<br />
* Take code and ideas from the other python-* clients, but ''do not wrap them'' as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK. The SDK can have helpers for auth caching and retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstack-sdks on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Python-OpenStackSDK [[Meetings/PythonOpenStackSDK|IRC meeting]] is held on TBD<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 python-openstacksdk Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=Meetings&diff=41923Meetings2014-02-11T19:38:50Z<p>Jesse Noller: /* python-openstacksdk Meeting */</p>
<hr />
<div>The OpenStack project holds its various public meetings on '''IRC''', in the <code><nowiki>#openstack-meeting</nowiki></code>, <code><nowiki>#openstack-meeting-alt</nowiki></code> and <code><nowiki>#openstack-meeting-3</nowiki></code> channels on Freenode. Everyone is encouraged to attend.<br />
<br />
You can also access the [https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4@group.calendar.google.com/public/basic.ics iCal feed for all OpenStack meetings].<br />
<br />
== OpenStack Project & Release Status meeting ==<br />
* Weekly on Tuesdays at 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[ThierryCarrez]]<br />
* See [[Meetings/ProjectMeeting]] for details<br />
<br />
== Technical Committee meeting ==<br />
* Weekly on Tuesdays at 2000 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[ThierryCarrez]]<br />
* See [[Governance/TechnicalCommittee]] for details<br />
<br />
== OpenStack Compute (Nova) ==<br />
=== Nova team Meeting ===<br />
* Weekly on Thursdays, alternating times - 1400 UTC and 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> (1400 UTC)<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> (2100 UTC) <br />
* Chair (to contact for more information): Russell Bryant<br />
* See [[Meetings/Nova]] for an agenda<br />
<br />
=== XenAPI team meeting ===<br />
* Weekly on Wednesdays at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by: [[JohnGarbutt]]<br />
* See [[Meetings/XenAPI]] for agenda<br />
<br />
=== Nova Hyper-V team meeting ===<br />
* Weekly on Tuesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by primeministerp (Peter Pouliot)<br />
<br />
=== Scheduler Sub-group meeting ===<br />
* Weekly on Tuesdays at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): n0ano (Don Dugger)<br />
* See [[Meetings/Scheduler]] for details<br />
<br />
=== VMwareAPI team meeting ===<br />
* Weekly on Wednesdays at 1700 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: [[ShawnHartsock]]<br />
* See [[Meetings/VMwareAPI]] for details<br />
<br />
=== PCI Passthrough Meeting ===<br />
* Weekly on Monday, Tuesday, Wednesday and Thursday at [http://www.worldclock.com/world_clock.html 1300 UTC] <br />
* Will change back to once weekly after agreements are reached.<br />
* IRC channel: #openstack-meeting-alt<br />
* Chair: baoli (Robert Li)<br />
* See [[Meetings/Passthrough]] for details<br />
<br />
<br />
== Documentation team meeting ==<br />
* Every other Tuesday at 1300 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[AnneGentle]]<br />
* See [[Meetings/DocTeamMeeting]] for an agenda<br />
<br />
== Project Infrastructure team meeting ==<br />
* Weekly on Tuesdays at 1900 UTC (there is a proposal to move this to Tuesdays at 2200 UTC)<br />
* IRC channel: #openstack-meeting<br />
* Chair (to contact for more information): [[User:Corvus|James E. Blair (jeblair)]]<br />
* See [[Meetings/InfraTeamMeeting]] for an agenda<br />
<br />
== QA team meeting ==<br />
* Weekly on Thursdays at 1700/2200 UTC (alternating)<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): Matt Treinish<br />
* See [[Meetings/QATeamMeeting]] for an agenda<br />
<br />
== DefCore / RefStack Develoment Meeting ==<br />
* Weekly on Thursdays at 2200 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chairs (to contact for more information): Rob "zehicle" Hirschfeld & Joshua McKenty<br />
* See [[Meetings/DefCore]] for an agenda<br />
<br />
== State management team meeting ==<br />
* Weekly on Thursdays at 2000 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000) <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[Harlowja]]<br />
* See [[Meetings/StateManagement]] for an agenda<br />
<br />
== Keystone team meeting ==<br />
* Weekly on Tuesdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[DolphMathews]]<br />
* See [[Meetings/KeystoneMeeting]] for an agenda<br />
<br />
== Ironic (Bare Metal) team meeting ==<br />
* Weekly on Mondays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more infomation) Devananda van der Veen<br />
* see [[Meetings/Ironic]] for agenda<br />
<br />
== TripleO team meeting ==<br />
* Weekly on Tuesdays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more infomation) Robert Collins (lifeless)<br />
* see [[Meetings/TripleO]] for agenda<br />
<br />
== OpenStack Networking (Neutron) ==<br />
=== Neutron team meeting ===<br />
* Weekly on Mondays at 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more infomation) Mark McClain<br />
* see [[Network/Meetings]] for agenda<br />
<br />
=== LBaaS meeting ===<br />
* Weekly on Thursdays at 1400 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more infomation) enikanorov (Eugene Nikanorov)<br />
* see [[Network/LBaaS]] for agenda<br />
<br />
=== ML2 Network sub-team meeting ===<br />
* Weekly on Wednesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): mestery (Kyle Mestery)<br />
* See [[Meetings/ML2]] for details<br />
<br />
=== Firewall as a Service (FWaaS) team meeting ===<br />
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1800 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: snaiksat (Sumit Naiksatam)<br />
* See [[Meetings/FWaaS]] for details<br />
<br />
=== Neutron Advanced Services' Common requirements team meeting ===<br />
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1900 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: snaiksat (Sumit Naiksatam)<br />
* See [[Meetings/AdvancedServices]] for details<br />
<br />
=== Neutron IPv6 sub-team Meeting === <br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1400 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> <br />
* Chair: sc68cal (Sean M. Collins)<br />
* See [[Meetings/Neutron-IPv6-Subteam]] for details<br />
<br />
=== Neutron Group Policy Sub-Team Meeting ===<br />
* Weekly on Thursdays at 1700 UTC<br />
* IRC channel: #openstack-meeting-alt<br />
* Chair: mestery (Kyle Mestery)<br />
* See [[Meetings/Neutron_Group_Policy]] for details<br />
<br />
=== Neutron Distributed Virtual Router meeting ===<br />
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1500 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair:Swami (Swaminathan Vasudevan)<br />
* See [[Meetings/Distributed-Virtual-Router]] for details<br />
<br />
=== Neutron blueprint ovs-firewall-driver Meeting ===<br />
* Tentative: Monday, December 16 at 2000 UTC<br />
* IRC channel: #openstack-meeting<br />
* Chair: asadoughi (Amir Sadoughi)<br />
* Agenda: See [[Meetings/Neutron_blueprint_ovs-firewall-driver]]<br />
<br />
=== Neutron L3 Sub Team Meeting ===<br />
* Tentative: tbd<br />
* IRC channel: tbd<br />
* Chair: carl_baldwin (Carl Baldwin)<br />
* Agenda: See [[Meetings/Neutron-L3-Subteam]]<br />
<br />
== Cinder team meeting ==<br />
* Weekly on Wednesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by [[JohnGriffith]]<br />
* see [[CinderMeetings]] for agenda<br />
<br />
== Ceilometer team meeting ==<br />
* Even weeks on Thursdays at 1500 UTC.<br />
* Odd weeks on Wednesdays at 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by jd__ (Julien Danjou)<br />
* see [[Meetings/Ceilometer]] for details<br />
<br />
== Designate (DNSaaS) meeting ==<br />
* Weekly Wednesdays at 1700 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): Kiall Mac Innes (kiall)<br />
* See [[Meetings/Designate]] for details<br />
<br />
== Trove (DBaaS) meeting ==<br />
* Weekly on Wednesdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): Michael Basnight (hub_cap) / Vipul Sabhaya (vipul) / Nikhil Manchanda (SlickNik) / Tim Simpson (grapex)<br />
* See [[Meetings/TroveMeeting]] for details<br />
<br />
== Marconi (queues) team meeting ==<br />
* Weekly on Tuesday at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: kgriffs (Kurt Griffiths)<br />
* See [[Meetings/Marconi]] for details<br />
<br />
== Savanna team meeting ==<br />
* Weekly on Thursdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more info): SergeyLukjanov (Sergey Lukjanov)<br />
* See [[Meetings/SavannaAgenda]] for details<br />
<br />
== Mistral meeting ==<br />
* Weekly on Mondays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: rakhmerov (Renat Akhmerov)<br />
* See [[Meetings/MistralAgenda]] for details<br />
<br />
== Murano meeting ==<br />
* Weekly on Tuesday at 1700 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: Georgiy Okrokvertskhov (Georgy_Ok)<br />
* See [[Meetings/MuranoAgenda]] for details<br />
<br />
== Heat (orchestration) team meeting ==<br />
* Weekly on Wednesdays at 2000 UTC or Thursdays at 0000 UTC (alternate weeks)<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): Steve Baker (stevebaker)<br />
* See [[Meetings/HeatAgenda]] for details<br />
<br />
== Horizon team meeting ==<br />
* Weekly on Tuesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* Chair: David Lyle (david-lyle)<br />
* See [[Meetings/Horizon]] for details<br />
<br />
== Swift team meeting ==<br />
* Weekly on Wednesdays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: notmyname (John Dickinson)<br />
* See [[Meetings/Swift]] for details<br />
<br />
== OpenStack Security Group (OSSG) meeting ==<br />
* Weekly on Thursdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): bdpayne (Bryan Payne)<br />
* See [[Meetings/OpenStackSecurity]] for an agenda<br />
<br />
== Python3 Compatibility Team meeting ==<br />
* Not planned anymore<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): jd_ (Julien Danjou)<br />
* See [[Meetings/Python3]] for details<br />
<br />
== Glance Team meeting ==<br />
* Weekly on Thursdays at 1400/2000 UTC (alternating)<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): markwash (Mark Washenberger)<br />
* See [[Meetings/Glance]] for details<br />
<br />
== Oslo Team meeting ==<br />
* On demand on Fridays at 1400 UTC (see [http://www.doodle.com/vbs7ux7m4pa3c6c5 this doodle])<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): markmc (Mark McLoughlin)<br />
* See [[Meetings/Oslo]] for details<br />
<br />
== OpenStack Community team meeting ==<br />
* Weekly on Wednesday at [http://www.worldclock.com/world_clock.html 2300 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: reed ([http://www.openstack.org/community/members/profile/1372 Stefano Maffulli])<br />
* See [[Meetings/Community]] for details<br />
<br />
== I18N Team meeting ==<br />
* Weekly on Thursday, alternating between 0100 UTC and 0700 UTC <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: daisy<br />
* See [[Meetings/I18nTeamMeeting]] for details<br />
<br />
== Training-manuals Team meeting ==<br />
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1700 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: sarob<br />
* See [[Meetings/training-manuals]] for details<br />
<br />
== Manila Team meeting ==<br />
* Weekly on Thursday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1500 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: bswartz<br />
* See [[ManilaMeetings]] for details<br />
<br />
== Stackalytics team meeting ==<br />
* Be-Weekly on Mondays (starting from October 21st) at [http://www.worldclock.com/world_clock.html 1500 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: ilyashakhat (Ilya Shakhat)<br />
* See [[Meetings/Stackalytics]] for details<br />
<br />
== Climate (Reservations) team meeting ==<br />
* Weekly on Fridays at [http://www.worldclock.com/world_clock.html 1500 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: bauzas (Sylvain Bauza), DinaBelova (Dina Belova)<br />
* See [[Meetings/Climate]] for details<br />
<br />
== Rally meeting ==<br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1700 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair:boris-42 (Boris Pavlovic)<br />
* See [[Meetings/Rally]] for details<br />
<br />
== Solum Team Meeting ==<br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1600 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: adrian_otto (Adrian Otto)<br />
* See [[Meetings/Solum]] for details<br />
<br />
== Congress Team Meeting ==<br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1800 UTC] <br />
* IRC channel: #openstack-meeting-alt<br />
* Chair: pballand (Pete Balland)<br />
* See [[Meetings/Congress]] for details<br />
<br />
== Barbican Meeting ==<br />
* Weekly on Mondays at [http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000 2000 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): jraim (#openstack-barbican @ Freenode)<br />
* See [[Meetings/Barbican]] for an agenda<br />
<br />
== Chef Cookbook meeting ==<br />
* Weekly on Mondays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-chef</nowiki></code><br />
* Chair: mattray (Matt Ray)<br />
* See [[Meetings/ChefCookbook]] for details<br />
<br />
== Milk Meeting ==<br />
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 2000 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: sarob<br />
* See [[Meetings/milk]] for details<br />
<br />
== StoryBoard Meeting ==<br />
* Weekly on Thursdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: cody-somerville or ttx<br />
* See [[StoryBoard]] for details<br />
<br />
<br />
== Hierarchical Multitenancy Meeting ==<br />
* Weekly on Fridays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: vishy<br />
* See [[HierarchicalMultitenancy]] for details<br />
<br />
== python-openstacksdk Meeting ==<br />
* Weekly on Wednesdays at [http://www.worldtimebuddy.com/?qm=1&lid=6,0,4726206,100&h=6&date=2014-2-11&sln=13-14 1900 UTC] starting 2/19/2014<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* Chair: jnoller<br />
* See [[PythonOpenStackSDK]] for details</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=Meetings&diff=41922Meetings2014-02-11T19:38:22Z<p>Jesse Noller: /* python-openstacksdk Meeting */</p>
<hr />
<div>The OpenStack project holds its various public meetings on '''IRC''', in the <code><nowiki>#openstack-meeting</nowiki></code>, <code><nowiki>#openstack-meeting-alt</nowiki></code> and <code><nowiki>#openstack-meeting-3</nowiki></code> channels on Freenode. Everyone is encouraged to attend.<br />
<br />
You can also access the [https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4@group.calendar.google.com/public/basic.ics iCal feed for all OpenStack meetings].<br />
<br />
== OpenStack Project & Release Status meeting ==<br />
* Weekly on Tuesdays at 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[ThierryCarrez]]<br />
* See [[Meetings/ProjectMeeting]] for details<br />
<br />
== Technical Committee meeting ==<br />
* Weekly on Tuesdays at 2000 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[ThierryCarrez]]<br />
* See [[Governance/TechnicalCommittee]] for details<br />
<br />
== OpenStack Compute (Nova) ==<br />
=== Nova team Meeting ===<br />
* Weekly on Thursdays, alternating times - 1400 UTC and 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> (1400 UTC)<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> (2100 UTC) <br />
* Chair (to contact for more information): Russell Bryant<br />
* See [[Meetings/Nova]] for an agenda<br />
<br />
=== XenAPI team meeting ===<br />
* Weekly on Wednesdays at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by: [[JohnGarbutt]]<br />
* See [[Meetings/XenAPI]] for agenda<br />
<br />
=== Nova Hyper-V team meeting ===<br />
* Weekly on Tuesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by primeministerp (Peter Pouliot)<br />
<br />
=== Scheduler Sub-group meeting ===<br />
* Weekly on Tuesdays at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): n0ano (Don Dugger)<br />
* See [[Meetings/Scheduler]] for details<br />
<br />
=== VMwareAPI team meeting ===<br />
* Weekly on Wednesdays at 1700 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: [[ShawnHartsock]]<br />
* See [[Meetings/VMwareAPI]] for details<br />
<br />
=== PCI Passthrough Meeting ===<br />
* Weekly on Monday, Tuesday, Wednesday and Thursday at [http://www.worldclock.com/world_clock.html 1300 UTC] <br />
* Will change back to once weekly after agreements are reached.<br />
* IRC channel: #openstack-meeting-alt<br />
* Chair: baoli (Robert Li)<br />
* See [[Meetings/Passthrough]] for details<br />
<br />
<br />
== Documentation team meeting ==<br />
* Every other Tuesday at 1300 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[AnneGentle]]<br />
* See [[Meetings/DocTeamMeeting]] for an agenda<br />
<br />
== Project Infrastructure team meeting ==<br />
* Weekly on Tuesdays at 1900 UTC (there is a proposal to move this to Tuesdays at 2200 UTC)<br />
* IRC channel: #openstack-meeting<br />
* Chair (to contact for more information): [[User:Corvus|James E. Blair (jeblair)]]<br />
* See [[Meetings/InfraTeamMeeting]] for an agenda<br />
<br />
== QA team meeting ==<br />
* Weekly on Thursdays at 1700/2200 UTC (alternating)<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): Matt Treinish<br />
* See [[Meetings/QATeamMeeting]] for an agenda<br />
<br />
== DefCore / RefStack Develoment Meeting ==<br />
* Weekly on Thursdays at 2200 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chairs (to contact for more information): Rob "zehicle" Hirschfeld & Joshua McKenty<br />
* See [[Meetings/DefCore]] for an agenda<br />
<br />
== State management team meeting ==<br />
* Weekly on Thursdays at 2000 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000) <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[Harlowja]]<br />
* See [[Meetings/StateManagement]] for an agenda<br />
<br />
== Keystone team meeting ==<br />
* Weekly on Tuesdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[DolphMathews]]<br />
* See [[Meetings/KeystoneMeeting]] for an agenda<br />
<br />
== Ironic (Bare Metal) team meeting ==<br />
* Weekly on Mondays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more infomation) Devananda van der Veen<br />
* see [[Meetings/Ironic]] for agenda<br />
<br />
== TripleO team meeting ==<br />
* Weekly on Tuesdays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more infomation) Robert Collins (lifeless)<br />
* see [[Meetings/TripleO]] for agenda<br />
<br />
== OpenStack Networking (Neutron) ==<br />
=== Neutron team meeting ===<br />
* Weekly on Mondays at 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more infomation) Mark McClain<br />
* see [[Network/Meetings]] for agenda<br />
<br />
=== LBaaS meeting ===<br />
* Weekly on Thursdays at 1400 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more infomation) enikanorov (Eugene Nikanorov)<br />
* see [[Network/LBaaS]] for agenda<br />
<br />
=== ML2 Network sub-team meeting ===<br />
* Weekly on Wednesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): mestery (Kyle Mestery)<br />
* See [[Meetings/ML2]] for details<br />
<br />
=== Firewall as a Service (FWaaS) team meeting ===<br />
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1800 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: snaiksat (Sumit Naiksatam)<br />
* See [[Meetings/FWaaS]] for details<br />
<br />
=== Neutron Advanced Services' Common requirements team meeting ===<br />
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1900 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: snaiksat (Sumit Naiksatam)<br />
* See [[Meetings/AdvancedServices]] for details<br />
<br />
=== Neutron IPv6 sub-team Meeting === <br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1400 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> <br />
* Chair: sc68cal (Sean M. Collins)<br />
* See [[Meetings/Neutron-IPv6-Subteam]] for details<br />
<br />
=== Neutron Group Policy Sub-Team Meeting ===<br />
* Weekly on Thursdays at 1700 UTC<br />
* IRC channel: #openstack-meeting-alt<br />
* Chair: mestery (Kyle Mestery)<br />
* See [[Meetings/Neutron_Group_Policy]] for details<br />
<br />
=== Neutron Distributed Virtual Router meeting ===<br />
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1500 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair:Swami (Swaminathan Vasudevan)<br />
* See [[Meetings/Distributed-Virtual-Router]] for details<br />
<br />
=== Neutron blueprint ovs-firewall-driver Meeting ===<br />
* Tentative: Monday, December 16 at 2000 UTC<br />
* IRC channel: #openstack-meeting<br />
* Chair: asadoughi (Amir Sadoughi)<br />
* Agenda: See [[Meetings/Neutron_blueprint_ovs-firewall-driver]]<br />
<br />
=== Neutron L3 Sub Team Meeting ===<br />
* Tentative: tbd<br />
* IRC channel: tbd<br />
* Chair: carl_baldwin (Carl Baldwin)<br />
* Agenda: See [[Meetings/Neutron-L3-Subteam]]<br />
<br />
== Cinder team meeting ==<br />
* Weekly on Wednesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by [[JohnGriffith]]<br />
* see [[CinderMeetings]] for agenda<br />
<br />
== Ceilometer team meeting ==<br />
* Even weeks on Thursdays at 1500 UTC.<br />
* Odd weeks on Wednesdays at 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by jd__ (Julien Danjou)<br />
* see [[Meetings/Ceilometer]] for details<br />
<br />
== Designate (DNSaaS) meeting ==<br />
* Weekly Wednesdays at 1700 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): Kiall Mac Innes (kiall)<br />
* See [[Meetings/Designate]] for details<br />
<br />
== Trove (DBaaS) meeting ==<br />
* Weekly on Wednesdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): Michael Basnight (hub_cap) / Vipul Sabhaya (vipul) / Nikhil Manchanda (SlickNik) / Tim Simpson (grapex)<br />
* See [[Meetings/TroveMeeting]] for details<br />
<br />
== Marconi (queues) team meeting ==<br />
* Weekly on Tuesday at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: kgriffs (Kurt Griffiths)<br />
* See [[Meetings/Marconi]] for details<br />
<br />
== Savanna team meeting ==<br />
* Weekly on Thursdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more info): SergeyLukjanov (Sergey Lukjanov)<br />
* See [[Meetings/SavannaAgenda]] for details<br />
<br />
== Mistral meeting ==<br />
* Weekly on Mondays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: rakhmerov (Renat Akhmerov)<br />
* See [[Meetings/MistralAgenda]] for details<br />
<br />
== Murano meeting ==<br />
* Weekly on Tuesday at 1700 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: Georgiy Okrokvertskhov (Georgy_Ok)<br />
* See [[Meetings/MuranoAgenda]] for details<br />
<br />
== Heat (orchestration) team meeting ==<br />
* Weekly on Wednesdays at 2000 UTC or Thursdays at 0000 UTC (alternate weeks)<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): Steve Baker (stevebaker)<br />
* See [[Meetings/HeatAgenda]] for details<br />
<br />
== Horizon team meeting ==<br />
* Weekly on Tuesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* Chair: David Lyle (david-lyle)<br />
* See [[Meetings/Horizon]] for details<br />
<br />
== Swift team meeting ==<br />
* Weekly on Wednesdays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: notmyname (John Dickinson)<br />
* See [[Meetings/Swift]] for details<br />
<br />
== OpenStack Security Group (OSSG) meeting ==<br />
* Weekly on Thursdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): bdpayne (Bryan Payne)<br />
* See [[Meetings/OpenStackSecurity]] for an agenda<br />
<br />
== Python3 Compatibility Team meeting ==<br />
* Not planned anymore<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): jd_ (Julien Danjou)<br />
* See [[Meetings/Python3]] for details<br />
<br />
== Glance Team meeting ==<br />
* Weekly on Thursdays at 1400/2000 UTC (alternating)<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): markwash (Mark Washenberger)<br />
* See [[Meetings/Glance]] for details<br />
<br />
== Oslo Team meeting ==<br />
* On demand on Fridays at 1400 UTC (see [http://www.doodle.com/vbs7ux7m4pa3c6c5 this doodle])<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): markmc (Mark McLoughlin)<br />
* See [[Meetings/Oslo]] for details<br />
<br />
== OpenStack Community team meeting ==<br />
* Weekly on Wednesday at [http://www.worldclock.com/world_clock.html 2300 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: reed ([http://www.openstack.org/community/members/profile/1372 Stefano Maffulli])<br />
* See [[Meetings/Community]] for details<br />
<br />
== I18N Team meeting ==<br />
* Weekly on Thursday, alternating between 0100 UTC and 0700 UTC <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: daisy<br />
* See [[Meetings/I18nTeamMeeting]] for details<br />
<br />
== Training-manuals Team meeting ==<br />
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1700 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: sarob<br />
* See [[Meetings/training-manuals]] for details<br />
<br />
== Manila Team meeting ==<br />
* Weekly on Thursday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1500 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: bswartz<br />
* See [[ManilaMeetings]] for details<br />
<br />
== Stackalytics team meeting ==<br />
* Be-Weekly on Mondays (starting from October 21st) at [http://www.worldclock.com/world_clock.html 1500 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: ilyashakhat (Ilya Shakhat)<br />
* See [[Meetings/Stackalytics]] for details<br />
<br />
== Climate (Reservations) team meeting ==<br />
* Weekly on Fridays at [http://www.worldclock.com/world_clock.html 1500 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: bauzas (Sylvain Bauza), DinaBelova (Dina Belova)<br />
* See [[Meetings/Climate]] for details<br />
<br />
== Rally meeting ==<br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1700 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair:boris-42 (Boris Pavlovic)<br />
* See [[Meetings/Rally]] for details<br />
<br />
== Solum Team Meeting ==<br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1600 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: adrian_otto (Adrian Otto)<br />
* See [[Meetings/Solum]] for details<br />
<br />
== Congress Team Meeting ==<br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1800 UTC] <br />
* IRC channel: #openstack-meeting-alt<br />
* Chair: pballand (Pete Balland)<br />
* See [[Meetings/Congress]] for details<br />
<br />
== Barbican Meeting ==<br />
* Weekly on Mondays at [http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000 2000 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): jraim (#openstack-barbican @ Freenode)<br />
* See [[Meetings/Barbican]] for an agenda<br />
<br />
== Chef Cookbook meeting ==<br />
* Weekly on Mondays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-chef</nowiki></code><br />
* Chair: mattray (Matt Ray)<br />
* See [[Meetings/ChefCookbook]] for details<br />
<br />
== Milk Meeting ==<br />
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 2000 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: sarob<br />
* See [[Meetings/milk]] for details<br />
<br />
== StoryBoard Meeting ==<br />
* Weekly on Thursdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: cody-somerville or ttx<br />
* See [[StoryBoard]] for details<br />
<br />
<br />
== Hierarchical Multitenancy Meeting ==<br />
* Weekly on Fridays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: vishy<br />
* See [[HierarchicalMultitenancy]] for details<br />
<br />
== python-openstacksdk Meeting ==<br />
* Weekly on Wednesdays at [http://www.worldtimebuddy.com/?qm=1&lid=6,0,4726206,100&h=6&date=2014-2-11&sln=13-14 1900 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* Chair: jnoller<br />
* See [[PythonOpenStackSDK]] for details</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=Meetings&diff=41920Meetings2014-02-11T19:37:13Z<p>Jesse Noller: </p>
<hr />
<div>The OpenStack project holds its various public meetings on '''IRC''', in the <code><nowiki>#openstack-meeting</nowiki></code>, <code><nowiki>#openstack-meeting-alt</nowiki></code> and <code><nowiki>#openstack-meeting-3</nowiki></code> channels on Freenode. Everyone is encouraged to attend.<br />
<br />
You can also access the [https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4@group.calendar.google.com/public/basic.ics iCal feed for all OpenStack meetings].<br />
<br />
== OpenStack Project & Release Status meeting ==<br />
* Weekly on Tuesdays at 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[ThierryCarrez]]<br />
* See [[Meetings/ProjectMeeting]] for details<br />
<br />
== Technical Committee meeting ==<br />
* Weekly on Tuesdays at 2000 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[ThierryCarrez]]<br />
* See [[Governance/TechnicalCommittee]] for details<br />
<br />
== OpenStack Compute (Nova) ==<br />
=== Nova team Meeting ===<br />
* Weekly on Thursdays, alternating times - 1400 UTC and 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> (1400 UTC)<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> (2100 UTC) <br />
* Chair (to contact for more information): Russell Bryant<br />
* See [[Meetings/Nova]] for an agenda<br />
<br />
=== XenAPI team meeting ===<br />
* Weekly on Wednesdays at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by: [[JohnGarbutt]]<br />
* See [[Meetings/XenAPI]] for agenda<br />
<br />
=== Nova Hyper-V team meeting ===<br />
* Weekly on Tuesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by primeministerp (Peter Pouliot)<br />
<br />
=== Scheduler Sub-group meeting ===<br />
* Weekly on Tuesdays at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): n0ano (Don Dugger)<br />
* See [[Meetings/Scheduler]] for details<br />
<br />
=== VMwareAPI team meeting ===<br />
* Weekly on Wednesdays at 1700 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: [[ShawnHartsock]]<br />
* See [[Meetings/VMwareAPI]] for details<br />
<br />
=== PCI Passthrough Meeting ===<br />
* Weekly on Monday, Tuesday, Wednesday and Thursday at [http://www.worldclock.com/world_clock.html 1300 UTC] <br />
* Will change back to once weekly after agreements are reached.<br />
* IRC channel: #openstack-meeting-alt<br />
* Chair: baoli (Robert Li)<br />
* See [[Meetings/Passthrough]] for details<br />
<br />
<br />
== Documentation team meeting ==<br />
* Every other Tuesday at 1300 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[AnneGentle]]<br />
* See [[Meetings/DocTeamMeeting]] for an agenda<br />
<br />
== Project Infrastructure team meeting ==<br />
* Weekly on Tuesdays at 1900 UTC (there is a proposal to move this to Tuesdays at 2200 UTC)<br />
* IRC channel: #openstack-meeting<br />
* Chair (to contact for more information): [[User:Corvus|James E. Blair (jeblair)]]<br />
* See [[Meetings/InfraTeamMeeting]] for an agenda<br />
<br />
== QA team meeting ==<br />
* Weekly on Thursdays at 1700/2200 UTC (alternating)<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): Matt Treinish<br />
* See [[Meetings/QATeamMeeting]] for an agenda<br />
<br />
== DefCore / RefStack Develoment Meeting ==<br />
* Weekly on Thursdays at 2200 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chairs (to contact for more information): Rob "zehicle" Hirschfeld & Joshua McKenty<br />
* See [[Meetings/DefCore]] for an agenda<br />
<br />
== State management team meeting ==<br />
* Weekly on Thursdays at 2000 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000) <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[Harlowja]]<br />
* See [[Meetings/StateManagement]] for an agenda<br />
<br />
== Keystone team meeting ==<br />
* Weekly on Tuesdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): [[DolphMathews]]<br />
* See [[Meetings/KeystoneMeeting]] for an agenda<br />
<br />
== Ironic (Bare Metal) team meeting ==<br />
* Weekly on Mondays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more infomation) Devananda van der Veen<br />
* see [[Meetings/Ironic]] for agenda<br />
<br />
== TripleO team meeting ==<br />
* Weekly on Tuesdays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more infomation) Robert Collins (lifeless)<br />
* see [[Meetings/TripleO]] for agenda<br />
<br />
== OpenStack Networking (Neutron) ==<br />
=== Neutron team meeting ===<br />
* Weekly on Mondays at 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more infomation) Mark McClain<br />
* see [[Network/Meetings]] for agenda<br />
<br />
=== LBaaS meeting ===<br />
* Weekly on Thursdays at 1400 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more infomation) enikanorov (Eugene Nikanorov)<br />
* see [[Network/LBaaS]] for agenda<br />
<br />
=== ML2 Network sub-team meeting ===<br />
* Weekly on Wednesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): mestery (Kyle Mestery)<br />
* See [[Meetings/ML2]] for details<br />
<br />
=== Firewall as a Service (FWaaS) team meeting ===<br />
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1800 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: snaiksat (Sumit Naiksatam)<br />
* See [[Meetings/FWaaS]] for details<br />
<br />
=== Neutron Advanced Services' Common requirements team meeting ===<br />
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1900 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: snaiksat (Sumit Naiksatam)<br />
* See [[Meetings/AdvancedServices]] for details<br />
<br />
=== Neutron IPv6 sub-team Meeting === <br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1400 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> <br />
* Chair: sc68cal (Sean M. Collins)<br />
* See [[Meetings/Neutron-IPv6-Subteam]] for details<br />
<br />
=== Neutron Group Policy Sub-Team Meeting ===<br />
* Weekly on Thursdays at 1700 UTC<br />
* IRC channel: #openstack-meeting-alt<br />
* Chair: mestery (Kyle Mestery)<br />
* See [[Meetings/Neutron_Group_Policy]] for details<br />
<br />
=== Neutron Distributed Virtual Router meeting ===<br />
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1500 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair:Swami (Swaminathan Vasudevan)<br />
* See [[Meetings/Distributed-Virtual-Router]] for details<br />
<br />
=== Neutron blueprint ovs-firewall-driver Meeting ===<br />
* Tentative: Monday, December 16 at 2000 UTC<br />
* IRC channel: #openstack-meeting<br />
* Chair: asadoughi (Amir Sadoughi)<br />
* Agenda: See [[Meetings/Neutron_blueprint_ovs-firewall-driver]]<br />
<br />
=== Neutron L3 Sub Team Meeting ===<br />
* Tentative: tbd<br />
* IRC channel: tbd<br />
* Chair: carl_baldwin (Carl Baldwin)<br />
* Agenda: See [[Meetings/Neutron-L3-Subteam]]<br />
<br />
== Cinder team meeting ==<br />
* Weekly on Wednesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by [[JohnGriffith]]<br />
* see [[CinderMeetings]] for agenda<br />
<br />
== Ceilometer team meeting ==<br />
* Even weeks on Thursdays at 1500 UTC.<br />
* Odd weeks on Wednesdays at 2100 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chaired by jd__ (Julien Danjou)<br />
* see [[Meetings/Ceilometer]] for details<br />
<br />
== Designate (DNSaaS) meeting ==<br />
* Weekly Wednesdays at 1700 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): Kiall Mac Innes (kiall)<br />
* See [[Meetings/Designate]] for details<br />
<br />
== Trove (DBaaS) meeting ==<br />
* Weekly on Wednesdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): Michael Basnight (hub_cap) / Vipul Sabhaya (vipul) / Nikhil Manchanda (SlickNik) / Tim Simpson (grapex)<br />
* See [[Meetings/TroveMeeting]] for details<br />
<br />
== Marconi (queues) team meeting ==<br />
* Weekly on Tuesday at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: kgriffs (Kurt Griffiths)<br />
* See [[Meetings/Marconi]] for details<br />
<br />
== Savanna team meeting ==<br />
* Weekly on Thursdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more info): SergeyLukjanov (Sergey Lukjanov)<br />
* See [[Meetings/SavannaAgenda]] for details<br />
<br />
== Mistral meeting ==<br />
* Weekly on Mondays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: rakhmerov (Renat Akhmerov)<br />
* See [[Meetings/MistralAgenda]] for details<br />
<br />
== Murano meeting ==<br />
* Weekly on Tuesday at 1700 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: Georgiy Okrokvertskhov (Georgy_Ok)<br />
* See [[Meetings/MuranoAgenda]] for details<br />
<br />
== Heat (orchestration) team meeting ==<br />
* Weekly on Wednesdays at 2000 UTC or Thursdays at 0000 UTC (alternate weeks)<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): Steve Baker (stevebaker)<br />
* See [[Meetings/HeatAgenda]] for details<br />
<br />
== Horizon team meeting ==<br />
* Weekly on Tuesdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* Chair: David Lyle (david-lyle)<br />
* See [[Meetings/Horizon]] for details<br />
<br />
== Swift team meeting ==<br />
* Weekly on Wednesdays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: notmyname (John Dickinson)<br />
* See [[Meetings/Swift]] for details<br />
<br />
== OpenStack Security Group (OSSG) meeting ==<br />
* Weekly on Thursdays at 1800 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): bdpayne (Bryan Payne)<br />
* See [[Meetings/OpenStackSecurity]] for an agenda<br />
<br />
== Python3 Compatibility Team meeting ==<br />
* Not planned anymore<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): jd_ (Julien Danjou)<br />
* See [[Meetings/Python3]] for details<br />
<br />
== Glance Team meeting ==<br />
* Weekly on Thursdays at 1400/2000 UTC (alternating)<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): markwash (Mark Washenberger)<br />
* See [[Meetings/Glance]] for details<br />
<br />
== Oslo Team meeting ==<br />
* On demand on Fridays at 1400 UTC (see [http://www.doodle.com/vbs7ux7m4pa3c6c5 this doodle])<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair (to contact for more information): markmc (Mark McLoughlin)<br />
* See [[Meetings/Oslo]] for details<br />
<br />
== OpenStack Community team meeting ==<br />
* Weekly on Wednesday at [http://www.worldclock.com/world_clock.html 2300 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: reed ([http://www.openstack.org/community/members/profile/1372 Stefano Maffulli])<br />
* See [[Meetings/Community]] for details<br />
<br />
== I18N Team meeting ==<br />
* Weekly on Thursday, alternating between 0100 UTC and 0700 UTC <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: daisy<br />
* See [[Meetings/I18nTeamMeeting]] for details<br />
<br />
== Training-manuals Team meeting ==<br />
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1700 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: sarob<br />
* See [[Meetings/training-manuals]] for details<br />
<br />
== Manila Team meeting ==<br />
* Weekly on Thursday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1500 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: bswartz<br />
* See [[ManilaMeetings]] for details<br />
<br />
== Stackalytics team meeting ==<br />
* Be-Weekly on Mondays (starting from October 21st) at [http://www.worldclock.com/world_clock.html 1500 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: ilyashakhat (Ilya Shakhat)<br />
* See [[Meetings/Stackalytics]] for details<br />
<br />
== Climate (Reservations) team meeting ==<br />
* Weekly on Fridays at [http://www.worldclock.com/world_clock.html 1500 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: bauzas (Sylvain Bauza), DinaBelova (Dina Belova)<br />
* See [[Meetings/Climate]] for details<br />
<br />
== Rally meeting ==<br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1700 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair:boris-42 (Boris Pavlovic)<br />
* See [[Meetings/Rally]] for details<br />
<br />
== Solum Team Meeting ==<br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1600 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair: adrian_otto (Adrian Otto)<br />
* See [[Meetings/Solum]] for details<br />
<br />
== Congress Team Meeting ==<br />
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1800 UTC] <br />
* IRC channel: #openstack-meeting-alt<br />
* Chair: pballand (Pete Balland)<br />
* See [[Meetings/Congress]] for details<br />
<br />
== Barbican Meeting ==<br />
* Weekly on Mondays at [http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000 2000 UTC]<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code><br />
* Chair (to contact for more information): jraim (#openstack-barbican @ Freenode)<br />
* See [[Meetings/Barbican]] for an agenda<br />
<br />
== Chef Cookbook meeting ==<br />
* Weekly on Mondays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-chef</nowiki></code><br />
* Chair: mattray (Matt Ray)<br />
* See [[Meetings/ChefCookbook]] for details<br />
<br />
== Milk Meeting ==<br />
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 2000 UTC] <br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: sarob<br />
* See [[Meetings/milk]] for details<br />
<br />
== StoryBoard Meeting ==<br />
* Weekly on Thursdays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: cody-somerville or ttx<br />
* See [[StoryBoard]] for details<br />
<br />
<br />
== Hierarchical Multitenancy Meeting ==<br />
* Weekly on Fridays at 1600 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code><br />
* Chair: vishy<br />
* See [[HierarchicalMultitenancy]] for details<br />
<br />
== python-openstacksdk Meeting ==<br />
* Weekly on Wednesdays at 1900 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* Chair: jnoller<br />
* See [[PythonOpenStackSDK]] for details</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=41659Meetings/PythonOpenStackSDK2014-02-07T23:14:06Z<p>Jesse Noller: Created page with "= Weekly Python-OpenstackSDK Team Meeting = If you're interested in PythonOpenStackSDK, we will be holding public meetings weekly in on freenode in #openstack-sdks. Pleas..."</p>
<hr />
<div>= Weekly Python-OpenstackSDK Team Meeting =<br />
<br />
If you're interested in [[PythonOpenStackSDK]], we will be holding public meetings weekly in on freenode in #openstack-sdks. Please feel free to add items to the agenda below with your name and we'll cover them. The meeting will last 1 hour.<br />
<br />
if you would like to attend, please fill out the doodle: http://doodle.com/qe6v2ssr28x8urqe<br />
<br />
<br />
== Agenda for Date TBD ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* State of blueprints<br />
* Determine Action Items / Initial Milestone<br />
* PTL<br />
<br />
== Previous Meetings ==</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=41658SDK-Development/PythonOpenStackSDK2014-02-07T23:03:55Z<p>Jesse Noller: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances, it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The python-openstacksdk project proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation, it becomes very easy to derive a unified CLI, such as openstackclient, or specialized per-service CLI tools. However, it is important that the definition of SDK -- the compilation of the APIs and developer functions -- and CLI tools stay separate as it is easy to conflate the idea of "clients," which is the state we have today. <br />
<br />
Once the initial work to create the python-openstacksdk is complete; the next stage would be to collapse the individual python-* clients and use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
'''What's in an SDK?''':<br />
<br />
An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:<br />
* Documentation aimed at users consuming the SDK and system.<br />
* Clear examples of usage, including functioning, executable examples.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators or Developers. These are developers looking to '''consume''' a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds. The commands they use should follow a consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/stackforge/python-openstacksdk<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints || https://launchpad.net/unifiedsdk<br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* Verified mocks/stubs for testing at all layers.<br />
* python-requests based REST client (built as "requests first").<br />
* Minimize external dependencies. This includes inter-openstack-project dependencies.<br />
* Do not dictate a concurrency paradigm. Ensure that the design is sound, but allow users to use gevent/threads/asyncio/etc.<br />
* Ensure thread safety. Avoid the use of and modification of global objects.<br />
* Documentation must be assumption free. The target audience are not intimately familiar with the internals or designs of the services exposed by the SDK. <br />
* Jargon free. APIs should go by program names ("compute", "storage", "messaging"), rather than the project names ("nova", "swift", "marconi") to ensure the library is accessible to people without significant OpenStack familiarity.<br />
* Vendors / Hosts of OpenStack Clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations, and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator". The client (Layer 4) code for keystoneclient might be in openstack.api.auth, but it would be able to be as advanced as it would like from an api standpoint, and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools/distutils "[http://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins entry points]" for plugins or vendor additions. Doing so prevents single binary builds on Windows and other platforms.<br />
* Take code and ideas from the other python-* clients, but ''do not wrap them'' as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK. The SDK can have helpers for auth caching and retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in ##openstack-sdks on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Python-OpenStackSDK [[Meetings/PythonOpenStackSDK|IRC meeting]] is held on TBD<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 python-openstacksdk Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=41657SDK-Development/PythonOpenStackSDK2014-02-07T23:01:06Z<p>Jesse Noller: /* Meetings */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances, it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation, it becomes very easy to derive a unified CLI, such as openstackclient, or specialized per-service CLI tools. However, it is important that the definition of SDK -- the compilation of the APIs and developer functions -- and CLI tools stay separate as it is easy to conflate the idea of "clients," which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients and use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
'''What's in an SDK?''':<br />
<br />
An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:<br />
* Documentation aimed at users consuming the SDK and system.<br />
* Clear examples of usage, including functioning, executable examples.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators or Developers. These are developers looking to '''consume''' a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds. The commands they use should follow a consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/stackforge/python-openstacksdk<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints || https://launchpad.net/unifiedsdk<br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* Verified mocks/stubs for testing at all layers.<br />
* python-requests based REST client (built as "requests first").<br />
* Minimize external dependencies. This includes inter-openstack-project dependencies.<br />
* Do not dictate a concurrency paradigm. Ensure that the design is sound, but allow users to use gevent/threads/asyncio/etc.<br />
* Ensure thread safety. Avoid the use of and modification of global objects.<br />
* Documentation must be assumption free. The target audience are not intimately familiar with the internals or designs of the services exposed by the SDK. <br />
* Jargon free. APIs should go by program names ("compute", "storage", "messaging"), rather than the project names ("nova", "swift", "marconi") to ensure the library is accessible to people without significant OpenStack familiarity.<br />
* Vendors / Hosts of OpenStack Clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations, and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator". The client (Layer 4) code for keystoneclient might be in openstack.api.auth, but it would be able to be as advanced as it would like from an api standpoint, and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools/distutils "[http://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins entry points]" for plugins or vendor additions. Doing so prevents single binary builds on Windows and other platforms.<br />
* Take code and ideas from the other python-* clients, but ''do not wrap them'' as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK. The SDK can have helpers for auth caching and retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in ##openstack-sdks on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Python-OpenStackSDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK/FAQ&diff=41656SDK-Development/PythonOpenStackSDK/FAQ2014-02-07T22:54:35Z<p>Jesse Noller: Created page with "In Progress."</p>
<hr />
<div>In Progress.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=41622SDK-Development/PythonOpenStackSDK2014-02-07T17:49:38Z<p>Jesse Noller: Jesse Noller moved page UnifiedSDK to PythonOpenStackSDK: Naming things</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances, it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation, it becomes very easy to derive a unified CLI, such as openstackclient, or specialized per-service CLI tools. However, it is important that the definition of SDK -- the compilation of the APIs and developer functions -- and CLI tools stay separate as it is easy to conflate the idea of "clients," which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients and use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
'''What's in an SDK?''':<br />
<br />
An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:<br />
* Documentation aimed at users consuming the SDK and system.<br />
* Clear examples of usage, including functioning, executable examples.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators or Developers. These are developers looking to '''consume''' a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds. The commands they use should follow a consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/stackforge/python-openstacksdk<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints || https://launchpad.net/unifiedsdk<br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* Verified mocks/stubs for testing at all layers.<br />
* python-requests based REST client (built as "requests first").<br />
* Minimize external dependencies. This includes inter-openstack-project dependencies.<br />
* Do not dictate a concurrency paradigm. Ensure that the design is sound, but allow users to use gevent/threads/asyncio/etc.<br />
* Ensure thread safety. Avoid the use of and modification of global objects.<br />
* Documentation must be assumption free. The target audience are not intimately familiar with the internals or designs of the services exposed by the SDK. <br />
* Jargon free. APIs should go by program names ("compute", "storage", "messaging"), rather than the project names ("nova", "swift", "marconi") to ensure the library is accessible to people without significant OpenStack familiarity.<br />
* Vendors / Hosts of OpenStack Clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations, and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator". The client (Layer 4) code for keystoneclient might be in openstack.api.auth, but it would be able to be as advanced as it would like from an api standpoint, and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools/distutils "[http://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins entry points]" for plugins or vendor additions. Doing so prevents single binary builds on Windows and other platforms.<br />
* Take code and ideas from the other python-* clients, but ''do not wrap them'' as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK. The SDK can have helpers for auth caching and retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in ##openstack-sdks on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=UnifiedSDK&diff=41623UnifiedSDK2014-02-07T17:49:38Z<p>Jesse Noller: Jesse Noller moved page UnifiedSDK to PythonOpenStackSDK: Naming things</p>
<hr />
<div>#REDIRECT [[PythonOpenStackSDK]]</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=41536SDK-Development/PythonOpenStackSDK2014-02-06T17:58:30Z<p>Jesse Noller: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances, it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation, it becomes very easy to derive a unified CLI, such as openstackclient, or specialized per-service CLI tools. However, it is important that the definition of SDK -- the compilation of the APIs and developer functions -- and CLI tools stay separate as it is easy to conflate the idea of "clients," which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients and use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
'''What's in an SDK?''':<br />
<br />
An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:<br />
* Documentation aimed at users consuming the SDK and system.<br />
* Clear examples of usage, including functioning, executable examples.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators or Developers. These are developers looking to '''consume''' a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds. The commands they use should follow a consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/stackforge/python-openstacksdk<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints || https://launchpad.net/unifiedsdk<br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* Verified mocks/stubs for testing at all layers.<br />
* python-requests based REST client (built as "requests first").<br />
* Minimize external dependencies. This includes inter-openstack-project dependencies.<br />
* Do not dictate a concurrency paradigm. Ensure that the design is sound, but allow users to use gevent/threads/asyncio/etc.<br />
* Ensure thread safety. Avoid the use of and modification of global objects.<br />
* Documentation must be assumption free. The target audience are not intimately familiar with the internals or designs of the services exposed by the SDK. <br />
* Jargon free. APIs should go by program names ("compute", "storage", "messaging"), rather than the project names ("nova", "swift", "marconi") to ensure the library is accessible to people without significant OpenStack familiarity.<br />
* Vendors / Hosts of OpenStack Clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations, and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator". The client (Layer 4) code for keystoneclient might be in openstack.api.auth, but it would be able to be as advanced as it would like from an api standpoint, and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools/distutils "[http://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins entry points]" for plugins or vendor additions. Doing so prevents single binary builds on Windows and other platforms.<br />
* Take code and ideas from the other python-* clients, but ''do not wrap them'' as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK. The SDK can have helpers for auth caching and retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in ##openstack-sdks on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=41535SDK-Development/PythonOpenStackSDK2014-02-06T17:56:47Z<p>Jesse Noller: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances, it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation, it becomes very easy to derive a unified CLI, such as openstackclient, or specialized per-service CLI tools. However, it is important that the definition of SDK -- the compilation of the APIs and developer functions -- and CLI tools stay separate as it is easy to conflate the idea of "clients," which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients and use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
'''What's in an SDK?''':<br />
<br />
An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:<br />
* Documentation aimed at users consuming the SDK and system.<br />
* Clear examples of usage, including functioning, executable examples.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators or Developers. These are developers looking to '''consume''' a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds. The commands they use should follow a consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/stackforge/python-openstacksdk<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints || https://launchpad.net/unifiedsdk<br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* Verified mocks/stubs for testing at all layers.<br />
* python-requests based REST client (built as "requests first").<br />
* Minimize external dependencies. This includes inter-openstack-project dependencies.<br />
* Do not dictate a concurrency paradigm. Ensure that the design is sound, but allow users to use gevent/threads/asyncio/etc.<br />
* Ensure thread safety. Avoid the use of and modification of global objects.<br />
* Documentation must be assumption free. The target audience are not intimately familiar with the internals or designs of the services exposed by the SDK. <br />
* Jargon free. APIs should go by program names ("compute", "storage", "messaging"), rather than the project names ("nova", "swift", "marconi") to ensure the library is accessible to people without significant OpenStack familiarity.<br />
* Vendors / Hosts of OpenStack but should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations, and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator". The client (Layer 4) code for keystoneclient might be in openstack.api.auth, but it would be able to be as advanced as it would like from an api standpoint, and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools/distutils "[http://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins entry points]" for plugins or vendor additions. Doing so prevents single binary builds on Windows and other platforms.<br />
* Take code and ideas from the other python-* clients, but ''do not wrap them'' as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK. The SDK can have helpers for auth caching and retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in ##openstack-sdks on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=41365SDK-Development/PythonOpenStackSDK2014-02-05T16:40:55Z<p>Jesse Noller: /* IRC */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances, it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation, it becomes very easy to derive a unified CLI, such as openstackclient, or specialized per-service CLI tools. However, it is important that the definition of SDK -- the compilation of the APIs and developer functions -- and CLI tools stay separate as it is easy to conflate the idea of "clients," which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients and use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
'''What's in an SDK?''':<br />
<br />
An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:<br />
* Documentation aimed at users consuming the SDK and system.<br />
* Clear examples of usage, including functioning, executable examples.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators or Developers. These are developers looking to '''consume''' a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds. The commands they use should follow a consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/stackforge/python-openstacksdk<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints || https://launchpad.net/unifiedsdk<br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* Verified mocks/stubs for testing at all layers.<br />
* python-requests based REST client (built as "requests first").<br />
* Minimize external dependencies. This includes inter-openstack-project dependencies.<br />
* Do not dictate a concurrency paradigm. Ensure that the design is sound, but allow users to use gevent/threads/asyncio/etc.<br />
* Ensure thread safety. Avoid the use of and modification of global objects.<br />
* Documentation must be assumption free. The target audience are not intimately familiar with the internals or designs of the services exposed by the SDK. <br />
* Vendors / Hosts of OpenStack clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations, and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator". The client (Layer 4) code for keystoneclient might be in openstack.api.auth, but it would be able to be as advanced as it would like from an api standpoint, and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools/distutils "[http://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins entry points]" for plugins or vendor additions. Doing so prevents single binary builds on Windows and other platforms.<br />
* Take code and ideas from the other python-* clients, but ''do not wrap them'' as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK. The SDK can have helpers for auth caching and retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in ##openstack-sdks on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=41356SDK-Development/PythonOpenStackSDK2014-02-05T15:53:06Z<p>Jesse Noller: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances, it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation, it becomes very easy to derive a unified CLI, such as openstackclient, or specialized per-service CLI tools. However, it is important that the definition of SDK -- the compilation of the APIs and developer functions -- and CLI tools stay separate as it is easy to conflate the idea of "clients," which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients and use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
'''What's in an SDK?''':<br />
<br />
An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:<br />
* Documentation aimed at users consuming the SDK and system.<br />
* Clear examples of usage, including functioning, executable examples.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators or Developers. These are developers looking to '''consume''' a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds. The commands they use should follow a consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/stackforge/python-openstacksdk<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints || https://launchpad.net/unifiedsdk<br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* Verified mocks/stubs for testing at all layers.<br />
* python-requests based REST client (built as "requests first").<br />
* Minimize external dependencies. This includes inter-openstack-project dependencies.<br />
* Do not dictate a concurrency paradigm. Ensure that the design is sound, but allow users to use gevent/threads/asyncio/etc.<br />
* Ensure thread safety. Avoid the use of and modification of global objects.<br />
* Documentation must be assumption free. The target audience are not intimately familiar with the internals or designs of the services exposed by the SDK. <br />
* Vendors / Hosts of OpenStack clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations, and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator". The client (Layer 4) code for keystoneclient might be in openstack.api.auth, but it would be able to be as advanced as it would like from an api standpoint, and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools/distutils "[http://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins entry points]" for plugins or vendor additions. Doing so prevents single binary builds on Windows and other platforms.<br />
* Take code and ideas from the other python-* clients, but ''do not wrap them'' as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK. The SDK can have helpers for auth caching and retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40487SDK-Development/PythonOpenStackSDK2014-01-24T22:09:34Z<p>Jesse Noller: /* Summary */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
'''What's in a SDK?''':<br />
<br />
An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, but it additionally includes:<br />
* Documentation aimed at users consuming the SDK and system.<br />
* Clear examples of usage, including functioning, executable examples.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/jnoller/openstacksdk (temporary)<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* verified mocks/stubs for testing (all layers)<br />
* python-requests based REST client (built as "requests first")<br />
* minimize external dependencies (this includes inter-openstack-project dependencies)<br />
* do not dictate a concurrency paradigm: ensure the design is sound but allow users to use gevent/threads/asyncio/etc<br />
* ensure thread safety: avoid global objects and modification of global objects<br />
* Documentation must be assumption free.<br />
* Vendors / Hosts of OpenStack clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator": "the client (Layer 4) code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools / disutils / etc entrypoints for plugs and vendor additions. This prevents single binary builds on windows and other platforms.<br />
* Take code, and ideas from the other python-* clients, but do not wrap them as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK: the SDK can have helpers for auth caching, auth retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40486SDK-Development/PythonOpenStackSDK2014-01-24T21:59:39Z<p>Jesse Noller: /* Non-Requirements ("Things Not To Do") */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/jnoller/openstacksdk (temporary)<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* verified mocks/stubs for testing (all layers)<br />
* python-requests based REST client (built as "requests first")<br />
* minimize external dependencies (this includes inter-openstack-project dependencies)<br />
* do not dictate a concurrency paradigm: ensure the design is sound but allow users to use gevent/threads/asyncio/etc<br />
* ensure thread safety: avoid global objects and modification of global objects<br />
* Documentation must be assumption free.<br />
* Vendors / Hosts of OpenStack clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator": "the client (Layer 4) code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools / disutils / etc entrypoints for plugs and vendor additions. This prevents single binary builds on windows and other platforms.<br />
* Take code, and ideas from the other python-* clients, but do not wrap them as openstackclient (currently) does.<br />
* Do not mix the CLI implementation with the SDK: the SDK can have helpers for auth caching, auth retries, etc, but should not get involved in the CLI implementation aspect.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40485SDK-Development/PythonOpenStackSDK2014-01-24T21:58:31Z<p>Jesse Noller: /* Non-Requirements ("Things Not To Do") */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/jnoller/openstacksdk (temporary)<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* verified mocks/stubs for testing (all layers)<br />
* python-requests based REST client (built as "requests first")<br />
* minimize external dependencies (this includes inter-openstack-project dependencies)<br />
* do not dictate a concurrency paradigm: ensure the design is sound but allow users to use gevent/threads/asyncio/etc<br />
* ensure thread safety: avoid global objects and modification of global objects<br />
* Documentation must be assumption free.<br />
* Vendors / Hosts of OpenStack clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator": "the client (Layer 4) code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools / disutils / etc entrypoints for plugs and vendor additions. This prevents single binary builds on windows and other platforms.<br />
* Take code, and ideas from the other python-* clients, but do not wrap them as openstackclient (currently) does.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40484SDK-Development/PythonOpenStackSDK2014-01-24T21:57:35Z<p>Jesse Noller: /* Requirements */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/jnoller/openstacksdk (temporary)<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* verified mocks/stubs for testing (all layers)<br />
* python-requests based REST client (built as "requests first")<br />
* minimize external dependencies (this includes inter-openstack-project dependencies)<br />
* do not dictate a concurrency paradigm: ensure the design is sound but allow users to use gevent/threads/asyncio/etc<br />
* ensure thread safety: avoid global objects and modification of global objects<br />
* Documentation must be assumption free.<br />
* Vendors / Hosts of OpenStack clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations and to easily package and ship without requiring a complete fork of the codebase. <br />
* No "Least Common Denominator": "the client (Layer 4) code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools / disutils / etc entrypoints for plugs and vendor additions. This prevents single binary builds on windows and other platforms.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40482SDK-Development/PythonOpenStackSDK2014-01-24T21:53:24Z<p>Jesse Noller: /* Non-Requirements ("Things Not To Do") */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/jnoller/openstacksdk (temporary)<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* verified mocks/stubs for testing (all layers)<br />
* python-requests based REST client (built as "requests first")<br />
* minimize external dependencies (this includes inter-openstack-project dependencies)<br />
* do not dictate a concurrency paradigm: ensure the design is sound but allow users to use gevent/threads/asyncio/etc<br />
* ensure thread safety: avoid global objects and modification of global objects<br />
* Documentation must be assumption free.<br />
* No "Least Common Denominator": "the client (Layer 4) code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
* Do not use setuptools / disutils / etc entrypoints for plugs and vendor additions. This prevents single binary builds on windows and other platforms.<br />
:<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40481SDK-Development/PythonOpenStackSDK2014-01-24T21:52:30Z<p>Jesse Noller: /* Requirements */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/jnoller/openstacksdk (temporary)<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* verified mocks/stubs for testing (all layers)<br />
* python-requests based REST client (built as "requests first")<br />
* minimize external dependencies (this includes inter-openstack-project dependencies)<br />
* do not dictate a concurrency paradigm: ensure the design is sound but allow users to use gevent/threads/asyncio/etc<br />
* ensure thread safety: avoid global objects and modification of global objects<br />
* Documentation must be assumption free.<br />
* No "Least Common Denominator": "the client (Layer 4) code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40480SDK-Development/PythonOpenStackSDK2014-01-24T21:46:52Z<p>Jesse Noller: /* Resources */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code || https://github.com/jnoller/openstacksdk (temporary)<br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* verified mocks/stubs for testing (all layers)<br />
* python-requests based REST client (built as "requests first")<br />
* Documentation must be assumption free.<br />
* No "Least Common Denominator": "the client (Layer 4) code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40479SDK-Development/PythonOpenStackSDK2014-01-24T21:42:47Z<p>Jesse Noller: /* Resources */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code <br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|-<br />
| Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes<br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* verified mocks/stubs for testing (all layers)<br />
* python-requests based REST client (built as "requests first")<br />
* Documentation must be assumption free.<br />
* No "Least Common Denominator": "the client (Layer 4) code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40478SDK-Development/PythonOpenStackSDK2014-01-24T21:42:01Z<p>Jesse Noller: /* Requirements */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code <br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* verified mocks/stubs for testing (all layers)<br />
* python-requests based REST client (built as "requests first")<br />
* Documentation must be assumption free.<br />
* No "Least Common Denominator": "the client (Layer 4) code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40475SDK-Development/PythonOpenStackSDK2014-01-24T21:37:18Z<p>Jesse Noller: /* Requirements */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code <br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
* Additionally: [https://etherpad.openstack.org/p/unified-sdk-notes see etherpad notes]<br />
:<br />
<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40471SDK-Development/PythonOpenStackSDK2014-01-24T20:01:35Z<p>Jesse Noller: /* Resources */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code <br />
|-<br />
| Bug tracker || https://launchpad.net/unifiedsdk<br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
:<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40470SDK-Development/PythonOpenStackSDK2014-01-24T19:53:49Z<p>Jesse Noller: /* Audience */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* '''Command line consumers''': These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code <br />
|-<br />
| Bug tracker <br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
:<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40469SDK-Development/PythonOpenStackSDK2014-01-24T19:53:11Z<p>Jesse Noller: /* Meetings */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* Application Developers: Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* Command line consumers: These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code <br />
|-<br />
| Bug tracker <br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
:<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
* The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]<br />
* [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40468SDK-Development/PythonOpenStackSDK2014-01-24T19:47:57Z<p>Jesse Noller: /* Resources */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* Application Developers: Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* Command line consumers: These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| Source code <br />
|-<br />
| Bug tracker <br />
|-<br />
| Blueprints <br />
|-<br />
| Developer doc <br />
|}<br />
:<br />
<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
:<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40467SDK-Development/PythonOpenStackSDK2014-01-24T19:46:12Z<p>Jesse Noller: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances it becomes increasingly difficult to consume OpenStack clouds.<br />
<br />
The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation it becomes very easy to derive a unified CLI (such as openstackclient) or specialized per-service CLI tools. However, it is important that the definition of SDK (the compilation of the APIs and developer functions) and CLI tools stay separate as it is easy to conflate the idea of "clients" which is the state we have today. <br />
<br />
Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients to use this as their logical backends.<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* Application Developers: Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* Command line consumers: These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
:<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
:<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Nollerhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=40397SDK-Development/PythonOpenStackSDK2014-01-23T16:58:54Z<p>Jesse Noller: Created page with "__TOC__ = Summary = This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack pytho..."</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Developement Toolkit").<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system, they face an uphill battle.<br />
The ''Unified SDK''' is a n<br />
<br />
The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* Application Developers: Application developers are not OpenStack Operators, or Developers - these are developers looking to '''consume''' a feature-rich OpenStack Cloud (multiple services). These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.<br />
* Command line consumers: These are similar to the Application Developers as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds - the commands they use should use consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.<br />
<br />
= Resources =<br />
:<br />
= Project Outline = <br />
:<br />
== Requirements ==<br />
:<br />
== Non-Requirements ("Things Not To Do") ==<br />
:<br />
<br />
<br />
= IRC =<br />
<br />
The developers use IRC in #openstacksdk on freenode for development discussion.<br />
<br />
= Meetings =<br />
:<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.</div>Jesse Noller