[openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

Shreeya Sharma shreeya93sharma at gmail.com
Thu Jul 14 09:48:32 UTC 2016


shreeya

On Thu, Jul 14, 2016 at 1:17 AM, <openstack-dev-request at lists.openstack.org>
wrote:

> Send OpenStack-dev mailing list submissions to
>         openstack-dev at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> or, via email, send a message with subject or body 'help' to
>         openstack-dev-request at lists.openstack.org
>
> You can reach the person managing the list at
>         openstack-dev-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: [TripleO] Making TripleO CI easier to consume outside of
>       TripleO CI (Wesley Hayutin)
>    2. Re: [mistral] [murano] [yaql] yaqluator bug (Alexey Khivin)
>    3. Re: [TripleO] Making TripleO CI easier to consume outside of
>       TripleO CI (Michal Pryc)
>    4. Re: [kolla] New specs process - a dicussion (Steven Dake (stdake))
>    5. Re: [TripleO] Making TripleO CI easier to consume outside of
>       TripleO CI (Wesley Hayutin)
>    6. [Neutron][DVR] - No IRC Meeting today (Brian Haley)
>    7. [storlets] IRC meeting times (eran at itsonlyme.name)
>    8. Re: [cinder] [nova] os-brick privsep failures and an upgrade
>       strategy? (Ivan Kolodyazhny)
>    9. [new][oslo] debtcollector 1.6.0 release (newton)
>       (no-reply at openstack.org)
>   10. [new][oslo] mox3 0.17.0 release (newton) (no-reply at openstack.org)
>   11. [new][oslo] futurist 0.15.0 release (newton)
>       (no-reply at openstack.org)
>   12. [new][oslo] oslo.cache 1.11.0 release (newton)
>       (no-reply at openstack.org)
>   13. [new][oslo] automaton 1.3.0 release (newton)
>       (no-reply at openstack.org)
>   14. [new][oslo] oslo.config 3.13.0 release (newton)
>       (no-reply at openstack.org)
>   15. [new][oslo] oslo.context 2.6.0 release (newton)
>       (no-reply at openstack.org)
>   16. [new][oslo] oslo.concurrency 3.12.0 release (newton)
>       (no-reply at openstack.org)
>   17. [new][oslo] oslo.i18n 3.8.0 release (newton)
>       (no-reply at openstack.org)
>   18. [new][oslo] oslo.middleware 3.15.0 release (newton)
>       (no-reply at openstack.org)
>   19. [new][oslo] oslo.log 3.12.0 release (newton)
>       (no-reply at openstack.org)
>   20. [new][oslo] oslo.db 4.8.0 release (newton)
>       (no-reply at openstack.org)
>   21. Re: The future of OpenStack documentation (Markus Zoeller)
>   22. [new][oslo] oslo.reports 1.12.0 release (newton)
>       (no-reply at openstack.org)
>   23. [new][oslo] oslo.privsep 1.10.0 release (newton)
>       (no-reply at openstack.org)
>   24. [new][oslo] oslo.policy 1.12.0 release (newton)
>       (no-reply at openstack.org)
>   25. [new][oslo] oslo.serialization 2.11.0 release     (newton)
>       (no-reply at openstack.org)
>   26. [new][oslo] oslo.versionedobjects 1.13.0 release  (newton)
>       (no-reply at openstack.org)
>   27. [new][oslo] oslo.rootwrap 4.4.0 release (newton)
>       (no-reply at openstack.org)
>   28. [new][oslo] oslo.service 1.13.0 release (newton)
>       (no-reply at openstack.org)
>   29. [new][oslo] oslotest 2.7.0 release (newton)
>       (no-reply at openstack.org)
>   30. [new][oslo] taskflow 2.3.0 release (newton)
>       (no-reply at openstack.org)
>   31. [new][oslo] oslosphinx 4.6.0 release (newton)
>       (no-reply at openstack.org)
>   32. [new][oslo] oslo.vmware 2.11.0 release (newton)
>       (no-reply at openstack.org)
>   33. [new][oslo] stevedore 1.16.0 release (newton)
>       (no-reply at openstack.org)
>   34. [new][oslo] tooz 1.41.0 release (newton) (no-reply at openstack.org)
>   35. [release][ptl][all] newton-2 milestone deadline 14        July
>       (Doug Hellmann)
>   36. Re: [new][oslo] mox3 0.17.0 release (newton) (Markus Zoeller)
>   37. Re: The future of OpenStack documentation (Matt Kassawara)
>   38. Re: [TripleO] Making TripleO CI easier to consume outside of
>       TripleO CI (David Moreau Simard)
>   39. Re: [TripleO] Making TripleO CI easier to consume outside of
>       TripleO CI (Ricardo Carrillo Cruz)
>   40. Re: The future of OpenStack documentation (Doug Hellmann)
>   41. Re: [nova] focused review pipeline of bug fix changes?
>       (Jeremy Stanley)
>   42. Re: [nova] focused review pipeline of bug fix changes?
>       (Jeremy Stanley)
>   43. Re: [all][oslo] pbr potential breaking change coming
>       (Jeremy Stanley)
>   44. Re: [new][oslo] mox3 0.17.0 release (newton) (Jeremy Stanley)
>   45. [app-catalog] App Catalog IRC meeting Thursday July       14th
>       (Christopher Aedo)
>   46. Re: [openstack-ansible] Nominating Jean-Philippe Evrard for
>       core in openstack-ansible and all openstack-ansible-* roles
>       (Jesse Pretorius)
>   47. Re: [openstack-ansible] Nominating Jean-Philippe Evrard for
>       core in openstack-ansible and all openstack-ansible-* roles
>       (Steve Lewis)
>   48. Re: [openstack-ansible] Nominating Jean-Philippe Evrard for
>       core in openstack-ansible and all openstack-ansible-* roles
>       (Carter, Kevin)
>   49. [designate] Designate News Round Up (Hayes, Graham)
>   50. Re: [openstack-ansible] Nominating Jean-Philippe Evrard for
>       core in openstack-ansible and all openstack-ansible-* roles
>       (Jimmy McCrory)
>   51. Re: [all] Status of the OpenStack port to Python 3 (Denis Makogon)
>   52. [Cinder][CI] Rule of recheck keywords has been    updated
>       (Watanabe, Isao)
>   53. [nova] Let's kill quota classes (again) (Matt Riedemann)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Jul 2016 08:13:41 -0400
> From: Wesley Hayutin <whayutin at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Making TripleO CI easier to
>         consume outside of TripleO CI
> Message-ID:
>         <
> CAOHJT4JYNxMjnvYOYSDTWMNAJTHhXt3PTP23UhjbDjX9MdQjOw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Jul 12, 2016 at 3:39 PM, John Trowbridge <trown at redhat.com> wrote:
>
> > Howdy folks,
> >
> > In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
> > is being used as a CI tool in RDO. This came about organically, because
> > we needed to use RDO CI to self-gate quickstart (it relies on having a
> > baremetal virthost). It displaced another ansible based CI tool there
> > (khaleesi) and most(all?) of the extra functionality from that tool
> > (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
> > roles that are able to plugin to quickstart.[1]
> >
> > We are still left with two different tool sets, where one should suffice
> > (and focus CI efforts in one place).
> >
> > I see two different ways to resolve this.
> >
> > 1. Actively work on making the tripleo-ci scripts consumable external to
> > tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
> > upstream CI for packstack and puppet, so it is not totally far-fetched
> > to add support for TripleO jobs.
> >
>
> I think we have to at least point out that RDO is not the only other target
> for a CI tool.
> There are a few more groups that would benefit from the leadership of the
> upstream CI system.  Without
> calling out specific groups, I'm thinking of the various OpenStack network
> teams, performance teams,
> test teams, etc.. that rely on setting up TripleO as the base for their
> work. To make things a bit more complicated
> there is not a single source of requirements for the various groups that
> would benefit from a robust,
> flexible upstream TripleO CI tool set.  I'm not convinced that the current
> bash scripts can be
> reworked or wrapped in a way that can be flexible enough to handle what is
> an essentially
> unknown set of requirements.
>
> IMHO we require a tool set that is pluggable, composable and flexible
> enough such that
> other development, and CI teams that rely on TripleO as the base for their
> work feel comfortable extending
> and replacing parts of the CI tool set to fit their needs.
>
>
>
> >
> > Pros:
> > - All CI development just happens directly in tripleo-ci and RDO just
> > inherits that work.
> >
> > Cons:
> > - This is totally untried, and therefore a totally unknown amount of
> work.
> > - It is all or nothing in that there is no incremental path to get the
> > CI scripts working outside of CI.
> > - We have to rewrite a bunch of working ansible code in bash which IMO
> > is the wrong direction for a modern CI system.
> >
> >
> > 2. Actively work on making tripleo-ci consume the ansible work in
> > tripleo-quickstart and the external role ecosystem around it.
> >
> > Pros:
> > - This could be done incrementally, replacing a single function from
> > tripleo.sh with an invocation of tripleo-quickstart that performs that
> > function instead.
> > - We would be able to pull in a lot of extra functionality via these
> > external roles for free(ish).
> >
> > Cons:
> > - Similarly unknown amount of work to completely switch.
> > - CI development would be done in multiple repos, though each would have
> > discrete and well defined functionality.
> >
> >
> > Personally, I don't think we should do anything drastic with CI until
> > after we release Newton, so we don't add any risk of impacting new
> > features that haven't landed yet. I do think it would be a good goal for
> > Ocata to have a CI system in TripleO that is consumable outside of
> > TripleO. In any case, this email is simply to garner feedback if other's
> > think this is a worthy thing to pursue and opinions on how we can get
> > there.
> >
>
> +1 here.  I agree there should be enough time for thoughtful conversation
> without
> disrupting higher priority work.
>
> Thanks for sending this out John!
>
>
> >
> >
> > [1]
> >
> >
> https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role-tripleo
> > (note not all of these are actively used/developed)
> > [2] https://github.com/rdo-infra/weirdo
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/15ec1005/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 13 Jul 2016 12:40:46 +0000
> From: Alexey Khivin <akhivin at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
> Message-ID:
>         <CAB2Nh0L76XAyCZervTQ+OauzjjXF9cp+=
> W6yeMoyuWYrNGA7LA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thank You Renat, Moshe, Stan and all!
>
>
> ??, 6 ???. 2016 ?. ? 7:01, Renat Akhmerov <renat.akhmerov at gmail.com>:
>
> > Great! Alex, enjoy using yaqluator :)
> >
> > Renat Akhmerov
> > @Nokia
> >
> > On 05 Jul 2016, at 23:16, Elisha, Moshe (Nokia - IL) <
> > moshe.elisha at nokia.com> wrote:
> >
> > Thank you all for assisting.
> >
> > When I tested Mistral I used an older version of Mistral (meaning an
> older
> > version of yaql).
> >
> > I have verified that latest Mistral is working as expected.
> > I have upgraded the yaql library in yaqluator to 1.1.0 and it is now
> > working as expected.
> >
> > Thanks!
> >
> > From: Dougal Matthews <dougal at redhat.com>
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <
> > openstack-dev at lists.openstack.org>
> > Date: Tuesday, 5 July 2016 at 17:53
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
> >
> >
> >
> > On 5 July 2016 at 08:32, Renat Akhmerov <renat.akhmerov at gmail.com>
> wrote:
> >
> >> Stan, thanks for clarification. What?s the latest stable version that
> >> we?re supposed to use? global-requirements.txt has yaql>=1.1.0, I wonder
> >> if it?s correct.
> >>
> >
> > It is also worth looking at the upper-constraints.txt. It has 1.1.1 which
> > is the latest release. So it all seems up to date.
> >
> >
> >
> https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L376
> >
> > I think the problem is that this external project isn't being updated.
> > Assuming they have not deployed anything that isn't committed, then they
> > are running YAQL 1.0.2 which is almost a year old.
> >
> >
> https://github.com/ALU-CloudBand/yaqluator/blob/master/requirements.txt#L3
> >
> >
> >>
> >> Renat Akhmerov
> >> @Nokia
> >>
> >> On 05 Jul 2016, at 12:12, Stan Lagun <slagun at mirantis.com> wrote:
> >>
> >> Hi!
> >>
> >> The issue with join is just a yaql bug that is already fixed. The
> problem
> >> with yaqluator is that it doesn't use the latest yaql library.
> >>
> >> Another problem is that it does't sets options correctly. As a result it
> >> is possible to bring the site down with a query that produces endless
> >> collection
> >>
> >> Sincerely yours,
> >> Stan Lagun
> >> Principal Software Engineer @ Mirantis
> >>
> >> <slagun at mirantis.com>
> >>
> >> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <
> >> moshe.elisha at nokia.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> Thank you for the kind words, Alexey.
> >>>
> >>> I was able to reproduce your bug and I have also found the issue.
> >>>
> >>> The problem is that we did not create the parser with the
> engine_options
> >>> used in the yaql library by default when using the CLI.
> >>> Specifically, the "yaql.limitIterators" was missing? I am not sure that
> >>> this settings should have this affect but maybe the Yaql guys can
> comment
> >>> on that.
> >>>
> >>> If we will change yaqluator to use this setting it will mean that
> >>> yaqluator will not be consistent with Mistral because Mistral is using
> YAQL
> >>> without this engine option (If I use your example in a workflow,
> Mistral
> >>> returns exactly like the yaqluator returns)
> >>>
> >>>
> >>> Workflow:
> >>>
> >>> ---
> >>> version: '2.0'
> >>>
> >>> test_yaql:
> >>>   tasks:
> >>>     test_yaql:
> >>>       action: std.noop
> >>>       publish:
> >>>         output_expr: <% [1,2].join([3], true, [$1, $2]) %>
> >>>
> >>>
> >>> Workflow result:
> >>>
> >>>
> >>> [root at s53-19 ~(keystone_admin)]# mistral task-get-published
> >>> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
> >>> {
> >>>     "output_expr": [
> >>>         [
> >>>             1,
> >>>             3
> >>>         ]
> >>>     ]
> >>> }
> >>>
> >>>
> >>> As Matthews pointed out, the yaqluator is indeed OpenSource and
> >>> contributions are welcomed.
> >>>
> >>> [1]
> >>>
> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
> >>>
> >>>
> >>>
> >>> From: Dougal Matthews <dougal at redhat.com>
> >>> Reply-To: "OpenStack Development Mailing List (not for usage
> >>> questions)" <openstack-dev at lists.openstack.org>
> >>> Date: Monday, 27 June 2016 at 16:44
> >>> To: "OpenStack Development Mailing List (not for usage questions)" <
> >>> openstack-dev at lists.openstack.org>
> >>> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
> >>>
> >>> On 27 June 2016 at 14:30, Alexey Khivin <akhivin at gmail.com> wrote:
> >>>
> >>>> Hello, Moshe
> >>>>
> >>>> Tomorrow I discovered yaqluator.com for myself! Thanks for the useful
> >>>> tool!
> >>>>
> >>>> But suddenly I was said that the expression
> >>>> [1,2].join([3], true, [$1, $2])
> >>>> evaluated to [[1,3]] on the yaqluator
> >>>>
> >>>> A the same time this expression evaluated right when I using raw yaql
> >>>> interpreter.
> >>>>
> >>>> Could we fix this issue?
> >>>>
> >>>> By the way, don't you want to make yaqluator opensource? If you would
> >>>> transfer yaqluator to Openstack Foundation, then  community will be
> able to
> >>>> fix such kind of bugs
> >>>>
> >>>
> >>> It looks like it is open source, there is a link in the footer:
> >>> https://github.com/ALU-CloudBand/yaqluator
> >>>
> >>>
> >>>>
> >>>> Thank you!
> >>>> Best regards, Alexey Khivin
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> __________________________________________________________________________
> >>>> OpenStack Development Mailing List (not for usage questions)
> >>>> Unsubscribe:
> >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> <
> http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
> >> <http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/109ba2fa/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 13 Jul 2016 14:54:20 +0200
> From: Michal Pryc <mpryc at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Making TripleO CI easier to
>         consume outside of TripleO CI
> Message-ID:
>         <
> CACJAfezG30UZdFM_mrxba4j6rU3tdmnSAZvoh8bJCvjHpAV_0A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> John,
>
> On Tue, Jul 12, 2016 at 9:39 PM, John Trowbridge <trown at redhat.com> wrote:
>
> > Howdy folks,
> >
> > In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
> > is being used as a CI tool in RDO. This came about organically, because
> > we needed to use RDO CI to self-gate quickstart (it relies on having a
> > baremetal virthost). It displaced another ansible based CI tool there
> > (khaleesi) and most(all?) of the extra functionality from that tool
> > (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
> > roles that are able to plugin to quickstart.[1]
> >
> >
> Here is small sum of frameworks/tools to give you an idea what we are
> currently using to test RHOS components.
>
> To create Triple-O undercloud/overcloud we are using the:
>
> https://github.com/redhat-openstack/ansible-ovb
>
> And then to install RHOSP on existing Triple-O:
>
> https://github.com/redhat-openstack/ansible-rhosp
>
> Then to run CI in such environment we use octario which is our main tool to
> run different flavors of tests and it's separate CI tool to be ready with
> different provisioning frameworks.
>
> https://github.com/redhat-openstack/octario/
>
>
> In the simplistic environment to run simple tests we are using InfraRed to
> provision simple instance (without Triple-O):
>
> https://github.com/rhosqeauto/InfraRed
>
> And then we run octario in such environment to run actual tests.
>
> Ideally if the provisioning parts were common and we could reuse them.
> Currently we need to use yet another set of tools to be able to patch rpm's
> prior to running tests.
>
> There was an idea planted by dsariel to move some of the playbooks into
> ansible-galaxy roles (possibly other teams had such idea as well), which I
> can see it's another +1 for going with tools currently developed by Wes as
> they are pretty separate and could be converted into ansible-galaxy, to be
> available across different use-cases, but then it would need to be well
> defined so the roles are not multiplied and we won't end up having similar
> roles.
>
>
> best
> Michal Pryc
>
>
>
> > We are still left with two different tool sets, where one should suffice
> > (and focus CI efforts in one place).
> >
> > I see two different ways to resolve this.
> >
> > 1. Actively work on making the tripleo-ci scripts consumable external to
> > tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
> > upstream CI for packstack and puppet, so it is not totally far-fetched
> > to add support for TripleO jobs.
> >
> > Pros:
> > - All CI development just happens directly in tripleo-ci and RDO just
> > inherits that work.
> >
> > Cons:
> > - This is totally untried, and therefore a totally unknown amount of
> work.
> > - It is all or nothing in that there is no incremental path to get the
> > CI scripts working outside of CI.
> > - We have to rewrite a bunch of working ansible code in bash which IMO
> > is the wrong direction for a modern CI system.
> >
> >
> > 2. Actively work on making tripleo-ci consume the ansible work in
> > tripleo-quickstart and the external role ecosystem around it.
> >
> > Pros:
> > - This could be done incrementally, replacing a single function from
> > tripleo.sh with an invocation of tripleo-quickstart that performs that
> > function instead.
> > - We would be able to pull in a lot of extra functionality via these
> > external roles for free(ish).
> >
> > Cons:
> > - Similarly unknown amount of work to completely switch.
> > - CI development would be done in multiple repos, though each would have
> > discrete and well defined functionality.
> >
> >
> > Personally, I don't think we should do anything drastic with CI until
> > after we release Newton, so we don't add any risk of impacting new
> > features that haven't landed yet. I do think it would be a good goal for
> > Ocata to have a CI system in TripleO that is consumable outside of
> > TripleO. In any case, this email is simply to garner feedback if other's
> > think this is a worthy thing to pursue and opinions on how we can get
> > there.
> >
> >
> > [1]
> >
> >
> https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role-tripleo
> > (note not all of these are actively used/developed)
> > [2] https://github.com/rdo-infra/weirdo
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/a4ce9600/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Wed, 13 Jul 2016 13:04:59 +0000
> From: "Steven Dake (stdake)" <stdake at cisco.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla] New specs process - a dicussion
> Message-ID: <D3ABB3B7.24F67%stdake at cisco.com>
> Content-Type: text/plain; charset="iso-8859-2"
>
> Josh,
>
> We did have the discussion at summit.  We aren't even going to have a "big
> spec".  We are going to run as bare minimal of a spec as possible.  The
> reason I brought up spec additions is because Kolla has become so large,
> managing the project using current techniques is not optimal.  I don't
> like process but in the future, the PTL will need an easy on-ramp to
> managing Kolla output.
>
> I agree with all of the risks you point out related to usage of specs.  I
> am hopeful we can make this is a super lightweight process without the
> nitpicking that occurs in other projects.  That said, the rollcall vote
> specs I expect to be as painful as they currently are (by design).
>
> Regards
> -steve
>
>
> On 7/12/16, 4:03 PM, "Joshua Harlow" <harlowja at fastmail.com> wrote:
>
> >Something for consideration to make the specs process not to painful and
> >one that I think (?) glance pioneered is to have a 'bigger spec' and a
> >'smaller spec' template.
> >
> >
> https://github.com/openstack/glance-specs/blob/master/specs/lite-specs.rst
> >
> >(smaller)
> >
> >https://github.com/openstack/glance-specs/blob/master/specs/template.rst
> >(bigger)
> >
> >Just my 2 cents, don't bog down people to much with just big specs and
> >nit picking and trying to develop the whole feature in the spec (cause
> >that will off-put new people and senior people and ...).
> >
> >-Josh
> >
> >Micha? Jastrz?bski wrote:
> >> Hey guys,
> >>
> >> Since our project matured, we decided that we should have a discussion
> >> regarding our spec process.
> >>
> >> https://etherpad.openstack.org/p/kolla-N-midcycle-specs
> >>
> >> Currently we do specs for most critical things, and they require
> >>majority vote.
> >>
> >> We want to introduce another way, to enable non-nuclear specs.
> >> To summarize our discussion so far:
> >>
> >> 1. Specs will require only 2 * +2 by default
> >> 2. Specs sit at minimum 2 weeks in gerrit before first +2 arrives, so
> >> other people will have time to look at it
> >> 3. Any core can require a rollcall vote - then it becomes rollcall vote
> >> 4. If nobody calls for rollcall vote, after 2 weeks spec can be merged
> >> with normal 2 * +2
> >>
> >> Thoughts?
> >> Michal
> >>
> >>
> >>_________________________________________________________________________
> >>_
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >>OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 13 Jul 2016 09:06:37 -0400
> From: Wesley Hayutin <whayutin at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Making TripleO CI easier to
>         consume outside of TripleO CI
> Message-ID:
>         <
> CAOHJT4Kf_siw7SBw2GhyOzi9qAtDZm3Hf893CjaKYuNRJ2hENg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Jul 13, 2016 at 8:54 AM, Michal Pryc <mpryc at redhat.com> wrote:
>
> > John,
> >
> > On Tue, Jul 12, 2016 at 9:39 PM, John Trowbridge <trown at redhat.com>
> wrote:
> >
> >> Howdy folks,
> >>
> >> In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
> >> is being used as a CI tool in RDO. This came about organically, because
> >> we needed to use RDO CI to self-gate quickstart (it relies on having a
> >> baremetal virthost). It displaced another ansible based CI tool there
> >> (khaleesi) and most(all?) of the extra functionality from that tool
> >> (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
> >> roles that are able to plugin to quickstart.[1]
> >>
> >>
> > Here is small sum of frameworks/tools to give you an idea what we are
> > currently using to test RHOS components.
> >
> > To create Triple-O undercloud/overcloud we are using the:
> >
> > https://github.com/redhat-openstack/ansible-ovb
> >
> > And then to install RHOSP on existing Triple-O:
> >
> > https://github.com/redhat-openstack/ansible-rhosp
> >
> > Then to run CI in such environment we use octario which is our main tool
> > to run different flavors of tests and it's separate CI tool to be ready
> > with different provisioning frameworks.
> >
> > https://github.com/redhat-openstack/octario/
> >
> >
> > In the simplistic environment to run simple tests we are using InfraRed
> to
> > provision simple instance (without Triple-O):
> >
> > https://github.com/rhosqeauto/InfraRed
> >
> > And then we run octario in such environment to run actual tests.
> >
> > Ideally if the provisioning parts were common and we could reuse them.
> > Currently we need to use yet another set of tools to be able to patch
> rpm's
> > prior to running tests.
> >
>
> +1, agree
> I think this part has been addressed w/
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-quickstart
>
>
> >
> > There was an idea planted by dsariel to move some of the playbooks into
> > ansible-galaxy roles (possibly other teams had such idea as well), which
> I
> > can see it's another +1 for going with tools currently developed by Wes
> as
> > they are pretty separate and could be converted into ansible-galaxy, to
> be
> > available across different use-cases, but then it would need to be well
> > defined so the roles are not multiplied and we won't end up having
> similar
> > roles.
> >
> >
> We also considered ansible-galaxy and any of the ansible roles found in
> github/redhat-openstack/ansible-role could be moved into galaxy.  Galaxy
> did not end up meeting our requirements for installing the roles and we
> ended up using python setuptools.  Some roles have specific config and
> playbooks that need to be copied to a standard location and galaxy just did
> not do that very well.
>
>
> >
> > best
> > Michal Pryc
> >
> >
> >
> >> We are still left with two different tool sets, where one should suffice
> >> (and focus CI efforts in one place).
> >>
> >> I see two different ways to resolve this.
> >>
> >> 1. Actively work on making the tripleo-ci scripts consumable external to
> >> tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
> >> upstream CI for packstack and puppet, so it is not totally far-fetched
> >> to add support for TripleO jobs.
> >>
> >> Pros:
> >> - All CI development just happens directly in tripleo-ci and RDO just
> >> inherits that work.
> >>
> >> Cons:
> >> - This is totally untried, and therefore a totally unknown amount of
> work.
> >> - It is all or nothing in that there is no incremental path to get the
> >> CI scripts working outside of CI.
> >> - We have to rewrite a bunch of working ansible code in bash which IMO
> >> is the wrong direction for a modern CI system.
> >>
> >>
> >> 2. Actively work on making tripleo-ci consume the ansible work in
> >> tripleo-quickstart and the external role ecosystem around it.
> >>
> >> Pros:
> >> - This could be done incrementally, replacing a single function from
> >> tripleo.sh with an invocation of tripleo-quickstart that performs that
> >> function instead.
> >> - We would be able to pull in a lot of extra functionality via these
> >> external roles for free(ish).
> >>
> >> Cons:
> >> - Similarly unknown amount of work to completely switch.
> >> - CI development would be done in multiple repos, though each would have
> >> discrete and well defined functionality.
> >>
> >>
> >> Personally, I don't think we should do anything drastic with CI until
> >> after we release Newton, so we don't add any risk of impacting new
> >> features that haven't landed yet. I do think it would be a good goal for
> >> Ocata to have a CI system in TripleO that is consumable outside of
> >> TripleO. In any case, this email is simply to garner feedback if other's
> >> think this is a worthy thing to pursue and opinions on how we can get
> >> there.
> >>
> >>
> >> [1]
> >>
> >>
> https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role-tripleo
> >> (note not all of these are actively used/developed)
> >> [2] https://github.com/rdo-infra/weirdo
> >>
> >>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/9f6be61a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Wed, 13 Jul 2016 09:32:31 -0400
> From: Brian Haley <brian.haley at hpe.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Neutron][DVR] - No IRC Meeting today
> Message-ID: <578642EF.8050003 at hpe.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Folks,
>
> Sorry for the late notice, but we will not have a DVR sub-team meeting
> today
> since neither Swami nor myself will be there to chair it.
>
> We will resume our meetings next week on July 20th.
>
> If you have any questions please ping us on IRC or send an email to the
> list.
>
> https://wiki.openstack.org/wiki/Meetings/Neutron-DVR
>
> Thanks,
>
> -Brian
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 13 Jul 2016 08:35:27 -0500
> From: eran at itsonlyme.name
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [storlets] IRC meeting times
> Message-ID:
>         <20160713083527.Horde.JjqJt86jqdhpfV7V6XE-oyL at e15.ehosts.com>
> Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
>
> Hi,
> I would like to change the IRC meeting times to Tuesdays at 07:00AM UTC
> That's:
> 16:00 JST
> 10:00 IST
>
> Any objections?
> Thanks!
> Eran
>
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 13 Jul 2016 16:54:50 +0300
> From: Ivan Kolodyazhny <e0ne at e0ne.info>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [cinder] [nova] os-brick privsep failures
>         and an upgrade strategy?
> Message-ID:
>         <CAGocpaHJ61e-5Lcijip=
> SVwZZ8U9m+T6R-9b2jACV2P41UMrog at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for the update, Matt.
>
> I will join our meeting next week.
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Tue, Jul 12, 2016 at 4:25 PM, Matt Riedemann <
> mriedem at linux.vnet.ibm.com>
> wrote:
>
> > On 7/12/2016 6:29 AM, Ivan Kolodyazhny wrote:
> >
> >> Hi team,
> >>
> >> Do we have any decision on this issue? I've found few patches but both
> >> of them are -1'ed.
> >>
> >> From Cinder perspective, it blocks us to release new os-brick with
> >> features, which are needed for other projects like Cinder and
> >> python-brick-cinderclient-ext.
> >>
> >> Regards,
> >> Ivan Kolodyazhny,
> >> http://blog.e0ne.info/
> >>
> >> On Wed, Jun 22, 2016 at 5:47 PM, Matt Riedemann
> >> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>> wrote:
> >>
> >>     On 6/21/2016 10:12 PM, Angus Lees wrote:
> >>
> >>         On Wed, 22 Jun 2016 at 05:59 Matt Riedemann
> >>         <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>
> >>         <mailto:mriedem at linux.vnet.ibm.com
> >>
> >>         <mailto:mriedem at linux.vnet.ibm.com>>> wrote:
> >>
> >>             Angus, what should we be looking at from the privsep side
> >>         for debugging
> >>             this?
> >>
> >>
> >>         The line above the screen-n-cpu.txt.gz failure you linked to is:
> >>         2016-06-21 16:21:30.994
> >>         <
> >>
> http://logs.openstack.org/85/331885/2/check/gate-grenade-dsvm-multinode/415e1bc/logs/new/screen-n-cpu.txt.gz?level=TRACE#_2016-06-21_16_21_30_994
> >> >1840
> >>         WARNING oslo.privsep.daemon [-] privsep log:
> >>         /usr/local/bin/nova-rootwrap: Unauthorized command:
> privsep-helper
> >>         --config-file /etc/nova/nova.conf --privsep_context
> >>         os_brick.privileged.default --privsep_sock_path
> >>         /tmp/tmpV5w2VC/privsep.sock (no filter matched)
> >>
> >>          .. so nova-rootwrap is rejecting the privsep-helper command
> line
> >>         because no filter matched.  This indicates the nova
> >>         compute.filters file
> >>         has not been updated, or is incorrect.
> >>
> >>
> >>         As was later pointed out by mtreinish, grenade is attempting to
> >>         run the
> >>         newton code against mitaka configs, and this includes using
> mitaka
> >>         rootwrap filters.   Unfortunately, the change to add privsep to
> >>         nova's
> >>         rootwrap filters wasn't approved until the newton cycle (so that
> >>         all the
> >>         os-brick privsep-related changes could be approved together),
> and
> >> so
> >>         this doesn't Just Work.
> >>
> >>         Digging in further, it appears that there *is* a mechanism in
> >>         grenade to
> >>         upgrade rootwrap filters between major releases, but this needs
> >>         to be
> >>         explicitly updated for each project+release and hasn't been for
> >>         nova+mitaka->newton.  I'm not sure how this is *meant* to work,
> >>         since
> >>         the grenade "theory of upgrade" doesn't mention when configs
> >>         should be
> >>         updated - the only mechanism provided is an "exception ... used
> >>         sparingly."
> >>
> >>
> >>     As noted in the review, my understanding of the config changes is
> >>     deprecation of options across release boundaries so that you can't
> >>     drop a config option that would break someone from release to
> >>     release without it being deprecated first. So deprecate option foo
> >>     in mitaka, people upgrading from liberty to mitaka aren't broken,
> >>     but they get warnings in mitaka so that when you drop the option in
> >>     newton it's not a surprise and consumers should have adjusted during
> >>     mitaka.
> >>
> >>     For rootwrap filters I agree this is more complicated.
> >>
> >>
> >>         Anyway, I added an upgrade step for nova mitaka->newton that
> >> updates
> >>         rootwrap filters appropriately(*).  Again, I'm not sure what
> this
> >>         communicates to deployers compared to cinder (which *did* have
> the
> >>         updated rootwrap filter merged in mitaka, but of course that
> >> update
> >>         still needs to be installed at some point).
> >>         (*) https://review.openstack.org/#/c/332610
> >>
> >>          - Gus
> >>
> >>
> >>
> >>
> __________________________________________________________________________
> >>         OpenStack Development Mailing List (not for usage questions)
> >>         Unsubscribe:
> >>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>         <
> >> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>     Alternatively Walter had a potential workaround to fallback to
> >>     rootwrap for os-brick:
> >>
> >>     https://review.openstack.org/#/c/329586/
> >>
> >>     So we could maybe use that for newton. But os-vif doesn't have
> >>     anything like that, so we'd have to see what kind of (immediately
> >>     deprecated) workaround could happen for os-vif in newton and then
> >>     drop that in ocata.
> >>
> >>     I'm told danpb is out until tomorrow though so we'll probably need
> >>     to wait to talk to him about options there.
> >>
> >>
> >>     --
> >>
> >>     Thanks,
> >>
> >>     Matt Riedemann
> >>
> >>
> >>
> >>
> __________________________________________________________________________
> >>     OpenStack Development Mailing List (not for usage questions)
> >>     Unsubscribe:
> >>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>     <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> > We probably aren't doing anything while Sean Dague is on vacation. He's
> > back next week and we have the nova/cinder meetups, so I'm planning on
> > talking about the grenade issue in person and hopefully we'll have a plan
> > by the end of next week to move forward.
> >
> >
> > --
> >
> > Thanks,
> >
> > Matt Riedemann
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/bdab20d1/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 9
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] debtcollector 1.6.0 release
>         (newton)
> Message-ID:
>         <mailman.21348.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are pumped to announce the release of:
>
> debtcollector 1.6.0: A collection of Python deprecation patterns and
> strategies that help you collect your technical debt in a non-
> destructive manner.
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/debtcollector
>
> With package available at:
>
>     https://pypi.python.org/pypi/debtcollector
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/debtcollector
>
> For more details, please see below.
>
> Changes in debtcollector 1.5.0..1.6.0
> -------------------------------------
>
> d46b64a Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> test-requirements.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index d1f9b5d..16f75c6 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -10 +10 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 10
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] mox3 0.17.0 release (newton)
> Message-ID:
>         <mailman.21349.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are tickled pink to announce the release of:
>
> mox3 0.17.0: Mock object framework for Python
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/mox3
>
> With package available at:
>
>     https://pypi.python.org/pypi/mox3
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/python-mox3
>
> For more details, please see below.
>
> Changes in mox3 0.16.0..0.17.0
> ------------------------------
>
> 2b58961 Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> test-requirements.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index ad30fa2..df05b72 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -20 +20 @@ six>=1.9.0 # MIT
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 11
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] futurist 0.15.0 release (newton)
> Message-ID:
>         <mailman.21350.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are eager to announce the release of:
>
> futurist 0.15.0: Useful additions to futures, from the future.
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/futurist
>
> With package available at:
>
>     https://pypi.python.org/pypi/futurist
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/futurist
>
> For more details, please see below.
>
> Changes in futurist 0.14.0..0.15.0
> ----------------------------------
>
> 4ca63cb Don't include openstack/common in flake8 exclude list
> c7c67ca Updated from global requirements
> dc08625 Begin adding our own thread pool executor
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> futurist/_futures.py  |  80 ++++++++++++++-------------
> futurist/_thread.py   | 146
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> futurist/_utils.py    |   2 +
> test-requirements.txt |   2 +-
> tox.ini               |   2 +-
> 5 files changed, 193 insertions(+), 39 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 6e6d300..68ed7a0 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -14 +14 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 12
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.cache 1.11.0 release
>         (newton)
> Message-ID:
>         <mailman.21351.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are psyched to announce the release of:
>
> oslo.cache 1.11.0: Cache storage for Openstack projects.
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.cache
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.cache
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.cache
>
> For more details, please see below.
>
> Changes in oslo.cache 1.10.0..1.11.0
> ------------------------------------
>
> 86bcd66 Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> requirements.txt      | 2 +-
> test-requirements.txt | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 28e46dd..b1defe2 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -10 +10 @@ oslo.log>=1.14.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.14.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 42f2881..0510e84 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -8,2 +8,2 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> -reno>=1.6.2 # Apache2
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> +reno>=1.8.0 # Apache2
>
>
>
>
>
> ------------------------------
>
> Message: 13
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] automaton 1.3.0 release (newton)
> Message-ID:
>         <mailman.21352.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are satisfied to announce the release of:
>
> automaton 1.3.0: Friendly state machines for python.
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/automaton
>
> With package available at:
>
>     https://pypi.python.org/pypi/automaton
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/automaton
>
> For more details, please see below.
>
> Changes in automaton 1.2.0..1.3.0
> ---------------------------------
>
> 4008814 Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> test-requirements.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 0036b56..2c695bc 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -11 +11 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 14
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.config 3.13.0 release
>         (newton)
> Message-ID:
>         <mailman.21353.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are thrilled to announce the release of:
>
> oslo.config 3.13.0: Oslo Configuration API
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.config
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.config
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.config
>
> For more details, please see below.
>
> Changes in oslo.config 3.12.0..3.13.0
> -------------------------------------
>
> 335b184 Add Python 3.5 classifier and venv
> d174a4e Enabling your project for mutable-config
> 7539018 Add namespace to _list_opts() in test
> a08ec74 decode subprocess output so doc build works on python3
> 7111070 Updated from global requirements
> 4f97c6f Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> setup.cfg                           |   1 +
> test-requirements.txt               |   4 +-
> tox.ini                             |   2 +-
> 7 files changed, 128 insertions(+), 5 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 4789fb0..d444b33 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -21 +21 @@ coverage>=3.6 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> @@ -23 +23 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -reno>=1.6.2 # Apache2
> +reno>=1.8.0 # Apache2
>
>
>
>
>
> ------------------------------
>
> Message: 15
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.context 2.6.0 release
>         (newton)
> Message-ID:
>         <mailman.21354.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are chuffed to announce the release of:
>
> oslo.context 2.6.0: Oslo Context library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.context
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.context
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.context
>
> For more details, please see below.
>
> Changes in oslo.context 2.5.0..2.6.0
> ------------------------------------
>
> 740b817 Handle openstack.request_id in from_environ
> d3af1d0 Add is_admin_project to context
> 4db9262 Updated from global requirements
> f0de0c6 Add oslo.context name attributes matching ids
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> oslo_context/context.py            |  45 +++++++-
> test-requirements.txt              |   4 +-
> 3 files changed, 174 insertions(+), 92 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 1db9871..79fca04 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -11,2 +11,2 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> -reno>=1.6.2 # Apache2
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> +reno>=1.8.0 # Apache2
>
>
>
>
>
> ------------------------------
>
> Message: 16
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.concurrency 3.12.0 release
>         (newton)
> Message-ID:
>         <mailman.21355.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are chuffed to announce the release of:
>
> oslo.concurrency 3.12.0: Oslo Concurrency library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.concurrency
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.concurrency
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.concurrency
>
> For more details, please see below.
>
> Changes in oslo.concurrency 3.11.0..3.12.0
> ------------------------------------------
>
> f7821d9 Updated from global requirements
> 68df6b2 Imported Translations from Zanata
> f13a21c Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> .../locale/en_GB/LC_MESSAGES/releasenotes.po       | 30
> ++++++++++++++++++++++
> requirements.txt                                   |  4 +--
> test-requirements.txt                              |  4 +--
> 3 files changed, 34 insertions(+), 4 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 51b3c76..864afc1 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -8 +8 @@ iso8601>=0.1.11 # MIT
> -oslo.config>=3.10.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
> @@ -10 +10 @@ oslo.i18n>=2.1.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 8418f39..e431107 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -13,2 +13,2 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> -reno>=1.6.2 # Apache2
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> +reno>=1.8.0 # Apache2
>
>
>
>
>
> ------------------------------
>
> Message: 17
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.i18n 3.8.0 release (newton)
> Message-ID:
>         <mailman.21356.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are overjoyed to announce the release of:
>
> oslo.i18n 3.8.0: Oslo i18n library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.i18n
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.i18n
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.i18n
>
> For more details, please see below.
>
> Changes in oslo.i18n 3.7.0..3.8.0
> ---------------------------------
>
> 16f40a6 Updated from global requirements
> 6bc0cfc Don't include openstack/common in flake8 exclude list
> 82e8a63 Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> test-requirements.txt | 4 ++--
> tox.ini               | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 758c7d5..80bdbbb 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -7 +7 @@ hacking<0.11,>=0.10.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> @@ -15 +15 @@ coverage>=3.6 # Apache-2.0
> -oslo.config>=3.10.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
>
>
>
>
>
> ------------------------------
>
> Message: 18
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.middleware 3.15.0 release
>         (newton)
> Message-ID:
>         <mailman.21357.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are thrilled to announce the release of:
>
> oslo.middleware 3.15.0: Oslo Middleware library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.middleware
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.middleware
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.middleware
>
> For more details, please see below.
>
> Changes in oslo.middleware 3.14.0..3.15.0
> -----------------------------------------
>
> 6ca6c88 Updated from global requirements
> 45e90c6 Updated from global requirements
> b07c27d Updated from global requirements
> 7e519d0 Deprecate using String as valid value for allowed_origin.
> 399e940 Deprecate multiple config block parsing.
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> oslo_middleware/cors.py | 10 +++++++++-
> requirements.txt        |  4 ++--
> test-requirements.txt   |  2 +-
> 4 files changed, 13 insertions(+), 29 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 01c7f22..b80e5c6 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -7 +7 @@ Jinja2>=2.8 # BSD License (3 clause)
> -oslo.config>=3.10.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
> @@ -10 +10 @@ oslo.i18n>=2.1.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index d913843..5f53419 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -10 +10 @@ oslotest>=1.10.0 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 19
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.log 3.12.0 release (newton)
> Message-ID:
>         <mailman.21358.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are thrilled to announce the release of:
>
> oslo.log 3.12.0: oslo.log library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.log
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.log
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.log
>
> For more details, please see below.
>
> 3.12.0
> ^^^^^^
>
> New Features
>
> * The log_config_append configuration option is now mutable and the
>   logging settings it controls are reconfigured when the configuration
>   file is reread. This can be used to, for example, change logger or
>   handler levels.
>
> Changes in oslo.log 3.11.0..3.12.0
> ----------------------------------
>
> c426a42 Replace "LOG.exception(_" with "LOG.exception(_LE"
> 5082d92 Updated from global requirements
> 8fde280 Reload log_config_append config on SIGHUP
> e4c651b Imported Translations from Zanata
> e3bd7e6 Updated from global requirements
> fc490c0 log: Introduce _iter_loggers
> 15ef585 Imported Translations from Zanata
> 1bea3a5 Updated from global requirements
> 68bde95 Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> oslo_log/_options.py                               |   1 +
> oslo_log/locale/de/LC_MESSAGES/oslo_log.po         |  60 +++++
> oslo_log/locale/en_GB/LC_MESSAGES/oslo_log.po      |  55 ++++
> oslo_log/locale/oslo_log.pot                       |  63 -----
> oslo_log/log.py                                    |  38 ++-
> .../notes/reload_log_config-743817192b1172b6.yaml  |   5 +
> .../locale/en_GB/LC_MESSAGES/releasenotes.po       |  63 +++++
> requirements.txt                                   |   4 +-
> test-requirements.txt                              |   4 +-
> 11 files changed, 488 insertions(+), 105 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 26c3390..9bac65f 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -7 +7 @@ six>=1.9.0 # MIT
> -oslo.config>=3.10.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
> @@ -10 +10 @@ oslo.i18n>=2.1.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index c2d83c8..4c9bc0c 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -21 +21 @@ coverage>=3.6 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> @@ -23 +23 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -reno>=1.6.2 # Apache2
> +reno>=1.8.0 # Apache2
>
>
>
>
>
> ------------------------------
>
> Message: 20
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.db 4.8.0 release (newton)
> Message-ID:
>         <mailman.21359.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are satisfied to announce the release of:
>
> oslo.db 4.8.0: Oslo Database library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.db
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.db
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.db
>
> For more details, please see below.
>
> 4.8.0
> ^^^^^
>
>
> New Features
> ************
>
> * enginefacade decorators can now be used for class and instance
>   methods, which implicitly receive the first positional argument.
>   Previously, it was required that all decorated functions receive a
>   context value as the first argument.
>
>
> Deprecation Notes
> *****************
>
> * The configuration option "sqlite_db" is now deprecated and will be
>   removed in the future. Please use configuration option "connection"
>   or "slave_connection" to connect to the database.
>
> Changes in oslo.db 4.6.0..4.8.0
> -------------------------------
>
> fc3c23a Updated from global requirements
> 462296b Add support for LONGTEXT, MEDIUMTEXT to JsonEncodedType
> 0a1bae9 Deprecate config option sqlite_db for removal
> 16886e5 Catch empty value DBDuplicate errors
> 1d7e7e4 Updated from global requirements
> 8e3b356 api: use sane default in wrap_db_retry()
> 21491e1 Imported Translations from Zanata
> e59c2b5 exc_filters: catch and translate non existent table on drop
> e0db469 exception: make message mandatory in DbMigrationError and
> deprecates it
> 8a5fbb7 Make it possible to use enginefacade decorators with class methods
> ef97c25 Updated from global requirements
> 4c82261 tests: fix order of assertEqual in exc_filter
> c4f025d exc_filters: catch and translate non existent constraint on drop
> 1579c7c Replace tempest-lib dependency with os-testr
> b8ffab6 Imported Translations from Zanata
> a2da070 Fix typos in comments and docstring
> c0005aa Updated from global requirements
> 9b9170f Updated from global requirements
> a71fe96 Fix typo: 'olso' to 'oslo'
> 34a3da3 Repair boolean CHECK constraint detection
> 2938f28 api: do not log a traceback if error is not expected
> e351f44 Fix imports in doc
> 044cf85 Allow testing of MySQL and PostgreSQL scenario locally
> 4bbadac Add support for custom JSON serializer
> 663092d api: always enable retry_on_request
> 7574ab7 Remove oslo-incubator related stuff
> 3ac4f3f Updated from global requirements
> 268987f Updated from global requirements
> 4afa0ce Remove direct dependency on babel
> 976bcdf Imported Translations from Zanata
> 3816739 Add debtcollector to requirements
> 30f061d Fix unit tests failures, when psycopg2 is not installed
> f5a8fb3 Fix server_default comparison for BigInteger
> c9e0bcd Remove unused sqlite_fk in _init_connection_args call
> 531ed45 Updated from global requirements
> 59b845d Correct docstring
> 46767e5 Updated from global requirements
> b283e7d Updated from global requirements
> 419a42f Updated from global requirements
> af0b3d3 Updated from global requirements
> b45a20b Updated from global requirements
> 08f4911 Raise DbMigrationError for invalid version
> b1de3f7 Add new filter for DBDataError exception
> 4048c8f Fix spelling mistake
> f98cb90 Let enginefacade._TransactionContextManager look for context
> 09c531b Remove  sqlalchemy < 1.0.0 compatible layer
> 045a6fb Update reno for stable/mitaka
> 6c9cc58 Updated from global requirements
> e9cbc6e Add tests for float interval values in wrap_db_retry()
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> CONTRIBUTING.rst                                   |  27 ++
> oslo_db/api.py                                     |  34 +-
> oslo_db/exception.py                               |  41 +++
> .../locale/en_GB/LC_MESSAGES/oslo_db-log-error.po  |  11 +-
> .../locale/en_GB/LC_MESSAGES/oslo_db-log-info.po   |   8 +-
> .../en_GB/LC_MESSAGES/oslo_db-log-warning.po       |   8 +-
> oslo_db/locale/en_GB/LC_MESSAGES/oslo_db.po        |  17 +-
> oslo_db/locale/es/LC_MESSAGES/oslo_db-log-error.po |  11 +-
> oslo_db/locale/es/LC_MESSAGES/oslo_db-log-info.po  |   8 +-
> .../locale/es/LC_MESSAGES/oslo_db-log-warning.po   |   8 +-
> oslo_db/locale/es/LC_MESSAGES/oslo_db.po           |  11 +-
> oslo_db/locale/fr/LC_MESSAGES/oslo_db-log-error.po |  11 +-
> oslo_db/locale/fr/LC_MESSAGES/oslo_db-log-info.po  |   8 +-
> .../locale/fr/LC_MESSAGES/oslo_db-log-warning.po   |   8 +-
> oslo_db/locale/fr/LC_MESSAGES/oslo_db.po           |  11 +-
> oslo_db/locale/oslo_db-log-error.pot               |  51 ---
> oslo_db/locale/oslo_db-log-info.pot                |  29 --
> oslo_db/locale/oslo_db-log-warning.pot             |  44 ---
> oslo_db/locale/oslo_db.pot                         |  83 -----
> oslo_db/options.py                                 |   3 +
> oslo_db/sqlalchemy/compat/__init__.py              |  25 --
> oslo_db/sqlalchemy/compat/handle_error.py          | 341
> ---------------------
> oslo_db/sqlalchemy/enginefacade.py                 |  16 +-
> oslo_db/sqlalchemy/engines.py                      |  11 +-
> oslo_db/sqlalchemy/exc_filters.py                  |  50 ++-
> oslo_db/sqlalchemy/migration.py                    |  25 +-
> oslo_db/sqlalchemy/migration_cli/manager.py        |   4 +-
> oslo_db/sqlalchemy/provision.py                    |   3 +-
> oslo_db/sqlalchemy/test_migrations.py              |   7 +-
> oslo_db/sqlalchemy/types.py                        |  13 +
> oslo_db/sqlalchemy/update_match.py                 |   2 +-
> oslo_db/sqlalchemy/utils.py                        |  31 +-
> ...eprecate_config_sqlite_db-bd41d49343049319.yaml |   7 +
> .../enginefacade_decorators-4660862fe22d2669.yaml  |   6 +
> releasenotes/source/conf.py                        |  10 +-
> releasenotes/source/index.rst                      |   1 +
> .../locale/en_GB/LC_MESSAGES/releasenotes.po       |  89 ++++++
> releasenotes/source/mitaka.rst                     |   6 +
> requirements.txt                                   |  12 +-
> setup.cfg                                          |  14 +-
> tox.ini                                            |  28 +-
> 54 files changed, 789 insertions(+), 958 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 352db43..fbc015b 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -6,2 +6,2 @@ pbr>=1.6 # Apache-2.0
> -alembic>=0.8.0 # MIT
> -Babel>=1.3 # BSD
> +alembic>=0.8.4 # MIT
> +debtcollector>=1.2.0 # Apache-2.0
> @@ -9,3 +9,3 @@ oslo.i18n>=2.1.0 # Apache-2.0
> -oslo.config>=3.4.0 # Apache-2.0
> -oslo.context>=0.2.0 # Apache-2.0
> -oslo.utils>=3.5.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
> +oslo.context>=2.4.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> @@ -14 +14 @@ sqlalchemy-migrate>=0.9.6 # Apache-2.0
> -stevedore>=1.5.0 # Apache-2.0
> +stevedore>=1.10.0 # Apache-2.0
>
>
>
>
>
> ------------------------------
>
> Message: 21
> Date: Wed, 13 Jul 2016 16:11:26 +0200
> From: Markus Zoeller <mzoeller at linux.vnet.ibm.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] The future of OpenStack documentation
> Message-ID: <57864C0E.70602 at linux.vnet.ibm.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 11.07.2016 00:02, Steve Martinelli wrote:
> > I personally like this solution, it seems much more scalable. This
> follows
> > the same pattern of the API docs (moving the content to project repos),
> > which puts the onus back on the project team to maintain and create
> > documentation. I'm also hoping this results in less duplication between
> the
> > guides and the keystone developer docs (the latter of which start to
> stray
> > from "developer" docs and begin to look like "user" docs.
>
> After reading this, the "configuration reference" comes to my mind.
> Having the api-ref and the config-ref at one place, near the code, seems
> logical to me. Nova put a lot of effort into providing valuable help
> text for the config options in the last months. We should also make sure
> that it will result in a good manual, which could be easier if it's
> in-tree, near the code.
>
> --
> Regards, Markus Zoeller (markus_z)
>
> > The folks that contribute to the keystone guides today would still be
> very
> > welcomed to continue to contribute once/if the switch is made.
> >
> > On Fri, Jul 8, 2016 at 5:02 PM, Matt Kassawara <mkassawara at gmail.com>
> wrote:
> >
> >> Currently, OpenStack provides central documentation (primarily in the
> >> openstack-manuals repository) for operators and users. The single
> location
> >> and consistent structure eases audiences of various technical expertise
> >> into OpenStack, typically operators and users rather than developers.
> >> Although I'm not a fan of the word "product", increasingly less
> technical
> >> audiences are learning about OpenStack and tend to compare it with other
> >> cloud infrastructure products. Such audiences expect a coherent,
> relatively
> >> mature product to easily evaluate, usually via proof-of-concept. Upon
> >> deciding to implement OpenStack, the central documentation attempts to
> >> gracefully lead them toward a production deployment that meets or
> exceeds
> >> requirements and expectations.
> >>
> >> However, since I began contributing to OpenStack documentation around
> the
> >> Havana release, I am seeing many projects, particularly core projects,
> >> trending toward more independence from other projects including central
> >> documentation. For operator and user documentation, a couple of projects
> >> contribute to the central documentation repository, some projects
> >> contribute to their own repositories, and an alarmingly large number of
> >> projects simply do not contribute such documentation and assume that all
> >> audiences involve developers. These differences lead to an increasingly
> >> negative overall experience for the audiences that OpenStack needs to
> >> increase adoption/growth and maintain the existing deployment base.
> >>
> >> As a contributor to central documentation and one or more other projects
> >> including neutron, I see the problems from both sides and don't
> >> particularly blame either party for them. Some politics, some technical,
> >> some a lack of resources, and some just a general misunderstanding about
> >> documentation. However, I think we need to develop a solution that works
> >> for both parties and ultimately benefits our audiences.
> >>
> >> One potential solution essentially involves moving operator and user
> >> documentation into project repositories (similar to developer
> >> documentation) and using infrastructure to coherently present it on
> >> docs.openstack.org which achieves the following goals:
> >>
> >> 1) Project developers can contribute documentation and code in the same
> >> patch, thus avoiding two different review queues and reviewers with
> >> different motivations and guidelines.
> >> 2) Project developers can either work directly or via liaison with one
> or
> >> more documentation team members to improve documentation components
> during
> >> development or after merging technically accurate content.
> >> 3) Rather than attempting to document all projects with little (if any)
> >> assistance from those projects, the primary role of the documentation
> team
> >> becomes managing overall organization/presentation of documentation and
> >> assisting projects with their contributions.
> >>
> >> We're seeing decent adoption of moving API documentation into project
> >> repositories, so I want to initiate some discussion about moving
> additional
> >> documentation (or other options) prior to mid-cycles (including ops) and
> >> the next summit.
> >>
> >> Matt
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
>
>
> ------------------------------
>
> Message: 22
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.reports 1.12.0 release
>         (newton)
> Message-ID:
>         <mailman.21360.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are eager to announce the release of:
>
> oslo.reports 1.12.0: oslo.reports library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.reports
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.reports
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.reports
>
> For more details, please see below.
>
> Changes in oslo.reports 1.11.0..1.12.0
> --------------------------------------
>
> 4b37e30 Updated from global requirements
> 96fa66c Updated from global requirements
> 30cfeab Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> requirements.txt      | 2 +-
> test-requirements.txt | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 62f078c..67f73ae 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -11 +11 @@ oslo.i18n>=2.1.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index ff73ef3..a180841 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -10 +10 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> @@ -13 +13 @@ sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> -oslo.config>=3.10.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
>
>
>
>
>
> ------------------------------
>
> Message: 23
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.privsep 1.10.0 release
>         (newton)
> Message-ID:
>         <mailman.21361.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are content to announce the release of:
>
> oslo.privsep 1.10.0: OpenStack library for privilege separation
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.privsep
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.privsep
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.privsep
>
> For more details, please see below.
>
> Changes in oslo.privsep 1.9.0..1.10.0
> -------------------------------------
>
> e46eebf Updated from global requirements
> b5e1c13 Updated from global requirements
> 021c911 Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> requirements.txt      | 4 ++--
> test-requirements.txt | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index e77185a..1397b11 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -7,2 +7,2 @@ oslo.i18n>=2.1.0 # Apache-2.0
> -oslo.config>=3.10.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 634e4c1..b3deaba 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -12 +12 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 24
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.policy 1.12.0 release
>         (newton)
> Message-ID:
>         <mailman.21362.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are jazzed to announce the release of:
>
> oslo.policy 1.12.0: Oslo Policy library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.policy
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.policy
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.policy
>
> For more details, please see below.
>
> Changes in oslo.policy 1.11.0..1.12.0
> -------------------------------------
>
> cbb0824 Updated from global requirements
> d0d39a4 Updated from global requirements
> 202340c Fix mispelled method name in setup.cfg
> a7a51bc Updated from global requirements
> 7e114b6 Updated from global requirements
> 123c155 Imported Translations from Zanata
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> releasenotes/source/locale/en_GB/LC_MESSAGES/releasenotes.po | 9 ++++++---
> requirements.txt                                             | 4 ++--
> setup.cfg                                                    | 2 +-
> test-requirements.txt                                        | 4 ++--
> 4 files changed, 11 insertions(+), 8 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 7204ac2..09e1525 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -6 +6 @@ requests>=2.10.0 # Apache-2.0
> -oslo.config>=3.10.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
> @@ -9 +9 @@ oslo.serialization>=1.10.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index f4844ab..eb9c954 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -7 +7 @@ oslotest>=1.10.0 # Apache-2.0
> -requests-mock>=0.7.0 # Apache-2.0
> +requests-mock>=1.0 # Apache-2.0
> @@ -16 +16 @@ sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> -reno>=1.6.2 # Apache2
> +reno>=1.8.0 # Apache2
>
>
>
>
>
> ------------------------------
>
> Message: 25
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.serialization 2.11.0 release
>         (newton)
> Message-ID:
>         <mailman.21363.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are glad to announce the release of:
>
> oslo.serialization 2.11.0: Oslo Serialization library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.serialization
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.serialization
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.serialization
>
> For more details, please see below.
>
> Changes in oslo.serialization 2.10.0..2.11.0
> --------------------------------------------
>
> 7ad9a95 Updated from global requirements
> 5ee90fc Updated from global requirements
> 1ec85e9 Use {} instead of dict()
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> oslo_serialization/jsonutils.py | 4 ++--
> requirements.txt                | 2 +-
> test-requirements.txt           | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 6872a60..54901dd 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -13 +13 @@ msgpack-python>=0.4.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 0a065c6..0a0d3bf 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -10 +10 @@ netaddr!=0.7.16,>=0.7.12 # BSD
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 26
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.versionedobjects 1.13.0
>         release (newton)
> Message-ID:
>         <mailman.21364.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are glad to announce the release of:
>
> oslo.versionedobjects 1.13.0: Oslo Versioned Objects library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.versionedobjects
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.versionedobjects
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.versionedobjects
>
> For more details, please see below.
>
> Changes in oslo.versionedobjects 1.12.0..1.13.0
> -----------------------------------------------
>
> b6410fe Updated from global requirements
> c6eaf00 Imported Translations from Zanata
> e80ab96 JSON schema get_schema implementation for common fields
> cf2838f Updated from global requirements
> 92e7ac7 JSON schema generation for versioned objects
> cf28125 Extend test_hashes to allow extra info gathering
> f5fdfc2 Updated from global requirements
> 238fd19 Improved error message for Object.coerce
> 1500618 Imported Translations from Zanata
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> oslo_versionedobjects/base.py                      | 44 ++++++++++++++
> oslo_versionedobjects/fields.py                    | 42 +++++++++++++-
> oslo_versionedobjects/fixture.py                   |  4 +-
> .../LC_MESSAGES/oslo_versionedobjects-log-error.po | 18 ++++--
> .../LC_MESSAGES/oslo_versionedobjects-log-error.po | 18 ++++--
> requirements.txt                                   |  4 +-
> test-requirements.txt                              |  2 +-
> 10 files changed, 255 insertions(+), 15 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 52bdb85..7813946 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -6 +6 @@ oslo.concurrency>=3.8.0 # Apache-2.0
> -oslo.config>=3.10.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
> @@ -10 +10 @@ oslo.serialization>=1.10.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 64d87df..b30d301 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -9 +9 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 27
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.rootwrap 4.4.0 release
>         (newton)
> Message-ID:
>         <mailman.21365.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are gleeful to announce the release of:
>
> oslo.rootwrap 4.4.0: Oslo Rootwrap
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.rootwrap
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.rootwrap
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.rootwrap
>
> For more details, please see below.
>
> Changes in oslo.rootwrap 4.3.0..4.4.0
> -------------------------------------
>
> 3a70d2e Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> test-requirements.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index e4b24c3..65bf3d1 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -15 +15 @@ testtools>=1.4.0 # MIT
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 28
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.service 1.13.0 release
>         (newton)
> Message-ID:
>         <mailman.21366.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are eager to announce the release of:
>
> oslo.service 1.13.0: oslo.service library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.service
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.service
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.service
>
> For more details, please see below.
>
> Changes in oslo.service 1.12.0..1.13.0
> --------------------------------------
>
> 3f39b9b Updated from global requirements
> 6421273 Updated from global requirements
> 84b53e6 Updated from global requirements
> e7317d7 Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> requirements.txt      | 4 ++--
> test-requirements.txt | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 87352e2..83d22d4 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -9 +9 @@ monotonic>=0.6 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> @@ -11 +11 @@ oslo.concurrency>=3.8.0 # Apache-2.0
> -oslo.config>=3.10.0 # Apache-2.0
> +oslo.config>=3.12.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index d0b8e20..de31b9a 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -12 +12 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 29
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslotest 2.7.0 release (newton)
> Message-ID:
>         <mailman.21367.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are pleased to announce the release of:
>
> oslotest 2.7.0: Oslo test framework
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslotest
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslotest
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslotest
>
> For more details, please see below.
>
> Changes in oslotest 2.6.0..2.7.0
> --------------------------------
>
> a0eb134 Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> test-requirements.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index bfdb9ba..cecb61e 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -13 +13 @@ coverage>=3.6 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 30
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] taskflow 2.3.0 release (newton)
> Message-ID:
>         <mailman.21368.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are jazzed to announce the release of:
>
> taskflow 2.3.0: Taskflow structured state management library.
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/taskflow
>
> With package available at:
>
>     https://pypi.python.org/pypi/taskflow
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/taskflow/
>
> For more details, please see below.
>
> Changes in taskflow 2.2.0..2.3.0
> --------------------------------
>
> 0b198de Updated from global requirements
> 185830b remove unused LOG
> 6ca905c Fixes: typo error in comments
> ec99a02 Updated from global requirements
> 7422194 Fix some misspellings in the function name and descriptions
> 21aa375 Updated from global requirements
> 599b270 Add tests to verify kwargs behavior on revert validation
> 6e21e31 Make tests less dependent on transient state
> 0766397 Use the full 'get_execute_failures' vs the shortname
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> requirements.txt                                   |  2 +-
> taskflow/engines/action_engine/actions/retry.py    |  3 -
> taskflow/engines/action_engine/compiler.py         |  8 +--
> taskflow/engines/action_engine/engine.py           | 12 ++--
> taskflow/engines/action_engine/executor.py         |  3 -
> taskflow/engines/action_engine/process_executor.py |  2 +-
> taskflow/engines/base.py                           |  2 +-
> taskflow/examples/99_bottles.py                    |  2 +-
> taskflow/jobs/backends/impl_zookeeper.py           |  2 +-
> taskflow/jobs/base.py                              |  2 +-
> taskflow/patterns/graph_flow.py                    |  2 +-
> taskflow/persistence/backends/impl_memory.py       |  2 +-
> taskflow/persistence/models.py                     |  3 -
> taskflow/storage.py                                |  2 +-
> taskflow/types/failure.py                          |  8 +--
> taskflow/types/notifier.py                         |  4 +-
> taskflow/types/tree.py                             |  2 +-
> test-requirements.txt                              |  2 +-
> 22 files changed, 73 insertions(+), 65 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index af3db31..73819aa 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -44 +44 @@ automaton>=0.5.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index e57fda1..6606911 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -38 +38 @@ eventlet!=0.18.3,>=0.18.2 # MIT
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 31
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslosphinx 4.6.0 release (newton)
> Message-ID:
>         <mailman.21369.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are jubilant to announce the release of:
>
> oslosphinx 4.6.0: OpenStack Sphinx Extensions and Theme
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslosphinx
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslosphinx
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslosphinx
>
> For more details, please see below.
>
> Changes in oslosphinx 4.5.0..4.6.0
> ----------------------------------
>
> e2ded8e Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> test-requirements.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 506a68b..3ee4d7d 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -8 +8 @@ hacking<0.11,>=0.10.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 32
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] oslo.vmware 2.11.0 release
>         (newton)
> Message-ID:
>         <mailman.21370.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are delighted to announce the release of:
>
> oslo.vmware 2.11.0: Oslo VMware library
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/oslo.vmware
>
> With package available at:
>
>     https://pypi.python.org/pypi/oslo.vmware
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/oslo.vmware
>
> For more details, please see below.
>
> Changes in oslo.vmware 2.10.0..2.11.0
> -------------------------------------
>
> 421b41c Updated from global requirements
> 04ad3d8 Add a py35 tox venv for upcoming py35 support
> 7b04a56 Updated from global requirements
> c202eff Remove unnecessary properties from image-meta
> 029bc0a Updated from global requirements
> a4a74ab Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> oslo_vmware/image_transfer.py            | 8 +++++---
> requirements.txt                         | 4 ++--
> setup.cfg                                | 1 +
> test-requirements.txt                    | 2 +-
> tox.ini                                  | 2 +-
> 6 files changed, 14 insertions(+), 10 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index c952316..4f4f3a6 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -12 +12 @@ oslo.i18n>=2.1.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.15.0 # Apache-2.0
> @@ -18 +18 @@ lxml>=2.3 # BSD
> -suds-jurko>=0.6 # LGPL
> +suds-jurko>=0.6 # LGPLv3+
> diff --git a/test-requirements.txt b/test-requirements.txt
> index a40ffab..b8c2e46 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -25 +25 @@ sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> -reno>=1.6.2 # Apache2
> +reno>=1.8.0 # Apache2
>
>
>
>
>
> ------------------------------
>
> Message: 33
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] stevedore 1.16.0 release (newton)
> Message-ID:
>         <mailman.21371.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are overjoyed to announce the release of:
>
> stevedore 1.16.0: Manage dynamic plugins for Python applications
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/stevedore
>
> With package available at:
>
>     https://pypi.python.org/pypi/stevedore
>
> Please report issues through launchpad:
>
>     https://bugs.launchpad.net/python-stevedore
>
> For more details, please see below.
>
> Changes in stevedore 1.15.0..1.16.0
> -----------------------------------
>
> 1218ab6 Fix NamedExtensionManager fails when loading failing extension in
> order
> da83cd8 Remove irrelated output item
> e3d08ce Fix broken link about setuptools entry points
> 6f81f6f NamedExtensionManager: call a callback when some names cannot be
> found
> f33b810 Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> README.rst                               |  2 +-
> stevedore/named.py                       | 20 +++++++++++++++++++-
> test-requirements.txt                    |  2 +-
> 6 files changed, 62 insertions(+), 4 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index d59feb9..977194a 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -6 +6 @@ Pillow>=2.4.0 # PIL License
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
>
>
>
>
>
> ------------------------------
>
> Message: 34
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][oslo] tooz 1.41.0 release (newton)
> Message-ID:
>         <mailman.21372.1468439277.7714.openstack-dev at lists.openstack.org>
>
> We are jazzed to announce the release of:
>
> tooz 1.41.0: Coordination library for distributed systems.
>
> This release is part of the newton release series.
>
> With source available at:
>
>     http://git.openstack.org/cgit/openstack/tooz
>
> With package available at:
>
>     https://pypi.python.org/pypi/tooz
>
> Please report issues through launchpad:
>
>     http://bugs.launchpad.net/python-tooz/
>
> For more details, please see below.
>
> Changes in tooz 1.40.0..1.41.0
> ------------------------------
>
> 3541e7c File driver: properly handle Windows paths
> 6716456 Updated from global requirements
> 7ea400a Updated from global requirements
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> requirements.txt                |  2 +-
> setup.cfg                       | 46 +++++++++++++++----------------------
> tooz/drivers/file.py            | 17 +++++++++++++-
> 4 files changed, 85 insertions(+), 30 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index 826db66..a9cecef 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -14 +14 @@ futurist>=0.11.0 # Apache-2.0
> -oslo.utils>=3.11.0 # Apache-2.0
> +oslo.utils>=3.14.0 # Apache-2.0
>
>
>
>
>
> ------------------------------
>
> Message: 35
> Date: Wed, 13 Jul 2016 10:55:11 -0400
> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [release][ptl][all] newton-2 milestone
>         deadline 14     July
> Message-ID: <1468421604-sup-2300 at lrrr.local>
> Content-Type: text/plain; charset=UTF-8
>
> PTLs and release liaisons, please remember that 14 July is the
> deadline for proposing your second milestone tags for deliverables
> using the cycle-with-milestone release model during newton. Milestones
> are date-based, so if missing the deadline means missing the
> milestone.
>
> Doug
>
>
>
> ------------------------------
>
> Message: 36
> Date: Wed, 13 Jul 2016 17:10:20 +0200
> From: Markus Zoeller <mzoeller at linux.vnet.ibm.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [new][oslo] mox3 0.17.0 release (newton)
> Message-ID: <578659DC.9070902 at linux.vnet.ibm.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 13.07.2016 16:01, no-reply at openstack.org wrote:
> > We are tickled pink to announce the release of:
> >
>
> Whoever chooses the wording in these announcements, you're a genius!
>
>
> --
> Regards, Markus Zoeller (markus_z)
>
> > mox3 0.17.0: Mock object framework for Python
> >
> > This release is part of the newton release series.
> >
> > With source available at:
> >
> >     http://git.openstack.org/cgit/openstack/mox3
> >
> > With package available at:
> >
> >     https://pypi.python.org/pypi/mox3
> >
> > Please report issues through launchpad:
> >
> >     http://bugs.launchpad.net/python-mox3
> >
> > For more details, please see below.
> >
> > Changes in mox3 0.16.0..0.17.0
> > ------------------------------
> >
> > 2b58961 Updated from global requirements
> >
> >
> > Diffstat (except docs and test files)
> > -------------------------------------
> >
> > test-requirements.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >
> > Requirements updates
> > --------------------
> >
> > diff --git a/test-requirements.txt b/test-requirements.txt
> > index ad30fa2..df05b72 100644
> > --- a/test-requirements.txt
> > +++ b/test-requirements.txt
> > @@ -20 +20 @@ six>=1.9.0 # MIT
> > -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> > +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
>
>
> ------------------------------
>
> Message: 37
> Date: Wed, 13 Jul 2016 09:52:45 -0600
> From: Matt Kassawara <mkassawara at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] The future of OpenStack documentation
> Message-ID:
>         <CABA+jQqQ25_pVhar0vV5jZBrucYNppkhi6ktd+tC4kkug=
> W1EQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The configuration reference essentially uses a script to parse help strings
> from code in project repositories. Occasionally, the documentation team
> augments content beyond what the automation provides. However, these
> content augmentations, the script, and schedule for running the script
> belong to the documentation team. Moving control of these items to projects
> would likely yield a more robust configuration reference, particularly
> regarding nuances of each project.
>
> Speaking of help strings, I see a conflict between providing sufficient
> content and preventing bloat of example configuration files. At the last
> summit, I suggested implementing two types of help strings... one long and
> one short. The configuration reference pulls the long string and the
> configuration file generator pulls the short string. If this idea makes
> sense, moving the configuration reference to project repositories would
> potentially enable each project to implement such changes at its own pace.
>
> On Wed, Jul 13, 2016 at 8:11 AM, Markus Zoeller <
> mzoeller at linux.vnet.ibm.com
> > wrote:
>
> > On 11.07.2016 00:02, Steve Martinelli wrote:
> > > I personally like this solution, it seems much more scalable. This
> > follows
> > > the same pattern of the API docs (moving the content to project repos),
> > > which puts the onus back on the project team to maintain and create
> > > documentation. I'm also hoping this results in less duplication between
> > the
> > > guides and the keystone developer docs (the latter of which start to
> > stray
> > > from "developer" docs and begin to look like "user" docs.
> >
> > After reading this, the "configuration reference" comes to my mind.
> > Having the api-ref and the config-ref at one place, near the code, seems
> > logical to me. Nova put a lot of effort into providing valuable help
> > text for the config options in the last months. We should also make sure
> > that it will result in a good manual, which could be easier if it's
> > in-tree, near the code.
> >
> > --
> > Regards, Markus Zoeller (markus_z)
> >
> > > The folks that contribute to the keystone guides today would still be
> > very
> > > welcomed to continue to contribute once/if the switch is made.
> > >
> > > On Fri, Jul 8, 2016 at 5:02 PM, Matt Kassawara <mkassawara at gmail.com>
> > wrote:
> > >
> > >> Currently, OpenStack provides central documentation (primarily in the
> > >> openstack-manuals repository) for operators and users. The single
> > location
> > >> and consistent structure eases audiences of various technical
> expertise
> > >> into OpenStack, typically operators and users rather than developers.
> > >> Although I'm not a fan of the word "product", increasingly less
> > technical
> > >> audiences are learning about OpenStack and tend to compare it with
> other
> > >> cloud infrastructure products. Such audiences expect a coherent,
> > relatively
> > >> mature product to easily evaluate, usually via proof-of-concept. Upon
> > >> deciding to implement OpenStack, the central documentation attempts to
> > >> gracefully lead them toward a production deployment that meets or
> > exceeds
> > >> requirements and expectations.
> > >>
> > >> However, since I began contributing to OpenStack documentation around
> > the
> > >> Havana release, I am seeing many projects, particularly core projects,
> > >> trending toward more independence from other projects including
> central
> > >> documentation. For operator and user documentation, a couple of
> projects
> > >> contribute to the central documentation repository, some projects
> > >> contribute to their own repositories, and an alarmingly large number
> of
> > >> projects simply do not contribute such documentation and assume that
> all
> > >> audiences involve developers. These differences lead to an
> increasingly
> > >> negative overall experience for the audiences that OpenStack needs to
> > >> increase adoption/growth and maintain the existing deployment base.
> > >>
> > >> As a contributor to central documentation and one or more other
> projects
> > >> including neutron, I see the problems from both sides and don't
> > >> particularly blame either party for them. Some politics, some
> technical,
> > >> some a lack of resources, and some just a general misunderstanding
> about
> > >> documentation. However, I think we need to develop a solution that
> works
> > >> for both parties and ultimately benefits our audiences.
> > >>
> > >> One potential solution essentially involves moving operator and user
> > >> documentation into project repositories (similar to developer
> > >> documentation) and using infrastructure to coherently present it on
> > >> docs.openstack.org which achieves the following goals:
> > >>
> > >> 1) Project developers can contribute documentation and code in the
> same
> > >> patch, thus avoiding two different review queues and reviewers with
> > >> different motivations and guidelines.
> > >> 2) Project developers can either work directly or via liaison with one
> > or
> > >> more documentation team members to improve documentation components
> > during
> > >> development or after merging technically accurate content.
> > >> 3) Rather than attempting to document all projects with little (if
> any)
> > >> assistance from those projects, the primary role of the documentation
> > team
> > >> becomes managing overall organization/presentation of documentation
> and
> > >> assisting projects with their contributions.
> > >>
> > >> We're seeing decent adoption of moving API documentation into project
> > >> repositories, so I want to initiate some discussion about moving
> > additional
> > >> documentation (or other options) prior to mid-cycles (including ops)
> and
> > >> the next summit.
> > >>
> > >> Matt
> > >>
> > >>
> >
> __________________________________________________________________________
> > >> OpenStack Development Mailing List (not for usage questions)
> > >> Unsubscribe:
> > OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/4056b361/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 38
> Date: Wed, 13 Jul 2016 11:58:20 -0400
> From: David Moreau Simard <dms at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Making TripleO CI easier to
>         consume outside of TripleO CI
> Message-ID:
>         <
> CAH7C+PrNqB6WWDHKPZTybqS0eUmbQn-42Fa5wqcwVnjP16X67w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Jul 13, 2016 at 9:06 AM, Wesley Hayutin <whayutin at redhat.com>
> wrote:
> > We also considered ansible-galaxy and any of the ansible roles found in
> > github/redhat-openstack/ansible-role could be moved into galaxy.  Galaxy
> did
> > not end up meeting our requirements for installing the roles and we
> ended up
> > using python setuptools.  Some roles have specific config and playbooks
> that
> > need to be copied to a standard location and galaxy just did not do that
> > very well.
>
> What special requirements do you have around that ?
> I'm able to install roles both from git (zuul-cloner) and from
> ansible-galaxy just fine.
>
> - ansible-role-requirements.yml [1]
> - ansible-galaxy install [2]
> - ansible.cfg role path [3]
>
> Stuff doesn't necessarily need to be "uploaded" to galaxy.
> ansible-galaxy is really a glorified wrapper around git :)
>
> [1]:
> https://github.com/rdo-infra/weirdo/blob/master/ansible-role-requirements.yml
> [2]: https://github.com/rdo-infra/weirdo/blob/master/tox.ini#L26
> [3]:
> https://github.com/rdo-infra/weirdo/blob/master/playbooks/ansible.cfg#L9
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
>
> ------------------------------
>
> Message: 39
> Date: Wed, 13 Jul 2016 18:04:25 +0200
> From: Ricardo Carrillo Cruz <ricardo.carrillo.cruz at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Making TripleO CI easier to
>         consume outside of TripleO CI
> Message-ID:
>         <CADe0dKDZDxuT_7iEczugyt9yA1QZG2sEANQge7mmQ-jjTB=
> o+A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I concur, in infra we install roles from git repos.
> Those are defined in a yaml that are then feeded to ansible-galaxy tool:
>
> http://git.openstack.org/cgit/openstack-infra/system-config/tree/roles.yaml
>
> Regards
>
> 2016-07-13 17:58 GMT+02:00 David Moreau Simard <dms at redhat.com>:
>
> > On Wed, Jul 13, 2016 at 9:06 AM, Wesley Hayutin <whayutin at redhat.com>
> > wrote:
> > > We also considered ansible-galaxy and any of the ansible roles found in
> > > github/redhat-openstack/ansible-role could be moved into galaxy.
> Galaxy
> > did
> > > not end up meeting our requirements for installing the roles and we
> > ended up
> > > using python setuptools.  Some roles have specific config and playbooks
> > that
> > > need to be copied to a standard location and galaxy just did not do
> that
> > > very well.
> >
> > What special requirements do you have around that ?
> > I'm able to install roles both from git (zuul-cloner) and from
> > ansible-galaxy just fine.
> >
> > - ansible-role-requirements.yml [1]
> > - ansible-galaxy install [2]
> > - ansible.cfg role path [3]
> >
> > Stuff doesn't necessarily need to be "uploaded" to galaxy.
> > ansible-galaxy is really a glorified wrapper around git :)
> >
> > [1]:
> >
> https://github.com/rdo-infra/weirdo/blob/master/ansible-role-requirements.yml
> > [2]: https://github.com/rdo-infra/weirdo/blob/master/tox.ini#L26
> > [3]:
> > https://github.com/rdo-infra/weirdo/blob/master/playbooks/ansible.cfg#L9
> >
> > David Moreau Simard
> > Senior Software Engineer | Openstack RDO
> >
> > dmsimard = [irc, github, twitter]
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/fc1be016/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 40
> Date: Wed, 13 Jul 2016 12:12:24 -0400
> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] The future of OpenStack documentation
> Message-ID: <1468425854-sup-236 at lrrr.local>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Matt Kassawara's message of 2016-07-13 09:52:45 -0600:
> > The configuration reference essentially uses a script to parse help
> strings
> > from code in project repositories. Occasionally, the documentation team
> > augments content beyond what the automation provides. However, these
> > content augmentations, the script, and schedule for running the script
> > belong to the documentation team. Moving control of these items to
> projects
> > would likely yield a more robust configuration reference, particularly
> > regarding nuances of each project.
>
> oslo.config already includes support for showing option values in
> sphinx-processed documentation. See
> http://docs.openstack.org/developer/oslo.config/sphinxext.html for
> instructions on the directives, and
> http://docs.openstack.org/developer/oslo.messaging/opts.html for an
> example of what it looks like rendered into HTML. You could experiment
> with this the existing developer documentation and if project teams
> agree it makes sense we could start setting up a separate reference
> guide in each repo.
>
> OTOH, sometimes configuring an application actually requires dealing
> with a deliverable that is spread across multiple repositories.
> Which is why at the summit we discussed updating the config generator
> to produce a format that is easier to parse (YAML, probably) and
> then use those files to produce the central config reference guide
> (or multiple guides).  With a periodic job to propose patches to
> the guide repo, it could stay very close to up to date more or less
> automatically. Some of the other things I've been doing this cycle
> have delayed me starting on this, but I'm happy to share my ideas
> in more detail with anyone who wants to pick it up and work on it.
>
> > Speaking of help strings, I see a conflict between providing sufficient
> > content and preventing bloat of example configuration files. At the last
> > summit, I suggested implementing two types of help strings... one long
> and
> > one short. The configuration reference pulls the long string and the
> > configuration file generator pulls the short string. If this idea makes
> > sense, moving the configuration reference to project repositories would
> > potentially enable each project to implement such changes at its own
> pace.
> >
> > On Wed, Jul 13, 2016 at 8:11 AM, Markus Zoeller <
> mzoeller at linux.vnet.ibm.com
> > > wrote:
> >
> > > On 11.07.2016 00:02, Steve Martinelli wrote:
> > > > I personally like this solution, it seems much more scalable. This
> > > follows
> > > > the same pattern of the API docs (moving the content to project
> repos),
> > > > which puts the onus back on the project team to maintain and create
> > > > documentation. I'm also hoping this results in less duplication
> between
> > > the
> > > > guides and the keystone developer docs (the latter of which start to
> > > stray
> > > > from "developer" docs and begin to look like "user" docs.
> > >
> > > After reading this, the "configuration reference" comes to my mind.
> > > Having the api-ref and the config-ref at one place, near the code,
> seems
> > > logical to me. Nova put a lot of effort into providing valuable help
> > > text for the config options in the last months. We should also make
> sure
> > > that it will result in a good manual, which could be easier if it's
> > > in-tree, near the code.
> > >
> > > --
> > > Regards, Markus Zoeller (markus_z)
> > >
> > > > The folks that contribute to the keystone guides today would still be
> > > very
> > > > welcomed to continue to contribute once/if the switch is made.
> > > >
> > > > On Fri, Jul 8, 2016 at 5:02 PM, Matt Kassawara <mkassawara at gmail.com
> >
> > > wrote:
> > > >
> > > >> Currently, OpenStack provides central documentation (primarily in
> the
> > > >> openstack-manuals repository) for operators and users. The single
> > > location
> > > >> and consistent structure eases audiences of various technical
> expertise
> > > >> into OpenStack, typically operators and users rather than
> developers.
> > > >> Although I'm not a fan of the word "product", increasingly less
> > > technical
> > > >> audiences are learning about OpenStack and tend to compare it with
> other
> > > >> cloud infrastructure products. Such audiences expect a coherent,
> > > relatively
> > > >> mature product to easily evaluate, usually via proof-of-concept.
> Upon
> > > >> deciding to implement OpenStack, the central documentation attempts
> to
> > > >> gracefully lead them toward a production deployment that meets or
> > > exceeds
> > > >> requirements and expectations.
> > > >>
> > > >> However, since I began contributing to OpenStack documentation
> around
> > > the
> > > >> Havana release, I am seeing many projects, particularly core
> projects,
> > > >> trending toward more independence from other projects including
> central
> > > >> documentation. For operator and user documentation, a couple of
> projects
> > > >> contribute to the central documentation repository, some projects
> > > >> contribute to their own repositories, and an alarmingly large
> number of
> > > >> projects simply do not contribute such documentation and assume
> that all
> > > >> audiences involve developers. These differences lead to an
> increasingly
> > > >> negative overall experience for the audiences that OpenStack needs
> to
> > > >> increase adoption/growth and maintain the existing deployment base.
> > > >>
> > > >> As a contributor to central documentation and one or more other
> projects
> > > >> including neutron, I see the problems from both sides and don't
> > > >> particularly blame either party for them. Some politics, some
> technical,
> > > >> some a lack of resources, and some just a general misunderstanding
> about
> > > >> documentation. However, I think we need to develop a solution that
> works
> > > >> for both parties and ultimately benefits our audiences.
> > > >>
> > > >> One potential solution essentially involves moving operator and user
> > > >> documentation into project repositories (similar to developer
> > > >> documentation) and using infrastructure to coherently present it on
> > > >> docs.openstack.org which achieves the following goals:
> > > >>
> > > >> 1) Project developers can contribute documentation and code in the
> same
> > > >> patch, thus avoiding two different review queues and reviewers with
> > > >> different motivations and guidelines.
> > > >> 2) Project developers can either work directly or via liaison with
> one
> > > or
> > > >> more documentation team members to improve documentation components
> > > during
> > > >> development or after merging technically accurate content.
> > > >> 3) Rather than attempting to document all projects with little (if
> any)
> > > >> assistance from those projects, the primary role of the
> documentation
> > > team
> > > >> becomes managing overall organization/presentation of documentation
> and
> > > >> assisting projects with their contributions.
> > > >>
> > > >> We're seeing decent adoption of moving API documentation into
> project
> > > >> repositories, so I want to initiate some discussion about moving
> > > additional
> > > >> documentation (or other options) prior to mid-cycles (including
> ops) and
> > > >> the next summit.
> > > >>
> > > >> Matt
> > > >>
> > > >>
> > >
> __________________________________________________________________________
> > > >> OpenStack Development Mailing List (not for usage questions)
> > > >> Unsubscribe:
> > > OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
>
>
> ------------------------------
>
> Message: 41
> Date: Wed, 13 Jul 2016 16:45:53 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] focused review pipeline of bug fix
>         changes?
> Message-ID: <20160713164553.GJ2458 at yuggoth.org>
> Content-Type: text/plain; charset=us-ascii
>
> On 2016-07-13 09:56:37 +0200 (+0200), Sahid Orentino Ferdjaoui wrote:
> [...]
> > Gerrit comments are lost when the patch get merged, we may want to
> > provide some stats from these tags in future that's why I think commit
> > message is better.
>
> It's not true at all that Gerrit comments are lost when the patch
> gets merged. You can continue to query comments in Gerrit for merged
> changes, or even selectively limit to, e.g., status:merged or
> status:abandoned or whatever when generating your stats.
>
> > Also if we only change commit messages, all of the gate is
> > re-executed ?
> [...]
>
> It depends on your project configuration in Gerrit and Zuul as to
> whether votes are reset and which jobs are (re)run. We're also
> hoping to be able to detect commit message edits explicitly in a
> future version of Zuul and be able to have specific handling for
> that too (right now you're limited to deciding which jobs run based
> on filename patterns appearing in the diff instead).
> --
> Jeremy Stanley
>
>
>
> ------------------------------
>
> Message: 42
> Date: Wed, 13 Jul 2016 16:50:04 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] focused review pipeline of bug fix
>         changes?
> Message-ID: <20160713165003.GK2458 at yuggoth.org>
> Content-Type: text/plain; charset=us-ascii
>
> On 2016-07-13 13:35:18 +0200 (+0200), Markus Zoeller wrote:
> [...]
> > it cannot be used in "gerrty" though, or can it?
> [...]
>
> It's probably one or two more lines of code to also print the Gerrit
> query such that it could be pasted into Gertty ^O (or make use of
> `gertty --open` to trigger opening that query URL directly into a
> running Gertty session?).
> --
> Jeremy Stanley
>
>
>
> ------------------------------
>
> Message: 43
> Date: Wed, 13 Jul 2016 17:11:42 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all][oslo] pbr potential breaking change
>         coming
> Message-ID: <20160713171142.GL2458 at yuggoth.org>
> Content-Type: text/plain; charset=us-ascii
>
> On 2016-07-13 13:25:44 +0200 (+0200), Markus Zoeller wrote:
> > For some reason the gate docs job didn't find the issue (wrong json
> > format) which got fixed with change [1]. It doesn't even emit a warning.
> > Locally, the execution of "tox -e docs" does find the issue. Can we make
> > the gate docs job aware of such json format issues?
> [...]
>
> It looks like your "docs" tox env is doing some additional checks[1]
> with the json.tool module. The gate-{name}-docs CI jobs don't call
> `tox -e docs` but `tox -evenv -- python setup.py build_sphinx`
> directly[2]. Changing that has been discussed[3][4] (and
> rejected/withdrawn) by the TC in the past.
>
> I agree with Andreas that if you want additional checking of this
> you probably need it in a different job. The same goes for tests of
> your config/policy generation and API guide/reference builds. The
> goal of gate-{name}-docs is to make sure that the setup.py
> build_sphinx entrypoint works across all covered projects (per the
> CTI[5]) without requiring any extra nonstandard magic.
>
> [1]
> http://git.openstack.org/cgit/openstack/nova/tree/tox.ini?id=df0aa8a#n97
> [2]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/run-docs.sh
> [3]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-30-20.01.log.html#l-27
> [4] https://review.openstack.org/119875
> [5]
> http://governance.openstack.org/reference/cti/python_cti.html#documentation
> --
> Jeremy Stanley
>
>
>
> ------------------------------
>
> Message: 44
> Date: Wed, 13 Jul 2016 17:22:32 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [new][oslo] mox3 0.17.0 release (newton)
> Message-ID: <20160713172232.GM2458 at yuggoth.org>
> Content-Type: text/plain; charset=us-ascii
>
> On 2016-07-13 17:10:20 +0200 (+0200), Markus Zoeller wrote:
> > Whoever chooses the wording in these announcements, you're a genius!
>
> You too can be a genius--add some more--there's only ~20 at the
> moment so they repeat pretty often:
>
> <URL:
> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/releasetools/release_notes.py?id=da89264#n33
> >
> --
> Jeremy Stanley
>
>
>
> ------------------------------
>
> Message: 45
> Date: Wed, 13 Jul 2016 12:39:15 -0500
> From: Christopher Aedo <doc at aedo.net>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>,
>         openstack-operators at lists.openstack.org,  user-committee
>         <user-committee at lists.openstack.org>
> Subject: [openstack-dev] [app-catalog] App Catalog IRC meeting
>         Thursday July   14th
> Message-ID:
>         <CA+odVQGHay-pahhxiahdcyLvNe=
> Dun7MBpdne1xecjdt+rcw3Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Join us Thursday for our weekly meeting, scheduled for July 14th at
> 17:00UTC in #openstack-meeting-3
>
> The agenda can be found here, and please add to if you want to discuss
> something with the Community App Catalog team:
> https://wiki.openstack.org/wiki/Meetings/app-catalog
>
> Tomorrow we will be talking more about our plan to implement GLARE as
> a back-end for the Community App Catalog, and what we'll need to merge
> in the next few weeks to make this a reality.
>
> Hope to see you there tomorrow!
>
>
>
> ------------------------------
>
> Message: 46
> Date: Wed, 13 Jul 2016 17:46:13 +0000
> From: Jesse Pretorius <Jesse.Pretorius at rackspace.co.uk>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [openstack-ansible] Nominating
>         Jean-Philippe Evrard for core in openstack-ansible and all
>         openstack-ansible-* roles
> Message-ID: <96401D83-9561-4527-B1EC-CE817F598B86 at rackspace.co.uk>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> From: "Truman, Travis" <Travis_Truman at comcast.com<mailto:
> Travis_Truman at comcast.com>>
> Subject: [openstack-dev] [openstack-ansible] Nominating Jean-Philippe
> Evrard for core in openstack-ansible and all openstack-ansible-* roles
>
> Jean-Philippe has been providing great code reviews and patches for some
> time. His recent commitment to running bug triage every week shows his
> willingness to step up and take responsibilities within the community. He?s
> also found an opportunity to innovate by introducing an improved bug triage
> process. He can often be found in #openstack-ansible as evrardjp providing
> support to deployers in a welcoming and friendly manner.
>
> In short, just the kind of contribution our community desires from core
> reviewers.
>
> Very much agreed. +1 from me!
>
> ________________________________
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at abuse at rackspace.com and delete the
> original message. Your cooperation is appreciated.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/31e6b206/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 47
> Date: Wed, 13 Jul 2016 10:47:12 -0700
> From: Steve Lewis <stevelle at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [openstack-ansible] Nominating
>         Jean-Philippe Evrard for core in openstack-ansible and all
>         openstack-ansible-* roles
> Message-ID:
>         <
> CACuNDX9wacF_cfqrhSxzspGtU2BOYwZvFeS7eR3TYk-Ma1gqoA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Jul 12, 2016 at 11:33 AM, Truman, Travis <
> Travis_Truman at comcast.com>
> wrote:
>
> > In short, just the kind of contribution our community desires from core
> > reviewers.
> >
>
> I'm happy to add my +1.
>
> --
> SteveL
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/db80bf30/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 48
> Date: Wed, 13 Jul 2016 12:47:26 -0500
> From: "Carter, Kevin" <kevin at cloudnull.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [openstack-ansible] Nominating
>         Jean-Philippe Evrard for core in openstack-ansible and all
>         openstack-ansible-* roles
> Message-ID:
>         <CAAG3CGos_kbwqQ=
> EjHrjbiuwHXRcAwDbx5pUN-wEY1_vDTh2Pg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> +1 from me too. It'll be great to have him on the core team.
>
> On Tue, Jul 12, 2016 at 1:33 PM, Truman, Travis
> <Travis_Truman at comcast.com> wrote:
> > Jean-Philippe has been providing great code reviews and patches for some
> > time. His recent commitment to running bug triage every week shows his
> > willingness to step up and take responsibilities within the community.
> He?s
> > also found an opportunity to innovate by introducing an improved bug
> triage
> > process. He can often be found in #openstack-ansible as evrardjp
> providing
> > support to deployers in a welcoming and friendly manner.
> >
> > In short, just the kind of contribution our community desires from core
> > reviewers.
> >
> > Thanks for all that you do for the community Jean-Philippe,
> > Travis Truman
> >
> >
> >
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> ------------------------------
>
> Message: 49
> Date: Wed, 13 Jul 2016 17:49:35 +0000
> From: "Hayes, Graham" <graham.hayes at hpe.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [designate] Designate News Round Up
> Message-ID:
>         <
> CS1PR84MB02150DDAC09E88FC35985D9090310 at CS1PR84MB0215.NAMPRD84.PROD.OUTLOOK.COM
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi All,
>
> Just a quick update on a few things!
>
> Mid Cycle
> =========
>
> The Mid Cycle is confirmed for 22-26th of August.
>
> It will be in Dublin, in the city center.
>
> The address is
>
> 64 Mount Street Lower,
> Dublin 2.
> D02 TH77
> Ireland
>
> I will be updating the page on the wiki with local hotels
> over the next day or so, so keep an eye on
>
> https://wiki.openstack.org/wiki/Sprints/DesignateNewtonSprint
>
> This is a shared office space, so we will need to let people in
> as they arrive - my phone number is +353 87 377 8315
>
> Docs Sprint
> ===========
>
> Today's docs sprint went well, we have a few reviews outstanding, so if
> everyone could have a look at the following:
>
> # https://review.openstack.org/#/c/341622/
> # https://review.openstack.org/#/c/341614/
> # https://review.openstack.org/#/c/341583/
> # https://review.openstack.org/#/c/341672/
>
>
> Project Mascot
> ==============
>
> The foundation has kindly offered to create mascots for each project.
>
> Can everyone put ideas in the etherpad:
>
>         https://etherpad.openstack.org/p/designate-mascot
>
> And if you see an idea you like, stick a "+" beside it.
>
> We will take the top few ideas and pass them to the foundation.
>
> Thanks!
>
> - Graham
>
>
>
> ------------------------------
>
> Message: 50
> Date: Wed, 13 Jul 2016 13:03:36 -0500
> From: Jimmy McCrory <jimmy.mccrory at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [openstack-ansible] Nominating
>         Jean-Philippe Evrard for core in openstack-ansible and all
>         openstack-ansible-* roles
> Message-ID:
>         <CAG9FQbb+t8Fi6Tn3VJ4B0U5heJC88df7mR11_NWJ3gS6P=
> rXJw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1, would make a great addition.
>
> On Wed, Jul 13, 2016 at 12:47 PM, Carter, Kevin <kevin at cloudnull.com>
> wrote:
>
> > +1 from me too. It'll be great to have him on the core team.
> >
> > On Tue, Jul 12, 2016 at 1:33 PM, Truman, Travis
> > <Travis_Truman at comcast.com> wrote:
> > > Jean-Philippe has been providing great code reviews and patches for
> some
> > > time. His recent commitment to running bug triage every week shows his
> > > willingness to step up and take responsibilities within the community.
> > He?s
> > > also found an opportunity to innovate by introducing an improved bug
> > triage
> > > process. He can often be found in #openstack-ansible as evrardjp
> > providing
> > > support to deployers in a welcoming and friendly manner.
> > >
> > > In short, just the kind of contribution our community desires from core
> > > reviewers.
> > >
> > > Thanks for all that you do for the community Jean-Philippe,
> > > Travis Truman
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/a9bd1f61/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 51
> Date: Wed, 13 Jul 2016 22:17:59 +0300
> From: Denis Makogon <lildee1991 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all] Status of the OpenStack port to
>         Python 3
> Message-ID:
>         <CALzSdt=
> XV01jzBX1YgMMwHcnEd3vB_zSPiUr6P4YLpORgvNHvg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello to All.
>
>
> I have free capacity to work on porting code to Py3. So, if any PTL is
> running out of team capacity i can help to work on project to enable Py3
> support.
>
> Kind regards,
> Denys Makogon
>
>
> 2016-07-06 13:01 GMT+03:00 Flavio Percoco <flavio at redhat.com>:
>
> > On 24/06/16 12:17 -0400, Sean Dague wrote:
> >
> >> On 06/24/2016 11:48 AM, Doug Hellmann wrote:
> >>
> >>> Excerpts from Dmitry Tantsur's message of 2016-06-24 10:59:14 +0200:
> >>>
> >>>> On 06/23/2016 11:21 PM, Clark Boylan wrote:
> >>>>
> >>>>> On Thu, Jun 23, 2016, at 02:15 PM, Doug Hellmann wrote:
> >>>>>
> >>>>>> Excerpts from Thomas Goirand's message of 2016-06-23 23:04:28 +0200:
> >>>>>>
> >>>>>>> On 06/23/2016 06:11 PM, Doug Hellmann wrote:
> >>>>>>>
> >>>>>>>> I'd like for the community to set a goal for Ocata to have Python
> >>>>>>>> 3 functional tests running for all projects.
> >>>>>>>>
> >>>>>>>> As Tony points out, it's a bit late to have this as a priority for
> >>>>>>>> Newton, though work can and should continue. But given how close
> >>>>>>>> we are to having the initial phase of the port done (thanks
> >>>>>>>> Victor!),
> >>>>>>>> and how far we are from discussions of priorities for Ocata, it
> >>>>>>>> seems very reasonable to set a community-wide goal for our next
> >>>>>>>> release cycle.
> >>>>>>>>
> >>>>>>>> Thoughts?
> >>>>>>>>
> >>>>>>>> Doug
> >>>>>>>>
> >>>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> Just think about it for a while. If we get Nova to work with Py3,
> and
> >>>>>>> everything else is working, including all functional tests in
> >>>>>>> Tempest,
> >>>>>>> then after Otaca, we could even start to *REMOVE* Py2 support after
> >>>>>>> Otaca+1. That would be really awesome to stop all the compat layer
> >>>>>>> madness and use the new features available in Py3.
> >>>>>>>
> >>>>>>
> >>>>>> We'll need to get some input from other distros and from deployers
> >>>>>> before we decide on a timeline for dropping Python 2. For now, let's
> >>>>>> focus on making Python 3 work. Then we can all rejoice while having
> >>>>>> the
> >>>>>> discussion of how much longer to support Python 2. :-)
> >>>>>>
> >>>>>>
> >>>>>>> I really would love to ship a full stack running Py3 for Debian
> >>>>>>> Stretch.
> >>>>>>> However, for this, it'd be super helful to have as much visibility
> as
> >>>>>>> possible. Are we setting a hard deadline for the Otaca release? Or
> is
> >>>>>>> this just a goal we only "would like" to reach, but it's not
> really a
> >>>>>>> big deal if we don't reach it?
> >>>>>>>
> >>>>>>
> >>>>>> Let's see what PTLs have to say about planning, but I think if not
> >>>>>> Ocata then we'd want to set one for the P release. We're running
> >>>>>> out of supported lifetime for Python 2.7.
> >>>>>>
> >>>>>
> >>>>> Keep in mind that there is interest in running OpenStack on PyPy
> which
> >>>>> is python 2.7. We don't have to continue supporting CPython 2.7
> >>>>> necessarily but we may want to support python 2.7 by way of PyPy.
> >>>>>
> >>>>
> >>>> PyPy folks have been working on python 3 support for some time
> already:
> >>>> http://doc.pypy.org/en/latest/release-pypy3.3-v5.2-alpha1.html
> >>>> It's an alpha, but by the time we consider dropping Python 2 it will
> >>>> probably be released :)
> >>>>
> >>>
> >>> We're targeting Python >=3.4, right now.  We'll have to decide as
> >>> a community whether PyPy support is a sufficient reason to keep
> >>> support for "older" versions (either 2.x or earlier versions of 3).
> >>> Before we can have that discussion, though, we need to actually run on
> >>> Python 3, so let's focus on that and evaluate the landscape of other
> >>> interpreters when the porting work is done.
> >>>
> >>
> >> +1, please don't get ahead of things until there is real full stack
> >> testing running on python3.
> >>
> >> It would also be good if some of our operators were running on python 3
> >> and providing feedback that it works in the real world before we even
> >> talk about dropping. Because our upstream testing (even the full stack
> >> testing) only can catch so much.
> >>
> >> So next steps:
> >>
> >> 1) full stack testing of everything we've got on python3 - (are there
> >> volunteers to get that going?)
> >> 2) complete Nova port to enable full stack testing on python3 for iaas
> >> base
> >> 3) encourage operators to deploy with python3 in production
> >> 4) gather real world feedback, develop rest of plan
> >>
> >
> >
> > Just one to +1 the above steps. I'd be very hesitant to make any plan
> > until we
> > are able to get not only nova but all the projects in the
> > starter-kit:compute[0]
> > running pn python3 (and w/ a full stack test).
> >
> > [0]
> > https://governance.openstack.org/reference/tags/starter-kit_compute.html
> >
> >
> > Flavio
> >
> > --
> > @flaper87
> > Flavio Percoco
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/1cb6173c/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 52
> Date: Wed, 13 Jul 2016 19:38:03 +0000
> From: "Watanabe, Isao" <watanabe_isao at jp.fujitsu.com>
> To: "openstack-dev at lists.openstack.org"
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Cinder][CI] Rule of recheck keywords has
>         been    updated
> Message-ID: <AC0F94DB49C0C2439892181E6CDA6E6C173917D4 at G01JPEXMBYT05>
> Content-Type: text/plain; charset="iso-2022-jp"
>
> Hello Cinder Third-Party CI Maintainers,
>
> The rule of recheck keywords has been discussed in today's IRC meeting [1].
> And the wiki [2] of tested-3rdParty-drivers has been updated.
> # The diff is [3].
>
> Please check the update and update your CI.
> It would be appreciated if you could also update the "Recheck trigger"
> information in your CI's wiki.
> You can find your CI's wiki pages at [4].
>
> [1]
> http://eavesdrop.openstack.org/meetings/cinder/2016/cinder.2016-07-13-16.00.log.html
> [2]
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#How_do_I_trigger_my_CI_to_rerun_on_gerrit_comments.3F
> [3]
> https://wiki.openstack.org/w/index.php?title=Cinder/tested-3rdParty-drivers&curid=3690&diff=128050&oldid=126774
> [4] https://wiki.openstack.org/wiki/ThirdPartySystems
>
> Best regards,
> Watanabe.isao
>
>
>
>
>
> ------------------------------
>
> Message: 53
> Date: Wed, 13 Jul 2016 14:47:53 -0500
> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [nova] Let's kill quota classes (again)
> Message-ID: <9a418d72-2ce1-970a-11e2-53b5472739d0 at linux.vnet.ibm.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> We got a bug that the os-quota-class-sets API isn't documented:
>
> https://bugs.launchpad.net/nova/+bug/1602400
>
> That's probably because we hate it and no one understands it.
>
> See this previous thread about trying to sort this out from the long
> long ago:
>
> https://lists.launchpad.net/openstack/msg12200.html
>
> We tried killing it before, but it turns out, it's actually used by
> something!
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-May/036031.html
>
> But we didn't have integration testing in Tempest for default quotas at
> that time (we added those tests in when we reverted the delete of the
> API back in Juno).
>
> I got looking at this because of the quota_class attribute in the nova
> RequestContext:
>
>
> https://github.com/openstack/nova/blob/93cc5e3ffd2867bdb39a707a230c1efc6ed2f5f4/nova/context.py#L138-L141
>
> That led me to markmc's thread about that only being there for the
> turnstile project and some old API rate limiting stuff that Rackspace
> was doing out of tree (it appears to set a type of middleware for a
> quota class for rate limiting).
>
> Anyway, super duper out of tree stuff that is probably not even used
> anymore (Vek - if you're reading, please speak up).
>
> I'll also point out that API rate limiting as a paste config was only in
> the v2 API and that code was all dropped and the API rate limiting stuff
> wasn't carried over for the v2.1 API, for good reason, see:
>
>
> http://lists.openstack.org/pipermail/openstack-operators/2016-June/010692.html
>
> You can still create unique quota classes via the os-quota-class-sets
> API (it does a create if the update operation fails), but as far as I
> can tell you can't really use those in any meaningful way.
>
> We really just have the 'default' quota class with a buttload of code
> and plumbing to use that, which sucks, because it's all very complicated.
>
> So I think I'm going to start a pet project of rooting this stuff out
> again, starting with nova.context.RequestContext.quota_class, unless
> anyone has a good reason we should keep this in tree.
>
> I think we should also add a microversion to the API in Ocata to disable
> the ability to create new quota classes, so that update is only update,
> and a 404 for anything else.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> End of OpenStack-dev Digest, Vol 51, Issue 26
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160714/9dc3bf09/attachment-0001.html>


More information about the OpenStack-dev mailing list