[openstack-dev] [Tricircle] Queens PTL candidacy
Dongfeng Huang
dfhuangg at gmail.com
Sat Aug 5 10:03:28 UTC 2017
+1
best regards,
Dongfeng Huang
2017-08-03 4:50 GMT+08:00 <openstack-dev-request at lists.openstack.org>:
> 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: [SPAM] [all][docs] recruiting for help with documentation
> tools (Thierry Carrez)
> 2. Re: [Cinder] Requirements for re-adding Gluster support
> (Niels de Vos)
> 3. [cinder] Apply for exception to having Storwize cinder
> Tiramisu replication patch reviewed and merged (Xiao Qin SH Li)
> 4. Re: [SPAM] [all][docs] recruiting for help with documentation
> tools (Doug Hellmann)
> 5. Re: [all][docs] recruiting for help with documentation tools
> (Doug Hellmann)
> 6. Re: [all][docs] recruiting for help with documentation tools
> (Doug Hellmann)
> 7. [requirements][release][docs] FFE for openstack-doc-tools
> (Andreas Jaeger)
> 8. [Tricircle] Queens PTL candidacy (Vega Cai)
> 9. [release][requirements] FFE release for reno 2.5.0 (Doug Hellmann)
> 10. Re: [release][requirements] FFE release for reno 2.5.0
> (Thierry Carrez)
> 11. [watcher] nominate Aditi Sharma to Watcher Core group
> (Чадин Александр (Alexander Chadin))
> 12. Re: [release][requirements] FFE release for reno 2.5.0
> (Tony Breeds)
> 13. [elections] [puppet] Candidacy for Puppet OpenStack PTL
> (Queens) (Mohammed Naser)
> 14. Re: [requirements][release][docs] FFE for openstack-doc-tools
> (Tony Breeds)
> 15. Fwd: ETSI NFV - OpenStack PTG in Denver (Ildiko Vancsa)
> 16. [elections][tripleo] Queens PTL candidacy (Alex Schultz)
> 17. [oslo][barbican][sahara] start RPC service before launcher
> wait? (Ken Giusti)
> 18. [all] Only 40 days to PTG ! (Thierry Carrez)
> 19. Re: [all] Only 40 days to PTG ! (Davanum Srinivas)
> 20. Re: [elections][tripleo] Queens PTL candidacy
> (Arkady.Kanevsky at dell.com)
> 21. [nova][docs] Concerns with docs migration (Matt Riedemann)
> 22. Re: [cinder] Apply for exception to having Storwize cinder
> Tiramisu replication patch reviewed and merged (Sean McGinnis)
> 23. Re: Trying again on wait_for_compute in devstack (Matt Riedemann)
> 24. Re: [devstack] [ironic] [nova] Trying again on
> wait_for_compute in devstack (Sean Dague)
> 25. [keystone][policy] no policy meeting today 2017-08-02
> (Lance Bragstad)
> 26. Re: Trying again on wait_for_compute in devstack (Matt Riedemann)
> 27. Re: [nova][docs] Concerns with docs migration (Stephen Finucane)
> 28. Re: [nova][docs] Concerns with docs migration (Stephen Finucane)
> 29. [trove] Can we move some non-voting broken jobs to the
> experimental queue? (Matt Riedemann)
> 30. Re: [nova][docs] Concerns with docs migration (Chris Friesen)
> 31. Re: [nova][docs] Concerns with docs migration (Chris Dent)
> 32. Re: [nova][docs] Concerns with docs migration (Stephen Finucane)
> 33. Re: [nova][docs] Concerns with docs migration (Doug Hellmann)
> 34. Re: [nova][docs] Concerns with docs migration (Akihiro Motoki)
> 35. Re: [nova][docs] Concerns with docs migration (Akihiro Motoki)
> 36. Re: [nova][docs] Concerns with docs migration (Doug Hellmann)
> 37. Re: [tripleo] Proposing Bogdan Dobrelya core on TripleO /
> Containers (Carlos Camacho Gonzalez)
> 38. [all] Rollout of Zuul v3 at the PTG (Monty Taylor)
> 39. Re: [nova][docs] Concerns with docs migration (Clark Boylan)
> 40. Re: [nova][docs] Concerns with docs migration (Stephen Finucane)
> 41. Re: [Tacker] Proposing yanxingan for Tacker core
> (Sridhar Ramaswamy)
> 42. Re: [nova][docs] Concerns with docs migration (Mathieu Gagné)
> 43. Re: [OpenStack-Ansible] Not running for Queens PTL
> (Lance Bragstad)
> 44. string freeze exception for VMAX driver (Walsh, Helen)
> 45. Re: [release][requirements] FFE release for reno 2.5.0
> (Matthew Thode)
> 46. Re: [requirements][release][docs] FFE for openstack-doc-tools
> (Matthew Thode)
> 47. Re: [nova][docs] Concerns with docs migration (Sean Dague)
> 48. Re: [nova][docs] Concerns with docs migration (Sean Dague)
> 49. Re: [nova][docs] Concerns with docs migration
> (Anne Gentle | Just Write Click)
> 50. Re: [requirements][release][docs] FFE for openstack-doc-tools
> (Andreas Jaeger)
> 51. [kolla][PTL][elections] Candidacy for Kolla PTL
> (Michał Jastrzębski)
> 52. [refstack][interop-wg] Non-candidacy for RefStack PTL
> (Catherine Cuong Diep)
> 53. Re: [nova][docs] Concerns with docs migration (Dean Troyer)
> 54. Re: [nova][docs] Concerns with docs migration (Clark Boylan)
> 55. Re: [openstack-ansible][security] To firewalld, or not to
> firewalld (Major Hayden)
> 56. [searchlight] Cancelling IRC meeting August 2nd
> (McLellan, Steven)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 2 Aug 2017 14:01:47 +0200
> From: Thierry Carrez <thierry at openstack.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [SPAM] [all][docs] recruiting for help
> with documentation tools
> Message-ID: <53030039-def1-a070-2ae9-7da26d8a9dec at openstack.org>
> Content-Type: text/plain; charset=utf-8
>
> Doug Hellmann wrote:
> > [...]
> > The areas we need help are maintaining the doc build jobs, the
> > sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,
> > and the template build tool in the openstack-manuals git repo. These
> > are all minimally complete, but there is definitely feature work
> > and bug fixing to do. I can guarantee that, if you sign up to help,
> > you will have a chance to land changes that will be visible for all
> > OpenStack users. At the start of Queens, I will be doing some
> > one-on-one training with volunteers to ensure they understand the
> > system we have in place now and help them start on some of the
> > remaining feature work.
> > [...]
> Feels like the doc owners/liaisons that we are looking for in the Top 5
> help wanted list[1] would be in a good position to help with that.
> Should we extend the description of the need so that it's clearer that
> help with maintaining the doc toolchain is also a top wanted thing ?
>
> [1]
> https://governance.openstack.org/tc/reference/top-5-help-
> wanted.html#documentation-owners
>
> --
> Thierry Carrez (ttx)
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 2 Aug 2017 14:04:15 +0200
> From: Niels de Vos <ndevos at redhat.com>
> To: openstack-dev at lists.openstack.org
> Cc: integration at gluster.org
> Subject: Re: [openstack-dev] [Cinder] Requirements for re-adding
> Gluster support
> Message-ID: <20170802120415.GF21449 at ndevos-x240.usersys.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> Thanks to everyone who replied! I'll try to summarize what we'll try to
> get from the Gluster Community users that run OpenStack.
>
> - find an owner/maintainer for the Gluster driver in Cinder
> little maintenance seems needed, no recent problems reported
>
> - get someone to maintain the gate job(s) in a CI environment of their
> own choosing (OpenStack Infra, Gluster Community, CentOS CI, ..)
>
> - send a patch to revert the change for removing the driver from Cinder
>
> - send a patch to revert the change for removing the driver from Nova
>
>
> With these tasks I'll try to find some of the OpenStack users in the
> Gluster Community that want to volunteer for this. There are a few
> Gluster developers (from Red Hat) that can assist these volunteers, but
> developers working for Red Hat will not have this as a priority. It
> falls in the "support the Gluster Community" bucket, and community users
> will need to do most of the work. This is similar for any of the other
> Open Source projects where Gluster is not productized by Red Hat.
>
> A similar approach by Red Hat developers working on Cinder caused the
> volume driver to be removed. We hope that interested users will step up
> and offer their time.
>
> Please let me know if I missed something or if this approach is
> unacceptible or unclear.
>
> Cheers,
> Niels
>
>
> On Wed, Jul 26, 2017 at 12:56:55PM +0200, Niels de Vos wrote:
> > Hello,
> >
> > In one of the last Cinder releases support for Gluster has been dropped.
> > The commit message [1] mentions that the support has been marked
> > deprecated during Newton.
> >
> > It seems that there are quite some users in the Gluster Community that
> > run OpenStack with Gluster storage. These users did not take action when
> > Newton came out, but voiced their disappointment with more recent
> > releases.
> >
> > As one of the Gluster Maintainers that is watching over the integration
> > of Gluster in other projects, I would like to know more about the tasks
> > that it takes to get Gluster support back into Cinder. With those
> > details, the Gluster Community can work with interested OpenStack users
> > to add required CI jobs, and possibly other things.
> >
> > At the moment, the only knowledge I have on why Gluster support was
> > removed from Cinder is in a messy email conversation [2]. Pointers to
> > further clarifications and requirements that Gluster did not meet are
> > welcome.
> >
> > My current guess is that adding a 3rd party CI [3] for Gluster is the
> > only missing piece? If that is the case, I expect that we could add one
> > or more Jenkins jobs to one of our Gluster Community CI's. We run tests
> > in our own Jenkins instance [4], but also use the CentOS CI [5] for some
> > heavier testing.
> >
> > Any guidance, suggestions and opinions are most welcome!
> >
> > Many thanks,
> > Niels
> >
> >
> > 1. https://github.com/openstack/cinder/commit/
> 16e93ccd4f3a6d62ed9d277f03b64bccc63ae060
> > 2. http://lists.gluster.org/pipermail/integration/2017-May/000024.html
> > 3. https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
> > 4. https://build.gluster.org/
> > 5. https://ci.centos.org/view/Gluster/
> >
> > ____________________________________________________________
> ______________
> > 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: 3
> Date: Wed, 2 Aug 2017 12:07:06 +0000
> From: "Xiao Qin SH Li" <lixqin at cn.ibm.com>
> To: openstack-dev at lists.openstack.org
> Cc: Yi Ming YZ Zhang <zymzhang at cn.ibm.com>
> Subject: [openstack-dev] [cinder] Apply for exception to having
> Storwize cinder Tiramisu replication patch reviewed and merged
> Message-ID:
> <OF24EF5DB8.BFD02DA7-ON00258170.00425B94-00258170.
> 004291A9 at notes.na.collabserv.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/10a6a8c2/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 02 Aug 2017 08:17:47 -0400
> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [SPAM] [all][docs] recruiting for help
> with documentation tools
> Message-ID: <1501676214-sup-1408 at lrrr.local>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Thierry Carrez's message of 2017-08-02 14:01:47 +0200:
> > Doug Hellmann wrote:
> > > [...]
> > > The areas we need help are maintaining the doc build jobs, the
> > > sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,
> > > and the template build tool in the openstack-manuals git repo. These
> > > are all minimally complete, but there is definitely feature work
> > > and bug fixing to do. I can guarantee that, if you sign up to help,
> > > you will have a chance to land changes that will be visible for all
> > > OpenStack users. At the start of Queens, I will be doing some
> > > one-on-one training with volunteers to ensure they understand the
> > > system we have in place now and help them start on some of the
> > > remaining feature work.
> > > [...]
> > Feels like the doc owners/liaisons that we are looking for in the Top 5
> > help wanted list[1] would be in a good position to help with that.
> > Should we extend the description of the need so that it's clearer that
> > help with maintaining the doc toolchain is also a top wanted thing ?
> >
> > [1]
> > https://governance.openstack.org/tc/reference/top-5-help-
> wanted.html#documentation-owners
> >
>
> I'm torn on that. On the one hand, I would like to recruit. On the
> other, we do need far more content contributors than tool maintainers.
> Let's wait and see. There were 2 responses to this thread already, so
> maybe we won't need to go that far.
>
> Doug
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 02 Aug 2017 08:18:58 -0400
> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all][docs] recruiting for help with
> documentation tools
> Message-ID: <1501676296-sup-129 at lrrr.local>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Swapnil Kulkarni's message of 2017-08-02 14:35:49 +0530:
> > On Wed, Aug 2, 2017 at 2:25 PM, Bogdan Dobrelya <bdobreli at redhat.com>
> wrote:
> > > On 01.08.2017 21:35, Doug Hellmann wrote:
> > >> With the changes we've made to docs processes upstream, every team
> > >> is going to need to build up their knowledge of how the new
> > >> documentation tools and jobs work. The docs team will still help,
> > >> but things will obviously go more smoothly if folks know how the
> > >> tools work, now that the bulk of the content is in-tree with the
> > >> code.
> > >>
> > >> At the same time, the docs team could use help with developing and
> > >> maintaining those tools. We have a couple people working on them
> > >> now (me, Andreas, and Anne), but none of us is doing it full time.
> > >> I need to transition off of this work, so over the course of Queens
> > >> I will be trying to build up the skills of the existing team so
> > >> they do not need to rely on me so much. Also, Andreas and Anne have
> > >> said that they cannot commit to driving any work.
> > >>
> > >> Although the documentation team has some skills in this area, they
> > >> could use help, so I would like to find a few people to join the
> > >> team specifically to work on the tooling (although if you wanted
> > >> to write documentation, too, no one will object).
> > >>
> > >> Some of you have been helping informally (thank you!), but the
> > >> community shift is big enough that we need to account for the new
> > >> need a bit more formally. I think if we could find several people
> > >> who could give a small percentage of their time (10%?), we would
> > >> be well covered. There will not be work every week, but when there
> > >> is something to do it's likely to take a small extended period (1-2
> > >> days) to add a feature or resolve an issue. If we found 4-6 people,
> > >> I think we would be covered and have a sustainable group.
> > >>
> > >> The areas we need help are maintaining the doc build jobs, the
> > >> sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,
> > >> and the template build tool in the openstack-manuals git repo. These
> > >> are all minimally complete, but there is definitely feature work
> > >> and bug fixing to do. I can guarantee that, if you sign up to help,
> > >> you will have a chance to land changes that will be visible for all
> > >> OpenStack users. At the start of Queens, I will be doing some
> > >> one-on-one training with volunteers to ensure they understand the
> > >> system we have in place now and help them start on some of the
> > >> remaining feature work.
> > >>
> > >> If you are interested in helping, please let me know by following
> > >> up to this thread, and then join #openstack-docs on IRC.
> > >
> > > +1
> > >
> > >>
> > >> Doug
> > >>
> > >> ____________________________________________________________
> ______________
> > >> 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
> > >>
> > >
> > >
> > > --
> > > Best regards,
> > > Bogdan Dobrelya,
> > > Irc #bogdando
> > >
> > > ____________________________________________________________
> ______________
> > > 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
> >
> >
> > +1
> >
>
> Thanks, Bogdan and Swapnil, I'm happy to have you on board!
>
> Doug
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 02 Aug 2017 08:20:53 -0400
> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all][docs] recruiting for help with
> documentation tools
> Message-ID: <1501676408-sup-9756 at lrrr.local>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Doug Hellmann's message of 2017-08-01 15:35:35 -0400:
> > With the changes we've made to docs processes upstream, every team
> > is going to need to build up their knowledge of how the new
> > documentation tools and jobs work. The docs team will still help,
> > but things will obviously go more smoothly if folks know how the
> > tools work, now that the bulk of the content is in-tree with the
> > code.
> >
> > At the same time, the docs team could use help with developing and
> > maintaining those tools. We have a couple people working on them
> > now (me, Andreas, and Anne), but none of us is doing it full time.
> > I need to transition off of this work, so over the course of Queens
> > I will be trying to build up the skills of the existing team so
> > they do not need to rely on me so much. Also, Andreas and Anne have
> > said that they cannot commit to driving any work.
> >
> > Although the documentation team has some skills in this area, they
> > could use help, so I would like to find a few people to join the
> > team specifically to work on the tooling (although if you wanted
> > to write documentation, too, no one will object).
> >
> > Some of you have been helping informally (thank you!), but the
> > community shift is big enough that we need to account for the new
> > need a bit more formally. I think if we could find several people
> > who could give a small percentage of their time (10%?), we would
> > be well covered. There will not be work every week, but when there
> > is something to do it's likely to take a small extended period (1-2
> > days) to add a feature or resolve an issue. If we found 4-6 people,
> > I think we would be covered and have a sustainable group.
> >
> > The areas we need help are maintaining the doc build jobs, the
> > sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,
> > and the template build tool in the openstack-manuals git repo. These
> > are all minimally complete, but there is definitely feature work
> > and bug fixing to do. I can guarantee that, if you sign up to help,
> > you will have a chance to land changes that will be visible for all
> > OpenStack users. At the start of Queens, I will be doing some
> > one-on-one training with volunteers to ensure they understand the
> > system we have in place now and help them start on some of the
> > remaining feature work.
> >
> > If you are interested in helping, please let me know by following
> > up to this thread, and then join #openstack-docs on IRC.
> >
> > Doug
> >
>
> If you want an idea of the sorts of work ahead, check out the tracking
> pad: https://etherpad.openstack.org/p/doc-future-problems
>
> Not everything on that list is related to the tools, but quite a lot is.
>
> Doug
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 2 Aug 2017 14:22:35 +0200
> From: Andreas Jaeger <aj at suse.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [requirements][release][docs] FFE for
> openstack-doc-tools
> Message-ID: <68048723-5543-20d4-07d3-43ec21ee8bd2 at suse.com>
> Content-Type: text/plain; charset="utf-8"
>
> We need a new release of openstack-doc-tools to handle the changed
> behaviour in how we build documents.
>
> The tool is only used by documentation projects for building and nowhere
> else listed in requirements file.
>
> Please release this and take the new version in for requirements repo,
>
> https://review.openstack.org/490001
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 02 Aug 2017 12:30:00 +0000
> From: Vega Cai <luckyvega.g at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Tricircle] Queens PTL candidacy
> Message-ID:
> <CAN33iADM-NHMW8nf0AtJZ1Z8Ep32TO4=G8KPSqT
> CuK2CHDqYGg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> I would like to announce my self nomination for the PTL candidacy in
> Tricircle Queens cycle. My name is Zhiyuan Cai, and my IRC handle is
> zhiyuan. As a core reviewer of Tricircle project, I have been actively
> participating in the development of this project since Mitaka cycle.
>
> During the Pike cycle, many fancy features are brought to Tricircle, like
> VxLAN support for cross Neutron L2/L3 networking, VLAN aware VMs, service
> function chaining; reliability and performance are improved for the
> asynchronous job running daemon; multi-region gate job is set up to test
> Tricircle in a real running OpenStack environment, a YAML based task schema
> is introduced to help developers to define the test scenario more easily.
>
> For the coming Queens cycle, here are some works we can focus on:
>
> * Continue the development of advanced networking features, like QoS and
> LBaaS.
> * Improve the test scenario coverage of multi-region gate job.
> * Examine the integration with Nova cell V2.
>
> Hope everyone will enjoy running and developing Tricircle.
>
> Thank you for your kind consideration of my candidacy.
>
> Best Regards
> Zhiyuan
> --
> BR
> Zhiyuan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/65d95aa3/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 02 Aug 2017 08:39:07 -0400
> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [release][requirements] FFE release for reno
> 2.5.0
> Message-ID: <1501677350-sup-3895 at lrrr.local>
> Content-Type: text/plain; charset=UTF-8
>
> We have a few projects that have modified stable branch release
> notes by editing the files on master, which makes those notes appear
> as part of the current release. Reno has a new option to address
> that problem by ignoring some note files, and I would like to release
> that version to allow project teams to fix up their release notes
> for pike. I really thought I had already released that update, so
> I'm sorry for the late request.
>
> Reno is only used during release notes builds, but it does appear
> in the global requirements list and constraints list. I think the
> risk is minimal.
>
> https://review.openstack.org/489998
>
> Doug
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 2 Aug 2017 14:41:57 +0200
> From: Thierry Carrez <thierry at openstack.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [release][requirements] FFE release for
> reno 2.5.0
> Message-ID: <12fdd660-5260-7ea8-ad63-0a1cbd63d7d7 at openstack.org>
> Content-Type: text/plain; charset=utf-8
>
> Doug Hellmann wrote:
> > We have a few projects that have modified stable branch release
> > notes by editing the files on master, which makes those notes appear
> > as part of the current release. Reno has a new option to address
> > that problem by ignoring some note files, and I would like to release
> > that version to allow project teams to fix up their release notes
> > for pike. I really thought I had already released that update, so
> > I'm sorry for the late request.
> >
> > Reno is only used during release notes builds, but it does appear
> > in the global requirements list and constraints list. I think the
> > risk is minimal.
> >
> > https://review.openstack.org/489998
>
> Sounds like something we should fix before release rather than after, so
> +2 from me.
>
> --
> Thierry Carrez (ttx)
>
>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 2 Aug 2017 12:47:38 +0000
> From: Чадин Александр (Alexander Chadin)
> <a.chadin at servionica.ru>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [watcher] nominate Aditi Sharma to Watcher
> Core group
> Message-ID: <2EA26395-C5FA-4E5B-A8D6-8349543ABA56 at servionica.ru>
> Content-Type: text/plain; charset="utf-8"
>
> Aditi Sharma (adisky in IRC) has been working on OpenStack Watcher since
> this March
> and has done some valuable patches[1] along with Action Plan cancelling
> blueprint (spec and
> implementation have been merged).
> I’d like to nominate Aditi Sharma to Watcher Core group and waiting for
> your vote.
> Please, give +1/-1 in reply to this message.
>
> [1] : https://review.openstack.org/#/q/owner:%22aditi+sharma+%253Caditi.s%
> 2540nectechnologies.in%253E%22
>
> Best Regards,
> ______________
> Alexander Chadin
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/4714f608/attachment-0001.html>
>
> ------------------------------
>
> Message: 12
> Date: Wed, 2 Aug 2017 23:18:19 +1000
> From: Tony Breeds <tony at bakeyournoodle.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [release][requirements] FFE release for
> reno 2.5.0
> Message-ID: <20170802131818.GB22339 at thor.bakeyournoodle.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Aug 02, 2017 at 08:39:07AM -0400, Doug Hellmann wrote:
> > We have a few projects that have modified stable branch release
> > notes by editing the files on master, which makes those notes appear
> > as part of the current release. Reno has a new option to address
> > that problem by ignoring some note files, and I would like to release
> > that version to allow project teams to fix up their release notes
> > for pike. I really thought I had already released that update, so
> > I'm sorry for the late request.
> >
> > Reno is only used during release notes builds, but it does appear
> > in the global requirements list and constraints list. I think the
> > risk is minimal.
> >
> > https://review.openstack.org/489998
>
> Package : reno [reno!=2.3.1,>=1.8.0] (used by 220 projects)
> Also affects : 220 projects
> <snip>
>
> So yeah it *could* destabalise the gate for a day if there is an issue.
> I'm not saying that's likely but it has happened in the past.
>
> Looking at the reno change log I don't see anything that worries me.
>
> From a requirements POV I'm +2 on a u-c bump -2 on a g-r bump.
>
> Yours Tony.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 488 bytes
> Desc: not available
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/1f37021c/attachment-0001.sig>
>
> ------------------------------
>
> Message: 13
> Date: Wed, 2 Aug 2017 09:19:31 -0400
> From: Mohammed Naser <mnaser at vexxhost.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [elections] [puppet] Candidacy for Puppet
> OpenStack PTL (Queens)
> Message-ID:
> <CAEs876jzt4dStXL07mhn1Z--VLGAOVwEdrcN2KidydmOn6H_GA@
> mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hey everyone,
>
> I would like to nominate myself for the PTL role for the Puppet OpenStack
> team
> for the Queens release cycle.
>
> I have been directly involved with OpenStack as a deployer and contributor
> since 2011. I have also personally used the Puppet OpenStack modules for a
> significant period of time in that period and I personally believe that
> they
> are one of the more robust and stable deployment methods of OpenStack.
>
> I'm very comfortable in terms of dealing with gate issues, Puppet and the
> OpenStack puppet modules specifically. I'm also confident that I can
> quickly
> get up to speed in PTL activities such as managing releases and other
> responsibilities.
>
> The Puppet OpenStack modules are quite stable for the projects which have
> been around for a long time, such as Nova or Neutron which doesn't leave a
> lot
> of work. However, for the Queens cycle, I believe the following goals are
> what
> I am to help accomplish:
>
> - Improve documentation to increase adoption of Puppet OpenStack
> - Add CI for modules which are not currently tested in
> `puppet-openstack-integration`
> which will increase their maturity.
> - Ensure modules stay up to date with service configuration settings
> - Optimize CI to check for any deprecated configuration warnings to be
> able to
> catch configuration changes earlier.
>
> I'm always available on IRC and I look forward to working with all of you
> for
> the upcoming cycle. I'm also always open to suggestions or recommendation
> on
> how we can do things better, as this is for the benefit of all of us.
>
> Sincerely,
> Mohammed Naser (mnaser)
>
>
>
> ------------------------------
>
> Message: 14
> Date: Wed, 2 Aug 2017 23:28:07 +1000
> From: Tony Breeds <tony at bakeyournoodle.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [requirements][release][docs] FFE for
> openstack-doc-tools
> Message-ID: <20170802132807.GC22339 at thor.bakeyournoodle.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Aug 02, 2017 at 02:22:35PM +0200, Andreas Jaeger wrote:
> > We need a new release of openstack-doc-tools to handle the changed
> > behaviour in how we build documents.
> >
> > The tool is only used by documentation projects for building and nowhere
> > else listed in requirements file.
> >
> > Please release this and take the new version in for requirements repo,
> >
> > https://review.openstack.org/490001
>
>
> I've posted a list of consumers to that review and we've confirmed that
> none of them have managed requirements.
>
> So from a requiremenmts POV I'm okay with a u-u bump here but I'm not
> 100% certain it's needed. We can sort that out tomorrow ;P
>
> Yours Tony.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 488 bytes
> Desc: not available
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/fe6c10d4/attachment-0001.sig>
>
> ------------------------------
>
> Message: 15
> Date: Wed, 2 Aug 2017 15:30:40 +0200
> From: Ildiko Vancsa <ildiko.vancsa at gmail.com>
> To: openstack-dev at lists.openstack.org, user-committee
> <user-committee at lists.openstack.org>
> Cc: Tetsuya Nakamura <t.nakamura at cablelabs.com>
> Subject: [openstack-dev] Fwd: ETSI NFV - OpenStack PTG in Denver
> Message-ID: <3253BF0B-0AE4-474C-86F5-2A9340749437 at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi All,
>
> I was kindly asked by Tetsuya (in cc) to help him distribute the
> information about an ETSI NFV tutorial & workshop that might be relevant to
> your work and therefore you might be interested in joining.
>
> You can find more information on the wiki page linked below.
>
> Please reach out to Tetsuya or respond to this mail thread in case you
> have any questions.
>
> Thanks and Best Regards,
> Ildikó
>
>
> > Begin forwarded message:
> >
> > Dear OpenStack folks,
> >
> > Let me introduce the ETSI NFV Tutorial & Specfest(Hackfest) event on
> September 11th in Denver downtown.
> >
> > During the ETSI NFV-ISG meeting in Denver, we would plan a special
> tutorial & specfest event on Monday, September 11th, which introduces and
> hacks on the latest ETSI NFV API specifications, VNF Package, Descriptors,
> OpenAPI, etc. Anyone can join the event without registration to the ETSI
> NFV meeting. It is free of charge. The details are in the ETSI NFV public
> wiki page:
> > https://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial
> >
> > Please come and join.
> >
> > Best Regards,
> > Tetsuya Nakamura, CableLabs,
> > Vice Chair, ETSI NFV-ISG,
> > t.nakamura at cablelabs.com
> >
>
>
>
>
> ------------------------------
>
> Message: 16
> Date: Wed, 2 Aug 2017 07:56:06 -0600
> From: Alex Schultz <aschultz at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [elections][tripleo] Queens PTL candidacy
> Message-ID:
> <CAFsb3b4FdNayHFvO7UKFj2O6-fzq3rsqFu2OYS+vEpzyi-CORQ@
> mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I would like to nominate myself for the TripleO PTL role for the Queens
> cycle.
>
> I have been a contributor to various OpenStack projects since Liberty. I
> have
> spent most of my time working on the deployment of OpenStack and with the
> engineers who deploy it. As many of you know, I believe the projects we
> work
> on should simplify workflows and improve the end user's lives. During my
> time
> as Puppet OpenStack PTL, I have promoted efforts to simplify and
> establishing
> reusable patterns and best practices. I feel confident that TripleO is on
> the
> right path and hope to continue to lead it in the right direction.
>
> For the last few cycles we have moved TripleO forwards and improved not
> only
> TripleO itself, but have provided additional tooling around deploying and
> managing OpenStack. As we look forward to the Queens cycle, it is imporant
> to recognize the work we have done and can continue to improve on.
>
> * Improving deployment of containerized services.
> We started the effort to switch over to containerized services being
> deployed
> with TripleO as part of the Pike cycle and we need to finalize the last
> few
> services. As we start the transition to including Kubernetes, we need to
> be
> mindful of the transition and make sure we evaluate and leverage already
> existing solutions.
> * Continue making the deployers' lives easier.
> The recent cycles have been full of efforts to allow users to do more
> with
> TripleO. With the work to expose composable roles, composable networks
> and
> containerization we have added additional flexibility for the deployment
> engineers to be able to build out architectures needed for the end user.
> That being said, there are still efforts to be done to make the
> deployment
> process less error prone and more user friendly.
> * Continued improvement of CI
> The process to transition over to tripleo-quickstart has made excellent
> progress over the last few cycles. We need to continue to refine the
> steps
> to ensure that Developers can reuse the work and be able to quickly and
> easily troubleshoot when things break down. Additionally we need to make
> sure that we can classify repeated failures and work to address them
> quickly
> as to not hold up bugs and features.
> * Improve visibility of the project status
> As part of the Queens cycle, I would like to devote some time into
> capturing
> metrics and information about the status of the various projects under
> the
> TripleO umbrella. We've been doing lots of work but it I think it would
> be
> beneficial for us to know where this work has been occurring. I'm hoping
> to
> work on some of the reporting around the status of our CI, bugs and
> reviews
> to be able to see where we could use some more efforts to hopefully
> improve
> our development velocities.
>
> Thanks,
> Alex Schultz
> irc: mwhahaha
>
>
>
> ------------------------------
>
> Message: 17
> Date: Wed, 2 Aug 2017 10:02:09 -0400
> From: Ken Giusti <kgiusti at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [oslo][barbican][sahara] start RPC service
> before launcher wait?
> Message-ID:
> <CAJoCO=Ps1hTki6EHW546V+ab+XCxUwE8gJHEM5ETCYWnom+rsA@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Oop - didn't reply all
> ---------- Forwarded message ----------
> From: Ken Giusti <kgiusti at gmail.com>
> Date: Tue, Aug 1, 2017 at 12:51 PM
> Subject: Re: [openstack-dev] [oslo][barbican][sahara] start RPC service
> before launcher wait?
> To: Adam Spiers <aspiers at suse.com>
>
>
> Hi Adam,
>
> I think there's a couple of problems here.
>
> Regardless of worker count, the service.wait() is called before
> service.start(). And from looking at the oslo.service code, the 'wait()'
> method is call after start(), then again after stop(). This doesn't match
> up with the intended use of oslo.messaging.server.wait(), which should only
> be called after .stop().
>
> Perhaps a bigger issue is that in the multi threaded case all threads
> appear to be calling start, wait, and stop on the same instance of the
> service (oslo.messaging rpc server). At least that's what I'm seeing in my
> muchly reduced test code:
>
> https://paste.fedoraproject.org/paste/-73zskccaQvpSVwRJD11cA
>
> The log trace shows multiple calls to start, wait, stop via different
> threads to the same TaskServer instance:
>
> https://paste.fedoraproject.org/paste/dyPq~lr26sQZtMzHn5w~Vg
>
> Is that expected?
>
> On Mon, Jul 31, 2017 at 9:32 PM, Adam Spiers <aspiers at suse.com> wrote:
>
> > Ken Giusti <kgiusti at gmail.com> wrote:
> >
> >> On Mon, Jul 31, 2017 at 10:01 AM, Adam Spiers <aspiers at suse.com> wrote:
> >>
> >>> I recently discovered a bug where barbican-worker would hang on
> >>> shutdown if queue.asynchronous_workers was changed from 1 to 2:
> >>>
> >>> https://bugs.launchpad.net/barbican/+bug/1705543
> >>>
> >>> resulting in a warning like this:
> >>>
> >>> WARNING oslo_messaging.server [-] Possible hang: stop is waiting for
> >>> start to complete
> >>>
> >>> I found a similar bug in Sahara:
> >>>
> >>> https://bugs.launchpad.net/sahara/+bug/1546119
> >>>
> >>> where the fix was to call start() on the RPC service before making the
> >>> launcher wait() on it, so I ported the fix to Barbican, and it seems
> >>> to work fine:
> >>>
> >>> https://review.openstack.org/#/c/485755
> >>>
> >>> I noticed that both projects use ProcessLauncher; barbican uses
> >>> oslo_service.service.launch() which has:
> >>>
> >>> if workers is None or workers == 1:
> >>> launcher = ServiceLauncher(conf, restart_method=restart_method)
> >>> else:
> >>> launcher = ProcessLauncher(conf, restart_method=restart_method)
> >>>
> >>> However, I'm not an expert in oslo.service or oslo.messaging, and one
> >>> of Barbican's core reviewers (thanks Kaitlin!) noted that not many
> >>> other projects start the task before calling wait() on the launcher,
> >>> so I thought I'd check here whether that is the correct fix, or
> >>> whether there's something else odd going on.
> >>>
> >>> Any oslo gurus able to shed light on this?
> >>>
> >>
> >> As far as an oslo.messaging server is concerned, the order of operations
> >> is:
> >>
> >> server.start()
> >> # do stuff until ready to stop the server...
> >> server.stop()
> >> server.wait()
> >>
> >> The final wait blocks until all requests that are in progress when
> stop()
> >> is called finish and cleanup.
> >>
> >
> > Thanks - that makes sense. So the question is, why would
> > barbican-worker only hang on shutdown when there are multiple workers?
> > Maybe the real bug is somewhere in oslo_service.service.ProcessLauncher
> > and it's not calling start() correctly?
> >
>
>
>
> --
> Ken Giusti (kgiusti at gmail.com)
>
>
>
> --
> Ken Giusti (kgiusti at gmail.com)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/7fd66d76/attachment-0001.html>
>
> ------------------------------
>
> Message: 18
> Date: Wed, 2 Aug 2017 16:33:09 +0200
> From: Thierry Carrez <thierry at openstack.org>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [all] Only 40 days to PTG !
> Message-ID: <106b91dc-1912-7010-9d31-e7d5da686dcc at openstack.org>
> Content-Type: text/plain; charset=utf-8
>
> Hi everyone,
>
> Time flies, and we are just 40 days from the Project Teams Gathering in
> Denver. Time for a few reminders!
>
>
> 1/ Registration
>
> If you haven't registered yet, you should do so[1] ASAP. Beyond securing
> your slot to the event, it helps us planning for rooms and lunches based
> on your days of attendance.
>
> [1] https://queensptg.eventbrite.com/
>
>
> 2/ Travel support program
>
> If you'd like to come join your project team in Denver but need
> financial help, our Travel Support Program[2] is still open. However the
> deadline for applications is *this Sunday, August 6*, so don't forget to
> apply in time !
>
> [2] https://openstackfoundation.formstack.com/forms/
> travelsupportptg_denver
>
>
> 3/ Visa
>
> If you need a visa, it's getting pretty late to go through the whole
> process in time for the event. Let us know ASAP if you need an
> invitation letter[3] !
>
> [3] https://openstackfoundation.formstack.com/forms/visa_form_denver_ptg
>
>
> 4/ Event layout
>
> We are still finalizing the list of teams and rooms that will meet at
> the event[4]. As previously announced, this time the week is split in
> the following way:
>
> - Monday/Tuesday: inter-team discussions on specific themes: workgroup
> discussions, help desks from various support teams, discussions for
> teams relying on liaisons like Oslo / Horizon / Docs, release goals
> hacking rooms...
>
> - Wednesday-Thursday-Friday: discussions within each project team to
> coordinate the Queens work, solve pressing issues and start getting
> things done
>
> [4]
> https://docs.google.com/spreadsheets/u/1/d/1xmOdT6uZ5XqViActr5sBOaz_
> mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312&single=true
>
>
> Let me know if you have any question. You can also ask questions on
> #openstack-ptg, or contact the events team at ptg at openstack.org.
>
> --
> Thierry Carrez (ttx)
>
>
>
> ------------------------------
>
> Message: 19
> Date: Wed, 2 Aug 2017 10:38:03 -0400
> From: Davanum Srinivas <davanum at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all] Only 40 days to PTG !
> Message-ID:
> <CANw6fcEPa33zCTMOg1C57H9SCaWochY+tz2EuR+XgR=-7pO6Ww at mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> May be good to point out to new folks, the etherpads for discussions are
> here:
> https://wiki.openstack.org/wiki/PTG/Queens/Etherpads
>
> Thanks,
> Dims
>
> On Wed, Aug 2, 2017 at 10:33 AM, Thierry Carrez <thierry at openstack.org>
> wrote:
> > Hi everyone,
> >
> > Time flies, and we are just 40 days from the Project Teams Gathering in
> > Denver. Time for a few reminders!
> >
> >
> > 1/ Registration
> >
> > If you haven't registered yet, you should do so[1] ASAP. Beyond securing
> > your slot to the event, it helps us planning for rooms and lunches based
> > on your days of attendance.
> >
> > [1] https://queensptg.eventbrite.com/
> >
> >
> > 2/ Travel support program
> >
> > If you'd like to come join your project team in Denver but need
> > financial help, our Travel Support Program[2] is still open. However the
> > deadline for applications is *this Sunday, August 6*, so don't forget to
> > apply in time !
> >
> > [2] https://openstackfoundation.formstack.com/forms/
> travelsupportptg_denver
> >
> >
> > 3/ Visa
> >
> > If you need a visa, it's getting pretty late to go through the whole
> > process in time for the event. Let us know ASAP if you need an
> > invitation letter[3] !
> >
> > [3] https://openstackfoundation.formstack.com/forms/visa_form_denver_ptg
> >
> >
> > 4/ Event layout
> >
> > We are still finalizing the list of teams and rooms that will meet at
> > the event[4]. As previously announced, this time the week is split in
> > the following way:
> >
> > - Monday/Tuesday: inter-team discussions on specific themes: workgroup
> > discussions, help desks from various support teams, discussions for
> > teams relying on liaisons like Oslo / Horizon / Docs, release goals
> > hacking rooms...
> >
> > - Wednesday-Thursday-Friday: discussions within each project team to
> > coordinate the Queens work, solve pressing issues and start getting
> > things done
> >
> > [4]
> > https://docs.google.com/spreadsheets/u/1/d/1xmOdT6uZ5XqViActr5sBOaz_
> mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312&single=true
> >
> >
> > Let me know if you have any question. You can also ask questions on
> > #openstack-ptg, or contact the events team at ptg at openstack.org.
> >
> > --
> > Thierry Carrez (ttx)
> >
> > ____________________________________________________________
> ______________
> > 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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
>
>
> ------------------------------
>
> Message: 20
> Date: Wed, 2 Aug 2017 14:46:52 +0000
> From: <Arkady.Kanevsky at dell.com>
> To: <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [elections][tripleo] Queens PTL candidacy
> Message-ID:
> <d6bc872ab12f46bd94671b57e7fb5e04 at AUSX13MPS308.AMER.DELL.COM>
> Content-Type: text/plain; charset="utf-8"
>
> +1
>
> -----Original Message-----
> From: Alex Schultz [mailto:aschultz at redhat.com]
> Sent: Wednesday, August 02, 2017 8:56 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [elections][tripleo] Queens PTL candidacy
>
> I would like to nominate myself for the TripleO PTL role for the Queens
> cycle.
>
> I have been a contributor to various OpenStack projects since Liberty. I
> have spent most of my time working on the deployment of OpenStack and with
> the engineers who deploy it. As many of you know, I believe the projects
> we work on should simplify workflows and improve the end user's lives.
> During my time as Puppet OpenStack PTL, I have promoted efforts to simplify
> and establishing reusable patterns and best practices. I feel confident
> that TripleO is on the right path and hope to continue to lead it in the
> right direction.
>
> For the last few cycles we have moved TripleO forwards and improved not
> only TripleO itself, but have provided additional tooling around deploying
> and managing OpenStack. As we look forward to the Queens cycle, it is
> imporant to recognize the work we have done and can continue to improve on.
>
> * Improving deployment of containerized services.
> We started the effort to switch over to containerized services being
> deployed
> with TripleO as part of the Pike cycle and we need to finalize the last
> few
> services. As we start the transition to including Kubernetes, we need to
> be
> mindful of the transition and make sure we evaluate and leverage already
> existing solutions.
> * Continue making the deployers' lives easier.
> The recent cycles have been full of efforts to allow users to do more
> with
> TripleO. With the work to expose composable roles, composable networks
> and
> containerization we have added additional flexibility for the deployment
> engineers to be able to build out architectures needed for the end user.
> That being said, there are still efforts to be done to make the
> deployment
> process less error prone and more user friendly.
> * Continued improvement of CI
> The process to transition over to tripleo-quickstart has made excellent
> progress over the last few cycles. We need to continue to refine the
> steps
> to ensure that Developers can reuse the work and be able to quickly and
> easily troubleshoot when things break down. Additionally we need to make
> sure that we can classify repeated failures and work to address them
> quickly
> as to not hold up bugs and features.
> * Improve visibility of the project status
> As part of the Queens cycle, I would like to devote some time into
> capturing
> metrics and information about the status of the various projects under
> the
> TripleO umbrella. We've been doing lots of work but it I think it would
> be
> beneficial for us to know where this work has been occurring. I'm hoping
> to
> work on some of the reporting around the status of our CI, bugs and
> reviews
> to be able to see where we could use some more efforts to hopefully
> improve
> our development velocities.
>
> Thanks,
> Alex Schultz
> irc: mwhahaha
>
> __________________________________________________________________________
> 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: 21
> Date: Wed, 2 Aug 2017 09:55:02 -0500
> From: Matt Riedemann <mriedemos at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <4c4a613b-b162-0746-b068-238b5ba6a1b4 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Now that Stephen Finucane is back from enjoying his youth and
> gallivanting all over Europe, and we talked about a few things in IRC
> this morning on the docs migration for Nova, I wanted to dump my
> concerns here for broader consumption.
>
> 1. We know we have to fix a bunch of broken links by adding in redirects
> [1] which sdague started here [2]. However, that apparently didn't catch
> everything, e.g. [3], so I'm concerned we're missing other broken links.
> Is there a way to find out?
>
> 2. The bottom change in the docs migration series for Nova is a massive
> refactor of the layout of the Nova devref [4]. That's something I don't
> want to do in Pike for two reasons:
>
> a) It's a huge change and we simply don't have the time to invest in
> properly assessing and reviewing it before Pike RC1.
>
> b) I think that if we're going to refactor the Nova devref home page to
> be a certain format, then we should really consider doing the same thing
> in the other projects, because today they are all different formats
> [5][6][7]. This is likely a cross-project discussion for the Queens PTG
> to determine if the home page for the projects should look similar. It
> seems they should given the uniformity that the Foundation has been
> working toward lately.
>
> 3. The patch for the import of the admin guide [8] is missing some CLI
> specific pages which are pretty useful given they aren't documented
> anywhere else, like the forced_host part of the compute API [9].
> Basically anything that's cli-nova-* in the admin guide should be in the
> Nova docs. It's also missing the compute-flavors page [10] which is
> pretty important for using OpenStack at all.
>
> 4. Similar to #3, but we don't have a patch yet for importing the user
> guide and there are several docs in the user guide that are Nova
> specific so I'd like to make sure we include those, like [11][12].
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120418.html
> [2] https://review.openstack.org/#/c/489650/
> [3] https://review.openstack.org/#/c/489641/
> [4] https://review.openstack.org/#/c/478485/
> [5] https://docs.openstack.org/cinder/latest/
> [6] https://docs.openstack.org/glance/latest/
> [7] https://docs.openstack.org/neutron/latest/
> [8] https://review.openstack.org/#/c/477497/
> [9]
> https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/admin-guide/source/cli-nova-specify-host.rst
> [10]
> https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/admin-guide/source/compute-flavors.rst
> [11]
> https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/user-guide/source/cli-launch-instances.rst
> [12]
> https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/user-guide/source/cli-delete-an-instance.rst
>
> --
>
> Thanks,
>
> Matt
>
>
>
> ------------------------------
>
> Message: 22
> Date: Wed, 2 Aug 2017 09:57:56 -0500
> From: Sean McGinnis <sean.mcginnis at gmx.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Cc: Yi Ming YZ Zhang <zymzhang at cn.ibm.com>
> Subject: Re: [openstack-dev] [cinder] Apply for exception to having
> Storwize cinder Tiramisu replication patch reviewed and merged
> Message-ID: <20170802145756.GA10718 at cooler>
> Content-Type: text/plain; charset=us-ascii
>
> This patch was Workflow-1 until after the feature freeze date.
> At this point I think we will need to wait until Queens opens
> up to get this through.
>
> Sean
>
> On Wed, Aug 02, 2017 at 12:07:06PM +0000, Xiao Qin SH Li wrote:
> > <div class="socmaildefaultfont" dir="ltr" style="font-family:Arial,
> Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont"
> dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt"
> ><div dir="ltr" > </div>
> > <div dir="ltr" ><div dir="ltr" >Hi all,</div>
> > <div dir="ltr" > </div>
> > <div dir="ltr" >There is a Tiramisu replication patch for IBM storwize
> cinder <a href="https://review.openstack.org/#/c/469394" rel="noopener"
> target="_blank" >https://review.openstack.org/#/c/469394</a>. Since it is
> already passed Pike-3, the deadline for new features. We would like to
> check if there's a chance to get an exception to have it reviewed and
> merged?</div>
> > <div dir="ltr" > </div>
> > <div dir="ltr" >Thanks a lot!</div></div>
> > <div dir="ltr" ><div class="socmaildefaultfont" dir="ltr"
> style="font-family:Arial;font-size:10.5pt" ><div
> class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt"
> ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt"
> ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt"
> ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt"
> ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt"
> ><div dir="ltr" style="margin-top: 20px;" ><div style="font-size: 12pt;
> font-weight: bold; font-family: sans-serif; color: #7C7C5F;" >Regards</div>
> > <div style="font-size: 12pt; font-weight: bold; font-family: sans-serif;
> color: #7C7C5F;" >Xiao Qin Li</div>
> > <div style="font-size: 10pt; font-weight: bold; font-family:
> sans-serif;" ><br><span style="color:#696969;" >Cloud Storage Solutions
> Development<br>IBM China Systems & Technology Laboratory in
> Shanghai<br>Email: lixqin at cn.ibm.com<br>Tel: 86-21-60928955<br>3/F,
> Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District,
> Shanghai 201203</span></div></div></div></div></div></div></div></
> div></div></div></div><BR>
> >
> >
>
> > ____________________________________________________________
> ______________
> > 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: 23
> Date: Wed, 2 Aug 2017 10:04:03 -0500
> From: Matt Riedemann <mriedemos at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Trying again on wait_for_compute in
> devstack
> Message-ID: <54a6467e-e3d0-c62a-86ec-ffebc407be2a at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 8/2/2017 6:17 AM, Sean Dague wrote:
> > and we're not going
> > to use it in multinode scenarios.
>
> Why would you not run this in multinode scenarios? That's the only time
> this is really a problem, because in the single node case we're
> discovering and mapping the compute node late enough that it's not been
> a problem.
>
> The main failures are in the multinode jobs:
>
> https://bugs.launchpad.net/grenade/+bug/1708039
>
> https://goo.gl/xXhW8r
>
> The devstack change is also failing on XenServer CI and who knows how
> many other 3rd party CIs that don't run against devstack changes, but
> will explode once it merges and they are running on Cinder or Neutron
> changes. I've dropped the tags in the subject line of this email so that
> this gets broader awareness as this isn't really just going to impact
> nova and ironic jobs if third party CIs aren't setup to handle this.
>
> Why don't we wait until after RC1 on 8/10 before doing this? We already
> broke the gate and lost at least 6-10 hours last week on the day of
> feature freeze because of this.
>
> --
>
> Thanks,
>
> Matt
>
>
>
> ------------------------------
>
> Message: 24
> Date: Wed, 2 Aug 2017 11:04:06 -0400
> From: Sean Dague <sean at dague.net>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [devstack] [ironic] [nova] Trying again
> on wait_for_compute in devstack
> Message-ID: <a520b55e-daf1-ce94-2161-12faf3dd6e88 at dague.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> An issue with the xenserver CI was identified. Once we get this patch
> in, and backported to ocata, it should also address a frequent grenade
> multinode fail scenario which is plaguing the gate.
>
> -Sean
>
> On 08/02/2017 07:17 AM, Sean Dague wrote:
> > The 3 node scenarios in Neutron (which are still experimental nv) are
> > typically failing to bring online the 3rd compute. In cells v2 you have
> > to explicitly add nodes to the cells. There is a nova-manage command
> > "discover-hosts" that takes all the compute nodes which have checked in,
> > but aren't yet assigned to a cell, and puts them into a cell of your
> > choosing. We do this in devstack-gate in the gate.
> >
> > However... subnodes don't take very long to setup (so few services). And
> > the nova-compute process takes about 30s before it's done all it's
> > initialization and actually checks in to the cluster. It's a real
> > possibility that discover_hosts will run before subnode 3 checks in. We
> > see it in logs. This also really could come and bite us on any multinode
> > job, and I'm a bit concerned some of the multinode jobs aren't running
> > multinode some times because of it.
> >
> > One way to fix this, without putting more logic in devstack-gate, is
> > ensure that by the time stack.sh finishes, the compute node is up. This
> > was tried previously, but it turned out that we totally missed that it
> > broke Ironic (the check happened too early, ironic was not yet running,
> > so we always failed), Cells v1 (munges hostnames :( ), and PowerVM
> > (their nova-compute was never starting correctly, and they were working
> > around it with a restart later).
> >
> > This patch https://review.openstack.org/#/c/488381/ tries again. The
> > check is moved very late, Ironic seems to be running fine with it. Cells
> > v1 is just skipped, that's deprecated in Nova now, and we're not going
> > to use it in multinode scenarios. The PowerVM team fixed their
> > nova-compute start issues, so they should be good to go as well.
> >
> > This is an FYI that we're going to land this again soon. If you think
> > this impacts your CI / jobs, please speak up. The CI runs on both the
> > main and experimental queue on devstack for this change look pretty
> > good, so I think we're safe to move forward this time. But we also
> > thought that the last time, and were wrong.
> >
> > -Sean
> >
>
>
> --
> Sean Dague
> http://dague.net
>
>
>
> ------------------------------
>
> Message: 25
> Date: Wed, 2 Aug 2017 10:06:24 -0500
> From: Lance Bragstad <lbragstad at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [keystone][policy] no policy meeting today
> 2017-08-02
> Message-ID: <90e50b8a-6a66-3a1d-0e47-b93d4ca02e9c at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> A lot of the team is focused on getting pike-rc1 out the door and
> reviews. The agenda is also empty. Let's cancel today and pick up next
> week or shortly before the PTG to organize our policy sessions there.
>
> Thanks,
>
> Lance
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/fb65e19e/attachment-0001.sig>
>
> ------------------------------
>
> Message: 26
> Date: Wed, 2 Aug 2017 10:08:26 -0500
> From: Matt Riedemann <mriedemos at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Trying again on wait_for_compute in
> devstack
> Message-ID: <b2c2703c-cede-2b39-7836-a267422a5639 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 8/2/2017 10:04 AM, Matt Riedemann wrote:
> >> and we're not going
> >> to use it in multinode scenarios.
> >
> > Why would you not run this in multinode scenarios? That's the only time
> > this is really a problem, because in the single node case we're
> > discovering and mapping the compute node late enough that it's not been
> > a problem.
>
> Did you mean we're not going to use "cells v1" in multinode scenarios? I
> read "we're not going to use it" with "it" being the discovery patch in
> devstack, not cells v1.
>
> --
>
> Thanks,
>
> Matt
>
>
>
> ------------------------------
>
> Message: 27
> Date: Wed, 02 Aug 2017 16:22:03 +0100
> From: Stephen Finucane <sfinucan at redhat.com>
> To: Matt Riedemann <mriedemos at gmail.com>, "OpenStack Development
> Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <1501687323.3229.21.camel at redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> > Now that Stephen Finucane is back from enjoying his youth and
> > gallivanting all over Europe, and we talked about a few things in IRC
> > this morning on the docs migration for Nova, I wanted to dump my
> > concerns here for broader consumption.
> >
> > 1. We know we have to fix a bunch of broken links by adding in redirects
> > [1] which sdague started here [2]. However, that apparently didn't catch
> > everything, e.g. [3], so I'm concerned we're missing other broken links.
> > Is there a way to find out?
>
> We knew this was going to be an issue, but I wasn't aware of any way to fix
> this. The solution looks good though - nice work.
>
> Unfortunately I can't think of any cleverer way to identify these broken
> links
> than manual inspection. I'll do this again for all the patches I've
> authored
> and try to do them for any others I encounter.
>
> > 2. The bottom change in the docs migration series for Nova is a massive
> > refactor of the layout of the Nova devref [4]. That's something I don't
> > want to do in Pike for two reasons:
> >
> > a) It's a huge change and we simply don't have the time to invest in
> > properly assessing and reviewing it before Pike RC1.
> >
> > b) I think that if we're going to refactor the Nova devref home page to
> > be a certain format, then we should really consider doing the same thing
> > in the other projects, because today they are all different formats
> > [5][6][7]. This is likely a cross-project discussion for the Queens PTG
> > to determine if the home page for the projects should look similar. It
> > seems they should given the uniformity that the Foundation has been
> > working toward lately.
>
> This is fair. I've been working on this with asettle and I personally agree
> with a lot of the changes/design decisions made there. However, I
> understand
> the time constraints so we can surely split this out. I'll work with
> asettle on
> this too.
>
> > 3. The patch for the import of the admin guide [8] is missing some CLI
> > specific pages which are pretty useful given they aren't documented
> > anywhere else, like the forced_host part of the compute API [9].
> > Basically anything that's cli-nova-* in the admin guide should be in the
> > Nova docs. It's also missing the compute-flavors page [10] which is
> > pretty important for using OpenStack at all.
>
> This is a tricky one. Based on previous discussions with dhellmann, the
> plan
> seems to be to replace any references to 'nova xxx' or 'openstack xxx'
> commands
> (i.e. commands using python-novaclient or python-openstackclient) in
> favour of
> 'curl'-based requests. The idea here is that the Python clients are not the
> only clients available, and we shouldn't be "mandating" their use by
> referencing them in the docs. I get this, though I don't fully agree with
> it
> (who really uses curl?). In any case though, this would surely be a big
> rewrite
> and, per your concerns in #2 above, doesn't sound like something we
> should be
> doing in Pike. I guess a basic import is the way to go for now. I'll take
> care
> of this.
>
> > 4. Similar to #3, but we don't have a patch yet for importing the user
> > guide and there are several docs in the user guide that are Nova
> > specific so I'd like to make sure we include those, like [11][12].
>
> As above.
>
> Stephen
>
> > [1]
> > http://lists.openstack.org/pipermail/openstack-dev/2017-
> August/120418.html
> > [2] https://review.openstack.org/#/c/489650/
> > [3] https://review.openstack.org/#/c/489641/
> > [4] https://review.openstack.org/#/c/478485/
> > [5] https://docs.openstack.org/cinder/latest/
> > [6] https://docs.openstack.org/glance/latest/
> > [7] https://docs.openstack.org/neutron/latest/
> > [8] https://review.openstack.org/#/c/477497/
> > [9]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/admin-gu
> > ide/source/cli-nova-specify-host.rst
> > [10]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/admin-gu
> > ide/source/compute-flavors.rst
> > [11]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/user-gui
> > de/source/cli-launch-instances.rst
> > [12]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/user-gui
> > de/source/cli-delete-an-instance.rst
> >
>
>
>
>
> ------------------------------
>
> Message: 28
> Date: Wed, 02 Aug 2017 16:22:18 +0100
> From: Stephen Finucane <sfinucan at redhat.com>
> To: Matt Riedemann <mriedemos at gmail.com>, "OpenStack Development
> Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <1501687338.3229.22.camel at redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> > Now that Stephen Finucane is back from enjoying his youth and
> > gallivanting all over Europe, and we talked about a few things in IRC
> > this morning on the docs migration for Nova, I wanted to dump my
> > concerns here for broader consumption.
> >
> > 1. We know we have to fix a bunch of broken links by adding in redirects
> > [1] which sdague started here [2]. However, that apparently didn't catch
> > everything, e.g. [3], so I'm concerned we're missing other broken links.
> > Is there a way to find out?
>
> Manual inspection is probably the easiest way to go.
>
> > 2. The bottom change in the docs migration series for Nova is a massive
> > refactor of the layout of the Nova devref [4]. That's something I don't
> > want to do in Pike for two reasons:
> >
> > a) It's a huge change and we simply don't have the time to invest in
> > properly assessing and reviewing it before Pike RC1.
> >
> > b) I think that if we're going to refactor the Nova devref home page to
> > be a certain format, then we should really consider doing the same thing
> > in the other projects, because today they are all different formats
> > [5][6][7]. This is likely a cross-project discussion for the Queens PTG
> > to determine if the home page for the projects should look similar. It
> > seems they should given the uniformity that the Foundation has been
> > working toward lately.
> >
> > 3. The patch for the import of the admin guide [8] is missing some CLI
> > specific pages which are pretty useful given they aren't documented
> > anywhere else, like the forced_host part of the compute API [9].
> > Basically anything that's cli-nova-* in the admin guide should be in the
> > Nova docs. It's also missing the compute-flavors page [10] which is
> > pretty important for using OpenStack at all.
> >
> > 4. Similar to #3, but we don't have a patch yet for importing the user
> > guide and there are several docs in the user guide that are Nova
> > specific so I'd like to make sure we include those, like [11][12].
> >
> > [1]
> > http://lists.openstack.org/pipermail/openstack-dev/2017-
> August/120418.html
> > [2] https://review.openstack.org/#/c/489650/
> > [3] https://review.openstack.org/#/c/489641/
> > [4] https://review.openstack.org/#/c/478485/
> > [5] https://docs.openstack.org/cinder/latest/
> > [6] https://docs.openstack.org/glance/latest/
> > [7] https://docs.openstack.org/neutron/latest/
> > [8] https://review.openstack.org/#/c/477497/
> > [9]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/admin-gu
> > ide/source/cli-nova-specify-host.rst
> > [10]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/admin-gu
> > ide/source/compute-flavors.rst
> > [11]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/user-gui
> > de/source/cli-launch-instances.rst
> > [12]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/user-gui
> > de/source/cli-delete-an-instance.rst
> >
>
>
>
>
> ------------------------------
>
> Message: 29
> Date: Wed, 2 Aug 2017 10:27:10 -0500
> From: Matt Riedemann <mriedemos at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [trove] Can we move some non-voting broken
> jobs to the experimental queue?
> Message-ID: <7fad19bb-84f0-bbfa-59a9-979f3f872dbc at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I don't dabble in Trove-land often but today I pushed a change and was
> watching it in zuul, and noticed that the change runs 26 jobs in the
> check queue. Several of those (cassandra, couch, mongo, percona) all
> failed nearly immediately with something in the diskimage builder, like
> this:
>
> http://logs.openstack.org/42/490042/1/check/gate-trove-
> scenario-dsvm-cassandra-single-ubuntu-xenial-nv/
> d38a8c1/logs/devstack-gate-post_test_hook.txt.gz#_2017-08-02_14_58_16_953
>
> diskimage_builder.element_dependencies.MissingElementException: Element
> 'ubuntu-xenial-cassandra' not found
>
> Is anyone maintaining these jobs? If not, they should be moved to the
> experimental queue so they can be run on demand, not in the check queue
> for every patch set proposed to Trove. These are also single and
> multi-node jobs, so they are needlessly eating up node pool resources.
>
> --
>
> Thanks,
>
> Matt
>
>
>
> ------------------------------
>
> Message: 30
> Date: Wed, 2 Aug 2017 09:28:18 -0600
> From: Chris Friesen <chris.friesen at windriver.com>
> To: <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <5981EF92.70402 at windriver.com>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
> On 08/02/2017 09:22 AM, Stephen Finucane wrote:
> > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
>
> >> 3. The patch for the import of the admin guide [8] is missing some CLI
> >> specific pages which are pretty useful given they aren't documented
> >> anywhere else, like the forced_host part of the compute API [9].
> >> Basically anything that's cli-nova-* in the admin guide should be in the
> >> Nova docs. It's also missing the compute-flavors page [10] which is
> >> pretty important for using OpenStack at all.
> >
> > This is a tricky one. Based on previous discussions with dhellmann, the
> plan
> > seems to be to replace any references to 'nova xxx' or 'openstack xxx'
> commands
> > (i.e. commands using python-novaclient or python-openstackclient) in
> favour of
> > 'curl'-based requests. The idea here is that the Python clients are not
> the
> > only clients available, and we shouldn't be "mandating" their use by
> > referencing them in the docs. I get this, though I don't fully agree
> with it
> > (who really uses curl?)
>
> Are we going to document the python clients elsewhere then? Personally I
> find
> it highly useful to have complete examples of how to do things with
> python-novaclient or python-openstackclient.
>
> Given that any users of the raw HTTP API are likely going to be developers,
> while users of the CLI tools may not be, it seems more important to give
> good
> examples of using the CLI tools. Any developer should be able to figure
> out the
> underlying HTTP (using the --debug option of the CLI tool if necessary).
>
> Chris
>
>
>
> ------------------------------
>
> Message: 31
> Date: Wed, 2 Aug 2017 16:34:10 +0100 (BST)
> From: Chris Dent <cdent+os at anticdent.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <alpine.OSX.2.21.1708021631240.51828 at cdent-m01.vmware.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On Wed, 2 Aug 2017, Stephen Finucane wrote:
> > Unfortunately I can't think of any cleverer way to identify these broken
> links
> > than manual inspection. I'll do this again for all the patches I've
> authored
> > and try to do them for any others I encounter.
>
> if there's access available to the web server logs:
>
> Get access to the server logs, grep for 404 response codes, sort by
> url, order by count. Anything that has a high number should be
> compared with the .htaccess file that Sean created.
>
> > This is a tricky one. Based on previous discussions with dhellmann, the
> plan
> > seems to be to replace any references to 'nova xxx' or 'openstack xxx'
> commands
> > (i.e. commands using python-novaclient or python-openstackclient) in
> favour of
> > 'curl'-based requests. The idea here is that the Python clients are not
> the
> > only clients available, and we shouldn't be "mandating" their use by
> > referencing them in the docs. I get this, though I don't fully agree
> with it
> > (who really uses curl?). In any case though, this would surely be a big
> rewrite
> > and, per your concerns in #2 above, doesn't sound like something we
> should be
> > doing in Pike. I guess a basic import is the way to go for now. I'll
> take care
> > of this.
>
> As much as I think using the raw HTTP is an important learning
> tool, using curl in the docs will make the docs very hard to
> comprehend.
>
> --
> Chris Dent (⊙＿⊙') https://anticdent.org/
> freenode: cdent tw: @anticdent
>
> ------------------------------
>
> Message: 32
> Date: Wed, 02 Aug 2017 16:35:23 +0100
> From: Stephen Finucane <sfinucan at redhat.com>
> To: Chris Friesen <chris.friesen at windriver.com>,
> openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <1501688123.3229.24.camel at redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:
> > On 08/02/2017 09:22 AM, Stephen Finucane wrote:
> > > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> > > > 3. The patch for the import of the admin guide [8] is missing some
> CLI
> > > > specific pages which are pretty useful given they aren't documented
> > > > anywhere else, like the forced_host part of the compute API [9].
> > > > Basically anything that's cli-nova-* in the admin guide should be in
> the
> > > > Nova docs. It's also missing the compute-flavors page [10] which is
> > > > pretty important for using OpenStack at all.
> > >
> > > This is a tricky one. Based on previous discussions with dhellmann, the
> > > plan
> > > seems to be to replace any references to 'nova xxx' or 'openstack xxx'
> > > commands
> > > (i.e. commands using python-novaclient or python-openstackclient) in
> favour
> > > of
> > > 'curl'-based requests. The idea here is that the Python clients are
> not the
> > > only clients available, and we shouldn't be "mandating" their use by
> > > referencing them in the docs. I get this, though I don't fully agree
> with
> > > it
> > > (who really uses curl?)
> >
> > Are we going to document the python clients elsewhere then?
>
> I think the docs would go into the respective python clients docs?
>
> > Personally I find it highly useful to have complete examples of how to do
> > things with python-novaclient or python-openstackclient.
>
> I agree. Personally, I'd like to see something like Stripe's API docs [1],
> maybe through a not-yet-existant 'sphinx-slate' extension [2], but that
> seems a
> lot of work for very little gain and would need serious maintaining.
>
> > Given that any users of the raw HTTP API are likely going to be
> developers,
> > while users of the CLI tools may not be, it seems more important to give
> > good examples of using the CLI tools. Any developer should be able to
> figure
> > out the underlying HTTP (using the --debug option of the CLI tool if
> > necessary).
>
> I think the main idea is that the 'python-*client's are not the only game
> in
> town and should not be treated as such. Who these other clients are is a
> question I don't personally know the answer to, however.
>
> In any case, this is surely a post-Pike issue, as noted above.
>
> Stephen
>
> [1] https://stripe.com/docs/api
> [2] https://github.com/lord/slate
>
>
>
> ------------------------------
>
> Message: 33
> Date: Wed, 02 Aug 2017 11:52:30 -0400
> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <1501688953-sup-448 at lrrr.local>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:
> > On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:
> > > On 08/02/2017 09:22 AM, Stephen Finucane wrote:
> > > > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> > > > > 3. The patch for the import of the admin guide [8] is missing some
> CLI
> > > > > specific pages which are pretty useful given they aren't documented
> > > > > anywhere else, like the forced_host part of the compute API [9].
> > > > > Basically anything that's cli-nova-* in the admin guide should be
> in the
> > > > > Nova docs. It's also missing the compute-flavors page [10] which is
> > > > > pretty important for using OpenStack at all.
> > > >
> > > > This is a tricky one. Based on previous discussions with dhellmann,
> the
> > > > plan
> > > > seems to be to replace any references to 'nova xxx' or 'openstack
> xxx'
> > > > commands
> > > > (i.e. commands using python-novaclient or python-openstackclient) in
> favour
> > > > of
> > > > 'curl'-based requests. The idea here is that the Python clients are
> not the
> > > > only clients available, and we shouldn't be "mandating" their use by
> > > > referencing them in the docs. I get this, though I don't fully agree
> with
> > > > it
> > > > (who really uses curl?)
> > >
> > > Are we going to document the python clients elsewhere then?
> >
> > I think the docs would go into the respective python clients docs?
>
> Right. I don't remember the details of the curl discussion, but I
> think what I was trying to say there was that the "nova" command
> line tool installed via python-novaclient should be documented as
> part of the openstack/python-novaclient repo rather than openstack/nova.
> A CLI reference for nova-manage, which I think is in openstack/nova,
> could be documented in openstack/nova.
>
> Basically, put the docs with the code, which is the whole point of this
> migration.
>
> Doug
>
>
>
> ------------------------------
>
> Message: 34
> Date: Thu, 3 Aug 2017 00:55:35 +0900
> From: Akihiro Motoki <amotoki at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID:
> <CALhU9tnhUusRL0N5R0N+o3SqOhuO3B5W=4oLtAQ1hejJ0eieqA
> @mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Thanks for summarizing the concerns. It is really helpful for all projects!
>
> 2017-08-02 23:55 GMT+09:00 Matt Riedemann <mriedemos at gmail.com>:
> > Now that Stephen Finucane is back from enjoying his youth and
> gallivanting
> > all over Europe, and we talked about a few things in IRC this morning on
> the
> > docs migration for Nova, I wanted to dump my concerns here for broader
> > consumption.
> >
> > 1. We know we have to fix a bunch of broken links by adding in redirects
> [1]
> > which sdague started here [2]. However, that apparently didn't catch
> > everything, e.g. [3], so I'm concerned we're missing other broken links.
> Is
> > there a way to find out?
> >
> > 2. The bottom change in the docs migration series for Nova is a massive
> > refactor of the layout of the Nova devref [4]. That's something I don't
> want
> > to do in Pike for two reasons:
> >
> > a) It's a huge change and we simply don't have the time to invest in
> > properly assessing and reviewing it before Pike RC1.
> >
> > b) I think that if we're going to refactor the Nova devref home page to
> be a
> > certain format, then we should really consider doing the same thing in
> the
> > other projects, because today they are all different formats [5][6][7].
> This
> > is likely a cross-project discussion for the Queens PTG to determine if
> the
> > home page for the projects should look similar. It seems they should
> given
> > the uniformity that the Foundation has been working toward lately.
>
> Totally agree for PTG topics. we need some guideline on what the top pages
> of
> individual projects should be and what are expected for top pages of
> sub directories.
> When the doc-migration started, I chatted on this a bit with asettle.
> The top page of each subdirectory (like admin, install and so on) are
> expected to link
> from a landing page on docs.openstack.org. On the other hand, we also
> need to
> take care of the top page of individual projects. In neutron case, we
> basically try to
> accommodate all documents in the standard directory structure and keep
> the top page as much as simple.
> It is really nice to have a consistent guideline on this.
>
> > 3. The patch for the import of the admin guide [8] is missing some CLI
> > specific pages which are pretty useful given they aren't documented
> anywhere
> > else, like the forced_host part of the compute API [9]. Basically
> anything
> > that's cli-nova-* in the admin guide should be in the Nova docs. It's
> also
> > missing the compute-flavors page [10] which is pretty important for using
> > OpenStack at all.
>
> Perhaps what we need are pages which explains how to use and configure
> a specific feature using on CLI and/or some. It might be beyond the
> scope of cli-nova-*.
> I think the end-user and admin guides can be refactored per topic.
>
> > 4. Similar to #3, but we don't have a patch yet for importing the user
> guide
> > and there are several docs in the user guide that are Nova specific so
> I'd
> > like to make sure we include those, like [11][12].
> >
> > [1]
> > http://lists.openstack.org/pipermail/openstack-dev/2017-
> August/120418.html
> > [2] https://review.openstack.org/#/c/489650/
> > [3] https://review.openstack.org/#/c/489641/
> > [4] https://review.openstack.org/#/c/478485/
> > [5] https://docs.openstack.org/cinder/latest/
> > [6] https://docs.openstack.org/glance/latest/
> > [7] https://docs.openstack.org/neutron/latest/
> > [8] https://review.openstack.org/#/c/477497/
> > [9]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/admin-guide/source/cli-nova-specify-host.rst
> > [10]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/admin-guide/source/compute-flavors.rst
> > [11]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/user-guide/source/cli-launch-instances.rst
> > [12]
> > https://github.com/openstack/openstack-manuals/blob/stable/
> ocata/doc/user-guide/source/cli-delete-an-instance.rst
> >
> > --
> >
> > Thanks,
> >
> > 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
>
>
>
> ------------------------------
>
> Message: 35
> Date: Thu, 3 Aug 2017 01:02:59 +0900
> From: Akihiro Motoki <amotoki at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID:
> <CALhU9tm=93Hm9K_NJasayeYV6yCC2NU3AyVGRmsrbY8-
> a3se5Q at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 2017-08-03 0:52 GMT+09:00 Doug Hellmann <doug at doughellmann.com>:
> > Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:
> >> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:
> >> > On 08/02/2017 09:22 AM, Stephen Finucane wrote:
> >> > > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> >> > > > 3. The patch for the import of the admin guide [8] is missing
> some CLI
> >> > > > specific pages which are pretty useful given they aren't
> documented
> >> > > > anywhere else, like the forced_host part of the compute API [9].
> >> > > > Basically anything that's cli-nova-* in the admin guide should be
> in the
> >> > > > Nova docs. It's also missing the compute-flavors page [10] which
> is
> >> > > > pretty important for using OpenStack at all.
> >> > >
> >> > > This is a tricky one. Based on previous discussions with dhellmann,
> the
> >> > > plan
> >> > > seems to be to replace any references to 'nova xxx' or 'openstack
> xxx'
> >> > > commands
> >> > > (i.e. commands using python-novaclient or python-openstackclient)
> in favour
> >> > > of
> >> > > 'curl'-based requests. The idea here is that the Python clients are
> not the
> >> > > only clients available, and we shouldn't be "mandating" their use by
> >> > > referencing them in the docs. I get this, though I don't fully
> agree with
> >> > > it
> >> > > (who really uses curl?)
> >> >
> >> > Are we going to document the python clients elsewhere then?
> >>
> >> I think the docs would go into the respective python clients docs?
> >
> > Right. I don't remember the details of the curl discussion, but I
> > think what I was trying to say there was that the "nova" command
> > line tool installed via python-novaclient should be documented as
> > part of the openstack/python-novaclient repo rather than openstack/nova.
> > A CLI reference for nova-manage, which I think is in openstack/nova,
> > could be documented in openstack/nova.
> >
> > Basically, put the docs with the code, which is the whole point of this
> > migration.
>
> It is true for CLI reference.
> The gray zone is CLI stuffs in the admin guide and/or end-user guide.
> I think this is the point Matt raised.
> cli-nova-* stuffs in the admin guide was per topic like launching instance,
> migrating instances and so on. It is actually beyond the CLI reference to
> me.
> It is about how to use specific features of nova.
> IMHO this kind of stuffs can be covered by the admin guide or user guide,
> so it fits into openstack/nova (or other server projects).
>
> Akihiro
>
> >
> > Doug
> >
> > ____________________________________________________________
> ______________
> > 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: 36
> Date: Wed, 02 Aug 2017 12:20:00 -0400
> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <1501690251-sup-600 at lrrr.local>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Akihiro Motoki's message of 2017-08-03 01:02:59 +0900:
> > 2017-08-03 0:52 GMT+09:00 Doug Hellmann <doug at doughellmann.com>:
> > > Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:
> > >> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:
> > >> > On 08/02/2017 09:22 AM, Stephen Finucane wrote:
> > >> > > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> > >> > > > 3. The patch for the import of the admin guide [8] is missing
> some CLI
> > >> > > > specific pages which are pretty useful given they aren't
> documented
> > >> > > > anywhere else, like the forced_host part of the compute API [9].
> > >> > > > Basically anything that's cli-nova-* in the admin guide should
> be in the
> > >> > > > Nova docs. It's also missing the compute-flavors page [10]
> which is
> > >> > > > pretty important for using OpenStack at all.
> > >> > >
> > >> > > This is a tricky one. Based on previous discussions with
> dhellmann, the
> > >> > > plan
> > >> > > seems to be to replace any references to 'nova xxx' or 'openstack
> xxx'
> > >> > > commands
> > >> > > (i.e. commands using python-novaclient or python-openstackclient)
> in favour
> > >> > > of
> > >> > > 'curl'-based requests. The idea here is that the Python clients
> are not the
> > >> > > only clients available, and we shouldn't be "mandating" their use
> by
> > >> > > referencing them in the docs. I get this, though I don't fully
> agree with
> > >> > > it
> > >> > > (who really uses curl?)
> > >> >
> > >> > Are we going to document the python clients elsewhere then?
> > >>
> > >> I think the docs would go into the respective python clients docs?
> > >
> > > Right. I don't remember the details of the curl discussion, but I
> > > think what I was trying to say there was that the "nova" command
> > > line tool installed via python-novaclient should be documented as
> > > part of the openstack/python-novaclient repo rather than
> openstack/nova.
> > > A CLI reference for nova-manage, which I think is in openstack/nova,
> > > could be documented in openstack/nova.
> > >
> > > Basically, put the docs with the code, which is the whole point of this
> > > migration.
> >
> > It is true for CLI reference.
> > The gray zone is CLI stuffs in the admin guide and/or end-user guide.
> > I think this is the point Matt raised.
> > cli-nova-* stuffs in the admin guide was per topic like launching
> instance,
> > migrating instances and so on. It is actually beyond the CLI reference
> to me.
> > It is about how to use specific features of nova.
> > IMHO this kind of stuffs can be covered by the admin guide or user guide,
> > so it fits into openstack/nova (or other server projects).
>
> Yeah, I don't know.
>
> My gut response is to say that if the example uses nova-manage or
> one of the nova service executables, then that makes sense to leave
> in the nova tree, but otherwise it should go into either the
> python-novaclient or python-openstackclient repositories (depending
> on which command line tool is used in the example).
>
> On the other hand, I can see that being somewhat confusing for
> someone who lands at the nova docs and can't find instructions for
> how to use it. Maybe less confusing, though, than if I am not
> *running* nova but am trying to use a nova deployed by someone else
> and I start from the python-novaclient or python-openstackclient
> docs because I installed one of those in order to talk to nova.
>
> I thought "put the docs with the code" would be a simple enough
> rule that we wouldn't have to think too hard about where to put
> individual example files, which would speed up the migration.
>
> Doug
>
> >
> > Akihiro
> >
> > >
> > > Doug
> > >
> > > ____________________________________________________________
> ______________
> > > 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, 2 Aug 2017 18:20:32 +0200
> From: Carlos Camacho Gonzalez <ccamacho at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tripleo] Proposing Bogdan Dobrelya core
> on TripleO / Containers
> Message-ID:
> <CANYJBfa288xLyvu1PpjoLsDMrgXyefxRmK07G6kT=ed8mv_gDw at mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Congrats!
>
> On Mon, Jul 31, 2017 at 6:29 PM, Bogdan Dobrelya <bdobreli at redhat.com>
> wrote:
> > On 31.07.2017 15:51, Emilien Macchi wrote:
> >> On Fri, Jul 21, 2017 at 7:55 AM, Emilien Macchi <emilien at redhat.com>
> wrote:
> >>> Hi,
> >>>
> >>> Bogdan (bogdando on IRC) has been very active in Containerization of
> >>> TripleO and his quality of review has increased over time.
> >>> I would like to give him core permissions on container work in TripleO.
> >>> Any feedback is welcome as usual, we'll vote as a team.
> >>
> >> Votes were positive, it's done now.
> >> Bogdan has now +2 and we expect him to use it on patches related to
> >> container work.
> >>
> >> Thanks,
> >>
> >
> > Thank you for your votes!
> >
> > --
> > Best regards,
> > Bogdan Dobrelya,
> > Irc #bogdando
> >
> > ____________________________________________________________
> ______________
> > 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: 38
> Date: Wed, 2 Aug 2017 11:21:11 -0500
> From: Monty Taylor <mordred at inaugust.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [all] Rollout of Zuul v3 at the PTG
> Message-ID: <ead295c8-35f2-7e57-11aa-f306722f4a29 at inaugust.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hey everybody!
>
> The time has come at long last, we're actually aiming at a concrete date
> for rolling Zuul v3 live. \o/
>
> tl;dr - Assuming things go well we want to do it at the PTG
>
> We couldn't be more excited - there are a giant pile of feature requests
> from folks that we've been responding with "yes, as soon as Zuul v3 is
> here you can do that" - and that's not any more fun for us as it is for
> you.
>
> If you have no idea what Zuul v3 is - there is a section at the end of
> the email just for you.
>
> The Plan
> ========
>
> Zuul v3 itself works great - we're using it to run tests on Zuul itself.
> The biggest bulk of work at the moment is ... job content.
>
> We know that we can do a one-time migration of job content - because we
> do it every day for our current jobs (they are translated from
> jenkins-job-builder to ansible on the fly in Zuul 2.5 today) However,
> that translated content is ugly - and Zuul v3 allows us to make a bunch
> of things nicer. We'd like to have as many of our jobs translated to
> 'nice' versions for the cutover as possible so that as people copy-pasta
> jobs they've got good content to work from.
>
> We're currently working on writing v3-native versions of the most common
> jobs. This includes the tox-based unittest jobs and common things like
> tarball creation, pypi and docs publication. Next up is getting
> devstack-gate jobs done. Between tox and devstack-gate - we should have
> the majority of our jobs covered, so any outliers we couldn't
> auto-translate into something nice and new will have good examples to
> work from for followup cleaning.
>
> devstack-gate question
> ----------------------
>
> There is an open question for devstack-gate. Namely - given the
> mechanism of how it works with defining a bunch of environment variables
> and then defining a shell function - it's currently unknown if we'll be
> able to fully auto-translate all of the existing project-specific
> special devstack-gate jobs, or whether we'll need to just migrate them
> all to things that look pretty similar to how they look now and have a
> few clear examples people can follow as they feel like updating things.
>
> We should know more about that soon as we're working devstack-gate jobs
> this week.
>
> Go Live
> -------
>
> On the Saturday and Sunday immediately preceeding the PTG, we will run a
> few trial cutovers. That is, we'll do a short zuul downtime, run job
> migration scripts, turn zuul v3 on, run for a little bit to see how
> things go, then turn it off and turn v2 back on. This will let us
> double-check the migration during a time that's likely slower than
> normal for any last minute dead-in-the-water issues.
>
> First thing Monday morning of the PTG, we'll throw the switch for real.
> We'll be around all week in a sort of "open office hours" form to help
> folks if there are any questions, if there are any job execution edge
> cases that need to be worked through - or if people are now excited by
> all the new features and have questions about how to make use of them.
>
> We'll essentially be planning on our PTG to be all about making sure any
> questions any of you have can be fielded with plenty of bandwidth.
>
> It's possible we won't be ready. We're pretty optimistic, but this is a
> big move, and something unforseen could come up between now and then.
> We're not going to throw the switch without being confident that things
> will go well just to meet a date. If we decide to cancel the cutover,
> we'll send an announcement to the list
>
> Between Now and Then
> ====================
>
> By and large the leadup to this should have very little impact on folks.
>
> There are some jobs that use scripts that are pre-baked into images that
> come from the jenkins/scripts directory in project-config. Those will no
> longer be used in Zuul v3 and will be migrated into Zuul v3 job
> definitions. Those scripts are currently under a soft-freeze, meaning
> that we'd prefer to not make any changes to them - but if a change is
> needed we need to ensure it gets forward-ported to the zuulv3 version.
> Closer to the PTG we'll put those scripts under a hard-freeze. They're
> all tricky to deal with anyway because they get baked in to images, so
> we're not expecting a ton of impact from that.
>
> We may need to freeze all of project-config in the days leading up to
> the cutover, but since those are the days leading up to the PTG it's
> unlikely that should be a super active time for that repo.
>
> Third Party CI
> ==============
>
> Any Third Party CI that is currently using Zuul should continue using
> Zuul v2 as you are today. Once we go live for OpenStack we'll be in a
> position to start discussing upgrade plans for 3rd Party operators. The
> goal is to migrate all of you - but we don't want folks to start
> tackling that until we're happy we've got automation and documentation
> worked out. After the PTG will be a great time to start discussing what
> that plan wants to look like.
>
> Wait - what the heck is Zuul v3 and why are we doing this?
> ==========================================================
>
> We've started a documentation page on this topic in the Infra Manual.
> It is short right now, but as we get closer to the cutover, we will
> continue to update this page with information about the migration:
>
> https://docs.openstack.org/infra/manual/zuulv3.html
>
> Zuul v3 is the new version of Zuul that incorporates a ton of learning
> about pain points from the last several years. It adds in-repo config,
> native multi-node testing, ansible-based job definitions, full DAG job
> dependencies and support for integration with systems OpenStack doesn't
> otherwise use such as GitHub.
>
> Zuul v3 is designed to be run by not-Infra. We're happy that Zuul has
> been useful for other people over the past few years, especially our
> Third-Party CI community - but up until v3 the OpenStack project was
> always consideration #1 and other users were best-effort.
>
> With v3 we formally consider users who are not the OpenStack Project to
> be first-class users. We have recently added 3 core reviewers to Zuul
> who are not involved with running OpenStack's Zuul. (one runs a Zuul v3
> at BMW and two run a Zuul v3 for the IBM BonnyCI project)
>
> We have a bunch of work teed up for post PTG rollout to add more support
> for a wider array of usecases. The OpNFV Infra team has an important
> feature request that Tristan from the RH Software Factory team has
> started implementing. We have planned support for container execution,
> both on a single-container and a COE (kubernetes/mesos) level, as well
> as additional triggers/reporters such as FedMsg as used by Fedora and
> Debian projects.
>
> More information on the background of Zuul v3 can be found at:
>
> https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html
>
> and
>
> http://lists.openstack.org/pipermail/openstack-dev/2017-
> February/113065.html
>
> Docs for Zuul v3 itself can currently be found at:
>
> https://docs.openstack.org/infra/zuul/feature/zuulv3/
>
> As usual, you can find us in #openstack-infra and in #zuul.
>
> Thanks!
> Monty
>
>
>
> ------------------------------
>
> Message: 39
> Date: Wed, 02 Aug 2017 09:28:52 -0700
> From: Clark Boylan <cboylan at sapwetik.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID:
> <1501691332.1382598.1060933592.04ED4028 at webmail.
> messagingengine.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> > Now that Stephen Finucane is back from enjoying his youth and
> > gallivanting all over Europe, and we talked about a few things in IRC
> > this morning on the docs migration for Nova, I wanted to dump my
> > concerns here for broader consumption.
> >
> > 1. We know we have to fix a bunch of broken links by adding in redirects
> > [1] which sdague started here [2]. However, that apparently didn't catch
> > everything, e.g. [3], so I'm concerned we're missing other broken links.
> > Is there a way to find out?
>
> The infra team can generate lists of 404 urls fairly easily on the docs
> server. This won't show you everything but will show you what urls
> people are finding/using that 404.
>
> >
>
> snip
>
> > [1]
> > http://lists.openstack.org/pipermail/openstack-dev/2017-
> August/120418.html
> > [2] https://review.openstack.org/#/c/489650/
> > [3] https://review.openstack.org/#/c/489641/
>
> Clark
>
>
>
> ------------------------------
>
> Message: 40
> Date: Wed, 02 Aug 2017 17:55:38 +0100
> From: Stephen Finucane <sfinucan at redhat.com>
> To: Clark Boylan <cboylan at sapwetik.org>,
> openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <1501692938.3229.26.camel at redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2017-08-02 at 09:28 -0700, Clark Boylan wrote:
> > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> > > Now that Stephen Finucane is back from enjoying his youth and
> > > gallivanting all over Europe, and we talked about a few things in IRC
> > > this morning on the docs migration for Nova, I wanted to dump my
> > > concerns here for broader consumption.
> > >
> > > 1. We know we have to fix a bunch of broken links by adding in
> redirects
> > > [1] which sdague started here [2]. However, that apparently didn't
> catch
> > > everything, e.g. [3], so I'm concerned we're missing other broken
> links.
> > > Is there a way to find out?
> >
> > The infra team can generate lists of 404 urls fairly easily on the docs
> > server. This won't show you everything but will show you what urls
> > people are finding/using that 404.
>
> I'd appreciate that. Have been going through things manually this
> afternoon but
> it's slow work. Can you do this (or know who could)?
>
> Stephen
>
>
>
> ------------------------------
>
> Message: 41
> Date: Wed, 2 Aug 2017 10:23:18 -0700
> From: Sridhar Ramaswamy <srics.r at gmail.com>
> To: gongys2017 <gongys2017 at aliyun.com>, "OpenStack Development
> Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Tacker] Proposing yanxingan for Tacker
> core
> Message-ID:
> <CAK6Sh4B6BiG7QG0qNMSpi5YRMSYy6wB7yoNveP3AQNRiiwAZ1Q at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +2
>
> Thanks Yan for your contribution to Tacker.
>
> On Jul 27, 2017 10:15 AM, "gongys2017" <gongys2017 at aliyun.com> wrote:
>
>
> I am proposing we add Yan xingan as a Tacker core.
>
> Yanxingan is woking in china mobile, a telecom company which has big
> requirement
> on NFV MANO. We are proud of having him on tacker team, and promoting the
> usage of
> tacker in his company.
>
> In not long time, he has contributed lots on project, such as review, BP
> and active in tacker project meeting.
> he has also done presentation on tacker to make propaganda of this project.
>
> Tacker cores, please respond with your opinion. If no reason is given to do
> otherwise, I will add Yan xingan to the core group in one week.
>
> Thanks,
> Yong Sheng Gong
>
>
> [1] https://review.openstack.org/#/q/owner:yanxingan%2540cmss.
> chinamobile.com
> <https://review.openstack.org/#/q/owner:%22TommyLike+%
> 253Ctommylikehu%2540gmail.com%253E%22++status:merged>
>
> __________________________________________________________________________
> 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/20170802/101440e8/attachment-0001.html>
>
> ------------------------------
>
> Message: 42
> Date: Wed, 2 Aug 2017 13:34:22 -0400
> From: Mathieu Gagné <mgagne at calavera.ca>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID:
> <CAFee_oRtpDN4Xk44gM6J-LWgu7tWDD+UpLy7BwYTAwn8GKU8iA@
> mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, Aug 2, 2017 at 12:28 PM, Clark Boylan <cboylan at sapwetik.org>
> wrote:
> > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> >> Now that Stephen Finucane is back from enjoying his youth and
> >> gallivanting all over Europe, and we talked about a few things in IRC
> >> this morning on the docs migration for Nova, I wanted to dump my
> >> concerns here for broader consumption.
> >>
> >> 1. We know we have to fix a bunch of broken links by adding in redirects
> >> [1] which sdague started here [2]. However, that apparently didn't catch
> >> everything, e.g. [3], so I'm concerned we're missing other broken links.
> >> Is there a way to find out?
> >
> > The infra team can generate lists of 404 urls fairly easily on the docs
> > server. This won't show you everything but will show you what urls
> > people are finding/using that 404.
> >
>
> Thanks for proposing this proactive solution.
> I find it *very frustrating* to Google something and land on a 404 error.
> Especially when the user survey keeps asking "How often do users refer
> to documentation from docs.openstack.org?"
> I don't often refer to the documentation but as of today, when I does,
> it's only to find the page I'm looking for has moved somewhere.
> What kind of experience are we giving to the users and operators? (I'm
> sure it's with good intents and for the best)
>
> I'm glad people are addressing the redirection issues.
>
> --
> Mathieu
>
>
>
> ------------------------------
>
> Message: 43
> Date: Wed, 2 Aug 2017 13:07:17 -0500
> From: Lance Bragstad <lbragstad at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, Amy Marrich <amy at demarco.com>
> Subject: Re: [openstack-dev] [OpenStack-Ansible] Not running for
> Queens PTL
> Message-ID: <103013bc-33bd-e52e-d849-230d5850ec63 at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I couldn't agree more with what others have already said. It's been
> awesome to see positive things come out of close communication between
> deployment projects and other project teams. I look forward to seeing
> the pattern and precedence continue!
>
>
> On 07/31/2017 12:59 PM, Amy Marrich wrote:
> > Andy,
> >
> > You'll be missed you did a great job(as did Kevin and Jesse before
> > you)! Glad you'll be around still as you'd definitely be missed.
> >
> > Amy (spotz)
> >
> > On Mon, Jul 31, 2017 at 4:48 AM, Andy McCrae <andy.mccrae at gmail.com
> > <mailto:andy.mccrae at gmail.com>> wrote:
> >
> > Following on from last week's meeting - I've had 2 cycles as PTL
> > for OSA, which has been a really great experience - we've achieved
> > a lot and built on the strong base we had, which I'm really proud
> > of. I strongly believe that inviting a fresh perspective and new
> > ideas as PTL is a winning strategy - it's served us well so far,
> > and in line with previous PTLs I won't be standing for a 3rd cycle.
> >
> > Looking forward to assisting the next PTL, and helping to continue
> > to mature and improve the project!
> >
> > Thanks!
> > Andy
> >
> > ____________________________________________________________
> ______________
> > 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
> > <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/20170802/a6782979/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/a6782979/attachment-0001.sig>
>
> ------------------------------
>
> Message: 44
> Date: Wed, 2 Aug 2017 18:14:42 +0000
> From: "Walsh, Helen" <Helen.Walsh at dell.com>
> To: "'openstack-dev at lists.openstack.org'"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] string freeze exception for VMAX driver
> Message-ID:
> <6031C821D2144A4CB722005A21B34BD53AB12F7D at MX202CL02.corp.emc.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> To whom it may concern,
>
> I would like to request a string freeze exception for 2 patches that are
> on the merge queue for Pike.
>
>
>
> 1. VMAX driver - align VMAX QOS settings with front end (CI Passed)
> https://review.openstack.org/#/c/484885/7/cinder/volume/
> drivers/dell_emc/vmax/rest.py line 800 (removal of exception message)
>
> Although it's primary aim is to align QoS with front end setting it
> indirectly fixes a lazy loading error we were seeing around QoS which
> occasionally
> Broke CI on previous patches.
>
>
>
> 2. VMAX driver - seamless upgrade from SMI-S to REST (CI Pending)
> https://review.openstack.org/#/c/482138/19/cinder/volume/
> drivers/dell_emc/vmax/common.py line 1400 ,1455 (message changes)
>
> This is vital for as reuse of volumes from Ocata to Pike. In Ocata we
> used SMIS to interface with the VMAX, in Pike we are using REST. A few
> changes needed to be made to make this transition as seamless as possible.
>
> Thank you,
> Helen
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/71aea9cf/attachment-0001.html>
>
> ------------------------------
>
> Message: 45
> Date: Wed, 2 Aug 2017 13:32:16 -0500
> From: Matthew Thode <prometheanfire at gentoo.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [release][requirements] FFE release for
> reno 2.5.0
> Message-ID: <20170802183216.GD27937 at gentoo.org>
> Content-Type: text/plain; charset="utf-8"
>
> On 17-08-02 23:18:19, Tony Breeds wrote:
> > On Wed, Aug 02, 2017 at 08:39:07AM -0400, Doug Hellmann wrote:
> > > We have a few projects that have modified stable branch release
> > > notes by editing the files on master, which makes those notes appear
> > > as part of the current release. Reno has a new option to address
> > > that problem by ignoring some note files, and I would like to release
> > > that version to allow project teams to fix up their release notes
> > > for pike. I really thought I had already released that update, so
> > > I'm sorry for the late request.
> > >
> > > Reno is only used during release notes builds, but it does appear
> > > in the global requirements list and constraints list. I think the
> > > risk is minimal.
> > >
> > > https://review.openstack.org/489998
> >
> > Package : reno [reno!=2.3.1,>=1.8.0] (used by 220 projects)
> > Also affects : 220 projects
> > <snip>
> >
> > So yeah it *could* destabalise the gate for a day if there is an issue.
> > I'm not saying that's likely but it has happened in the past.
> >
> > Looking at the reno change log I don't see anything that worries me.
> >
> > From a requirements POV I'm +2 on a u-c bump -2 on a g-r bump.
> >
> > Yours Tony.
>
> Agreed, the amount of projects that'd be impacted by a GR bump is too
> high, but a UC bump is fine.
>
> --
> Matthew Thode (prometheanfire)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/15b5cf1d/attachment-0001.sig>
>
> ------------------------------
>
> Message: 46
> Date: Wed, 2 Aug 2017 13:34:08 -0500
> From: Matthew Thode <prometheanfire at gentoo.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [requirements][release][docs] FFE for
> openstack-doc-tools
> Message-ID: <20170802183408.GE27937 at gentoo.org>
> Content-Type: text/plain; charset="utf-8"
>
> On 17-08-02 14:22:35, Andreas Jaeger wrote:
> > We need a new release of openstack-doc-tools to handle the changed
> > behaviour in how we build documents.
> >
> > The tool is only used by documentation projects for building and nowhere
> > else listed in requirements file.
> >
> > Please release this and take the new version in for requirements repo,
> >
> > https://review.openstack.org/490001
> >
> > Andreas
>
> Looks fine here, are you looking for just a UC bump?
>
> --
> Matthew Thode (prometheanfire)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/832bb3f1/attachment-0001.sig>
>
> ------------------------------
>
> Message: 47
> Date: Wed, 2 Aug 2017 14:34:40 -0400
> From: Sean Dague <sean at dague.net>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <867d07e4-9de8-59af-2c51-0ee30d11a930 at dague.net>
> Content-Type: text/plain; charset=utf-8
>
> On 08/02/2017 12:20 PM, Doug Hellmann wrote:
> > Excerpts from Akihiro Motoki's message of 2017-08-03 01:02:59 +0900:
> >> 2017-08-03 0:52 GMT+09:00 Doug Hellmann <doug at doughellmann.com>:
> >>> Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:
> >>>> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:
> >>>>> On 08/02/2017 09:22 AM, Stephen Finucane wrote:
> >>>>>> On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> >>>>>>> 3. The patch for the import of the admin guide [8] is missing some
> CLI
> >>>>>>> specific pages which are pretty useful given they aren't documented
> >>>>>>> anywhere else, like the forced_host part of the compute API [9].
> >>>>>>> Basically anything that's cli-nova-* in the admin guide should be
> in the
> >>>>>>> Nova docs. It's also missing the compute-flavors page [10] which is
> >>>>>>> pretty important for using OpenStack at all.
> >>>>>>
> >>>>>> This is a tricky one. Based on previous discussions with dhellmann,
> the
> >>>>>> plan
> >>>>>> seems to be to replace any references to 'nova xxx' or 'openstack
> xxx'
> >>>>>> commands
> >>>>>> (i.e. commands using python-novaclient or python-openstackclient)
> in favour
> >>>>>> of
> >>>>>> 'curl'-based requests. The idea here is that the Python clients are
> not the
> >>>>>> only clients available, and we shouldn't be "mandating" their use by
> >>>>>> referencing them in the docs. I get this, though I don't fully
> agree with
> >>>>>> it
> >>>>>> (who really uses curl?)
> >>>>>
> >>>>> Are we going to document the python clients elsewhere then?
> >>>>
> >>>> I think the docs would go into the respective python clients docs?
> >>>
> >>> Right. I don't remember the details of the curl discussion, but I
> >>> think what I was trying to say there was that the "nova" command
> >>> line tool installed via python-novaclient should be documented as
> >>> part of the openstack/python-novaclient repo rather than
> openstack/nova.
> >>> A CLI reference for nova-manage, which I think is in openstack/nova,
> >>> could be documented in openstack/nova.
> >>>
> >>> Basically, put the docs with the code, which is the whole point of this
> >>> migration.
> >>
> >> It is true for CLI reference.
> >> The gray zone is CLI stuffs in the admin guide and/or end-user guide.
> >> I think this is the point Matt raised.
> >> cli-nova-* stuffs in the admin guide was per topic like launching
> instance,
> >> migrating instances and so on. It is actually beyond the CLI reference
> to me.
> >> It is about how to use specific features of nova.
> >> IMHO this kind of stuffs can be covered by the admin guide or user
> guide,
> >> so it fits into openstack/nova (or other server projects).
> >
> > Yeah, I don't know.
> >
> > My gut response is to say that if the example uses nova-manage or
> > one of the nova service executables, then that makes sense to leave
> > in the nova tree, but otherwise it should go into either the
> > python-novaclient or python-openstackclient repositories (depending
> > on which command line tool is used in the example).
> >
> > On the other hand, I can see that being somewhat confusing for
> > someone who lands at the nova docs and can't find instructions for
> > how to use it. Maybe less confusing, though, than if I am not
> > *running* nova but am trying to use a nova deployed by someone else
> > and I start from the python-novaclient or python-openstackclient
> > docs because I installed one of those in order to talk to nova.
> >
> > I thought "put the docs with the code" would be a simple enough
> > rule that we wouldn't have to think too hard about where to put
> > individual example files, which would speed up the migration.
>
> It's not so simple because years ago we decided nova-manage was mostly a
> bad thing (as you needed to run it on the API node and be able to read
> db creds with it), and exposed as much as possible of the administrative
> interfaces over the API. The policy of openstack client was that
> administrative commands would not go in openstack client. So a bunch of
> what was once nova-manage (5 years ago), is part of the nova cli now,
> and not really implemented by other toolkits.
>
> This is also why the python nova client is not going away any time soon.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
>
> ------------------------------
>
> Message: 48
> Date: Wed, 2 Aug 2017 14:37:14 -0400
> From: Sean Dague <sean at dague.net>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <815c61d5-cde6-b1c5-b6da-068181ed5b93 at dague.net>
> Content-Type: text/plain; charset=utf-8
>
> On 08/02/2017 12:28 PM, Clark Boylan wrote:
> > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> >> Now that Stephen Finucane is back from enjoying his youth and
> >> gallivanting all over Europe, and we talked about a few things in IRC
> >> this morning on the docs migration for Nova, I wanted to dump my
> >> concerns here for broader consumption.
> >>
> >> 1. We know we have to fix a bunch of broken links by adding in redirects
> >> [1] which sdague started here [2]. However, that apparently didn't catch
> >> everything, e.g. [3], so I'm concerned we're missing other broken links.
> >> Is there a way to find out?
> >
> > The infra team can generate lists of 404 urls fairly easily on the docs
> > server. This won't show you everything but will show you what urls
> > people are finding/using that 404.
>
> If we could get a weekly report of 404 urls posted somewhere public,
> that would be extremely useful, because the easy ones based on git
> renames are done, and everything else is going to require human
> inspection to figure out what the right landing target is.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
>
> ------------------------------
>
> Message: 49
> Date: Wed, 2 Aug 2017 13:42:20 -0500
> From: Anne Gentle | Just Write Click <annegentle at justwriteclick.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID: <21A1E90D-8750-4B33-9E0C-38CF1DB7C82B at justwriteclick.com>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On Aug 2, 2017, at 1:37 PM, Sean Dague <sean at dague.net> wrote:
> >
> >> On 08/02/2017 12:28 PM, Clark Boylan wrote:
> >>> On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> >>> Now that Stephen Finucane is back from enjoying his youth and
> >>> gallivanting all over Europe, and we talked about a few things in IRC
> >>> this morning on the docs migration for Nova, I wanted to dump my
> >>> concerns here for broader consumption.
> >>>
> >>> 1. We know we have to fix a bunch of broken links by adding in
> redirects
> >>> [1] which sdague started here [2]. However, that apparently didn't
> catch
> >>> everything, e.g. [3], so I'm concerned we're missing other broken
> links.
> >>> Is there a way to find out?
> >>
> >> The infra team can generate lists of 404 urls fairly easily on the docs
> >> server. This won't show you everything but will show you what urls
> >> people are finding/using that 404.
> >
> > If we could get a weekly report of 404 urls posted somewhere public,
> > that would be extremely useful, because the easy ones based on git
> > renames are done, and everything else is going to require human
> > inspection to figure out what the right landing target is.
> >
>
> Fantastic idea.
>
> I love how many more ideas we are getting as more brains share them.
>
> > -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> > ____________________________________________________________
> ______________
> > 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: 50
> Date: Wed, 2 Aug 2017 20:44:25 +0200
> From: Andreas Jaeger <aj at suse.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [requirements][release][docs] FFE for
> openstack-doc-tools
> Message-ID: <50d14336-3d83-82fc-a498-800b3ad3c3d0 at suse.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 2017-08-02 20:34, Matthew Thode wrote:
> > On 17-08-02 14:22:35, Andreas Jaeger wrote:
> >> We need a new release of openstack-doc-tools to handle the changed
> >> behaviour in how we build documents.
> >>
> >> The tool is only used by documentation projects for building and nowhere
> >> else listed in requirements file.
> >>
> >> Please release this and take the new version in for requirements repo,
> >>
> >> https://review.openstack.org/490001
> >>
> >> Andreas
> >
> > Looks fine here, are you looking for just a UC bump?
>
> After reviewing the affected repos: let's just do the UC bump,
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
>
>
> ------------------------------
>
> Message: 51
> Date: Wed, 2 Aug 2017 11:44:43 -0700
> From: Michał Jastrzębski <inc007 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [kolla][PTL][elections] Candidacy for Kolla
> PTL
> Message-ID:
> <CALc0zUDB-8Z9s1uG7hJdfZXUbFpjTH53+0Z-_
> 6HTVfE_vNUd-Q at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello everyone,
>
> Once more unto the breach dear friends! I would like to run for PTL again
> for
> Queens. Pike was very exciting release for Kolla. With strong focus on
> Kolla-Kubernetes, Kolla-Ansible getting more and more production
> deployments
> and Kolla images being successfully consumed by project outside of Kolla
> like TripleO or OpenStack-Helm, I think this was quite a success for us.
>
> We managed to improve one of biggest pain points we saw in Kolla - gates.
> We
> still have lengths to go, but progress is significant.
>
> I'd love to help our community to make Queens even better. We have several
> exiting features in our plates, like automated push mechanism for images or
> orchestration layer for kolla-kubernetes.
>
> We also need to focus on another big pain point of Kolla - documentation.
>
> I would like us to strengthen cooperation with Kubernetes community and I'm
> strong believer that best bridge between communities is built on top of
> common
> technical issues and mutual help. I think Kolla-Kubernetes naturally helps
> with this cooperation and we can use it even more.
>
> Per request, I also add small haiku to my nomination;)
>
> Glues Stack together
> Project by great people made
> Queens approaching soon
>
> Regards,
> Michal inc0 Jastrzebski
>
>
>
> ------------------------------
>
> Message: 52
> Date: Wed, 2 Aug 2017 12:15:10 -0700
> From: "Catherine Cuong Diep" <cdiep at us.ibm.com>
> To: openstack-dev at lists.openstack.org, interop-wg at lists.openstack.org
> Subject: [openstack-dev] [refstack][interop-wg] Non-candidacy for
> RefStack PTL
> Message-ID:
> <OF451E760C.DC645181-ON00258170.00690983-88258170.
> 0069C25F at notes.na.collabserv.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>
> Hi Everyone,
>
> As I had announced in the RefStack IRC meeting a few weeks ago, I will not
> run for RefStack PTL in the upcoming cycle. I have been PTL for the last 2
> years and it is time to pass the torch to a new leader.
>
> I would like to thanks everyone for your support and contribution to make
> the RefStack project and interoperability testing a reality. We would not
> be where we are today without your
> commitment and dedication.
>
> I will still be around to help the project and to work with the next PTL
> for a smooth transition.
>
> Catherine Diep
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/3cbb7019/attachment-0001.html>
>
> ------------------------------
>
> Message: 53
> Date: Wed, 2 Aug 2017 14:32:41 -0500
> From: Dean Troyer <dtroyer at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID:
> <CAOJFoEtASL4it3cg3vrkSCU1yg2V8Jv2bd=XmSiMn06MrEw7Ww at mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, Aug 2, 2017 at 11:20 AM, Doug Hellmann <doug at doughellmann.com>
> wrote:
> > My gut response is to say that if the example uses nova-manage or
> > one of the nova service executables, then that makes sense to leave
> > in the nova tree, but otherwise it should go into either the
> > python-novaclient or python-openstackclient repositories (depending
> > on which command line tool is used in the example).
>
> I don't think this is a good rule of thumb...
>
> > On the other hand, I can see that being somewhat confusing for
> > someone who lands at the nova docs and can't find instructions for
> > how to use it. Maybe less confusing, though, than if I am not
> > *running* nova but am trying to use a nova deployed by someone else
> > and I start from the python-novaclient or python-openstackclient
> > docs because I installed one of those in order to talk to nova.
>
> When the point of the example is to illustrate configuring nova, the
> example should stay with the nova code, even if it uses novaclient or
> osc. The examples that are about _using_ novaclient or osc belong in
> those repos, but where they are just a means to configuring something
> in nova, they should remain with nova and use the tools that users are
> expected to be familiar with (novaclient and/or osc in this example).
>
> > I thought "put the docs with the code" would be a simple enough
> > rule that we wouldn't have to think too hard about where to put
> > individual example files, which would speed up the migration.
>
> If I find a doc that tells me how to set up a VM with a Neutron
> network and ports and subnets and floating IPs that uses curl, I'm not
> reading farther.
>
> dt
>
> --
>
> Dean Troyer
> dtroyer at gmail.com
>
>
>
> ------------------------------
>
> Message: 54
> Date: Wed, 02 Aug 2017 13:44:26 -0700
> From: Clark Boylan <cboylan at sapwetik.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration
> Message-ID:
> <1501706666.1436702.1061272472.67255022 at webmail.
> messagingengine.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Aug 2, 2017, at 11:37 AM, Sean Dague wrote:
> > On 08/02/2017 12:28 PM, Clark Boylan wrote:
> > > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> > >> Now that Stephen Finucane is back from enjoying his youth and
> > >> gallivanting all over Europe, and we talked about a few things in IRC
> > >> this morning on the docs migration for Nova, I wanted to dump my
> > >> concerns here for broader consumption.
> > >>
> > >> 1. We know we have to fix a bunch of broken links by adding in
> redirects
> > >> [1] which sdague started here [2]. However, that apparently didn't
> catch
> > >> everything, e.g. [3], so I'm concerned we're missing other broken
> links.
> > >> Is there a way to find out?
> > >
> > > The infra team can generate lists of 404 urls fairly easily on the docs
> > > server. This won't show you everything but will show you what urls
> > > people are finding/using that 404.
> >
> > If we could get a weekly report of 404 urls posted somewhere public,
> > that would be extremely useful, because the easy ones based on git
> > renames are done, and everything else is going to require human
> > inspection to figure out what the right landing target is.
> >
>
> I've pushed https://review.openstack.org/#/c/490175/ which will generate
> a report each day for roughly the last day's worth of 404s. You should
> be able to see them at https://docs.openstack.org/404s once the change
> merges and the cron job fires.
>
> You can see what that will look like (from my test runs) at
> http://paste.openstack.org/show/617322/. Note that this isn't a complete
> file because paste.openstack.org truncated it but you'll get the full
> data from the wbeserver once this change merges.
>
> Clark
>
>
>
> ------------------------------
>
> Message: 55
> Date: Wed, 2 Aug 2017 15:47:32 -0500
> From: Major Hayden <major at mhtx.net>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [openstack-ansible][security] To
> firewalld, or not to firewalld
> Message-ID: <1d83331d-5c63-2a00-74b2-628e8332f9bf at mhtx.net>
> Content-Type: text/plain; charset=utf-8
>
> On 08/02/2017 03:57 AM, Mark Goddard wrote:
> > The solution we built used a conf.d/ mechanism layered on top of
> iptables. An advantage of this approach is that operators or co-resident
> software stacks could add their own rules to the firewall. AFAIK, this is
> not generally possible when using iptables-save/restore as it relies on a
> single configuration file which must be 'owned' by something - in this case
> presumably OSA.
> >
> > I'm not suggesting that you reimplement the solution I've described, but
> it does outline one benefit of firewalld - OSA would not need to entirely
> own the firewall configuration.
>
> Thanks for the feedback! I'm leaning away from firewalld now and looking
> at something a little simpler with iptables.
>
> During a recent IRC meeting someone brought up ferm[0]. They have several
> examples, but the workstation[1] one makes some sense. It would be fairly
> easy to template the ferm DSL files.
>
> [0] http://ferm.foo-projects.org/
> [1] http://ferm.foo-projects.org/download/examples/webserver.ferm
>
> --
> Major Hayden
>
>
>
> ------------------------------
>
> Message: 56
> Date: Wed, 2 Aug 2017 20:50:06 +0000
> From: "McLellan, Steven" <steve.mclellan at hpe.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [searchlight] Cancelling IRC meeting August
> 2nd
> Message-ID: <D7C217D9-DB43-4585-916E-030AA1C6D72A at hpe.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Apologies for the short notice, but I'm cancelling the IRC meeting for
> August 2nd as I have a family commitment tomorrow morning. We'll resume as
> normal next week.
>
> Thanks,
>
> Steve
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170802/33723f98/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> 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 64, Issue 5
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170805/d4d9d0d1/attachment-0001.html>
More information about the OpenStack-dev
mailing list