https://wiki.openstack.org/w/api.php?action=feedcontributions&user=Brian.curtin&feedformat=atomOpenStack - User contributions [en]2024-03-29T06:22:13ZUser contributionsMediaWiki 1.28.2https://wiki.openstack.org/w/index.php?title=Meetings/OpenStackClient&diff=101265Meetings/OpenStackClient2016-01-14T19:03:17Z<p>Brian.curtin: /* Regular attendees */</p>
<hr />
<div>= Weekly OpenStackClient Team Meeting =<br />
<br />
The OpenStackClient Team holds public weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code> on Thursdays at 19:00 UTC ([http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=0&sec=0 Timezone Help]).<br /><br />
Everyone who uses an OpenStack command-line interface is invited to attend.<br />
<br />
== Regular attendees ==<br />
<br />
Add yourself to this list to be pinged prior to each meeting:<br />
<br />
dtroyer, dhellmann, stevemar, terrylhowe, lhcheng, dstanek, MeganR<br />
<br />
The meeting minutes of can be found here: [http://eavesdrop.openstack.org/meetings/openstackclient meeting minutes on eavesdrop]<br />
<br />
== Next Meeting Agenda ==<br />
<br />
''Note: Not all meetings had an advance agenda.''<br />
<br />
=== 24 Sep 2015 ===<br />
* Remaining Image work<br />
* SDK Integration<br />
** terrylhowe's series for Network: https://review.openstack.org/#/c/138745/<br />
** dtroyer's common refactor, beginning Image: https://review.openstack.org/#/c/227037/<br />
** Version discussion for dependency addition<br />
*** Recent ML discussion: http://lists.openstack.org/pipermail/openstack-dev/2015-September/075107.html<br />
* Bugs and Reviews<br />
* Open Discussion<br />
<br />
=== 6 August 2015 ===<br />
* Discussed making 1.6.0 release<br />
<br />
=== 16 July 2015 ===<br />
* Make a consistent functional test, identity vs others, pretty table vs not<br />
<br />
=== 04 Jun 2015 ===<br />
* Open actions<br />
** https://bugs.launchpad.net/python-openstackclient/+bug/1405562<br />
*** Amey Bhide is making good progress on this<br />
** https://bugs.launchpad.net/python-openstackclient/+bug/1459519<br />
*** Terry has https://review.openstack.org/#/c/186394/ in cliff (now approved)<br />
** Plugins - osc-plugin to cookiecutter<br />
*** dtroyer: no movement<br />
* Releases<br />
** 1.4.0 release any minute now, was going to be a point release but the EC2 credentials fixes included adding v3 commands<br />
** Still waiting on requirements update for KSC, in gate queue: https://review.openstack.org/#/c/188078/ (now merged)<br />
* Blueprint Review<br />
* Bugs/Reviews<br />
* Open discussion<br />
<br />
=== 28 May 2015 ===<br />
* Open actions<br />
* Blueprint Review<br />
* Bugs/Reviews<br />
* Open discussion<br />
<br />
=== 07 May 2015 ===<br />
* Open actions<br />
* Summit planning<br />
** [https://etherpad.openstack.org/p/osc-liberty-summit-planning Etherpad]<br />
* Bugs/Reviews<br />
* Open discussion<br />
<br />
=== 30 Apr 2015 ===<br />
* Open actions<br />
* Release planning<br />
** 1.2.0 release today - [https://launchpad.net/python-openstackclient/+milestone/m10 milestone m10]<br />
* Summit planning<br />
** [https://etherpad.openstack.org/p/osc-liberty-summit-planning Etherpad]<br />
* Bugs/Reviews<br />
* Open discussion<br />
<br />
=== 23 Apr 2015 ===<br />
* Open actions<br />
* Release planning<br />
** 1.1.0 released on 21Apr2015 - [https://launchpad.net/python-openstackclient/+milestone/m9 milestone m9]<br />
** follow-up soon with 1.1.1 to clean up release notes and get in a few more bug fixes - [https://launchpad.net/python-openstackclient/+milestone/m10 nilestone m10]<br />
* Summit planning<br />
** [https://etherpad.openstack.org/p/osc-liberty-summit-planning Etherpad]<br />
* Bugs<br />
** [https://bugs.launchpad.net/python-openstackclient/+bug/1443089 1443089] - image list displays a maximum of 25 images<br />
*** is this fixed by [https://review.openstack.org/#/c/173420/ review 173420]?<br />
* Open discussion<br />
<br />
=== 16 Apr 2015 ===<br />
* Open actions<br />
* Summit planning<br />
* Reviews<br />
** [https://review.openstack.org/#/c/164091/ 164091] - session timing<br />
* Bugs<br />
** [https://bugs.launchpad.net/python-openstackclient/+bug/1406470 1406470] - track backwards incompatible changes<br />
*** Suggested to use a commit message tag<br />
** [https://bugs.launchpad.net/python-openstackclient/+bug/1409218 1409218] - condense credentials (ec2, v3, compute)<br />
*** still m9?<br />
** [https://bugs.launchpad.net/python-openstackclient/+bug/1435962 1435962] - add support for keystone service providers<br />
*** [https://review.openstack.org/#/c/165755/ review 165755]<br />
*** has this been released in KSC yet?<br />
** [https://bugs.launchpad.net/python-openstackclient/+bug/1443089 1443089] - image list displays a maximum of 25 images<br />
*** recent discussion on how to handle:<br />
**** add --limit (or other option)<br />
**** just do the pagination to return all<br />
**** both of the above<br />
** [https://bugs.launchpad.net/python-openstackclient/+bug/1431649 1431649] - openstackclient is really slow<br />
*** static import timing done with boris-42's profimp, addressed some in [https://review.openstack.org/173098 review 173098]<br />
* Blueprints<br />
** New: [https://blueprints.launchpad.net/python-openstackclient/+spec/waitcommand wait command]<br />
* Open discussion<br />
<br />
=== 09 Apr 2015 ===<br />
* Open actions<br />
* Open discussion<br />
<br />
=== 02 Apr 2015 ===<br />
* Open actions<br />
** stevemar: BP to move fakes to fixtures for plugin testing<br />
** dtroyer: BP to generalize JSON input<br />
** dtroyer: add timing info to https://bugs.launchpad.net/python-openstackclient/+bug/1431649<br />
** dtroyer: ML tag - OSC is registered<br />
* Summit space<br />
** what do we want/need? I asked ttx for one fishbowl and one workroom slot each, do we need them both?<br />
*** https://wiki.openstack.org/wiki/Summit/Planning<br />
* Review Review<br />
** --os-cloud (https://review.openstack.org/129795)<br />
* Bug Review<br />
* Other repos<br />
** os-client-config renamed last week<br />
* Open Discussion<br />
<br />
=== 19 Mar 2015 ===<br />
* Open actions<br />
** dtroyer: contributors list<br />
* Public test interfaces<br />
** Question about plugins using fakes from openstackclient.tests, public status undefined before now<br />
* Bug Review<br />
** Priorities for next release<br />
* Other repos<br />
** ACL changes in Gerrit made for cliff and os-client-config<br />
* Open discussion<br />
<br />
=== 12 Mar 2015 ===<br />
* Open actions<br />
** Project proposal submitted: https://review.openstack.org/#/c/161885/<br />
* Release plans<br />
* Bug Review<br />
* Other repos<br />
** cliff<br />
** os-client-config<br />
* Open discussion<br />
<br />
=== 05 Mar 2015 ===<br />
* Re-confirm meeting time from Doodle results (http://doodle.com/4uy5w2ehn8y2eayh)<br />
* Open actions<br />
** dhellmann set up doodle for meeting times (done)<br />
** dtroyer to add cliff repo ownership to project proposal (done)<br />
** dhellmann discuss cliff ownership change with oslo team (done)<br />
* Project status<br />
** Project requirement evaluation: [https://etherpad.openstack.org/p/osc-project etherpad]<br />
** cliff repo ownership resolution<br />
** Also add os-client-config repo<br />
* Release schedule<br />
** Possibly early next week (09 Mar 2015)<br />
** propose 1.1.0 as new --os-cloud support adds interesting new capability<br />
* Bug review<br />
** Evaluate what can be completed before release and what should be deferred<br />
* Open discussion<br />
<br />
=== 26 Feb 2015 ===<br />
* Confirm meeting time<br />
* Project status<br />
** Project requirement evaluation: [https://etherpad.openstack.org/p/osc-project etherpad]<br />
** Should this project also own the cliff repo?<br />
* Release schedule<br />
* Bug review<br />
* Open discussion</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=96284Meetings/PythonOpenStackSDK2015-11-10T18:51:40Z<p>Brian.curtin: /* Agenda */</p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* #topic 1.0 Gerrit pruning - figure out what we actually need to keep<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Stackforge_Namespace_Retirement&diff=89029Stackforge Namespace Retirement2015-08-27T19:54:23Z<p>Brian.curtin: </p>
<hr />
<div>=== Background ===<br />
<br />
The stackforge/ git namespace is being retired, and active projects are being moved to the openstack/ namespace. See this mailing list post for [http://lists.openstack.org/pipermail/openstack-dev/2015-August/071816.html full background]. These changes are scheduled to occur on October 17, 2015.<br />
<br />
There are two lists below, one for active projects that should be moved, and a second for inactive projects that should become read-only. Please update them to add your project to the correct list.<br />
<br />
=== Active Projects to Move ===<br />
Active stackforge projects that wish to move into the openstack/ namespace should be added to this list. Projects in this list will be automatically moved by the Infrastructure team to openstack/ on October 17. Please note that no other renames can happen during this move -- projects will strictly be moved from stackforge/ to openstack/ with their existing names. <br />
<br />
* aeromancer<br />
* python-openstacksdk<br />
<br />
=== Inactive Projects to Retire ===<br />
Inactive projects that should be retired should be added to this list. These projects will have a commit merged removing their content and replacing it with a message indicating the project is no longer maintained and will become read-only in Gerrit.<br />
<br />
* MRaaS</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=88789Meetings/PythonOpenStackSDK2015-08-25T18:24:13Z<p>Brian.curtin: /* Agenda */</p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic Image Import<br />
** #link https://review.openstack.org/#/c/199318/<br />
** discuss function combination and naming<br />
* #topic The Compute User Guide<br />
** #link https://review.openstack.org/#/c/215823/<br />
** discuss the style and improvements<br />
** #link http://docs-draft.openstack.org/23/215823/2/check/gate-python-openstacksdk-docs/8d5d180//doc/build/html/users/guides/connect.html<br />
** #link http://docs-draft.openstack.org/23/215823/2/check/gate-python-openstacksdk-docs/8d5d180//doc/build/html/users/guides/compute.html<br />
* #topic path_args direction<br />
* Current reviews, next plans for release<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=88238Meetings/PythonOpenStackSDK2015-08-18T18:51:47Z<p>Brian.curtin: </p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic Release 0.6.2<br />
** fixed object_store.create_object, renamed extensions to plugins<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1474478 isn't fixed and oddly seems complicated, would rather release now without it<br />
* Current reviews, next plans for release<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=88237Meetings/PythonOpenStackSDK2015-08-18T18:43:33Z<p>Brian.curtin: </p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic Release 0.6.2<br />
** fixed object_store.create_object, renamed extensions to plugins<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1474478 isn't fixed and oddly seems complicated, would rather release now without it<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=87764Meetings/PythonOpenStackSDK2015-08-11T18:47:04Z<p>Brian.curtin: </p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic Plans for next release, likely 0.6.2<br />
** Create should update all attributes returned in response (https://bugs.launchpad.net/python-openstacksdk/+bug/1474478)<br />
** object_store.create_object not working with container instances (not converting instance to ID)<br />
* #topic Plans for 0.7 release?<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=86446Meetings/PythonOpenStackSDK2015-07-21T18:40:13Z<p>Brian.curtin: </p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic big tent application<br />
** #link https://etherpad.openstack.org/p/python-openstacksdk-big-tent-proposal<br />
* #topic release<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=85844Meetings/PythonOpenStackSDK2015-07-13T22:21:42Z<p>Brian.curtin: </p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic big tent application<br />
** #link https://etherpad.openstack.org/p/python-openstacksdk-big-tent-proposal<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=84828Meetings/PythonOpenStackSDK2015-06-30T15:20:55Z<p>Brian.curtin: </p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic Proposal: moratorium on new services/resources being added until after 1.0<br />
** In order to be able to release, we're going to need to put a halt to adding support for new operations while we catch up on functional tests, documentation, and the other larger initiatives we need to complete.<br />
* #topic second meeting<br />
** Qiming and the rest of the Senlin team is interested in coming to our meetings, but they're between 11-13 hours difference. I caught their Senlin team meeting from 0800-0900 US/Central time. <br />
** As the project grows, we're going to need to reach more people anyway, so we're going to have to have two meetings at some point - not everyone can or has to make both meetings, but we'll just need to make sure everyone is aware of what's going on, and that decisions are appropriately handled inside and outside of meetings due to the increasingly distributed nature of the contributors. <br />
* #topic find<br />
** There are a lot of open bugs regarding find. Let's see if we can nail down a path forward for find.<br />
* #topic reauth on token timeout<br />
** Does the SDK automatically reauth on token timeout? If not, this will be essential for 1.0. If we don't have it, the SDK can't be used in long lived processes (e.g. web apps, daemons, etc.). These are essential use cases.<br />
* #topic registering error handlers<br />
** Related to reauth. Is it possible to register an error handler in the SDK? The best way to handle reauth is to register an error handler for 401s and let it automatically handle the reauth for users. If we can register an error handler for that, might as well open up the capability to users.<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=84520Meetings/PythonOpenStackSDK2015-06-29T16:57:45Z<p>Brian.curtin: </p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic Proposal: moratorium on new services/resources being added until after 1.0<br />
** In order to be able to release, we're going to need to put a halt to adding support for new operations while we catch up on functional tests, documentation, and the other larger initiatives we need to complete.<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=84102Meetings/PythonOpenStackSDK2015-06-23T16:03:28Z<p>Brian.curtin: </p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic Add Heat resource support<br />
** #link https://review.openstack.org/#/c/181063/<br />
* #topic marking APIs as Beta in the SDK<br />
* #topic functional testing of "non-core" service<br />
** can openstack.tests.functional.base.requires_service be changed to wrap an entire test class?<br />
* #topic Resource.find<br />
** #link https://review.openstack.org/#/c/193728/<br />
* Add your topic here<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=83586Meetings/PythonOpenStackSDK2015-06-16T18:42:29Z<p>Brian.curtin: </p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic Expose 'get_x_openstack_request_id' method in all OpenStack clients api bindings <br />
** #link https://blueprints.launchpad.net/python-openstacksdk/+spec/expose-get-x-openstack-request-id<br />
** tpatil will attend the meeting to discuss this proposal<br />
* #topic roadmap<br />
** Etherpad started here: https://etherpad.openstack.org/p/sdk_road_to_1.0<br />
*** listing topics for now, will prioritize and create bugs/blueprints/whatever based on it<br />
** become an official project<br />
*** get into the openstack namespace in git<br />
*** add sdk to openstack projects list, example #link https://review.openstack.org/#/c/190949/<br />
*** bring it up at the cross-project meeting<br />
*** talk to the TC<br />
*** what else? <br />
* Add your topic here<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=83585Meetings/PythonOpenStackSDK2015-06-16T18:33:01Z<p>Brian.curtin: /* Agenda */</p>
<hr />
<div>= Weekly Python-OpenStackSDK Team Meeting =<br />
<br />
If you're interested in the [[PythonOpenStackSDK]], we will be holding public meetings weekly to discuss its ongoing development. Please feel free to add items to the agenda below with your IRC nickname and we'll cover them. The meeting will last 1 hour.<br />
<br />
== Meetings ==<br />
<br />
* Meeting Time: Weekly, Tuesday at 19:00 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code><br />
* MeetBot Manual http://meetbot.debian.net/Manual.html<br />
<br />
== Agenda ==<br />
<br />
* #startmeeting python-openstacksdk<br />
* Roll Call<br />
* #topic Expose 'get_x_openstack_request_id' method in all OpenStack clients api bindings <br />
** #link https://blueprints.launchpad.net/python-openstacksdk/+spec/expose-get-x-openstack-request-id<br />
** tpatil will attend the meeting to discuss this proposal<br />
* #topic roadmap<br />
** Etherpad started here: https://etherpad.openstack.org/p/sdk_road_to_1.0<br />
** more user/contributor docs<br />
** more functional tests<br />
** solidify plugin architecture<br />
** become an official project<br />
*** get into the openstack namespace in git<br />
*** add sdk to openstack projects list, example #link https://review.openstack.org/#/c/190949/<br />
*** bring it up at the cross-project meeting<br />
*** talk to the TC<br />
*** what else? <br />
* Add your topic here<br />
<br />
== Previous Meetings ==<br />
<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 Meeting Archive]</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=81027Meetings/PythonOpenStackSDK2015-05-12T18:23:59Z<p>Brian.curtin: /* Agenda for 2015-04-28 1900 UTC */</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 on Tuesdays. 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 />
== Agenda for 2015-05-12 1900 UTC ==<br />
* Roll Call<br />
* get/list/find - what are we doing?<br />
* What else do we ''need'' to complete this week?<br />
<br />
== Agenda for 2015-04-28 1900 UTC ==<br />
* Roll Call<br />
* get/list/find - what are we doing?<br />
** https://review.openstack.org/178302 and https://review.openstack.org/164351 combine to negate the need for find as far as I know<br />
** on get, should get implicitly try by name if it's not an ID, or do we want people to be explicit? Or can we have the opportunity to be forgiving with what we're sent while also giving the ability to be specific?<br />
<br />
== Agenda for 2015-04-21 1900 UTC ==<br />
* Roll Call<br />
* #topic wait_for_status<br />
** #link https://review.openstack.org/#/c/174980/<br />
* #topic common get method<br />
** #link https://review.openstack.org/#/c/164351/<br />
<br />
== Agenda for 2015-03-31 1900 UTC ==<br />
* Roll Call<br />
* #topic Functional Testing<br />
** #link https://review.openstack.org/#/c/169405/ - Moving unit tests<br />
** How exactly do we want to accomplish this?<br />
* #topic Removing httpretty<br />
** #link https://review.openstack.org/#/c/164837/ -- remove httpretty from Transport tests<br />
** After that, the only usage should be in object_store tests, but those will change as the new APIs are applied so no need to replace them right now.<br />
* #topic Common API changes<br />
** Any "Common <action> method" reviews are ready to be reviewed<br />
** Update under way, working on some intermediate work to make sure the dirty list is properly handled from Resource.update_attrs<br />
<br />
== Agenda for 2015-03-17 1900 UTC ==<br />
* Roll Call<br />
* #topic API guidelines<br />
** #link https://etherpad.openstack.org/p/proxy_api_guidelines<br />
** #link https://review.openstack.org/#/c/164310/ delete method<br />
* #topic functional testing<br />
** #link https://review.openstack.org/#/c/162210/<br />
* #topic request/response logging<br />
** #link https://review.openstack.org/#/c/162761/<br />
<br />
== Agenda for 2015-03-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/162782/<br />
* https://review.openstack.org/#/c/162761/<br />
* PUT/POST differences/issues in our create support<br />
* Discuss API Guidelines https://etherpad.openstack.org/p/proxy_api_guidelines<br />
<br />
== Agenda for 2015-03-01 1900 UTC ==<br />
* Roll Call<br />
* conn.update vs conn.compute.update_server - https://review.openstack.org/#/c/160635/<br />
* list filtering WIP - does this make sense? https://review.openstack.org/#/c/160138/<br />
* need to implement CaseInsensitiveDict for header dict<br />
* identity: use set() for valid_options https://review.openstack.org/#/c/160840/<br />
<br />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=81026Meetings/PythonOpenStackSDK2015-05-12T18:23:42Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-04-28 1900 UTC ==<br />
* Roll Call<br />
* get/list/find - what are we doing?<br />
* What else do we ''need'' to complete this week?<br />
<br />
== Agenda for 2015-04-28 1900 UTC ==<br />
* Roll Call<br />
* get/list/find - what are we doing?<br />
** https://review.openstack.org/178302 and https://review.openstack.org/164351 combine to negate the need for find as far as I know<br />
** on get, should get implicitly try by name if it's not an ID, or do we want people to be explicit? Or can we have the opportunity to be forgiving with what we're sent while also giving the ability to be specific?<br />
<br />
== Agenda for 2015-04-21 1900 UTC ==<br />
* Roll Call<br />
* #topic wait_for_status<br />
** #link https://review.openstack.org/#/c/174980/<br />
* #topic common get method<br />
** #link https://review.openstack.org/#/c/164351/<br />
<br />
== Agenda for 2015-03-31 1900 UTC ==<br />
* Roll Call<br />
* #topic Functional Testing<br />
** #link https://review.openstack.org/#/c/169405/ - Moving unit tests<br />
** How exactly do we want to accomplish this?<br />
* #topic Removing httpretty<br />
** #link https://review.openstack.org/#/c/164837/ -- remove httpretty from Transport tests<br />
** After that, the only usage should be in object_store tests, but those will change as the new APIs are applied so no need to replace them right now.<br />
* #topic Common API changes<br />
** Any "Common <action> method" reviews are ready to be reviewed<br />
** Update under way, working on some intermediate work to make sure the dirty list is properly handled from Resource.update_attrs<br />
<br />
== Agenda for 2015-03-17 1900 UTC ==<br />
* Roll Call<br />
* #topic API guidelines<br />
** #link https://etherpad.openstack.org/p/proxy_api_guidelines<br />
** #link https://review.openstack.org/#/c/164310/ delete method<br />
* #topic functional testing<br />
** #link https://review.openstack.org/#/c/162210/<br />
* #topic request/response logging<br />
** #link https://review.openstack.org/#/c/162761/<br />
<br />
== Agenda for 2015-03-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/162782/<br />
* https://review.openstack.org/#/c/162761/<br />
* PUT/POST differences/issues in our create support<br />
* Discuss API Guidelines https://etherpad.openstack.org/p/proxy_api_guidelines<br />
<br />
== Agenda for 2015-03-01 1900 UTC ==<br />
* Roll Call<br />
* conn.update vs conn.compute.update_server - https://review.openstack.org/#/c/160635/<br />
* list filtering WIP - does this make sense? https://review.openstack.org/#/c/160138/<br />
* need to implement CaseInsensitiveDict for header dict<br />
* identity: use set() for valid_options https://review.openstack.org/#/c/160840/<br />
<br />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=78419Meetings/PythonOpenStackSDK2015-04-28T18:26:41Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-04-28 1900 UTC ==<br />
* Roll Call<br />
* get/list/find - what are we doing?<br />
** https://review.openstack.org/178302 and https://review.openstack.org/164351 combine to negate the need for find as far as I know<br />
** on get, should get implicitly try by name if it's not an ID, or do we want people to be explicit? Or can we have the opportunity to be forgiving with what we're sent while also giving the ability to be specific?<br />
<br />
== Agenda for 2015-04-21 1900 UTC ==<br />
* Roll Call<br />
* #topic wait_for_status<br />
** #link https://review.openstack.org/#/c/174980/<br />
* #topic common get method<br />
** #link https://review.openstack.org/#/c/164351/<br />
<br />
== Agenda for 2015-03-31 1900 UTC ==<br />
* Roll Call<br />
* #topic Functional Testing<br />
** #link https://review.openstack.org/#/c/169405/ - Moving unit tests<br />
** How exactly do we want to accomplish this?<br />
* #topic Removing httpretty<br />
** #link https://review.openstack.org/#/c/164837/ -- remove httpretty from Transport tests<br />
** After that, the only usage should be in object_store tests, but those will change as the new APIs are applied so no need to replace them right now.<br />
* #topic Common API changes<br />
** Any "Common <action> method" reviews are ready to be reviewed<br />
** Update under way, working on some intermediate work to make sure the dirty list is properly handled from Resource.update_attrs<br />
<br />
== Agenda for 2015-03-17 1900 UTC ==<br />
* Roll Call<br />
* #topic API guidelines<br />
** #link https://etherpad.openstack.org/p/proxy_api_guidelines<br />
** #link https://review.openstack.org/#/c/164310/ delete method<br />
* #topic functional testing<br />
** #link https://review.openstack.org/#/c/162210/<br />
* #topic request/response logging<br />
** #link https://review.openstack.org/#/c/162761/<br />
<br />
== Agenda for 2015-03-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/162782/<br />
* https://review.openstack.org/#/c/162761/<br />
* PUT/POST differences/issues in our create support<br />
* Discuss API Guidelines https://etherpad.openstack.org/p/proxy_api_guidelines<br />
<br />
== Agenda for 2015-03-01 1900 UTC ==<br />
* Roll Call<br />
* conn.update vs conn.compute.update_server - https://review.openstack.org/#/c/160635/<br />
* list filtering WIP - does this make sense? https://review.openstack.org/#/c/160138/<br />
* need to implement CaseInsensitiveDict for header dict<br />
* identity: use set() for valid_options https://review.openstack.org/#/c/160840/<br />
<br />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=77890Meetings/PythonOpenStackSDK2015-04-20T22:43:58Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-04-21 1900 UTC ==<br />
* Roll Call<br />
* #topic wait_for_status<br />
** #link https://review.openstack.org/#/c/174980/<br />
* #topic common get method<br />
** #link https://review.openstack.org/#/c/164351/<br />
<br />
== Agenda for 2015-03-31 1900 UTC ==<br />
* Roll Call<br />
* #topic Functional Testing<br />
** #link https://review.openstack.org/#/c/169405/ - Moving unit tests<br />
** How exactly do we want to accomplish this?<br />
* #topic Removing httpretty<br />
** #link https://review.openstack.org/#/c/164837/ -- remove httpretty from Transport tests<br />
** After that, the only usage should be in object_store tests, but those will change as the new APIs are applied so no need to replace them right now.<br />
* #topic Common API changes<br />
** Any "Common <action> method" reviews are ready to be reviewed<br />
** Update under way, working on some intermediate work to make sure the dirty list is properly handled from Resource.update_attrs<br />
<br />
== Agenda for 2015-03-17 1900 UTC ==<br />
* Roll Call<br />
* #topic API guidelines<br />
** #link https://etherpad.openstack.org/p/proxy_api_guidelines<br />
** #link https://review.openstack.org/#/c/164310/ delete method<br />
* #topic functional testing<br />
** #link https://review.openstack.org/#/c/162210/<br />
* #topic request/response logging<br />
** #link https://review.openstack.org/#/c/162761/<br />
<br />
== Agenda for 2015-03-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/162782/<br />
* https://review.openstack.org/#/c/162761/<br />
* PUT/POST differences/issues in our create support<br />
* Discuss API Guidelines https://etherpad.openstack.org/p/proxy_api_guidelines<br />
<br />
== Agenda for 2015-03-01 1900 UTC ==<br />
* Roll Call<br />
* conn.update vs conn.compute.update_server - https://review.openstack.org/#/c/160635/<br />
* list filtering WIP - does this make sense? https://review.openstack.org/#/c/160138/<br />
* need to implement CaseInsensitiveDict for header dict<br />
* identity: use set() for valid_options https://review.openstack.org/#/c/160840/<br />
<br />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=76647Meetings/PythonOpenStackSDK2015-03-31T17:46:43Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-03-31 1900 UTC ==<br />
* Roll Call<br />
* #topic Functional Testing<br />
** #link https://review.openstack.org/#/c/169405/ - Moving unit tests<br />
** How exactly do we want to accomplish this?<br />
* #topic Removing httpretty<br />
** #link https://review.openstack.org/#/c/164837/ -- remove httpretty from Transport tests<br />
** After that, the only usage should be in object_store tests, but those will change as the new APIs are applied so no need to replace them right now.<br />
* #topic Common API changes<br />
** Any "Common <action> method" reviews are ready to be reviewed<br />
** Update under way, working on some intermediate work to make sure the dirty list is properly handled from Resource.update_attrs<br />
<br />
== Agenda for 2015-03-17 1900 UTC ==<br />
* Roll Call<br />
* #topic API guidelines<br />
** #link https://etherpad.openstack.org/p/proxy_api_guidelines<br />
** #link https://review.openstack.org/#/c/164310/ delete method<br />
* #topic functional testing<br />
** #link https://review.openstack.org/#/c/162210/<br />
* #topic request/response logging<br />
** #link https://review.openstack.org/#/c/162761/<br />
<br />
== Agenda for 2015-03-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/162782/<br />
* https://review.openstack.org/#/c/162761/<br />
* PUT/POST differences/issues in our create support<br />
* Discuss API Guidelines https://etherpad.openstack.org/p/proxy_api_guidelines<br />
<br />
== Agenda for 2015-03-01 1900 UTC ==<br />
* Roll Call<br />
* conn.update vs conn.compute.update_server - https://review.openstack.org/#/c/160635/<br />
* list filtering WIP - does this make sense? https://review.openstack.org/#/c/160138/<br />
* need to implement CaseInsensitiveDict for header dict<br />
* identity: use set() for valid_options https://review.openstack.org/#/c/160840/<br />
<br />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=75783Meetings/PythonOpenStackSDK2015-03-17T17:48:38Z<p>Brian.curtin: /* Agenda for 2015-03-17 1900 UTC */</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 on Tuesdays. 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 />
== Agenda for 2015-03-17 1900 UTC ==<br />
* Roll Call<br />
* #topic API guidelines<br />
** #link https://etherpad.openstack.org/p/proxy_api_guidelines<br />
** #link https://review.openstack.org/#/c/164310/ delete method<br />
* #topic functional testing<br />
** #link https://review.openstack.org/#/c/162210/<br />
* #topic request/response logging<br />
** #link https://review.openstack.org/#/c/162761/<br />
<br />
== Agenda for 2015-03-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/162782/<br />
* https://review.openstack.org/#/c/162761/<br />
* PUT/POST differences/issues in our create support<br />
* Discuss API Guidelines https://etherpad.openstack.org/p/proxy_api_guidelines<br />
<br />
== Agenda for 2015-03-01 1900 UTC ==<br />
* Roll Call<br />
* conn.update vs conn.compute.update_server - https://review.openstack.org/#/c/160635/<br />
* list filtering WIP - does this make sense? https://review.openstack.org/#/c/160138/<br />
* need to implement CaseInsensitiveDict for header dict<br />
* identity: use set() for valid_options https://review.openstack.org/#/c/160840/<br />
<br />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=75339Meetings/PythonOpenStackSDK2015-03-10T18:59:39Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-03-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/162782/<br />
* https://review.openstack.org/#/c/162761/<br />
* PUT/POST differences/issues in our create support<br />
* Discuss API Guidelines https://etherpad.openstack.org/p/proxy_api_guidelines<br />
<br />
== Agenda for 2015-03-01 1900 UTC ==<br />
* Roll Call<br />
* conn.update vs conn.compute.update_server - https://review.openstack.org/#/c/160635/<br />
* list filtering WIP - does this make sense? https://review.openstack.org/#/c/160138/<br />
* need to implement CaseInsensitiveDict for header dict<br />
* identity: use set() for valid_options https://review.openstack.org/#/c/160840/<br />
<br />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=75338Meetings/PythonOpenStackSDK2015-03-10T18:41:50Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-03-10 1900 UTC ==<br />
* Roll Call<br />
* Discuss API Guidelines https://etherpad.openstack.org/p/proxy_api_guidelines<br />
* PUT/POST differences/issues in our create support<br />
* https://review.openstack.org/#/c/162782/<br />
* https://review.openstack.org/#/c/162761/<br />
<br />
== Agenda for 2015-03-01 1900 UTC ==<br />
* Roll Call<br />
* conn.update vs conn.compute.update_server - https://review.openstack.org/#/c/160635/<br />
* list filtering WIP - does this make sense? https://review.openstack.org/#/c/160138/<br />
* need to implement CaseInsensitiveDict for header dict<br />
* identity: use set() for valid_options https://review.openstack.org/#/c/160840/<br />
<br />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=74876Meetings/PythonOpenStackSDK2015-03-03T18:57:19Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-03-01 1900 UTC ==<br />
* Roll Call<br />
* conn.update vs conn.compute.update_server - https://review.openstack.org/#/c/160635/<br />
* list filtering WIP - does this make sense? https://review.openstack.org/#/c/160138/<br />
* need to implement CaseInsensitiveDict for header dict<br />
* identity: use set() for valid_options https://review.openstack.org/#/c/160840/<br />
<br />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=API_Special_Interest_Group/Current_Design/Query&diff=74336API Special Interest Group/Current Design/Query2015-02-24T20:07:44Z<p>Brian.curtin: </p>
<hr />
<div>https://etherpad.openstack.org/p/find_filters<br />
<br />
compute v2<br />
<br />
/servers?changes-since=<timestamp>&image=<image url>&flavor=<flavor url>&name=<regex>&status=<string>&host=<string>&page_size=<int>&limit=<int>&marker=<id><br />
/servers?changes-since=<timestamp>&image=<image url>&flavor=<flavor url>&name=<regex>&status=<string>&host=<string>&limit=<int>&marker=<id><br />
/flavors?minDisk=<int>&minRam=<int>&limit=<int>&marker=<id><br />
/flavors/detail?minDisk=<int>&minRam=<int>&limit=<int>&marker=<int><br />
/images?changes-since=<timestamp>&server=<server url>&name=<string>&status=<string>&type=<string>&limit=<int>&marker=<id><br />
/images/detail?changes-since=<timestamp>&server=<server url>&name=<string>&status=<string>&type=<string>&limit=<int>&marker=<id><br />
​/os-hosts?service=<string>&zone=<string><br />
​/os-migrations?host=<string>&status=<string>&cell_name=<string><br />
<br />
identity v3<br />
<br />
/services?type=<string>&page=<string>&per_page=<string><br />
/endpoints?interface=<string>&service_id=<string>&page=<string>&per_page=<string><br />
/domains?name=<string>&enabled=<string>&page=<string>&per_page=<string><br />
/projects?domain_id=<string>&name=<string>&enabled=<string>&page=<string>&per_page=<string><br />
/users?domain_id=<string>&name=<string>&enabled=<string>&page=<string>&per_page=<string><br />
/groups?domain_id=<string>&page=<string>&per_page=<string><br />
/groups/​{group_id}​/users?domain_id=<string>&description=<string>&name=<string>&enabled=<string>&page=<string>&per_page=<string><br />
/credentials?page=<string>&per_page=<string><br />
/roles?name=<string>&page=<string>&per_page=<string><br />
/policies?type=<string>&page=<string>&per_page=<string><br />
<br />
identity v2<br />
<br />
/tenants?limit=<int>&marker=<string>&name=<string><br />
/tenants/​{tenantId}​/users?limit=<int>&marker=<string><br />
/OS-KSADM/services?limit=<int>&marker=<string>&name=<string><br />
<br />
image v2<br />
<br />
/images?limit=<int>&marker=<string>&name=<string>&visibility=<string>&member_status=<string>&owner=<string>&status=<string>&size_min=<string>&size_max=string>&sort_key=<string>&sort_dir=<string>&tag=<string><br />
<br />
network v2<br />
* http://specs.openstack.org/openstack/neutron-specs/specs/api/networking_general_api_information.html#filtering-and-column-selection<br />
<br />
/networks?id=<string>&name=<string>&shared=<string>&status=<string>&subnets=<string> # can filter on all top-level attributes<br />
/networks?fields=<attr>&fields=<attr> # can return a subset of the body<br />
<br />
/subnets?name=<string>&enable_dhcp=<bool>&network_id=<string>&dns_nameservers=<???>&allocation_pools=<???>&host_routes=<???>&ip_version=<int>&gateway_ip=string>&cidr=<string>&id=<string>&<br />
/subnets?fields=<attr>&fields=<attr> # can return a subset of the body<br />
<br />
/ports?<br />
status=<string>&name=<string>&allowed_address_pairs=<???>&admin_state_up=<bool>&network_id=<string>&extra_dhcp_opts=<???>&device_owner=<string>&mac_address=<string>&fixed_ips=<???>&id=<string>&security_groups=<string>&device_id=<string><br />
/ports?fields=<attr>&fields=<attr> # can return a subset of the body<br />
<br />
/routers?status=<string>&external_gateway_info=<???>&name=<string>&admin_state_up=<bool>&id=<string>&<br />
/routers?fields=<attr>&fields=<attr> # can return a subset of the body<br />
<br />
object store v1<br />
<br />
/​{account}​/?limit=<int>&marker=<string>&end_marker=<string>&format=<string>&prefix=<string>&delimiter=<character><br />
/​{account}/{container}​/?limit=<int>&marker=<string>&end_marker=<string>&format=<string>&prefix=<string>&delimiter=<character>&path=<string><br />
/​{account}​/​{container}​/​{object}​?signature=<string>&expires=<string>&multipart-manifest=<string>&<br />
<br />
orchestration v1<br />
<br />
/stacks?limit=<int>&marker=<string>&status=<string>&name=<string>&show_deleted=<string>&sort_keys=<string>&sort_dir=<string><br />
}​/stacks/​{stack_name}​/​{stack_id}​/resources?nested_depth=<string><br />
/stacks/​{stack_name}​/​{stack_id}​/events?limit=<int>&marker=<string>&resource_action=<string>&resource_status=<string>&resource_name=<string>&resource_type=string>&sort_keys=<string>&sort_dir=<string>&<br />
<br />
telemetry v2<br />
* http://docs.openstack.org/developer/ceilometer/webapi/v2.html#filtering-queries<br />
<br />
/alarms?q=<list of filter rules><br />
/meters?q=<list of filter rules><br />
/resources?q=<list of filter rules></div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=API_Special_Interest_Group/Current_Design/Query&diff=74335API Special Interest Group/Current Design/Query2015-02-24T20:07:15Z<p>Brian.curtin: Created page with "compute v2 /servers?changes-since=<timestamp>&image=<image url>&flavor=<flavor url>&name=<regex>&status=<string>&host=<string>&page_size=<int>&limit=<int>&marker=<id> /server..."</p>
<hr />
<div>compute v2<br />
<br />
/servers?changes-since=<timestamp>&image=<image url>&flavor=<flavor url>&name=<regex>&status=<string>&host=<string>&page_size=<int>&limit=<int>&marker=<id><br />
/servers?changes-since=<timestamp>&image=<image url>&flavor=<flavor url>&name=<regex>&status=<string>&host=<string>&limit=<int>&marker=<id><br />
/flavors?minDisk=<int>&minRam=<int>&limit=<int>&marker=<id><br />
/flavors/detail?minDisk=<int>&minRam=<int>&limit=<int>&marker=<int><br />
/images?changes-since=<timestamp>&server=<server url>&name=<string>&status=<string>&type=<string>&limit=<int>&marker=<id><br />
/images/detail?changes-since=<timestamp>&server=<server url>&name=<string>&status=<string>&type=<string>&limit=<int>&marker=<id><br />
​/os-hosts?service=<string>&zone=<string><br />
​/os-migrations?host=<string>&status=<string>&cell_name=<string><br />
<br />
identity v3<br />
<br />
/services?type=<string>&page=<string>&per_page=<string><br />
/endpoints?interface=<string>&service_id=<string>&page=<string>&per_page=<string><br />
/domains?name=<string>&enabled=<string>&page=<string>&per_page=<string><br />
/projects?domain_id=<string>&name=<string>&enabled=<string>&page=<string>&per_page=<string><br />
/users?domain_id=<string>&name=<string>&enabled=<string>&page=<string>&per_page=<string><br />
/groups?domain_id=<string>&page=<string>&per_page=<string><br />
/groups/​{group_id}​/users?domain_id=<string>&description=<string>&name=<string>&enabled=<string>&page=<string>&per_page=<string><br />
/credentials?page=<string>&per_page=<string><br />
/roles?name=<string>&page=<string>&per_page=<string><br />
/policies?type=<string>&page=<string>&per_page=<string><br />
<br />
identity v2<br />
<br />
/tenants?limit=<int>&marker=<string>&name=<string><br />
/tenants/​{tenantId}​/users?limit=<int>&marker=<string><br />
/OS-KSADM/services?limit=<int>&marker=<string>&name=<string><br />
<br />
image v2<br />
<br />
/images?limit=<int>&marker=<string>&name=<string>&visibility=<string>&member_status=<string>&owner=<string>&status=<string>&size_min=<string>&size_max=string>&sort_key=<string>&sort_dir=<string>&tag=<string><br />
<br />
network v2<br />
* http://specs.openstack.org/openstack/neutron-specs/specs/api/networking_general_api_information.html#filtering-and-column-selection<br />
<br />
/networks?id=<string>&name=<string>&shared=<string>&status=<string>&subnets=<string> # can filter on all top-level attributes<br />
/networks?fields=<attr>&fields=<attr> # can return a subset of the body<br />
<br />
/subnets?name=<string>&enable_dhcp=<bool>&network_id=<string>&dns_nameservers=<???>&allocation_pools=<???>&host_routes=<???>&ip_version=<int>&gateway_ip=string>&cidr=<string>&id=<string>&<br />
/subnets?fields=<attr>&fields=<attr> # can return a subset of the body<br />
<br />
/ports?<br />
status=<string>&name=<string>&allowed_address_pairs=<???>&admin_state_up=<bool>&network_id=<string>&extra_dhcp_opts=<???>&device_owner=<string>&mac_address=<string>&fixed_ips=<???>&id=<string>&security_groups=<string>&device_id=<string><br />
/ports?fields=<attr>&fields=<attr> # can return a subset of the body<br />
<br />
/routers?status=<string>&external_gateway_info=<???>&name=<string>&admin_state_up=<bool>&id=<string>&<br />
/routers?fields=<attr>&fields=<attr> # can return a subset of the body<br />
<br />
object store v1<br />
<br />
/​{account}​/?limit=<int>&marker=<string>&end_marker=<string>&format=<string>&prefix=<string>&delimiter=<character><br />
/​{account}/{container}​/?limit=<int>&marker=<string>&end_marker=<string>&format=<string>&prefix=<string>&delimiter=<character>&path=<string><br />
/​{account}​/​{container}​/​{object}​?signature=<string>&expires=<string>&multipart-manifest=<string>&<br />
<br />
orchestration v1<br />
<br />
/stacks?limit=<int>&marker=<string>&status=<string>&name=<string>&show_deleted=<string>&sort_keys=<string>&sort_dir=<string><br />
}​/stacks/​{stack_name}​/​{stack_id}​/resources?nested_depth=<string><br />
/stacks/​{stack_name}​/​{stack_id}​/events?limit=<int>&marker=<string>&resource_action=<string>&resource_status=<string>&resource_name=<string>&resource_type=string>&sort_keys=<string>&sort_dir=<string>&<br />
<br />
telemetry v2<br />
* http://docs.openstack.org/developer/ceilometer/webapi/v2.html#filtering-queries<br />
<br />
/alarms?q=<list of filter rules><br />
/meters?q=<list of filter rules><br />
/resources?q=<list of filter rules></div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=74329Meetings/PythonOpenStackSDK2015-02-24T18:24:40Z<p>Brian.curtin: /* Agenda for 2015-02-24 1900 UTC */</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 on Tuesdays. 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 />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right (https://etherpad.openstack.org/p/find_filters)<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=74328Meetings/PythonOpenStackSDK2015-02-24T18:23:43Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-02-24 1900 UTC ==<br />
* Roll Call<br />
* What to do with Resource.page?<br />
** https://bugs.launchpad.net/python-openstacksdk/+bug/1424211<br />
** Resource.list is handled, building out Resource.find - Resource.page in the middle<br />
* plugins<br />
** need to test out https://review.openstack.org/#/c/155362/ with recent KSC synchrnoization<br />
* release again soon?<br />
** https://review.openstack.org/#/c/158191/ to bring equal with FlavorDetail<br />
** Resource.find would be nice to have now, but may take a while to get right<br />
<br />
<br />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=73806Meetings/PythonOpenStackSDK2015-02-17T17:48:34Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Resource Changes Needed<br />
** General purpose find<br />
** Non-paginated list<br />
** dirty list not kept up to date - https://review.openstack.org/#/c/156485/<br />
** case insensitive attr dict - https://review.openstack.org/#/c/156135/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=73761Meetings/PythonOpenStackSDK2015-02-17T03:27:19Z<p>Brian.curtin: /* Agenda for 2015-02-10 1900 UTC */</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 on Tuesdays. 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 />
== Agenda for 2015-02-16 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Make Resource.find more general purpose - https://review.openstack.org/#/c/156004/<br />
** Improve Resource.page for single-page usage - https://review.openstack.org/#/c/156007/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=73760Meetings/PythonOpenStackSDK2015-02-17T03:27:06Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Key Reviews<br />
** Revert to KSC auth plugins - https://review.openstack.org/#/c/156064/<br />
** Make Resource.find more general purpose - https://review.openstack.org/#/c/156004/<br />
** Improve Resource.page for single-page usage - https://review.openstack.org/#/c/156007/<br />
** Support Resource as a type for properties - https://review.openstack.org/#/c/152275/<br />
* Easier/Quicker Reviews<br />
** Add the Type resource for the Volume service - https://review.openstack.org/#/c/155115/<br />
** Add the Volume type for the Volume service - https://review.openstack.org/#/c/155125/<br />
** Add the Snapshot type for the Volume service - https://review.openstack.org/#/c/155132/<br />
<br />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=73659SDK-Development/PythonOpenStackSDK2015-02-13T21:24:13Z<p>Brian.curtin: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
The OpenStack SDK is an project to improve the overall experience of users of OpenStack clouds, from application developers to operators, by providing one place to work with OpenStack's many services. As a a software development kit, the project aims to offer a complete set of libraries to work with OpenStack services, as well as complete documentation and examples for working with the ecosystem.<br />
<br />
=== Detailed Description ===<br />
<br />
Currently, OpenStack's user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured, and inconsistent. If a consumer who is not "in the know" - read: not an operator or developer involved in creation of OpenStack - attempts to consume more than one service, their complexity increases almost linearly. With each service currently providing its own client, which includes both the library and a command line tool, the number of dependencies along with the varying interfaces used by them offers a less than welcoming experience.<br />
<br />
The python-openstacksdk project is an attempt at providing once place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.<br />
<br />
=== What's in an SDK? ===<br />
<br />
The root of a complete SDK is a consumer focused set of libraries for interacting with the system. It additionally includes:<br />
* Documentation aimed at users consuming OpenStack clouds, whether internally at their company or commercially available<br />
* Documentation aimed at OpenStack developers, enabling them to extend libraries or contribute their own libraries, including extensions<br />
* Examples of usage, including fully functional applications that demo the various services the SDK works with<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* Application Developers: Application developers are consumers of OpenStack clouds. While they can be operators or contributors to the services themselves, the primary application developer persona is anyone wanting to develop an application to leverage one or more services provided by OpenStack. These developers require a consistent set of usable APIs with minimal dependencies to manage.<br />
* Command line Users: These are similar to the Application Developers, as their requirements include a consistent set of interactions but they're carried out through a single executable that communicates with their OpenStack cloud. As with Application Developers, minimal dependencies to complete their tasks is of high importance.<br />
<br />
Important to both audiences is that terminology is jargon free and doesn't use nicknames or require knowledge of project history or internals. For example, working with the compute service should be done through library or command line interactions utilizing the compute name, not Nova.<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/python-openstacksdk<br />
|-<br />
| Blueprints || https://launchpad.net/python-openstacksdk<br />
|-<br />
| User Documentation || http://python-openstacksdk.readthedocs.org/en/latest/contributors/index.html<br />
|-<br />
| Contributor Documentation || http://python-openstacksdk.readthedocs.org/en/latest/users/index.html<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 />
= IRC =<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 at 1900 UTC in #openstack-meeting-3<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 python-openstacksdk Meeting Archive]<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=73658SDK-Development/PythonOpenStackSDK2015-02-13T21:22:48Z<p>Brian.curtin: /* Summary */</p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
The OpenStack SDK is an project to improve the overall experience of users of OpenStack clouds, from application developers to operators, by providing one place to work with OpenStack's many services. As a a software development kit, the project aims to offer a complete set of libraries to work with OpenStack services, as well as complete documentation and examples for working with the ecosystem.<br />
<br />
== Detailed Description ==<br />
<br />
Currently, OpenStack's user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured, and inconsistent. If a consumer who is not "in the know" - read: not an operator or developer involved in creation of OpenStack - attempts to consume more than one service, their complexity increases almost linearly. With each service currently providing its own client, which includes both the library and a command line tool, the number of dependencies along with the varying interfaces used by them offers a less than welcoming experience.<br />
<br />
The python-openstacksdk project is an attempt at providing once place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.<br />
<br />
== What's in an SDK? ==<br />
<br />
The root of a complete SDK is a consumer focused set of libraries for interacting with the system. It additionally includes:<br />
* Documentation aimed at users consuming OpenStack clouds, whether internally at their company or commercially available<br />
* Documentation aimed at OpenStack developers, enabling them to extend libraries or contribute their own libraries, including extensions<br />
* Examples of usage, including fully functional applications that demo the various services the SDK works with<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are consumers of OpenStack clouds. While they can be operators or contributors to the services themselves, the primary application developer persona is anyone wanting to develop an application to leverage one or more services provided by OpenStack. These developers require a consistent set of usable APIs with minimal dependencies to manage.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements include a consistent set of interactions but they're carried out through a single executable that communicates with their OpenStack cloud. As with Application Developers, minimal dependencies to complete their tasks is of high importance.<br />
<br />
Important to both audiences is that terminology is jargon free and doesn't use nicknames or require knowledge of project history or internals. For example, working with the compute service should be done through library or command line interactions utilizing the compute name, not Nova.<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/python-openstacksdk<br />
|-<br />
| Blueprints || https://launchpad.net/python-openstacksdk<br />
|-<br />
| User Documentation || http://python-openstacksdk.readthedocs.org/en/latest/contributors/index.html<br />
|-<br />
| Contributor Documentation || http://python-openstacksdk.readthedocs.org/en/latest/users/index.html<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 />
= IRC =<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 at 1900 UTC in #openstack-meeting-3<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 python-openstacksdk Meeting Archive]<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=73657SDK-Development/PythonOpenStackSDK2015-02-13T21:21:37Z<p>Brian.curtin: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
The OpenStack SDK is an project to improve the overall experience of users of OpenStack clouds, from application developers to operators, by providing one place to work with OpenStack's many services. As a a software development kit, the project aims to offer a complete set of libraries to work with OpenStack services, as well as complete documentation and examples for working with the ecosystem.<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured, and inconsistent. If a consumer who is not "in the know" - read: not an operator or developer involved in creation of OpenStack - attempts to consume more than one service, their complexity increases almost linearly. With each service currently providing its own client, which includes both the library and a command line tool, the number of dependencies along with the varying interfaces used by them offers a less than welcoming experience.<br />
<br />
The python-openstacksdk project is an attempt at providing once place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.<br />
<br />
'''What's in an SDK?''':<br />
<br />
The root of a complete SDK is a consumer focused set of libraries for interacting with the system. It additionally includes:<br />
* Documentation aimed at users consuming OpenStack clouds, whether internally at their company or commercially available<br />
* Documentation aimed at OpenStack developers, enabling them to extend libraries or contribute their own libraries, including extensions<br />
* Examples of usage, including fully functional applications that demo the various services the SDK works with<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are consumers of OpenStack clouds. While they can be operators or contributors to the services themselves, the primary application developer persona is anyone wanting to develop an application to leverage one or more services provided by OpenStack. These developers require a consistent set of usable APIs with minimal dependencies to manage.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements include a consistent set of interactions but they're carried out through a single executable that communicates with their OpenStack cloud. As with Application Developers, minimal dependencies to complete their tasks is of high importance.<br />
<br />
Important to both audiences is that terminology is jargon free and doesn't use nicknames or require knowledge of project history or internals. For example, working with the compute service should be done through library or command line interactions utilizing the compute name, not Nova.<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/python-openstacksdk<br />
|-<br />
| Blueprints || https://launchpad.net/python-openstacksdk<br />
|-<br />
| User Documentation || http://python-openstacksdk.readthedocs.org/en/latest/contributors/index.html<br />
|-<br />
| Contributor Documentation || http://python-openstacksdk.readthedocs.org/en/latest/users/index.html<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 />
= IRC =<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 at 1900 UTC in #openstack-meeting-3<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 python-openstacksdk Meeting Archive]<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=73656SDK-Development/PythonOpenStackSDK2015-02-13T21:18:55Z<p>Brian.curtin: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
The OpenStack SDK is an project to improve the overall experience of users of OpenStack clouds, from application developers to operators, by providing one place to work with OpenStack's many services. As a a software development kit, the project aims to offer a complete set of libraries to work with OpenStack services, as well as complete documentation and examples for working with the ecosystem.<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured, and inconsistent. If a consumer who is not "in the know" - read: not an operator or developer involved in creation of OpenStack - attempts to consume more than one service, their complexity increases almost linearly. With each service currently providing its own client, which includes both the library and a command line tool, the number of dependencies along with the varying interfaces used by them offers a less than welcoming experience.<br />
<br />
The python-openstacksdk project is an attempt at providing once place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.<br />
<br />
'''What's in an SDK?''':<br />
<br />
The root of a complete SDK is a consumer focused set of libraries for interacting with the system. It additionally includes:<br />
* Documentation aimed at users consuming OpenStack clouds, whether internally at their company or commercially available<br />
* Documentation aimed at OpenStack developers, enabling them to extend libraries or contribute their own libraries, including extensions<br />
* Examples of usage, including fully functional applications that demo the various services the SDK works with<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are consumers of OpenStack clouds. While they can be operators or contributors to the services themselves, the primary application developer persona is anyone wanting to develop an application to leverage one or more services provided by OpenStack. These developers require a consistent set of usable APIs with minimal dependencies to manage.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements include a consistent set of interactions but they're carried out through a single executable that communicates with their OpenStack cloud. As with Application Developers, minimal dependencies to complete their tasks is of high importance.<br />
<br />
Important to both audiences is that terminology is jargon free and doesn't use nicknames or require knowledge of project history or internals. For example, working with the compute service should be done through library or command line interactions utilizing the compute name, not Nova.<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/python-openstacksdk<br />
|-<br />
| Blueprints || https://launchpad.net/python-openstacksdk<br />
|-<br />
| User Documentation || http://python-openstacksdk.readthedocs.org/en/latest/contributors/index.html<br />
|-<br />
| Contributor Documentation || http://python-openstacksdk.readthedocs.org/en/latest/users/index.html<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 />
* 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 />
= IRC =<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 at 1900 UTC in #openstack-meeting-3<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstack_sdk/2014/ 2014 python-openstacksdk Accidental Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk_weekly_meeting/2014/ 2014 python-openstacksdk Accidental Archive]<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=73655SDK-Development/PythonOpenStackSDK2015-02-13T21:16:53Z<p>Brian.curtin: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
The OpenStack SDK is an project to improve the overall experience of users of OpenStack clouds, from application developers to operators, by providing one place to work with OpenStack's many services. As a a software development kit, the project aims to offer a complete set of libraries to work with OpenStack services, as well as complete documentation and examples for working with the ecosystem.<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured, and inconsistent. If a consumer who is not "in the know" - read: not an operator or developer involved in creation of OpenStack - attempts to consume more than one service, their complexity increases almost linearly. With each service currently providing its own client, which includes both the library and a command line tool, the number of dependencies along with the varying interfaces used by them offers a less than welcoming experience.<br />
<br />
The python-openstacksdk project is an attempt at providing once place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.<br />
<br />
'''What's in an SDK?''':<br />
<br />
The root of a complete SDK is a consumer focused set of libraries for interacting with the system. It additionally includes:<br />
* Documentation aimed at users consuming OpenStack clouds, whether internally at their company or commercially available<br />
* Documentation aimed at OpenStack developers, enabling them to extend libraries or contribute their own libraries, including extensions<br />
* Examples of usage, including fully functional applications that demo the various services the SDK works with<br />
<br />
= Audience =<br />
There are two key audiences for this project:<br />
<br />
* '''Application Developers''': Application developers are consumers of OpenStack clouds. While they can be operators or contributors to the services themselves, the primary application developer persona is anyone wanting to develop an application to leverage one or more services provided by OpenStack. These developers require a consistent set of usable APIs with minimal dependencies to manage.<br />
* '''Command line consumers''': These are similar to the Application Developers, as their requirements include a consistent set of interactions but they're carried out through a single executable that communicates with their OpenStack cloud. As with Application Developers, minimal dependencies to complete their tasks is of high importance.<br />
<br />
Important to both audiences is that terminology is jargon free and doesn't use nicknames or require knowledge of project history or internals. Working with the compute service should be done through library or command line interactions using the compute name, not Nova.<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/python-openstacksdk<br />
|-<br />
| Blueprints || https://launchpad.net/python-openstacksdk<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 />
* 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 />
= IRC =<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 at 1900 UTC in #openstack-meeting-3<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstack_sdk/2014/ 2014 python-openstacksdk Accidental Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk_weekly_meeting/2014/ 2014 python-openstacksdk Accidental Archive]<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=73654SDK-Development/PythonOpenStackSDK2015-02-13T21:09:22Z<p>Brian.curtin: </p>
<hr />
<div>__TOC__<br />
<br />
= Summary =<br />
<br />
The OpenStack SDK is an project to improve the overall experience of users of OpenStack clouds, from application developers to operators, by providing one place to work with OpenStack's many services. As a a software development kit, the project aims to offer a complete set of libraries to work with OpenStack services, as well as complete documentation and examples for working with the ecosystem.<br />
<br />
'''Detailed Description''':<br />
<br />
Currently, OpenStack's user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured, and inconsistent. If a consumer who is not "in the know" - read: not an operator or developer involved in creation of OpenStack - attempts to consume more than one service, their complexity increases almost linearly. With each service currently providing its own client, which includes both the library and a command line tool, the number of dependencies along with the varying interfaces used by them offers a less than welcoming experience.<br />
<br />
The python-openstacksdk project is an attempt at providing once place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.<br />
<br />
'''What's in an SDK?''':<br />
<br />
An SDK is more than just a set of APIs. A complete SDK provides a consumer focused set of libraries for interacting with the system, and additionally includes:<br />
* Documentation aimed at users consuming OpenStack clouds, whether internally at their company or commercially available<br />
* Documentation aimed at OpenStack developers, enabling them to extend libraries or contribute their own libraries, including extensions<br />
* Examples of usage, including fully functional applications that demo the various services the SDK works with<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/python-openstacksdk<br />
|-<br />
| Blueprints || https://launchpad.net/python-openstacksdk<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 />
* 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 />
= IRC =<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 at 1900 UTC in #openstack-meeting-3<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstack_sdk/2014/ 2014 python-openstacksdk Accidental Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk_weekly_meeting/2014/ 2014 python-openstacksdk Accidental Archive]<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=73413Meetings/PythonOpenStackSDK2015-02-10T18:56:46Z<p>Brian.curtin: /* Agenda for 2015-02-03 1900 UTC */</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 on Tuesdays. 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 />
== Agenda for 2015-02-10 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=73412Meetings/PythonOpenStackSDK2015-02-10T18:52:57Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Auth plugins work!<br />
** https://github.com/briancurtin/rackspace-sdk-plugin (temporary home, not on PyPI)<br />
* Going to split up Cinder review into one change for all Resources, then one change for each resource's addition to the connection level, then docs<br />
* Resource.list consistency update<br />
** For non-pagined but listed resources, they can (mostly) use Resource.page as a drop-in-replacement<br />
** Those resources should probably override list and make themselves work with page so you can always list() and get back a generator of items<br />
<br />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=72904Meetings/PythonOpenStackSDK2015-02-03T18:34:34Z<p>Brian.curtin: /* 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 on Tuesdays. 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 />
== Agenda for 2015-02-03 1900 UTC ==<br />
* Roll Call<br />
* Conversations at Cinder meetup, Cinder v2 https://review.openstack.org/#/c/150979/<br />
* Thoughts on doc work in progress? http://briancurtin.com/doc_reorg/<br />
* Resource.list consistency (pagination disabled, or not supported but still returning lists) https://review.openstack.org/#/c/147686/<br />
* Support for async Transport backend?<br />
<br />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=72458Meetings/PythonOpenStackSDK2015-01-27T18:27:35Z<p>Brian.curtin: /* Agenda for 2015-01-20 1900 UTC */</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 on Tuesdays. 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 />
== Agenda for 2015-01-27 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=72457Meetings/PythonOpenStackSDK2015-01-27T18:27:22Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update: holding off on CDN + Rackspace auth plugin for now (internal deadline moved so I'm pushing it back a bit)<br />
* Cinder v2 in progress (resource + high level) - going to the Cinder mid-cycle sprint to show them what's up<br />
* Resource.page - how to represent this in the higher level? Same with Resource.find<br />
* Auth plugin refactor (merged) - what's next for User Preference and the module loader?<br />
<br />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=72083Meetings/PythonOpenStackSDK2015-01-20T18:38:29Z<p>Brian.curtin: /* Agenda for 2014-01-20 1900 UTC */</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 on Tuesdays. 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 />
== Agenda for 2015-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=72082Meetings/PythonOpenStackSDK2015-01-20T18:38:17Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2014-01-20 1900 UTC ==<br />
* Roll Call<br />
* Update on CDN<br />
** Resources "done", but can't test them without the Rackspace piece working (or until it works in devstack). Workflow-1 for now.<br />
** Rackspace "plugin" mostly done, but currently lives in-tree (next to v2 and v3 plugins). Looking at how to work with it outside of the repo as a true plugin.<br />
* Object Store proxy - any strong objection to merging and working on part 2? (easier setting of attributes/header values)<br />
* Other proxies - Ian's image one, any others moving forward - how to proceed?<br />
<br />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=68886Meetings/PythonOpenStackSDK2014-11-25T18:39:21Z<p>Brian.curtin: /* 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 on Tuesdays. 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 />
== Agenda for 2014-11-25 1900 UTC ==<br />
* Roll Call<br />
* Swift devs will likely be joining us to contribute soon<br />
** Brian's ``object_store`` proxy is basically "done" to get something out there working that we can mold, just needs tests.<br />
** Documentation is shaping up, waiting to hear back if there are any gaps that outsiders might need near term.<br />
* Regionless and versionless services<br />
** Terry has a review out to start on versionless (https://review.openstack.org/#/c/136632/)<br />
** Brian has a review out to start on regionless (https://review.openstack.org/#/c/136655/)<br />
<br />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=Meetings/PythonOpenStackSDK&diff=68291Meetings/PythonOpenStackSDK2014-11-18T17:41:31Z<p>Brian.curtin: </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 on Tuesdays. 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 />
== Agenda for 2014-11-18 1900 UTC ==<br />
* Roll Call<br />
* Implement iterator paging - https://review.openstack.org/134105 - one +2, need more views<br />
* entry_points to load services - https://review.openstack.org/131314 - summit discussion leaned towards no<br />
* prop attr access return None by default - https://review.openstack.org/134632 - one +2, need more views<br />
* high level views (swift and jenkins)<br />
** How do we want to move forward with these particular reviews?<br />
** Once those are in, how do we want to progress with them before expanding to provide the same high-level view across all other resources?<br />
* Unicode/bytes - do we need to take a stance on this at any level, or pass through whatever values we're given? e.g., when creating an object in object-store, does that name need to be one or the other? (I think we're just a pass-through, but want to be sure)<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Discussion on more complex/nested resources<br />
** path_args stuff, needing to inject other information into some of the classmethods<br />
** No movement on pinging community for higher level, want to have more of this fleshed out for examples<br />
<br />
== Agenda for 2014-08-12 1900 UTC ==<br />
* Roll Call<br />
* Current state of Resources<br />
** Compute, Networking, and Telemetry seem to be coming along well<br />
** Object Storage<br />
*** https://review.openstack.org/#/c/111807/ (comments addressed, should be ready)<br />
** Are we going in a good and/or right direction in general?<br />
** Where to go from here?<br />
***Think about higher level before we go too far? (something that doesn't require you to pass sessions around all the time)<br />
***Think about the lower level before we go too far? (something that just gives back dicts, like Dean mentioned)<br />
<br />
== Agenda for 2014-08-05 1900 UTC ==<br />
* Roll Call<br />
* Neutron reviews<br />
** Some need type corrections (many bools, some ints, some list/dict) -- acceptable for them to go in as-is and follow up with a bug report to go back and correct?<br />
* Swift account/container review -- went back to Container.list lists containers, rather than previous attempt which had Container.list listing objects in a container<br />
* No movement on the so called lower level resource right now, will split out next<br />
* Resource automation - Terry has some script<br />
<br />
== Agenda for 2014-07-29 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
** Needs a comment added to authenticator.create to say the function should be removed since we'll never be able to keep up with plugins. Was agreed upon by Jamie, Terry, and Brian - otherwise is ready to go.<br />
* swift status -- stuck on a good way to get the container into the Object class, the first such resource that requires additional information. The first swift implementation was injecting the container name into the dictionary that was used to create Object, which had an unorthodox usage compared to other services.<br />
* Terry submitted a Summit talk proposal on the project<br />
* Lower level discussion that Dean has wanted to have<br />
<br />
== Agenda for 2014-07-22 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- add some factories<br />
* https://review.openstack.org/#/c/105728/ -- full flavor CRUD<br />
* https://review.openstack.org/#/c/104987/ -- swift resource (not 100%)<br />
** Container.list needs a change that was hacked into a previous patch set to get the proper request path<br />
* Dean wants to talk about low level API<br />
<br />
== Agenda for 2014-07-08 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/104948/ -- Add some factories<br />
** has one +2<br />
* https://review.openstack.org/#/c/105431/ -- Minor fixes to examples<br />
* Swift and Neutron resources<br />
** right direction?<br />
** how to build on them?<br />
** what's next?<br />
<br />
== Agenda for 2014-07-01 1900 UTC ==<br />
* Roll Call<br />
* Accessories (things examples/resources depend on)<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources<br />
** https://review.openstack.org/#/c/102561/ -- Add --data option to debug curl logging<br />
** https://review.openstack.org/#/c/102504/ -- Have exceptions print something by default<br />
** https://review.openstack.org/#/c/102587/ -- Add common method to find a resource<br />
** https://review.openstack.org/#/c/102607/ -- Change transport JSON handling<br />
** https://review.openstack.org/#/c/102564/ -- Have the service catalog ignore empty urls<br />
* Examples<br />
** https://review.openstack.org/#/c/102590/ -- Example create command<br />
** https://review.openstack.org/#/c/102591/ -- Add example delete<br />
** https://review.openstack.org/#/c/102922/ -- Add example get<br />
* Resources<br />
** https://review.openstack.org/#/c/102593/ -- Simple network resource<br />
** https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
<br />
== Agenda for 2014-06-24 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/99456/ -- Important changes for service filtering<br />
** Updated to address Alex and Dolph's concerns on previous patch set, has one +2<br />
* https://review.openstack.org/#/c/99463/ -- Very basic image resource<br />
* Not far enough along for review, but working on swift resource, fitting head request for account info into it right now<br />
<br />
== Agenda for 2014-06-17 1900 UTC ==<br />
* Roll Call<br />
* Discuss namespacing scheme<br />
** Need to be mindful of cross-service SDK usage, e.g., Heat server talking to Glance API. Building our resources out as openstack.image, openstack.compute, may be presumptuous.<br />
** Different top-level namespace? Perhaps openstack.sdk.compute? <br />
* https://review.openstack.org/#/c/99456/ - Important changes for service filtering<br />
** has one +2<br />
* https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__<br />
** has one +2, was also blessed by Dean<br />
* https://review.openstack.org/#/c/99463/ - Very basic image resource<br />
** No formal reviews, Brian is ok with it but needs to finish reviewing<br />
* https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly<br />
** has one +2<br />
<br />
== Agenda for 2014-06-10 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/98917/ - Important auth fixes<br />
** has one +2<br />
* ...which is a dependency of https://review.openstack.org/#/c/97829/ - Example code reorg and auth examples<br />
** has one -2, Dean has https://review.openstack.org/#/c/98858/ to show where he was going with similar work<br />
* ...which is a dependency of https://review.openstack.org/#/c/98524/ - Example session command<br />
** has one +2 after being slimmed down<br />
* On examples: perhaps need to make clearer distinction between end-user examples, and developer examples (for us)<br />
* Any status on building out resources<br />
<br />
== Agenda for 2014-05-27 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** updated since Summit, has some comments, needs more reviews!<br />
* https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class<br />
** small, has one +2, reviews would be helpful to move along<br />
* https://review.openstack.org/#/c/94707 -- Add command structure to example code<br />
** small, has one +2, reviews would be helpful to move along<br />
<br />
== Agenda for 2014-05-20 1900 UTC ==<br />
* Roll Call<br />
* Can't run coverage until new pbr comes out with support for a testr argument called [https://git.openstack.org/cgit/openstack-dev/pbr/commit/pbr?id=d68a32126588de9d0e865f546d22293bae269130 "coverage-package-name"]<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** When rebased, should be fine to go in. Depends on "Add presentation layer".<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Has one +2<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** some updates from Terry before summit - any other plans here?<br />
<br />
== Agenda for 2014-05-06 1900 UTC ==<br />
* Roll Call<br />
* https://review.openstack.org/#/c/90301/ -- Resource Properties<br />
** Has two +1s but one minor issue, has a suggestion to address it.<br />
* https://review.openstack.org/#/c/91448/ -- Example code for presentation<br />
** Test failure in dependent change, but it seems pretty straightforward.<br />
* https://review.openstack.org/#/c/90538/ -- Add presentation layer<br />
** Was changed around from initial comments by Jamie. Last patch set has a comment that will make tests pass all around.<br />
* https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient<br />
** C&P from keystoneclient, needs to take out some deprecated or no longer useful things that came along with it<br />
<br />
== Agenda for 2014-04-29 1900 UTC ==<br />
* Roll Call<br />
* Open discussion? Anything on your minds?<br />
<br />
== Agenda for 2014-04-22 1900 UTC ==<br />
* Roll Call<br />
* Outline a plan to move forward, ideally with rough timelines. If we can pull it together, it would be nice to head into the OpenStack Summit with a minimum viable demo of the project.<br />
** Class design decision between the proposals<br />
*** What is outstanding?<br />
*** What do we need to do to reach consensus?<br />
*** When can we build on top of the winner?<br />
** When can we implement the minimally needed Keystone bits to build out a service?<br />
** When can we implement the first service?<br />
* Discuss open reviews<br />
<br />
== Agenda for 2014-04-15 1900 UTC ==<br />
* Roll Call<br />
* Quick mention of chatter from PyCon on the project<br />
* Ed's proposal: https://review.openstack.org/#/c/85720/<br />
* Jamie's proposal: https://review.openstack.org/#/c/86227/<br />
<br />
== Agenda for 2014-04-08 1900 UTC ==<br />
* Roll Call (many parties in transit to PyCon)<br />
* Discussion of base code for class design commit: https://review.openstack.org/#/c/85720/<br />
** Limit discussion to design approach, and not specific code concerns<br />
** There is one other proposed entry, but no code yet. Any others we should consider?<br />
** Timeline for selecting a design and moving forward with it<br />
* Discussion of any other in-progress reviews<br />
* Possible BoF at PyCon if enough people attending<br />
<br />
== Agenda for 2014-04-01 1900 UTC ==<br />
* Discussion of pace and how to speed things up<br />
** Several reviews nearing completion<br />
** Next steps to build on top, pushing towards an MVP<br />
* Discussion of class design BP/wiki<br />
** https://blueprints.launchpad.net/unifiedsdk/+spec/overall-class-design<br />
** https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion<br />
* Discussion of any in-progress reviews<br />
* Plan the next steps, hoping to get more code flowing into reviews<br />
<br />
== Agenda for 2014-03-25 1900 UTC ==<br />
* Roll Call<br />
* requests.Session wrapper: https://review.openstack.org/#/c/81882/<br />
* redirection handling: https://review.openstack.org/#/c/81988/<br />
* Design Summit submission: http://summit.openstack.org/cfp/details/95<br />
<br />
== Agenda for 2014-03-18 1900 UTC ==<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Design Summit submissions: http://summit.openstack.org/cfp/details/95 and http://summit.openstack.org/cfp/details/34<br />
* Plan next steps - expansion of example, expansion of services, etc.<br />
<br />
== Agenda for 2014-03-11 1900 UTC ==<br />
<br />
* Roll Call<br />
* Discuss direction and plans for http/identity sketches: https://review.openstack.org/#/c/79435/<br />
* Gauge interest in meeting during the OpenStack Design Summit in Atlanta in May<br />
<br />
== Agenda for 2014-03-04 1900 UTC ==<br />
<br />
* Roll Call<br />
* Feedback on the wiki / current state (open discussion)<br />
* Discuss extension models for third-party vendors<br />
* API strawman status<br />
<br />
== Agenda for 2014-02-19 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>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=68285SDK-Development/PythonOpenStackSDK2014-11-18T17:28:51Z<p>Brian.curtin: /* 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 one client per service to install in order to build an application on the OpenStack platform, 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 singe 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 potential next step would be to collapse the individual python-* clients and use this as their logical backends. Another idea has been floated around to cut over to this SDK and move python-*client libraries into a security fix only mode, with eventual deprecation.<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/python-openstacksdk<br />
|-<br />
| Blueprints || https://launchpad.net/python-openstacksdk<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 />
* 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 />
= IRC =<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 at 1900 UTC in #openstack-meeting-3<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstack_sdk/2014/ 2014 python-openstacksdk Accidental Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk_weekly_meeting/2014/ 2014 python-openstacksdk Accidental Archive]<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=68284SDK-Development/PythonOpenStackSDK2014-11-18T17:28:13Z<p>Brian.curtin: /* 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 one client per service to install in order to build an application on the OpenStack platform, 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 singe 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 potential next step would be to collapse the individual python-* clients and use this as their logical backends. Another idea has been floated around to cut over to this SDK and move python-*client libraries into a security fix only mode, with eventual deprecation.<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/python-openstacksdk<br />
|-<br />
| Blueprints || https://launchpad.net/python-openstacksdk<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 />
* 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 />
= IRC =<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/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstack_sdk/2014/ 2014 python-openstacksdk Accidental Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk_weekly_meeting/2014/ 2014 python-openstacksdk Accidental Archive]<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=68283SDK-Development/PythonOpenStackSDK2014-11-18T17:27:26Z<p>Brian.curtin: </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 one client per service to install in order to build an application on the OpenStack platform, 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 singe 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 potential next step would be to collapse the individual python-* clients and use this as their logical backends. Another idea has been floated around to cut over to this SDK and move python-*client libraries into a security fix only mode, with eventual deprecation.<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 />
* 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 />
= IRC =<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/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstack_sdk/2014/ 2014 python-openstacksdk Accidental Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk_weekly_meeting/2014/ 2014 python-openstacksdk Accidental Archive]<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=68282SDK-Development/PythonOpenStackSDK2014-11-18T17:26:15Z<p>Brian.curtin: /* 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 one client per service to install in order to build an application on the OpenStack platform, 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 singe 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 potential next step would be to collapse the individual python-* clients and use this as their logical backends. Another idea has been floated around to cut over to this SDK and move python-*client libraries into a security fix only mode, with eventual deprecation.<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 />
* 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 />
= 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/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstack_sdk/2014/ 2014 python-openstacksdk Accidental Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk_weekly_meeting/2014/ 2014 python-openstacksdk Accidental Archive]<br />
:<br />
<br />
= Design Discussion =<br />
How should we structure the code for this SDK? Join in on the [[PythonOpenStackSDK/ClassDesignDiscussion|Class Design Discussion]] to help make this a robust project.<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtinhttps://wiki.openstack.org/w/index.php?title=SDK-Development/PythonOpenStackSDK&diff=68279SDK-Development/PythonOpenStackSDK2014-11-18T17:24:51Z<p>Brian.curtin: /* 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 one client per service to install in order to build an application on the OpenStack platform, 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 singe 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 potential next step would be to collapse the individual python-* clients and use this as their logical backends. Another idea has been floated around to cut over to this SDK and move python-*client libraries into a security fix only mode, with eventual deprecation.<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/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstack_sdk/2014/ 2014 python-openstacksdk Accidental Archive]<br />
* [http://eavesdrop.openstack.org/meetings/python_openstacksdk_weekly_meeting/2014/ 2014 python-openstacksdk Accidental Archive]<br />
:<br />
<br />
= Design Discussion =<br />
How should we structure the code for this SDK? Join in on the [[PythonOpenStackSDK/ClassDesignDiscussion|Class Design Discussion]] to help make this a robust project.<br />
<br />
= Frequently Asked Questions =<br />
Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.</div>Brian.curtin