
<div dir="ltr">+1<div><br></div><div>best regards,</div><div>Dongfeng Huang</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">2017-08-03 4:50 GMT+08:00  <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>

        <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

<br>

To subscribe or unsubscribe via the World Wide Web, visit<br>

        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

or, via email, send a message with subject or body 'help' to<br>

        <a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.<wbr>openstack.org</a><br>

<br>

You can reach the person managing the list at<br>

        <a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.<wbr>openstack.org</a><br>

<br>

When replying, please edit your Subject line so it is more specific<br>

than "Re: Contents of OpenStack-dev digest..."<br>

<br>

<br>

Today's Topics:<br>

<br>

   1. Re: [SPAM] [all][docs] recruiting for help with documentation<br>

      tools (Thierry Carrez)<br>

   2. Re: [Cinder] Requirements for re-adding Gluster support<br>

      (Niels de Vos)<br>

   3. [cinder] Apply for exception to having Storwize cinder<br>

      Tiramisu replication patch reviewed and merged (Xiao Qin SH Li)<br>

   4. Re: [SPAM] [all][docs] recruiting for help with   documentation<br>

      tools (Doug Hellmann)<br>

   5. Re: [all][docs] recruiting for help with  documentation tools<br>

      (Doug Hellmann)<br>

   6. Re: [all][docs] recruiting for help with  documentation tools<br>

      (Doug Hellmann)<br>

   7. [requirements][release][docs] FFE for     openstack-doc-tools<br>

      (Andreas Jaeger)<br>

   8.  [Tricircle] Queens PTL candidacy (Vega Cai)<br>

   9. [release][requirements] FFE release for reno 2.5.0 (Doug Hellmann)<br>

  10. Re: [release][requirements] FFE release for reno 2.5.0<br>

      (Thierry Carrez)<br>

  11. [watcher] nominate Aditi Sharma to Watcher Core   group<br>

      (Чадин Александр (Alexander Chadin))<br>

  12. Re: [release][requirements] FFE release for reno 2.5.0<br>

      (Tony Breeds)<br>

  13. [elections] [puppet] Candidacy for Puppet OpenStack       PTL<br>

      (Queens) (Mohammed Naser)<br>

  14. Re: [requirements][release][docs] FFE for openstack-doc-tools<br>

      (Tony Breeds)<br>

  15. Fwd: ETSI NFV - OpenStack PTG in Denver (Ildiko Vancsa)<br>

  16. [elections][tripleo] Queens PTL candidacy (Alex Schultz)<br>

  17. [oslo][barbican][sahara] start RPC service before launcher<br>

      wait? (Ken Giusti)<br>

  18. [all] Only 40 days to PTG ! (Thierry Carrez)<br>

  19. Re: [all] Only 40 days to PTG ! (Davanum Srinivas)<br>

  20. Re: [elections][tripleo] Queens PTL candidacy<br>

      (<a href="mailto:Arkady.Kanevsky@dell.com">Arkady.Kanevsky@dell.com</a>)<br>

  21. [nova][docs] Concerns with docs migration (Matt Riedemann)<br>

  22. Re: [cinder] Apply for exception to having Storwize cinder<br>

      Tiramisu replication patch reviewed and merged (Sean McGinnis)<br>

  23. Re: Trying again on wait_for_compute in devstack (Matt Riedemann)<br>

  24. Re: [devstack] [ironic] [nova] Trying again on<br>

      wait_for_compute in devstack (Sean Dague)<br>

  25. [keystone][policy] no policy meeting today        2017-08-02<br>

      (Lance Bragstad)<br>

  26. Re: Trying again on wait_for_compute in devstack (Matt Riedemann)<br>

  27. Re: [nova][docs] Concerns with docs migration (Stephen Finucane)<br>

  28. Re: [nova][docs] Concerns with docs migration (Stephen Finucane)<br>

  29. [trove] Can we move some non-voting broken jobs to the<br>

      experimental queue? (Matt Riedemann)<br>

  30. Re: [nova][docs] Concerns with docs migration (Chris Friesen)<br>

  31. Re: [nova][docs] Concerns with docs migration (Chris Dent)<br>

  32. Re: [nova][docs] Concerns with docs migration (Stephen Finucane)<br>

  33. Re: [nova][docs] Concerns with docs migration (Doug Hellmann)<br>

  34. Re: [nova][docs] Concerns with docs migration (Akihiro Motoki)<br>

  35. Re: [nova][docs] Concerns with docs migration (Akihiro Motoki)<br>

  36. Re: [nova][docs] Concerns with docs migration (Doug Hellmann)<br>

  37. Re: [tripleo] Proposing Bogdan Dobrelya core on TripleO /<br>

      Containers (Carlos Camacho Gonzalez)<br>

  38. [all] Rollout of Zuul v3 at the PTG (Monty Taylor)<br>

  39. Re: [nova][docs] Concerns with docs migration (Clark Boylan)<br>

  40. Re: [nova][docs] Concerns with docs migration (Stephen Finucane)<br>

  41. Re: [Tacker] Proposing yanxingan for Tacker core<br>

      (Sridhar Ramaswamy)<br>

  42. Re: [nova][docs] Concerns with docs migration (Mathieu Gagné)<br>

  43. Re: [OpenStack-Ansible] Not running for Queens PTL<br>

      (Lance Bragstad)<br>

  44. string freeze exception for VMAX driver (Walsh, Helen)<br>

  45. Re: [release][requirements] FFE release for reno 2.5.0<br>

      (Matthew Thode)<br>

  46. Re: [requirements][release][docs] FFE for openstack-doc-tools<br>

      (Matthew Thode)<br>

  47. Re: [nova][docs] Concerns with docs migration (Sean Dague)<br>

  48. Re: [nova][docs] Concerns with docs migration (Sean Dague)<br>

  49. Re: [nova][docs] Concerns with docs migration<br>

      (Anne Gentle | Just Write Click)<br>

  50. Re: [requirements][release][docs] FFE for openstack-doc-tools<br>

      (Andreas Jaeger)<br>

  51. [kolla][PTL][elections] Candidacy for Kolla PTL<br>

      (Michał Jastrzębski)<br>

  52. [refstack][interop-wg] Non-candidacy for RefStack PTL<br>

      (Catherine Cuong Diep)<br>

  53. Re: [nova][docs] Concerns with docs migration (Dean Troyer)<br>

  54. Re: [nova][docs] Concerns with docs migration (Clark Boylan)<br>

  55. Re: [openstack-ansible][security] To firewalld, or not to<br>

      firewalld (Major Hayden)<br>

  56.  [searchlight] Cancelling IRC meeting August 2nd<br>

      (McLellan, Steven)<br>

<br>

<br>

------------------------------<wbr>------------------------------<wbr>----------<br>

<br>

Message: 1<br>

Date: Wed, 2 Aug 2017 14:01:47 +0200<br>

From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [SPAM] [all][docs] recruiting for help<br>

        with documentation tools<br>

Message-ID: <<a href="mailto:53030039-def1-a070-2ae9-7da26d8a9dec@openstack.org">53030039-def1-a070-2ae9-<wbr>7da26d8a9dec@openstack.org</a>><br>

Content-Type: text/plain; charset=utf-8<br>

<br>

Doug Hellmann wrote:<br>

> [...]<br>

> The areas we need help are maintaining the doc build jobs, the<br>

> sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,<br>

> and the template build tool in the openstack-manuals git repo. These<br>

> are all minimally complete, but there is definitely feature work<br>

> and bug fixing to do. I can guarantee that, if you sign up to help,<br>

> you will have a chance to land changes that will be visible for all<br>

> OpenStack users. At the start of Queens, I will be doing some<br>

> one-on-one training with volunteers to ensure they understand the<br>

> system we have in place now and help them start on some of the<br>

> remaining feature work.<br>

> [...]<br>

Feels like the doc owners/liaisons that we are looking for in the Top 5<br>

help wanted list[1] would be in a good position to help with that.<br>

Should we extend the description of the need so that it's clearer that<br>

help with maintaining the doc toolchain is also a top wanted thing ?<br>

<br>

[1]<br>

<a href="https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners" rel="noreferrer" target="_blank">https://governance.openstack.<wbr>org/tc/reference/top-5-help-<wbr>wanted.html#documentation-<wbr>owners</a><br>

<br>

--<br>

Thierry Carrez (ttx)<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 2<br>

Date: Wed, 2 Aug 2017 14:04:15 +0200<br>

From: Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Cc: <a href="mailto:integration@gluster.org">integration@gluster.org</a><br>

Subject: Re: [openstack-dev] [Cinder] Requirements for re-adding<br>

        Gluster support<br>

Message-ID: <<a href="mailto:20170802120415.GF21449@ndevos-x240.usersys.redhat.com">20170802120415.GF21449@<wbr>ndevos-x240.usersys.redhat.com</a><wbr>><br>

Content-Type: text/plain; charset=us-ascii<br>

<br>

Thanks to everyone who replied! I'll try to summarize what we'll try to<br>

get from the Gluster Community users that run OpenStack.<br>

<br>

- find an owner/maintainer for the Gluster driver in Cinder<br>

  little maintenance seems needed, no recent problems reported<br>

<br>

- get someone to maintain the gate job(s) in a CI environment of their<br>

  own choosing (OpenStack Infra, Gluster Community, CentOS CI, ..)<br>

<br>

- send a patch to revert the change for removing the driver from Cinder<br>

<br>

- send a patch to revert the change for removing the driver from Nova<br>

<br>

<br>

With these tasks I'll try to find some of the OpenStack users in the<br>

Gluster Community that want to volunteer for this. There are a few<br>

Gluster developers (from Red Hat) that can assist these volunteers, but<br>

developers working for Red Hat will not have this as a priority. It<br>

falls in the "support the Gluster Community" bucket, and community users<br>

will need to do most of the work. This is similar for any of the other<br>

Open Source projects where Gluster is not productized by Red Hat.<br>

<br>

A similar approach by Red Hat developers working on Cinder caused the<br>

volume driver to be removed. We hope that interested users will step up<br>

and offer their time.<br>

<br>

Please let me know if I missed something or if this approach is<br>

unacceptible or unclear.<br>

<br>

Cheers,<br>

Niels<br>

<br>

<br>

On Wed, Jul 26, 2017 at 12:56:55PM +0200, Niels de Vos wrote:<br>

> Hello,<br>

><br>

> In one of the last Cinder releases support for Gluster has been dropped.<br>

> The commit message [1] mentions that the support has been marked<br>

> deprecated during Newton.<br>

><br>

> It seems that there are quite some users in the Gluster Community that<br>

> run OpenStack with Gluster storage. These users did not take action when<br>

> Newton came out, but voiced their disappointment with more recent<br>

> releases.<br>

><br>

> As one of the Gluster Maintainers that is watching over the integration<br>

> of Gluster in other projects, I would like to know more about the tasks<br>

> that it takes to get Gluster support back into Cinder. With those<br>

> details, the Gluster Community can work with interested OpenStack users<br>

> to add required CI jobs, and possibly other things.<br>

><br>

> At the moment, the only knowledge I have on why Gluster support was<br>

> removed from Cinder is in a messy email conversation [2]. Pointers to<br>

> further clarifications and requirements that Gluster did not meet are<br>

> welcome.<br>

><br>

> My current guess is that adding a 3rd party CI [3] for Gluster is the<br>

> only missing piece? If that is the case, I expect that we could add one<br>

> or more Jenkins jobs to one of our Gluster Community CI's. We run tests<br>

> in our own Jenkins instance [4], but also use the CentOS CI [5] for some<br>

> heavier testing.<br>

><br>

> Any guidance, suggestions and opinions are most welcome!<br>

><br>

> Many thanks,<br>

> Niels<br>

><br>

><br>

> 1. <a href="https://github.com/openstack/cinder/commit/16e93ccd4f3a6d62ed9d277f03b64bccc63ae060" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>cinder/commit/<wbr>16e93ccd4f3a6d62ed9d277f03b64b<wbr>ccc63ae060</a><br>

> 2. <a href="http://lists.gluster.org/pipermail/integration/2017-May/000024.html" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>pipermail/integration/2017-<wbr>May/000024.html</a><br>

> 3. <a href="https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers" rel="noreferrer" target="_blank">https://wiki.openstack.org/<wbr>wiki/Cinder/tested-3rdParty-<wbr>drivers</a><br>

> 4. <a href="https://build.gluster.org/" rel="noreferrer" target="_blank">https://build.gluster.org/</a><br>

> 5. <a href="https://ci.centos.org/view/Gluster/" rel="noreferrer" target="_blank">https://ci.centos.org/view/<wbr>Gluster/</a><br>

><br>

> ______________________________<wbr>______________________________<wbr>______________<br>

> OpenStack Development Mailing List (not for usage questions)<br>

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 3<br>

Date: Wed, 2 Aug 2017 12:07:06 +0000<br>

From: "Xiao Qin SH Li" <<a href="mailto:lixqin@cn.ibm.com">lixqin@cn.ibm.com</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Cc: Yi Ming YZ Zhang <<a href="mailto:zymzhang@cn.ibm.com">zymzhang@cn.ibm.com</a>><br>

Subject: [openstack-dev] [cinder] Apply for exception to having<br>

        Storwize cinder Tiramisu replication patch reviewed and merged<br>

Message-ID:<br>

        <<a href="mailto:OF24EF5DB8.BFD02DA7-ON00258170.00425B94-00258170.004291A9@notes.na.collabserv.com">OF24EF5DB8.BFD02DA7-<wbr>ON00258170.00425B94-00258170.<wbr>004291A9@notes.na.collabserv.<wbr>com</a>><br>

<br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/10a6a8c2/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/10a6a8c2/<wbr>attachment-0001.html</a>><br>

<br>

------------------------------<br>

<br>

Message: 4<br>

Date: Wed, 02 Aug 2017 08:17:47 -0400<br>

From: Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>

To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [SPAM] [all][docs] recruiting for help<br>

        with    documentation tools<br>

Message-ID: <1501676214-sup-1408@lrrr.<wbr>local><br>

Content-Type: text/plain; charset=UTF-8<br>

<br>

Excerpts from Thierry Carrez's message of 2017-08-02 14:01:47 +0200:<br>

> Doug Hellmann wrote:<br>

> > [...]<br>

> > The areas we need help are maintaining the doc build jobs, the<br>

> > sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,<br>

> > and the template build tool in the openstack-manuals git repo. These<br>

> > are all minimally complete, but there is definitely feature work<br>

> > and bug fixing to do. I can guarantee that, if you sign up to help,<br>

> > you will have a chance to land changes that will be visible for all<br>

> > OpenStack users. At the start of Queens, I will be doing some<br>

> > one-on-one training with volunteers to ensure they understand the<br>

> > system we have in place now and help them start on some of the<br>

> > remaining feature work.<br>

> > [...]<br>

> Feels like the doc owners/liaisons that we are looking for in the Top 5<br>

> help wanted list[1] would be in a good position to help with that.<br>

> Should we extend the description of the need so that it's clearer that<br>

> help with maintaining the doc toolchain is also a top wanted thing ?<br>

><br>

> [1]<br>

> <a href="https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners" rel="noreferrer" target="_blank">https://governance.openstack.<wbr>org/tc/reference/top-5-help-<wbr>wanted.html#documentation-<wbr>owners</a><br>

><br>

<br>

I'm torn on that. On the one hand, I would like to recruit. On the<br>

other, we do need far more content contributors than tool maintainers.<br>

Let's wait and see. There were 2 responses to this thread already, so<br>

maybe we won't need to go that far.<br>

<br>

Doug<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 5<br>

Date: Wed, 02 Aug 2017 08:18:58 -0400<br>

From: Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>

To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [all][docs] recruiting for help with<br>

        documentation tools<br>

Message-ID: <1501676296-sup-129@lrrr.local<wbr>><br>

Content-Type: text/plain; charset=UTF-8<br>

<br>

Excerpts from Swapnil Kulkarni's message of 2017-08-02 14:35:49 +0530:<br>

> On Wed, Aug 2, 2017 at 2:25 PM, Bogdan Dobrelya <<a href="mailto:bdobreli@redhat.com">bdobreli@redhat.com</a>> wrote:<br>

> > On 01.08.2017 21:35, Doug Hellmann wrote:<br>

> >> With the changes we've made to docs processes upstream, every team<br>

> >> is going to need to build up their knowledge of how the new<br>

> >> documentation tools and jobs work. The docs team will still help,<br>

> >> but things will obviously go more smoothly if folks know how the<br>

> >> tools work, now that the bulk of the content is in-tree with the<br>

> >> code.<br>

> >><br>

> >> At the same time, the docs team could use help with developing and<br>

> >> maintaining those tools. We have a couple people working on them<br>

> >> now (me, Andreas, and Anne), but none of us is doing it full time.<br>

> >> I need to transition off of this work, so over the course of Queens<br>

> >> I will be trying to build up the skills of the existing team so<br>

> >> they do not need to rely on me so much. Also, Andreas and Anne have<br>

> >> said that they cannot commit to driving any work.<br>

> >><br>

> >> Although the documentation team has some skills in this area, they<br>

> >> could use help, so I would like to find a few people to join the<br>

> >> team specifically to work on the tooling (although if you wanted<br>

> >> to write documentation, too, no one will object).<br>

> >><br>

> >> Some of you have been helping informally (thank you!), but the<br>

> >> community shift is big enough that we need to account for the new<br>

> >> need a bit more formally. I think if we could find several people<br>

> >> who could give a small percentage of their time (10%?), we would<br>

> >> be well covered. There will not be work every week, but when there<br>

> >> is something to do it's likely to take a small extended period (1-2<br>

> >> days) to add a feature or resolve an issue. If we found 4-6 people,<br>

> >> I think we would be covered and have a sustainable group.<br>

> >><br>

> >> The areas we need help are maintaining the doc build jobs, the<br>

> >> sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,<br>

> >> and the template build tool in the openstack-manuals git repo. These<br>

> >> are all minimally complete, but there is definitely feature work<br>

> >> and bug fixing to do. I can guarantee that, if you sign up to help,<br>

> >> you will have a chance to land changes that will be visible for all<br>

> >> OpenStack users. At the start of Queens, I will be doing some<br>

> >> one-on-one training with volunteers to ensure they understand the<br>

> >> system we have in place now and help them start on some of the<br>

> >> remaining feature work.<br>

> >><br>

> >> If you are interested in helping, please let me know by following<br>

> >> up to this thread, and then join #openstack-docs on IRC.<br>

> ><br>

> > +1<br>

> ><br>

> >><br>

> >> Doug<br>

> >><br>

> >> ______________________________<wbr>______________________________<wbr>______________<br>

> >> OpenStack Development Mailing List (not for usage questions)<br>

> >> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

> >><br>

> ><br>

> ><br>

> > --<br>

> > Best regards,<br>

> > Bogdan Dobrelya,<br>

> > Irc #bogdando<br>

> ><br>

> > ______________________________<wbr>______________________________<wbr>______________<br>

> > OpenStack Development Mailing List (not for usage questions)<br>

> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

><br>

><br>

> +1<br>

><br>

<br>

Thanks, Bogdan and Swapnil, I'm happy to have you on board!<br>

<br>

Doug<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 6<br>

Date: Wed, 02 Aug 2017 08:20:53 -0400<br>

From: Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>

To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [all][docs] recruiting for help with<br>

        documentation tools<br>

Message-ID: <1501676408-sup-9756@lrrr.<wbr>local><br>

Content-Type: text/plain; charset=UTF-8<br>

<br>

Excerpts from Doug Hellmann's message of 2017-08-01 15:35:35 -0400:<br>

> With the changes we've made to docs processes upstream, every team<br>

> is going to need to build up their knowledge of how the new<br>

> documentation tools and jobs work. The docs team will still help,<br>

> but things will obviously go more smoothly if folks know how the<br>

> tools work, now that the bulk of the content is in-tree with the<br>

> code.<br>

><br>

> At the same time, the docs team could use help with developing and<br>

> maintaining those tools. We have a couple people working on them<br>

> now (me, Andreas, and Anne), but none of us is doing it full time.<br>

> I need to transition off of this work, so over the course of Queens<br>

> I will be trying to build up the skills of the existing team so<br>

> they do not need to rely on me so much. Also, Andreas and Anne have<br>

> said that they cannot commit to driving any work.<br>

><br>

> Although the documentation team has some skills in this area, they<br>

> could use help, so I would like to find a few people to join the<br>

> team specifically to work on the tooling (although if you wanted<br>

> to write documentation, too, no one will object).<br>

><br>

> Some of you have been helping informally (thank you!), but the<br>

> community shift is big enough that we need to account for the new<br>

> need a bit more formally. I think if we could find several people<br>

> who could give a small percentage of their time (10%?), we would<br>

> be well covered. There will not be work every week, but when there<br>

> is something to do it's likely to take a small extended period (1-2<br>

> days) to add a feature or resolve an issue. If we found 4-6 people,<br>

> I think we would be covered and have a sustainable group.<br>

><br>

> The areas we need help are maintaining the doc build jobs, the<br>

> sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,<br>

> and the template build tool in the openstack-manuals git repo. These<br>

> are all minimally complete, but there is definitely feature work<br>

> and bug fixing to do. I can guarantee that, if you sign up to help,<br>

> you will have a chance to land changes that will be visible for all<br>

> OpenStack users. At the start of Queens, I will be doing some<br>

> one-on-one training with volunteers to ensure they understand the<br>

> system we have in place now and help them start on some of the<br>

> remaining feature work.<br>

><br>

> If you are interested in helping, please let me know by following<br>

> up to this thread, and then join #openstack-docs on IRC.<br>

><br>

> Doug<br>

><br>

<br>

If you want an idea of the sorts of work ahead, check out the tracking<br>

pad: <a href="https://etherpad.openstack.org/p/doc-future-problems" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/doc-future-problems</a><br>

<br>

Not everything on that list is related to the tools, but quite a lot is.<br>

<br>

Doug<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 7<br>

Date: Wed, 2 Aug 2017 14:22:35 +0200<br>

From: Andreas Jaeger <<a href="mailto:aj@suse.com">aj@suse.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [requirements][release][docs] FFE for<br>

        openstack-doc-tools<br>

Message-ID: <<a href="mailto:68048723-5543-20d4-07d3-43ec21ee8bd2@suse.com">68048723-5543-20d4-07d3-<wbr>43ec21ee8bd2@suse.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

We need a new release of openstack-doc-tools to handle the changed<br>

behaviour in how we build documents.<br>

<br>

The tool is only used by documentation projects for building and nowhere<br>

else listed in requirements file.<br>

<br>

Please release this and take the new version in for requirements repo,<br>

<br>

<a href="https://review.openstack.org/490001" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>490001</a><br>

<br>

Andreas<br>

--<br>

 Andreas Jaeger aj@{<a href="http://suse.com" rel="noreferrer" target="_blank">suse.com</a>,<a href="http://opensuse.org" rel="noreferrer" target="_blank">opensuse.org</a>} Twitter: jaegerandi<br>

  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany<br>

   GF: Felix Imendörffer, Jane Smithard, Graham Norton,<br>

       HRB 21284 (AG Nürnberg)<br>

    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126<br>

<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 8<br>

Date: Wed, 02 Aug 2017 12:30:00 +0000<br>

From: Vega Cai <<a href="mailto:luckyvega.g@gmail.com">luckyvega.g@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev]  [Tricircle] Queens PTL candidacy<br>

Message-ID:<br>

        <CAN33iADM-<wbr>NHMW8nf0AtJZ1Z8Ep32TO4=<a href="mailto:G8KPSqTCuK2CHDqYGg@mail.gmail.com">G8KPSqT<wbr>CuK2CHDqYGg@mail.gmail.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

Hi all,<br>

<br>

I would like to announce my self nomination for the PTL candidacy in<br>

Tricircle Queens cycle. My name is Zhiyuan Cai, and my IRC handle is<br>

zhiyuan. As a core reviewer of Tricircle project, I have been actively<br>

participating in the development of this project since Mitaka cycle.<br>

<br>

During the Pike cycle, many fancy features are brought to Tricircle, like<br>

VxLAN support for cross Neutron L2/L3 networking, VLAN aware VMs, service<br>

function chaining; reliability and performance are improved for the<br>

asynchronous job running daemon; multi-region gate job is set up to test<br>

Tricircle in a real running OpenStack environment, a YAML based task schema<br>

is introduced to help developers to define the test scenario more easily.<br>

<br>

For the coming Queens cycle, here are some works we can focus on:<br>

<br>

* Continue the development of advanced networking features, like QoS and<br>

LBaaS.<br>

* Improve the test scenario coverage of multi-region gate job.<br>

* Examine the integration with Nova cell V2.<br>

<br>

Hope everyone will enjoy running and developing Tricircle.<br>

<br>

Thank you for your kind consideration of my candidacy.<br>

<br>

Best Regards<br>

Zhiyuan<br>

--<br>

BR<br>

Zhiyuan<br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/65d95aa3/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/65d95aa3/<wbr>attachment-0001.html</a>><br>

<br>

------------------------------<br>

<br>

Message: 9<br>

Date: Wed, 02 Aug 2017 08:39:07 -0400<br>

From: Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: [openstack-dev] [release][requirements] FFE release for reno<br>

        2.5.0<br>

Message-ID: <1501677350-sup-3895@lrrr.<wbr>local><br>

Content-Type: text/plain; charset=UTF-8<br>

<br>

We have a few projects that have modified stable branch release<br>

notes by editing the files on master, which makes those notes appear<br>

as part of the current release. Reno has a new option to address<br>

that problem by ignoring some note files, and I would like to release<br>

that version to allow project teams to fix up their release notes<br>

for pike. I really thought I had already released that update, so<br>

I'm sorry for the late request.<br>

<br>

Reno is only used during release notes builds, but it does appear<br>

in the global requirements list and constraints list. I think the<br>

risk is minimal.<br>

<br>

<a href="https://review.openstack.org/489998" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>489998</a><br>

<br>

Doug<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 10<br>

Date: Wed, 2 Aug 2017 14:41:57 +0200<br>

From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [release][requirements] FFE release for<br>

        reno 2.5.0<br>

Message-ID: <<a href="mailto:12fdd660-5260-7ea8-ad63-0a1cbd63d7d7@openstack.org">12fdd660-5260-7ea8-ad63-<wbr>0a1cbd63d7d7@openstack.org</a>><br>

Content-Type: text/plain; charset=utf-8<br>

<br>

Doug Hellmann wrote:<br>

> We have a few projects that have modified stable branch release<br>

> notes by editing the files on master, which makes those notes appear<br>

> as part of the current release. Reno has a new option to address<br>

> that problem by ignoring some note files, and I would like to release<br>

> that version to allow project teams to fix up their release notes<br>

> for pike. I really thought I had already released that update, so<br>

> I'm sorry for the late request.<br>

><br>

> Reno is only used during release notes builds, but it does appear<br>

> in the global requirements list and constraints list. I think the<br>

> risk is minimal.<br>

><br>

> <a href="https://review.openstack.org/489998" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>489998</a><br>

<br>

Sounds like something we should fix before release rather than after, so<br>

+2 from me.<br>

<br>

--<br>

Thierry Carrez (ttx)<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 11<br>

Date: Wed, 2 Aug 2017 12:47:38 +0000<br>

From: Чадин Александр (Alexander Chadin)<br>

        <<a href="mailto:a.chadin@servionica.ru">a.chadin@servionica.ru</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [watcher] nominate Aditi Sharma to Watcher<br>

        Core    group<br>

Message-ID: <<a href="mailto:2EA26395-C5FA-4E5B-A8D6-8349543ABA56@servionica.ru">2EA26395-C5FA-4E5B-A8D6-<wbr>8349543ABA56@servionica.ru</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

Aditi Sharma (adisky in IRC) has been working on OpenStack Watcher since this March<br>

and has done some valuable patches[1] along with Action Plan cancelling blueprint (spec and<br>

implementation have been merged).<br>

I’d like to nominate Aditi Sharma to Watcher Core group and waiting for your vote.<br>

Please, give +1/-1 in reply to this message.<br>

<br>

[1] : <a href="https://review.openstack.org/#/q/owner:%22aditi+sharma+%253Caditi.s%2540nectechnologies.in%253E%22" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/owner:%22aditi+sharma+%<wbr>253Caditi.s%<wbr>2540nectechnologies.in%253E%22</a><br>

<br>

Best Regards,<br>

______________<br>

Alexander Chadin<br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/4714f608/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/4714f608/<wbr>attachment-0001.html</a>><br>

<br>

------------------------------<br>

<br>

Message: 12<br>

Date: Wed, 2 Aug 2017 23:18:19 +1000<br>

From: Tony Breeds <<a href="mailto:tony@bakeyournoodle.com">tony@bakeyournoodle.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [release][requirements] FFE release for<br>

        reno 2.5.0<br>

Message-ID: <<a href="mailto:20170802131818.GB22339@thor.bakeyournoodle.com">20170802131818.GB22339@thor.<wbr>bakeyournoodle.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

On Wed, Aug 02, 2017 at 08:39:07AM -0400, Doug Hellmann wrote:<br>

> We have a few projects that have modified stable branch release<br>

> notes by editing the files on master, which makes those notes appear<br>

> as part of the current release. Reno has a new option to address<br>

> that problem by ignoring some note files, and I would like to release<br>

> that version to allow project teams to fix up their release notes<br>

> for pike. I really thought I had already released that update, so<br>

> I'm sorry for the late request.<br>

><br>

> Reno is only used during release notes builds, but it does appear<br>

> in the global requirements list and constraints list. I think the<br>

> risk is minimal.<br>

><br>

> <a href="https://review.openstack.org/489998" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>489998</a><br>

<br>

Package      : reno [reno!=2.3.1,>=1.8.0] (used by 220 projects)<br>

Also affects : 220 projects<br>

<snip><br>

<br>

So yeah it *could* destabalise the gate for a day if there is an issue.<br>

I'm not saying that's likely but it has happened in the past.<br>

<br>

Looking at the reno change log I don't see anything that worries me.<br>

<br>

>From a requirements POV I'm +2 on a u-c bump -2 on a g-r bump.<br>

<br>

Yours Tony.<br>

-------------- next part --------------<br>

A non-text attachment was scrubbed...<br>

Name: signature.asc<br>

Type: application/pgp-signature<br>

Size: 488 bytes<br>

Desc: not available<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/1f37021c/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/1f37021c/<wbr>attachment-0001.sig</a>><br>

<br>

------------------------------<br>

<br>

Message: 13<br>

Date: Wed, 2 Aug 2017 09:19:31 -0400<br>

From: Mohammed Naser <<a href="mailto:mnaser@vexxhost.com">mnaser@vexxhost.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [elections] [puppet] Candidacy for Puppet<br>

        OpenStack       PTL (Queens)<br>

Message-ID:<br>

        <<a href="mailto:CAEs876jzt4dStXL07mhn1Z--VLGAOVwEdrcN2KidydmOn6H_GA@mail.gmail.com">CAEs876jzt4dStXL07mhn1Z--<wbr>VLGAOVwEdrcN2KidydmOn6H_GA@<wbr>mail.gmail.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

Hey everyone,<br>

<br>

I would like to nominate myself for the PTL role for the Puppet OpenStack team<br>

for the Queens release cycle.<br>

<br>

I have been directly involved with OpenStack as a deployer and contributor<br>

since 2011.  I have also personally used the Puppet OpenStack modules for a<br>

significant period of time in that period and I personally believe that they<br>

are one of the more robust and stable deployment methods of OpenStack.<br>

<br>

I'm very comfortable in terms of dealing with gate issues, Puppet and the<br>

OpenStack puppet modules specifically.  I'm also confident that I can quickly<br>

get up to speed in PTL activities such as managing releases and other<br>

responsibilities.<br>

<br>

The Puppet OpenStack modules are quite stable for the projects which have<br>

been around for a long time, such as Nova or Neutron which doesn't leave a lot<br>

of work.  However, for the Queens cycle, I believe the following goals are what<br>

I am to help accomplish:<br>

<br>

- Improve documentation to increase adoption of Puppet OpenStack<br>

- Add CI for modules which are not currently tested in<br>

`puppet-openstack-integration`<br>

  which will increase their maturity.<br>

- Ensure modules stay up to date with service configuration settings<br>

- Optimize CI to check for any deprecated configuration warnings to be able to<br>

  catch configuration changes earlier.<br>

<br>

I'm always available on IRC and I look forward to working with all of you for<br>

the upcoming cycle.  I'm also always open to suggestions or recommendation on<br>

how we can do things better, as this is for the benefit of all of us.<br>

<br>

Sincerely,<br>

Mohammed Naser (mnaser)<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 14<br>

Date: Wed, 2 Aug 2017 23:28:07 +1000<br>

From: Tony Breeds <<a href="mailto:tony@bakeyournoodle.com">tony@bakeyournoodle.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [requirements][release][docs] FFE for<br>

        openstack-doc-tools<br>

Message-ID: <<a href="mailto:20170802132807.GC22339@thor.bakeyournoodle.com">20170802132807.GC22339@thor.<wbr>bakeyournoodle.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

On Wed, Aug 02, 2017 at 02:22:35PM +0200, Andreas Jaeger wrote:<br>

> We need a new release of openstack-doc-tools to handle the changed<br>

> behaviour in how we build documents.<br>

><br>

> The tool is only used by documentation projects for building and nowhere<br>

> else listed in requirements file.<br>

><br>

> Please release this and take the new version in for requirements repo,<br>

><br>

> <a href="https://review.openstack.org/490001" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>490001</a><br>

<br>

<br>

I've posted a list of consumers to that review and we've confirmed that<br>

none of them have managed requirements.<br>

<br>

So from a requiremenmts POV I'm okay with a u-u bump here but I'm not<br>

100% certain it's needed.  We can sort that out tomorrow ;P<br>

<br>

Yours Tony.<br>

-------------- next part --------------<br>

A non-text attachment was scrubbed...<br>

Name: signature.asc<br>

Type: application/pgp-signature<br>

Size: 488 bytes<br>

Desc: not available<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/fe6c10d4/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/fe6c10d4/<wbr>attachment-0001.sig</a>><br>

<br>

------------------------------<br>

<br>

Message: 15<br>

Date: Wed, 2 Aug 2017 15:30:40 +0200<br>

From: Ildiko Vancsa <<a href="mailto:ildiko.vancsa@gmail.com">ildiko.vancsa@gmail.com</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a>, user-committee<br>

        <<a href="mailto:user-committee@lists.openstack.org">user-committee@lists.<wbr>openstack.org</a>><br>

Cc: Tetsuya Nakamura <<a href="mailto:t.nakamura@cablelabs.com">t.nakamura@cablelabs.com</a>><br>

Subject: [openstack-dev] Fwd: ETSI NFV - OpenStack PTG in Denver<br>

Message-ID: <<a href="mailto:3253BF0B-0AE4-474C-86F5-2A9340749437@gmail.com">3253BF0B-0AE4-474C-86F5-<wbr>2A9340749437@gmail.com</a>><br>

Content-Type: text/plain; charset=utf-8<br>

<br>

Hi All,<br>

<br>

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.<br>

<br>

You can find more information on the wiki page linked below.<br>

<br>

Please reach out to Tetsuya or respond to this mail thread in case you have any questions.<br>

<br>

Thanks and Best Regards,<br>

Ildikó<br>

<br>

<br>

> Begin forwarded message:<br>

><br>

> Dear OpenStack folks,<br>

><br>

> Let me introduce the ETSI NFV Tutorial & Specfest(Hackfest) event on September 11th in Denver downtown.<br>

><br>

> 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:<br>

> <a href="https://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial" rel="noreferrer" target="_blank">https://nfvwiki.etsi.org/<wbr>index.php?title=ETSI_NFV_<wbr>Tutorial</a><br>

><br>

> Please come and join.<br>

><br>

> Best Regards,<br>

> Tetsuya Nakamura, CableLabs,<br>

> Vice Chair, ETSI NFV-ISG,<br>

> <a href="mailto:t.nakamura@cablelabs.com">t.nakamura@cablelabs.com</a><br>

><br>

<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 16<br>

Date: Wed, 2 Aug 2017 07:56:06 -0600<br>

From: Alex Schultz <<a href="mailto:aschultz@redhat.com">aschultz@redhat.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [elections][tripleo] Queens PTL candidacy<br>

Message-ID:<br>

        <<a href="mailto:CAFsb3b4FdNayHFvO7UKFj2O6-fzq3rsqFu2OYS%2BvEpzyi-CORQ@mail.gmail.com">CAFsb3b4FdNayHFvO7UKFj2O6-<wbr>fzq3rsqFu2OYS+vEpzyi-CORQ@<wbr>mail.gmail.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

I would like to nominate myself for the TripleO PTL role for the Queens cycle.<br>

<br>

I have been a contributor to various OpenStack projects since Liberty. I have<br>

spent most of my time working on the deployment of OpenStack and with the<br>

engineers who deploy it.  As many of you know, I believe the projects we work<br>

on should simplify workflows and improve the end user's lives. During my time<br>

as Puppet OpenStack PTL, I have promoted efforts to simplify and establishing<br>

reusable patterns and best practices. I feel confident that TripleO is on the<br>

right path and hope to continue to lead it in the right direction.<br>

<br>

For the last few cycles we have moved TripleO forwards and improved not only<br>

TripleO itself, but have provided additional tooling around deploying and<br>

managing OpenStack. As we look forward to the Queens cycle, it is imporant<br>

to recognize the work we have done and can continue to improve on.<br>

<br>

* Improving deployment of containerized services.<br>

  We started the effort to switch over to containerized services being deployed<br>

  with TripleO as part of the Pike cycle and we need to finalize the last few<br>

  services. As we start the transition to including Kubernetes, we need to be<br>

  mindful of the transition and make sure we evaluate and leverage already<br>

  existing solutions.<br>

* Continue making the deployers' lives easier.<br>

  The recent cycles have been full of efforts to allow users to do more with<br>

  TripleO. With the work to expose composable roles, composable networks and<br>

  containerization we have added additional flexibility for the deployment<br>

  engineers to be able to build out architectures needed for the end user.<br>

  That being said, there are still efforts to be done to make the deployment<br>

  process less error prone and more user friendly.<br>

* Continued improvement of CI<br>

  The process to transition over to tripleo-quickstart has made excellent<br>

  progress over the last few cycles. We need to continue to refine the steps<br>

  to ensure that Developers can reuse the work and be able to quickly and<br>

  easily troubleshoot when things break down.  Additionally we need to make<br>

  sure that we can classify repeated failures and work to address them quickly<br>

  as to not hold up bugs and features.<br>

* Improve visibility of the project status<br>

  As part of the Queens cycle, I would like to devote some time into capturing<br>

  metrics and information about the status of the various projects under the<br>

  TripleO umbrella. We've been doing lots of work but it I think it would be<br>

  beneficial for us to know where this work has been occurring. I'm hoping to<br>

  work on some of the reporting around the status of our CI, bugs and reviews<br>

  to be able to see where we could use some more efforts to hopefully improve<br>

  our development velocities.<br>

<br>

Thanks,<br>

Alex Schultz<br>

irc: mwhahaha<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 17<br>

Date: Wed, 2 Aug 2017 10:02:09 -0400<br>

From: Ken Giusti <<a href="mailto:kgiusti@gmail.com">kgiusti@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [oslo][barbican][sahara] start RPC service<br>

        before  launcher wait?<br>

Message-ID:<br>

        <CAJoCO=<a href="mailto:Ps1hTki6EHW546V%2Bab%2BXCxUwE8gJHEM5ETCYWnom%2BrsA@mail.gmail.com">Ps1hTki6EHW546V+ab+<wbr>XCxUwE8gJHEM5ETCYWnom+rsA@<wbr>mail.gmail.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

Oop - didn't reply all<br>

---------- Forwarded message ----------<br>

From: Ken Giusti <<a href="mailto:kgiusti@gmail.com">kgiusti@gmail.com</a>><br>

Date: Tue, Aug 1, 2017 at 12:51 PM<br>

Subject: Re: [openstack-dev] [oslo][barbican][sahara] start RPC service<br>

before launcher wait?<br>

To: Adam Spiers <<a href="mailto:aspiers@suse.com">aspiers@suse.com</a>><br>

<br>

<br>

Hi Adam,<br>

<br>

I think there's a couple of problems here.<br>

<br>

Regardless of worker count, the service.wait() is called before<br>

service.start().  And from looking at the oslo.service code, the 'wait()'<br>

method is call after start(), then again after stop().  This doesn't match<br>

up with the intended use of oslo.messaging.server.wait(), which should only<br>

be called after .stop().<br>

<br>

Perhaps a bigger issue is that in the multi threaded case all threads<br>

appear to be calling start, wait, and stop on the same instance of the<br>

service (oslo.messaging rpc server).  At least that's what I'm seeing in my<br>

muchly reduced test code:<br>

<br>

<a href="https://paste.fedoraproject.org/paste/-73zskccaQvpSVwRJD11cA" rel="noreferrer" target="_blank">https://paste.fedoraproject.<wbr>org/paste/-<wbr>73zskccaQvpSVwRJD11cA</a><br>

<br>

The log trace shows multiple calls to start, wait, stop via different<br>

threads to the same TaskServer instance:<br>

<br>

<a href="https://paste.fedoraproject.org/paste/dyPq~lr26sQZtMzHn5w~Vg" rel="noreferrer" target="_blank">https://paste.fedoraproject.<wbr>org/paste/dyPq~lr26sQZtMzHn5w~<wbr>Vg</a><br>

<br>

Is that expected?<br>

<br>

On Mon, Jul 31, 2017 at 9:32 PM, Adam Spiers <<a href="mailto:aspiers@suse.com">aspiers@suse.com</a>> wrote:<br>

<br>

> Ken Giusti <<a href="mailto:kgiusti@gmail.com">kgiusti@gmail.com</a>> wrote:<br>

><br>

>> On Mon, Jul 31, 2017 at 10:01 AM, Adam Spiers <<a href="mailto:aspiers@suse.com">aspiers@suse.com</a>> wrote:<br>

>><br>

>>> I recently discovered a bug where barbican-worker would hang on<br>

>>> shutdown if queue.asynchronous_workers was changed from 1 to 2:<br>

>>><br>

>>>    <a href="https://bugs.launchpad.net/barbican/+bug/1705543" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>barbican/+bug/1705543</a><br>

>>><br>

>>> resulting in a warning like this:<br>

>>><br>

>>>    WARNING oslo_messaging.server [-] Possible hang: stop is waiting for<br>

>>> start to complete<br>

>>><br>

>>> I found a similar bug in Sahara:<br>

>>><br>

>>>    <a href="https://bugs.launchpad.net/sahara/+bug/1546119" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>sahara/+bug/1546119</a><br>

>>><br>

>>> where the fix was to call start() on the RPC service before making the<br>

>>> launcher wait() on it, so I ported the fix to Barbican, and it seems<br>

>>> to work fine:<br>

>>><br>

>>>    <a href="https://review.openstack.org/#/c/485755" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/485755</a><br>

>>><br>

>>> I noticed that both projects use ProcessLauncher; barbican uses<br>

>>> oslo_service.service.launch() which has:<br>

>>><br>

>>>    if workers is None or workers == 1:<br>

>>>        launcher = ServiceLauncher(conf, restart_method=restart_method)<br>

>>>    else:<br>

>>>        launcher = ProcessLauncher(conf, restart_method=restart_method)<br>

>>><br>

>>> However, I'm not an expert in oslo.service or oslo.messaging, and one<br>

>>> of Barbican's core reviewers (thanks Kaitlin!) noted that not many<br>

>>> other projects start the task before calling wait() on the launcher,<br>

>>> so I thought I'd check here whether that is the correct fix, or<br>

>>> whether there's something else odd going on.<br>

>>><br>

>>> Any oslo gurus able to shed light on this?<br>

>>><br>

>><br>

>> As far as an oslo.messaging server is concerned, the order of operations<br>

>> is:<br>

>><br>

>> server.start()<br>

>> # do stuff until ready to stop the server...<br>

>> server.stop()<br>

>> server.wait()<br>

>><br>

>> The final wait blocks until all requests that are in progress when stop()<br>

>> is called finish and cleanup.<br>

>><br>

><br>

> Thanks - that makes sense.  So the question is, why would<br>

> barbican-worker only hang on shutdown when there are multiple workers?<br>

> Maybe the real bug is somewhere in oslo_service.service.<wbr>ProcessLauncher<br>

> and it's not calling start() correctly?<br>

><br>

<br>

<br>

<br>

--<br>

Ken Giusti  (<a href="mailto:kgiusti@gmail.com">kgiusti@gmail.com</a>)<br>

<br>

<br>

<br>

--<br>

Ken Giusti  (<a href="mailto:kgiusti@gmail.com">kgiusti@gmail.com</a>)<br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/7fd66d76/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/7fd66d76/<wbr>attachment-0001.html</a>><br>

<br>

------------------------------<br>

<br>

Message: 18<br>

Date: Wed, 2 Aug 2017 16:33:09 +0200<br>

From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>

To: OpenStack Development Mailing List<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [all] Only 40 days to PTG !<br>

Message-ID: <<a href="mailto:106b91dc-1912-7010-9d31-e7d5da686dcc@openstack.org">106b91dc-1912-7010-9d31-<wbr>e7d5da686dcc@openstack.org</a>><br>

Content-Type: text/plain; charset=utf-8<br>

<br>

Hi everyone,<br>

<br>

Time flies, and we are just 40 days from the Project Teams Gathering in<br>

Denver. Time for a few reminders!<br>

<br>

<br>

1/ Registration<br>

<br>

If you haven't registered yet, you should do so[1] ASAP. Beyond securing<br>

your slot to the event, it helps us planning for rooms and lunches based<br>

on your days of attendance.<br>

<br>

[1] <a href="https://queensptg.eventbrite.com/" rel="noreferrer" target="_blank">https://queensptg.eventbrite.<wbr>com/</a><br>

<br>

<br>

2/ Travel support program<br>

<br>

If you'd like to come join your project team in Denver but need<br>

financial help, our Travel Support Program[2] is still open. However the<br>

deadline for applications is *this Sunday, August 6*, so don't forget to<br>

apply in time !<br>

<br>

[2] <a href="https://openstackfoundation.formstack.com/forms/travelsupportptg_denver" rel="noreferrer" target="_blank">https://openstackfoundation.<wbr>formstack.com/forms/<wbr>travelsupportptg_denver</a><br>

<br>

<br>

3/ Visa<br>

<br>

If you need a visa, it's getting pretty late to go through the whole<br>

process in time for the event. Let us know ASAP if you need an<br>

invitation letter[3] !<br>

<br>

[3] <a href="https://openstackfoundation.formstack.com/forms/visa_form_denver_ptg" rel="noreferrer" target="_blank">https://openstackfoundation.<wbr>formstack.com/forms/visa_form_<wbr>denver_ptg</a><br>

<br>

<br>

4/ Event layout<br>

<br>

We are still finalizing the list of teams and rooms that will meet at<br>

the event[4]. As previously announced, this time the week is split in<br>

the following way:<br>

<br>

- Monday/Tuesday: inter-team discussions on specific themes: workgroup<br>

discussions, help desks from various support teams, discussions for<br>

teams relying on liaisons like Oslo / Horizon / Docs, release goals<br>

hacking rooms...<br>

<br>

- Wednesday-Thursday-Friday: discussions within each project team to<br>

coordinate the Queens work, solve pressing issues and start getting<br>

things done<br>

<br>

[4]<br>

<a href="https://docs.google.com/spreadsheets/u/1/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312&single=true" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>spreadsheets/u/1/d/<wbr>1xmOdT6uZ5XqViActr5sBOaz_<wbr>mEgjKSCY7NEWcAEcT-A/pubhtml?<wbr>gid=397241312&single=true</a><br>

<br>

<br>

Let me know if you have any question. You can also ask questions on<br>

#openstack-ptg, or contact the events team at <a href="mailto:ptg@openstack.org">ptg@openstack.org</a>.<br>

<br>

--<br>

Thierry Carrez (ttx)<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 19<br>

Date: Wed, 2 Aug 2017 10:38:03 -0400<br>

From: Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [all] Only 40 days to PTG !<br>

Message-ID:<br>

        <<wbr>CANw6fcEPa33zCTMOg1C57H9SCaWoc<wbr>hY+tz2EuR+XgR=-<a href="mailto:7pO6Ww@mail.gmail.com">7pO6Ww@mail.<wbr>gmail.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

May be good to point out to new folks, the etherpads for discussions are here:<br>

<a href="https://wiki.openstack.org/wiki/PTG/Queens/Etherpads" rel="noreferrer" target="_blank">https://wiki.openstack.org/<wbr>wiki/PTG/Queens/Etherpads</a><br>

<br>

Thanks,<br>

Dims<br>

<br>

On Wed, Aug 2, 2017 at 10:33 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>

> Hi everyone,<br>

><br>

> Time flies, and we are just 40 days from the Project Teams Gathering in<br>

> Denver. Time for a few reminders!<br>

><br>

><br>

> 1/ Registration<br>

><br>

> If you haven't registered yet, you should do so[1] ASAP. Beyond securing<br>

> your slot to the event, it helps us planning for rooms and lunches based<br>

> on your days of attendance.<br>

><br>

> [1] <a href="https://queensptg.eventbrite.com/" rel="noreferrer" target="_blank">https://queensptg.eventbrite.<wbr>com/</a><br>

><br>

><br>

> 2/ Travel support program<br>

><br>

> If you'd like to come join your project team in Denver but need<br>

> financial help, our Travel Support Program[2] is still open. However the<br>

> deadline for applications is *this Sunday, August 6*, so don't forget to<br>

> apply in time !<br>

><br>

> [2] <a href="https://openstackfoundation.formstack.com/forms/travelsupportptg_denver" rel="noreferrer" target="_blank">https://openstackfoundation.<wbr>formstack.com/forms/<wbr>travelsupportptg_denver</a><br>

><br>

><br>

> 3/ Visa<br>

><br>

> If you need a visa, it's getting pretty late to go through the whole<br>

> process in time for the event. Let us know ASAP if you need an<br>

> invitation letter[3] !<br>

><br>

> [3] <a href="https://openstackfoundation.formstack.com/forms/visa_form_denver_ptg" rel="noreferrer" target="_blank">https://openstackfoundation.<wbr>formstack.com/forms/visa_form_<wbr>denver_ptg</a><br>

><br>

><br>

> 4/ Event layout<br>

><br>

> We are still finalizing the list of teams and rooms that will meet at<br>

> the event[4]. As previously announced, this time the week is split in<br>

> the following way:<br>

><br>

> - Monday/Tuesday: inter-team discussions on specific themes: workgroup<br>

> discussions, help desks from various support teams, discussions for<br>

> teams relying on liaisons like Oslo / Horizon / Docs, release goals<br>

> hacking rooms...<br>

><br>

> - Wednesday-Thursday-Friday: discussions within each project team to<br>

> coordinate the Queens work, solve pressing issues and start getting<br>

> things done<br>

><br>

> [4]<br>

> <a href="https://docs.google.com/spreadsheets/u/1/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312&single=true" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>spreadsheets/u/1/d/<wbr>1xmOdT6uZ5XqViActr5sBOaz_<wbr>mEgjKSCY7NEWcAEcT-A/pubhtml?<wbr>gid=397241312&single=true</a><br>

><br>

><br>

> Let me know if you have any question. You can also ask questions on<br>

> #openstack-ptg, or contact the events team at <a href="mailto:ptg@openstack.org">ptg@openstack.org</a>.<br>

><br>

> --<br>

> Thierry Carrez (ttx)<br>

><br>

> ______________________________<wbr>______________________________<wbr>______________<br>

> OpenStack Development Mailing List (not for usage questions)<br>

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

<br>

<br>

--<br>

Davanum Srinivas :: <a href="https://twitter.com/dims" rel="noreferrer" target="_blank">https://twitter.com/dims</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 20<br>

Date: Wed, 2 Aug 2017 14:46:52 +0000<br>

From: <<a href="mailto:Arkady.Kanevsky@dell.com">Arkady.Kanevsky@dell.com</a>><br>

To: <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [elections][tripleo] Queens PTL candidacy<br>

Message-ID:<br>

        <<a href="mailto:d6bc872ab12f46bd94671b57e7fb5e04@AUSX13MPS308.AMER.DELL.COM">d6bc872ab12f46bd94671b57e7fb5<wbr>e04@AUSX13MPS308.AMER.DELL.COM</a><wbr>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

+1<br>

<br>

-----Original Message-----<br>

From: Alex Schultz [mailto:<a href="mailto:aschultz@redhat.com">aschultz@redhat.com</a>]<br>

Sent: Wednesday, August 02, 2017 8:56 AM<br>

To: OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [elections][tripleo] Queens PTL candidacy<br>

<br>

I would like to nominate myself for the TripleO PTL role for the Queens cycle.<br>

<br>

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.<br>

<br>

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.<br>

<br>

* Improving deployment of containerized services.<br>

  We started the effort to switch over to containerized services being deployed<br>

  with TripleO as part of the Pike cycle and we need to finalize the last few<br>

  services. As we start the transition to including Kubernetes, we need to be<br>

  mindful of the transition and make sure we evaluate and leverage already<br>

  existing solutions.<br>

* Continue making the deployers' lives easier.<br>

  The recent cycles have been full of efforts to allow users to do more with<br>

  TripleO. With the work to expose composable roles, composable networks and<br>

  containerization we have added additional flexibility for the deployment<br>

  engineers to be able to build out architectures needed for the end user.<br>

  That being said, there are still efforts to be done to make the deployment<br>

  process less error prone and more user friendly.<br>

* Continued improvement of CI<br>

  The process to transition over to tripleo-quickstart has made excellent<br>

  progress over the last few cycles. We need to continue to refine the steps<br>

  to ensure that Developers can reuse the work and be able to quickly and<br>

  easily troubleshoot when things break down.  Additionally we need to make<br>

  sure that we can classify repeated failures and work to address them quickly<br>

  as to not hold up bugs and features.<br>

* Improve visibility of the project status<br>

  As part of the Queens cycle, I would like to devote some time into capturing<br>

  metrics and information about the status of the various projects under the<br>

  TripleO umbrella. We've been doing lots of work but it I think it would be<br>

  beneficial for us to know where this work has been occurring. I'm hoping to<br>

  work on some of the reporting around the status of our CI, bugs and reviews<br>

  to be able to see where we could use some more efforts to hopefully improve<br>

  our development velocities.<br>

<br>

Thanks,<br>

Alex Schultz<br>

irc: mwhahaha<br>

<br>

______________________________<wbr>______________________________<wbr>______________<br>

OpenStack Development Mailing List (not for usage questions)<br>

Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

------------------------------<br>

<br>

Message: 21<br>

Date: Wed, 2 Aug 2017 09:55:02 -0500<br>

From: Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:4c4a613b-b162-0746-b068-238b5ba6a1b4@gmail.com">4c4a613b-b162-0746-b068-<wbr>238b5ba6a1b4@gmail.com</a>><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

Now that Stephen Finucane is back from enjoying his youth and<br>

gallivanting all over Europe, and we talked about a few things in IRC<br>

this morning on the docs migration for Nova, I wanted to dump my<br>

concerns here for broader consumption.<br>

<br>

1. We know we have to fix a bunch of broken links by adding in redirects<br>

[1] which sdague started here [2]. However, that apparently didn't catch<br>

everything, e.g. [3], so I'm concerned we're missing other broken links.<br>

Is there a way to find out?<br>

<br>

2. The bottom change in the docs migration series for Nova is a massive<br>

refactor of the layout of the Nova devref [4]. That's something I don't<br>

want to do in Pike for two reasons:<br>

<br>

a) It's a huge change and we simply don't have the time to invest in<br>

properly assessing and reviewing it before Pike RC1.<br>

<br>

b) I think that if we're going to refactor the Nova devref home page to<br>

be a certain format, then we should really consider doing the same thing<br>

in the other projects, because today they are all different formats<br>

[5][6][7]. This is likely a cross-project discussion for the Queens PTG<br>

to determine if the home page for the projects should look similar. It<br>

seems they should given the uniformity that the Foundation has been<br>

working toward lately.<br>

<br>

3. The patch for the import of the admin guide [8] is missing some CLI<br>

specific pages which are pretty useful given they aren't documented<br>

anywhere else, like the forced_host part of the compute API [9].<br>

Basically anything that's cli-nova-* in the admin guide should be in the<br>

Nova docs. It's also missing the compute-flavors page [10] which is<br>

pretty important for using OpenStack at all.<br>

<br>

4. Similar to #3, but we don't have a patch yet for importing the user<br>

guide and there are several docs in the user guide that are Nova<br>

specific so I'd like to make sure we include those, like [11][12].<br>

<br>

[1]<br>

<a href="http://lists.openstack.org/pipermail/openstack-dev/2017-August/120418.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>August/120418.html</a><br>

[2] <a href="https://review.openstack.org/#/c/489650/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489650/</a><br>

[3] <a href="https://review.openstack.org/#/c/489641/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489641/</a><br>

[4] <a href="https://review.openstack.org/#/c/478485/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/478485/</a><br>

[5] <a href="https://docs.openstack.org/cinder/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>cinder/latest/</a><br>

[6] <a href="https://docs.openstack.org/glance/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>glance/latest/</a><br>

[7] <a href="https://docs.openstack.org/neutron/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>neutron/latest/</a><br>

[8] <a href="https://review.openstack.org/#/c/477497/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/477497/</a><br>

[9]<br>

<a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-guide/source/cli-nova-specify-host.rst" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/admin-guide/source/<wbr>cli-nova-specify-host.rst</a><br>

[10]<br>

<a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-guide/source/compute-flavors.rst" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/admin-guide/source/<wbr>compute-flavors.rst</a><br>

[11]<br>

<a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-guide/source/cli-launch-instances.rst" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/user-guide/source/<wbr>cli-launch-instances.rst</a><br>

[12]<br>

<a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-guide/source/cli-delete-an-instance.rst" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/user-guide/source/<wbr>cli-delete-an-instance.rst</a><br>

<br>

--<br>

<br>

Thanks,<br>

<br>

Matt<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 22<br>

Date: Wed, 2 Aug 2017 09:57:56 -0500<br>

From: Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Cc: Yi Ming YZ Zhang <<a href="mailto:zymzhang@cn.ibm.com">zymzhang@cn.ibm.com</a>><br>

Subject: Re: [openstack-dev] [cinder] Apply for exception to having<br>

        Storwize cinder Tiramisu replication patch reviewed and merged<br>

Message-ID: <20170802145756.GA10718@cooler<wbr>><br>

Content-Type: text/plain; charset=us-ascii<br>

<br>

This patch was Workflow-1 until after the feature freeze date.<br>

At this point I think we will need to wait until Queens opens<br>

up to get this through.<br>

<br>

Sean<br>

<br>

On Wed, Aug 02, 2017 at 12:07:06PM +0000, Xiao Qin SH Li wrote:<br>

> <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" >&nbsp;</div><br>

> <div dir="ltr" ><div dir="ltr" >Hi all,</div><br>

> <div dir="ltr" >&nbsp;</div><br>

> <div dir="ltr" >There is a Tiramisu replication patch for IBM storwize cinder <a href="<a href="https://review.openstack.org/#/c/469394" rel="noreferrer" target="_blank">https://review.<wbr>openstack.org/#/c/469394</a>" rel="noopener" target="_blank" ><a href="https://review.openstack.org/#/c/469394" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/469394</a></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><br>

> <div dir="ltr" >&nbsp;</div><br>

> <div dir="ltr" >Thanks a lot!</div></div><br>

> <div dir="ltr" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-<wbr>size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-<wbr>size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-<wbr>size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-<wbr>size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-<wbr>size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-<wbr>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><br>

> <div style="font-size: 12pt; font-weight: bold; font-family: sans-serif; color: #7C7C5F;" >Xiao Qin Li</div><br>

> <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 &amp; Technology Laboratory in Shanghai<br>Email: <a href="mailto:lixqin@cn.ibm.com">lixqin@cn.ibm.com</a><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></<wbr>div></div></div></div></div></<wbr>div></div></div></div><BR><br>

><br>

><br>

<br>

> ______________________________<wbr>______________________________<wbr>______________<br>

> OpenStack Development Mailing List (not for usage questions)<br>

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 23<br>

Date: Wed, 2 Aug 2017 10:04:03 -0500<br>

From: Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] Trying again on wait_for_compute in<br>

        devstack<br>

Message-ID: <<a href="mailto:54a6467e-e3d0-c62a-86ec-ffebc407be2a@gmail.com">54a6467e-e3d0-c62a-86ec-<wbr>ffebc407be2a@gmail.com</a>><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

On 8/2/2017 6:17 AM, Sean Dague wrote:<br>

> and we're not going<br>

> to use it in multinode scenarios.<br>

<br>

Why would you not run this in multinode scenarios? That's the only time<br>

this is really a problem, because in the single node case we're<br>

discovering and mapping the compute node late enough that it's not been<br>

a problem.<br>

<br>

The main failures are in the multinode jobs:<br>

<br>

<a href="https://bugs.launchpad.net/grenade/+bug/1708039" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>grenade/+bug/1708039</a><br>

<br>

<a href="https://goo.gl/xXhW8r" rel="noreferrer" target="_blank">https://goo.gl/xXhW8r</a><br>

<br>

The devstack change is also failing on XenServer CI and who knows how<br>

many other 3rd party CIs that don't run against devstack changes, but<br>

will explode once it merges and they are running on Cinder or Neutron<br>

changes. I've dropped the tags in the subject line of this email so that<br>

this gets broader awareness as this isn't really just going to impact<br>

nova and ironic jobs if third party CIs aren't setup to handle this.<br>

<br>

Why don't we wait until after RC1 on 8/10 before doing this? We already<br>

broke the gate and lost at least 6-10 hours last week on the day of<br>

feature freeze because of this.<br>

<br>

--<br>

<br>

Thanks,<br>

<br>

Matt<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 24<br>

Date: Wed, 2 Aug 2017 11:04:06 -0400<br>

From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [devstack] [ironic] [nova] Trying again<br>

        on wait_for_compute in devstack<br>

Message-ID: <<a href="mailto:a520b55e-daf1-ce94-2161-12faf3dd6e88@dague.net">a520b55e-daf1-ce94-2161-<wbr>12faf3dd6e88@dague.net</a>><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

An issue with the xenserver CI was identified. Once we get this patch<br>

in, and backported to ocata, it should also address a frequent grenade<br>

multinode fail scenario which is plaguing the gate.<br>

<br>

        -Sean<br>

<br>

On 08/02/2017 07:17 AM, Sean Dague wrote:<br>

> The 3 node scenarios in Neutron (which are still experimental nv) are<br>

> typically failing to bring online the 3rd compute. In cells v2 you have<br>

> to explicitly add nodes to the cells. There is a nova-manage command<br>

> "discover-hosts" that takes all the compute nodes which have checked in,<br>

> but aren't yet assigned to a cell, and puts them into a cell of your<br>

> choosing. We do this in devstack-gate in the gate.<br>

><br>

> However... subnodes don't take very long to setup (so few services). And<br>

> the nova-compute process takes about 30s before it's done all it's<br>

> initialization and actually checks in to the cluster. It's a real<br>

> possibility that discover_hosts will run before subnode 3 checks in. We<br>

> see it in logs. This also really could come and bite us on any multinode<br>

> job, and I'm a bit concerned some of the multinode jobs aren't running<br>

> multinode some times because of it.<br>

><br>

> One way to fix this, without putting more logic in devstack-gate, is<br>

> ensure that by the time stack.sh finishes, the compute node is up. This<br>

> was tried previously, but it turned out that we totally missed that it<br>

> broke Ironic (the check happened too early, ironic was not yet running,<br>

> so we always failed), Cells v1 (munges hostnames :(  ), and PowerVM<br>

> (their nova-compute was never starting correctly, and they were working<br>

> around it with a restart later).<br>

><br>

> This patch <a href="https://review.openstack.org/#/c/488381/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/488381/</a> tries again. The<br>

> check is moved very late, Ironic seems to be running fine with it. Cells<br>

> v1 is just skipped, that's deprecated in Nova now, and we're not going<br>

> to use it in multinode scenarios. The PowerVM team fixed their<br>

> nova-compute start issues, so they should be good to go as well.<br>

><br>

> This is an FYI that we're going to land this again soon. If you think<br>

> this impacts your CI / jobs, please speak up. The CI runs on both the<br>

> main and experimental queue on devstack for this change look pretty<br>

> good, so I think we're safe to move forward this time. But we also<br>

> thought that the last time, and were wrong.<br>

><br>

>       -Sean<br>

><br>

<br>

<br>

--<br>

Sean Dague<br>

<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 25<br>

Date: Wed, 2 Aug 2017 10:06:24 -0500<br>

From: Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [keystone][policy] no policy meeting today<br>

        2017-08-02<br>

Message-ID: <<a href="mailto:90e50b8a-6a66-3a1d-0e47-b93d4ca02e9c@gmail.com">90e50b8a-6a66-3a1d-0e47-<wbr>b93d4ca02e9c@gmail.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

A lot of the team is focused on getting pike-rc1 out the door and<br>

reviews. The agenda is also empty. Let's cancel today and pick up next<br>

week or shortly before the PTG to organize our policy sessions there.<br>

<br>

Thanks,<br>

<br>

Lance<br>

<br>

<br>

-------------- next part --------------<br>

A non-text attachment was scrubbed...<br>

Name: signature.asc<br>

Type: application/pgp-signature<br>

Size: 833 bytes<br>

Desc: OpenPGP digital signature<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/fb65e19e/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/fb65e19e/<wbr>attachment-0001.sig</a>><br>

<br>

------------------------------<br>

<br>

Message: 26<br>

Date: Wed, 2 Aug 2017 10:08:26 -0500<br>

From: Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] Trying again on wait_for_compute in<br>

        devstack<br>

Message-ID: <<a href="mailto:b2c2703c-cede-2b39-7836-a267422a5639@gmail.com">b2c2703c-cede-2b39-7836-<wbr>a267422a5639@gmail.com</a>><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

On 8/2/2017 10:04 AM, Matt Riedemann wrote:<br>

>> and we're not going<br>

>> to use it in multinode scenarios.<br>

><br>

> Why would you not run this in multinode scenarios? That's the only time<br>

> this is really a problem, because in the single node case we're<br>

> discovering and mapping the compute node late enough that it's not been<br>

> a problem.<br>

<br>

Did you mean we're not going to use "cells v1" in multinode scenarios? I<br>

read "we're not going to use it" with "it" being the discovery patch in<br>

devstack, not cells v1.<br>

<br>

--<br>

<br>

Thanks,<br>

<br>

Matt<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 27<br>

Date: Wed, 02 Aug 2017 16:22:03 +0100<br>

From: Stephen Finucane <<a href="mailto:sfinucan@redhat.com">sfinucan@redhat.com</a>><br>

To: Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>>, "OpenStack Development<br>

        Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:1501687323.3229.21.camel@redhat.com">1501687323.3229.21.camel@<wbr>redhat.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:<br>

> Now that Stephen Finucane is back from enjoying his youth and<br>

> gallivanting all over Europe, and we talked about a few things in IRC<br>

> this morning on the docs migration for Nova, I wanted to dump my<br>

> concerns here for broader consumption.<br>

><br>

> 1. We know we have to fix a bunch of broken links by adding in redirects<br>

> [1] which sdague started here [2]. However, that apparently didn't catch<br>

> everything, e.g. [3], so I'm concerned we're missing other broken links.<br>

> Is there a way to find out?<br>

<br>

We knew this was going to be an issue, but I wasn't aware of any way to fix<br>

this. The solution looks good though - nice work.<br>

<br>

Unfortunately I can't think of any cleverer way to identify these broken links<br>

than manual inspection. I'll do this again for all the patches I've authored<br>

and try to do them for any others I encounter.<br>

<br>

> 2. The bottom change in the docs migration series for Nova is a massive<br>

> refactor of the layout of the Nova devref [4]. That's something I don't<br>

> want to do in Pike for two reasons:<br>

><br>

> a) It's a huge change and we simply don't have the time to invest in<br>

> properly assessing and reviewing it before Pike RC1.<br>

><br>

> b) I think that if we're going to refactor the Nova devref home page to<br>

> be a certain format, then we should really consider doing the same thing<br>

> in the other projects, because today they are all different formats<br>

> [5][6][7]. This is likely a cross-project discussion for the Queens PTG<br>

> to determine if the home page for the projects should look similar. It<br>

> seems they should given the uniformity that the Foundation has been<br>

> working toward lately.<br>

<br>

This is fair. I've been working on this with asettle and I personally agree<br>

with a lot of the changes/design decisions made there. However, I understand<br>

the time constraints so we can surely split this out. I'll work with asettle on<br>

this too.<br>

<br>

> 3. The patch for the import of the admin guide [8] is missing some CLI<br>

> specific pages which are pretty useful given they aren't documented<br>

> anywhere else, like the forced_host part of the compute API [9].<br>

> Basically anything that's cli-nova-* in the admin guide should be in the<br>

> Nova docs. It's also missing the compute-flavors page [10] which is<br>

> pretty important for using OpenStack at all.<br>

<br>

This is a tricky one. Based on previous discussions with dhellmann, the plan<br>

seems to be to replace any references to 'nova xxx' or 'openstack xxx' commands<br>

(i.e. commands using python-novaclient or python-openstackclient) in favour of<br>

'curl'-based requests. The idea here is that the Python clients are not the<br>

only clients available, and we shouldn't be "mandating" their use by<br>

referencing them in the docs. I get this, though I don't fully agree with it<br>

(who really uses curl?). In any case though, this would surely be a big rewrite<br>

and, per your concerns in #2 above,  doesn't sound like something we should be<br>

doing in Pike. I guess a basic import is the way to go for now. I'll take care<br>

of this.<br>

<br>

> 4. Similar to #3, but we don't have a patch yet for importing the user<br>

> guide and there are several docs in the user guide that are Nova<br>

> specific so I'd like to make sure we include those, like [11][12].<br>

<br>

As above.<br>

<br>

Stephen<br>

<br>

> [1]<br>

> <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-August/120418.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>August/120418.html</a><br>

> [2] <a href="https://review.openstack.org/#/c/489650/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489650/</a><br>

> [3] <a href="https://review.openstack.org/#/c/489641/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489641/</a><br>

> [4] <a href="https://review.openstack.org/#/c/478485/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/478485/</a><br>

> [5] <a href="https://docs.openstack.org/cinder/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>cinder/latest/</a><br>

> [6] <a href="https://docs.openstack.org/glance/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>glance/latest/</a><br>

> [7] <a href="https://docs.openstack.org/neutron/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>neutron/latest/</a><br>

> [8] <a href="https://review.openstack.org/#/c/477497/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/477497/</a><br>

> [9]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-gu" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/admin-gu</a><br>

> ide/source/cli-nova-specify-<wbr>host.rst<br>

> [10]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-gu" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/admin-gu</a><br>

> ide/source/compute-flavors.rst<br>

> [11]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-gui" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/user-gui</a><br>

> de/source/cli-launch-<wbr>instances.rst<br>

> [12]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-gui" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/user-gui</a><br>

> de/source/cli-delete-an-<wbr>instance.rst<br>

><br>

<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 28<br>

Date: Wed, 02 Aug 2017 16:22:18 +0100<br>

From: Stephen Finucane <<a href="mailto:sfinucan@redhat.com">sfinucan@redhat.com</a>><br>

To: Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>>, "OpenStack Development<br>

        Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:1501687338.3229.22.camel@redhat.com">1501687338.3229.22.camel@<wbr>redhat.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:<br>

> Now that Stephen Finucane is back from enjoying his youth and<br>

> gallivanting all over Europe, and we talked about a few things in IRC<br>

> this morning on the docs migration for Nova, I wanted to dump my<br>

> concerns here for broader consumption.<br>

><br>

> 1. We know we have to fix a bunch of broken links by adding in redirects<br>

> [1] which sdague started here [2]. However, that apparently didn't catch<br>

> everything, e.g. [3], so I'm concerned we're missing other broken links.<br>

> Is there a way to find out?<br>

<br>

Manual inspection is probably the easiest way to go.<br>

<br>

> 2. The bottom change in the docs migration series for Nova is a massive<br>

> refactor of the layout of the Nova devref [4]. That's something I don't<br>

> want to do in Pike for two reasons:<br>

><br>

> a) It's a huge change and we simply don't have the time to invest in<br>

> properly assessing and reviewing it before Pike RC1.<br>

><br>

> b) I think that if we're going to refactor the Nova devref home page to<br>

> be a certain format, then we should really consider doing the same thing<br>

> in the other projects, because today they are all different formats<br>

> [5][6][7]. This is likely a cross-project discussion for the Queens PTG<br>

> to determine if the home page for the projects should look similar. It<br>

> seems they should given the uniformity that the Foundation has been<br>

> working toward lately.<br>

><br>

> 3. The patch for the import of the admin guide [8] is missing some CLI<br>

> specific pages which are pretty useful given they aren't documented<br>

> anywhere else, like the forced_host part of the compute API [9].<br>

> Basically anything that's cli-nova-* in the admin guide should be in the<br>

> Nova docs. It's also missing the compute-flavors page [10] which is<br>

> pretty important for using OpenStack at all.<br>

><br>

> 4. Similar to #3, but we don't have a patch yet for importing the user<br>

> guide and there are several docs in the user guide that are Nova<br>

> specific so I'd like to make sure we include those, like [11][12].<br>

><br>

> [1]<br>

> <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-August/120418.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>August/120418.html</a><br>

> [2] <a href="https://review.openstack.org/#/c/489650/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489650/</a><br>

> [3] <a href="https://review.openstack.org/#/c/489641/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489641/</a><br>

> [4] <a href="https://review.openstack.org/#/c/478485/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/478485/</a><br>

> [5] <a href="https://docs.openstack.org/cinder/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>cinder/latest/</a><br>

> [6] <a href="https://docs.openstack.org/glance/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>glance/latest/</a><br>

> [7] <a href="https://docs.openstack.org/neutron/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>neutron/latest/</a><br>

> [8] <a href="https://review.openstack.org/#/c/477497/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/477497/</a><br>

> [9]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-gu" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/admin-gu</a><br>

> ide/source/cli-nova-specify-<wbr>host.rst<br>

> [10]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-gu" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/admin-gu</a><br>

> ide/source/compute-flavors.rst<br>

> [11]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-gui" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/user-gui</a><br>

> de/source/cli-launch-<wbr>instances.rst<br>

> [12]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-gui" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/user-gui</a><br>

> de/source/cli-delete-an-<wbr>instance.rst<br>

><br>

<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 29<br>

Date: Wed, 2 Aug 2017 10:27:10 -0500<br>

From: Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [trove] Can we move some non-voting broken<br>

        jobs to the experimental queue?<br>

Message-ID: <<a href="mailto:7fad19bb-84f0-bbfa-59a9-979f3f872dbc@gmail.com">7fad19bb-84f0-bbfa-59a9-<wbr>979f3f872dbc@gmail.com</a>><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

I don't dabble in Trove-land often but today I pushed a change and was<br>

watching it in zuul, and noticed that the change runs 26 jobs in the<br>

check queue. Several of those (cassandra, couch, mongo, percona) all<br>

failed nearly immediately with something in the diskimage builder, like<br>

this:<br>

<br>

<a href="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" rel="noreferrer" target="_blank">http://logs.openstack.org/42/<wbr>490042/1/check/gate-trove-<wbr>scenario-dsvm-cassandra-<wbr>single-ubuntu-xenial-nv/<wbr>d38a8c1/logs/devstack-gate-<wbr>post_test_hook.txt.gz#_2017-<wbr>08-02_14_58_16_953</a><br>

<br>

diskimage_builder.element_<wbr>dependencies.<wbr>MissingElementException: Element<br>

'ubuntu-xenial-cassandra' not found<br>

<br>

Is anyone maintaining these jobs? If not, they should be moved to the<br>

experimental queue so they can be run on demand, not in the check queue<br>

for every patch set proposed to Trove. These are also single and<br>

multi-node jobs, so they are needlessly eating up node pool resources.<br>

<br>

--<br>

<br>

Thanks,<br>

<br>

Matt<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 30<br>

Date: Wed, 2 Aug 2017 09:28:18 -0600<br>

From: Chris Friesen <<a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>><br>

To: <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:5981EF92.70402@windriver.com">5981EF92.70402@windriver.com</a>><br>

Content-Type: text/plain; charset="utf-8"; format=flowed<br>

<br>

On 08/02/2017 09:22 AM, Stephen Finucane wrote:<br>

> On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:<br>

<br>

>> 3. The patch for the import of the admin guide [8] is missing some CLI<br>

>> specific pages which are pretty useful given they aren't documented<br>

>> anywhere else, like the forced_host part of the compute API [9].<br>

>> Basically anything that's cli-nova-* in the admin guide should be in the<br>

>> Nova docs. It's also missing the compute-flavors page [10] which is<br>

>> pretty important for using OpenStack at all.<br>

><br>

> This is a tricky one. Based on previous discussions with dhellmann, the plan<br>

> seems to be to replace any references to 'nova xxx' or 'openstack xxx' commands<br>

> (i.e. commands using python-novaclient or python-openstackclient) in favour of<br>

> 'curl'-based requests. The idea here is that the Python clients are not the<br>

> only clients available, and we shouldn't be "mandating" their use by<br>

> referencing them in the docs. I get this, though I don't fully agree with it<br>

> (who really uses curl?)<br>

<br>

Are we going to document the python clients elsewhere then?  Personally I find<br>

it highly useful to have complete examples of how to do things with<br>

python-novaclient or python-openstackclient.<br>

<br>

Given that any users of the raw HTTP API are likely going to be developers,<br>

while users of the CLI tools may not be, it seems more important to give good<br>

examples of using the CLI tools.  Any developer should be able to figure out the<br>

underlying HTTP (using the --debug option of the CLI tool if necessary).<br>

<br>

Chris<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 31<br>

Date: Wed, 2 Aug 2017 16:34:10 +0100 (BST)<br>

From: Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:alpine.OSX.2.21.1708021631240.51828@cdent-m01.vmware.com">alpine.OSX.2.21.<wbr>1708021631240.51828@cdent-m01.<wbr>vmware.com</a>><br>

Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>

<br>

On Wed, 2 Aug 2017, Stephen Finucane wrote:<br>

> Unfortunately I can't think of any cleverer way to identify these broken links<br>

> than manual inspection. I'll do this again for all the patches I've authored<br>

> and try to do them for any others I encounter.<br>

<br>

if there's access available to the web server logs:<br>

<br>

Get access to the server logs, grep for 404 response codes, sort by<br>

url, order by count. Anything that has a high number should be<br>

compared with the .htaccess file that Sean created.<br>

<br>

> This is a tricky one. Based on previous discussions with dhellmann, the plan<br>

> seems to be to replace any references to 'nova xxx' or 'openstack xxx' commands<br>

> (i.e. commands using python-novaclient or python-openstackclient) in favour of<br>

> 'curl'-based requests. The idea here is that the Python clients are not the<br>

> only clients available, and we shouldn't be "mandating" their use by<br>

> referencing them in the docs. I get this, though I don't fully agree with it<br>

> (who really uses curl?). In any case though, this would surely be a big rewrite<br>

> and, per your concerns in #2 above,  doesn't sound like something we should be<br>

> doing in Pike. I guess a basic import is the way to go for now. I'll take care<br>

> of this.<br>

<br>

As much as I think using the raw HTTP is an important learning<br>

tool, using curl in the docs will make the docs very hard to<br>

comprehend.<br>

<br>

--<br>

Chris Dent                      (⊙＿⊙')         <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>

freenode: cdent                                         tw: @anticdent<br>

<br>

------------------------------<br>

<br>

Message: 32<br>

Date: Wed, 02 Aug 2017 16:35:23 +0100<br>

From: Stephen Finucane <<a href="mailto:sfinucan@redhat.com">sfinucan@redhat.com</a>><br>

To: Chris Friesen <<a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>>,<br>

        <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:1501688123.3229.24.camel@redhat.com">1501688123.3229.24.camel@<wbr>redhat.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:<br>

> On 08/02/2017 09:22 AM, Stephen Finucane wrote:<br>

> > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:<br>

> > > 3. The patch for the import of the admin guide [8] is missing some CLI<br>

> > > specific pages which are pretty useful given they aren't documented<br>

> > > anywhere else, like the forced_host part of the compute API [9].<br>

> > > Basically anything that's cli-nova-* in the admin guide should be in the<br>

> > > Nova docs. It's also missing the compute-flavors page [10] which is<br>

> > > pretty important for using OpenStack at all.<br>

> ><br>

> > This is a tricky one. Based on previous discussions with dhellmann, the<br>

> > plan<br>

> > seems to be to replace any references to 'nova xxx' or 'openstack xxx'<br>

> > commands<br>

> > (i.e. commands using python-novaclient or python-openstackclient) in favour<br>

> > of<br>

> > 'curl'-based requests. The idea here is that the Python clients are not the<br>

> > only clients available, and we shouldn't be "mandating" their use by<br>

> > referencing them in the docs. I get this, though I don't fully agree with<br>

> > it<br>

> > (who really uses curl?)<br>

><br>

> Are we going to document the python clients elsewhere then?<br>

<br>

I think the docs would go into the respective python clients docs?<br>

<br>

> Personally I find it highly useful to have complete examples of how to do<br>

> things with python-novaclient or python-openstackclient.<br>

<br>

I agree. Personally, I'd like to see something like Stripe's API docs [1],<br>

maybe through a not-yet-existant 'sphinx-slate' extension [2], but that seems a<br>

lot of work for very little gain and would need serious maintaining.<br>

<br>

> Given that any users of the raw HTTP API are likely going to be developers,<br>

> while users of the CLI tools may not be, it seems more important to give<br>

> good examples of using the CLI tools.  Any developer should be able to figure<br>

> out the underlying HTTP (using the --debug option of the CLI tool if<br>

> necessary).<br>

<br>

I think the main idea is that the 'python-*client's are not the only game in<br>

town and should not be treated as such. Who these other clients are is a<br>

question I don't personally know the answer to, however.<br>

<br>

In any case, this is surely a post-Pike issue, as noted above.<br>

<br>

Stephen<br>

<br>

[1] <a href="https://stripe.com/docs/api" rel="noreferrer" target="_blank">https://stripe.com/docs/api</a><br>

[2] <a href="https://github.com/lord/slate" rel="noreferrer" target="_blank">https://github.com/lord/slate</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 33<br>

Date: Wed, 02 Aug 2017 11:52:30 -0400<br>

From: Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>

To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <1501688953-sup-448@lrrr.local<wbr>><br>

Content-Type: text/plain; charset=UTF-8<br>

<br>

Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:<br>

> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:<br>

> > On 08/02/2017 09:22 AM, Stephen Finucane wrote:<br>

> > > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:<br>

> > > > 3. The patch for the import of the admin guide [8] is missing some CLI<br>

> > > > specific pages which are pretty useful given they aren't documented<br>

> > > > anywhere else, like the forced_host part of the compute API [9].<br>

> > > > Basically anything that's cli-nova-* in the admin guide should be in the<br>

> > > > Nova docs. It's also missing the compute-flavors page [10] which is<br>

> > > > pretty important for using OpenStack at all.<br>

> > ><br>

> > > This is a tricky one. Based on previous discussions with dhellmann, the<br>

> > > plan<br>

> > > seems to be to replace any references to 'nova xxx' or 'openstack xxx'<br>

> > > commands<br>

> > > (i.e. commands using python-novaclient or python-openstackclient) in favour<br>

> > > of<br>

> > > 'curl'-based requests. The idea here is that the Python clients are not the<br>

> > > only clients available, and we shouldn't be "mandating" their use by<br>

> > > referencing them in the docs. I get this, though I don't fully agree with<br>

> > > it<br>

> > > (who really uses curl?)<br>

> ><br>

> > Are we going to document the python clients elsewhere then?<br>

><br>

> I think the docs would go into the respective python clients docs?<br>

<br>

Right. I don't remember the details of the curl discussion, but I<br>

think what I was trying to say there was that the "nova" command<br>

line tool installed via python-novaclient should be documented as<br>

part of the openstack/python-novaclient repo rather than openstack/nova.<br>

A CLI reference for nova-manage, which I think is in openstack/nova,<br>

could be documented in openstack/nova.<br>

<br>

Basically, put the docs with the code, which is the whole point of this<br>

migration.<br>

<br>

Doug<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 34<br>

Date: Thu, 3 Aug 2017 00:55:35 +0900<br>

From: Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID:<br>

        <CALhU9tnhUusRL0N5R0N+<wbr>o3SqOhuO3B5W=<a href="mailto:4oLtAQ1hejJ0eieqA@mail.gmail.com">4oLtAQ1hejJ0eieqA<wbr>@mail.gmail.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

Thanks for summarizing the concerns. It is really helpful for all projects!<br>

<br>

2017-08-02 23:55 GMT+09:00 Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>>:<br>

> Now that Stephen Finucane is back from enjoying his youth and gallivanting<br>

> all over Europe, and we talked about a few things in IRC this morning on the<br>

> docs migration for Nova, I wanted to dump my concerns here for broader<br>

> consumption.<br>

><br>

> 1. We know we have to fix a bunch of broken links by adding in redirects [1]<br>

> which sdague started here [2]. However, that apparently didn't catch<br>

> everything, e.g. [3], so I'm concerned we're missing other broken links. Is<br>

> there a way to find out?<br>

><br>

> 2. The bottom change in the docs migration series for Nova is a massive<br>

> refactor of the layout of the Nova devref [4]. That's something I don't want<br>

> to do in Pike for two reasons:<br>

><br>

> a) It's a huge change and we simply don't have the time to invest in<br>

> properly assessing and reviewing it before Pike RC1.<br>

><br>

> b) I think that if we're going to refactor the Nova devref home page to be a<br>

> certain format, then we should really consider doing the same thing in the<br>

> other projects, because today they are all different formats [5][6][7]. This<br>

> is likely a cross-project discussion for the Queens PTG to determine if the<br>

> home page for the projects should look similar. It seems they should given<br>

> the uniformity that the Foundation has been working toward lately.<br>

<br>

Totally agree for PTG topics. we need some guideline on what the top pages of<br>

individual projects should be and what are expected for top pages of<br>

sub directories.<br>

When the doc-migration started, I chatted on this a bit with asettle.<br>

The top page of each subdirectory (like admin, install and so on) are<br>

expected to link<br>

from a landing page on <a href="http://docs.openstack.org" rel="noreferrer" target="_blank">docs.openstack.org</a>. On the other hand, we also need to<br>

take care of the top page of individual projects. In neutron case, we<br>

basically try to<br>

accommodate all documents in the standard directory structure and keep<br>

the top page as much as simple.<br>

It is really nice to have a consistent guideline on this.<br>

<br>

> 3. The patch for the import of the admin guide [8] is missing some CLI<br>

> specific pages which are pretty useful given they aren't documented anywhere<br>

> else, like the forced_host part of the compute API [9]. Basically anything<br>

> that's cli-nova-* in the admin guide should be in the Nova docs. It's also<br>

> missing the compute-flavors page [10] which is pretty important for using<br>

> OpenStack at all.<br>

<br>

Perhaps what we need are pages which explains how to use and configure<br>

a specific feature using on CLI and/or some. It might be beyond the<br>

scope of cli-nova-*.<br>

I think the end-user and admin guides can be refactored per topic.<br>

<br>

> 4. Similar to #3, but we don't have a patch yet for importing the user guide<br>

> and there are several docs in the user guide that are Nova specific so I'd<br>

> like to make sure we include those, like [11][12].<br>

><br>

> [1]<br>

> <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-August/120418.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>August/120418.html</a><br>

> [2] <a href="https://review.openstack.org/#/c/489650/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489650/</a><br>

> [3] <a href="https://review.openstack.org/#/c/489641/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489641/</a><br>

> [4] <a href="https://review.openstack.org/#/c/478485/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/478485/</a><br>

> [5] <a href="https://docs.openstack.org/cinder/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>cinder/latest/</a><br>

> [6] <a href="https://docs.openstack.org/glance/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>glance/latest/</a><br>

> [7] <a href="https://docs.openstack.org/neutron/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>neutron/latest/</a><br>

> [8] <a href="https://review.openstack.org/#/c/477497/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/477497/</a><br>

> [9]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-guide/source/cli-nova-specify-host.rst" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/admin-guide/source/<wbr>cli-nova-specify-host.rst</a><br>

> [10]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-guide/source/compute-flavors.rst" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/admin-guide/source/<wbr>compute-flavors.rst</a><br>

> [11]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-guide/source/cli-launch-instances.rst" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/user-guide/source/<wbr>cli-launch-instances.rst</a><br>

> [12]<br>

> <a href="https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/user-guide/source/cli-delete-an-instance.rst" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>openstack-manuals/blob/stable/<wbr>ocata/doc/user-guide/source/<wbr>cli-delete-an-instance.rst</a><br>

><br>

> --<br>

><br>

> Thanks,<br>

><br>

> Matt<br>

><br>

> ______________________________<wbr>______________________________<wbr>______________<br>

> OpenStack Development Mailing List (not for usage questions)<br>

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 35<br>

Date: Thu, 3 Aug 2017 01:02:59 +0900<br>

From: Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID:<br>

        <CALhU9tm=<a href="mailto:93Hm9K_NJasayeYV6yCC2NU3AyVGRmsrbY8-a3se5Q@mail.gmail.com">93Hm9K_<wbr>NJasayeYV6yCC2NU3AyVGRmsrbY8-<wbr>a3se5Q@mail.gmail.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

2017-08-03 0:52 GMT+09:00 Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>>:<br>

> Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:<br>

>> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:<br>

>> > On 08/02/2017 09:22 AM, Stephen Finucane wrote:<br>

>> > > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:<br>

>> > > > 3. The patch for the import of the admin guide [8] is missing some CLI<br>

>> > > > specific pages which are pretty useful given they aren't documented<br>

>> > > > anywhere else, like the forced_host part of the compute API [9].<br>

>> > > > Basically anything that's cli-nova-* in the admin guide should be in the<br>

>> > > > Nova docs. It's also missing the compute-flavors page [10] which is<br>

>> > > > pretty important for using OpenStack at all.<br>

>> > ><br>

>> > > This is a tricky one. Based on previous discussions with dhellmann, the<br>

>> > > plan<br>

>> > > seems to be to replace any references to 'nova xxx' or 'openstack xxx'<br>

>> > > commands<br>

>> > > (i.e. commands using python-novaclient or python-openstackclient) in favour<br>

>> > > of<br>

>> > > 'curl'-based requests. The idea here is that the Python clients are not the<br>

>> > > only clients available, and we shouldn't be "mandating" their use by<br>

>> > > referencing them in the docs. I get this, though I don't fully agree with<br>

>> > > it<br>

>> > > (who really uses curl?)<br>

>> ><br>

>> > Are we going to document the python clients elsewhere then?<br>

>><br>

>> I think the docs would go into the respective python clients docs?<br>

><br>

> Right. I don't remember the details of the curl discussion, but I<br>

> think what I was trying to say there was that the "nova" command<br>

> line tool installed via python-novaclient should be documented as<br>

> part of the openstack/python-novaclient repo rather than openstack/nova.<br>

> A CLI reference for nova-manage, which I think is in openstack/nova,<br>

> could be documented in openstack/nova.<br>

><br>

> Basically, put the docs with the code, which is the whole point of this<br>

> migration.<br>

<br>

It is true for CLI reference.<br>

The gray zone is CLI stuffs in the admin guide and/or end-user guide.<br>

I think this is the point Matt raised.<br>

cli-nova-* stuffs in the admin guide was per topic like launching instance,<br>

migrating instances and so on. It is actually beyond the CLI reference to me.<br>

It is about how to use specific features of nova.<br>

IMHO this kind of stuffs can be covered by the admin guide or user guide,<br>

so it fits into openstack/nova (or other server projects).<br>

<br>

Akihiro<br>

<br>

><br>

> Doug<br>

><br>

> ______________________________<wbr>______________________________<wbr>______________<br>

> OpenStack Development Mailing List (not for usage questions)<br>

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 36<br>

Date: Wed, 02 Aug 2017 12:20:00 -0400<br>

From: Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>

To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <1501690251-sup-600@lrrr.local<wbr>><br>

Content-Type: text/plain; charset=UTF-8<br>

<br>

Excerpts from Akihiro Motoki's message of 2017-08-03 01:02:59 +0900:<br>

> 2017-08-03 0:52 GMT+09:00 Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>>:<br>

> > Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:<br>

> >> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:<br>

> >> > On 08/02/2017 09:22 AM, Stephen Finucane wrote:<br>

> >> > > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:<br>

> >> > > > 3. The patch for the import of the admin guide [8] is missing some CLI<br>

> >> > > > specific pages which are pretty useful given they aren't documented<br>

> >> > > > anywhere else, like the forced_host part of the compute API [9].<br>

> >> > > > Basically anything that's cli-nova-* in the admin guide should be in the<br>

> >> > > > Nova docs. It's also missing the compute-flavors page [10] which is<br>

> >> > > > pretty important for using OpenStack at all.<br>

> >> > ><br>

> >> > > This is a tricky one. Based on previous discussions with dhellmann, the<br>

> >> > > plan<br>

> >> > > seems to be to replace any references to 'nova xxx' or 'openstack xxx'<br>

> >> > > commands<br>

> >> > > (i.e. commands using python-novaclient or python-openstackclient) in favour<br>

> >> > > of<br>

> >> > > 'curl'-based requests. The idea here is that the Python clients are not the<br>

> >> > > only clients available, and we shouldn't be "mandating" their use by<br>

> >> > > referencing them in the docs. I get this, though I don't fully agree with<br>

> >> > > it<br>

> >> > > (who really uses curl?)<br>

> >> ><br>

> >> > Are we going to document the python clients elsewhere then?<br>

> >><br>

> >> I think the docs would go into the respective python clients docs?<br>

> ><br>

> > Right. I don't remember the details of the curl discussion, but I<br>

> > think what I was trying to say there was that the "nova" command<br>

> > line tool installed via python-novaclient should be documented as<br>

> > part of the openstack/python-novaclient repo rather than openstack/nova.<br>

> > A CLI reference for nova-manage, which I think is in openstack/nova,<br>

> > could be documented in openstack/nova.<br>

> ><br>

> > Basically, put the docs with the code, which is the whole point of this<br>

> > migration.<br>

><br>

> It is true for CLI reference.<br>

> The gray zone is CLI stuffs in the admin guide and/or end-user guide.<br>

> I think this is the point Matt raised.<br>

> cli-nova-* stuffs in the admin guide was per topic like launching instance,<br>

> migrating instances and so on. It is actually beyond the CLI reference to me.<br>

> It is about how to use specific features of nova.<br>

> IMHO this kind of stuffs can be covered by the admin guide or user guide,<br>

> so it fits into openstack/nova (or other server projects).<br>

<br>

Yeah, I don't know.<br>

<br>

My gut response is to say that if the example uses nova-manage or<br>

one of the nova service executables, then that makes sense to leave<br>

in the nova tree, but otherwise it should go into either the<br>

python-novaclient or python-openstackclient repositories (depending<br>

on which command line tool is used in the example).<br>

<br>

On the other hand, I can see that being somewhat confusing for<br>

someone who lands at the nova docs and can't find instructions for<br>

how to use it. Maybe less confusing, though, than if I am not<br>

*running* nova but am trying to use a nova deployed by someone else<br>

and I start from the python-novaclient or python-openstackclient<br>

docs because I installed one of those in order to talk to nova.<br>

<br>

I thought "put the docs with the code" would be a simple enough<br>

rule that we wouldn't have to think too hard about where to put<br>

individual example files, which would speed up the migration.<br>

<br>

Doug<br>

<br>

><br>

> Akihiro<br>

><br>

> ><br>

> > Doug<br>

> ><br>

> > ______________________________<wbr>______________________________<wbr>______________<br>

> > OpenStack Development Mailing List (not for usage questions)<br>

> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 37<br>

Date: Wed, 2 Aug 2017 18:20:32 +0200<br>

From: Carlos Camacho Gonzalez <<a href="mailto:ccamacho@redhat.com">ccamacho@redhat.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [tripleo] Proposing Bogdan Dobrelya core<br>

        on TripleO / Containers<br>

Message-ID:<br>

        <<wbr>CANYJBfa288xLyvu1PpjoLsDMrgXye<wbr>fxRmK07G6kT=<a href="mailto:ed8mv_gDw@mail.gmail.com">ed8mv_gDw@mail.<wbr>gmail.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

Congrats!<br>

<br>

On Mon, Jul 31, 2017 at 6:29 PM, Bogdan Dobrelya <<a href="mailto:bdobreli@redhat.com">bdobreli@redhat.com</a>> wrote:<br>

> On 31.07.2017 15:51, Emilien Macchi wrote:<br>

>> On Fri, Jul 21, 2017 at 7:55 AM, Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br>

>>> Hi,<br>

>>><br>

>>> Bogdan (bogdando on IRC) has been very active in Containerization of<br>

>>> TripleO and his quality of review has increased over time.<br>

>>> I would like to give him core permissions on container work in TripleO.<br>

>>> Any feedback is welcome as usual, we'll vote as a team.<br>

>><br>

>> Votes were positive, it's done now.<br>

>> Bogdan has now +2 and we expect him to use it on patches related to<br>

>> container work.<br>

>><br>

>> Thanks,<br>

>><br>

><br>

> Thank you for your votes!<br>

><br>

> --<br>

> Best regards,<br>

> Bogdan Dobrelya,<br>

> Irc #bogdando<br>

><br>

> ______________________________<wbr>______________________________<wbr>______________<br>

> OpenStack Development Mailing List (not for usage questions)<br>

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 38<br>

Date: Wed, 2 Aug 2017 11:21:11 -0500<br>

From: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [all] Rollout of Zuul v3 at the PTG<br>

Message-ID: <<a href="mailto:ead295c8-35f2-7e57-11aa-f306722f4a29@inaugust.com">ead295c8-35f2-7e57-11aa-<wbr>f306722f4a29@inaugust.com</a>><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

Hey everybody!<br>

<br>

The time has come at long last, we're actually aiming at a concrete date<br>

for rolling Zuul v3 live. \o/<br>

<br>

tl;dr - Assuming things go well we want to do it at the PTG<br>

<br>

We couldn't be more excited - there are a giant pile of feature requests<br>

from folks that we've been responding with "yes, as soon as Zuul v3 is<br>

here you can do that" - and that's not any more fun for us as it is for you.<br>

<br>

If you have no idea what Zuul v3 is - there is a section at the end of<br>

the email just for you.<br>

<br>

The Plan<br>

========<br>

<br>

Zuul v3 itself works great - we're using it to run tests on Zuul itself.<br>

The biggest bulk of work at the moment is ... job content.<br>

<br>

We know that we can do a one-time migration of job content - because we<br>

do it every day for our current jobs (they are translated from<br>

jenkins-job-builder to ansible on the fly in Zuul 2.5 today) However,<br>

that translated content is ugly - and Zuul v3 allows us to make a bunch<br>

of things nicer. We'd like to have as many of our jobs translated to<br>

'nice' versions for the cutover as possible so that as people copy-pasta<br>

jobs they've got good content to work from.<br>

<br>

We're currently working on writing v3-native versions of the most common<br>

jobs. This includes the tox-based unittest jobs and common things like<br>

tarball creation, pypi and docs publication. Next up is getting<br>

devstack-gate jobs done. Between tox and devstack-gate - we should have<br>

the majority of our jobs covered, so any outliers we couldn't<br>

auto-translate into something nice and new will have good examples to<br>

work from for followup cleaning.<br>

<br>

devstack-gate question<br>

----------------------<br>

<br>

There is an open question for devstack-gate. Namely - given the<br>

mechanism of how it works with defining a bunch of environment variables<br>

and then defining a shell function - it's currently unknown if we'll be<br>

able to fully auto-translate all of the existing project-specific<br>

special devstack-gate jobs, or whether we'll need to just migrate them<br>

all to things that look pretty similar to how they look now and have a<br>

few clear examples people can follow as they feel like updating things.<br>

<br>

We should know more about that soon as we're working devstack-gate jobs<br>

this week.<br>

<br>

Go Live<br>

-------<br>

<br>

On the Saturday and Sunday immediately preceeding the PTG, we will run a<br>

few trial cutovers. That is, we'll do a short zuul downtime, run job<br>

migration scripts, turn zuul v3 on, run for a little bit to see how<br>

things go, then turn it off and turn v2 back on. This will let us<br>

double-check the migration during a time that's likely slower than<br>

normal for any last minute dead-in-the-water issues.<br>

<br>

First thing Monday morning of the PTG, we'll throw the switch for real.<br>

We'll be around all week in a sort of "open office hours" form to help<br>

folks if there are any questions, if there are any job execution edge<br>

cases that need to be worked through - or if people are now excited by<br>

all the new features and have questions about how to make use of them.<br>

<br>

We'll essentially be planning on our PTG to be all about making sure any<br>

questions any of you have can be fielded with plenty of bandwidth.<br>

<br>

It's possible we won't be ready. We're pretty optimistic, but this is a<br>

big move, and something unforseen could come up between now and then.<br>

We're not going to throw the switch without being confident that things<br>

will go well just to meet a date. If we decide to cancel the cutover,<br>

we'll send an announcement to the list<br>

<br>

Between Now and Then<br>

====================<br>

<br>

By and large the leadup to this should have very little impact on folks.<br>

<br>

There are some jobs that use scripts that are pre-baked into images that<br>

come from the jenkins/scripts directory in project-config. Those will no<br>

longer be used in Zuul v3 and will be migrated into Zuul v3 job<br>

definitions. Those scripts are currently under a soft-freeze, meaning<br>

that we'd prefer to not make any changes to them - but if a change is<br>

needed we need to ensure it gets forward-ported to the zuulv3 version.<br>

Closer to the PTG we'll put those scripts under a hard-freeze. They're<br>

all tricky to deal with anyway because they get baked in to images, so<br>

we're not expecting a ton of impact from that.<br>

<br>

We may need to freeze all of project-config in the days leading up to<br>

the cutover, but since those are the days leading up to the PTG it's<br>

unlikely that should be a super active time for that repo.<br>

<br>

Third Party CI<br>

==============<br>

<br>

Any Third Party CI that is currently using Zuul should continue using<br>

Zuul v2 as you are today. Once we go live for OpenStack we'll be in a<br>

position to start discussing upgrade plans for 3rd Party operators. The<br>

goal is to migrate all of you - but we don't want folks to start<br>

tackling that until we're happy we've got automation and documentation<br>

worked out. After the PTG will be a great time to start discussing what<br>

that plan wants to look like.<br>

<br>

Wait - what the heck is Zuul v3 and why are we doing this?<br>

==============================<wbr>============================<br>

<br>

We've started a documentation page on this topic in the Infra Manual.<br>

It is short right now, but as we get closer to the cutover, we will<br>

continue to update this page with information about the migration:<br>

<br>

     <a href="https://docs.openstack.org/infra/manual/zuulv3.html" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>infra/manual/zuulv3.html</a><br>

<br>

Zuul v3 is the new version of Zuul that incorporates a ton of learning<br>

about pain points from the last several years. It adds in-repo config,<br>

native multi-node testing, ansible-based job definitions, full DAG job<br>

dependencies and support for integration with systems OpenStack doesn't<br>

otherwise use such as GitHub.<br>

<br>

Zuul v3 is designed to be run by not-Infra. We're happy that Zuul has<br>

been useful for other people over the past few years, especially our<br>

Third-Party CI community - but up until v3 the OpenStack project was<br>

always consideration #1 and other users were best-effort.<br>

<br>

With v3 we formally consider users who are not the OpenStack Project to<br>

be first-class users. We have recently added 3 core reviewers to Zuul<br>

who are not involved with running OpenStack's Zuul. (one runs a Zuul v3<br>

at BMW and two run a Zuul v3 for the IBM BonnyCI project)<br>

<br>

We have a bunch of work teed up for post PTG rollout to add more support<br>

for a wider array of usecases. The OpNFV Infra team has an important<br>

feature request that Tristan from the RH Software Factory team has<br>

started implementing. We have planned support for container execution,<br>

both on a single-container and a COE (kubernetes/mesos) level, as well<br>

as additional triggers/reporters such as FedMsg as used by Fedora and<br>

Debian projects.<br>

<br>

More information on the background of Zuul v3 can be found at:<br>

<br>

<a href="https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html" rel="noreferrer" target="_blank">https://specs.openstack.org/<wbr>openstack-infra/infra-specs/<wbr>specs/zuulv3.html</a><br>

<br>

and<br>

<br>

<a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/113065.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>February/113065.html</a><br>

<br>

Docs for Zuul v3 itself can currently be found at:<br>

<br>

<a href="https://docs.openstack.org/infra/zuul/feature/zuulv3/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>infra/zuul/feature/zuulv3/</a><br>

<br>

As usual, you can find us in #openstack-infra and in #zuul.<br>

<br>

Thanks!<br>

Monty<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 39<br>

Date: Wed, 02 Aug 2017 09:28:52 -0700<br>

From: Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID:<br>

        <<a href="mailto:1501691332.1382598.1060933592.04ED4028@webmail.messagingengine.com">1501691332.1382598.<wbr>1060933592.04ED4028@webmail.<wbr>messagingengine.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:<br>

> Now that Stephen Finucane is back from enjoying his youth and<br>

> gallivanting all over Europe, and we talked about a few things in IRC<br>

> this morning on the docs migration for Nova, I wanted to dump my<br>

> concerns here for broader consumption.<br>

><br>

> 1. We know we have to fix a bunch of broken links by adding in redirects<br>

> [1] which sdague started here [2]. However, that apparently didn't catch<br>

> everything, e.g. [3], so I'm concerned we're missing other broken links.<br>

> Is there a way to find out?<br>

<br>

The infra team can generate lists of 404 urls fairly easily on the docs<br>

server. This won't show you everything but will show you what urls<br>

people are finding/using that 404.<br>

<br>

><br>

<br>

snip<br>

<br>

> [1]<br>

> <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-August/120418.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>August/120418.html</a><br>

> [2] <a href="https://review.openstack.org/#/c/489650/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489650/</a><br>

> [3] <a href="https://review.openstack.org/#/c/489641/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489641/</a><br>

<br>

Clark<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 40<br>

Date: Wed, 02 Aug 2017 17:55:38 +0100<br>

From: Stephen Finucane <<a href="mailto:sfinucan@redhat.com">sfinucan@redhat.com</a>><br>

To: Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>>,<br>

        <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:1501692938.3229.26.camel@redhat.com">1501692938.3229.26.camel@<wbr>redhat.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

On Wed, 2017-08-02 at 09:28 -0700, Clark Boylan wrote:<br>

> On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:<br>

> > Now that Stephen Finucane is back from enjoying his youth and<br>

> > gallivanting all over Europe, and we talked about a few things in IRC<br>

> > this morning on the docs migration for Nova, I wanted to dump my<br>

> > concerns here for broader consumption.<br>

> ><br>

> > 1. We know we have to fix a bunch of broken links by adding in redirects<br>

> > [1] which sdague started here [2]. However, that apparently didn't catch<br>

> > everything, e.g. [3], so I'm concerned we're missing other broken links.<br>

> > Is there a way to find out?<br>

><br>

> The infra team can generate lists of 404 urls fairly easily on the docs<br>

> server. This won't show you everything but will show you what urls<br>

> people are finding/using that 404.<br>

<br>

I'd appreciate that. Have been going through things manually this afternoon but<br>

it's slow work. Can you do this (or know who could)?<br>

<br>

Stephen<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 41<br>

Date: Wed, 2 Aug 2017 10:23:18 -0700<br>

From: Sridhar Ramaswamy <<a href="mailto:srics.r@gmail.com">srics.r@gmail.com</a>><br>

To: gongys2017 <<a href="mailto:gongys2017@aliyun.com">gongys2017@aliyun.com</a>>,  "OpenStack Development<br>

        Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [Tacker] Proposing yanxingan for Tacker<br>

        core<br>

Message-ID:<br>

        <<a href="mailto:CAK6Sh4B6BiG7QG0qNMSpi5YRMSYy6wB7yoNveP3AQNRiiwAZ1Q@mail.gmail.com">CAK6Sh4B6BiG7QG0qNMSpi5YRMSYy<wbr>6wB7yoNveP3AQNRiiwAZ1Q@mail.<wbr>gmail.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

+2<br>

<br>

Thanks Yan for your contribution to Tacker.<br>

<br>

On Jul 27, 2017 10:15 AM, "gongys2017" <<a href="mailto:gongys2017@aliyun.com">gongys2017@aliyun.com</a>> wrote:<br>

<br>

<br>

I am proposing we add Yan xingan as a Tacker core.<br>

<br>

Yanxingan is woking in china mobile, a telecom company which has big<br>

requirement<br>

on NFV MANO. We are proud of having him on tacker team, and promoting the<br>

usage of<br>

tacker in his company.<br>

<br>

In not long time, he has contributed lots on project, such as review, BP<br>

and active in tacker project meeting.<br>

he has also done presentation on tacker to make propaganda of this project.<br>

<br>

Tacker cores, please respond with your opinion. If no reason is given to do<br>

otherwise, I will add Yan xingan to the core group in one week.<br>

<br>

Thanks,<br>

Yong Sheng Gong<br>

<br>

<br>

[1] <a href="https://review.openstack.org/#/q/owner:yanxingan%2540cmss" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/owner:yanxingan%2540cmss</a>.<br>

<a href="http://chinamobile.com" rel="noreferrer" target="_blank">chinamobile.com</a><br>

<<a href="https://review.openstack.org/#/q/owner:%22TommyLike+%253Ctommylikehu%2540gmail.com%253E%22++status:merged" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/q/owner:%22TommyLike+%<wbr>253Ctommylikehu%2540gmail.com%<wbr>253E%22++status:merged</a>><br>

<br>

______________________________<wbr>______________________________<wbr>______________<br>

OpenStack Development Mailing List (not for usage questions)<br>

Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/101440e8/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/101440e8/<wbr>attachment-0001.html</a>><br>

<br>

------------------------------<br>

<br>

Message: 42<br>

Date: Wed, 2 Aug 2017 13:34:22 -0400<br>

From: Mathieu Gagné <<a href="mailto:mgagne@calavera.ca">mgagne@calavera.ca</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID:<br>

        <<a href="mailto:CAFee_oRtpDN4Xk44gM6J-LWgu7tWDD%2BUpLy7BwYTAwn8GKU8iA@mail.gmail.com">CAFee_oRtpDN4Xk44gM6J-<wbr>LWgu7tWDD+UpLy7BwYTAwn8GKU8iA@<wbr>mail.gmail.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

On Wed, Aug 2, 2017 at 12:28 PM, Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br>

> On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:<br>

>> Now that Stephen Finucane is back from enjoying his youth and<br>

>> gallivanting all over Europe, and we talked about a few things in IRC<br>

>> this morning on the docs migration for Nova, I wanted to dump my<br>

>> concerns here for broader consumption.<br>

>><br>

>> 1. We know we have to fix a bunch of broken links by adding in redirects<br>

>> [1] which sdague started here [2]. However, that apparently didn't catch<br>

>> everything, e.g. [3], so I'm concerned we're missing other broken links.<br>

>> Is there a way to find out?<br>

><br>

> The infra team can generate lists of 404 urls fairly easily on the docs<br>

> server. This won't show you everything but will show you what urls<br>

> people are finding/using that 404.<br>

><br>

<br>

Thanks for proposing this proactive solution.<br>

I find it *very frustrating* to Google something and land on a 404 error.<br>

Especially when the user survey keeps asking "How often do users refer<br>

to documentation from <a href="http://docs.openstack.org" rel="noreferrer" target="_blank">docs.openstack.org</a>?"<br>

I don't often refer to the documentation but as of today, when I does,<br>

it's only to find the page I'm looking for has moved somewhere.<br>

What kind of experience are we giving to the users and operators? (I'm<br>

sure it's with good intents and for the best)<br>

<br>

I'm glad people are addressing the redirection issues.<br>

<br>

--<br>

Mathieu<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 43<br>

Date: Wed, 2 Aug 2017 13:07:17 -0500<br>

From: Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>>, Amy Marrich <<a href="mailto:amy@demarco.com">amy@demarco.com</a>><br>

Subject: Re: [openstack-dev] [OpenStack-Ansible] Not running for<br>

        Queens PTL<br>

Message-ID: <<a href="mailto:103013bc-33bd-e52e-d849-230d5850ec63@gmail.com">103013bc-33bd-e52e-d849-<wbr>230d5850ec63@gmail.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

I couldn't agree more with what others have already said. It's been<br>

awesome to see positive things come out of close communication between<br>

deployment projects and other project teams. I look forward to seeing<br>

the pattern and precedence continue!<br>

<br>

<br>

On 07/31/2017 12:59 PM, Amy Marrich wrote:<br>

> Andy,<br>

><br>

> You'll be missed you did a great job(as did Kevin and Jesse before<br>

> you)! Glad you'll be around still as you'd definitely be missed.<br>

><br>

> Amy (spotz)<br>

><br>

> On Mon, Jul 31, 2017 at 4:48 AM, Andy McCrae <<a href="mailto:andy.mccrae@gmail.com">andy.mccrae@gmail.com</a><br>

> <mailto:<a href="mailto:andy.mccrae@gmail.com">andy.mccrae@gmail.com</a>><wbr>> wrote:<br>

><br>

>     Following on from last week's meeting - I've had 2 cycles as PTL<br>

>     for OSA, which has been a really great experience - we've achieved<br>

>     a lot and built on the strong base we had, which I'm really proud<br>

>     of. I strongly believe that inviting a fresh perspective and new<br>

>     ideas as PTL is a winning strategy - it's served us well so far,<br>

>     and in line with previous PTLs I won't be standing for a 3rd cycle.<br>

><br>

>     Looking forward to assisting the next PTL, and helping to continue<br>

>     to mature and improve the project!<br>

><br>

>     Thanks!<br>

>     Andy<br>

><br>

>     ______________________________<wbr>______________________________<wbr>______________<br>

>     OpenStack Development Mailing List (not for usage questions)<br>

>     Unsubscribe:<br>

>     <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

>     <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>

>     <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

>     <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>

><br>

><br>

><br>

><br>

> ______________________________<wbr>______________________________<wbr>______________<br>

> OpenStack Development Mailing List (not for usage questions)<br>

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/a6782979/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/a6782979/<wbr>attachment-0001.html</a>><br>

-------------- next part --------------<br>

A non-text attachment was scrubbed...<br>

Name: signature.asc<br>

Type: application/pgp-signature<br>

Size: 833 bytes<br>

Desc: OpenPGP digital signature<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/a6782979/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/a6782979/<wbr>attachment-0001.sig</a>><br>

<br>

------------------------------<br>

<br>

Message: 44<br>

Date: Wed, 2 Aug 2017 18:14:42 +0000<br>

From: "Walsh, Helen" <<a href="mailto:Helen.Walsh@dell.com">Helen.Walsh@dell.com</a>><br>

To: "'<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>'"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] string freeze exception for VMAX driver<br>

Message-ID:<br>

        <<a href="mailto:6031C821D2144A4CB722005A21B34BD53AB12F7D@MX202CL02.corp.emc.com">6031C821D2144A4CB722005A21B34<wbr>BD53AB12F7D@MX202CL02.corp.<wbr>emc.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

<br>

<br>

To whom it may concern,<br>

<br>

I would like to request a string freeze exception for 2 patches that are on the merge queue for Pike.<br>

<br>

<br>

<br>

1.     VMAX driver - align VMAX QOS settings with front end  (CI Passed)<br>

<a href="https://review.openstack.org/#/c/484885/7/cinder/volume/drivers/dell_emc/vmax/rest.py" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/484885/7/cinder/volume/<wbr>drivers/dell_emc/vmax/rest.py</a>  line 800 (removal of exception message)<br>

<br>

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<br>

Broke CI on previous patches.<br>

<br>

<br>

<br>

2.       VMAX driver - seamless upgrade from SMI-S to REST (CI Pending)<br>

<a href="https://review.openstack.org/#/c/482138/19/cinder/volume/drivers/dell_emc/vmax/common.py" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/482138/19/cinder/volume/<wbr>drivers/dell_emc/vmax/common.<wbr>py</a>   line 1400 ,1455 (message changes)<br>

<br>

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.<br>

<br>

Thank you,<br>

Helen<br>

<br>

<br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/71aea9cf/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/71aea9cf/<wbr>attachment-0001.html</a>><br>

<br>

------------------------------<br>

<br>

Message: 45<br>

Date: Wed, 2 Aug 2017 13:32:16 -0500<br>

From: Matthew Thode <<a href="mailto:prometheanfire@gentoo.org">prometheanfire@gentoo.org</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [release][requirements] FFE release for<br>

        reno 2.5.0<br>

Message-ID: <<a href="mailto:20170802183216.GD27937@gentoo.org">20170802183216.GD27937@<wbr>gentoo.org</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

On 17-08-02 23:18:19, Tony Breeds wrote:<br>

> On Wed, Aug 02, 2017 at 08:39:07AM -0400, Doug Hellmann wrote:<br>

> > We have a few projects that have modified stable branch release<br>

> > notes by editing the files on master, which makes those notes appear<br>

> > as part of the current release. Reno has a new option to address<br>

> > that problem by ignoring some note files, and I would like to release<br>

> > that version to allow project teams to fix up their release notes<br>

> > for pike. I really thought I had already released that update, so<br>

> > I'm sorry for the late request.<br>

> ><br>

> > Reno is only used during release notes builds, but it does appear<br>

> > in the global requirements list and constraints list. I think the<br>

> > risk is minimal.<br>

> ><br>

> > <a href="https://review.openstack.org/489998" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>489998</a><br>

><br>

> Package      : reno [reno!=2.3.1,>=1.8.0] (used by 220 projects)<br>

> Also affects : 220 projects<br>

> <snip><br>

><br>

> So yeah it *could* destabalise the gate for a day if there is an issue.<br>

> I'm not saying that's likely but it has happened in the past.<br>

><br>

> Looking at the reno change log I don't see anything that worries me.<br>

><br>

> From a requirements POV I'm +2 on a u-c bump -2 on a g-r bump.<br>

><br>

> Yours Tony.<br>

<br>

Agreed, the amount of projects that'd be impacted by a GR bump is too<br>

high, but a UC bump is fine.<br>

<br>

--<br>

Matthew Thode (prometheanfire)<br>

-------------- next part --------------<br>

A non-text attachment was scrubbed...<br>

Name: signature.asc<br>

Type: application/pgp-signature<br>

Size: 833 bytes<br>

Desc: not available<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/15b5cf1d/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/15b5cf1d/<wbr>attachment-0001.sig</a>><br>

<br>

------------------------------<br>

<br>

Message: 46<br>

Date: Wed, 2 Aug 2017 13:34:08 -0500<br>

From: Matthew Thode <<a href="mailto:prometheanfire@gentoo.org">prometheanfire@gentoo.org</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [requirements][release][docs] FFE for<br>

        openstack-doc-tools<br>

Message-ID: <<a href="mailto:20170802183408.GE27937@gentoo.org">20170802183408.GE27937@<wbr>gentoo.org</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

On 17-08-02 14:22:35, Andreas Jaeger wrote:<br>

> We need a new release of openstack-doc-tools to handle the changed<br>

> behaviour in how we build documents.<br>

><br>

> The tool is only used by documentation projects for building and nowhere<br>

> else listed in requirements file.<br>

><br>

> Please release this and take the new version in for requirements repo,<br>

><br>

> <a href="https://review.openstack.org/490001" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>490001</a><br>

><br>

> Andreas<br>

<br>

Looks fine here, are you looking for just a UC bump?<br>

<br>

--<br>

Matthew Thode (prometheanfire)<br>

-------------- next part --------------<br>

A non-text attachment was scrubbed...<br>

Name: signature.asc<br>

Type: application/pgp-signature<br>

Size: 833 bytes<br>

Desc: not available<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/832bb3f1/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/832bb3f1/<wbr>attachment-0001.sig</a>><br>

<br>

------------------------------<br>

<br>

Message: 47<br>

Date: Wed, 2 Aug 2017 14:34:40 -0400<br>

From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:867d07e4-9de8-59af-2c51-0ee30d11a930@dague.net">867d07e4-9de8-59af-2c51-<wbr>0ee30d11a930@dague.net</a>><br>

Content-Type: text/plain; charset=utf-8<br>

<br>

On 08/02/2017 12:20 PM, Doug Hellmann wrote:<br>

> Excerpts from Akihiro Motoki's message of 2017-08-03 01:02:59 +0900:<br>

>> 2017-08-03 0:52 GMT+09:00 Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>>:<br>

>>> Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:<br>

>>>> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:<br>

>>>>> On 08/02/2017 09:22 AM, Stephen Finucane wrote:<br>

>>>>>> On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:<br>

>>>>>>> 3. The patch for the import of the admin guide [8] is missing some CLI<br>

>>>>>>> specific pages which are pretty useful given they aren't documented<br>

>>>>>>> anywhere else, like the forced_host part of the compute API [9].<br>

>>>>>>> Basically anything that's cli-nova-* in the admin guide should be in the<br>

>>>>>>> Nova docs. It's also missing the compute-flavors page [10] which is<br>

>>>>>>> pretty important for using OpenStack at all.<br>

>>>>>><br>

>>>>>> This is a tricky one. Based on previous discussions with dhellmann, the<br>

>>>>>> plan<br>

>>>>>> seems to be to replace any references to 'nova xxx' or 'openstack xxx'<br>

>>>>>> commands<br>

>>>>>> (i.e. commands using python-novaclient or python-openstackclient) in favour<br>

>>>>>> of<br>

>>>>>> 'curl'-based requests. The idea here is that the Python clients are not the<br>

>>>>>> only clients available, and we shouldn't be "mandating" their use by<br>

>>>>>> referencing them in the docs. I get this, though I don't fully agree with<br>

>>>>>> it<br>

>>>>>> (who really uses curl?)<br>

>>>>><br>

>>>>> Are we going to document the python clients elsewhere then?<br>

>>>><br>

>>>> I think the docs would go into the respective python clients docs?<br>

>>><br>

>>> Right. I don't remember the details of the curl discussion, but I<br>

>>> think what I was trying to say there was that the "nova" command<br>

>>> line tool installed via python-novaclient should be documented as<br>

>>> part of the openstack/python-novaclient repo rather than openstack/nova.<br>

>>> A CLI reference for nova-manage, which I think is in openstack/nova,<br>

>>> could be documented in openstack/nova.<br>

>>><br>

>>> Basically, put the docs with the code, which is the whole point of this<br>

>>> migration.<br>

>><br>

>> It is true for CLI reference.<br>

>> The gray zone is CLI stuffs in the admin guide and/or end-user guide.<br>

>> I think this is the point Matt raised.<br>

>> cli-nova-* stuffs in the admin guide was per topic like launching instance,<br>

>> migrating instances and so on. It is actually beyond the CLI reference to me.<br>

>> It is about how to use specific features of nova.<br>

>> IMHO this kind of stuffs can be covered by the admin guide or user guide,<br>

>> so it fits into openstack/nova (or other server projects).<br>

><br>

> Yeah, I don't know.<br>

><br>

> My gut response is to say that if the example uses nova-manage or<br>

> one of the nova service executables, then that makes sense to leave<br>

> in the nova tree, but otherwise it should go into either the<br>

> python-novaclient or python-openstackclient repositories (depending<br>

> on which command line tool is used in the example).<br>

><br>

> On the other hand, I can see that being somewhat confusing for<br>

> someone who lands at the nova docs and can't find instructions for<br>

> how to use it. Maybe less confusing, though, than if I am not<br>

> *running* nova but am trying to use a nova deployed by someone else<br>

> and I start from the python-novaclient or python-openstackclient<br>

> docs because I installed one of those in order to talk to nova.<br>

><br>

> I thought "put the docs with the code" would be a simple enough<br>

> rule that we wouldn't have to think too hard about where to put<br>

> individual example files, which would speed up the migration.<br>

<br>

It's not so simple because years ago we decided nova-manage was mostly a<br>

bad thing (as you needed to run it on the API node and be able to read<br>

db creds with it), and exposed as much as possible of the administrative<br>

interfaces over the API. The policy of openstack client was that<br>

administrative commands would not go in openstack client. So a bunch of<br>

what was once nova-manage (5 years ago), is part of the nova cli now,<br>

and not really implemented by other toolkits.<br>

<br>

This is also why the python nova client is not going away any time soon.<br>

<br>

        -Sean<br>

<br>

--<br>

Sean Dague<br>

<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 48<br>

Date: Wed, 2 Aug 2017 14:37:14 -0400<br>

From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:815c61d5-cde6-b1c5-b6da-068181ed5b93@dague.net">815c61d5-cde6-b1c5-b6da-<wbr>068181ed5b93@dague.net</a>><br>

Content-Type: text/plain; charset=utf-8<br>

<br>

On 08/02/2017 12:28 PM, Clark Boylan wrote:<br>

> On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:<br>

>> Now that Stephen Finucane is back from enjoying his youth and<br>

>> gallivanting all over Europe, and we talked about a few things in IRC<br>

>> this morning on the docs migration for Nova, I wanted to dump my<br>

>> concerns here for broader consumption.<br>

>><br>

>> 1. We know we have to fix a bunch of broken links by adding in redirects<br>

>> [1] which sdague started here [2]. However, that apparently didn't catch<br>

>> everything, e.g. [3], so I'm concerned we're missing other broken links.<br>

>> Is there a way to find out?<br>

><br>

> The infra team can generate lists of 404 urls fairly easily on the docs<br>

> server. This won't show you everything but will show you what urls<br>

> people are finding/using that 404.<br>

<br>

If we could get a weekly report of 404 urls posted somewhere public,<br>

that would be extremely useful, because the easy ones based on git<br>

renames are done, and everything else is going to require human<br>

inspection to figure out what the right landing target is.<br>

<br>

        -Sean<br>

<br>

--<br>

Sean Dague<br>

<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 49<br>

Date: Wed, 2 Aug 2017 13:42:20 -0500<br>

From: Anne Gentle | Just Write Click <<a href="mailto:annegentle@justwriteclick.com">annegentle@justwriteclick.com</a><wbr>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID: <<a href="mailto:21A1E90D-8750-4B33-9E0C-38CF1DB7C82B@justwriteclick.com">21A1E90D-8750-4B33-9E0C-<wbr>38CF1DB7C82B@justwriteclick.<wbr>com</a>><br>

Content-Type: text/plain;       charset=us-ascii<br>

<br>

<br>

<br>

> On Aug 2, 2017, at 1:37 PM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>

><br>

>> On 08/02/2017 12:28 PM, Clark Boylan wrote:<br>

>>> On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:<br>

>>> Now that Stephen Finucane is back from enjoying his youth and<br>

>>> gallivanting all over Europe, and we talked about a few things in IRC<br>

>>> this morning on the docs migration for Nova, I wanted to dump my<br>

>>> concerns here for broader consumption.<br>

>>><br>

>>> 1. We know we have to fix a bunch of broken links by adding in redirects<br>

>>> [1] which sdague started here [2]. However, that apparently didn't catch<br>

>>> everything, e.g. [3], so I'm concerned we're missing other broken links.<br>

>>> Is there a way to find out?<br>

>><br>

>> The infra team can generate lists of 404 urls fairly easily on the docs<br>

>> server. This won't show you everything but will show you what urls<br>

>> people are finding/using that 404.<br>

><br>

> If we could get a weekly report of 404 urls posted somewhere public,<br>

> that would be extremely useful, because the easy ones based on git<br>

> renames are done, and everything else is going to require human<br>

> inspection to figure out what the right landing target is.<br>

><br>

<br>

Fantastic idea.<br>

<br>

I love how many more ideas we are getting as more brains share them.<br>

<br>

>    -Sean<br>

><br>

> --<br>

> Sean Dague<br>

> <a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>

><br>

> ______________________________<wbr>______________________________<wbr>______________<br>

> OpenStack Development Mailing List (not for usage questions)<br>

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 50<br>

Date: Wed, 2 Aug 2017 20:44:25 +0200<br>

From: Andreas Jaeger <<a href="mailto:aj@suse.com">aj@suse.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [requirements][release][docs] FFE for<br>

        openstack-doc-tools<br>

Message-ID: <<a href="mailto:50d14336-3d83-82fc-a498-800b3ad3c3d0@suse.com">50d14336-3d83-82fc-a498-<wbr>800b3ad3c3d0@suse.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

On 2017-08-02 20:34, Matthew Thode wrote:<br>

> On 17-08-02 14:22:35, Andreas Jaeger wrote:<br>

>> We need a new release of openstack-doc-tools to handle the changed<br>

>> behaviour in how we build documents.<br>

>><br>

>> The tool is only used by documentation projects for building and nowhere<br>

>> else listed in requirements file.<br>

>><br>

>> Please release this and take the new version in for requirements repo,<br>

>><br>

>> <a href="https://review.openstack.org/490001" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>490001</a><br>

>><br>

>> Andreas<br>

><br>

> Looks fine here, are you looking for just a UC bump?<br>

<br>

After reviewing the affected repos: let's just do the UC bump,<br>

<br>

Andreas<br>

--<br>

 Andreas Jaeger aj@{<a href="http://suse.com" rel="noreferrer" target="_blank">suse.com</a>,<a href="http://opensuse.org" rel="noreferrer" target="_blank">opensuse.org</a>} Twitter: jaegerandi<br>

  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany<br>

   GF: Felix Imendörffer, Jane Smithard, Graham Norton,<br>

       HRB 21284 (AG Nürnberg)<br>

    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126<br>

<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 51<br>

Date: Wed, 2 Aug 2017 11:44:43 -0700<br>

From: Michał Jastrzębski <<a href="mailto:inc007@gmail.com">inc007@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev] [kolla][PTL][elections] Candidacy for Kolla<br>

        PTL<br>

Message-ID:<br>

        <<a href="mailto:CALc0zUDB-8Z9s1uG7hJdfZXUbFpjTH53%2B0Z-_6HTVfE_vNUd-Q@mail.gmail.com">CALc0zUDB-<wbr>8Z9s1uG7hJdfZXUbFpjTH53+0Z-_<wbr>6HTVfE_vNUd-Q@mail.gmail.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

Hello everyone,<br>

<br>

Once more unto the breach dear friends! I would like to run for PTL again for<br>

Queens. Pike was very exciting release for Kolla. With strong focus on<br>

Kolla-Kubernetes, Kolla-Ansible getting more and more production deployments<br>

and Kolla images being successfully consumed by project outside of Kolla<br>

like TripleO or OpenStack-Helm, I think this was quite a success for us.<br>

<br>

We managed to improve one of biggest pain points we saw in Kolla - gates. We<br>

still have lengths to go, but progress is significant.<br>

<br>

I'd love to help our community to make Queens even better. We have several<br>

exiting features in our plates, like automated push mechanism for images or<br>

orchestration layer for kolla-kubernetes.<br>

<br>

We also need to focus on another big pain point of Kolla - documentation.<br>

<br>

I would like us to strengthen cooperation with Kubernetes community and I'm<br>

strong believer that best bridge between communities is built on top of common<br>

technical issues and mutual help. I think Kolla-Kubernetes naturally helps<br>

with this cooperation and we can use it even more.<br>

<br>

Per request, I also add small haiku to my nomination;)<br>

<br>

Glues Stack together<br>

Project by great people made<br>

Queens approaching soon<br>

<br>

Regards,<br>

Michal inc0 Jastrzebski<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 52<br>

Date: Wed, 2 Aug 2017 12:15:10 -0700<br>

From: "Catherine Cuong Diep" <<a href="mailto:cdiep@us.ibm.com">cdiep@us.ibm.com</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a>, <a href="mailto:interop-wg@lists.openstack.org">interop-wg@lists.openstack.org</a><br>

Subject: [openstack-dev] [refstack][interop-wg] Non-candidacy for<br>

        RefStack        PTL<br>

Message-ID:<br>

        <<a href="mailto:OF451E760C.DC645181-ON00258170.00690983-88258170.0069C25F@notes.na.collabserv.com">OF451E760C.DC645181-<wbr>ON00258170.00690983-88258170.<wbr>0069C25F@notes.na.collabserv.<wbr>com</a>><br>

<br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

<br>

Hi Everyone,<br>

<br>

As I had announced in the RefStack IRC meeting a few weeks ago, I will not<br>

run for RefStack PTL in the upcoming cycle. I have been PTL for the last 2<br>

years and it is time to pass the torch to a new leader.<br>

<br>

I would like to thanks everyone for your support and contribution to make<br>

the RefStack project and interoperability testing a reality. We would not<br>

be where we are today without your<br>

commitment and dedication.<br>

<br>

I will still be around to help the project and to work with the next PTL<br>

for a smooth transition.<br>

<br>

Catherine Diep<br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/3cbb7019/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/3cbb7019/<wbr>attachment-0001.html</a>><br>

<br>

------------------------------<br>

<br>

Message: 53<br>

Date: Wed, 2 Aug 2017 14:32:41 -0500<br>

From: Dean Troyer <<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID:<br>

        <<wbr>CAOJFoEtASL4it3cg3vrkSCU1yg2V8<wbr>Jv2bd=<a href="mailto:XmSiMn06MrEw7Ww@mail.gmail.com">XmSiMn06MrEw7Ww@mail.<wbr>gmail.com</a>><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

On Wed, Aug 2, 2017 at 11:20 AM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>

> My gut response is to say that if the example uses nova-manage or<br>

> one of the nova service executables, then that makes sense to leave<br>

> in the nova tree, but otherwise it should go into either the<br>

> python-novaclient or python-openstackclient repositories (depending<br>

> on which command line tool is used in the example).<br>

<br>

I don't think this is a good rule of thumb...<br>

<br>

> On the other hand, I can see that being somewhat confusing for<br>

> someone who lands at the nova docs and can't find instructions for<br>

> how to use it. Maybe less confusing, though, than if I am not<br>

> *running* nova but am trying to use a nova deployed by someone else<br>

> and I start from the python-novaclient or python-openstackclient<br>

> docs because I installed one of those in order to talk to nova.<br>

<br>

When the point of the example is to illustrate configuring nova, the<br>

example should stay with the nova code, even if it uses novaclient or<br>

osc.  The examples that are about _using_ novaclient or osc belong in<br>

those repos, but where they are just a means to configuring something<br>

in nova, they should remain with nova and use the tools that users are<br>

expected to be familiar with (novaclient and/or osc in this example).<br>

<br>

> I thought "put the docs with the code" would be a simple enough<br>

> rule that we wouldn't have to think too hard about where to put<br>

> individual example files, which would speed up the migration.<br>

<br>

If I find a doc that tells me how to set up a VM with a Neutron<br>

network and ports and subnets and floating IPs that uses curl, I'm not<br>

reading farther.<br>

<br>

dt<br>

<br>

--<br>

<br>

Dean Troyer<br>

<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 54<br>

Date: Wed, 02 Aug 2017 13:44:26 -0700<br>

From: Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [nova][docs] Concerns with docs migration<br>

Message-ID:<br>

        <<a href="mailto:1501706666.1436702.1061272472.67255022@webmail.messagingengine.com">1501706666.1436702.<wbr>1061272472.67255022@webmail.<wbr>messagingengine.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

On Wed, Aug 2, 2017, at 11:37 AM, Sean Dague wrote:<br>

> On 08/02/2017 12:28 PM, Clark Boylan wrote:<br>

> > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:<br>

> >> Now that Stephen Finucane is back from enjoying his youth and<br>

> >> gallivanting all over Europe, and we talked about a few things in IRC<br>

> >> this morning on the docs migration for Nova, I wanted to dump my<br>

> >> concerns here for broader consumption.<br>

> >><br>

> >> 1. We know we have to fix a bunch of broken links by adding in redirects<br>

> >> [1] which sdague started here [2]. However, that apparently didn't catch<br>

> >> everything, e.g. [3], so I'm concerned we're missing other broken links.<br>

> >> Is there a way to find out?<br>

> ><br>

> > The infra team can generate lists of 404 urls fairly easily on the docs<br>

> > server. This won't show you everything but will show you what urls<br>

> > people are finding/using that 404.<br>

><br>

> If we could get a weekly report of 404 urls posted somewhere public,<br>

> that would be extremely useful, because the easy ones based on git<br>

> renames are done, and everything else is going to require human<br>

> inspection to figure out what the right landing target is.<br>

><br>

<br>

I've pushed <a href="https://review.openstack.org/#/c/490175/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/490175/</a> which will generate<br>

a report each day for roughly the last day's worth of 404s. You should<br>

be able to see them at <a href="https://docs.openstack.org/404s" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>404s</a> once the change<br>

merges and the cron job fires.<br>

<br>

You can see what that will look like (from my test runs) at<br>

<a href="http://paste.openstack.org/show/617322/" rel="noreferrer" target="_blank">http://paste.openstack.org/<wbr>show/617322/</a>. Note that this isn't a complete<br>

file because <a href="http://paste.openstack.org" rel="noreferrer" target="_blank">paste.openstack.org</a> truncated it but you'll get the full<br>

data from the wbeserver once this change merges.<br>

<br>

Clark<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 55<br>

Date: Wed, 2 Aug 2017 15:47:32 -0500<br>

From: Major Hayden <<a href="mailto:major@mhtx.net">major@mhtx.net</a>><br>

To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>

Subject: Re: [openstack-dev] [openstack-ansible][security] To<br>

        firewalld, or not to firewalld<br>

Message-ID: <<a href="mailto:1d83331d-5c63-2a00-74b2-628e8332f9bf@mhtx.net">1d83331d-5c63-2a00-74b2-<wbr>628e8332f9bf@mhtx.net</a>><br>

Content-Type: text/plain; charset=utf-8<br>

<br>

On 08/02/2017 03:57 AM, Mark Goddard wrote:<br>

> 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.<br>

><br>

> 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.<br>

<br>

Thanks for the feedback!  I'm leaning away from firewalld now and looking at something a little simpler with iptables.<br>

<br>

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.<br>

<br>

[0] <a href="http://ferm.foo-projects.org/" rel="noreferrer" target="_blank">http://ferm.foo-projects.org/</a><br>

[1] <a href="http://ferm.foo-projects.org/download/examples/webserver.ferm" rel="noreferrer" target="_blank">http://ferm.foo-projects.org/<wbr>download/examples/webserver.<wbr>ferm</a><br>

<br>

--<br>

Major Hayden<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 56<br>

Date: Wed, 2 Aug 2017 20:50:06 +0000<br>

From: "McLellan, Steven" <<a href="mailto:steve.mclellan@hpe.com">steve.mclellan@hpe.com</a>><br>

To: "OpenStack Development Mailing List (not for usage questions)"<br>

        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>

Subject: [openstack-dev]  [searchlight] Cancelling IRC meeting August<br>

        2nd<br>

Message-ID: <<a href="mailto:D7C217D9-DB43-4585-916E-030AA1C6D72A@hpe.com">D7C217D9-DB43-4585-916E-<wbr>030AA1C6D72A@hpe.com</a>><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

Hi,<br>

<br>

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.<br>

<br>

Thanks,<br>

<br>

Steve<br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170802/33723f98/attachment.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170802/33723f98/<wbr>attachment.html</a>><br>

<br>

------------------------------<br>

<br>

Subject: Digest Footer<br>

<br>

______________________________<wbr>_________________<br>

OpenStack-dev mailing list<br>

<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.<wbr>org</a><br>

<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>

<br>

<br>

------------------------------<br>

<br>

End of OpenStack-dev Digest, Vol 64, Issue 5<br>

******************************<wbr>**************<br>

</blockquote></div><br></div></div></div>