Re: [openstack-dev] [all] Yakumo: Pythonic, unified OpenStack client library

[Brian Curtin]

On Tue, May 2, 2017 at 10:46 PM, Akira Yoshiyama 
wrote:

> Hello all,
>
> I'm pleased to announce Yakumo, yet another unified OpenStack client
> library with an interactive shell. You can find Yakumo below:
>
>PyPI: https://pypi.python.org/pypi/yakumo/
>Github: https://github.com/yosshy/python-yakumo/
>
> Yakumo development focuses to:
>
> * Pythonic: handles each cloud resource as an object in the same manner
> * Unified: handles all OpenStack APIs at once
> * Less dependency: no import of other OpenStack client libraries
>
> Why do we have to specify IDs of cloud resources in Python
> programming? Python is an object-oriented programming language. IMO,
> we should use objects to represent cloud resources, including method
> arguments. It's one of the reasons I've started Yakumo project.
>
> Yakumo 0.11.0 suports OpenStack APIs below:
>
> * Identity API v2/v3
> * Compute API v2
> * Networking v2
> * Image Service API v1/v2
> * Block Storage v1/v2
> * Object Storage v1
>
> Yakumo has 23 sample smoke tests below for the APIs now. It's useful
> to test your cloud and learn usage of Yakumo.
>
>https://github.com/yosshy/python-yakumo/tree/master/yakumo/smoketests
>
> And also you can use 'ossh', an interactive python shell in Yakumo.
> It's a good example.
> # ossh --os-cloud=mypackstack
>
> Finding existing resources:
> (c is an client object automatically generated for mypackstack environment)
> >>> i = c.image.find_one(name="trusty")
> >>> f = c.flavor.find_one(name='m1.small')
> >>> k = c.key_pair.find_one(name='key1')
> >>> n = c.network.find_one(name='private')
> >>> i, f, k, n
> ( (id="887b0393-5065-4bcf-941d-623100baa06e", name="trusty")>,
> ,
> ,
>  (id="22e3fa30-11c0-4065-bbf7-8d8bbb50f63b", name="private")>)
>
> Creating a server:
> >>> s = c.server.create(name='vm1', image=i, flavor=f, networks=[n],
> key_pair=k)
> >>> s
>  (id="b1477f6c-bbc4-4c37-ba05-14b935a5d08c" empty)>
>
> Waiting for building task finished:
> >>> s.wait_for_finished()
> >>> s.status
> u'ACTIVE'
>
> Deleting the server:
> >>> s.delete()
>
> See README for more usage and details:
>
>https://github.com/yosshy/python-yakumo/blob/master/README.md
>
> Feedback is welcome!
>
> Cheers,
> Akira Yoshiyama


Looks almost exactly like openstacksdk. Why duplicate that and pollute an
already crowded space as there are already far too many existing libraries
to work with OpenStack?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] openstacksdk and compute limits for projects

[Brian Curtin]

On Tue, Jan 17, 2017 at 4:23 PM, Michael Gale 
wrote:

> Hello,
>
> Does anyone know what the equivalent of the following command would be
> via the API?
> `openstack limits show --absolute --project `
>
> I am using an admin account to pull stats and information from a Mitaka
> environment, now I can run the above command in bash, looping over each
> project that exist. However I would like to get the information using the
> openstacksdk via Python.
>
> I can use:
> `connection.compute.get_limits()`
>  however that only works for the project I logged in with.
>

It could take an id/name, but the REST API doesn't seem to be documented
that it takes an id or name, which is probably why it doesn't currently
accept them:
http://developer.openstack.org/api-ref/compute/?expanded=show-rate-and-absolute-limits-detail

How should we implement this?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] cirros images to change default password

[Brian Curtin]

On Tue, Nov 29, 2016 at 7:48 AM, Ihar Hrachyshka  wrote:
> Hi,
>
> It was ‘cubswin:)’ before, but now that Cubs won [1] it’s ‘gocubsgo’ [2].
>
> I hope it helps someone in the future.
>
> [1] 
> http://www.chicagotribune.com/sports/baseball/cubs/ct-cubs-win-world-series-sullivan-spt-1103-20161102-story.html
> [2] 
> https://git.launchpad.net/cirros/commit/?id=9a7c371ef329cf78f256d0a5a8f475d9c57f5477
>
> Ihar

Feel free to sing along to "Go Cubs Go" to celebrate this password
change and/or the Cubs world series victory --
https://www.youtube.com/watch?v=A9XtDyDUjIU

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Endpoint structure: a free-for-all

[Brian Curtin]

On Wed, Oct 19, 2016 at 2:03 PM, Sean Dague <s...@dague.net> wrote:
> On 10/19/2016 01:40 PM, Brian Curtin wrote:
>> On Wed, Oct 19, 2016 at 12:59 PM, Jay Pipes <jaypi...@gmail.com> wrote:
>>> On 10/19/2016 05:32 PM, Brian Curtin wrote:
>>>>
>>>> I'm currently facing what looks more and more like an impossible
>>>> problem in determining the root of each service on a given cloud. It
>>>> is apparently a free-for-all in how endpoints can be structured, and I
>>>> think we're out of ways to approach it that catch all of the ways that
>>>> all people can think of.
>>>>
>>>> In openstacksdk, we can no longer use the service catalog for
>>>> determining each service's endpoints. Among other things, this is due
>>>> to a combination of some versions of some services not actually being
>>>> listed, and with things heading the direction of version-less services
>>>> anyway. Recently we changed to using the service catalog as a pointer
>>>> to where services live and then try to find the root of that service
>>>> by stripping the path down and making some extra requests on startup
>>>> to find what's offered. Despite a few initial snags, this now works
>>>> reasonably well in a majority of cases.
>>>>
>>>> We have seen endpoints structured in the following ways:
>>>>  A. subdomains, e.g., https://service.cloud.com/v2
>>>>  B. paths, e.g., https://cloud.com/service/v2 (sometimes there are
>>>> more paths in between the root and /service/)
>>>>  C. service-specific ports, e.g., https://cloud.com:1234/v2
>>>>  D. both A and B plus ports
>>>>
>>>> Within all of these, we can find the root of the given service just
>>>> fine. We split the path and build successively longer paths starting
>>>> from the root. In the above examples, we need to hit the path just
>>>> short of the /v2, so in B it actually takes two requests as we'd make
>>>> one to cloud.com which fails, but then a second one to
>>>> cloud.com/service gives us what we need.
>>>>
>>>> However, another case came up: the root of all endpoints is itself
>>>> another service. That makes it look like this:
>>>>
>>>>  E. https://cloud.com:/service/v2
>>>>  F. https://cloud.com:/otherservice
>>>>
>>>> In this case, https://cloud.com: is keystone, so trying to get E's
>>>> base by going from the root and outward will give me a versions
>>>> response I can parse properly, but it points to keystone. We then end
>>>> up building requests for 'service' that go to keystone endpoints and
>>>> end up failing. We're doing this using itertools.accumulate on the
>>>> path fragments, so you might think 'just throw it through
>>>> `reversed()`' and go the other way. If we do that, we'll also get a
>>>> versions response that we can parse, but it's the v2 specific info,
>>>> not all available versions.
>>>>
>>>> So now that we can't reliably go from the left, and we definitely
>>>> can't go from the right, how about the middle?
>>>>
>>>> This sounds ridiculous, and if it sounds familiar it's because they
>>>> devise a "middle out" algorithm on the show Silicon Valley, but in
>>>> most cases it'd actually work. In E above, it'd be fine. However,
>>>> depending on the number of path fragments and which direction we chose
>>>> to move first, we'd sometimes hit either a version-specific response
>>>> or another service's response, so it's not reliable.
>>>>
>>>> Ultimately, I would like to know how something like this can be solved.
>>>>
>>>> 1. Is there any reliable, functional, and accurate programmatic way to
>>>> get the versions and endpoints that all services on a cloud offer?
>>>
>>>
>>> The Keystone service catalog should be the thing that provides the endpoints
>>> for all services in the cloud. Within each service, determining the
>>> (micro)version of the API is unfortunately going to be a per-service
>>> endeavour. For some APIs, a microversion header is returned, others don't
>>> have microversions. The microversion header is unfortunately not
>>> standardized for all APIs that use microversions, though a number of us
>>> would like to see a single:
>>>
>>> OpenStack-API-Version:  , ...
&g

Re: [openstack-dev] Endpoint structure: a free-for-all

[Brian Curtin]

On Wed, Oct 19, 2016 at 12:59 PM, Jay Pipes <jaypi...@gmail.com> wrote:
> On 10/19/2016 05:32 PM, Brian Curtin wrote:
>>
>> I'm currently facing what looks more and more like an impossible
>> problem in determining the root of each service on a given cloud. It
>> is apparently a free-for-all in how endpoints can be structured, and I
>> think we're out of ways to approach it that catch all of the ways that
>> all people can think of.
>>
>> In openstacksdk, we can no longer use the service catalog for
>> determining each service's endpoints. Among other things, this is due
>> to a combination of some versions of some services not actually being
>> listed, and with things heading the direction of version-less services
>> anyway. Recently we changed to using the service catalog as a pointer
>> to where services live and then try to find the root of that service
>> by stripping the path down and making some extra requests on startup
>> to find what's offered. Despite a few initial snags, this now works
>> reasonably well in a majority of cases.
>>
>> We have seen endpoints structured in the following ways:
>>  A. subdomains, e.g., https://service.cloud.com/v2
>>  B. paths, e.g., https://cloud.com/service/v2 (sometimes there are
>> more paths in between the root and /service/)
>>  C. service-specific ports, e.g., https://cloud.com:1234/v2
>>  D. both A and B plus ports
>>
>> Within all of these, we can find the root of the given service just
>> fine. We split the path and build successively longer paths starting
>> from the root. In the above examples, we need to hit the path just
>> short of the /v2, so in B it actually takes two requests as we'd make
>> one to cloud.com which fails, but then a second one to
>> cloud.com/service gives us what we need.
>>
>> However, another case came up: the root of all endpoints is itself
>> another service. That makes it look like this:
>>
>>  E. https://cloud.com:/service/v2
>>  F. https://cloud.com:/otherservice
>>
>> In this case, https://cloud.com: is keystone, so trying to get E's
>> base by going from the root and outward will give me a versions
>> response I can parse properly, but it points to keystone. We then end
>> up building requests for 'service' that go to keystone endpoints and
>> end up failing. We're doing this using itertools.accumulate on the
>> path fragments, so you might think 'just throw it through
>> `reversed()`' and go the other way. If we do that, we'll also get a
>> versions response that we can parse, but it's the v2 specific info,
>> not all available versions.
>>
>> So now that we can't reliably go from the left, and we definitely
>> can't go from the right, how about the middle?
>>
>> This sounds ridiculous, and if it sounds familiar it's because they
>> devise a "middle out" algorithm on the show Silicon Valley, but in
>> most cases it'd actually work. In E above, it'd be fine. However,
>> depending on the number of path fragments and which direction we chose
>> to move first, we'd sometimes hit either a version-specific response
>> or another service's response, so it's not reliable.
>>
>> Ultimately, I would like to know how something like this can be solved.
>>
>> 1. Is there any reliable, functional, and accurate programmatic way to
>> get the versions and endpoints that all services on a cloud offer?
>
>
> The Keystone service catalog should be the thing that provides the endpoints
> for all services in the cloud. Within each service, determining the
> (micro)version of the API is unfortunately going to be a per-service
> endeavour. For some APIs, a microversion header is returned, others don't
> have microversions. The microversion header is unfortunately not
> standardized for all APIs that use microversions, though a number of us
> would like to see a single:
>
> OpenStack-API-Version:  , ...
>
> header supported. This is the header supported in the new placement REST
> API, for what it's worth.

I get the microversion part, and we support that (for some degree of
support), but this is about the higher level major versions. The
example that started this was Keystone only listing a v2 endpoint in
the service catalog, at least on devstack. I need to be able to hit v3
APIs when a user wants to do v3 things, regardless of which version
they auth to, so the way to get it was to get the root and go from
there. That both versions weren't listed was initially confusing to
me, but that's where the suggestion of "go to the root and get
everything" started out.

The service catalog holding providing al

[openstack-dev] Endpoint structure: a free-for-all

[Brian Curtin]

I'm currently facing what looks more and more like an impossible
problem in determining the root of each service on a given cloud. It
is apparently a free-for-all in how endpoints can be structured, and I
think we're out of ways to approach it that catch all of the ways that
all people can think of.

In openstacksdk, we can no longer use the service catalog for
determining each service's endpoints. Among other things, this is due
to a combination of some versions of some services not actually being
listed, and with things heading the direction of version-less services
anyway. Recently we changed to using the service catalog as a pointer
to where services live and then try to find the root of that service
by stripping the path down and making some extra requests on startup
to find what's offered. Despite a few initial snags, this now works
reasonably well in a majority of cases.

We have seen endpoints structured in the following ways:
 A. subdomains, e.g., https://service.cloud.com/v2
 B. paths, e.g., https://cloud.com/service/v2 (sometimes there are
more paths in between the root and /service/)
 C. service-specific ports, e.g., https://cloud.com:1234/v2
 D. both A and B plus ports

Within all of these, we can find the root of the given service just
fine. We split the path and build successively longer paths starting
from the root. In the above examples, we need to hit the path just
short of the /v2, so in B it actually takes two requests as we'd make
one to cloud.com which fails, but then a second one to
cloud.com/service gives us what we need.

However, another case came up: the root of all endpoints is itself
another service. That makes it look like this:

 E. https://cloud.com:/service/v2
 F. https://cloud.com:/otherservice

In this case, https://cloud.com: is keystone, so trying to get E's
base by going from the root and outward will give me a versions
response I can parse properly, but it points to keystone. We then end
up building requests for 'service' that go to keystone endpoints and
end up failing. We're doing this using itertools.accumulate on the
path fragments, so you might think 'just throw it through
`reversed()`' and go the other way. If we do that, we'll also get a
versions response that we can parse, but it's the v2 specific info,
not all available versions.

So now that we can't reliably go from the left, and we definitely
can't go from the right, how about the middle?

This sounds ridiculous, and if it sounds familiar it's because they
devise a "middle out" algorithm on the show Silicon Valley, but in
most cases it'd actually work. In E above, it'd be fine. However,
depending on the number of path fragments and which direction we chose
to move first, we'd sometimes hit either a version-specific response
or another service's response, so it's not reliable.

Ultimately, I would like to know how something like this can be solved.

1. Is there any reliable, functional, and accurate programmatic way to
get the versions and endpoints that all services on a cloud offer?

2. Are there any guidelines, rules, expectations, or other
documentation on how services can be installed and their endpoints
structured that are helpful to people build apps that use them, not in
those trying to install and operate them? I've looked around a few
times and found nothing useful. A lot of what I've found has
referenced suggestions for operators setting them up behind various
load balancing tools.

3. If 1 and 2 won't actually help me solve this, do you have any other
suggestions that will? We already go left, right, and middle of each
URI, so I'm out of directions to go, and we can't go back to the
service catalog.

Thanks,

Brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl] code churn and questionable changes

[Brian Curtin]

On Wed, Sep 21, 2016 at 8:15 AM, gordon chung  wrote:
> i feel like this gets brought up every year. we block these patches in
> Telemetry projects unless they can be justified beyond the copy/paste
> description.
>
> in addition to this, please, PLEASE stop creating 'all project bugs'. i
> don't want to get emails on updates to projects unrelated to the ones i
> care about. also, it makes updating the bug impossible because it times
> out. i'm too lazy to search ML but this has been raise before, please stop.
>
> let's all unite together and block these patches to bring an end to it. :)

I know Launchpad only has about three features, but is there a way to
block this there? I created that MagicMock issue that somehow got
spammed to everyone, but it was never intended to be used that way. It
was to solve a legitimate problem we inflicted on ourselves long ago,
corrected it pretty quickly and easily, and then moved on with life.
It probably doesn't affect any of the 50 projects it got added to in
the same way, or at all even.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Easing contributions to central documentation

[Brian Curtin]

On Thu, May 12, 2016 at 1:24 AM, Joseph Robinson
 wrote:
> Hi All, One reply inline:
>
> On 11/05/2016, 7:33 AM, "Lana Brindley"  wrote:
>
>>On 10/05/16 20:08, Julien Danjou wrote:
>>> On Mon, May 09 2016, Matt Kassawara wrote:
>>>
 So, before developer frustrations drive some or all projects to move
 their documentation in-tree which which negatively impacts the goal of
 presenting a coherent product, I suggest establishing an agreement
 between developers and the documentation team regarding the review
 process.
>>>
>>> My 2c, but it's said all over the place that OpenStack is not a product,
>>> but a framework. So perhaps the goal you're pursuing is not working
>>> because it's not accessible by design?
>>>
 1) The documentation team should review the patch for compliance with
 conventions (proper structure, format, grammar, spelling, etc.) and
provide
 feedback to the developer who updates the patch.
 2) The documentation team should modify the patch to make it compliant
and
 ask the developer for a final review to prior to merging it.
 3) The documentation team should only modify the patch to make it
build (if
 necessary) and quickly merge it with a documentation bug to resolve any
 compliance problems in a future patch by the documentation team.
>
> I like the idea of options 2 and 3. Specifically though, I think Option 3
> - merging content that builds, and checking out a bug to improve the
> quality - can work in some cases. With a dedicated teams on several
> guides, docs contributors would be able to pick up bugs right away -
> that¹s my 2c.

This is just enabling technical debt as process and ultimately hurts
the users of the docs who end up with poorly worded or incorrect
information by letting subpar -- but syntactically correct --
documentation in. Even a dedicated team isn't going to get around to
everything, and someone coming in later to pick up bugs to document is
less likely to be the right person to convey the proper explanation
and details than the one who implemented the work.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

[Brian Curtin]

On Sun, Feb 7, 2016 at 3:07 PM, Jay Pipes  wrote:
> I would love to see the OpenStack contributor community take back the design
> summit to its original format and purpose and decouple it from the OpenStack
> Summit's conference portion.
>
> I believe the design summits should be organized by the OpenStack
> contributor community, not the OpenStack Foundation and its marketing and
> event planning staff.

As someone who spent years organizing PyCon as a volunteer from the
Python community, with four of those years in a row taking about 8
solid months of pre-conference effort, not to mention the on-site
effort to run a volunteer conference of that size [0]...I would
suggest even longer and harder thought before stretching a community
like this even more thinly. Things should change, but probably not the
"who's doing the work" aspect.

[0] PyCon is around 2500 (though with one paid staffer now), so maybe
larger than the target for the event you're thinking of, but it was
still a massive effort at the crowds of 2000, 1500, 1000, etc. and
being fully community driven.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Brian Curtin]

Because it's still day_n AOE in early hours of day_n+1 local-time in a
lot of places. I think I have until 6 AM the day after an AOE deadline
where it's still considered the deadline date anywhere on earth, as
there are still places on earth where the date hasn't flipped.

Your EOD is not the deadline, as it's really only a reference to how
many more hours you have until it's no longer that date anywhere on
earth. People screw themselves out of things by using their EOD as the
definition.

(we've been using this with the PyCon CFP since forever)

On Thu, Sep 17, 2015 at 1:17 PM, Kevin Benton <blak...@gmail.com> wrote:
> How is it not what I described? Time zones become irrelevant if you get it
> in by the end of the day in your local time zone.
>
> https://en.wikipedia.org/wiki/Anywhere_on_Earth
>
> On Thu, Sep 17, 2015 at 10:30 AM, Brian Curtin <br...@python.org> wrote:
>>
>> On Thu, Sep 17, 2015 at 12:26 PM, Kevin Benton <blak...@gmail.com> wrote:
>> > Maybe it would be a good idea to switch to 23:59 AOE deadlines like many
>> > paper submissions use for academic conferences. That way there is never
>> > a
>> > need to convert TZs, you just get it in by the end of the day in your
>> > own
>> > time zone.
>>
>> This is somehow going to cause even more confusion because you'll have
>> to explain AOE (which is not what you described).
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Kevin Benton
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Brian Curtin]

On Thu, Sep 17, 2015 at 12:26 PM, Kevin Benton  wrote:
> Maybe it would be a good idea to switch to 23:59 AOE deadlines like many
> paper submissions use for academic conferences. That way there is never a
> need to convert TZs, you just get it in by the end of the day in your own
> time zone.

This is somehow going to cause even more confusion because you'll have
to explain AOE (which is not what you described).

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Debian already using Python 3.5: please gate on that

[Brian Curtin]

On Thursday, June 18, 2015, Doug Hellmann d...@doughellmann.com wrote:

 Excerpts from Thomas Goirand's message of 2015-06-18 15:44:17 +0200:
  Hi!
 
  tl;dr: skip this message, the subject line is enough! :)
 
  As per the subject line, we already have Python 3.5 in Debian (AFAICT,
  from Debian Experimental, in version beta 2). As a consequence, we're
  already running (unit) tests using Python 3.5. Some have failures: I
  could see issues in ceilometerclient, keystoneclient, glanceclient and
  more (yes, I am planning to report these issues, and we already started
  doing so). As Python 3.4 is still the default interpreter for
  /usr/bin/python3, that's currently fine, but it soon wont be.
 
  All this to say: if you are currently gating on Python 3, please start
  slowly adding support for 3.5, as we're planning to switch to that for
  Debian 9 (aka Stretch). I believe Ubuntu will follow (as the Python core
  packages are imported from Debian).

 3.5 is still in beta. What's the schedule for an official release from
 the python-dev team?


3.4 Final is planed for September 13
 https://www.python.org/dev/peps/pep-0478/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

[Brian Curtin]

On Wed, Feb 11, 2015 at 1:43 PM, Jeremy Stanley fu...@yuggoth.org wrote:
 Also, if there are people on this list who feel like
 discussions here sometimes get negative or uncomfortable, I'm happy
 to point you to free software community mailing lists (more than I
 can count on all my fingers and toes) whose day-to-day interactions
 make the worst of our flame wars (if you can even call them that)
 look like a gradeschool holiday pageant by comparison.

If people feel it's a negative or uncomfortable environment, find out
why and try to do something to improve it. Telling someone that there
are worse options out there is the opposite of fostering an open
community.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] docstring standard?

[Brian Curtin]

On Tue, Feb 10, 2015 at 1:57 PM, Min Pae sputni...@gmail.com wrote:
 I think most people would agree documentation is a good thing, and
 consistency is generally a good thing…  is there an accepted standard on
 layout and minimum required fields?

 If not, should there be?

 For example

 - Heading (short description)
 - Description
 - Inputs
- Input name + description
- Input type
 - Outputs
- Output description
- Output type

 vs

 - Heading (short description)
 - Inputs
- Input name + description
- Input type
 - Outputs
- Output description
- Output type
 - Description


 I generally like the former, but given that the docstring in python follows
 the function/method header rather than precedes it, it seems like the latter
 would be better for python so that descriptions of the inputs and outputs
 are not separated by lengthy descriptions.

 Comments/opinions?

In python-openstacksdk we go the route that has the description at the
top, which is partially driven by our use of autodoc. It looks and
reads better to describe what a method does and then show the options,
versus giving a one sentence description, a bunch of detailed options,
and then telling you a paragraph about what it can do.

Even if you're not generating documentation out of it, having the
in/out parameters as the last thing makes it a little more usable when
reading the code itself.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

[Brian Curtin]

On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague s...@dague.net wrote:
 - [H305 H306 H307] Organize your imports according to the `Import order
   template`_ and `Real-world Import Order Examples`_ below.

 I think these remain reasonable guidelines, but H302 is exceptionally
 tricky to get right, and we keep not getting it right.

 H305-307 are actually impossible to get right. Things come in and out of
 stdlib in python all the time.

Do you have concrete examples of where this has been an issue? Modules
are only added roughly every 18 months and only on the 3.x line as of
the middle of 2010 when 2.7.0 was released. Nothing should have left
the 2.x line within that time as well, and I don't recall anything
having completed a deprecation cycle on the 3.x side.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] python-openstacksdk post-summit status update

[Brian Curtin]

Since a bunch of people had been asking at the Summit, and bunch of
them were interested in contributing, it seemed like a good idea to
put together some status on where the OpenStack SDK project is at.

What follows is the status section of a larger blog post on the SDK at
the Summit, available at
http://blog.briancurtin.com/posts/openstack-sdk-post-summit-update.html


Current Project Status
==

The OpenStack SDK is quickly heading toward being usable for
application developers. Leading up to the OpenStack Summit we had a
reasonably complete Resource layer and had been working on building
out a higher-level interface, as exposed through the Connection class.
As of now, first cuts of a high-level interface have implementations
in Gerrit for most of the official programs, and we're working to
iterate on what we have in there right now before expanding further.
We also had an impromptu design session on Thursday to cover a couple
of things we'll need to work through.

Project Architecture


At the lowest level, the authentication, session, and transport pieces
have been rounded out and we've been building on them for a while now.
These were some of the first building blocks, and having a reasonably
common approach that multiple service libraries could build on is one
of the project goals.

Session objects are constructed atop Authenticators and Transports.
They get tokens from the Authenticator to insert into your headers,
get endpoints to build up complete URLs, and make HTTP requests on the
Transport, which itself is built on top of requests and handles all
things inbound and outbound from the REST APIs.

On top of that lies the Resource layer, a base class implemented in
openstack/resource.py, which aims to be a 1-1 representation of the
requests or responses the REST APIs are dealing with. For example, the
Server class in openstack/compute/v2/server.py inherits from Resource
and maps to the inputs and outputs of the compute service's `/servers`
endpoint. That Server object contains attributes of type
openstack.resource.prop, which is a class that maps
server-communicated values, such as mapping the accessIPv4 response
body value to an attribute called access_ipv4. This serves two
purposes: one is that it's a place we can bring consistency to the
library when it comes to naming, and two is that props have a type
argument that allows for minimal client-side validation on request
values.

Resource objects are slightly raw to work with directly. They require
you to maintain your own session (it's the first argument of Resource
methods), and they typically only support our thin wrappers around
HTTP verbs. Server.create will take your session and then make a POST
request populated with the props you set on your object.

On top of the Resource layer is the Connection class, which forms our
high-level layer. Connection objects, from openstack/connection.py,
tie together our core pieces - authentication and transport within a
session - and expose namespaces that allow you to work with OpenStack
services from one place. This high-level layer is implemented via
Proxy classes inside of each service's versioned namespace, in their
_proxy.py module.

Right now many of these Proxy implementations are up for review in
Gerrit, but openstack.compute.list_flavors is currently available in
master. It builds on the openstack.compute.v2.flavor Resource, simply
calling its list method inside list_flavors and passing on the Session
that compute was initialized with.

What the high-level looks like
**

There are a bunch of example scripts in the works in the Gerrit
reviews, but some of what we're working on looks like the following.

Create a container and object in object storage::

   from openstack import connection
   conn = connection.Connection(auth_url=https://myopenstack:5000/v3;,
user_name=me, password=secret, ...)
   cnt = conn.object_store.create_container(my_container)
   ob = conn.object_store.create_object(container=cnt, name=my_obj,
data=Hello, world!)

Create a server with a keypair::

   from openstack import connection
   conn = connection.Connection(auth_url=https://myopenstack:5000/v3;,
user_name=me, password=secret, ...)
   args = {
   name: my_server,
   flavorRef: big,
   imageRef: asdf-1234-qwer-5678,
   key_name: my_ssh_key,
   }
   server = conn.compute.create_server(**args)
   servers = conn.compute.list_servers()

Where we're going
*

General momentum has carried us into this Connection/Proxy layer,
where we have initial revisions of a number of services, and by
default, we'll just keep pushing on this layer. I expect we'll iterate
on how we want this layer to look, hopefully with input from people
outside of the regular contributors. Outside of that, results from
conversations at the Summit will 

[openstack-dev] Status update on the python-openstacksdk project

[Brian Curtin]

Hi all,

Between recent IRC meetings and the mid-cycle operators meetup, we've
heard things ranging from is the SDK project still around to I
can't wait for this. I'm Brian Curtin from Rackspace and I'd like to
tell you what the python-openstacksdk [0][1] project has been up to
lately.

After initial discussions, meetings [2], and a coordination session in
Atlanta, a group of us decided to kick off a project to offer a
complete Software Development Kit for those creating and building on
top of OpenStack. This project aims to offer a one-stop-shop to
interact with all of the parts of an OpenStack cloud, either writing
code against a consistent set of APIs, or by using command line tools
implemented on those APIs [3], with concise documentation and examples
that end-users can leverage.

From a vendor perspective, it doesn't make sense for all of us to have
our own SDKs written against the same APIs. Additionally, every
service having their own client/CLI presents a fragmented view to
consumers and introduces difficulties once users move beyond
involvement with one or two services. Beyond the varying dependencies
and the sheer number of moving parts involved, user experience is not
as welcoming and great as it should be.

We first built transport and session layers based on python-requests
and Jamie Lennox's Keystone client authentication plugins (minus
compatibility cruft). The service resources are represented in a base
resource class, and we've implemented resources for interacting with
Identity, Object-Store, Compute, Image, Database, Network, and
Orchestration APIs. Expanding or adding support for new services is
straightforward, but we're thinking about the rest of the picture
before building out too far.

This resource layer may be slightly raw if you're looking at it as a
consumer, and not likely what you'd want in a full scale application.
Now that we have these resources exposed to work with, we're looking
upward to think about how an end-user would want to interact with a
service. We're also moving downward and looking at what we want to
provide to command line interfaces, such as easier access to the
JSON/dicts (as prodded by Dean :).

Overall, we're moving along nicely. While we're thinking about these
high-level/end-user views, I'd love to know if anyone has any thoughts
there. For example, what would the ideal interface to your favorite
service look like? As things are hacked out, we'll share them and
gather as much input as we can from this community as well as the
users.

If you're interested in getting involved or have any questions or
comments, we meet on Tuesdays at 1900 UTC in #openstack-meeting-3, and
all of us hang out in #openstack-sdks on Freenode.

As for who's involved, we're on stackalytics [4], but recently it has
been Terry Howe (HP), Jamie Lennox (Red Hat), Dean Troyer (Nebula),
Steve Lewis (Rackspace), and myself.

Thanks for your time


[0] https://github.com/stackforge/python-openstacksdk
[1] https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK
[2] http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/
[3] OpenStackClient is planning to switch to using the Python SDK
after the interfaces have stabilized.
[4] 
http://stackalytics.com/?project_type=stackforgemodule=python-openstacksdkrelease=all

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting log/minutes from 2014-08-12

[Brian Curtin]

Minutes:
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-08-12-19.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-08-12-19.00.txt
Log:
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-08-12-19.00.log.html

The next scheduled meeting is Tuesday 2014-08-19 at 1900 UTC

We're currently working up some last bits before putting together a 'state
of the project' summary as well as an RFC for what a higher-level interface
should look like.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting minutes for 2014-08-05

[Brian Curtin]

The following logs are from today's python-openstacksdk meeting

Minutes:
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-08-05-19.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-08-05-19.00.txt
Log:
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-08-05-19.00.log.html

The next meeting is scheduled for 2014-08-12 at 1900 UTC
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting minutes from 2014-07-22

[Brian Curtin]

Today was a relatively quick meeting, but a meeting nonetheless.

Minutes:
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-07-22-19.00.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-07-22-19.00.txt

Log:
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-07-22-19.00.log.html

Next meeting scheduled for Tuesday July 29 at 1900 UTC.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Creating new python-new_project_nameclient

[Brian Curtin]

On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 Hi,

 I'm looking at creating a new python-new_project_nameclient and I was
 wondering if there was any on going effort to share code between the
 clients or not? I've looked at the code in python-novaclient and
 python-neutronclient and both of them seem to have their own homegrown
 HTTPClient and keystone integration. Figured I'd ping the mailing list here
 before I go on and make my own homegrown HTTPClient as well.


It's still quite early, but this is one of the things we're working on with
python-openstacksdk[0][1]. As of today[2] there are reviews for the start
of how Neutron and Glance clients would work out, and I'm working on the
start of a Swift one myself. However, if you need your client written
today, this project isn't there yet.

[0] https://github.com/stackforge/python-openstacksdk
[1] https://wiki.openstack.org/wiki/PythonOpenStackSDK
[2]
https://review.openstack.org/#/q/status:open+project:stackforge/python-openstacksdk,n,z
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting Minutes for Tuesday June 17

[Brian Curtin]

Meeting ended Tue Jun 17 19:59:32 2014 UTC.

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-06-17-19.00.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-06-17-19.00.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-06-17-19.00.log.html

The next meeting will be Tuesday June 24 at 1900 UTC

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Tuesday May 27 Meeting Minutes

[Brian Curtin]

Meeting ended Tue May 27 20:00:28 2014 UTC

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-27-19.01.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-27-19.01.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-27-19.01.log.html


Next meeting is Tuesday June 3 at 1900 UTC. I will be at PyCon Russia
and won't be able to run the meeting, so I'll try to grab someone else
to run the meeting.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting Minutes - 2014-05-20

[Brian Curtin]

Next meeting will be 2014-05-27

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-20-19.00.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-20-19.00.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-20-19.00.log.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-openstacksdk] Meeting Minutes - 2014-05-20

[Brian Curtin]

On Tue, May 20, 2014 at 6:43 PM, Joe Gordon joe.gord...@gmail.com wrote:


 On Tue, May 20, 2014 at 1:37 PM, Brian Curtin br...@python.org wrote:

 Next meeting will be 2014-05-27

 Minutes:
 http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-20-19.00.html


 These meeting minutes are very sparse.

Sorry about that. The meeting started with light attendance and was
more conversational, then I forgot about MeetBot it came time to shut
it off. Future meetings will go back to using the appropriate commands
to generate useful minutes.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Programs] Client Tools program discussion

[Brian Curtin]

On Wed, May 7, 2014 at 7:38 AM, Doug Hellmann
doug.hellm...@dreamhost.com wrote:
 On Tue, May 6, 2014 at 5:45 PM, Joe Gordon joe.gord...@gmail.com wrote:



 On Tue, May 6, 2014 at 6:54 AM, Dean Troyer dtro...@gmail.com wrote:

 On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez thie...@openstack.org
 wrote:

 Would you take over the Python client libraries as well ? On one hand
 they need /some/ domain expertise, but on the other I see no reason to
 special-case Python against other SDKs, and that may give the libraries
 a bit more attention and convergence (they currently are the ugly
 stepchild in some programs, and vary a lot).


 The future of the existing client libs has not been settled, my working
 assumption is that they would remain with their home programs as they are
 now.  From the start OpenStackClient was meant to be a clean-slate for the
 CLI and the Python SDK is taking the same basic approach.



 Very excited for the OpenStackClient, it is already way nicer then the
 existing clients.


 Just working this out in my head. So the work flow would be:

 1. At first ClientTools consist of just the OpenStackClient
 2. When the pythonSDK is ready to move off of stackforge, it will live in
 ClientTools
 3. Specific python-*clients will be rewritten (from scratch?) to use the
 PythonSDK. But this time they won't have a built in CLI. These libraries
 will live along side the respective servers (so nova's python-novaclient
 will live in Compute)? All while moving OpenStackClient to the new libraries


 Is that what you are proposing?

 My understanding is that the SDK aims to be a ground-up replacement
 for the existing disparate client libraries. Whether that replacement
 is appropriate for use inside OpenStack may be up for debate (I think
 I remember someone saying that wasn't necessarily a goal, with the
 focus being on end users, but I haven't been able to attend many of
 the meetings so my information may be out of date).

Ideally the python-openstacksdk becomes the one-stop shop for
interacting with OpenStack as an OpenStack contributor, an operator,
an end-user of an OpenStack cloud, etc. If you're writing Python code
to work with OpenStack, that would be the place to go for code, tools,
examples, and documentation.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Programs] Client Tools program discussion

[Brian Curtin]

On Tue, May 6, 2014 at 8:38 AM, Doug Hellmann
doug.hellm...@dreamhost.com wrote:
 On Tue, May 6, 2014 at 8:02 AM, Thierry Carrez thie...@openstack.org wrote:
 Dean Troyer wrote:
 I want to open the discussion of an OpenStack Client Tools program
 proposal to a wider audience.  It would initially consist of
 OpenStackClient and eventually add the existing SDK projects as they are
 ready to join. The initial wiki page is at
 https://wiki.openstack.org/wiki/ClientTools.  I do want to have the
 proposal made before the summit, but not necessarily the TC consideration.

 I've been looking forward to this day for a long time! :-)


 Would you take over the Python client libraries as well ? On one hand
 they need /some/ domain expertise, but on the other I see no reason to
 special-case Python against other SDKs, and that may give the libraries
 a bit more attention and convergence (they currently are the ugly
 stepchild in some programs, and vary a lot).

 If I understand the mission of the new Python SDK team, they plan to
 build a new library with more consistency that may eventually replace
 the project-specific libraries. (Maybe someone on that team can check
 my facts there?) If that's correct, then it could make sense for that
 SDK project to fold into a client tools program when it reaches some
 definition of done.

Yep. Dean and I talked very briefly about this maybe a month ago, and
the python-openstacksdk would fall under this at some point in the
future. The same would likely be true for other similar projects,
e.g., the PHP SDK that is also under way.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Class Design Vote (until EOD Thursday)

[Brian Curtin]

Per the meeting yesterday, we're having a vote on which way to go
between Ed's and Jamie's proposals. If you have an opinion one way or
another, please make it known at
https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDecision

Voting ends at the end of the day UTC on Thursday. If you enter 
it'll enter your name and the time you voted.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Minutes from 15 April Meeting

[Brian Curtin]

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-15-19.00.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-15-19.00.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-15-19.00.log.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting Tuesday April 8 - 1900 UTC

[Brian Curtin]

Tomorrow is a scheduled python-openstacksdk meeting, although at least
myself and Alex Gaynor will not be available as we're in transit to
PyCon. I didn't hear from any others that they couldn't make the
meeting, so I'm guessing it will go on, just with someone else leading
it.

As Ed Leafe's proposal is the only thing that has changed (I got
bogged down last minute conference prep, don't have any code ready to
discuss yet), that's probably one topic to cover, but the rest of the
agenda is up to whoever shows up :)

https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting

Date/Time: Tuesday 25 March - 1900 UTC / 1400 CDT

IRC channel: #openstack-meeting-3

About the project:
https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK

If you have questions, all of us lurk in #openstack-sdks on freenode!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting Minutes - Tuesday April 1

[Brian Curtin]

We've decided to cancel the project.


April Fools. Thanks all for another good meeting. We have some action
items to build on, so we should be rolling onward for next week.

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-01-19.00.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-01-19.00.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-01-19.00.log.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Meeting Tuesday 01 April @ 1900 UTC

[Brian Curtin]

Reminder that tomorrow is the python-openstacksdk meeting.

https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting

Date/Time: Tuesday 01 April - 1900 UTC / 1400 CDT

IRC channel: #openstack-meeting-3

Meeting Agenda:
https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK

About the project:
https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK

If you have questions, all of us lurk in #openstack-sdks on freenode!

Ed's class design wiki will kick things off, and we'll take that into
the outstanding code reviews.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting Minutes - Tuesday 25 March

[Brian Curtin]

Thanks for another good meeting. More code coming along, and a few
reviews out there to take a look at.

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-25-19.01.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-25-19.01.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-25-19.01.log.html

We're all in #openstack-sdks in Freenode

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting Tuesday, 25 March @ 1900 UTC

[Brian Curtin]

Reminder that tomorrow is the python-openstacksdk meeting.

https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting

Date/Time: Tuesday 25 March - 1900 UTC / 1400 CDT

IRC channel: #openstack-meeting-3

Meeting Agenda:
https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK

About the project:
https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK

If you have questions, all of us lurk in #openstack-sdks on freenode!

The meeting will likely be a higher-bandwidth review session and
continued discussion of next steps as more code rolls in.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Minutes of Mar 18 Meeting

[Brian Curtin]

Thanks everyone for another good meeting. Lots of good talk about
direction and where to take the current example.

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-18-19.00.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-18-19.00.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-18-19.00.log.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting Tuesday Mar 18 19:00 UTC

[Brian Curtin]

Reminder that tomorrow is the python-openstacksdk meeting.

https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting

Date/Time: Tuesday 4 March - 19:00 UTC / 1400 CDT

IRC channel: #openstack-meeting-3

Meeting Agenda:
https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK

About the project:
https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK

If you have questions, all of us lurk in #openstack-sdks on freenode!

The meeting will likely consist of continued discussion around this review:
https://review.openstack.org/#/c/79435/. Will also discuss where to go
with Design Summit submissions, as well as how to progress with the
example.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Minutes from 11 Mar meeting

[Brian Curtin]

We just wrapped up our weekly meeting, and the minutes and log are available.

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-11-19.00.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-11-19.00.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-11-19.00.log.html

We're starting to get into code, so a lot of the discussion was around
the direction of the current example
(https://review.openstack.org/#/c/79435/) and some of the library
choices. There is some research to be done and more reviews to be had,
but it's off to a good start.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting Tuesday 11 Mar 19:00 UTC

[Brian Curtin]

Reminder that tomorrow is the python-openstacksdk meeting. Double
reminder that, where applicable, this is one hour later thanks to
Daylight Saving Time.

https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting

Date/Time: Tuesday 4 March - 19:00 UTC / 1400 CDT

IRC channel: #openstack-meeting-3

Meeting Agenda:
https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK

About the project:
https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK

If you have questions, all of us lurk in #openstack-sdks on freenode!

There isn't much of an agenda for this meeting as there hasn't was a
ton of movement last week. It will likely consist of discussion around
this review to kick things off:
https://review.openstack.org/#/c/79435/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Minutes for 4 March Meeting

[Brian Curtin]

Today was the second python-openstacksdk meeting

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-04-19.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-04-19.00.txt
Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-04-19.00.log.html

Action Items:
1. Remove the existing API strawman (https://review.openstack.org/#/c/75362/)
2. Sketch out a core HTTP layer to build on
3. Write a rough Identity client

The next meeting is scheduled for Tuesday 11 March at 1900 UTC / 1300 CST.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python-openstacksdk] Meeting Tuesday 4 March - 19:00 CST

[Brian Curtin]

Reminder that tomorrow we're back on the meeting schedule after having
last week off. Extra special note that the meeting is moved up a day
to Tuesday instead of being on a Wednesday last time.

https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting

Date/Time: Tuesday 4 March - 19:00 UTC / 1pm CST

IRC channel: #openstack-meeting-3

Meeting Agenda:
https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK

About the project:
https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK

If you have questions, all of us lurk in #openstack-sdks on freenode!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-openstacksdk] Meeting minutes, and Next Steps/new meeting time.

[Brian Curtin]

On Thu, Feb 20, 2014 at 12:02 PM, Jesse Noller
jesse.nol...@rackspace.com wrote:
 Hi Everyone;

 Our first python-openstack meeting was awesome: and I really want to thank 
 everyone who came, and for Doug teaching me the meeting bot :)

 Minutes:
 http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-02-19-19.01.html
 Minutes 
 (text):http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-02-19-19.01.txt
 Log:
 http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-02-19-19.01.log.html

 Note that coming out of this we will be moving the meetings to Tuesdays, 
 19:00 UTC / 1pm CST starting on Tuesday March 4th. Next week there will not 
 be a meeting while we discuss and flesh out next steps and requested items 
 (API, names, extensions and internal HTTP API).

 If you want to participate: please join us on free node: #openstack-sdks

 https://wiki.openstack.org/wiki/PythonOpenStackSDK

As was discussed in the meeting, that page is now moved under and
referenced from https://wiki.openstack.org/wiki/SDK-Development (also
linked from /SDKs). There's a redirect in place on the previous
location, but it now lives at
https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Swift] Porting swiftclient to Python 3?

[Brian Curtin]

Hi,

I just had a look at the python-swiftclient reviews in Gerrit and noticed that 
Kui Shi and I are working on the same stuff, but I'm guessing Kui didn't see 
that I had proposed a number of Python 3 changes from a few weeks ago. Now that 
there are reviews and a web of dependent branches being maintained by both of 
us, how should this proceed?

I don't want to waste anyone's time with two sets of branches to develop and 
two sets of patches to review.

Brian
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Swift] Porting swiftclient to Python 3?

[Brian Curtin]

On Oct 12, 2013, at 5:59 PM, John Dickinson m...@not.mn wrote:

 Co-reviewing each other's patches and discussing changes in #openstack-swift 
 would be good ways to ensure that you are working in the same direction.
 
 --John

Kui ended up abandoning his changes and I'm going to review them to incorporate 
them into mine, then we'll move forward that way. Easy enough :)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Python 3

[Brian Curtin]

On Jul 23, 2013, at 4:32 PM, Doug Hellmann 
doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote:




On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton 
lo...@bacoosta.commailto:lo...@bacoosta.com wrote:

I'm sure this has been asked before, but what exactly is the plan for Python 3 
support?

Is the plan to support 2 and 3 at the same time? I was looking around for a 
blue print or something but I can't seem to find anything.

If Python 3 support is part of the plan, can I start running 2to3 and making 
edits to keep changes compatible with Python 2?

Eric replied with details, but I wanted to address the question of 2to3.

Using 2to3 is no longer the preferred way to port to Python 3. With changes 
that landed in 3.3, it is easier to create code that will run under python 2.7 
and 3.3, without resorting to the translation steps that were needed for 
3.0-3.2. Chuck Short has landed a series of patches modifying code by hand for 
some cases (mostly print and exceptions) and by using the six library in others 
(for iteration and module renaming).

Speaking of preferred ways to port, has there been any discussion about which 
version takes precedence when we have to do different things? For example, with 
imports, should we be trying the 2.x name first and falling back to 3.x on 
ImportError, or vice versa?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Usage of mox through out the Openstack project.

[Brian Curtin]

On Jul 24, 2013, at 1:12 PM, Chuck Short 
chuck.sh...@canonical.commailto:chuck.sh...@canonical.com
 wrote:

Hi,


The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test suites 
in the Openstack project is quite extensive. This is probably due to the fact 
that it is the most familiar mocking object framework for most python 
developers.

However there is big drawback with using mox across all of the OpenStack 
projects is that it is not python3 compatible. This makes python3 compliance 
problematic because we want the test suites to be compatible as well.

While thinking about this problem for a while now, while helping porting 
OpenStack over to python3 there is a couple of options that as a project can do 
as a whole:

1. Change mox usage to more python3 friendly such as mock. 
(https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of code 
churn in the projects as we move away from mox to mock.

2. Use the python3 fork called pymox (https://github.com/emonty/pymox). This 
project has reasonable compatibility with mox and is python3 compatible. Using 
this option causes less code churn. IMHO this would be the better option.

I would like to hear peoples opinion on this.

Moving towards the standard library's unittest.mock for 3 and the external 
package for 2 is what I've done in the past, but I moved away from mocker and 
another one I forget, not mox.

Are there usages of mox that aren't served by mock? Code churn sucks, but if 
something has to change, I think there's value in moving toward the standard 
facilities if they'll do the job.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Python 3

[Brian Curtin]

On Jul 24, 2013, at 1:27 PM, Eric Windisch 
e...@cloudscaling.commailto:e...@cloudscaling.com
 wrote:


Speaking of preferred ways to port, has there been any discussion about which 
version takes precedence when we have to do different things? For example, with 
imports, should we be trying the 2.x name first and falling back to 3.x on 
ImportError, or vice versa?

Are we having it now? My belief here is we should be following the principle of 
ask forgiveness, not permission. Try Python 3 and then fallback to Python 2 
whenever possible.

That's my belief and preference as well.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Python 3

[Brian Curtin]

On Jul 23, 2013, at 3:51 PM, Eric Windisch 
e...@cloudscaling.commailto:e...@cloudscaling.com
 wrote:




On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton 
lo...@bacoosta.commailto:lo...@bacoosta.com wrote:

I'm sure this has been asked before, but what exactly is the plan for Python 3 
support?

Is the plan to support 2 and 3 at the same time? I was looking around for a 
blue print or something but I can't seem to find anything.

I suppose a wiki page is due.  This was discussed at the last summit: 
https://etherpad.openstack.org/havana-python3

The plan is to support Python 2.6+ for the 2.x series and Python 3.3+. This 
effort has begun for libraries (oslo) and clients. Work is appreciated on the 
primary projects, but will ultimately become stalled if the library work is not 
first completed.

FWIW, I came across https://wiki.openstack.org/wiki/Python3Deps and updated 
routes, which currently works with 3.3. One small step, for free!

I'm a newcomer to this list, but I'm a CPython core contributor and am working 
in Developer Relations at Rackspace, so supporting Python 3 is right up my 
alley.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev