Re: [openstack-dev] [Nova] Add config option for real deletes insteadof soft-deletes

[Luo Gangyi]

Hi, Artom


I checked my cluster (20 compute nodes fully operated for 5 month, with 258 VMs 
and 112 users),
the datebase size of nova only 1.5MB. 


So, is it necessary to do the cleanup?


--
Luo gangyiluogan...@chinamobile.com



 




-- Original --
From:  "Artom Lifshitz";;
Date:  Wed, Apr 22, 2015 05:42 AM
To:  "openstack-dev"; 

Subject:  [openstack-dev] [Nova] Add config option for real deletes insteadof 
soft-deletes



Hello,

I'd like to gauge acceptance of introducing a feature that would give operators
a config option to perform real database deletes instead of soft deletes.

There's definitely a need for *something* that cleans up the database. There
have been a few attempts at a DB purge engine [1][2][3][4][5], and archiving to
shadow tables has been merged [6] (though that currently has some issues [7]).

DB archiving notwithstanding, the general response to operators when they   

mention the database becoming too big seems to be "DIY cleanup."

I would like to propose a different approach: add a config option that turns
soft-deletes into real deletes, and start telling operators "if you turn this
on, it's DIY backups."

Would something like that be acceptable and feasible? I'm ready to put in the
work to implement this, however searching the mailing list indicates that it
would be somewhere between non trivial and impossible [8]. Before I start, I
would like some confidence that it's closer to the former than the latter :)

Cheers!

[1] https://blueprints.launchpad.net/nova/+spec/db-purge-engine
[2] https://blueprints.launchpad.net/nova/+spec/db-purge2
[3] https://blueprints.launchpad.net/nova/+spec/remove-db-archiving
[4] https://blueprints.launchpad.net/nova/+spec/database-purge
[5] https://blueprints.launchpad.net/nova/+spec/db-archiving
[6] https://review.openstack.org/#/c/18493/
[7] https://review.openstack.org/#/c/109201/
[8] 
http://lists.openstack.org/pipermail/openstack-operators/2014-November/005591.html

__
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] [neutron][lbaas] adding lbaas core

[santosh sharma]

Congrats Phil.

Santosh

On Wed, Apr 22, 2015 at 9:38 AM, Vijay Venkatachalam <
vijay.venkatacha...@citrix.com> wrote:

> Congratulations Phil!
>
>
> -Original Message-
> From: Tom Creighton [mailto:tom.creigh...@rackspace.com]
> Sent: Wednesday, 22 April 2015 12:14 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core
>
> Congratulations Phil!
>
>
>
> > On Apr 21, 2015, at 11:54 AM, Doug Wiegley 
> wrote:
> >
> > It’s been a week, welcome Phil.
> >
> > Thanks,
> > doug
> >
> >
> >> On Apr 13, 2015, at 2:39 PM, Doug Wiegley 
> wrote:
> >>
> >> Hi all,
> >>
> >> I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy,
> did a bunch of work on the ref impl for lbaasv2, and and I'll let the
> numbers[1] speak for themselves.
> >>
> >> Existing lbaas cores, please vote.  All three of us.  :-)
> >>
> >> [1] http://stackalytics.com/report/contribution/neutron-lbaas/30
> >>
> >> Thanks,
> >> doug
> >>
> >>
> >
> >
> > __
> >  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
>



-- 
Santosh
__
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] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management

[Miguel Angel Ajo Pelayo]

The rally process (email based) doesn’t seem scalable enough for the neutron 
case
IMHO, but I agree that a voting system doesn’t differ too much from launchpad
and that it can be gamed.

> On 22/4/2015, at 1:21, Assaf Muller  wrote:
> 
> Just to offer some closure, it seems like the voting idea was shot down with
> the energy of a trillion stars, yet the general idea of offering an easy way
> for users to request features makes sense. Expect to see ideas of how
> to implement this soon...
> 
> - Original Message -
>> 
>>> On Apr 10, 2015, at 11:04 AM, Boris Pavlovic  wrote:
>>> 
>>> Hi,
>>> 
>>> I believe that specs are too detailed and too dev oriented for managers,
>>> operators and devops.
>>> They actually don't want/have time to write/read all the stuff in specs and
>>> that's why the communication between dev & operators community is a
>>> broken.
>>> 
>>> I would recommend to think about simpler approaches like making mechanism
>>> for proposing features/changes in projects.
>>> Like we have in Rally:
>>> https://rally.readthedocs.org/en/latest/feature_requests.html
>>> 
>>> This is similar to specs but more concentrate on WHAT rather than HOW.
>> 
>> +1
>> 
>> I think the line between HOW and WHAT are too often blurred in Neutron.
>> Unless we’re able to improve our ability to communicate at an appropriate
>> level of abstraction with non-dev stakeholders, meeting their needs will
>> continue to be a struggle.
>> 
>> 
>> Maru
>> __
>> 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

Miguel Angel Ajo




__
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] [neutron] [docs] Networking Guide Doc Day - April 23rd

[Edgar Magana]

Dear Ruijig,

As Sean already mentioned, those are not private branches. Let me explain you, 
in order to facilitate the collaboration from new authors on this new guide, we 
decided to use these git repos with .rst format.
So, part of the work needed for the networking guide during this doc day is to 
move the content from this repos to the openstack-manuals repo under the 
networking section.

Again, here an example: https://review.openstack.org/#/c/174693/

Thanks,

Edgar

From: , Ruijing mailto:ruijing@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 21, 2015 at 5:38 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 
23rd

Hi, Edgar,

The following documents are still in private branch:

Scenario 1a - Legacy Content - Ready for conversion to 
RST
Scenario 1b - Legacy Content - Ready for conversion to 
RST
Scenario 2 - High availability (DVR and Open vSwitch) Content - Ready for 
conversion to 
RST
Scenario 3b - High availability (L3 HA and Linux Bridge) Content - Work in 
Progress

Thanks,
-Ruijing

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Tuesday, April 21, 2015 10:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 
23rd

Hello,

Which Docs are you referring?  Please, point me to the specific Docs in private 
branches to find out the process to move them to public.

Thanks,

Edgar

From: , Ruijing mailto:ruijing@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 20, 2015 at 9:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 
23rd

Hi, Edgar

Some docs are still in private branch. Can we move to public branch for 
reviewing & submitting patches?

Thanks,
-Ruijing

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Saturday, April 18, 2015 2:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

Hello Folks,

I would like to invite all available contributors to help us to complete the 
OpenStack Networking Guide.

We are having a Networking Doc Day on April 23rd in order to review the current 
guide and make a big push on its content.
Let's use both the Neutron and Docs IRC channels:
#openstack-neutron
#openstack-doc

All the expected content is being described in the TOC:
https://wiki.openstack.org/wiki/NetworkingGuide/TOC

Information for Doc contributors in here:
https://wiki.openstack.org/wiki/Documentation/HowTo#Edit_OpenStack_RST_and.2For_DocBook_documentation

We have prepared an etherpad to coordinate who is doing what:
https://etherpad.openstack.org/p/networking-guide

There are so many ways you can contribute:

  *   Assign to yourself one of the available chapters
  *   Review the current content and open bugs if needed
  *   Review the existing gerrit commit if you are familiar with the information
  *   Be available on IRC to answer some questions about configuration details 
or functionality
  *   Cheering at the contributors!
Do not hesitate in contacting me for any questions.

Cheers!

Edgar Magana
IRC: emagana
emag...@gmail.com
edgar.mag...@workday.com
__
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] [Glance] Open glance-drivers to all glance-cores

[Nikhil Komawar]

Hello all,

With all due respect to all the Glance core-reviewers (who are doing an 
excellent job, by the way), please NO. First reaction that came to my mind 
after reading the title: What might be the thinking behind this, what is the 
direction this is driving the project towards, what’s next, open Glance core 
reviewers to all committers? I think not.

The prime reason:-
===
Glance “drivers” is a role and very much like any other role, it revolves 
around responsibilities. The authority aspect of this role is a side-effect and 
a privilege given to help perform these responsibilities effectively. 
Similarly, Glance "core-reviewers" more commonly called as Glance cores is 
another responsibility. It revolves around managing the code that is proposed 
to be merged to the project code bases. So, how can something that’s approved 
by the drivers and not approved by the core reviewers get into the project? 
Although, the role played and the authority imposed may be different by both 
these groups, however that effect is observed by the community on the code 
proposed.

The specs are open to the community and have set expectations for providing the 
details around subtle aspects like Deployer Impact, Security Impact, Developer 
Impact, etc. So, all of these groups can point out to the author if the 
respective expectations aren’t met. And the timely provided feedback will have 
to be weighed in by the drivers. As the name of the role suggests, these people 
are expected to get things resolved and help drive the priorities of the 
program.

How were the priorities set?
=
Well, this is very well known; during the Summits, mini summits, various 
meetings, mailing list discussions, etc.

What are the factors a driver must look into while providing feedback?
=
We are contributing to a Foundation that supports Open Source software. We 
promote Open Community discussions. Besides these important considerations, a 
thorough guideline for providing feedback is documented at [1]. 

How do they help drive the program?

*They provide feedback that help support the important paradigms of (open but 
in general) software evolution: Supportability, Maintainability, Elasticity, 
Scalability, Stability, etc.
* They are proactive in providing feedback on different fronts: design 
patterns, OpenStack coherence, cross-project interactions, developer 
perspectives, operator perspectives, security perspective, testing, dependency, 
use-cases, adoptability that can include subset of  user research, market 
research, competition research, interoperability etc
* They help prioritize the code that is planned to be reviewed in a cycle and 
sometimes take ownership of a spec to see it though by discussing with 
different groups, reviewers, cross project liaisons, meetings within and 
outside of the project.
* More importantly they provide timely feedback of the specs that have been 
prioritized in the beginning of cycle and attempt to provide prudent feedback 
on other specs.

While I see that some of the core reviewers help the project in many of the 
above aspects and are good candidates for drivers, being a driver is an added 
responsibility. We should make every effort to set the right expectations on 
the same and encourage great developers become core-reviewers without being 
bogged down by this added burden. Hence, we have a clear separation of concern 
and do not have a strong dependency on either of the responsibility.

About the ability to scale and the ACLs on the specs:
===
I have to agree that our feedback time and thoroughness has lacked severely for 
the past few cycles. However, we must note that the community is growing and 
sometimes we need to bear through the transition phase. We have had a mission 
statement change and a few related features are still spunkily trying to get 
merged. I am glad that you brought up the feedback time on the specs, as this 
also applies to the feedback time on feature-code. For example, Artifacts 
reviews did not get much attention from the existing set of core-reviewers. How 
do we solve that first? If we are going to scale drivers, we first need to 
commit to be able to review features that are earlier promised to land. Adding 
more features that come later on the priority list of the program with the help 
of a bigger driver team and not providing early feedback to top priority 
reviews doesn’t make much sense.

Clarity and transparency:
=
Historically, the feedback has primarily been given at the summits and at 
mini-summits. Any strong objections have been sincerely discussed and I’ve been 
part of most of them over the last few years. So, personally I did not have 
issues around clarity and transparency of the feedback. I have seen any 
features that needed feedback from variety of groups have been discussed at 

Re: [openstack-dev] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Tue, Apr 21, 2015 at 9:33 PM, Robert Collins
 wrote:
> Hello everybody, I'm announcing my candidacy for the TC.
>
> I loved Jay's list of reasons [not ]to vote for him - and I'd like you
> to apply those to me too :).
> [http://lists.openstack.org/pipermail/openstack-dev/2015-April/062234.html]
>
> I think OpenStack is facing several key challenges at the moment.
>
> We've scaled our community but progress on scaling individual projects
> is slower. This is a complicated, thorny project, with many
> contributing factors. Everything from the basic primitives we make
> consistently available (such as exposing notifications to API clients,
> or what our RPC layer can do) through social factors (who can review,
> what reviews are for) and the sheer technical complexity involved in
> our CI system. The IT world hasn't slowed down since OpenStack was
> founded, and there is more and more need for us to move fast and
> execute well on the desires of our contributors - because those
> desires are driven by a need to solve real problems they [or their
> users/customers] are facing.
>
> Our product (OpenStack) is becoming balkanized. Operations that should
> be easy and consistent across many clouds are not, and it is becoming
> harder. Again there are many contributing factors: each service has
> its own domain with gnarly backends, different things that are slow or
> fast or flaky, and a different group of engineers discussing what the
> API should look like, how it should behave, and what is or isn't in
> scope. OpenStackClient as a consistent Python API to such things is a
> good step, but the heart of the problem lies in how we're defining the
> interface users use. We need to find some way to bring together the
> folk building the individual services to provide a consistent
> experience for users. Our APIs need to be predictable, simple and easy
> to work with.
>
> And these join together to form the third challenge: delivering on our
> vision: "to produce the ubiquitous Open Source Cloud Computing
> platform that will meet the needs of public and private clouds
> regardless of size, by being simple to implement and massively
> scalable''. Thierry put it well when he said we had been caught in the
> middle tier - neither very small nor very large clouds are a good fit
> for OpenStack. We're failing many potential users because of this.
>
> Last time I was on the TC I felt I helped OpenStack, but I did not run
> for re-election because I knew I had not helped as much as I could,
> and I wanted to avoid trying to eek out enough time to do so. My lack
> of time was due to being a PTL at the same time. I am not a PTL - and
> won't run for PTL in any project if I'm on the TC; I no longer believe
> there is enough time in a week to do justice to both the PTL and TC
> offices. If elected I'll be able to devote the majority of my time to
> the TC and related issues - making me much more effective - so I can
> help shift the dial on all the challenges we face.
>
> -Rob
>
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> __
> 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



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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][releases] upcoming library releases to unfreeze requirements in master

[Robert Collins]

On 22 April 2015 at 08:53, Matt Riedemann  wrote:
>
>
> On 4/21/2015 2:44 PM, Doug Hellmann wrote:
>>
>> Excerpts from Doug Hellmann's message of 2015-04-21 13:11:09 -0400:
>>>
>>> I'm working on releasing a *bunch* of libraries, including clients, from
>>> their master branches so we can thaw the requirements list for the
>>> liberty cycle. As with any big operation, this may be disruptive. I
>>> apologize in advance if it is, but we cannot thaw the requirements
>>> without making the releases so we need them all.
>>>
>>> Here's the full list, in the form of the release script I am running,
>>> in case you start seeing issues and want to check if you were
>>> affected:
>>
>>
>> OK, this is all done. I have verified that all of the libraries are on
>> PyPI and I have sent the release notes (sometimes several copies, at no
>> extra charge to you -- seriously, sorry about the noise).
>>
>> Doug
>>
>> __
>> 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
>>
>
> And the gate is wedged. :)
>
> https://bugs.launchpad.net/openstack-gate/+bug/1446847

Endish of my workday, but https://review.openstack.org/#/c/176113/ has
some promise. It doesn't install the 'right' versions- thats something
we're going to have to circle back on, but it does run the tests
successfully, which should unwedge us and let us take a little more
time over the what-gets-installed issue.

I believe Sean was proposing to disable grenade temporarily.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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-dev] TC Candidacy

[Robert Collins]

Hello everybody, I'm announcing my candidacy for the TC.

I loved Jay's list of reasons [not ]to vote for him - and I'd like you
to apply those to me too :).
[http://lists.openstack.org/pipermail/openstack-dev/2015-April/062234.html]

I think OpenStack is facing several key challenges at the moment.

We've scaled our community but progress on scaling individual projects
is slower. This is a complicated, thorny project, with many
contributing factors. Everything from the basic primitives we make
consistently available (such as exposing notifications to API clients,
or what our RPC layer can do) through social factors (who can review,
what reviews are for) and the sheer technical complexity involved in
our CI system. The IT world hasn't slowed down since OpenStack was
founded, and there is more and more need for us to move fast and
execute well on the desires of our contributors - because those
desires are driven by a need to solve real problems they [or their
users/customers] are facing.

Our product (OpenStack) is becoming balkanized. Operations that should
be easy and consistent across many clouds are not, and it is becoming
harder. Again there are many contributing factors: each service has
its own domain with gnarly backends, different things that are slow or
fast or flaky, and a different group of engineers discussing what the
API should look like, how it should behave, and what is or isn't in
scope. OpenStackClient as a consistent Python API to such things is a
good step, but the heart of the problem lies in how we're defining the
interface users use. We need to find some way to bring together the
folk building the individual services to provide a consistent
experience for users. Our APIs need to be predictable, simple and easy
to work with.

And these join together to form the third challenge: delivering on our
vision: "to produce the ubiquitous Open Source Cloud Computing
platform that will meet the needs of public and private clouds
regardless of size, by being simple to implement and massively
scalable''. Thierry put it well when he said we had been caught in the
middle tier - neither very small nor very large clouds are a good fit
for OpenStack. We're failing many potential users because of this.

Last time I was on the TC I felt I helped OpenStack, but I did not run
for re-election because I knew I had not helped as much as I could,
and I wanted to avoid trying to eek out enough time to do so. My lack
of time was due to being a PTL at the same time. I am not a PTL - and
won't run for PTL in any project if I'm on the TC; I no longer believe
there is enough time in a week to do justice to both the PTL and TC
offices. If elected I'll be able to devote the majority of my time to
the TC and related issues - making me much more effective - so I can
help shift the dial on all the challenges we face.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [neutron][lbaas] adding lbaas core

[Vijay Venkatachalam]

Congratulations Phil!


-Original Message-
From: Tom Creighton [mailto:tom.creigh...@rackspace.com] 
Sent: Wednesday, 22 April 2015 12:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core

Congratulations Phil!



> On Apr 21, 2015, at 11:54 AM, Doug Wiegley  
> wrote:
> 
> It’s been a week, welcome Phil.
> 
> Thanks,
> doug
> 
> 
>> On Apr 13, 2015, at 2:39 PM, Doug Wiegley  
>> wrote:
>> 
>> Hi all,
>> 
>> I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a 
>> bunch of work on the ref impl for lbaasv2, and and I'll let the numbers[1] 
>> speak for themselves.
>> 
>> Existing lbaas cores, please vote.  All three of us.  :-)
>> 
>> [1] http://stackalytics.com/report/contribution/neutron-lbaas/30
>> 
>> Thanks,
>> doug
>> 
>> 
> 
> 
> __
>  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] [neutron] [docs] Networking Guide Doc Day - April 23rd

[Sean M. Collins]

Those are not private branches. We are in the process of converting and
importing them, and is covered in the wiki.

https://wiki.openstack.org/wiki/NetworkingGuide/TOC#Deployment_Scenarios

Also, The first scenario is being imported in the following review:

https://review.openstack.org/#/c/174693/

-- 
Sean M. Collins

__
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] [oslo][policy][neutron] oslo.policy API is not powerful enough to switch Neutron to it

[Doug Hellmann]

Excerpts from Ihar Hrachyshka's message of 2015-04-17 14:45:58 +0200:
> Hi,
> 
> tl;dr neutron has special semantics for policy targets that relies on
> private symbols from oslo.policy, and it's impossible to introduce
> this semantics into oslo.policy itself due to backwards compatibility
> concerns, meaning we need to expose some more symbols as part of
> public API for the library to facilitate neutron switch to it.
> 
> ===
> 
> oslo.policy was graduated during Kilo [1]. Neutron considered the
> switch to it [2], but failed to achieve it because some library
> symbols that were originally public (or at least looked like public)
> in policy.py from oslo-incubator, became private in oslo.policy.
> Specifically, Neutron policy code [3] relies on the following symbols
> that are now hidden inside oslo_policy._checks (note the underscore in
> the name of the module that suggests we cannot use the module directly):
> 
> - - RoleCheck
> - - RuleCheck
> - - AndCheck

I'm not sure I followed all of the rest of what you wrote below, but it
seems like this is the real problem. We are pretty aggressive about
making things private when we release a new library, because it's easier
to make them public later if we need to than it is to make public things
private.

In this case, it looks like we made some symbols private even though
they were already being used, and that seems like a mistake on our part.
So, if we make those public, would that address the issues with neutron
adopting the library?

> 
> Those symbols are used for the following matters:
> (all the relevant neutron code is in neutron/policy.py)
> 
> 1. debug logging in case policy does not authorize an action
> (RuleCheck, AndCheck) [log_rule_list]
> 
> 2. filling in admin context with admin roles (RoleCheck, RuleCheck,
> AndCheck/OrCheck internals) [get_admin_roles]
> 
> 3. aggregating core, attribute and subattribute policies (RuleCheck,
> AndCheck) [_prepare_check]
> 
> 
> == 1. debug logging in case policy does not authorize an action ==
> 
> Neutron logs rules that failed to match if policy module does not
> authorize an action. Not sure whether Neutron developers really want
> to have those debug logs, and whether we cannot just kill them to
> avoid this specific usage of private symbols; though it also seems
> that we could easily use __str__ that is present for all types of
> Checks instead. So it does not look like a blocker for the switch.
> 
> 
> == 2. filling in admin context with admin roles ==
> 
> Admin context object is filled with .roles attribute that is a list of
> roles considered granting admin permissions [4]. The attribute would
> then be used by plugins that would like to do explicit policy checks.
> As per Salvatore, this attribute can probably be dropped now that all
> plugins and services don't rely on it (Salvatore mentioned lbaas
> mixins as the ones that previously relied on it, but are now not doing
> it since service split from neutron tree (?)).
> 
> The problem with dropping the .roles attribute from context object in
> Liberty is that we, as a responsible upstream with lots of plugins
> maintained out-of-tree (see the ongoing vendor decomposition effort)
> would need to support the attribute while it's marked as deprecated
> for at least one cycle, meaning that if we don't get those oslo.policy
> internals we rely on in Liberty, we would need to postpone the switch
> till Mizzle, or rely on private symbols during the switch (while a new
> release of oslo.policy can easily break us).
> 
> (BTW the code to extract admin roles is not really robust and has
> bugs, f.e. it does not handle AndChecks that could be used in
> context_is_admin. In theory, 'and' syntax would mean that both roles
> are needed to claim someone is an admin, while the code to extract
> admin roles handles 'and' the same way as 'or'. For the deprecation
> time being, we may need to document this limitation.)
> 
> 
> == 3. aggregating core, attribute and subattribute policies ==
> 
> That's the most interesting issue.
> 
> For oslo.policy, policies are described as "target: rule", where rule
> is interpreted as per registered checks, while target is opaque to the
> library.
> 
> Neutron extended the syntax for target as:
> target[:attribute[:subattribute]].

This extension of the syntax is a bit more problematic. We should
talk about a way to fold that into the library so it can be used
consistently across projects. FTR, making it less easy to extend
common behaviors in application-specific ways is one reason we like
to make symbols private whenever possible.

Although it is not well-documented, we do support chained attribute
names on the right-side of the expression [1]. Does that do what you are
describing here, or do we need to extend it to support a similar syntax
on the left side of the expression.

[1] 
http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/_checks.py#n288

[snip]

> So the question to oslo.policy maintainers is: w

Re: [openstack-dev] [neutron] neutron DB upgrade

[Guo, Ruijing]

Thanks for your detail explanation.

I agree with you that we still use DB upgrade when fresh installation.

Yes. It happened to me that unused vendor DB upgrade failure causes neutron DB 
upgrade failure.
I have little concerns about adding whole DB upgrade in one directory 
alembic_migrations/versions.

It is difficult for devops to debug/workaround the issue.

I suggest to separate according to components or enforce file name as 
__.py.

If I don’t use the component and DB for that component upgrade fails, I can 
safely delete **.

Thanks,
-Ruijing


From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Tuesday, April 21, 2015 9:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] neutron DB upgrade



On 21 April 2015 at 14:25, Guo, Ruijing 
mailto:ruijing@intel.com>> wrote:
Somebody can help me to understand why neutron DB is needed upgrade even in 
refresh installation unlike other components.

From my understanding,  DB upgrade is risky and needed when upgrade.

Alembic is a fairly reliable tool for managing DB upgrades.
Also there are enough tests in place to ensure the sanity of each "db 
migration" and that the DB schema is always in sync with business logic's data 
model.


Release A should have schema A and Release B should have schema B.

This will make really difficult doing testing during the development cycle. 
While all interim migrations added during the release cycle can be squashed 
into a single migration provided at release time, this action will probably 
transform a relatively safe process into a risky one, as there will be little 
time to react to issues introduced by that single migration.


Only upgrade A to B need to upgrade DB.

This is what happens for most users. However there still are a few which more 
or less closely follow trunk - that is to say they're not tied to any specific 
release.
Also, this does not apply to developers and CI (which is ultimately one of the 
principal tools we use to ensure what we deliver is not completely rubbish).


In the same time,  can we separate neutron DB as vendor DB & non-vendor DB?

We had vendor or plugin specific migrations until Juno. When he had these kind 
of conditional migrations doing DB upgrades was very risky. DB schema 
management has become a lot simpler and safer since we unified the schema.

However, as a part of the vendor plugin split out there will be eventually a 
next step where all vendor-specific tables are moved into their own dbs.
Are tables for plugins which are not ML2 causing you any problem?


1.  For that case, we can upgrade vendor DB if we use some vendor scenario.

2. we already separate vendor code from neutron code base.

Thanks,
-Ruijing

__
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] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Tue, Apr 21, 2015 at 5:29 PM, Jay Pipes  wrote:
> Hey Stackers,
>
> I'd like to continue serving on the Technical Committee, and I'm asking for
> your votes in the upcoming elections.
>
> Here's my ask of you, dear voter:
>
> #1.
>
> Please do NOT vote for me just because you may recognize my name being
> around the OpenStack community for a long time. Being a long-time member of
> something does not make me any more able to offer creative solutions to our
> problems than someone who's been in our community for a year or so.
>
> #2.
>
> Please do NOT vote for me just because I'm currently on the Technical
> Committee and have served on the TC in the past. There is no "carry-over"
> power that someone that has served on the TC in the past brings with them to
> bear on future TCs. Ideas and a person's ability to debate the issues fairly
> and concisely are what determines the effectiveness of a TC member, not the
> length of time they have served on the TC.
>
> #3.
>
> Please do NOT vote for me because you think I am (often unduly) outspoken or
> critical about certain particular issues that you find dear. Even if you
> hate XML as much as I do or would love to see API extensions die in a fire,
> you shouldn't vote for me just because you happen to agree with me on those
> particulars. The TC is not about squabbling and religious wars. It's about
> BIG ideas and listening to the viewpoints of others and seeing how the
> OpenStack contributor ecosystem can be shaped by those ideas in meaningful
> ways.
>
> #4.
>
> Please DO vote for me because you think I will fairly consider the
> viewpoints of the other TC members -- whomever they happen to be.
>
> #5.
>
> Please DO vote for me because you think I will be diligent in gathering the
> feedback of our disparate and excellent contributor teams, and critically,
> use that feedback to make our OpenStack community better for us all.
>
> #6.
>
> Please DO vote for me if you believe I will be an advocate for OpenStack's
> contributor community in the broader open source ecosystem, and continue to
> further the ideals of our four Opens [1].
>
> Thanks much,
> -jay
>
> [1] https://wiki.openstack.org/wiki/Open
>
> __
> 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



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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] [neutron] [docs] Networking Guide Doc Day - April 23rd

[Guo, Ruijing]

Hi, Edgar,

The following documents are still in private branch:

Scenario 1a - Legacy Content - Ready for conversion to 
RST
Scenario 1b - Legacy Content - Ready for conversion to 
RST
Scenario 2 - High availability (DVR and Open vSwitch) Content - Ready for 
conversion to 
RST
Scenario 3b - High availability (L3 HA and Linux Bridge) Content - Work in 
Progress

Thanks,
-Ruijing

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Tuesday, April 21, 2015 10:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 
23rd

Hello,

Which Docs are you referring?  Please, point me to the specific Docs in private 
branches to find out the process to move them to public.

Thanks,

Edgar

From: , Ruijing mailto:ruijing@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 20, 2015 at 9:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 
23rd

Hi, Edgar

Some docs are still in private branch. Can we move to public branch for 
reviewing & submitting patches?

Thanks,
-Ruijing

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Saturday, April 18, 2015 2:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

Hello Folks,

I would like to invite all available contributors to help us to complete the 
OpenStack Networking Guide.

We are having a Networking Doc Day on April 23rd in order to review the current 
guide and make a big push on its content.
Let's use both the Neutron and Docs IRC channels:
#openstack-neutron
#openstack-doc

All the expected content is being described in the TOC:
https://wiki.openstack.org/wiki/NetworkingGuide/TOC

Information for Doc contributors in here:
https://wiki.openstack.org/wiki/Documentation/HowTo#Edit_OpenStack_RST_and.2For_DocBook_documentation

We have prepared an etherpad to coordinate who is doing what:
https://etherpad.openstack.org/p/networking-guide

There are so many ways you can contribute:

  *   Assign to yourself one of the available chapters
  *   Review the current content and open bugs if needed
  *   Review the existing gerrit commit if you are familiar with the information
  *   Be available on IRC to answer some questions about configuration details 
or functionality
  *   Cheering at the contributors!
Do not hesitate in contacting me for any questions.

Cheers!

Edgar Magana
IRC: emagana
emag...@gmail.com
edgar.mag...@workday.com
__
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][releases] upcoming library releases to unfreeze requirements in master

[Joe Gordon]

On Tue, Apr 21, 2015 at 4:35 PM, Joe Gordon  wrote:

>
>
> On Tue, Apr 21, 2015 at 1:53 PM, Matt Riedemann <
> mrie...@linux.vnet.ibm.com> wrote:
>
>>
>>
>> On 4/21/2015 2:44 PM, Doug Hellmann wrote:
>>
>>> Excerpts from Doug Hellmann's message of 2015-04-21 13:11:09 -0400:
>>>
 I'm working on releasing a *bunch* of libraries, including clients, from
 their master branches so we can thaw the requirements list for the
 liberty cycle. As with any big operation, this may be disruptive. I
 apologize in advance if it is, but we cannot thaw the requirements
 without making the releases so we need them all.

 Here's the full list, in the form of the release script I am running,
 in case you start seeing issues and want to check if you were
 affected:

>>>
>>> OK, this is all done. I have verified that all of the libraries are on
>>> PyPI and I have sent the release notes (sometimes several copies, at no
>>> extra charge to you -- seriously, sorry about the noise).
>>>
>>> Doug
>>>
>>>
>>> __
>>> 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
>>>
>>>
>> And the gate is wedged. :)
>>
>> https://bugs.launchpad.net/openstack-gate/+bug/1446847
>>
>>
> Double wedged:
>
> https://bugs.launchpad.net/openstack-gate/+bug/1446882
>
>

Fixed, now we are back to being are just wedged once.


> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>>
>> __
>> 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

[openstack-dev] TC Candidacy

[Jay Pipes]

Hey Stackers,

I'd like to continue serving on the Technical Committee, and I'm asking 
for your votes in the upcoming elections.


Here's my ask of you, dear voter:

#1.

Please do NOT vote for me just because you may recognize my name being 
around the OpenStack community for a long time. Being a long-time member 
of something does not make me any more able to offer creative solutions 
to our problems than someone who's been in our community for a year or so.


#2.

Please do NOT vote for me just because I'm currently on the Technical 
Committee and have served on the TC in the past. There is no 
"carry-over" power that someone that has served on the TC in the past 
brings with them to bear on future TCs. Ideas and a person's ability to 
debate the issues fairly and concisely are what determines the 
effectiveness of a TC member, not the length of time they have served on 
the TC.


#3.

Please do NOT vote for me because you think I am (often unduly) 
outspoken or critical about certain particular issues that you find 
dear. Even if you hate XML as much as I do or would love to see API 
extensions die in a fire, you shouldn't vote for me just because you 
happen to agree with me on those particulars. The TC is not about 
squabbling and religious wars. It's about BIG ideas and listening to the 
viewpoints of others and seeing how the OpenStack contributor ecosystem 
can be shaped by those ideas in meaningful ways.


#4.

Please DO vote for me because you think I will fairly consider the 
viewpoints of the other TC members -- whomever they happen to be.


#5.

Please DO vote for me because you think I will be diligent in gathering 
the feedback of our disparate and excellent contributor teams, and 
critically, use that feedback to make our OpenStack community better for 
us all.


#6.

Please DO vote for me if you believe I will be an advocate for 
OpenStack's contributor community in the broader open source ecosystem, 
and continue to further the ideals of our four Opens [1].


Thanks much,
-jay

[1] https://wiki.openstack.org/wiki/Open

__
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][releases] upcoming library releases to unfreeze requirements in master

[Joe Gordon]

On Tue, Apr 21, 2015 at 1:53 PM, Matt Riedemann 
wrote:

>
>
> On 4/21/2015 2:44 PM, Doug Hellmann wrote:
>
>> Excerpts from Doug Hellmann's message of 2015-04-21 13:11:09 -0400:
>>
>>> I'm working on releasing a *bunch* of libraries, including clients, from
>>> their master branches so we can thaw the requirements list for the
>>> liberty cycle. As with any big operation, this may be disruptive. I
>>> apologize in advance if it is, but we cannot thaw the requirements
>>> without making the releases so we need them all.
>>>
>>> Here's the full list, in the form of the release script I am running,
>>> in case you start seeing issues and want to check if you were
>>> affected:
>>>
>>
>> OK, this is all done. I have verified that all of the libraries are on
>> PyPI and I have sent the release notes (sometimes several copies, at no
>> extra charge to you -- seriously, sorry about the noise).
>>
>> Doug
>>
>> __
>> 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
>>
>>
> And the gate is wedged. :)
>
> https://bugs.launchpad.net/openstack-gate/+bug/1446847
>
>
Double wedged:

https://bugs.launchpad.net/openstack-gate/+bug/1446882


> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __
> 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] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management

[Assaf Muller]

Just to offer some closure, it seems like the voting idea was shot down with
the energy of a trillion stars, yet the general idea of offering an easy way
for users to request features makes sense. Expect to see ideas of how
to implement this soon...

- Original Message -
> 
> > On Apr 10, 2015, at 11:04 AM, Boris Pavlovic  wrote:
> > 
> > Hi,
> > 
> > I believe that specs are too detailed and too dev oriented for managers,
> > operators and devops.
> > They actually don't want/have time to write/read all the stuff in specs and
> > that's why the communication between dev & operators community is a
> > broken.
> > 
> > I would recommend to think about simpler approaches like making mechanism
> > for proposing features/changes in projects.
> > Like we have in Rally:
> > https://rally.readthedocs.org/en/latest/feature_requests.html
> > 
> > This is similar to specs but more concentrate on WHAT rather than HOW.
> 
> +1
> 
> I think the line between HOW and WHAT are too often blurred in Neutron.
> Unless we’re able to improve our ability to communicate at an appropriate
> level of abstraction with non-dev stakeholders, meeting their needs will
> continue to be a struggle.
> 
> 
> Maru
> __
> 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] TC candidacy

[Elizabeth K. Joseph]

confirmed


On Tue, Apr 21, 2015 at 4:02 PM, Angus Salkeld  wrote:
> I'd like to announce my candidacy for the Technical Committee elections.
>
>
> This last (Kilo) cycle I have been the PTL for Heat, but will not be for
> Liberty.
>
> Because of this, if I get elected to the TC, I can dedicate a significant
> amount of time to TC duties.
>
> I have an interest in projects that exist in the upper layers in OpenStack
> (Heat, Murano, Mistral, Ceilometer/Monasca, Zaqar), so this gives me a
> slightly different viewpoint than the existing TC members (I hope this will
> be complementary).
>
>
> Topics that I am interested in pursuing:
>
>
> 1. How can the TC/PTL's better influence what developers work on?
>
> We currently have working groups and project tags, but are there other ways
> that we can encourage developers to work on global issues that users and
> operators are asking for?
>
> So if the TC came up with say 2 global "themes" every cycle, let's say "ease
> of upgrades" and "scale", what can we use as a carrot to encourage a
> developer to work on these topics rather than something else. Clearly this
> has limits, but if the user survey is screaming "we need X", it would be
> great to have a tool to help focus developers onto this.
>
> One idea might be to use stackalytics main page to show the work done on TC
> selected blueprints/bugs. We could tag particular blueprints/bugs and
> highlight the developers that have worked on these (i.e. can we use
> stackalytics as a tool to motivate developers to work on
> TC supported "themes").
>
> A note on this (some motivation for taking advantage of stackalytics):
> It looks like this commit changed the default view on stackalytics from
> commits to reviews
> https://github.com/stackforge/stackalytics/commit/eb3bebbaa66a718e284d3095dfa8f496bb1d298c
> (14 Apr 2014)
> http://stackalytics.com/?release=all&metric=commits
> http://stackalytics.com/?release=all
>
> See the sudden plateau of commits and increase in reviews after that time on
> the top graph (I am sure there are other factors at play too).
>
>
> 2. How can we better support new foundational projects that we expect other
> projects to consume.
>
> Under the new big tent model, we are welcoming more projects into the
> openstack/ code namespace while simultaneously shifting the determination of
> production-worthiness to distributors and operators. This poses a problem
> for projects like Zaqar, Mistral, and even Heat, as these projects may be
> consumed/used by other upper-layer projects. Consuming projects end up with
> lots of conditional code as they must take into account that the deployed
> cloud may not have these dependent projects installed.
>
> How can we make the end user (and inter-project) experience richer and
> friendlier with a consistent method of negotiating and discovering the
> underlying features a deployed cloud offers?
>
> Could tenant-based services/endpoints be helpful in allowing end users to
> install optional projects?
>
>
> 3. Getting notification messages to the end user.
>
> Based on this:
> http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html
>
> Other clouds provide better messaging feedback on what the infrastructure is
> doing. We are really missing this and I'd like to help to get us to the
> point where the user (that doesn't have access to the logs) can understand
> what has happened to their resources.
>
>
> I'm interested in either leading or participating in working groups from
> within the TC to address these issues.
>
>
> Thanks
> Angus Salkeld
>
> __
> 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
>



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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-dev] TC candidacy

[Angus Salkeld]

I'd like to announce my candidacy for the Technical Committee elections.


This last (Kilo) cycle I have been the PTL for Heat, but will not be for
Liberty.

Because of this, if I get elected to the TC, I can dedicate a significant
amount of time to TC duties.

I have an interest in projects that exist in the upper layers in OpenStack
(Heat, Murano, Mistral, Ceilometer/Monasca, Zaqar), so this gives me a
slightly different viewpoint than the existing TC members (I hope this will
be complementary).


Topics that I am interested in pursuing:


1. How can the TC/PTL's better influence what developers work on?

We currently have working groups and project tags, but are there other ways
that we can encourage developers to work on global issues that users and
operators are asking for?

So if the TC came up with say 2 global "themes" every cycle, let's say
"ease of upgrades" and "scale", what can we use as a carrot to encourage a
developer to work on these topics rather than something else. Clearly this
has limits, but if the user survey is screaming "we need X", it would be
great to have a tool to help focus developers onto this.

One idea might be to use stackalytics main page to show the work done on TC
selected blueprints/bugs. We could tag particular blueprints/bugs and
highlight the developers that have worked on these (i.e. can we use
stackalytics as a tool to motivate developers to work on
TC supported "themes").

A note on this (some motivation for taking advantage of stackalytics):
It looks like this commit changed the default view on stackalytics from
commits to reviews
https://github.com/stackforge/stackalytics/commit/eb3bebbaa66a718e284d3095dfa8f496bb1d298c
(14 Apr 2014)
http://stackalytics.com/?release=all&metric=commits
http://stackalytics.com/?release=all

See the sudden plateau of commits and increase in reviews after that time
on the top graph (I am sure there are other factors at play too).


2. How can we better support new foundational projects that we expect other
projects to consume.

Under the new big tent model, we are welcoming more projects into the
openstack/ code namespace while simultaneously shifting the determination
of production-worthiness to distributors and operators. This poses a
problem for projects like Zaqar, Mistral, and even Heat, as these projects
may be consumed/used by other upper-layer projects. Consuming projects end
up with lots of conditional code as they must take into account that the
deployed cloud may not have these dependent projects installed.

How can we make the end user (and inter-project) experience richer and
friendlier with a consistent method of negotiating and discovering the
underlying features a deployed cloud offers?

Could tenant-based services/endpoints be helpful in allowing end users to
install optional projects?


3. Getting notification messages to the end user.

Based on this:
http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html

Other clouds provide better messaging feedback on what the infrastructure
is doing. We are really missing this and I'd like to help to get us to the
point where the user (that doesn't have access to the logs) can understand
what has happened to their resources.


I'm interested in either leading or participating in working groups from
within the TC to address these issues.


Thanks
Angus Salkeld
__
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] [TripleO] on supporting multiple implementations of tripleo-heat-templates

[Fox, Kevin M]

I would think there's a 3rd implementation on the horizon already The 
abstraction might allow easy docker integration...

Thanks,
Kevin

From: Dan Prince [dpri...@redhat.com]
Sent: Tuesday, April 21, 2015 12:53 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] on supporting multiple implementations 
of tripleo-heat-templates

On Fri, 2015-04-17 at 15:21 +0200, Giulio Fidente wrote:
> Hi,
>
> the Heat/Puppet implementation of the Overcloud deployment seems to be
> surpassing in features the Heat/Elements implementation.
>
> The changes for Ceph are an example, the Puppet based version is already
> adding features which don't have they counterpart into Elements based.
>
> Recently we started working on the addition of Pacemaker into the
> Overcloud, to monitor the services and provide a number of 'auto
> healing' features, and again this is happening in the Puppet
> implementation only (at least for now) so I think the gap will become
> bigger.
>
> Given we support different implementations with a single top-level
> template [1], to keep other templates valid we're forced to propagate
> the params into the Elements based templates as well, even though there
> is no use for these there, see for example [2].

This was done intentionally when adding the new puppet templates. The
idea was that tripleo-heat-templates was defining a high level interface
that could be used to provision and configure a cloud with multiple
backends (tripleo-image-elements and or puppet being the current
options). It was actually a bit more work to do it this way but the idea
is that we are refining our interfaces to be more generic and correct.
In doing the puppet work we actually discovered lots of data that was
being copied into various roles that wasn't needed. And having the
working tripleo-image-elements implementation to begin with was also a
great help to speed the puppet stuff along.

>
> The extra work itself is not of great concern but I wonder if it
> wouldn't make sense to deprecate the Elements based templates at this
> point, instead of keep adding there unused parts?

You aren't really adding that many unused parts. Just a parameter here
and there right? And this is just to keep the CI jobs happy.

With regards to the specific templates for triple-image-elements for
configuration long term I'm not sure where they are headed. I don't
think there is as much interest in maintaining them so perhaps we should
deprecate them...

However, I would like to see us maintain the abstractions we have in
place in tripleo-heat-templates should another implementation come along
besides Puppet. To me this is sort of the essence of TripleO (defining
an interface to deploy a cloud). And if you are suggesting we get rid of
tripleo-image-elements just so we can then go and remove these
abstractions then I think it might be a step in the wrong direction. In
other words... regardless of what happens to the maintenance of the
tripleo-image-elements (and any associated templates) lets keep a
structure that supports multiple backends. Yes, it may cost a bit of
extra wiring here and there but I think it is worth the effort.

>  Thoughts?
>
> 1.
> https://github.com/openstack/tripleo-heat-templates/blob/master/overcloud-without-mergepy.yaml
> 2. https://review.openstack.org/#/c/173773
>
> __
> 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

__
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] [keystone] keystonemiddleware stable/juno broken

[Morgan Fainberg]

Getting a stable branch for pycadf would be consistent with the oslo
libraries and clients. I would support moving down that path rather than
mucking with bad dep resolution.

--Morgan

On Tue, Apr 21, 2015 at 10:20 AM, Brant Knudson  wrote:

>
>
> On Tue, Apr 21, 2015 at 12:10 PM, gordon chung  wrote:
>
>> __
>> > Date: Tue, 21 Apr 2015 11:12:12 -0500
>> > From: b...@acm.org
>> > To: openstack-dev@lists.openstack.org
>> > Subject: Re: [openstack-dev] [keystone] keystonemiddleware stable/juno
>> broken
>> >
>> >
>> >
>> > On Sun, Apr 19, 2015 at 2:21 PM, Brant Knudson
>> > mailto:b...@acm.org>> wrote:
>> >
>> > Ever since the stable/juno branch was created for keystonemiddleware
>> > it's been broken and there are several changes piling up there. The fix
>> > for bug 1408838 "Tests fail with new oslo.utils 1.2.1" allows the tests
>> > to pass. I cherry-picked the fix here[1].
>> >
>> > Based on the title of the bug, you'd think that capping
>> > oslo.utils<1.2.1 would be an alternative fix, but I tried installing
>> > older versions of oslo.utils and eventually it failed with a completely
>> > different error, so I think that's a dead end.
>> >
>> > [1] https://review.openstack.org/#/c/175232/
>> >
>> >
>> > So this fix has merged, but keystonemiddleware has another problem --
>> > the proposal bot posted a change to get the requirements up to date and
>> > that's failing all the -python* jobs. Looks like what's happening is
>> > that during the tox venv installation the oslo.messaging package is
>> > being updated to version 1.9.0, which is way newer than the other oslo
>> > packages and this is causing a test that uses pkg_resource to fail with
>> > a dependency issue (oslo.messaging 1.9.0 requires
>> > oslo.utils<1.5.0,>1.4.0 but global requirements has oslo.utils<1.2.0,
>> > so that's what's installed). This all appears to be related to other
>> > issues we've seen where the dep resolver isn't working as expected.
>> >
>> > I tried using an older pycadf (which, from the tox logs is where
>> > oslo.messaging is being upgraded) but it was only with a very old
>> > version of pycadf that things worked.
>>
>> does it make sense to make a stable/juno branch for pycadf and remove the
>> oslo.messaging requirement? it actually isn't a mandatory requirement and
>> was moved to test-requirements in 0.7.0
>>
>>
> Gordon -
>
> I think that would also work... if I have some time I'll take a look at
> it, or maybe someone else will get to it first.
>
> :: Brant
>
>
> __
> 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] [neutron][lbaas] adding lbaas core

[Madhusudhan Kandadai]

Congrats Phill!

On Tue, Apr 21, 2015 at 12:34 PM, Jain, Vivek  wrote:

> Congrats Phil !!
>
> Thanks,
> Vivek
>
> > On Apr 21, 2015, at 10:16 AM, Phillip Toohill <
> phillip.tooh...@rackspace.com> wrote:
> >
> > Thank you!
> >
> > Phillip V. Toohill III
> > Software Developer
> >
> > phone: 210-312-4366
> > mobile: 210-440-8374
> >
> >
> > 
> > From: Brandon Logan 
> > Sent: Tuesday, April 21, 2015 11:57 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core
> >
> > Welcome Phil!
> > 
> > From: Doug Wiegley 
> > Sent: Tuesday, April 21, 2015 11:54 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core
> >
> > It’s been a week, welcome Phil.
> >
> > Thanks,
> > doug
> >
> >
> >> On Apr 13, 2015, at 2:39 PM, Doug Wiegley 
> wrote:
> >>
> >> Hi all,
> >>
> >> I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy,
> did a bunch of work on the ref impl for lbaasv2, and and I'll let the
> numbers[1] speak for themselves.
> >>
> >> Existing lbaas cores, please vote.  All three of us.  :-)
> >>
> >> [1] http://stackalytics.com/report/contribution/neutron-lbaas/30
> >>
> >> Thanks,
> >> doug
> >
> >
> >
> __
> > 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
> >
> >
> __
> > 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
>
__
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] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

[Joe Gordon]

On Fri, Apr 17, 2015 at 1:22 AM, Victor Stinner  wrote:

> >> For the full list, see the wiki page:
> >> https://wiki.openstack.org/wiki/Python3#Core_OpenStack_projects
>
> > Thanks for updating the wiki page that is a very useful list.
> > From the looks of things, it seems like nova getting Python3 support in
> Liberty is not going to happen.
>


I based this on the wiki, but maybe I am wrong.

remaining libraries for nova:
oslo.db -- looks like it is almost there
oslo.messaging  -- same
paste -- almost there
sqlalchemy-migrate -- almost there
suds -- with the suds fork shouldn't be too hard
websockify -- unknown
libvirt-python -- unknown
mysql-python  -- alternitive looks viable.

Based on there being two unknowns, and a lot of dependencies that are just
almost there, and a few we may want to migrate off of, I was assuming
addressing those issues would make it hard for us to make nova python3
compatible for Liberty.


>
> Why? I plan to work on porting nova to Python 3. I proposed a nova session
> on Python 3 at the next OpenStack Summit at Vancouver. I plan to write a
> spec too.
>
> I'm not aware of any real blocker for nova.
>
> > What are your thoughts on how to tackle sqlalchemy-migrate? It looks
> like that is a blocker for several projects. And something I think we have
> wanted to move off of for some time now.
>
> I just checked sqlachemy-migrate. The README and the documentation are
> completly outdated, but the project is very active: latest commit one month
> ago and latest release (0.9.6) one month ago. There are py33 and py34
> environments and tests pass on Python 3.3 and Python 3.4! I didn't check
> yet, but I guess that sqlachemy-migrate 0.9.6 already works on Python 3.
> Python 3 classifiers are just missing in setup.cfg.
>
> I sent patches to update the doc, to add Python 3 classifiers and to
> upgrade requirements. The project moved to stackforge, reviews are at
> review.openstack.org:
>
>
> https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z
>
> The wiki page said that scripttest and ibm-db-sa were not Python 3
> compatible. It's no more true: scripttest is compatible Python 3, and there
> is ibm-db-sa-py3 which is Python 3 compatible.
>
> I updated the wiki page for sqlachemy-migrate.
>
> Victor
>
> __
> 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] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

[Joe Gordon]

On Tue, Apr 21, 2015 at 1:37 PM, Ian Cordasco 
wrote:

> On 4/16/15, 17:54, "Clint Byrum"  wrote:
>
> >Excerpts from Joe Gordon's message of 2015-04-16 15:15:01 -0700:
> >> On Fri, Apr 10, 2015 at 4:01 AM, Victor Stinner 
> >>wrote:
> >>
> >> > > https://wiki.openstack.org/wiki/Python3#Dependencies appears to be
> >> > fairly out of date.
> >> >
> >> > You're right. I updated this wiki page. In practice, much more
> >>OpenStack
> >> > clients, Common Libraries and Development Tools are already Python 3
> >> > compatible. I added the link to my pull request for Oslo Messaging.
> >> >
> >> > > It would be nice to get a better sense of what the remaining
> >>libraries
> >> > to port over are before the summit so we can start planning how to do
> >>the
> >> > python34 migration.
> >> >
> >> > I checked quickly. There are small libraries like pyEClib required by
> >> > Swift, but the major blocker libraries are: MySQL-Python, suds,
> >>Paste. For
> >> > oslo.db, it's already Python 3 compatible no?
> >> >
> >> >
> >> > * MySQL-Python
> >> >
> >> > MySQL-Python doesn't look to be active (last commit in january 2014).
> >> > There are multiple Python 3 pending pull requests:
> >> > https://github.com/farcepest/MySQLdb1/pulls
> >> >
> >> > Mike Bayer is evaluating PyMySQL which is Python 3 compatible:
> >> > https://wiki.openstack.org/wiki/PyMySQL_evaluation
> >> >
> >> > See also https://github.com/farcepest/moist (is it alive? is it
> >>Python 3
> >> > compatible?)
> >> >
> >> >
> >> > * suds
> >> >
> >> > There is https://bitbucket.org/jurko/suds : a fork compatible with
> >>Python
> >> > 3. Global requirements contain this comment:
> >> >
> >> > # NOTE(dims): suds is not python 3.x compatible, suds-jurko is a fork
> >>that
> >> > # works with py3x. oslo.vmware would convert to suds-jurko first then
> >>nova
> >> > # and cinder would follow. suds should be remove immediately once
> >>those
> >> > # projects move to suds-jurko for all jobs.
> >> >
> >> >
> >> > * Paste
> >> >
> >> > I already fixed Python 3 compatibility issues and my changes were
> >>merged,
> >> > but there is no release including my fixes yet :-(
> >> >
> >> > I heard that Paste is completly outdated and should be replaced. Ok,
> >>but
> >> > in practice it's still used and not Python 3 compatible.
> >> >
> >> > Workaround: use the development (git) version of Paste.
> >> >
> >> >
> >> > For the full list, see the wiki page:
> >> > https://wiki.openstack.org/wiki/Python3#Core_OpenStack_projects
> >>
> >>
> >> Thanks for updating the wiki page that is a very useful list.
> >>
> >> From the looks of things, it seems like nova getting Python3 support in
> >> Liberty is not going to happen. But we can make good progress in
> >> dependencies sorted out. By fixing the dependencies and switching a few
> >>out
> >> for better ones.
> >>
> >> What are your thoughts on how to tackle  sqlalchemy-migrate? It looks
> >>like
> >> that is a blocker for several projects. And something I think we have
> >> wanted to move off of for some time now.
> >>
> >
> >IMHO it is quite a bit easier to port something to python 3 than to
> >move off of it entirely. I'd say it's worth it for forward progress to
> >try and port sqlalchemy-migrate, even if that means the effort becomes
> >a sunk cost in a year.
>
> Also, isn’t sqlalchemy-migrate something we currently maintain (or a group
> of OpenStack developers do it for OpenStack. Can’t we work with them to
> add support for Python 3?
>

yup https://github.com/stackforge/sqlalchemy-migrate. The better question
is: 'is it worth adding support in versus moving over to alembic, since we
want to do that anyway?' I don't personally have an answer for that.


>
> __
> 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] [Zaqar] Call for adoption (or exclusion?)

[Steve Baker]

On 22/04/15 06:58, Tim Bell wrote:

This touches on many of the aspects of the Ops tagging to be discussed in
Vancouver.

What are the criteria for

- An operator to consider a PoC for a new function ? We look for RDO
packaging, Puppet configuration and ops/end user documentation.
- An operator offering function to their end users in test (I.e. This
works well enough to see if there is an end user benefit to justify the
operations cost) ?
- An operator to offer this in production (I.e. The operator deploys the
code and makes it available to the end users) ? This implies scaling,
upgradability, etc. and commits to a sustainable roadmap (with the
community)

I really appreciate the reflections going on here since the worst case
scenario for us is that the end users of the cloud become dependent on a
component and finding that the community is not self sustaining.

Tagging allows the operator to make an informed decision given their user
community and assess the risk vs benefit.

Agreed, and I've just proposed a cross-project track session to discuss 
how user-facing projects like OpenStackClient, Horizon and Heat can 
define and assign tags for the services they support.





On 4/21/15, 2:51 PM, "Ryan Brown"  wrote:


On 04/20/2015 07:12 PM, Steve Baker wrote:

On 21/04/15 11:01, Angus Salkeld wrote:


On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote:

 As an Op, a few things that come to mind in that category are:
  * RDO packaging (stated earlier). If its not easy to install, its
 not going to be deployed as much. I haven't installed it yet,
 because I haven't had time to do much other then yum install it...
  * Horizon UI
  * Heat Resources. (Some basic stuff like create/delete queue to
 go along with the stack. also link #1 below)


Here you go:
https://github.com/openstack/heat/tree/master/contrib/heat_zaqar

One thing we need to do in Vancouver is come up with criteria for moving
resources from contrib into the main tree. Previously this was whether
the project was integrated. As a starter I would suggest something like:
1. project is in the openstack git namespace
2. the client library is synced with global-requirements.txt
3. the resources are complete enough to be useful in template authoring
We need to think about potential for integration testing in the gate
too.

I think scenario/functional tests should be table stakes to graduate a
resource from contrib/ .

  


 Horizon has a discovery aspect to it. If users don't know a
 service is available, its hard for them to use it. Even with the
 most simple UI of Create/Delete/List queues, discovery is handled.

Absolutely agreed. Especially in a service like Zaqar where the vast
majority of usage isn't by humans in a web interface, the horizon bit
becomes mostly a dashboard/auditing/testing destination instead of a
primary interface.


[snip]

--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

__
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



__
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] Liberty Design Summit - Proposed room / time layout

[Morgan Fainberg]

The work session on wed. at 1350 conflicts with a talk given by keystone
developers: http://sched.co/2qch

Trading this session slot to earlier on Wednesday would be ideal, but if
not I'll plan to use this as a platform to get more people to go to the
talk :)

--Morgan

On Tue, Apr 21, 2015 at 11:19 AM, Ben Swartzlander 
wrote:

> On 04/17/2015 05:00 AM, Thierry Carrez wrote:
>
>> Hi PTLs,
>>
>> Following the slot allocation last week, here is the proposed room layout:
>>
>>
>> https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit?usp=sharing
>>
>> It takes into account the following changes:
>> - Barbican donates on fishbowl room to Security
>> - Magnum takes one of the available Friday-afternoon sprints
>>
>> You'll notice that we still have 3 unallocated Friday afternoon sprints,
>> as well as an unallocated fishbowl room. Ceilometer expressed interest
>> in having the latter (which would require some shuffling around since
>> they have a work session at that time). At this point I prefer to keep
>> it for late adjustments.
>>
>> If you see major problems with the proposed layout let me know. I may
>> have missed a blatant issue. It's a bit difficult to find a combination
>> that works for everyone, especially when you add conference talk
>> conflicts in the mix, but I'll do my best to accommodate reported issues.
>>
>
> My main request was that the Manila sessions didn't overlap with the
> Cinder sessions, since there are some key people who are involved in both
> projects. It looks like some attempt was made to avoid overlaps (the
> fishbowl sessions at least), but the working sessions could be adjusted to
> overlap less (space permitting). I would prefer that some of the Wednesday
> Manila working sessions were moved to the end of Thursday (after the Cinder
> ones).
>
> -Ben Swartzlander
>
>  Barring major issues we'll push this to the Design Summit sched and let
>> PTLs update the content there as they refine content.
>>
>> Regards,
>>
>>
>
> __
> 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] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

[Joe Gordon]

On Tue, Apr 21, 2015 at 1:18 PM, Diem Tran  wrote:

>  Hi Duncan,
>
> We totally understand that CI is not a box ticking exercise, it actually
> serves a purpose, and we are fully on board with the need for CI. We have
> resources monitoring the CI results and handling failures on daily basis.
>

I still don't see any successful runs:

http://paste.openstack.org/show/205029/


>
> As far as the failures, we have resolved all issues related to our drivers
> that occur during the weekend (hence the failures). My understanding is
> that some time due to instability of devstack, there might be intermittent
> failures not related to out drivers at all, such as this:
> https://review.openstack.org/#/c/168177/
>
> Thanks,
> Diem.
>
>
> On 04/21/2015 03:40 PM, Duncan Thomas wrote:
>
> Can you please investigate and comment here on this thread as to why your
> CI is failing for all patches? If this is not resolved, your driver will
> not be re-added, and ignoring requests to investigate CI failures will
> increase the chances of your driver being removed in future, without
> notice. Setting up a CI system is not a box ticking exercise, it requires
> monitoring and maintenance. If that is not possible then you are not yet in
> a position to be added back into cinder.
> On 21 Apr 2015 19:32, "Diem Tran"  wrote:
>
>>
>> On 04/21/2015 01:01 PM, Mike Perez wrote:
>>
>>> On 09:57 Apr 21, Mike Perez wrote:
>>>
 On 15:47 Apr 20, Diem Tran wrote:

> Hi Mike,
>
> Oracle ZFSSA iSCSI CI is now reporting test results. It is configured
> to run against the ZFSSA iSCSI driver. You can see the results here:
> https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z
>
> Below are some patchsets that the CI reports:
> https://review.openstack.org/#/c/168424/
> https://review.openstack.org/#/c/168419/
> https://review.openstack.org/#/c/175247/
> https://review.openstack.org/#/c/175077/
> https://review.openstack.org/#/c/163706/
>
>
> I would like to kindly request you and the core team to get the
> Oracle ZFSSA iSCSI driver re-integrated back to the Cinder code base.
> If there is anything else you need from the CI and the driver, please
> do let me know.
>
 This was done on 4/8:

 https://review.openstack.org/#/c/170770/

>>> My mistake this was only the NFS driver. The window to have drivers
>>> readded in
>>> Kilo has long past. Please see:
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-March/059990.html
>>>
>>> This will have to be readded in Liberty only at this point.
>>>
>>
>> Thank you for your reply. Could you please let me know the procedure
>> needed for the driver to be readded to Liberty? Specifically, will you be
>> the one who upload the revert patchset, or it is the driver maintainer's
>> responsibility?
>>
>> Diem.
>>
>>
>>
>> __
>> 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:unsubscribehttp://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
>
>
__
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-dev] [Nova] Add config option for real deletes instead of soft-deletes

[Artom Lifshitz]

Hello,

I'd like to gauge acceptance of introducing a feature that would give operators
a config option to perform real database deletes instead of soft deletes.

There's definitely a need for *something* that cleans up the database. There
have been a few attempts at a DB purge engine [1][2][3][4][5], and archiving to
shadow tables has been merged [6] (though that currently has some issues [7]).

DB archiving notwithstanding, the general response to operators when they   

mention the database becoming too big seems to be "DIY cleanup."

I would like to propose a different approach: add a config option that turns
soft-deletes into real deletes, and start telling operators "if you turn this
on, it's DIY backups."

Would something like that be acceptable and feasible? I'm ready to put in the
work to implement this, however searching the mailing list indicates that it
would be somewhere between non trivial and impossible [8]. Before I start, I
would like some confidence that it's closer to the former than the latter :)

Cheers!

[1] https://blueprints.launchpad.net/nova/+spec/db-purge-engine
[2] https://blueprints.launchpad.net/nova/+spec/db-purge2
[3] https://blueprints.launchpad.net/nova/+spec/remove-db-archiving
[4] https://blueprints.launchpad.net/nova/+spec/database-purge
[5] https://blueprints.launchpad.net/nova/+spec/db-archiving
[6] https://review.openstack.org/#/c/18493/
[7] https://review.openstack.org/#/c/109201/
[8] 
http://lists.openstack.org/pipermail/openstack-operators/2014-November/005591.html

__
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] [tripleo] Adventures in QuintupleO

[Ben Nemec]

On 04/20/2015 04:39 PM, Steve Baker wrote:
> I've been spending some time getting quintupleo working on top of a Juno 
> RDO OpenStack. I'm at a point now where I think it is worth putting 
> effort into making it easy for anyone to try this.

\o/

> 
> Ben Nemec has done the hard work of proving this is possible[1] 
> resulting in the repo he uses to bring up an environment which behaves 
> like a baremetal env[2]
> 
> I'd like to build on this to create a new upstream repo aimed at setting 
> up an environment which is ready for undercloud and overcloud installation.
> 
> For rdo-management, using it would be documented in its own section of 
> the Setup chapter[3]
> 
> Ben's heat templates bring up BMC and baremetal nodes. I've been 
> extending those to also define the undercloud network and a bare 
> undercloud node ready for undercloud installation (or optionally an 
> image-based undercloud).  Another future enhancement could be to figure 
> out how to use only a single nova server serve all of the BMC requests 
> (possibly with one server having a neutron port per baremetal it is 
> managing)
> 
> This will still require patching the nethercloud until we can find a way 
> of upstreaming those changes. The repo can at least be where those 
> patches live for now.
> 
> So my questions for now would be:
> 
> What should the repo be called? quintuplo-setup?

Or just quintupleo.  I doubt we're going to have a lot of problems with
name collisions. :-)

> 
> Where should it live? git openstack in the openstack namespace? github 
> rdo-management?

I'm not sure, but a few thoughts:

It requires hackery of the underlying cloud.  I'm wondering if that
disqualifies it from the openstack namespace.

It's only known to work with the instack-undercloud workflow.  In theory
that means it should be able to work with devtest, but at the moment we
haven't actually used the two together.  Which makes me wonder if it
should just go in the rdo-management tree, but on the other hand I know
there are people interested in it outside of RDO, so I'm not sure that's
a perfect fit either.

So given that I'm pretty undecided about where this belongs, maybe
stackforge would be a good choice until we decide where it's going?

> 
> [1] http://blog.nemebean.com/tags/quintupleo
> [2] https://github.com/cybertron/tripleo-scripts
> [3] 
> https://repos.fedorapeople.org/repos/openstack-m/instack-undercloud/html/setup.html
> 
> 
> __
> 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] [api] gabbi: A tool for declarative testing of APIs

[Everett Toews]

On Apr 20, 2015, at 2:45 PM, Chris Dent  wrote:

> I wanted to make a quick update on the latest happenings with
> gabbi[0], the tool I've created to do "declarative" testing of
> OpenStack APIs (starting with Ceilometer and Gnocchi).
> 
> * Jay Pipes and I are doing a presentation "API Matters" at summit.
>  The latter of half of that will be me noodling about gabbi,
>  including a demo.[1]

This is great! I'm looking forward to attending it.

Miguel and I are doing something similar with our "The Good and the Bad of the 
OpenStack REST APIs” presentation [1]. Which is exactly 10 minutes after your 
presentation. :)

Cheers,
Everett

[1] 
https://openstacksummitmay2015vancouver.sched.org/event/6ce758d5c7340db74e0d432e138c6619
__
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][releases] upcoming library releases to unfreeze requirements in master

[Matt Riedemann]

On 4/21/2015 2:44 PM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2015-04-21 13:11:09 -0400:

I'm working on releasing a *bunch* of libraries, including clients, from
their master branches so we can thaw the requirements list for the
liberty cycle. As with any big operation, this may be disruptive. I
apologize in advance if it is, but we cannot thaw the requirements
without making the releases so we need them all.

Here's the full list, in the form of the release script I am running,
in case you start seeing issues and want to check if you were
affected:


OK, this is all done. I have verified that all of the libraries are on
PyPI and I have sent the release notes (sometimes several copies, at no
extra charge to you -- seriously, sorry about the noise).

Doug

__
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



And the gate is wedged. :)

https://bugs.launchpad.net/openstack-gate/+bug/1446847

--

Thanks,

Matt Riedemann


__
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] [api] Minor changes to API

[Everett Toews]

On Apr 20, 2015, at 2:19 PM, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>> 
wrote:

Hi openstack-dev@

I was wondering if the API Working Group had an opinion on how to deal with 
minor changes to the api?  For example, what if you wanted to add a new 
attribute to a JSON response?  I would think that a minor change like that 
could be done without having to create a new versioned endpoint.  So a newer 
release would just add the new attribute without having to create a new /v1.1/ 
endpoint.

I’d suggest (like others have already) doing microversions like Nova [1]. 
Creating a new endpoint would be a cruel thing to do to your clients, 
especially considering it’s a seemingly backwards compatible change.

However, minor changes like that could still possibly break clients that are 
not expecting them.  For example, a client that uses the json response as 
arguments to a method via **kwargs would start seeing TypeErrors for unexpected 
arguments.

And let us not forget statically typed languages. But even there adding a new 
attribute isn’t that big of a deal. If there’s an unexpected attribute in a 
response, it can simply be ignored. No harm done.

But the user might not even be aware the new attribute is available unless 
they’re not looking at their request/response logs. Hence the need for 
microversions.

Everett

[1] 
http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
__
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][releases] upcoming library releases to unfreeze requirements in master

[Doug Hellmann]

Excerpts from Kevin L. Mitchell's message of 2015-04-21 15:22:29 -0500:
> On Tue, 2015-04-21 at 15:44 -0400, Doug Hellmann wrote:
> > OK, this is all done. I have verified that all of the libraries are on
> > PyPI and I have sent the release notes (sometimes several copies, at no
> > extra charge to you -- seriously, sorry about the noise).
> 
> Just out of curiosity, how many entries are in whatever array from which
> the script selects randomly?  That's the best part of the release
> script, IMO :)

The release_notes.py script [1] is part of the release-tools repo. If
you have emotions to add to the list, please do!

Doug

[1] 
http://git.openstack.org/cgit/openstack-infra/release-tools/tree/release_notes.py#n29

__
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] [barbican] Utilizing the KMIP plugin

[Christopher N Solis]

Hey Joel.
Thanks for the advice!
I was able to solve the problem and have the ssl connection become trusted.
Barbican seems to be authenticating correctly to the KMIP server as well
now.
However, I have another problem.

When I try to store a plain text secret into barbican I receive the
following error:

File "/home/swift/barbican/barbican/api/controllers/__init__.py", line 104,
in handler
return fn(inst, *args, **kwargs)
  File "/home/swift/barbican/barbican/api/controllers/__init__.py", line
90, in enforcer
return fn(inst, *args, **kwargs)
  File "/home/swift/barbican/barbican/api/controllers/__init__.py", line
146, in content_types_enforcer
return fn(inst, *args, **kwargs)
  File "/home/swift/barbican/barbican/api/controllers/secrets.py", line
326, in on_post
transport_key_id=data.get('transport_key_id'))
  File "/home/swift/barbican/barbican/plugin/resources.py", line 95, in
store_secret
plugin_name=plugin_name)
  File "/home/swift/barbican/barbican/plugin/interface/secret_store.py",
line 478, in _check_plugins_configured
return plugin_related_function(self, *args, **kwargs)
  File "/home/swift/barbican/barbican/plugin/interface/secret_store.py",
line 513, in get_plugin_store
if ext.obj.store_secret_supports(key_spec):
  File "/home/swift/barbican/barbican/plugin/kmip_secret_store.py", line
481, in store_secret_supports
return self.generate_supports(key_spec)
  File "/home/swift/barbican/barbican/plugin/kmip_secret_store.py", line
437, in generate_supports
alg_dict_entry = self.valid_alg_dict.get(key_spec.alg.lower())
AttributeError: 'NoneType' object has no attribute 'lower'

I don't really know what could be causing this error. Any ideas?

Regards,

  CHRIS SOLIS





From:   "Coffman, Joel M." 
To: "'OpenStack Development Mailing List (not for usage
questions)'" , Christopher N
Solis/Austin/IBM@IBMUS
Cc: "Reller, Nathan S." , "Farr, Kaitlin
M." , "Coffman, Joel M."

Date:   04/16/2015 03:22 PM
Subject:RE: [openstack-dev] [barbican] Utilizing the KMIP plugin



However, I cannot not make a request to the kmip plugin because of an ssl
error:
The keyfile, certfile, and ca_certs are passed directly to ssl.wrap_socket.
Debugging any SSL errors isn’t easy – Google is generally the best resource
to identify and resolve issues based on the error codes returned by
OpenSSL. :-(

What exactly is each variable suppose to contain?
See the ssl.wrap_socket documentation for more details.
I have keyfile and certfile being a self signed certificate and 2048 bit
RSA key respectively for barbican to use and ca_certs is the kmip_plugins'
certificate for barbican to trust. Does this setup sound right?
In the sentence, you swap the key and certificate (i.e., the RSA key should
be the keyfile and the self-signed certificate should be the certfile), but
that’s probably not the real issue. :-)

If credentials (i.e., a key and certificate) weren’t provided to you for
the KMIP appliance, you’ll probably need to have the KMIP appliance sign
your self-signed certificate so it knows that it’s valid. The procedure
differs by appliance but loosely resembles the following:
  1.   Generate key and certificate on local machine using OpenSSL
  2.   Upload certificate to KMIP appliance
  3.   Sign the certificate using the KMIP appliance’s server
  certificate
Alternatively, a key and certificate could be provided for the KMIP
appliance; you would use those files rather than generating them locally.

Hope that information is helpful.

Joel


From: John Wood [mailto:john.w...@rackspace.com]
Sent: Wednesday, April 15, 2015 9:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Reller, Nathan S.; Farr, Kaitlin M.
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin

Hello Christopher,

I’m glad you are making progress. I’m including two folks that worked on
the KMIP plugin to see if they can help with your error diagnosis.

Thanks,
John


From: Christopher N Solis 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: Tuesday, April 14, 2015 at 10:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin



Hey John.
Thanks!
You were right. It was reading the config from the /root directory because
I switched to the root user.
After switching back to the normal user it is reading the correct config
file again.
It is trying to use the kmip plugin now.

However, I cannot not make a request to the kmip plugin because of an ssl
error:

2015-04-14 10:02:26,219 - barbican.plugin.kmip_secret_store - ERROR - Error
opening or writing to client
Traceback (most recent call last):
  File "/home/swift/barbican/barbican/plugin/kmip_secret_store.py", line
167, in generate_symmetric_key
self.client.open()
  File

Re: [openstack-dev] [api] Minor changes to API

[Everett Toews]

On Apr 20, 2015, at 7:07 PM, Ian Wells 
mailto:ijw.ubu...@cack.org.uk>> wrote:

On 20 April 2015 at 15:23, Matthew Treinish 
mailto:mtrein...@kortar.org>> wrote:
On Mon, Apr 20, 2015 at 03:10:40PM -0700, Ian Wells wrote:
> It would be nice to have a consistent policy here; it would make future
> decision making easier and it would make it easier to write specs if we
> knew what was expected and the possible implementations weren't up for
> (quite so much) debate.  For different reasons, Neutron extensions are also
> not favoured, so there's no clear cut choice to make.

Uhm, there is: https://wiki.openstack.org/wiki/APIChangeGuidelines
and if you read that adding attrs without advertising it (using an
extension, microversion, or whatever) is not an allowed change.

It is also not an unallowed change (given that there's a section that appears 
to define what an unallowed attribute change is).  The page reads very 
awkwardly.

Whatever your preference might be, I think it's best we lose the ambiguity.  
And perhaps advertise that page a little more widely, actually - I hadn't come 
across it in my travels.  And perhaps improve its air of authority: rules on 
this subject should probably live somewhere in a repo so that it's clear 
there's consensus for changes.  Currently anyone can change it for any reason, 
and two years after the last substantive change it's hard to say who even knew 
it was being changed, let alone whether they agreed.

Such a repo exists! [1]

You can see those docs rendered here. [2]

It’s under the purview of the API Working Group. [3] You’re most welcome to 
join us.

That APIChangeGuidelines wiki page really needs to be incorporated into the 
official repo [1]. I’ve added that as an agenda item to our next meeting on 
Thursday 2015-04-23 at 00:00 UTC [4].

[1] http://git.openstack.org/cgit/openstack/api-wg/
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://wiki.openstack.org/wiki/API_Working_Group
[4] https://wiki.openstack.org/wiki/Meetings/API-WG

__
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] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

[Ian Cordasco]

On 4/16/15, 17:54, "Clint Byrum"  wrote:

>Excerpts from Joe Gordon's message of 2015-04-16 15:15:01 -0700:
>> On Fri, Apr 10, 2015 at 4:01 AM, Victor Stinner 
>>wrote:
>> 
>> > > https://wiki.openstack.org/wiki/Python3#Dependencies appears to be
>> > fairly out of date.
>> >
>> > You're right. I updated this wiki page. In practice, much more
>>OpenStack
>> > clients, Common Libraries and Development Tools are already Python 3
>> > compatible. I added the link to my pull request for Oslo Messaging.
>> >
>> > > It would be nice to get a better sense of what the remaining
>>libraries
>> > to port over are before the summit so we can start planning how to do
>>the
>> > python34 migration.
>> >
>> > I checked quickly. There are small libraries like pyEClib required by
>> > Swift, but the major blocker libraries are: MySQL-Python, suds,
>>Paste. For
>> > oslo.db, it's already Python 3 compatible no?
>> >
>> >
>> > * MySQL-Python
>> >
>> > MySQL-Python doesn't look to be active (last commit in january 2014).
>> > There are multiple Python 3 pending pull requests:
>> > https://github.com/farcepest/MySQLdb1/pulls
>> >
>> > Mike Bayer is evaluating PyMySQL which is Python 3 compatible:
>> > https://wiki.openstack.org/wiki/PyMySQL_evaluation
>> >
>> > See also https://github.com/farcepest/moist (is it alive? is it
>>Python 3
>> > compatible?)
>> >
>> >
>> > * suds
>> >
>> > There is https://bitbucket.org/jurko/suds : a fork compatible with
>>Python
>> > 3. Global requirements contain this comment:
>> >
>> > # NOTE(dims): suds is not python 3.x compatible, suds-jurko is a fork
>>that
>> > # works with py3x. oslo.vmware would convert to suds-jurko first then
>>nova
>> > # and cinder would follow. suds should be remove immediately once
>>those
>> > # projects move to suds-jurko for all jobs.
>> >
>> >
>> > * Paste
>> >
>> > I already fixed Python 3 compatibility issues and my changes were
>>merged,
>> > but there is no release including my fixes yet :-(
>> >
>> > I heard that Paste is completly outdated and should be replaced. Ok,
>>but
>> > in practice it's still used and not Python 3 compatible.
>> >
>> > Workaround: use the development (git) version of Paste.
>> >
>> >
>> > For the full list, see the wiki page:
>> > https://wiki.openstack.org/wiki/Python3#Core_OpenStack_projects
>> 
>> 
>> Thanks for updating the wiki page that is a very useful list.
>> 
>> From the looks of things, it seems like nova getting Python3 support in
>> Liberty is not going to happen. But we can make good progress in
>> dependencies sorted out. By fixing the dependencies and switching a few
>>out
>> for better ones.
>> 
>> What are your thoughts on how to tackle  sqlalchemy-migrate? It looks
>>like
>> that is a blocker for several projects. And something I think we have
>> wanted to move off of for some time now.
>> 
>
>IMHO it is quite a bit easier to port something to python 3 than to
>move off of it entirely. I'd say it's worth it for forward progress to
>try and port sqlalchemy-migrate, even if that means the effort becomes
>a sunk cost in a year.

Also, isn’t sqlalchemy-migrate something we currently maintain (or a group
of OpenStack developers do it for OpenStack. Can’t we work with them to
add support for Python 3?

__
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][releases] upcoming library releases to unfreeze requirements in master

[Kevin L. Mitchell]

On Tue, 2015-04-21 at 15:44 -0400, Doug Hellmann wrote:
> OK, this is all done. I have verified that all of the libraries are on
> PyPI and I have sent the release notes (sometimes several copies, at no
> extra charge to you -- seriously, sorry about the noise).

Just out of curiosity, how many entries are in whatever array from which
the script selects randomly?  That's the best part of the release
script, IMO :)
-- 
Kevin L. Mitchell 
Rackspace


__
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-dev] [Gnocci] 1.0.0rc1 is out

[Julien Danjou]

Hi folks,

If you want to give it a try, the first and I hope last RC for Gnocchi
1.0.0 numbered 1.0.0rc1 is out:

  https://pypi.python.org/pypi/gnocchi
  https://launchpad.net/gnocchi/1.0/1.0.0rc1

Test and enjoy!

Cheers,
-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info


signature.asc
Description: PGP signature
__
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] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

[Diem Tran]

Hi Duncan,

We totally understand that CI is not a box ticking exercise, it actually 
serves a purpose, and we are fully on board with the need for CI. We 
have resources monitoring the CI results and handling failures on daily 
basis.


As far as the failures, we have resolved all issues related to our 
drivers that occur during the weekend (hence the failures). My 
understanding is that some time due to instability of devstack, there 
might be intermittent failures not related to out drivers at all, such 
as this:

https://review.openstack.org/#/c/168177/

Thanks,
Diem.

On 04/21/2015 03:40 PM, Duncan Thomas wrote:


Can you please investigate and comment here on this thread as to why 
your CI is failing for all patches? If this is not resolved, your 
driver will not be re-added, and ignoring requests to investigate CI 
failures will increase the chances of your driver being removed in 
future, without notice. Setting up a CI system is not a box ticking 
exercise, it requires monitoring and maintenance. If that is not 
possible then you are not yet in a position to be added back into cinder.


On 21 Apr 2015 19:32, "Diem Tran" > wrote:



On 04/21/2015 01:01 PM, Mike Perez wrote:

On 09:57 Apr 21, Mike Perez wrote:

On 15:47 Apr 20, Diem Tran wrote:

Hi Mike,

Oracle ZFSSA iSCSI CI is now reporting test results.
It is configured
to run against the ZFSSA iSCSI driver. You can see the
results here:

https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z

Below are some patchsets that the CI reports:
https://review.openstack.org/#/c/168424/
https://review.openstack.org/#/c/168419/
https://review.openstack.org/#/c/175247/
https://review.openstack.org/#/c/175077/
https://review.openstack.org/#/c/163706/


I would like to kindly request you and the core team
to get the
Oracle ZFSSA iSCSI driver re-integrated back to the
Cinder code base.
If there is anything else you need from the CI and the
driver, please
do let me know.

This was done on 4/8:

https://review.openstack.org/#/c/170770/

My mistake this was only the NFS driver. The window to have
drivers readded in
Kilo has long past. Please see:


http://lists.openstack.org/pipermail/openstack-dev/2015-March/059990.html

This will have to be readded in Liberty only at this point.


Thank you for your reply. Could you please let me know the
procedure needed for the driver to be readded to Liberty?
Specifically, will you be the one who upload the revert patchset,
or it is the driver maintainer's responsibility?

Diem.



__
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


__
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] [TripleO] on supporting multiple implementations of tripleo-heat-templates

[Dan Prince]

On Fri, 2015-04-17 at 09:37 -0700, Clint Byrum wrote:
> Excerpts from Giulio Fidente's message of 2015-04-17 06:21:28 -0700:
> > Hi,
> > 
> > the Heat/Puppet implementation of the Overcloud deployment seems to be 
> > surpassing in features the Heat/Elements implementation.
> > 
> > The changes for Ceph are an example, the Puppet based version is already 
> > adding features which don't have they counterpart into Elements based.
> > 
> > Recently we started working on the addition of Pacemaker into the 
> > Overcloud, to monitor the services and provide a number of 'auto 
> > healing' features, and again this is happening in the Puppet 
> > implementation only (at least for now) so I think the gap will become 
> > bigger.
> > 
> > Given we support different implementations with a single top-level 
> > template [1], to keep other templates valid we're forced to propagate 
> > the params into the Elements based templates as well, even though there 
> > is no use for these there, see for example [2].
> > 
> > The extra work itself is not of great concern but I wonder if it 
> > wouldn't make sense to deprecate the Elements based templates at this 
> > point, instead of keep adding there unused parts? Thoughts?
> > 
> 
> In a perfect world, templates wouldn't have implementation details like
> puppet-anything in them. We all know that isn't true, but in a perfect
> world.. ;)

The high level templates don't. All the puppet stuff is nicely
encapsulated in a sub-directory (except for the resource registry which
is a really minor exception). I'm actually really happy with how the
architecture of the Heat templates is evolving to be more pluggable in
the last release.

> 
> I was just wondering the other day if anybody is relying on the non-puppet
> jobs anymore. I think from my view of things, the "elements" approach
> can be deprecated and removed if nobody steps up to maintain them.

Agree, and I think things are naturally already moving in that
direction.

> 
> __
> 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] [TripleO] on supporting multiple implementations of tripleo-heat-templates

[Dan Prince]

On Fri, 2015-04-17 at 15:21 +0200, Giulio Fidente wrote:
> Hi,
> 
> the Heat/Puppet implementation of the Overcloud deployment seems to be 
> surpassing in features the Heat/Elements implementation.
> 
> The changes for Ceph are an example, the Puppet based version is already 
> adding features which don't have they counterpart into Elements based.
> 
> Recently we started working on the addition of Pacemaker into the 
> Overcloud, to monitor the services and provide a number of 'auto 
> healing' features, and again this is happening in the Puppet 
> implementation only (at least for now) so I think the gap will become 
> bigger.
> 
> Given we support different implementations with a single top-level 
> template [1], to keep other templates valid we're forced to propagate 
> the params into the Elements based templates as well, even though there 
> is no use for these there, see for example [2].

This was done intentionally when adding the new puppet templates. The
idea was that tripleo-heat-templates was defining a high level interface
that could be used to provision and configure a cloud with multiple
backends (tripleo-image-elements and or puppet being the current
options). It was actually a bit more work to do it this way but the idea
is that we are refining our interfaces to be more generic and correct.
In doing the puppet work we actually discovered lots of data that was
being copied into various roles that wasn't needed. And having the
working tripleo-image-elements implementation to begin with was also a
great help to speed the puppet stuff along.

> 
> The extra work itself is not of great concern but I wonder if it 
> wouldn't make sense to deprecate the Elements based templates at this 
> point, instead of keep adding there unused parts?

You aren't really adding that many unused parts. Just a parameter here
and there right? And this is just to keep the CI jobs happy.

With regards to the specific templates for triple-image-elements for
configuration long term I'm not sure where they are headed. I don't
think there is as much interest in maintaining them so perhaps we should
deprecate them...

However, I would like to see us maintain the abstractions we have in
place in tripleo-heat-templates should another implementation come along
besides Puppet. To me this is sort of the essence of TripleO (defining
an interface to deploy a cloud). And if you are suggesting we get rid of
tripleo-image-elements just so we can then go and remove these
abstractions then I think it might be a step in the wrong direction. In
other words... regardless of what happens to the maintenance of the
tripleo-image-elements (and any associated templates) lets keep a
structure that supports multiple backends. Yes, it may cost a bit of
extra wiring here and there but I think it is worth the effort.

>  Thoughts?
> 
> 1. 
> https://github.com/openstack/tripleo-heat-templates/blob/master/overcloud-without-mergepy.yaml
> 2. https://review.openstack.org/#/c/173773
> 
> __
> 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][releases] upcoming library releases to unfreeze requirements in master

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2015-04-21 13:11:09 -0400:
> I'm working on releasing a *bunch* of libraries, including clients, from
> their master branches so we can thaw the requirements list for the
> liberty cycle. As with any big operation, this may be disruptive. I
> apologize in advance if it is, but we cannot thaw the requirements
> without making the releases so we need them all.
> 
> Here's the full list, in the form of the release script I am running,
> in case you start seeing issues and want to check if you were
> affected:

OK, this is all done. I have verified that all of the libraries are on
PyPI and I have sent the release notes (sometimes several copies, at no
extra charge to you -- seriously, sorry about the noise).

Doug

__
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] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

[Duncan Thomas]

Can you please investigate and comment here on this thread as to why your
CI is failing for all patches? If this is not resolved, your driver will
not be re-added, and ignoring requests to investigate CI failures will
increase the chances of your driver being removed in future, without
notice. Setting up a CI system is not a box ticking exercise, it requires
monitoring and maintenance. If that is not possible then you are not yet in
a position to be added back into cinder.
On 21 Apr 2015 19:32, "Diem Tran"  wrote:

>
> On 04/21/2015 01:01 PM, Mike Perez wrote:
>
>> On 09:57 Apr 21, Mike Perez wrote:
>>
>>> On 15:47 Apr 20, Diem Tran wrote:
>>>
 Hi Mike,

 Oracle ZFSSA iSCSI CI is now reporting test results. It is configured
 to run against the ZFSSA iSCSI driver. You can see the results here:
 https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z

 Below are some patchsets that the CI reports:
 https://review.openstack.org/#/c/168424/
 https://review.openstack.org/#/c/168419/
 https://review.openstack.org/#/c/175247/
 https://review.openstack.org/#/c/175077/
 https://review.openstack.org/#/c/163706/


 I would like to kindly request you and the core team to get the
 Oracle ZFSSA iSCSI driver re-integrated back to the Cinder code base.
 If there is anything else you need from the CI and the driver, please
 do let me know.

>>> This was done on 4/8:
>>>
>>> https://review.openstack.org/#/c/170770/
>>>
>> My mistake this was only the NFS driver. The window to have drivers
>> readded in
>> Kilo has long past. Please see:
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-March/059990.html
>>
>> This will have to be readded in Liberty only at this point.
>>
>
> Thank you for your reply. Could you please let me know the procedure
> needed for the driver to be readded to Liberty? Specifically, will you be
> the one who upload the revert patchset, or it is the driver maintainer's
> responsibility?
>
> Diem.
>
>
>
> __
> 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

[openstack-dev] [release] tooz release 0.15.0 (liberty)

[Doug Hellmann]

We are happy to announce the release of:

tooz 0.15.0: Coordination library for distributed systems.

For more details, please see the git log history below and:

http://launchpad.net/python-tooz/+milestone/0.15.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-tooz/

Changes in tooz 0.14.0..0.15.0
--

e4bbade 2015-04-18 11:25:34 -0700 Fix param name to be its right name
bed46b8 2015-04-17 17:58:23 -0700 Replace more instance(s) of exception 
chaining with helper
3b619de 2015-04-18 00:52:34 + Just use staticmethod functions to create 
_dumps/_loads
a039cb0 2015-04-16 18:15:34 + Uncap library requirements for liberty
5f92ace 2015-04-15 17:31:21 -0700 Link AOF to redis persistence docs
a890d34 2015-04-15 08:56:47 -0700 Add exception docs to developer docs
edd499f 2015-04-14 23:26:12 -0700 Add + use helper to raise + chain exceptions
15e659f 2015-04-14 15:51:35 -0700 Allow the acquired file to be closed manually
a0980f8 2015-04-14 19:34:50 + Updated from global requirements
e21f7af 2015-04-13 18:45:27 -0700 Silence logs + errors when stopping and group 
membership lost
6aabfbe 2015-04-13 15:30:47 -0700 Make and use a thread safe pymemcache client 
subclass
270ad93 2015-04-13 14:13:39 -0700 Handle errors that come out of pymemcache 
better
44131d0 2015-04-13 15:45:14 + Use rst inline code structure + link to 
sentinel

Diffstat (except docs and test files)
-

requirements-py3.txt|  10 ++--
requirements.txt|   8 +--
test-requirements.txt   |   9 +--
tooz/coordination.py|  39 
tooz/drivers/file.py|   4 ++
tooz/drivers/ipc.py |   4 +-
tooz/drivers/memcached.py   | 143 +++-
tooz/drivers/mysql.py   |  12 +++-
tooz/drivers/pgsql.py   |   8 ++-
tooz/drivers/redis.py   |  45 +++---
tooz/drivers/zookeeper.py   |  72 --
tooz/locking.py |  10 +++-
tooz/utils.py   |   9 +--
16 files changed, 422 insertions(+), 76 deletions(-)


Requirements updates


diff --git a/requirements-py3.txt b/requirements-py3.txt
index c9c1428..b61b75b 100644
--- a/requirements-py3.txt
+++ b/requirements-py3.txt
@@ -6 +6 @@ Babel>=1.3
-stevedore>=1.3.0,<1.4.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
@@ -10,2 +10,2 @@ kazoo>=1.3.1
-pymemcache>=1.2
-zake>=0.1.6
+pymemcache>=1.2  # Apache 2.0 License
+zake>=0.1.6 # Apache-2.0
@@ -13,2 +13,2 @@ msgpack-python>=0.4.0
-retrying>=1.2.3,!=1.3.0
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+retrying>=1.2.3,!=1.3.0 # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/requirements.txt b/requirements.txt
index 287692d..e995b54 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ Babel>=1.3
-stevedore>=1.3.0,<1.4.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
@@ -10 +10 @@ kazoo>=1.3.1
-pymemcache>=1.2
+pymemcache>=1.2  # Apache 2.0 License
@@ -13 +13 @@ msgpack-python>=0.4.0
-retrying>=1.2.3,!=1.3.0
+retrying>=1.2.3,!=1.3.0 # Apache-2.0
@@ -15 +15 @@ futures>=2.1.6
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 0e02724..56264a1 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ discover
-mock>=1.0  # only needed on < python 3.3
+mock>=1.0
@@ -10 +10 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
@@ -17,2 +17,3 @@ psycopg2
-PyMySQL>=0.6.2
-sysv_ipc>=0.6.8
+PyMySQL>=0.6.2  # MIT License
+sysv_ipc>=0.6.8  # BSD License
+fixtures>=0.3.14



__
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] [nova][python-novaclient] microversion implementation on client side

[Dean Troyer]

On Tue, Apr 21, 2015 at 1:27 PM, Chris Friesen 
wrote:

> On 04/21/2015 11:35 AM, Hayes, Graham wrote:
>
>> From: Jay Pipes [jaypi...@gmail.com]
>>> The existing --os-compute-api-version CLI option should be made to take:
>>>
>>>* 2
>>>* \d+.\d+
>>>* "latest"
>>>
>>> And nothing else.
>>>
>>
>  Yes - please don't add a flag to the cli (or the python bindings for
>> that matter)
>>
>
> Isn't a cli flag exactly what Jay was describing?


It is, it already exists, it just needs to be made to properly recognize
the required version strings, which is what Jay was suggesting.


> This should be done via discovery. If a call requires a micro-version
>> that is not deployed - return an error.
>>
>
> I haven't had the pleasure(?) of needing to do this, but wouldn't you need
> to know what API versions are available before you try to do some task?
> (In order to know what actions are available, or what parameters to expect
> to be returned.)
>

When a user needs to know much more about the API than "this is the one
that does Whiz-Bang Feature that I want" then we've failed.  Also, many
users aren't probably going to care about API microversions, more likely to
care that GWclient 2.1.2 is the version they need to use Whiz-Bang since
that's what they'll have control over.


> As I understand it, Jay's proposal is that if you don't specify a version
> you get the default (currently version 2, I think), if you do specify a
> version you get that version, and if you specify "latest" then you get the
> most recent version that the server knows about.


The way we've been headed in other discovery implementations is to
negotiate the highest compatible version between the client and server
unless a specific version requested.  What happens in the client will of
course be client-specific, but as a user I would hope that it either makes
a best effort to fail gracefully or make a lot of noise that includes a
clue as to why it failed.


dt

-- 

Dean Troyer
dtro...@gmail.com
__
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-dev] [release] taskflow release 0.9.0 (liberty)

[Doug Hellmann]

We are psyched to announce the release of:

taskflow 0.9.0: Taskflow structured state management library.

For more details, please see the git log history below and:

http://launchpad.net/taskflow/+milestone/0.9.0

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

Changes in taskflow 0.8.1..0.9.0


c76ee25 2015-04-18 14:44:24 + Validate correct exception subclass in 
'raise_with_cause'
18d3cd1 2015-04-17 21:05:21 -0700 Remove link to kazoo eventlet handler
672e1f4 2015-04-16 16:29:49 -0700 Add states generating venv and use pydot2
50eb387 2015-04-16 12:08:30 -0700 Add strict job state transition checking
0a94d68 2015-04-16 18:15:17 + Uncap library requirements for liberty
018dbf6 2015-04-15 16:10:33 -0700 Have reset state handlers go through a shared 
list
0eee98d 2015-04-15 15:43:08 -0700 Add job states in docs + states in python
661f3b0 2015-04-12 22:57:28 -0700 Expose r/o listener callback + details filter 
callback
15d73cb 2015-04-11 10:16:13 -0700 Expose listener notification type + docs
d8e76fd 2015-04-10 20:25:51 -0700 Ensure listener args are always a 
tuple/immutable
624001a 2015-04-10 17:11:26 -0700 Include the 'dump_memory_backend' example in 
the docs
8910cdb 2015-04-09 15:02:06 -0700 Make resolution/retry strategies more clear 
and better
4ef79bc 2015-04-08 16:21:34 -0700 Rename notifier 'listeners' to 'topics'
ee7f07f 2015-04-08 15:28:25 -0700 Mention link to states doc in notify state 
transitions
0ad2fd9 2015-04-08 15:22:46 -0700 Ensure we don't get stuck in formatting loops
c64ca27 2015-04-08 14:04:38 -0700 Add note about thread safety of fake 
filesystem
647b69e 2015-04-05 09:46:19 -0700 Have the notification/listener docs match 
other sections
ebc0782 2015-04-04 19:46:20 -0700 Put semantics preservation section into note 
block
2ad837c 2015-04-03 17:37:34 -0700 Note that the traditional mode also avoids 
this truncation issue
7e8981a 2015-04-03 16:11:04 -0700 Avoid going into causes of non-taskflow 
exceptions
aa8be4b 2015-04-03 16:04:46 -0700 Use the ability to chain exceptions correctly
9cb7181 2015-04-03 17:40:28 + Add a example showing how to share an executor
c553d65 2015-04-02 11:54:42 -0700 Shrink the bookshelf description
17b7c21 2015-04-01 17:12:38 -0700 Remove link about implementing job garbage 
binning
254d3f9 2015-04-01 14:34:30 -0700 Put the examples/misc/considerations under a 
new section
f7d81c7 2015-04-01 13:10:49 -0700 Add a suspension engine section
ce7b1d2 2015-03-31 11:43:55 -0700 Allow ls() to list recursively (using 
breadth-first)
1714cca 2015-03-30 14:55:05 -0700 Turn 'check_who' into a decorator
bb0af4f 2015-03-30 13:05:43 -0700 Use 'node' terminology instead of 'item' 
terminology
de68bc2 2015-03-29 22:59:04 -0700 Allow providing a node stringify function to 
tree pformat
f11579b 2015-03-29 22:53:47 -0700 Add in memory filesystem clearing
d33b316 2015-03-29 22:48:42 -0700 Just unify having a single requirements.txt 
file
30c7c0c 2015-03-25 21:59:27 -0700 Add memory backend get() support

Diffstat (except docs and test files)
-

requirements-py2.txt   |  36 -
requirements-py3.txt   |  30 
requirements.txt   |  36 +
taskflow/engines/action_engine/analyzer.py |   6 +-
taskflow/engines/action_engine/completer.py| 131 
taskflow/engines/action_engine/runtime.py  |  33 +++--
taskflow/engines/worker_based/protocol.py  |  32 ++--
taskflow/examples/dump_memory_backend.py   |   7 +-
taskflow/examples/share_engine_thread.py   |  81 ++
taskflow/exceptions.py |  16 +-
taskflow/jobs/backends/impl_zookeeper.py   | 164 +
taskflow/patterns/graph_flow.py|  91 ++--
taskflow/persistence/backends/impl_dir.py  |   8 +-
taskflow/persistence/backends/impl_memory.py   |  61 +++-
taskflow/persistence/backends/impl_sqlalchemy.py   |  74 ++
taskflow/persistence/backends/impl_zookeeper.py|  32 ++--
taskflow/states.py |  33 -
.../unit/persistence/test_memory_persistence.py|  40 +
taskflow/types/notifier.py |  81 ++
taskflow/types/tree.py |  17 ++-
test-requirements.txt  |   4 +-
tools/generate_states.sh   |  36 -
tools/state_graph.py   |  18 ++-
tools/update_states.sh |  40 +
tox.ini|  18 ++-
38 files changed, 982 insertions(+), 408 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
new file mode 100644
index 000..8e0c5f3
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,36 @@
+# 

[openstack-dev] [release] python-saharaclient release 0.9.0 (liberty)

[Doug Hellmann]

We are tickled pink to announce the release of:

python-saharaclient 0.9.0: Client library for Sahara API

For more details, please see the git log history below.


Changes in python-saharaclient 0.7.7..0.9.0
---

b909f04 2015-04-16 18:13:39 + Uncap library requirements for liberty
0d8e838 2015-04-14 10:31:14 +0300 Add regions support to saharaclient
67e3d66 2015-04-14 10:24:02 +0300 Provide user-agent in saharaclient
513387d 2015-04-07 10:20:27 + Add CONTRIBUTING.rst
5e8b889 2015-04-07 10:23:24 +0200 Port to Python 3
67b4e76 2015-04-02 11:04:56 +0900 add --name option to assign name to 
job-binary-internal
2141b6a 2015-03-27 16:17:04 +1100 Rework authentication
fb9cf4e 2015-03-26 15:24:36 -0400 Add support for job-types-list
b0511a8 2015-03-26 12:44:48 +0100 Add post_test_hook for functional tests
86dd3d4 2015-03-24 16:15:13 +0100 Copy functional tests from tempest CLI
0a00e75 2015-03-21 00:18:02 + Updated from global requirements
f7f1e22 2015-03-20 12:36:06 +0300 Add support for show_events parameter
6b1c801 2015-03-03 16:47:42 +0300 Added support of instance locality

Diffstat (except docs and test files)
-

CONTRIBUTING.rst   |  21 +++
requirements.txt   |   8 +-
saharaclient/api/base.py   |  14 +-
saharaclient/api/client.py | 181 +++--
saharaclient/api/clusters.py   |  10 +-
saharaclient/api/events.py |  31 
saharaclient/api/httpclient.py |  54 --
saharaclient/api/images.py |   8 +-
saharaclient/api/job_binary_internals.py   |   5 +-
saharaclient/api/job_types.py  |  28 
saharaclient/api/node_group_templates.py   |  18 +-
saharaclient/api/plugins.py|   2 +-
saharaclient/api/shell.py  |  93 +++
saharaclient/shell.py  |  22 +--
setup.cfg  |   3 +
test-requirements.txt  |  12 +-
tox.ini|   6 +
25 files changed, 596 insertions(+), 304 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 46eb375..3fa675b 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9,3 +9,3 @@ netaddr>=0.7.12
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
-python-keystoneclient>=1.0.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
+python-keystoneclient>=1.1.0
@@ -13 +13 @@ requests>=2.2.0,!=2.4.0
-six>=1.7.0
+six>=1.9.0
diff --git a/test-requirements.txt b/test-requirements.txt
index ac3a773..118a5cc 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10,4 +10,4 @@ mock>=1.0
-oslo.config>=1.6.0  # Apache-2.0
-oslosphinx>=2.2.0  # Apache-2.0
-python-neutronclient>=2.3.6,<3
-python-novaclient>=2.18.0
+oslo.config>=1.9.3  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+python-neutronclient>=2.3.11,<3
+python-novaclient>=2.22.0
@@ -15 +15 @@ python-swiftclient>=2.2.0
-requests-mock>=0.5.1 # Apache-2.0
+requests-mock>=0.6.0  # Apache-2.0
@@ -17 +17 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-tempest-lib>=0.2.0
+tempest-lib>=0.4.0



__
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] [neutron][lbaas] adding lbaas core

[Jain, Vivek]

Congrats Phil !!

Thanks,
Vivek

> On Apr 21, 2015, at 10:16 AM, Phillip Toohill  
> wrote:
> 
> Thank you!
> 
> Phillip V. Toohill III
> Software Developer
> 
> phone: 210-312-4366
> mobile: 210-440-8374
> 
> 
> 
> From: Brandon Logan 
> Sent: Tuesday, April 21, 2015 11:57 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core
> 
> Welcome Phil!
> 
> From: Doug Wiegley 
> Sent: Tuesday, April 21, 2015 11:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core
> 
> It’s been a week, welcome Phil.
> 
> Thanks,
> doug
> 
> 
>> On Apr 13, 2015, at 2:39 PM, Doug Wiegley  
>> wrote:
>> 
>> Hi all,
>> 
>> I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a 
>> bunch of work on the ref impl for lbaasv2, and and I'll let the numbers[1] 
>> speak for themselves.
>> 
>> Existing lbaas cores, please vote.  All three of us.  :-)
>> 
>> [1] http://stackalytics.com/report/contribution/neutron-lbaas/30
>> 
>> Thanks,
>> doug
> 
> 
> __
> 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
> 
> __
> 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

[openstack-dev] [release] python-openstackclient release 1.1.0 (liberty)

[Doug Hellmann]

We are gleeful to announce the release of:

python-openstackclient 1.1.0: OpenStack Command-line Client

For more details, please see the git log history below and:

https://launchpad.net/python-openstackclient/+milestone/1.1.0

Please report issues through launchpad:

https://bugs.launchpad.net/python-openstackclient

Changes in python-openstackclient 1.0.3..1.1.0
--

3c7b518 2015-04-20 11:23:15 -0600 Handle the pagination for image list
3284384 2015-04-20 06:04:10 + Imported Translations from Transifex
00eeb35 2015-04-19 02:41:04 -0400 remove unnecessary conditionals
e85971b 2015-04-19 01:43:40 -0400 Update the docs for new nic options
6e70139 2015-04-18 23:04:53 -0500 Begin documenting --os-cloud
5649695 2015-04-18 23:04:51 -0500 Add --os-cloud support
0e61e5f 2015-04-18 06:04:12 + Imported Translations from Transifex
6c4f815 2015-04-17 13:37:44 -0400 Re-organize functional tests
4c107e6 2015-04-17 10:14:57 -0700 Role operations should not require list 
object permission
15bc2cc 2015-04-17 07:54:05 -0600 Print warning on authentication error
d363068 2015-04-17 14:20:37 +0200 Fix skipped image create attribute location 
attr
5780606 2015-04-16 18:13:36 + Uncap library requirements for liberty
f43c1f7 2015-04-15 22:40:52 -0500 Defer client imports
459526e 2015-04-15 21:17:00 -0400 Better help for --nic in create server
8bd8a8d 2015-04-15 01:42:00 -0400 Add support to specify volume quotas per 
volume type
a0fe37e 2015-04-13 16:21:50 -0600 Add warning message if unknown version 
supplied
0d68987 2015-04-07 23:53:31 -0700 Fix session timing
77e3fba 2015-04-03 02:26:22 -0400 Add support for showing limits of a specific 
project
ec4ef5f 2015-04-02 12:59:34 -0500 Suppress warnings user can't fix
e60bf28 2015-04-02 11:21:07 +1100 Use glanceclient's inbuilt images find
f6bd2fa 2015-03-31 18:38:53 + Updated from global requirements
894fe6c 2015-03-31 06:05:13 + Imported Translations from Transifex
6a9d6af 2015-03-30 11:53:17 -0400 Add support to remote_id
6c224f5 2015-03-19 23:49:02 -0700 Add project and domain params to network 
create
7628510 2015-03-19 14:02:50 -0400 Add a doc about authenticating against v3
6214344 2015-03-19 13:54:19 -0400 Add the ability to set and unset flavor 
properties
8e92dfc 2015-03-17 23:44:53 +0100 Use cliff deferred help instead of homemade 
one
a9d1e3d 2015-03-11 19:16:18 +1100 Base TokenEndpoint plugin on keystoneclient's
be3cbd2 2014-11-14 17:01:49 -0600 Look harder to find DevStack

Diffstat (except docs and test files)
-

examples/common.py |   8 +
examples/object_api.py |  17 +-
examples/osc-lib.py|  14 +-
functional/harpoon.sh  |   9 +-
openstackclient/api/auth.py| 166 +++--
openstackclient/api/auth_plugin.py |  21 +-
openstackclient/common/clientmanager.py|  24 +-
openstackclient/common/limits.py   |  29 +-
openstackclient/common/quota.py|  12 +-
openstackclient/common/session.py  |  50 ++
openstackclient/common/timing.py   |  10 +-
openstackclient/compute/client.py  |  20 +-
openstackclient/compute/v2/flavor.py   |  78 ++-
openstackclient/compute/v2/server.py   |  11 +-
openstackclient/identity/common.py |  59 +-
openstackclient/identity/v3/group.py   |   7 +-
openstackclient/identity/v3/identity_provider.py   |  68 +-
openstackclient/identity/v3/project.py |   3 +-
openstackclient/identity/v3/role.py|  81 +--
openstackclient/identity/v3/role_assignment.py |  17 +-
openstackclient/identity/v3/trust.py   |   9 +-
openstackclient/identity/v3/user.py|   9 +-
openstackclient/image/client.py|  56 +-
openstackclient/image/v1/image.py  |  14 +-
openstackclient/image/v2/image.py  |  12 +-
openstackclient/network/v2/network.py  |  21 +
openstackclient/shell.py   | 115 +--
openstackclient/volume/client.py   |  20 +-
.../de/LC_MESSAGES/python-openstackclient.po   | 266 ---
.../locale/python-openstackclient.pot  | 226 +++---
.../zh_TW/LC_MESSAGES/python-openstackclient.po| 767 +
requirements.txt   |  15 +-
setup.cfg  |   2 +
test-requirements.txt  |   6 +-
68 files changed, 3145 insertions(+), 1139 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 97d06c4..b8712eb 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ Babel>=1.3
-cliff>=1.7.0  # Apache-2.0
+cliff>=1.10.0  # Apache-2.0
@@ -10,4 +10,5 @@

[openstack-dev] [release] stevedore release 1.4.0 (liberty)

[Doug Hellmann]

We are pleased to announce the release of:

stevedore 1.4.0: Manage dynamic plugins for Python applications

For more details, please see the git log history below and:

https://launchpad.net/python-stevedore/+milestone/1.4.0

Please report issues through launchpad:

https://bugs.launchpad.net/python-stevedore

Changes in stevedore 1.3.0..1.4.0
-

b347780 2015-04-16 18:14:59 + Uncap library requirements for liberty
0e44799 2015-03-21 00:18:26 + Updated from global requirements

Diffstat (except docs and test files)
-

test-requirements.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 6075428..9d75458 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11,2 +11,2 @@ discover
-oslotest>=1.2.0  # Apache-2.0
-oslosphinx>=2.2.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] python-troveclient release 1.1.0 (liberty)

[Doug Hellmann]

We are chuffed to announce the release of:

python-troveclient 1.1.0: Client library for OpenStack DBaaS API

For more details, please see the git log history below.


Changes in python-troveclient 1.0.9..1.1.0
--

738479e 2015-04-16 18:13:46 + Uncap library requirements for liberty
5125628 2015-04-08 09:11:13 + Fixes unit-test in troveclient
0fed50e 2015-03-23 16:12:59 +0900 Add test to DatastoreVersionMembers
de77518 2015-03-21 00:18:07 + Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt |  2 +-
test-requirements.txt|  4 +-
7 files changed, 102 insertions(+), 54 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 744bcf9..a87acea 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ simplejson>=2.2.0
-oslo.utils>=1.2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index dcbe47a..6c5f39f 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7,2 +7,2 @@ discover
-oslosphinx>=2.2.0  # Apache-2.0
-requests-mock>=0.5.1  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+requests-mock>=0.6.0  # Apache-2.0



__
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-dev] [release] python-manilaclient release 1.1.0 (liberty)

[Doug Hellmann]

We are pumped to announce the release of:

python-manilaclient 1.1.0: Client library for OpenStack Manila API.

For more details, please see the git log history below.


Changes in python-manilaclient 1.0.4..1.1.0
---

163c34f 2015-04-16 18:13:26 + Uncap library requirements for liberty

Diffstat (except docs and test files)
-

requirements.txt  | 6 +++---
test-requirements.txt | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b973fc0..64a94ff 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -10,3 +10,3 @@ iso8601>=0.1.9
-oslo.config>=1.9.3,<1.10.0  # Apache-2.0
-oslo.serialization>=1.4.0,<1.5.0   # Apache-2.0
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index cdd51e7..5935882 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -14 +14 @@ ordereddict
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] python-novaclient release 2.24.0 (liberty)

[Doug Hellmann]

We are chuffed to announce the release of:

python-novaclient 2.24.0: Client library for OpenStack Compute API

For more details, please see the git log history below.


Changes in python-novaclient 2.23.0..2.24.0
---

ccff3d3 2015-04-20 13:52:38 +0300 Remove all imports from oslo namespace
c4d2f92 2015-04-17 05:36:27 + Fix typo on class Client sample
9799353 2015-04-16 18:13:32 + Uncap library requirements for liberty
88beed1 2015-04-01 08:35:39 +0530 Combine test cases for checking nova limits 
response
d614dbc 2015-03-31 20:16:14 +0300 Fix repr of FloatingIPBulk
038c0dc 2015-03-26 16:36:12 +0800 Fix comments on metadata number limitation
4cef067 2015-03-26 12:09:27 +0530 Corrected help for nova boot when attaching 
block device
0343dff 2015-03-25 12:15:40 +1030 Removes reference to v3 nova api from 
novaclient docs
1c39f8f 2015-03-21 19:27:36 +0800 Don't record time when self.timing is False
025bcfb 2015-03-21 00:17:56 + Updated from global requirements
8679eed 2015-03-19 22:58:17 +0800 Revert 'Remove image to local block device 
mapping'

Diffstat (except docs and test files)
-

novaclient/client.py   | 29 +++
novaclient/i18n.py |  6 ++--
novaclient/shell.py| 41 ++
.../unit/fixture_data/security_group_rules.py  |  2 +-
novaclient/utils.py| 26 --
novaclient/v2/client.py|  6 ++--
novaclient/v2/flavors.py   |  2 +-
novaclient/v2/floating_ips.py  |  3 ++
novaclient/v2/floating_ips_bulk.py | 14 +---
novaclient/v2/servers.py   | 16 ++---
novaclient/v2/shell.py | 11 +++---
requirements.txt   |  6 ++--
test-requirements.txt  |  6 ++--
32 files changed, 198 insertions(+), 105 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index bc729cf..9fe2b95 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,3 +7,3 @@ iso8601>=0.1.9
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.serialization>=1.2.0   # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index acdbc24..6790cc6 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11 +11 @@ mock>=1.0
-requests-mock>=0.5.1  # Apache-2.0
+requests-mock>=0.6.0  # Apache-2.0
@@ -13 +13 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
@@ -17 +17 @@ testtools>=0.9.36,!=1.2.0
-tempest-lib>=0.3.0
+tempest-lib>=0.4.0



__
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-dev] [release] python-keystoneclient-kerberos release 0.2.0 (liberty)

[Doug Hellmann]

We are eager to announce the release of:

python-keystoneclient-kerberos 0.2.0: Kerberos authentication for the
OpenStack clients

For more details, please see the git log history below and:

http://launchpad.net/python-keystoneclient/+milestone/0.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-keystoneclient

Changes in python-keystoneclient-kerberos 0.1.4..0.2.0
--

adf5897 2015-04-16 18:13:16 + Uncap library requirements for liberty

Diffstat (except docs and test files)
-

requirements.txt  | 2 +-
test-requirements.txt | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b604bb6..d598b7d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ pbr>=0.6,!=0.7,<1.0
-python-keystoneclient>=1.0.0
+python-keystoneclient>=1.1.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 4ff26ac..7569eb2 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ python-subunit>=0.0.18
-requests-mock>=0.5.1  # Apache-2.0
+requests-mock>=0.6.0  # Apache-2.0
@@ -12,2 +12,2 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.2.0  # Apache-2.0
-oslotest>=1.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0



__
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-dev] [release] python-glanceclient release 0.18.0 (liberty)

[Doug Hellmann]

We are gleeful to announce the release of:

python-glanceclient 0.18.0: OpenStack Image API Client Library

For more details, please see the git log history below and:

http://launchpad.net/python-glanceclient/+milestone/0.18.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-glanceclient

Changes in python-glanceclient 0.17.0..0.18.0
-

8b4456a 2015-04-16 18:13:00 + Uncap library requirements for liberty
76c9f68 2015-04-14 10:00:51 +0200 Add unit tests for log_curl_request
bd0aa06 2015-04-11 11:04:23 + Fix https stack trace on python 3.4 client
c698b4e 2015-04-11 11:03:54 + Fix client when using no ssl compression
64a1a0f 2015-04-11 11:00:19 + Add SSL cert verification regression tests
c730266 2015-04-11 00:02:22 +1200 Omit 'locations' as image-create parameter
a6234d1 2015-04-02 06:15:48 + Creating task with invalid property crashes 
in py3
fd2f989 2015-03-28 14:22:49 +1100 Don't accept *args for client
e386e44 2015-03-28 14:21:51 +1100 Stub authentication requests rather than 
plugins
27f70bb 2015-03-28 14:19:52 +1100 Remove keystoneclient mocks
02b1a05 2015-03-28 14:16:00 +1100 Replace mox in tests with requests-mock
90407d9 2015-03-27 19:03:48 +0300 Expose 'is_base' schema property attribute
2c08b40 2015-03-26 12:42:36 + Validate tag name when filtering for images
13b5a5a 2015-03-26 12:42:18 + Remove redundant FakeSchemaAPI __init__ method
c149a94 2015-03-22 17:26:55 +0530 glance image-show now have --human-readable 
option
42d7548 2015-03-19 20:53:54 -0600 Test unit for checking update active images
6d864ef 2015-03-19 10:24:34 +0100 Correct help messages for image-update command
f272ab3 2015-02-16 11:09:00 +1100 Generate API documentation
a1bb3eb 2014-11-26 12:20:40 -0600 Use any instead of False in generator

Diffstat (except docs and test files)
-

glanceclient/client.py|   9 ++
glanceclient/common/https.py  |  11 +-
glanceclient/common/utils.py  |   4 +-
glanceclient/v1/client.py |   4 +-
glanceclient/v1/shell.py  |   6 +-
glanceclient/v2/client.py |   4 +-
glanceclient/v2/images.py |  15 ++-
glanceclient/v2/schemas.py|  21 ++-
glanceclient/v2/shell.py  |   9 +-
glanceclient/v2/tasks.py  |   2 +-
requirements.txt  |   8 +-
test-requirements.txt |   5 +-
tox.ini   |   2 +-
25 files changed, 608 insertions(+), 471 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index c34e04a..7245e72 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ PrettyTable>=0.7,<0.8
-python-keystoneclient>=1.0.0
+python-keystoneclient>=1.1.0
@@ -12,3 +12,3 @@ warlock>=1.0.1,<2
-six>=1.7.0
-oslo.utils>=1.2.0   # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
+six>=1.9.0
+oslo.utils>=1.4.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 06cb4aa..b0e7f67 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +7,0 @@ discover
-mox3>=0.7.0
@@ -10 +9 @@ mock>=1.0
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
@@ -13,0 +13,2 @@ testtools>=0.9.36,!=1.2.0
+fixtures>=0.3.14
+requests-mock>=0.6.0  # Apache-2.0



__
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-dev] [release] python-neutronclient release 2.5.0 (liberty)

[Doug Hellmann]

We are pumped to announce the release of:

python-neutronclient 2.5.0: CLI and Client Library for OpenStack
Networking

For more details, please see the git log history below.


Changes in python-neutronclient 2.4.0..2.5.0


2f0fc2c 2015-04-16 18:13:29 + Uncap library requirements for liberty

Diffstat (except docs and test files)
-

requirements.txt  | 8 
test-requirements.txt | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 12f89a0..b7a9ee1 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ argparse
-cliff>=1.10.0,<1.11.0  # Apache-2.0
+cliff>=1.10.0  # Apache-2.0
@@ -9,3 +9,3 @@ netaddr>=0.7.12
-oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
-oslo.serialization>=1.4.0,<1.5.0   # Apache-2.0
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index b910353..1c395de 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12,2 +12,2 @@ mock>=1.0
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
-oslotest>=1.5.1,<1.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0



__
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-dev] [release] python-magnumclient release 0.1.0 (liberty)

[Doug Hellmann]

__
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-dev] [release] python-cinderclient release 1.2.0 (liberty)

[Doug Hellmann]

We are tickled pink to announce the release of:

python-cinderclient 1.2.0: OpenStack Block Storage API Client Library

For more details, please see the git log history below.


Changes in python-cinderclient 1.1.1..1.2.0
---

ae03d2a 2015-04-20 15:50:08 + Enable version discovery
b4b0eea 2015-04-20 09:44:13 -0600 Remove print statement in unit test
2fa7e1e 2015-04-20 15:10:36 + Add ability to specify path var to testr
c8f670e 2015-04-16 18:12:53 + Uncap library requirements for liberty
fa8c7e3 2015-04-12 17:02:18 +0530 cinder list now supports filter by tenant
de36755 2015-03-31 23:37:18 -0700 Allow cinderclient to handle exception 
response
e5a1304 2015-03-23 21:20:10 -0600 Move unit tests into test directory
e2afc01 2015-03-17 14:21:48 + bash_completion now shows only subcommands 
when subcommand is "help"
425565b 2015-03-16 18:45:21 + Update to change name for volume type client
0f73c5f 2015-03-16 23:26:22 +0530 cinder list now prints dash '-' when data is 
None
57c9bf1 2015-03-10 09:45:00 +0530 cinderclient accepts arguments after metadata 
without -- separator
f47f973 2015-03-06 01:45:08 +0530 Updated help on cinder reset-state cli
fc7ebb1 2015-02-25 18:51:43 + Adopt CLI sorting argument guidelines
c01529f 2015-02-24 16:11:46 +0800 Add missing all-tenants option to 
transfer-list
d76387c 2015-02-12 10:52:17 -0300 Add -d short option for --debug
9176e44 2015-02-10 11:25:31 + Fix volume_transfers import in v2
f9eefcc 2015-02-05 20:19:06 + Updated from global requirements
ff3e5a4 2015-02-04 20:25:14 + reset-state should warn that it is DB only
e5779d3 2015-01-30 16:50:21 + Expose cinder's scheduler pool API
e9e8aab 2015-01-28 13:36:20 -0600 Fix up help message for reset-state call
11e5e4f 2015-01-22 15:11:33 + Add tests for consistency groups and 
cgsnapshots
0560f78 2015-01-22 14:52:25 + cinder list fails with 'name' sort key
200aeae 2015-01-15 10:56:27 +0800 Remove commented code in 
cinderclient/v1/volumes.py
fdba364 2015-01-13 16:09:34 -0500 Make cinderclient metadata CLI output 
consistent
0b38d75 2015-01-12 22:58:00 + Leverage openstack.common.importutils 
import_class
3a97cb2 2015-01-08 12:21:33 + v2 error message grammatical error
1d38426 2015-01-05 16:04:43 -0500 Add command to show pool information for 
backends
b0e4cc1 2014-12-22 02:23:00 + Client output is not sorted by --sort_key
6f8c235 2014-12-19 13:26:21 -0500 Add support for os-volume-type-access 
extension
bc2b8bf 2014-12-17 07:27:38 -0800 Added type description for volume type client
7783767 2014-12-09 11:41:27 -0600 Don't use sessions if third party plugin is 
used
6f66494 2014-12-05 03:30:39 + Workflow documentation is now in infra-manual
5920994 2014-12-04 02:20:59 + List all the request items when the list is 
over osapi_max_limit
d9da860 2014-12-03 16:39:23 -0500 Allow CG quota to be showed and updated
7a50182 2014-12-01 02:43:52 + Add the parameter bypass_url to the cinder 
client
a68ba94 2014-12-01 02:16:44 + Use newer features from keystoneclient
4ccb70a 2014-11-30 19:37:10 +0200 Support Volume Backup Quota
713e331 2014-11-27 21:48:14 + Updated from global requirements
616b982 2014-11-25 12:39:17 -0600 Add ability to create volume from image by 
image name
ac9ef2b 2014-11-25 15:14:09 + Remove cinderclient/tests from coverage report
029a776 2014-11-25 01:28:54 + Fix 'search_opts' error with backup delete 
command
542a675 2014-11-17 16:33:07 +0530 Remove unused methods from utils.py
384b882 2014-10-27 14:41:54 + Fix incorrect variable name
a6b434e 2014-10-24 11:57:42 -0400 cinderclient does not retry with 
TimeoutException
122bf5b 2014-10-24 15:43:04 + Adds tty password entry for cinderclient
d202875 2014-10-09 15:22:49 -0400 Don't git ignore .mailmap and .testr.conf
e76f06b 2014-10-08 17:00:51 -0400 gitignore /.*
6f5fd37 2014-10-08 19:30:10 +0400 Add profiling support to cinderclient
20df1cb 2014-10-02 15:24:01 -0400 Fix volume name support of unmanage and 
replication commands
1cb1350 2014-10-02 14:58:19 + Simplify cinder manage command args
41f5835 2014-10-01 14:34:13 -0600 Add swap and it's variants to gitignore
1dc8081 2014-09-24 20:03:58 -0400 Docstring of unmanage subcommand is missing
5bf13e1 2014-09-19 10:35:35 -0400 Remove Python 2.4 compat shim
b03d1e1 2014-09-13 09:40:00 +0200 Stop using intersphinx
f7d391e 2014-09-09 18:40:31 + client HTTPClient __init__ fails if auth_url 
None
17e4d6c 2014-09-08 11:31:22 + Fixed typos found by RETF rules
4a7014a 2014-08-29 00:09:43 -0700 Ability to pass metadata during snapshot 
create
cebd81e 2014-07-23 12:35:33 + Fix comment in tearDown()
31a7ae5 2014-07-03 15:06:51 +0800 Use immutable arg rather mutable arg
05d9232 2014-07-01 14:53:54 +0800 Add CONTRIBUTING.rst

Diffstat (except docs and test files)
-

.coveragerc|2 +-
.gitignore 

[openstack-dev] [release] oslo.vmware release 0.12.0 (liberty)

[Doug Hellmann]

We are tickled pink to announce the release of:

oslo.vmware 0.12.0: Oslo VMware library

For more details, please see the git log history below and:

http://launchpad.net/oslo.vmware/+milestone/0.12.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.vmware

Changes in oslo.vmware 0.11.1..0.12.0
-

9338d7f 2015-04-16 18:10:45 + Uncap library requirements for liberty
46f2327 2015-04-04 02:30:40 -0400 Cleanup README.rst and setup.cfg
bc146a3 2015-04-03 14:11:39 + Update to latest hacking
0f73e5d 2015-03-25 06:04:48 + Imported Translations from Transifex
6d8594a 2015-03-24 07:30:29 -0700 Revert "VMWare NSXv: Common components"
9b57b13 2015-03-21 00:17:14 + Updated from global requirements
3879e83 2015-03-20 16:14:43 + Move pylint dependency to tox.ini
8445b49 2015-03-20 03:35:11 -0700 Move exception related tests to new module

Diffstat (except docs and test files)
-

README.rst |2 +-
.../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po  |   10 +-
oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po   |   81 +-
oslo.vmware/locale/oslo.vmware-log-info.pot|8 +-
oslo.vmware/locale/oslo.vmware.pot |  131 +--
oslo_vmware/network/__init__.py|0
oslo_vmware/network/nsx/__init__.py|0
oslo_vmware/network/nsx/nsxv/__init__.py   |0
oslo_vmware/network/nsx/nsxv/api/__init__.py   |0
oslo_vmware/network/nsx/nsxv/api/api.py|  598 --
oslo_vmware/network/nsx/nsxv/api/api_helper.py |  117 --
oslo_vmware/network/nsx/nsxv/common/__init__.py|0
oslo_vmware/network/nsx/nsxv/common/exceptions.py  |   97 --
oslo_vmware/network/nsx/nsxv/objects/__init__.py   |0
.../network/nsx/nsxv/objects/edge_cfg_obj.py   |   67 --
.../network/nsx/nsxv/objects/loadbalancer.py   |  392 ---
.../network/nsx/nsxv/test_nsxv_loadbalancer.py |   98 --
requirements-py3.txt   |   12 +-
requirements.txt   |   12 +-
setup.cfg  |2 +-
test-requirements.txt  |5 +-
tox.ini|3 +
30 files changed, 158 insertions(+), 2947 deletions(-)


Requirements updates


diff --git a/requirements-py3.txt b/requirements-py3.txt
index fba2804..ab96725 100644
--- a/requirements-py3.txt
+++ b/requirements-py3.txt
@@ -5 +5 @@
-stevedore>=1.1.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
@@ -14,3 +14,3 @@ six>=1.9.0
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.serialization>=1.2.0   # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
@@ -23 +23 @@ suds-jurko>=0.6
-eventlet>=0.16.1
+eventlet>=0.16.1,!=0.17.0
@@ -27 +27 @@ urllib3>=1.8.3
-oslo.concurrency>=1.4.1 # Apache-2.0
+oslo.concurrency>=1.8.0 # Apache-2.0
diff --git a/requirements.txt b/requirements.txt
index 4b4b2bb..807bcfc 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ pbr>=0.6,!=0.7,<1.0
-stevedore>=1.1.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
@@ -16,3 +16,2 @@ six>=1.9.0
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.serialization>=1.2.0   # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
@@ -25,2 +24 @@ suds>=0.4
-eventlet>=0.16.1
-httplib2>=0.7.5
+eventlet>=0.16.1,!=0.17.0
@@ -29 +27 @@ urllib3>=1.8.3
-oslo.concurrency>=1.4.1 # Apache-2.0
+oslo.concurrency>=1.8.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index cfaa103..5346047 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -6,2 +6 @@
-hacking>=0.9.2,<0.10
-pylint>=1.3.0  # GNU GPL v2
+hacking>=0.10.0,<0.11
@@ -24 +23 @@ coverage>=3.6
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] python-keystoneclient release 1.4.0 (liberty)

[Doug Hellmann]

We are thrilled to announce the release of:

python-keystoneclient 1.4.0: Client Library for OpenStack Identity

For more details, please see the git log history below.


Changes in python-keystoneclient 1.3.0..1.4.0
-

8b80097 2015-04-16 18:13:09 + Uncap library requirements for liberty
85eeecb 2015-04-14 15:09:22 + Fix s3_token middleware parsing insecure 
option
b3c1867 2015-04-14 15:06:56 +1000 Make process_header private
a335b7f 2015-04-11 11:13:55 -0500 Fix tests to work with requests<2.3
e79d571 2015-04-09 10:48:30 +1000 Increase minimum token life required
52e4305 2015-04-06 23:39:30 -0400 Update sample data with audit ids
6ee6af2 2015-04-06 22:47:54 -0400 pep8 fix for CMS
57b0fe2 2015-04-06 13:41:41 -0300 Inherited role domain calls on keystoneclient 
v3
1628b77 2015-03-31 12:47:16 -0400 Add support to create ECP assertion based on 
a token
a2fc6cf 2015-03-31 12:43:16 -0400 Add support to create SAML assertion based on 
a token
389c3ee 2015-03-31 10:03:20 +1100 Allow requesting an unscoped Token
dfc9009 2015-03-28 14:33:15 +1100 Expose audit_id via AccessInfo
cf97f27 2015-03-26 20:31:02 + Replace assertRaisesRegexp with 
assertRaisesRegex
981c499 2015-03-26 11:01:31 + Updated from global requirements
161c869 2015-03-24 21:31:27 +1100 Return None for missing trust_id in fixture
e39eec0 2015-03-18 10:25:55 +1100 Provide a generic auth plugin loader
c0145e5 2015-03-17 08:27:47 -0500 Make non-import packages lazy
be1e94f 2015-03-09 16:11:51 +1100 Don't autodoc the test suite

Diffstat (except docs and test files)
-

examples/pki/cms/auth_token_scoped_expired.pkiz|   2 +-
examples/pki/cms/auth_v3_token_revoked.json|   1 +
examples/pki/cms/auth_v3_token_revoked.pkiz|   2 +-
examples/pki/cms/auth_v3_token_scoped.json |   1 +
examples/pki/cms/auth_v3_token_scoped.pkiz |   2 +-
examples/pki/cms/revocation_list.json  |   2 +-
examples/pki/cms/revocation_list.pem   |  20 ++--
examples/pki/cms/revocation_list.pkiz  |   2 +-
keystoneclient/__init__.py |  39 +--
keystoneclient/access.py   |  57 ++
keystoneclient/auth/base.py|  36 --
keystoneclient/auth/identity/base.py   |   5 +-
keystoneclient/auth/identity/v3/base.py|  11 +-
keystoneclient/base.py |   5 +
keystoneclient/common/cms.py   |   4 +-
keystoneclient/fixture/v2.py   |  33 +-
keystoneclient/fixture/v3.py   |  30 -
keystoneclient/middleware/s3_token.py  |   3 +-
keystoneclient/session.py  |   8 +-
keystoneclient/v3/contrib/federation/core.py   |   2 +
keystoneclient/v3/contrib/federation/saml.py   |  81 ++
keystoneclient/v3/roles.py |  86 +++
requirements.txt   |  10 +-
test-requirements.txt  |   8 +-
38 files changed, 872 insertions(+), 90 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index cf4e036..e20190a 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11,4 +11,4 @@ netaddr>=0.7.12
-oslo.config>=1.9.0  # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.serialization>=1.2.0   # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
@@ -18 +18 @@ six>=1.9.0
-stevedore>=1.1.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 1bbc10d..0fb4968 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -15,2 +15,2 @@ oauthlib>=0.6
-oslosphinx>=2.2.0  # Apache-2.0
-oslotest>=1.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -18 +18 @@ pycrypto>=2.6
-requests-mock>=0.5.1  # Apache-2.0
+requests-mock>=0.6.0  # Apache-2.0
@@ -20 +20 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-tempest-lib>=0.2.0
+tempest-lib>=0.4.0



__
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-dev] [release] python-heatclient release 0.5.0 (liberty)

[Doug Hellmann]

We are tickled pink to announce the release of:

python-heatclient 0.5.0: OpenStack Orchestration API Client Library

For more details, please see the git log history below and:

http://launchpad.net/python-heatclient/+milestone/0.5.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-heatclient

Changes in python-heatclient 0.4.0..0.5.0
-

7c70bcf 2015-04-20 13:42:26 + correction in function names under 
test_resource
77204a3 2015-04-16 18:13:03 + Uncap library requirements for liberty
6b08533 2015-04-02 10:40:01 +1300 Make README.rst comply with expected format
65a1c78 2015-04-01 16:55:17 +0200 Remove the deprecated shell commands

Diffstat (except docs and test files)
-

README.rst |  16 ++--
heatclient/v1/shell.py | 161 -
requirements.txt   |   6 +-
test-requirements.txt  |   4 +-
6 files changed, 16 insertions(+), 181 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b8eaca6..a290a65 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -10,3 +10,3 @@ PrettyTable>=0.7,<0.8
-oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
-oslo.serialization>=1.4.0,<1.5.0   # Apache-2.0
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index cc3962d..50abc48 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13,2 +13,2 @@ mox3>=0.7.0
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
-oslotest>=1.5.1,<1.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0



__
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-dev] [release] python-designateclient release 1.2.0 (liberty)

[Doug Hellmann]

We are happy to announce the release of:

python-designateclient 1.2.0: OpenStack DNS as a Service - Client

For more details, please see the git log history below and:

http://launchpad.net/python-designateclient/+milestone/1.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-designateclient

Changes in python-designateclient 1.1.1..1.2.0
--

39d8b54 2015-04-21 15:07:07 + Update README to work with release tools
ed808de 2015-04-16 18:12:56 + Uncap library requirements for liberty
94c242f 2015-03-21 00:17:31 + Updated from global requirements
debf39a 2015-02-24 12:44:24 +0530 Added extra previllege to list all domains 
from all tenants
4118d0f 2015-02-20 13:59:17 + Updated from global requirements
ab3ed69 2015-02-13 02:00:03 + Updated from global requirements
e0e428a 2015-01-29 15:07:09 +0100 Fix if checking on ttl for Create/Update 
commands
92b5872 2015-01-26 10:34:00 + Updated from global requirements
e20b1d3 2014-12-05 03:30:39 + Workflow documentation is now in infra-manual

Diffstat (except docs and test files)
-

README.rst | 17 +
designateclient/cli/domains.py |  4 ++--
designateclient/cli/records.py |  4 ++--
designateclient/shell.py   |  4 
designateclient/utils.py   |  3 ++-
designateclient/v1/__init__.py |  5 -
requirements.txt   |  8 
8 files changed, 36 insertions(+), 11 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 82387a7..2ced90a 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4 +4 @@
-cliff>=1.7.0  # Apache-2.0
+cliff>=1.10.0  # Apache-2.0
@@ -7 +7 @@ pbr>=0.6,!=0.7,<1.0
-python-keystoneclient>=0.11.1
+python-keystoneclient>=1.1.0
@@ -9,2 +9,2 @@ requests>=2.2.0,!=2.4.0
-six>=1.7.0
-stevedore>=1.1.0  # Apache-2.0
+six>=1.9.0
+stevedore>=1.3.0  # Apache-2.0



__
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-dev] [release] python-barbicanclient release 3.1.0 (liberty)

[Doug Hellmann]

We are amped to announce the release of:

python-barbicanclient 3.1.0: Client Library for OpenStack Barbican Key
Management API

For more details, please see the git log history below.


Changes in python-barbicanclient 3.0.3..3.1.0
-

e24ed33 2015-04-20 13:58:33 -0500 Excluding tests from coverage report
137a893 2015-04-17 10:24:26 -0500 Fix the clientrc file to match defaults and 
add docs
f2ddf1e 2015-04-16 17:36:59 -0500 Updating client and client docs for accuracy
c1fd9d4 2015-04-16 16:13:41 -0500 Porting over more documentation to RST from 
cli wiki
538daa3 2015-04-16 18:12:46 + Uncap library requirements for liberty
840a98c 2015-04-15 15:38:27 -0500 Adding payload flag to get secret
e06df05 2015-04-15 14:20:56 -0500 Raising errors from the client instead of 
ksclient
bbd14af 2015-04-10 11:43:21 +0200 Fix order listing on the command line.
f0fe464 2015-04-08 19:02:22 -0500 Fixing the broken functional tests
54a52ae 2015-04-02 08:32:23 +1100 Use the ksc Adapter instead of custom 
HTTPClient
7c0a1d7 2015-03-26 15:47:11 -0500 Negative tests for orders

Diffstat (except docs and test files)
-

.coveragerc|   2 +-
barbicanclient/barbican_cli/orders.py  |   6 +-
barbicanclient/barbican_cli/secrets.py |  14 +-
barbicanclient/base.py |   2 +-
barbicanclient/client.py   | 130 +-
barbicanclient/containers.py   |  37 +++-
barbicanclient/exceptions.py   |  28 +++
barbicanclient/orders.py   |  55 --
barbicanclient/secrets.py  |  35 ++--
clientrc   |  25 ++-
.../client/v1/functional/test_containers.py|  47 +++--
.../client/v1/functional/test_orders.py| 196 +
.../client/v1/functional/test_secrets.py   |  81 ++---
requirements.txt   |   8 +-
test-requirements.txt  |   4 +-
20 files changed, 770 insertions(+), 217 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b125e91..187135f 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9,4 +9,4 @@ python-keystoneclient>=1.1.0
-cliff>=1.10.0,<1.11.0  # Apache-2.0
-oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
-oslo.serialization>=1.4.0,<1.5.0   # Apache-2.0
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+cliff>=1.10.0  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 684cef9..036e2f9 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12 +12 @@ testtools>=0.9.36,!=1.2.0
-oslotest>=1.5.1,<1.6.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -17 +17 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] python-ironicclient release 0.6.0 (liberty)

[Doug Hellmann]

We are psyched to announce the release of:

python-ironicclient 0.6.0: OpenStack Bare Metal Provisioning API
Client Library

For more details, please see the git log history below.


Changes in python-ironicclient 0.5.1..0.6.0
---

8f476f4 2015-04-21 00:10:08 + Encode exception on cli for UnicodeDecodeError
28bdd0b 2015-04-17 16:25:44 +0200 Implement and enable retries on Conflict
fba8364 2015-04-16 18:13:06 + Uncap library requirements for liberty

Diffstat (except docs and test files)
-

ironicclient/client.py   |   9 +-
ironicclient/common/http.py  |  46 +
ironicclient/shell.py|  32 +-
requirements.txt |   4 +-
test-requirements.txt|   2 +-
6 files changed, 265 insertions(+), 11 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b20966d..b837718 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,2 +7,2 @@ lxml>=2.3
-oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index d2e45fe..57e162e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11 +11 @@ mock>=1.0
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] oslo.messaging release 1.9.0 (liberty)

[Doug Hellmann]

We are happy to announce the release of:

oslo.messaging 1.10.0: Oslo Messaging API

For more details, please see the git log history below and:

http://launchpad.net/oslo.messaging/+milestone/1.10.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.messaging

Changes in oslo.messaging 1.9.0..1.10.0
---

9dd8441 Uncap library requirements for liberty
72c5014 Use unittest.mock on Python 3
a00d075 Enable redis test dependency on Python 3
9ef3fa8 Remove amqp driver 'unpacked content' logging
ef3575d Updated from global requirements
4decea1 Add pypi download + version badges
48441a6 Fix TypeError caused by err_msg formatting
6a83bfb Fix typo in oslo_messaging/_drivers/protocols/amqp/opts.py
d214770 Document notification_driver possible values
07c3e8b Do not skip functional test for amqp driver
5ec72e8 Add functional test for notify.logger
6f4e32a Properly deserialize received AMQP 1.0 messages
fb8c431 Make notify driver messaging play well with publish_errors
c244126 Imported Translations from Transifex
49c6d9c Sync with latest oslo-incubator
f033fc9 Don't raise Timeout on no-matchmaker results

Diffstat (except docs and test files)
-

README.rst |  8 +++
.../locale/en_GB/LC_MESSAGES/oslo.messaging.po | 22 +++---
oslo_messaging/_drivers/amqp.py|  6 +-
oslo_messaging/_drivers/impl_rabbit.py |  2 +-
oslo_messaging/_drivers/impl_zmq.py|  9 ++-
oslo_messaging/_drivers/protocols/amqp/driver.py   |  3 +-
oslo_messaging/_drivers/protocols/amqp/opts.py |  2 +-
oslo_messaging/notify/log_handler.py   |  3 +-
oslo_messaging/notify/logger.py| 34 -
oslo_messaging/notify/notifier.py  |  4 +-
oslo_messaging/openstack/common/versionutils.py| 13 +++-
requirements-py3.txt   | 14 ++--
requirements.txt   | 14 ++--
test-requirements-py3.txt  |  8 ++-
test-requirements.txt  |  6 +-
46 files changed, 273 insertions(+), 99 deletions(-)


Requirements updates


diff --git a/requirements-py3.txt b/requirements-py3.txt
index 4ec18c6..a37a824 100644
--- a/requirements-py3.txt
+++ b/requirements-py3.txt
@@ -5,6 +5,6 @@
-oslo.config>=1.9.3,<1.10.0  # Apache-2.0
-oslo.context>=0.2.0,<0.3.0 # Apache-2.0
-oslo.serialization>=1.4.0,<1.5.0   # Apache-2.0
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
-oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
-stevedore>=1.3.0,<1.4.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
+oslo.context>=0.2.0 # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
@@ -22 +22 @@ kombu>=2.5.0
-oslo.middleware>=1.0.0,<1.1.0  # Apache-2.0
+oslo.middleware>=1.0.0  # Apache-2.0
diff --git a/requirements.txt b/requirements.txt
index ec5fef6..aaf7390 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,6 +7,6 @@ pbr>=0.6,!=0.7,<1.0
-oslo.config>=1.9.3,<1.10.0  # Apache-2.0
-oslo.context>=0.2.0,<0.3.0 # Apache-2.0
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
-oslo.serialization>=1.4.0,<1.5.0   # Apache-2.0
-oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
-stevedore>=1.3.0,<1.4.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
+oslo.context>=0.2.0 # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
@@ -29 +29 @@ kombu>=2.5.0
-oslo.middleware>=1.0.0,<1.1.0  # Apache-2.0
+oslo.middleware>=1.0.0  # Apache-2.0
diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt
index f137195..22b4c4e 100644
--- a/test-requirements-py3.txt
+++ b/test-requirements-py3.txt
@@ -10 +9,0 @@ fixtures>=0.3.14
-mock>=1.0
@@ -16 +15,4 @@ testtools>=0.9.36,!=1.2.0
-oslotest>=1.5.1,<1.6.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
+
+# for test_matchmaker_redis
+redis>=2.10.0
@@ -25 +27 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 5afaa74..c962f4a 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -16 +16 @@ testtools>=0.9.36,!=1.2.0
-oslotest>=1.5.1,<1.6.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -25 +25 @@ redis>=2.10.0
-pyzmq>=14.3.1
+pyzmq>=14.3.1 # LGPL+BSD
@@ -34 +34 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0

__
OpenStack 

[openstack-dev] [release] oslo.utils release 1.5.0 (liberty)

[Doug Hellmann]

We are pleased to announce the release of:

oslo.utils 1.5.0: Oslo Utility library

For more details, please see the git log history below and:

http://launchpad.net/oslo.utils/+milestone/1.5.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.utils

Changes in oslo.utils 1.4.0..1.5.0
--

a18b051 2015-04-17 17:57:07 + Add liberty release name to versionutils
824732d 2015-04-17 17:56:53 + Expose opts entry point for version_utils
9044829 2015-04-17 17:56:41 + Switch from oslo.config to oslo_config
bbf48f0 2015-04-17 17:56:26 + Remove oslo.log code and clean up 
versionutils API
5ae762c 2015-04-17 17:56:11 + Remove code that moved to oslo.i18n
b7e5c5f 2015-04-17 17:55:56 + Enhance versionutils.deprecated to work with 
classes
0672a61 2015-04-17 17:55:33 + Add Kilo release name to versionutils
427b8af 2015-04-17 13:54:48 -0400 Allow deprecated decorator to specify no plan 
for removal
3371550 2015-04-16 18:09:46 + Uncap library requirements for liberty
96e1ab7 2015-04-16 11:37:26 + Add JUNO as a target to versionutils module
3a7fca5 2015-04-13 10:49:20 -0700 Add missing reflection + uuidutils docs
c50d816 2015-04-10 17:15:31 +0200 timeutils: avoid passing leap second to 
datetime
cb88d17 2015-04-07 18:19:37 -0700 Add pypi download + version badges
6ab5ae2 2015-04-04 02:22:36 -0400 Cleanup README.rst and setup.cfg
0fae531 2015-04-03 12:27:59 + pep8: fixed multiple violations
486fac2 2015-04-03 12:27:59 + Use oslotest instead of common test module
a55dc72 2015-04-03 12:27:59 + Use hacking import_exceptions for 
gettextutils._
e00421c 2015-04-03 12:27:59 + fixed typos
7c8ebe8 2015-04-03 12:27:59 + Fix violations of H302:import only modules
db513b5 2015-04-03 12:27:59 + Adds decorator to deprecate functions and 
methods
d5f98cd 2015-04-03 12:27:59 + Remove vim header
6afa675 2015-04-03 12:27:59 + Add `versionutils` for version compatibility 
checks
597d5dd 2015-04-03 12:27:59 + Update hacking setting
a649d55 2015-03-28 02:34:31 + Updated from global requirements
69526a1 2015-03-26 06:12:10 + Imported Translations from Transifex
782e41f 2015-03-23 17:53:49 + Clean up TestIsIPv6Enabled
b200da8 2015-03-23 14:37:56 +0100 Fix test_netutils: stop patches
4ab214e 2015-03-18 12:37:01 -0400 Add a new string to the list of masked 
patterns
1a6dc73 2015-03-16 15:33:18 -0700 Provide common `fetch_current_thread_functor` 
function
6fe565d 2015-03-16 06:11:07 + Imported Translations from Transifex
e1bc333 2015-01-28 13:44:59 -0500 add dependency warning to requirements.txt

Diffstat (except docs and test files)
-

README.rst |  15 +-
openstack/common/versionutils.py   | 262 +++
oslo.utils/locale/de/LC_MESSAGES/oslo.utils.po |  30 ++-
oslo.utils/locale/en_GB/LC_MESSAGES/oslo.utils.po  |  30 ++-
.../locale/fr/LC_MESSAGES/oslo.utils-log-error.po  |  12 +-
.../locale/fr/LC_MESSAGES/oslo.utils-log-info.po   |  43 
oslo.utils/locale/fr/LC_MESSAGES/oslo.utils.po |  32 ++-
oslo.utils/locale/oslo.utils.pot   |  30 ++-
oslo_utils/eventletutils.py|  18 ++
oslo_utils/reflection.py   |   3 +-
oslo_utils/strutils.py |   3 +-
oslo_utils/timeutils.py|   9 +-
oslo_utils/uuidutils.py|   4 +
requirements.txt   |   7 +-
test-requirements.txt  |   6 +-
23 files changed, 849 insertions(+), 74 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index be23276..11d5413 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4,0 +5,5 @@
+# NOTE(dhellmann): Because oslo.utils is used by the client libraries,
+# we do not want to add a lot of dependencies to it. If you find that
+# adding a new feature to oslo.utils means adding a new dependency,
+# that is a likely indicator that the feature belongs somewhere else.
+
@@ -9 +14 @@ iso8601>=0.1.9
-oslo.i18n>=1.3.0  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 0fab2b3..7f335ce 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -5 +5 @@
-hacking>=0.9.1,<0.10
+hacking>=0.10.0,<0.11
@@ -13 +13 @@ testtools>=0.9.36,!=1.2.0
-oslotest>=1.2.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -22 +22 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] pycadf release 0.9.0 (liberty)

[Doug Hellmann]

We are stoked to announce the release of:

pycadf 0.9.0: CADF Library

For more details, please see the git log history below and:

https://launchpad.net/pycadf/+milestone/0.9.0

Please report issues through launchpad:

https://bugs.launchpad.net/pycadf

Changes in pycadf 0.8.0..0.9.0
--

9501f4f 2015-04-16 18:11:14 + Uncap library requirements for liberty
f436f9b 2015-03-21 00:17:21 + Updated from global requirements
b697115 2015-03-17 18:05:45 -0400 update README.rst to include additional links
1a55d1c 2015-03-12 11:47:05 -0400 Remove empty _templates folder
87f5f39 2015-03-11 23:36:36 -0400 Add a section for audit maps
ad80497 2015-03-07 19:28:21 + Fix formatting error for geolocation note
0379e70 2015-03-07 19:27:37 + add a new set of release notes
8180e64 2015-03-07 13:45:29 -0500 Clean up pycadf's doc landing page
25a4227 2015-03-07 12:14:29 -0500 Add api_audit_map.conf for Trove project
72acde6 2015-03-06 17:38:23 + Updated from global requirements
e935333 2015-03-05 04:57:34 + Updated from global requirements
ebc86a7 2015-02-20 13:59:09 + Updated from global requirements
6c1ee2e 2015-02-19 06:00:29 + Additional doc clean up
1613013 2015-02-16 13:57:51 -0500 cleanup documentation

Diffstat (except docs and test files)
-

README.rst |  21 ++--
etc/pycadf/trove_api_audit_map.conf|  23 
requirements.txt   |  10 +-
test-requirements.txt  |   6 +-
24 files changed, 458 insertions(+), 444 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index af6ce08..a446088 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5,4 +5,4 @@ Babel>=1.3
-oslo.config>=1.6.0  # Apache-2.0
-oslo.context>=0.1.0 # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.serialization>=1.2.0   # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
+oslo.context>=0.2.0 # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
@@ -10 +10 @@ pytz>=2013.6
-six>=1.7.0
+six>=1.9.0
diff --git a/test-requirements.txt b/test-requirements.txt
index f68f957..a5cc83d 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11,2 +11,2 @@ mock>=1.0
-oslo.messaging>=1.6.0  # Apache-2.0
-oslotest>=1.2.0  # Apache-2.0
+oslo.messaging>=1.8.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -18 +18 @@ testtools>=0.9.36,!=1.2.0
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] oslo.policy release 0.4.0 (liberty)

[Doug Hellmann]

We are tickled pink to announce the release of:

oslo.policy 0.4.0: Oslo Policy library

For more details, please see the git log history below and:

http://launchpad.net/oslo.policy/+milestone/0.4.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.policy

Changes in oslo.policy 0.3.1..0.4.0
---

cf8b445 2015-04-16 18:07:06 + Uncap library requirements for liberty
9cbfab6 2015-04-14 13:40:48 +0200 Fix invalid indentation in _load_policy_file 
method
3beba6b 2015-04-04 02:33:28 -0400 Cleanup README.rst and setup.cfg
b5f07df 2015-03-31 22:25:00 -0400 Avoid reloading policy files in policy.d for 
every call
a08bc79 2015-03-31 13:35:13 -0400 Lists for Generic Checks
b3fe254 2015-03-21 00:17:05 + Updated from global requirements

Diffstat (except docs and test files)
-

README.rst |   3 +-
oslo_policy/_checks.py |  49 ---
oslo_policy/policy.py  |  43 +++---
requirements.txt   |   6 +-
setup.cfg  |   2 +-
test-requirements.txt  |   4 +-
9 files changed, 349 insertions(+), 28 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index d21ad4b..1d780b2 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5,3 +5,3 @@
-oslo.config>=1.9.0  # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.serialization>=1.2.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index d921e2b..55b42c2 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -6 +6 @@ hacking>=0.10.0,<0.11
-oslotest>=1.2.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -9 +9 @@ oslotest>=1.2.0  # Apache-2.0
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] oslo.versionedobjects release 0.2.0 (liberty)

[Doug Hellmann]

We are excited to announce the release of:

oslo.versionedobjects 0.2.0: Oslo Versioned Objects library

For more details, please see the git log history below and:

http://launchpad.net/oslo.versionedobjects/+milestone/0.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.versionedobjects

Changes in oslo.versionedobjects 0.1.1..0.2.0
-

23d15eb 2015-04-16 18:10:19 + Uncap library requirements for liberty
cfe2cd7 2015-04-04 02:05:55 -0400 Standardize setup.cfg summary for oslo libs
29ac0fc 2015-04-03 14:08:13 + Update to the latest version of hacking
ae5558f 2015-03-28 11:16:59 -0400 Copy the default value for field
2ccb13a 2015-03-21 00:17:16 + Updated from global requirements
1a6bea7 2015-03-19 13:57:45 -0400 New config group for oslo_versionedobjects

Diffstat (except docs and test files)
-

oslo_versionedobjects/__init__.py   | 13 --
oslo_versionedobjects/base.py   |  7 +++--
oslo_versionedobjects/exception.py  |  8 +++---
oslo_versionedobjects/fields.py |  3 ++-
requirements-py3.txt| 21 ---
requirements.txt| 19 --
setup.cfg   |  2 +-
test-requirements.txt   |  9 ---
tox.ini |  2 +-
10 files changed, 78 insertions(+), 46 deletions(-)


Requirements updates


diff --git a/requirements-py3.txt b/requirements-py3.txt
index dd838b4..b24d76c 100644
--- a/requirements-py3.txt
+++ b/requirements-py3.txt
@@ -1,2 +1,5 @@
-eventlet>=0.16.1
-six>=1.7.0
+# The order of packages is significant, because pip processes them in the order
+# of appearance. Changing the order has an impact on the overall integration
+# process, which may cause wedges in the gate later.
+eventlet>=0.16.1,!=0.17.0
+six>=1.9.0
@@ -4,5 +7,5 @@ Babel>=1.3
-oslo.concurrency>=1.4.1 # Apache-2.0
-oslo.context>=0.1.0 # Apache-2.0
-oslo.messaging>=1.4.0,!=1.5.0
-oslo.serialization>=1.2.0   # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
+oslo.concurrency>=1.8.0 # Apache-2.0
+oslo.context>=0.2.0 # Apache-2.0
+oslo.messaging>=1.8.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
@@ -10,2 +13,2 @@ iso8601>=0.1.9
-oslo.log>=0.1.0
-oslo.i18n>=1.3.0  # Apache-2.0
+oslo.log>=1.0.0  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
diff --git a/requirements.txt b/requirements.txt
index 87ccf48..c889c07 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1 +1,4 @@
-six>=1.7.0
+# The order of packages is significant, because pip processes them in the order
+# of appearance. Changing the order has an impact on the overall integration
+# process, which may cause wedges in the gate later.
+six>=1.9.0
@@ -3,5 +6,5 @@ Babel>=1.3
-oslo.concurrency>=1.4.1 # Apache-2.0
-oslo.context>=0.1.0 # Apache-2.0
-oslo.messaging>=1.4.0,!=1.5.0
-oslo.serialization>=1.2.0   # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
+oslo.concurrency>=1.8.0 # Apache-2.0
+oslo.context>=0.2.0 # Apache-2.0
+oslo.messaging>=1.8.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
@@ -9,2 +12,2 @@ iso8601>=0.1.9
-oslo.log>=0.1.0
-oslo.i18n>=1.3.0  # Apache-2.0
+oslo.log>=1.0.0  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 8915308..368b46b 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -1,2 +1,5 @@
-hacking>=0.5.6,<0.8
-oslotest>=1.2.0  # Apache-2.0
+# The order of packages is significant, because pip processes them in the order
+# of appearance. Changing the order has an impact on the overall integration
+# process, which may cause wedges in the gate later.
+hacking>=0.10.0,<0.11
+oslotest>=1.5.1  # Apache-2.0
@@ -5 +8 @@ testtools>=0.9.36,!=1.2.0
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] python-ceilometerclient release 1.2.0 (liberty)

[Doug Hellmann]

We are delighted to announce the release of:

python-ceilometerclient 1.2.0: OpenStack Telemetry API Client Library

For more details, please see the git log history below.


Changes in python-ceilometerclient 1.1.0..1.2.0
---

220371b 2015-04-16 18:12:50 + Uncap library requirements for liberty
16880fc 2015-04-02 18:43:25 +0800 print user friendly error message for alarm 
update time constraints

Diffstat (except docs and test files)
-

ceilometerclient/v2/alarms.py |  5 +++--
requirements.txt  |  8 
test-requirements.txt |  2 +-
4 files changed, 25 insertions(+), 7 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 6ff32c2..bbeb1b6 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,3 +7,3 @@ iso8601>=0.1.9
-oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
-oslo.serialization>=1.4.0,<1.5.0   # Apache-2.0
-oslo.utils>=1.4.0,<1.5.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
@@ -14 +14 @@ six>=1.9.0
-stevedore>=1.3.0,<1.4.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 953bfe9..99e1c7c 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ mock>=1.0
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] oslo.serialization release 1.5.0 (liberty)

[Doug Hellmann]

We are satisfied to announce the release of:

oslo.serialization 1.5.0: Oslo Serialization library

For more details, please see the git log history below and:

http://launchpad.net/oslo.serialization/+milestone/1.5.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.serialization

Changes in oslo.serialization 1.4.0..1.5.0
--

6665672 2015-04-16 11:27:46 -0700 Expose base msgpack exceptions so users don't 
need to import
b2c235e 2015-04-16 18:08:08 + Uncap library requirements for liberty
4ada51b 2015-04-14 21:09:14 + More docstring cleanups/tweaks
58c1f29 2015-04-14 14:08:23 -0700 Add docstring(s) to handler registry(s)
5b4e919 2015-04-07 18:16:48 -0700 Add pypi download + version badges
d6782d9 2015-04-04 02:25:32 -0400 Cleanup README.rst and setup.cfg
c7898c2 2015-03-31 17:29:41 -0700 Make the msgpackutils handlers more extendable
ef8657f 2015-03-21 00:17:09 + Updated from global requirements

Diffstat (except docs and test files)
-

README.rst |  11 +-
oslo_serialization/jsonutils.py|  16 +-
oslo_serialization/msgpackutils.py | 380 +++--
requirements.txt   |   2 +-
setup.cfg  |   2 +-
test-requirements.txt  |   6 +-
9 files changed, 330 insertions(+), 131 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 06e2755..ff4e573 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -17 +17 @@ iso8601>=0.1.9
-oslo.utils>=1.2.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index af6a92e..ee6d133 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
@@ -12 +12 @@ oslosphinx>=2.2.0  # Apache-2.0
-oslotest>=1.2.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -14 +14 @@ simplejson>=2.2.0
-oslo.i18n>=1.3.0  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0



__
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-dev] [release] oslotest release 1.6.0 (liberty)

[Doug Hellmann]

We are stoked to announce the release of:

oslotest 1.6.0: Oslo test framework

For more details, please see the git log history below and:

http://launchpad.net/oslotest/+milestone/1.6.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslotest

Changes in oslotest 1.5.1..1.6.0


9116088 2015-04-16 18:09:08 + Uncap library requirements for liberty
1542d8c 2015-04-04 02:39:46 -0400 Cleanup README.rst and setup.cfg
2478170 2015-04-03 16:43:21 +0200 mockpatch: factorize code
d0d6528 2015-04-03 14:13:03 + Update to latest hacking
88ea8c1 2015-03-21 00:17:19 + Updated from global requirements
fd60b9c 2015-03-12 14:31:54 +0100 mockpatch: fix a potential race condition

Diffstat (except docs and test files)
-

README.rst|  3 ++-
oslotest/mockpatch.py | 47 +--
setup.cfg |  2 +-
test-requirements.txt |  4 ++--
4 files changed, 22 insertions(+), 34 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 5a845ba..d6f80b3 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -5 +5 @@
-hacking>=0.9.2,<0.10
+hacking>=0.10.0,<0.11
@@ -14 +14 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] oslo.db release 1.2.0 (liberty)

[Doug Hellmann]

We are amped to announce the release of:

oslo.db 1.2.0: oslo.db library

For more details, please see the git log history below and:

http://launchpad.net/oslo/+milestone/1.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo

Changes in oslo.db 1.1.0..1.2.0
---

f740e3b 2014-11-28 06:01:27 + Imported Translations from Transifex
ca1ad56 2014-11-21 17:05:34 +0200 Make test_models pass on py3
549ba15 2014-11-21 12:32:04 +0200 Repair include_object to accommodate new 
objects
10e8d15 2014-11-20 19:26:22 +0200 Add table name to foreign keys diff
ddd11df 2014-11-20 14:11:24 + Updated from global requirements
2269848 2014-11-19 19:46:04 +0200 Handle Galera deadlock on SELECT FOR UPDATE
4b2058b 2014-11-19 16:02:42 +0200 Add exception filter for 
_sqlite_dupe_key_error
b6d363d 2014-11-19 15:21:20 +0200 Add info on how to run unit tests
7f755bf 2014-11-18 16:05:01 +0200 Ensure is_backend_avail() doesn't leave open 
connections
c54d3a9 2014-11-18 11:36:12 + Updated from global requirements
2099177 2014-11-08 12:58:23 + Add pbr to installation requirements
135701b 2014-10-27 21:21:10 -0700 Fix python3.x scoping issues with removed 
'de' variable

Diffstat (except docs and test files)
-

CONTRIBUTING.rst   | 39 +++
.../locale/en_GB/LC_MESSAGES/oslo.db-log-info.po   |  8 ++--
oslo.db/locale/fr/LC_MESSAGES/oslo.db-log-error.po | 56 ++
oslo.db/locale/fr/LC_MESSAGES/oslo.db-log-info.po  | 33 +
.../locale/fr/LC_MESSAGES/oslo.db-log-warning.po   | 40 
oslo/db/sqlalchemy/exc_filters.py  | 21 ++--
oslo/db/sqlalchemy/session.py  | 10 ++--
oslo/db/sqlalchemy/test_migrations.py  |  2 +-
oslo/db/sqlalchemy/utils.py|  3 +-
requirements.txt   |  1 +
test-requirements-py2.txt  |  2 +-
test-requirements-py3.txt  |  2 +-
15 files changed, 233 insertions(+), 35 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index cc50660..f8a0d8c 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4,0 +5 @@
+pbr>=0.6,!=0.7,<1.0
diff --git a/test-requirements-py2.txt b/test-requirements-py2.txt
index 13cea90..ac5c18a 100644
--- a/test-requirements-py2.txt
+++ b/test-requirements-py2.txt
@@ -19 +19 @@ testscenarios>=0.4
-testtools>=0.9.36
+testtools>=0.9.36,!=1.2.0
diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt
index 4f195da..58b9a3d 100644
--- a/test-requirements-py3.txt
+++ b/test-requirements-py3.txt
@@ -18 +18 @@ testscenarios>=0.4
-testtools>=0.9.36
+testtools>=0.9.36,!=1.2.0



__
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-dev] [release] oslo.rootwrap release 1.7.0 (liberty)

[Doug Hellmann]

We are gleeful to announce the release of:

oslo.rootwrap 1.7.0: Oslo Rootwrap

For more details, please see the git log history below and:

http://launchpad.net/oslo.rootwrap/+milestone/1.7.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.rootwrap

Changes in oslo.rootwrap 1.6.0..1.7.0
-

a947967 2015-04-16 18:07:38 + Uncap library requirements for liberty
1782ef1 2015-04-06 09:59:00 -0400 Speed up non-daemon rootwrap command line 
invocation
ea65f25 2015-04-04 01:57:04 -0400 Correct RST syntax errors in README.rst
19b2562 2015-04-03 14:04:10 + Update to latest hacking
37b8d37 2015-03-31 23:06:06 +1100 Avoid calling sudo just to change users
fc41323 2015-03-21 00:17:07 + Updated from global requirements

Diffstat (except docs and test files)
-

README.rst |  4 ++--
oslo_rootwrap/cmd.py   |  5 -
oslo_rootwrap/filters.py   | 16 
oslo_rootwrap/wrapper.py   | 14 +++---
test-requirements-py3.txt  |  4 ++--
test-requirements.txt  |  8 
7 files changed, 45 insertions(+), 20 deletions(-)


Requirements updates


diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt
index f0c388c..48bbf97 100644
--- a/test-requirements-py3.txt
+++ b/test-requirements-py3.txt
@@ -5 +5 @@
-hacking>=0.9.2,<0.10
+hacking>=0.10.0,<0.11
@@ -26 +26 @@ mock>=1.0
-oslotest>=1.2.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 4b0b51a..c7ababb 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -5 +5 @@
-hacking>=0.9.2,<0.10
+hacking>=0.10.0,<0.11
@@ -16,2 +16,2 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.2.0  # Apache-2.0
-oslotest>=1.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -24 +24 @@ mock>=1.0
-eventlet>=0.16.1
+eventlet>=0.16.1,!=0.17.0



__
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-dev] [release] django_openstack_auth release 1.3.0 (liberty)

[Doug Hellmann]

We are content to announce the release of:

django_openstack_auth 1.3.0: Django authentication backend for use
with OpenStack Identity

For more details, please see the git log history below and:

https://launchpad.net/django-openstack-auth/+milestone/1.3.0

Please report issues through launchpad:

https://bugs.launchpad.net/django-openstack-auth

Changes in django_openstack_auth 1.2.0..1.3.0
-

3a8d34f 2015-04-21 14:51:17 + Update README to work with release tools
03446e8 2015-04-20 06:03:10 + Imported Translations from Transifex
8657c04 2015-04-19 06:02:29 + Imported Translations from Transifex
866471a 2015-04-17 06:03:00 + Imported Translations from Transifex
1786833 2015-04-16 17:50:31 + Uncap library requirements for liberty

Diffstat (except docs and test files)
-

README.rst|  9 +
openstack_auth/locale/ar/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/ca/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/cs/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/de/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/en_AU/LC_MESSAGES/django.po | 12 +++-
openstack_auth/locale/en_GB/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/es/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/es_MX/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/fi_FI/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/fr/LC_MESSAGES/django.po|  9 +
openstack_auth/locale/hi/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/it/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/ko_KR/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/ne/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/nl_NL/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pa_IN/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pl_PL/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pt/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/pt_BR/LC_MESSAGES/django.po | 18 ++
openstack_auth/locale/ru/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/sl_SI/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/sr/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/tr_TR/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/uk/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/zh_CN/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/zh_TW/LC_MESSAGES/django.po |  6 +++---
requirements.txt  |  2 +-
test-requirements.txt |  2 +-
29 files changed, 98 insertions(+), 92 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8116201..bdbd4b5 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ Django>=1.4.2,<1.8
-oslo.config>=1.9.3,<1.10.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index c8c6a3b..58cab54 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] oslo.middleware release 1.1.0 (liberty)

[Doug Hellmann]

We are overjoyed to announce the release of:

oslo.middleware 1.1.0: Oslo Middleware library

For more details, please see the git log history below and:

http://launchpad.net/oslo.middleware/+milestone/1.1.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.middleware

Changes in oslo.middleware 1.0.0..1.1.0
---

2abb286 2015-04-16 18:06:11 + Uncap library requirements for liberty
027dd34 2015-04-08 18:28:13 -0700 Add CORS Middleware for Oslo.
eff065e 2015-04-03 14:03:10 + Update to latest hacking
a8f4e82 2015-03-21 00:17:03 + Updated from global requirements

Diffstat (except docs and test files)
-

oslo_middleware/__init__.py|   2 +
oslo_middleware/cors.py| 240 +
oslo_middleware/opts.py|   7 +-
requirements.txt   |   6 +-
test-requirements.txt  |   6 +-
8 files changed, 1028 insertions(+), 7 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 95059c6..b488bbd 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ Babel>=1.3
-oslo.config>=1.9.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
@@ -9 +9 @@ oslo.context>=0.2.0 # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
@@ -11 +11 @@ six>=1.9.0
-stevedore>=1.1.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index c5c0328..52cc789 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -6 +6 @@ fixtures>=0.3.14
-hacking>=0.9.2,<0.10
+hacking>=0.10.0,<0.11
@@ -8,2 +8,2 @@ mock>=1.0
-oslosphinx>=2.2.0  # Apache-2.0
-oslotest>=1.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0



__
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-dev] [release] keystonemiddleware release 1.6.0 (liberty)

[Doug Hellmann]

We are overjoyed to announce the release of:

keystonemiddleware 1.6.0: Middleware for OpenStack Identity

For more details, please see the git log history below.


Changes in keystonemiddleware 1.5.0..1.6.0
--

04a6a9f 2015-04-16 17:53:57 + Uncap library requirements for liberty
452bf87 2015-04-16 16:32:37 +1000 Remove retry parameter
90edbc8 2015-04-14 15:01:39 + Fix s3_token middleware parsing insecure 
option
1150d04 2015-04-08 18:58:41 + Updated from global requirements
809967f 2015-04-08 02:42:23 + Pull echo service out of auth_token.
abcdbb3 2015-04-05 16:12:43 + Fix typos in keystonemiddleware
bafd958 2015-03-16 14:24:47 +1100 Rename requests mock object in testing
8e1bba1 2015-03-15 08:36:44 -0500 Update auth_token config docs
71fc24e 2015-03-14 18:45:56 +0800 Crosslink to other sites that are owned by 
Keystone
50c2baf 2015-03-13 08:59:15 -0500 Move _memcache_pool into auth_token
fec6f62 2015-03-11 17:03:54 -0500 Move unit tests into tests.unit

Diffstat (except docs and test files)
-

keystonemiddleware/_memcache_pool.py   |  184 --
keystonemiddleware/auth_token/__init__.py  |   86 +-
keystonemiddleware/auth_token/_cache.py|4 +-
keystonemiddleware/auth_token/_memcache_pool.py|  184 ++
keystonemiddleware/echo/__init__.py|0
keystonemiddleware/echo/__main__.py|7 +
keystonemiddleware/echo/service.py |   46 +
keystonemiddleware/s3_token.py |3 +-
.../unit/auth_token/test_auth_token_middleware.py  | 2760 +++
requirements.txt   |8 +-
test-requirements-py3.txt  |8 +-
test-requirements.txt  |8 +-
40 files changed, 5041 insertions(+), 4968 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b207833..0a4ff4b 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ iso8601>=0.1.9
-oslo.config>=1.9.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
@@ -9,3 +9,3 @@ oslo.context>=0.2.0 # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.serialization>=1.2.0   # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt
index ff9e614..9a33730 100644
--- a/test-requirements-py3.txt
+++ b/test-requirements-py3.txt
@@ -11,4 +11,4 @@ pycrypto>=2.6
-oslosphinx>=2.2.0  # Apache-2.0
-oslotest>=1.2.0  # Apache-2.0
-oslo.messaging>=1.6.0  # Apache-2.0
-requests-mock>=0.5.1  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
+oslo.messaging>=1.8.0  # Apache-2.0
+requests-mock>=0.6.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 55d21d5..e36b86e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12,4 +12,4 @@ pycrypto>=2.6
-oslosphinx>=2.2.0  # Apache-2.0
-oslotest>=1.2.0  # Apache-2.0
-oslo.messaging>=1.6.0  # Apache-2.0
-requests-mock>=0.5.1  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
+oslo.messaging>=1.8.0  # Apache-2.0
+requests-mock>=0.6.0  # Apache-2.0



__
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-dev] [release] oslo.log release 1.1.0 (liberty)

[Doug Hellmann]

We are chuffed to announce the release of:

oslo.log 1.1.0: oslo.log library

For more details, please see the git log history below and:

http://launchpad.net/oslo.log/+milestone/1.1.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.log

Changes in oslo.log 1.0.0..1.1.0


a45d56c 2015-04-16 18:04:22 + Uncap library requirements for liberty
33f051f 2015-03-25 20:40:47 + Add link to Logging Guidelines
8ad47ba 2015-03-25 19:24:20 + Expose opts entry point for version_utils
fd58202 2015-03-25 19:24:20 + Switch from oslo.config to oslo_config
2d46053 2015-03-25 19:24:20 + Remove oslo.log code and clean up 
versionutils API
0a512b9 2015-03-25 19:24:20 + Remove code that moved to oslo.i18n
f635dbd 2015-03-25 19:24:20 + Enhance versionutils.deprecated to work with 
classes
93db0ec 2015-03-25 19:24:20 + Add Kilo release name to versionutils
7f263be 2015-03-25 19:24:20 + Allow deprecated decorator to specify no plan 
for removal
14d1d9e 2015-03-25 19:24:20 + Add JUNO as a target to versionutils module
30e7c5b 2015-03-25 19:24:20 + pep8: fixed multiple violations
7bee814 2015-03-25 19:24:20 + Use oslotest instead of common test module
54d64a0 2015-03-25 19:24:20 + Use hacking import_exceptions for 
gettextutils._
0e829c0 2015-03-25 19:24:20 + fixed typos
e141593 2015-03-25 19:24:20 + Fix violations of H302:import only modules
3e3c7bb 2015-03-25 19:24:20 + Adds decorator to deprecate functions and 
methods
f6923e3 2015-03-25 19:24:20 + Remove vim header
ce726f1 2015-03-25 19:24:20 + Add `versionutils` for version compatibility 
checks
7f6db3a 2015-03-21 08:23:17 -0500 Default to True for use-syslog-rfc-format
68af49e 2015-03-21 00:16:58 + Updated from global requirements
c084b9d 2015-03-10 14:38:40 + Restore automatic unicode conversion
35e51bc 2015-03-10 13:56:27 + Add migration notes

Diffstat (except docs and test files)
-

openstack/common/versionutils.py | 260 +++
oslo_log/_options.py |   8 +-
oslo_log/log.py  |  17 +++
requirements.txt |   8 +-
test-requirements.txt|   4 +-
8 files changed, 730 insertions(+), 12 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 54ada9b..f38fc04 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ iso8601>=0.1.9
-oslo.config>=1.9.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
@@ -11,3 +11,3 @@ oslo.context>=0.2.0 # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
-oslo.serialization>=1.2.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 0fab2b3..b551d65 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13 +13 @@ testtools>=0.9.36,!=1.2.0
-oslotest>=1.2.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -22 +22 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] cliff release 1.11.0 (liberty)

[Doug Hellmann]

We are delighted to announce the release of:

cliff 1.11.0: Command Line Interface Formulation Framework

For more details, please see the git log history below and:

https://launchpad.net/python-cliff/+milestone/1.11.0

Please report issues through launchpad:

https://bugs.launchpad.net/python-cliff

Changes in cliff 1.10.1..1.11.0
---

3b138fe 2015-04-18 13:12:20 +0200 Catch and ignore error when locale can not be 
set
f558d9e 2015-04-16 17:47:46 + Uncap library requirements for liberty
40da955 2015-03-21 00:08:05 + Updated from global requirements
c7462f8 2015-03-10 16:35:58 +1100 Update links to setuptools doc.
91f5ad3 2015-03-06 12:28:04 -0600 Pass user command text to the Command object
299fbb7 2015-02-20 17:45:55 + Change the argument passed to __init__ for 
help

Diffstat (except docs and test files)
-

README.rst  |  2 +-
cliff/app.py| 11 +--
cliff/command.py|  3 ++-
cliff/display.py|  5 +++--
cliff/help.py   |  3 ++-
requirements.txt|  2 +-
test-requirements.txt   |  2 +-
9 files changed, 25 insertions(+), 10 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 754a591..0bc229b 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -10 +10 @@ six>=1.9.0
-stevedore>=1.1.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index ebb6880..af151ba 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9 +9 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] debtcollector release 0.4.0 (liberty)

[Doug Hellmann]

We are satisfied to announce the release of:

debtcollector 0.4.0: A collection of Python deprecation patterns and
strategies that help you collect your technical debt in a non-
destructive manner.

For more details, please see the git log history below and:

http://launchpad.net/debtcollector/+milestone/0.4.0

Please report issues through launchpad:

http://bugs.launchpad.net/debtcollector

Changes in debtcollector 0.3.0..0.4.0
-

62a75d7 2015-04-16 17:49:16 + Uncap library requirements for liberty
3afa864 2015-04-10 17:37:16 -0700 No longer need to workaround six issue/bug
3eddc93 2015-04-08 10:35:17 -0700 Add pypi download + version badges
cd3e5d8 2015-03-21 00:08:07 + Updated from global requirements

Diffstat (except docs and test files)
-

README.rst | 8 
debtcollector/moves.py | 8 +---
requirements.txt   | 2 +-
test-requirements.txt  | 4 ++--
5 files changed, 14 insertions(+), 11 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 6af7f18..827fc3b 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ six>=1.9.0
-oslo.utils>=1.2.0 # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 8592bde..031650a 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11,2 +11,2 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.2.0  # Apache-2.0
-oslotest>=1.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0



__
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-dev] [release] oslo.context release 0.3.0 (liberty)

[Doug Hellmann]

We are jubilant to announce the release of:

oslo.context 0.3.0: Oslo Context library

For more details, please see the git log history below and:

http://launchpad.net/oslo.context/+milestone/0.3.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.context

Changes in oslo.context 0.2.0..0.3.0


95c031d 2015-04-16 18:02:15 + Uncap library requirements for liberty
6ac5cc2 2015-04-04 02:02:41 -0400 Standardize setup.cfg summary for oslo libs
2d6b2d6 2015-04-03 13:57:40 + Update to latest hacking
abfc021 2015-03-26 11:00:56 + Updated from global requirements
7cc81aa 2015-03-05 14:50:48 -0500 fix bug tracker link

Diffstat (except docs and test files)
-

README.rst| 2 +-
setup.cfg | 2 +-
test-requirements.txt | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 7793b38..0d0e2e5 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -5,2 +5,2 @@
-hacking>=0.9.1,<0.10
-oslotest>=1.2.0  # Apache-2.0
+hacking>=0.10.0,<0.11
+oslotest>=1.5.1  # Apache-2.0
@@ -10 +10 @@ coverage>=3.6
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] oslo.i18n release 0.1.0 (liberty)

[Doug Hellmann]

We are thrilled to announce the release of:

oslo.i18n HEAD: oslo.i18n library

For more details, please see the git log history below and:

http://launchpad.net/oslo/+milestone/HEAD

Please report issues through launchpad:

http://bugs.launchpad.net/oslo

Changes in oslo.i18n 0.1.0..HEAD


166f4a5 2014-07-13 12:35:19 -0700 Document how to add import exceptions
a4fc251 2014-07-13 12:35:15 -0700 Remove mention of Message objects from public 
docs
d648097 2014-06-05 22:20:35 +0200 Setup for translation

Diffstat (except docs and test files)
-

oslo.i18n/locale/oslo.i18n.pot | 29 +
oslo/i18n/_gettextutils.py |  5 -
oslo/i18n/log.py   | 12 +---
4 files changed, 77 insertions(+), 8 deletions(-)



__
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-dev] [release] oslo.concurrency release 1.9.0 (liberty)

[Doug Hellmann]

We are tickled pink to announce the release of:

oslo.concurrency 1.9.0: Oslo Concurrency library

For more details, please see the git log history below and:

http://launchpad.net/oslo.concurrency/+milestone/1.9.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.concurrency

Changes in oslo.concurrency 1.8.0..1.9.0


4d7dce2 2015-04-19 01:17:43 +0200 Add binary parameter to execute and 
ssh_execute
c05c8c3 2015-04-18 00:11:28 +0200 Port processutils to Python 3
f366bd2 2015-04-16 17:45:40 + Uncap library requirements for liberty
e3c2419 2015-04-10 17:45:03 +0200 Move fixtures to test-requirements.txt
fa415de 2015-04-11 00:56:02 +1000 Fix test_as_root* tests to work when run as 
root
d04cf66 2015-04-07 21:09:17 + Add pypi download + version badges
fe84d2a 2015-04-04 02:01:33 -0400 Standardize setup.cfg summary for oslo libs
e6f5e19 2015-03-24 06:04:39 + Imported Translations from Transifex
9f949fd 2015-03-21 00:16:47 + Updated from global requirements
a0549bf 2015-03-20 16:03:21 -0400 Remove tools/run_cross_tests.sh from 
openstack-common.conf

Diffstat (except docs and test files)
-

README.rst |  10 +-
openstack-common.conf  |   1 -
.../LC_MESSAGES/oslo.concurrency-log-error.po  |  32 
.../locale/en_GB/LC_MESSAGES/oslo.concurrency.po   |  56 ---
oslo_concurrency/processutils.py   |  52 +-
requirements.txt   |   7 +-
setup.cfg  |   2 +-
test-requirements.txt  |   7 +-
12 files changed, 317 insertions(+), 72 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 1fcebea..cf4758d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8,4 +8,3 @@ iso8601>=0.1.9
-fixtures>=0.3.14
-oslo.config>=1.9.0  # Apache-2.0
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.utils>=1.2.0   # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index e715139..0fb38b7 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -6 +6 @@ hacking>=0.10.0,<0.11
-oslotest>=1.2.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -8,0 +9 @@ futures>=2.1.6
+fixtures>=0.3.14
@@ -11 +12 @@ futures>=2.1.6
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
@@ -14 +15 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-eventlet>=0.16.1
+eventlet>=0.16.1,!=0.17.0



__
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-dev] [release] oslo.config release 1.11.0 (liberty)

[Doug Hellmann]

We are psyched to announce the release of:

oslo.config 1.11.0: Oslo Configuration API

For more details, please see the git log history below and:

http://launchpad.net/oslo.config/+milestone/1.11.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.config

Changes in oslo.config 1.10.0..1.11.0
-

2e32e58 2015-04-16 17:56:05 + Uncap library requirements for liberty

Diffstat (except docs and test files)
-

requirements.txt  | 2 +-
test-requirements.txt | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index f560a0e..3e21533 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ six>=1.9.0
-stevedore>=1.3.0,<1.4.0  # Apache-2.0
+stevedore>=1.3.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index a23ab6e..27f6050 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13 +13 @@ testtools>=0.9.36,!=1.2.0
-oslotest>=1.5.1,<1.6.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
@@ -22 +22 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0
@@ -25 +25 @@ oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
-oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0



__
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-dev] [Nova] Reviewers please watch the check-tempest-dsvm-cells job now

[Andrew Laski]

It's been a long road but due to the hard work of bauzas and melwitt the 
cells Tempest check job should now be green for changes that don't break 
cells.  The job has been red for a long time so it's likely that people 
don't think about it much.  I would ask that until we can get the 
confidence to make it voting please take notice when it's red and 
investigate or bring it to the attention of one of us in #openstack-nova.


__
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] [Zaqar] Call for adoption (or exclusion?)

[Tim Bell]

This touches on many of the aspects of the Ops tagging to be discussed in
Vancouver.

What are the criteria for

- An operator to consider a PoC for a new function ? We look for RDO
packaging, Puppet configuration and ops/end user documentation.
- An operator offering function to their end users in test (I.e. This
works well enough to see if there is an end user benefit to justify the
operations cost) ?
- An operator to offer this in production (I.e. The operator deploys the
code and makes it available to the end users) ? This implies scaling,
upgradability, etc. and commits to a sustainable roadmap (with the
community)

I really appreciate the reflections going on here since the worst case
scenario for us is that the end users of the cloud become dependent on a
component and finding that the community is not self sustaining.

Tagging allows the operator to make an informed decision given their user
community and assess the risk vs benefit.

Tim


On 4/21/15, 2:51 PM, "Ryan Brown"  wrote:

>On 04/20/2015 07:12 PM, Steve Baker wrote:
>> On 21/04/15 11:01, Angus Salkeld wrote:
>>>
>>>
>>> On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M >> > wrote:
>>>
>>> As an Op, a few things that come to mind in that category are:
>>>  * RDO packaging (stated earlier). If its not easy to install, its
>>> not going to be deployed as much. I haven't installed it yet,
>>> because I haven't had time to do much other then yum install it...
>>>  * Horizon UI
>>>  * Heat Resources. (Some basic stuff like create/delete queue to
>>> go along with the stack. also link #1 below)
>>>
>>>
>>> Here you go:
>>> https://github.com/openstack/heat/tree/master/contrib/heat_zaqar
>> One thing we need to do in Vancouver is come up with criteria for moving
>> resources from contrib into the main tree. Previously this was whether
>> the project was integrated. As a starter I would suggest something like:
>> 1. project is in the openstack git namespace
>> 2. the client library is synced with global-requirements.txt
>> 3. the resources are complete enough to be useful in template authoring
>> We need to think about potential for integration testing in the gate
>>too.
>
>I think scenario/functional tests should be table stakes to graduate a
>resource from contrib/ .
>
>>>  
>>>
>>> Horizon has a discovery aspect to it. If users don't know a
>>> service is available, its hard for them to use it. Even with the
>>> most simple UI of Create/Delete/List queues, discovery is handled.
>
>Absolutely agreed. Especially in a service like Zaqar where the vast
>majority of usage isn't by humans in a web interface, the horizon bit
>becomes mostly a dashboard/auditing/testing destination instead of a
>primary interface.
>
>>> [snip]
>
>-- 
>Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
>
>__
>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] Fwd: Integration Gerrit with Launchpad

[Dimitri John Ledkov]

Heya,

On 20 April 2015 at 00:26, Kaneko Takehiro  wrote:
> Hi,
>
> I'm managing a stackforge project and want to integrate Gerrit with
> Launchpad.
>
> Links;
>   Git: https://git.openstack.org/cgit/stackforge/rack/
>   Launchpad: https://launchpad.net/python-rack
>
> Project name 'rack' is duplicated in Launchpad so I named our project
> 'python-rack'.
> How can I integrate Gerrit with Launchpad in this case?

If rack is more popular and existing lp "rack" project is dead/dormant
(and it looks like it is dormant). One can file a question on
launchpad asking to rename and take over the project name, if you wish
to have "rack" name on launchpad.

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

__
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] [neutron][lbaas] adding lbaas core

[Tom Creighton]

Congratulations Phil!



> On Apr 21, 2015, at 11:54 AM, Doug Wiegley  
> wrote:
> 
> It’s been a week, welcome Phil.
> 
> Thanks,
> doug
> 
> 
>> On Apr 13, 2015, at 2:39 PM, Doug Wiegley  
>> wrote:
>> 
>> Hi all,
>> 
>> I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a 
>> bunch of work on the ref impl for lbaasv2, and and I'll let the numbers[1] 
>> speak for themselves.
>> 
>> Existing lbaas cores, please vote.  All three of us.  :-)
>> 
>> [1] http://stackalytics.com/report/contribution/neutron-lbaas/30
>> 
>> Thanks,
>> doug
>> 
>> 
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [nova][python-novaclient] microversion implementation on client side

[Chris Friesen]

On 04/21/2015 11:35 AM, Hayes, Graham wrote:

From: Jay Pipes [jaypi...@gmail.com]
The existing --os-compute-api-version CLI option should be made to take:

   * 2
   * \d+.\d+
   * "latest"

And nothing else.



Yes - please don't add a flag to the cli (or the python bindings for
that matter)


Isn't a cli flag exactly what Jay was describing?


Speaking as someone who spends a lot of time interaction with different
clouds, based on different versions of OpenStack and develops on top of
tip of master clouds - the thought of trying to remember what micro
versions are enabled on the cloud I am currently testing / working on is
terrifying.


This should be done via discovery. If a call requires a micro-version
that is not deployed - return an error.


I haven't had the pleasure(?) of needing to do this, but wouldn't you need to 
know what API versions are available before you try to do some task?  (In order 
to know what actions are available, or what parameters to expect to be returned.)


As I understand it, Jay's proposal is that if you don't specify a version you 
get the default (currently version 2, I think), if you do specify a version you 
get that version, and if you specify "latest" then you get the most recent 
version that the server knows about.


Chris

__
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-dev] [release] bad release note emails

[Doug Hellmann]

Some of the repos I was trying to generate release notes from,
especially the python-fooclient repos, don't have the data in the
README.rst files needed for the script to work. As a result, some of the
emails are blank.

I'm working on fixing that, sorry for the noise.

Doug


__
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] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

[Anita Kuno]

On 04/20/2015 04:39 PM, Sukhdev Kapur wrote:
> Hi Ramy,
> 
> While I agree, in principal, with this line of thinking and goal, my
> concern will be how much extra work is it going to create for existing CI
> owners?
> Our Ci system has been stable for a long time, and we put in a good amount
> of effort to get it to that point. Our CI is not based upon zuul framework.
> Zuul was still under discussion at the time when we put together our CI. We
> use Jenkins as front end, along with Gerrit triggers, and AWS for
> posting/preserving results/log.  We have dedicated back-end servers for
>  testing.
> 
> My paranoia at this point will be to learn a new framework, risk breaking
> things and taking a huge effort to get things stabilized - without much
> additional ROI.
> Am I overreacting here or does my argument makes sense?
> 
> I wonder how many folks will be in that camp?
> 
> Sukhdev
Hi Sukhdev:

What is being offered is an opportunity to pool efforts for those who
wish to participate. There is no pressure to participate if you are
concerned that you would compromise the integrity of a stable system.
You and others that have put in so much work are to be lauded for your
commitment to your goal, thank you. Ramy's efforts in no way are an
attempt to degrade the stability you have created.

Part of the exhaustion level folks feel in this space, at all points in
the spectrum, is the cost of maintenance. In infra we are constantly
dealing with problems from operators and it would reduce the burden on
us, as well as reduce the tension on operators, if we had a solution
that was easier to maintain. The more people running the same structure,
the easier any one issue is to solve (hopefully).

The goal is once the structure is in place that OpenStack's Infra would
also consume it, enabling common bugs to be discovered and fixed upstream.

Noone is forced to participate nor are they going to be forced to
operate this structure. This is simply a chance to work together on a
direction which infra would very much like to see in place.

Thanks Sukhdev,
Anita.
> 
> 
> 
> 
> On Sun, Apr 19, 2015 at 10:17 PM, Asselin, Ramy  wrote:
> 
>>  All Third-Party CI operators:
>>
>>
>>
>> We’ve got 85 Third Party CI systems registered in the wiki[1], all of them
>> running a variety of closed & open-source solutions.
>>
>> Instead of individually maintaining all those similar solutions, let’s
>> join together and collectively maintain a single solution.
>>
>>
>>
>> If that sounds good to you, there’s an Infra-spec that’s been approved [2]
>> to refactor much of what the Infrastructure team uses for the upstream
>> “Jenkins” CI to be more easily reusable by many of us.
>>
>>
>>
>> We’ve got stories defined [3], and a few patches submitted. We’re using
>> the gerrit-topic “downstream-puppet” [4].
>>
>>
>>
>> For example, we’ve got the first part under review for the “Log Server”,
>> which creates your own version of http://logs.openstack.org/
>>
>>
>>
>> If anyone is interested in migrating towards a common solution, reply, or
>> ping me IRC (asselin) on Freenode #openstack-infra, or join some of the
>> third party ci meetings [5].
>>
>>
>>
>> Thanks!
>>
>> Ramy
>>
>>
>>
>> [1] https://wiki.openstack.org/wiki/ThirdPartySystems
>>
>> [2]
>> http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html
>>
>> [3] https://storyboard.openstack.org/#!/story/2000101
>>
>> [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z
>>
>> [5]
>> https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings
>>
>>
>>
>>
>>
>> __
>> 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
> 


__
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-dev] [release] keystonemiddleware release 1.6.0 (liberty)

[Doug Hellmann]

__
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-dev] [release] python-barbicanclient release 3.0.1 (liberty)

[Doug Hellmann]

__
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] Liberty Design Summit - Proposed room / time layout

[Ben Swartzlander]

On 04/17/2015 05:00 AM, Thierry Carrez wrote:

Hi PTLs,

Following the slot allocation last week, here is the proposed room layout:

https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit?usp=sharing

It takes into account the following changes:
- Barbican donates on fishbowl room to Security
- Magnum takes one of the available Friday-afternoon sprints

You'll notice that we still have 3 unallocated Friday afternoon sprints,
as well as an unallocated fishbowl room. Ceilometer expressed interest
in having the latter (which would require some shuffling around since
they have a work session at that time). At this point I prefer to keep
it for late adjustments.

If you see major problems with the proposed layout let me know. I may
have missed a blatant issue. It's a bit difficult to find a combination
that works for everyone, especially when you add conference talk
conflicts in the mix, but I'll do my best to accommodate reported issues.


My main request was that the Manila sessions didn't overlap with the 
Cinder sessions, since there are some key people who are involved in 
both projects. It looks like some attempt was made to avoid overlaps 
(the fishbowl sessions at least), but the working sessions could be 
adjusted to overlap less (space permitting). I would prefer that some of 
the Wednesday Manila working sessions were moved to the end of Thursday 
(after the Cinder ones).


-Ben Swartzlander


Barring major issues we'll push this to the Design Summit sched and let
PTLs update the content there as they refine content.

Regards,




__
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-dev] [release] project) release 1.3.0 (liberty)

[Doug Hellmann]

We are glad to announce the release of:

django_openstack_auth 1.3.0: Django authentication backend for use
with OpenStack Identity

For more details, please see the git log history below and:

https://launchpad.net/django-openstack-auth/+milestone/1.3.0

Please report issues through launchpad:

https://bugs.launchpad.net/django-openstack-auth

Changes in django_openstack_auth 1.2.0..1.3.0
-

3a8d34f 2015-04-21 14:51:17 + Update README to work with release tools
03446e8 2015-04-20 06:03:10 + Imported Translations from Transifex
8657c04 2015-04-19 06:02:29 + Imported Translations from Transifex
866471a 2015-04-17 06:03:00 + Imported Translations from Transifex
1786833 2015-04-16 17:50:31 + Uncap library requirements for liberty

Diffstat (except docs and test files)
-

README.rst|  9 +
openstack_auth/locale/ar/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/ca/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/cs/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/de/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/en_AU/LC_MESSAGES/django.po | 12 +++-
openstack_auth/locale/en_GB/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/es/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/es_MX/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/fi_FI/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/fr/LC_MESSAGES/django.po|  9 +
openstack_auth/locale/hi/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/it/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/ko_KR/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/ne/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/nl_NL/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pa_IN/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pl_PL/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pt/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/pt_BR/LC_MESSAGES/django.po | 18 ++
openstack_auth/locale/ru/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/sl_SI/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/sr/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/tr_TR/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/uk/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/zh_CN/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/zh_TW/LC_MESSAGES/django.po |  6 +++---
requirements.txt  |  2 +-
test-requirements.txt |  2 +-
29 files changed, 98 insertions(+), 92 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8116201..bdbd4b5 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ Django>=1.4.2,<1.8
-oslo.config>=1.9.3,<1.10.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index c8c6a3b..58cab54 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] pycadf release 0.6.0 (liberty)

[Doug Hellmann]

__
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-dev] [release] (no release 1.3.0 (liberty)

[Doug Hellmann]

We are stoked to announce the release of:

django_openstack_auth 1.3.0: Django authentication backend for use
with OpenStack Identity

For more details, please see the git log history below and:

https://launchpad.net/django-openstack-auth/+milestone/1.3.0

Please report issues through launchpad:

https://bugs.launchpad.net/django-openstack-auth

Changes in django_openstack_auth 1.2.0..1.3.0
-

3a8d34f 2015-04-21 14:51:17 + Update README to work with release tools
03446e8 2015-04-20 06:03:10 + Imported Translations from Transifex
8657c04 2015-04-19 06:02:29 + Imported Translations from Transifex
866471a 2015-04-17 06:03:00 + Imported Translations from Transifex
1786833 2015-04-16 17:50:31 + Uncap library requirements for liberty

Diffstat (except docs and test files)
-

README.rst|  9 +
openstack_auth/locale/ar/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/ca/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/cs/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/de/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/en_AU/LC_MESSAGES/django.po | 12 +++-
openstack_auth/locale/en_GB/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/es/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/es_MX/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/fi_FI/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/fr/LC_MESSAGES/django.po|  9 +
openstack_auth/locale/hi/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/it/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/ko_KR/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/ne/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/nl_NL/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pa_IN/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pl_PL/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pt/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/pt_BR/LC_MESSAGES/django.po | 18 ++
openstack_auth/locale/ru/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/sl_SI/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/sr/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/tr_TR/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/uk/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/zh_CN/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/zh_TW/LC_MESSAGES/django.po |  6 +++---
requirements.txt  |  2 +-
test-requirements.txt |  2 +-
29 files changed, 98 insertions(+), 92 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8116201..bdbd4b5 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ Django>=1.4.2,<1.8
-oslo.config>=1.9.3,<1.10.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index c8c6a3b..58cab54 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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-dev] [release] taskflow release 0.6.0 (liberty)

[Doug Hellmann]

We are satisfied to announce the release of:

taskflow 0.6.0: Taskflow structured state management library.

For more details, please see the git log history below and:

http://launchpad.net/taskflow/+milestone/0.6.0

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

Changes in taskflow 0.5.0..0.6.0


4e514f4 2014-12-18 13:55:41 -0800 Move over to using oslo.utils [reflection, 
uuidutils]
e5ae74d 2014-12-18 01:28:41 + Updated from global requirements
6520b9c 2014-12-17 19:13:45 + Add a basic map/reduce example to show how 
this can be done
cafa3b2 2014-12-17 19:13:35 + Add a parallel table mutation example
1b06183 2014-12-15 19:19:18 -0800 Add a 'can_be_registered' method that checks 
before notifying
97b4e18 2014-12-15 15:52:39 -0800 Base task executor should provide 
'wait_for_any'
e9ecdc7 2014-12-14 21:46:51 -0800 Replace autobind with a notifier module 
helper function
aa8d55d 2014-12-15 03:38:52 + Cleanup some doc warnings/bad/broken links
1f4dd72 2014-12-13 19:09:03 -0800 Use the notifier type in the task 
class/module directly
cdfd8ec 2014-12-13 17:13:07 -0800 Use a tiny clamp helper to clamp the 
'on_progress' value
624d966 2014-12-12 22:12:03 -0800 Retain the existence of a 'EngineBase' until 
0.7 or later
f5060ff 2014-12-12 22:05:03 -0800 Remove the base postfix from the internal 
task executor
b4e4e21 2014-12-12 20:52:58 + Remove usage of listener base postfix
a440ec4 2014-12-12 12:39:57 -0800 Add a moved_inheritable_class deprecation 
helper
1c7d242 2014-12-11 13:15:19 -0800 Avoid holding the lock while scanning for 
existing jobs
79ff9e7 2014-12-10 23:25:08 -0800 Remove the base postfix for engine abstract 
base class
880f7d2 2014-12-10 23:21:31 -0800 Avoid popping while another entity is 
iterating
a908124 2014-12-11 07:20:45 + Updated from global requirements
fda6fde 2014-12-11 04:10:16 + Use explict 'attr_dict' when adding 
provider->consumer edge
eaf4995 2014-12-10 20:05:44 -0800 Properly handle and skip empty intermediary 
flows
f1457a0 2014-12-10 18:58:42 -0800 Ensure message gets processed correctly
b275c51 2014-12-09 15:52:14 -0800 Just assign a empty collection instead of 
copy/clear
f333e1b 2014-12-09 00:15:34 -0800 Remove rtype from task clone() doc
14431bc 2014-12-08 22:09:13 -0800 Add and use a new simple helper logging module
a113368 2014-12-08 16:51:27 -0800 Have the sphinx copyright date be dynamic
2f78ecf 2014-12-08 14:27:53 -0800 Add appropriate links into README.rst
4eb0ca2 2014-12-08 01:21:15 + Use condition variables using 'with'
50b866c 2014-12-07 18:52:54 + Use an appropriate ``extract_traceback`` limit
c4d3279 2014-12-07 09:42:17 -0800 Allow all deprecation helpers to take a 
stacklevel
cd664bd 2014-12-07 00:25:01 -0800 Correctly identify stack level in 
``_extract_engine``
5f0b514 2014-12-06 15:03:58 -0800 Stop returning atoms from execute/revert 
methods
dc4262e 2014-12-06 14:46:09 -0800 Have tasks be able to provide copy() methods
e978eca 2014-12-06 22:30:14 + Allow stopwatches to be restarted
af62f4c 2014-12-06 22:30:10 + Ensure that failures can be pickled
e168f44 2014-12-06 14:29:24 -0800 Rework pieces of the task callback capability
dc39351 2014-12-05 21:12:03 -0800 Just use 4 spaces for classifier indents
4707ac7 2014-12-05 00:13:15 -0800 Move atom action handlers to there own 
subfolder/submodule
2033d01 2014-12-05 03:30:41 + Workflow documentation is now in infra-manual
2f03736 2014-12-05 01:53:47 + Ensure frozen attribute is set in fsm 
clones/copies
8150553 2014-12-04 16:59:54 -0800 Fix split on "+" for connection strings that 
specify dialects
b8e975e 2014-12-04 19:04:14 + Update listeners to ensure they correctly 
handle all atoms
cf45a70 2014-12-04 11:03:36 -0800 Allow for the notifier to provide a 
'details_filter'
c698842 2014-12-04 08:05:09 + Be explicit about publish keyword arguments
6a6aa79 2014-12-03 16:15:05 -0800 Some package additions and adjustments to the 
env_builder.sh
a692138 2014-12-02 16:02:24 -0800 Cache immutable visible scopes in the runtime 
component
14ecaa4 2014-12-02 12:47:03 -0800 Raise value errors instead of asserts
1de8bbd 2014-12-01 21:39:23 -0800 Add a claims listener that connects job 
claims to engines
1e8fabd 2014-12-01 19:26:20 -0800 Split the scheduler into sub-schedulers
35fcd90 2014-12-01 18:15:02 -0800 Use a module level constant to provide the 
DEFAULT_LISTEN_FOR
178f279 2014-12-02 01:57:37 + Move the _pformat() method to be a classmethod
9675964 2014-11-28 15:10:31 -0800 Add link to issue 17911
e07fb21 2014-11-28 15:07:20 -0800 Avoid deepcopying exception values
95e94f7 2014-11-28 13:07:38 -0800 Include documentation of the utility modules
265181f 2014-11-27 20:07:21 -0800 Use a metaclass to dynamically add testcases 
to example runner
cf85dd0 2014-11-25 09:57:16 -0800 Remove default setting of 
'mysql_traditional_mode'
bb8ea56 2014-11-24 18:13:56 -0800 Move scheduler and completer cla

[openstack-dev] [release] lp release 1.3.0 (liberty)

[Doug Hellmann]

We are glad to announce the release of:

django_openstack_auth 1.3.0: Django authentication backend for use
with OpenStack Identity

For more details, please see the git log history below and:

https://launchpad.net/django-openstack-auth/+milestone/1.3.0

Please report issues through launchpad:

https://bugs.launchpad.net/django-openstack-auth

Changes in django_openstack_auth 1.2.0..1.3.0
-

3a8d34f 2015-04-21 14:51:17 + Update README to work with release tools
03446e8 2015-04-20 06:03:10 + Imported Translations from Transifex
8657c04 2015-04-19 06:02:29 + Imported Translations from Transifex
866471a 2015-04-17 06:03:00 + Imported Translations from Transifex
1786833 2015-04-16 17:50:31 + Uncap library requirements for liberty

Diffstat (except docs and test files)
-

README.rst|  9 +
openstack_auth/locale/ar/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/ca/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/cs/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/de/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/en_AU/LC_MESSAGES/django.po | 12 +++-
openstack_auth/locale/en_GB/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/es/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/es_MX/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/fi_FI/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/fr/LC_MESSAGES/django.po|  9 +
openstack_auth/locale/hi/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/it/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/ko_KR/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/ne/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/nl_NL/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pa_IN/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pl_PL/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/pt/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/pt_BR/LC_MESSAGES/django.po | 18 ++
openstack_auth/locale/ru/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/sl_SI/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/sr/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/tr_TR/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/uk/LC_MESSAGES/django.po|  6 +++---
openstack_auth/locale/zh_CN/LC_MESSAGES/django.po |  6 +++---
openstack_auth/locale/zh_TW/LC_MESSAGES/django.po |  6 +++---
requirements.txt  |  2 +-
test-requirements.txt |  2 +-
29 files changed, 98 insertions(+), 92 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8116201..bdbd4b5 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ Django>=1.4.2,<1.8
-oslo.config>=1.9.3,<1.10.0  # Apache-2.0
+oslo.config>=1.9.3  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index c8c6a3b..58cab54 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0  # Apache-2.0
+oslosphinx>=2.5.0  # Apache-2.0



__
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