<div class="zcontentRow"> <p style="font-size:18px;font-family:comic sans ms;">Thanks <span class="author-a-z90zz75zz89zj67e6z65zyz84zz87zz75zz88zkw">mlavalle, </span></p><p style="font-size:18px;font-family:comic sans ms;"><span class="author-a-z90zz75zz89zj67e6z65zyz84zz87zz75zz88zkw">I have </span><span style="font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; line-height: 25.7142868041992px; background-color: rgb(255, 255, 255);">added my information </span><span style="font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; line-height: 25.7142868041992px; background-color: rgb(255, 255, 255);">to the etherpad and expect to discussing the topic about SR-IOV bond as following</span></p><p style="font-size:18px;font-family:comic sans ms;"><span style="font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; line-height: 25.7142868041992px; background-color: rgb(255, 255, 255);"><a href="https://review.openstack.org/#/c/506066/4" _src="https://review.openstack.org/#/c/506066/4">https://review.openstack.org/#/c/506066/4</a></span></p><p style="font-size:18px;font-family:comic sans ms;"><a href="https://review.openstack.org/#/c/463526/" _src="https://review.openstack.org/#/c/463526/">https://review.openstack.org/#/c/463526/</a> </p><p style="font-size:18px;font-family:comic sans ms;"><br></p><p style="font-size:18px;font-family:comic sans ms;"><span style="font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; font-size: 18px; line-height: 25.7142868041992px; background-color: rgb(255, 255, 255);">I am looking forward to see you ~~</span></p><p style="font-size:18px;font-family:comic sans ms;"><br></p><p style="font-size:18px;font-family:comic sans ms;"><br></p><p style="font-size:18px;font-family:comic sans ms;"><br></p><div class="zMailSign" unonamech="张延显10065016" unonameen="zhangyanxian10065016"><p class="zMailSignTitle" unonamech="张延显10065016" unonameen="zhangyanxian10065016" style="display: none;"><label class="sign_nameUno"></label><span class="sign_arrow"></span></p><div class="zMailSignContent"><div><div><div><p style="font-family: 宋体; font-size:14px; line-height: normal; widows: 1;"><span style="font-size:14px;color:#58595B;font-family:微软雅黑;font-size:14px;"><span class="signedit"><br></span></span></p><p style="font-family: 宋体; font-size:14px; line-height: normal; widows: 1;"><span style="font-size:14px;color:#58595B;font-family:微软雅黑"><span class="signedit" id="sign_name">张延显</span> <span style="font-family:Arial"><span class="signedit" id="sign_name_eng">zhangyanxian</span></span></span></p><p style="font-size:14px; line-height: normal; widows: 1;"><span style="font-size:14px;color:#58595B;font-family:微软雅黑;font-size:14px;"><span style=""><span class="signedit"><br></span></span></span></p><p style="font-family: 宋体; font-size:14px; line-height: normal; widows: 1;"><span style="font-size:14px;color:#58595B;font-family:微软雅黑"><span class="signedit" id="sign_position">软件高级系统工程师</span><span style="font-family:Arial"><span class="signedit" id="sign_position_eng">  Senior System Software Engineer</span></span></span><br><span style="font-size:14px;color:#58595B;font-family:微软雅黑"><span class="signedit" id="sign_dept">虚拟化南京一部/无线研究院/无线产品经营部</span> <span style="font-family:Arial"> <span class="signedit" id="sign_dept_eng">NIV Nanjing Dept. I/Wireless Product R&D Institute/Wireless Product Operation Division</span></span></span></p><p style="font-size:14px; line-height: normal; widows: 1;"><span style="font-size:14px;color:#58595B;font-family:微软雅黑;font-size:14px;"><span style=""><span class="signedit"><br></span></span></span></p><p style="font-size:14px; line-height: normal; widows: 1;"><span style="font-size:14px;color:#58595B;font-family:微软雅黑;font-size:14px;"></span></p><table style="color: rgb(0, 0, 0); font-family: 宋体; widows: 1;"><tbody><tr class="firstRow"><td valign="top" width="100"><img id="sign-icon" src="cid:9ae3e214c17d49ed935d87c674ba3ee2" width="130" height="120"></td><td valign="top" width="500" style="word-break: break-all;"><img id="sign-logo" src="cid:24242e5637af428891c4db731e7765ad" width="115" height="38"><br><span style="font-size:14px;color:#58595B;font-family:微软雅黑"><span class="signedit" id="sign_addr">江苏省南京市雨花台区紫荆花路68号中兴南京研发中心 </span><br><span style="font-family:Arial">R&D Building, ZTE Corporation Zijinghua Road No. 68, <br><span class="signedit" id="sign_addr_eng_2">Yuhuatai District, Nanjing City, Jiangsu Province,P.R.China, 210012</span> <br><span style="color:#008FD4">M</span>: <span class="signedit" id="sign_phone">+86 18260022960</span> <br><span style="color:#008FD4">E</span>: <span class="signedit" id="sign_email">zhang.yanxian@zte.com.cn</span> <br><span style="color:#008FD4"><a href="http://www.zte.com.cn/" target="_blank">www.zte.com.cn</a></span></span></span></td></tr></tbody></table><span style="line-height: normal; widows: 1; font-size:14px;;color:#58595b;font-size:10px"></span></div></div></div></div></div><div><div class="zhistoryRow" style="display:block"><div class="zhistoryDes" style="width: 100%; height: 28px; line-height: 28px; background-color: #E0E5E9; color: #1388FF; text-align: center;" language-data="HistoryOrgTxt">原始邮件</div><div id="zwriteHistoryContainer"><div class="control-group zhistoryPanel"><div class="zhistoryHeader" style="padding: 8px; background-color: #F5F6F8;"><div><strong language-data="HistorySenderTxt">发件人:</strong><span class="zreadUserName"> <openstack-dev-request@lists.openstack.org>;</span></div><div><strong language-data="HistoryTOTxt">收件人:</strong><span class="zreadUserName" style="display: inline;"> <openstack-dev@lists.openstack.org>;</span></div><div><strong language-data="HistoryDateTxt">日 期 :</strong><span class="">2017年10月21日 15:37</span></div><div><strong language-data="HistorySubjectTxt">主 题 :</strong><span class="zreadTitle"><strong>OpenStack-dev Digest, Vol 66, Issue 36</strong></span></div></div><p class="zhistoryContent"><br></p></div><div>Send OpenStack-dev mailing list submissions to<br>    openstack-dev@lists.openstack.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>or, via email, send a message with subject or body 'help' to<br>    openstack-dev-request@lists.openstack.org<br><br>You can reach the person managing the list at<br>    openstack-dev-owner@lists.openstack.org<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: [puppet] avoid rechecks (Arnaud MORIN)<br>   2. [nova] [placement] resource providers update 39 (Chris Dent)<br>   3. Re: [keystone][all][tc] v2.0 API removal (Jeremy Stanley)<br>   4. [neutron] [stadium] Tempest plugin split goal for stadium<br>      projects (Bernard Cafarelli)<br>   5. [neutron][vpnaas] core reviewer proposal (Takashi Yamamoto)<br>   6. [neutron][networking-midonet] Core reviewers change    proposal<br>      (Takashi Yamamoto)<br>   7. Fwd: [Distutils][pbr] Announcement: Pip 10 is    coming, and<br>      will move all internal APIs (Doug Hellmann)<br>   8. [tc] Technical Committee Status update, October 20th<br>      (Thierry Carrez)<br>   9. Re: [policy] AWS IAM session (Lance Bragstad)<br>  10. Re: [puppet] avoid rechecks (Mohammed Naser)<br>  11. Do you hate the new gerrit thing where the cursor    jumps all<br>      over? (Matt Riedemann)<br>  12. Re: [OpenStack-docs] [docs] Documentation meeting    Thursday<br>      (Petr Kovar)<br>  13. [docs] Docs meeting time? (was: Documentation    meeting<br>      Thursday) (Petr Kovar)<br>  14. Re: [keystone][all][tc] v2.0 API removal (Yaguang Tang)<br>  15. [docs] Docs meeting time? (was: Documentation meeting<br>      Thursday) (Chan Chason)<br>  16. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0    API<br>      removal (Fox, Kevin M)<br>  17. Re: Do you hate the new gerrit thing where the cursor jumps<br>      all over? (Jeremy Freudberg)<br>  18. Re: Do you hate the new gerrit thing where the cursor jumps<br>      all over? (Clark Boylan)<br>  19. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API<br>      removal (Jeremy Stanley)<br>  20. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0    API<br>      removal (Jeremy Stanley)<br>  21. Re: Do you hate the new gerrit thing where the cursor jumps<br>      all over? (Jeremy Freudberg)<br>  22. Re: Fwd: [Distutils][pbr] Announcement: Pip 10 is coming, and<br>      will move all internal APIs (Clark Boylan)<br>  23. Re: Fwd: [Distutils][pbr] Announcement: Pip 10 is coming, and<br>      will move all internal APIs (Clark Boylan)<br>  24. [ironic] Support for single OpenStack system supporting VM<br>      and Baremetal Instances simultaneously ? (Waines, Greg)<br>  25. Re: [infra] Short gerrit / zuul outage 2017-10-20    20:00UTC<br>      (Ian Wienand)<br>  26. Re: Fwd: [Distutils][pbr] Announcement: Pip 10 is coming, and<br>      will move all internal APIs (Clark Boylan)<br>  27.  [neutron] - are you attending the Sydney summit? (Miguel Lavalle)<br>  28. Re: Fwd: [Distutils][pbr][devstack][qa]    Announcement: Pip 10<br>      is coming, and will move all internal APIs (Doug Hellmann)<br>  29. [qa] Proposing changes to 17UTC team meeting (Andrea Frittoli)<br>  30. [All][Elections] Vote Vote Vote in the TC election!<br>      (Kendall Nelson)<br>  31. Re: Fwd: [Distutils][pbr][devstack][qa] Announcement: Pip 10<br>      is coming, and will move all internal APIs (Sam Yaple)<br>  32. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0    API<br>      removal (Fox, Kevin M)<br>  33. Re: [TripleO][Kolla] Concerns about containers images in<br>      DockerHub (Steven Dake (stdake))<br>  34. Re: Do you hate the new gerrit thing where the cursor jumps<br>      all over? (Tim Burke)<br>  35. [all] [elections] Technical Committee Election    Results<br>      (Kendall Nelson)<br>  36. Re: [all] [elections] Technical Committee Election Results<br>      (Ildiko Vancsa)<br>  37. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API<br>      removal (Morgan Fainberg)<br>  38. Re: [all] [elections] Technical Committee Election Results<br>      (Tony Breeds)<br>  39. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API<br>      removal (Morgan Fainberg)<br>  40. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API<br>      removal (Fox, Kevin M)<br>  41. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API<br>      removal (Cody A.W. Somerville)<br>  42. Re: [TripleO][Kolla] Concerns about containers images in<br>      DockerHub (Michał Jastrzębski)<br>  43. Re: [tc][election] Question for candidates: How do you think<br>      we can make our community more inclusive? (Diana Clarke)<br>  44. OpenStack Bug Smash for Queens (Fred Li)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Fri, 20 Oct 2017 14:18:29 +0200<br>From: Arnaud MORIN <arnaud.morin@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [puppet] avoid rechecks<br>Message-ID:<br>    <CALn_SgZU7r2=v+f44hykSySiuDYGHf55S_g-0W+e54t69wWOxA@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi Mohammed and all,<br><br>Can we help with the puppet CI?<br><br>Cheers,<br>Arnaud.<br><br>On 1 October 2017 at 17:27, Mohammed Naser <mnaser@vexxhost.com> wrote:<br><br>> Hi everyone,<br>><br>> As the Puppet modules CI is still in the process of getting plumbed<br>> properly with Zuul v3, you'll notice many of your checks failing.  If<br>> you notice a job that has a legacy- prefix, it is probably not<br>> migrated yet and will likely fail, therefore, I'd avoid a recheck to<br>> avoid taking up resources for a job that will fail.<br>><br>> If none of your jobs are prefixed with legacy- then you can do the<br>> normal troubleshooting and recheck if it is a timeout of the job or a<br>> connectivity issue.<br>><br>> I'll keep everyone updated at the progress of moving things over.<br>><br>> Thanks,<br>> Mohammed<br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/64bc2562/attachment-0001.html><br><br>------------------------------<br><br>Message: 2<br>Date: Fri, 20 Oct 2017 13:32:45 +0100 (BST)<br>From: Chris Dent <cdent+os@anticdent.org><br>To: OpenStack-dev@lists.openstack.org<br>Subject: [openstack-dev] [nova] [placement] resource providers update<br>    39<br>Message-ID: <alpine.OSX.2.21.1710201332190.93119@cdent-m01.vmware.com><br>Content-Type: text/plain; charset="utf-8"; Format="flowed"<br><br><br>This is update 39 for resource providers and placement.<br><br># Most Important<br><br>This week we had spec freeze, so now it is time to get rolling with<br>the making and the doing. Most of the specs that are related to<br>placement already had code in progress, so there's lots of stuff ready<br>to review. Given the volume of stuff in flight, the usual extras we'll<br>discover along the way, and the headspace we need to reserve for<br>thinking and experimenting about the future, we've got plenty going.<br><br># What's Changed<br><br>Forward progress mostly. Engaging Neutron using placement, at the<br>intersection of Nova and Neutron, as represented by specs like<br><br>     https://review.openstack.org/#/c/502306/<br><br>has been put off to later as it has too many dependencies on stuff<br>that is currently under development and not yet done.<br><br>The Granular Resource Request Syntax spec merged, which lays the<br>groundwork for nested resource providers and traits can work.<br><br>efried has created a functional test that exercises two bugs he<br>figured out with "alloc candidates with same RC in cn & shared"<br><br>     https://review.openstack.org/#/c/513149/<br><br>This is interesting because it requires us to make some decisions<br>and clear statements about what is supposed to be happening, not just<br>fix a bug.<br><br># Main Themes<br><br>## Nested Resource Providers<br><br>Progress is happening on nested providers:<br><br>     https://review.openstack.org/#/q/topic:bp/nested-resource-providers<br><br>It was injected into the middle of the de-orm stack, so while much of<br>that work has merged, there are some tail ends:<br><br>     https://review.openstack.org/#/q/topic:bp/de-orm-resource-providers<br><br>And the work to make traits work is relevant here, because with traits<br>nested aren't near as useful:<br><br>     https://review.openstack.org/#/q/bp/add-trait-support-in-allocation-candidates<br><br>## Migration allocations<br><br>The migration allocations work is nearly complete at:<br><br>     https://review.openstack.org/#/q/topic:bp/migration-allocations<br><br>Management of those allocations currently involves some raciness,<br>birthing the idea to allow POST /allocations, which causes a cascade<br>of required changes to bring that about. The code stack for that<br>starts at:<br><br>     https://review.openstack.org/#/c/500410/<br><br>## Alternate Hosts<br><br>We want to be able to do retries within cells, so we need some<br>alternate hosts when returning a destination that are structured<br>nicely for RPC:<br><br>     https://review.openstack.org/#/q/topic:bp/return-alternate-hosts<br><br># Other<br><br>* https://review.openstack.org/#/c/513001/<br>   Only add CUSTOM_ prefix if required<br><br>* https://review.openstack.org/#/c/508555/<br>   Re-use existing ComputeNode on ironic rebalance<br><br>* https://review.openstack.org/#/c/512553/<br>   Reproduce bug 1724172 in the functional test env<br>   (this is an allocations related bug)<br><br>* https://review.openstack.org/#/c/493865/<br>   cover migration cases with functional tests<br><br>* https://review.openstack.org/#/c/513041/<br>   Extract instance allocation removal code<br><br>* https://review.openstack.org/#/c/495159/<br>   Test resource allocation during soft delete<br><br>* https://review.openstack.org/#/c/499539/<br>   Moving more utils to ServerResourceAllocationTestBase<br><br>* https://review.openstack.org/#/c/503037/<br>   factor out compute service start in ServerMovingTest<br><br>* https://review.openstack.org/#/c/505202/<br>   Change live_migrate tests to use fakedriver<br><br>* https://review.openstack.org/#/c/497399/<br>   Extend ServerMovingTests with custom resources<br><br>* https://review.openstack.org/#/q/topic:bug/1702420<br>    Fixes for shared providers map being incorrect<br><br>* https://review.openstack.org/#/c/499826/<br>    Include /resource_providers/uuid/allocations link<br>    (Matt has declared this needs a microversion)<br><br>* https://review.openstack.org/#/c/492247/<br>    Use ksa adapter for placement conf & requests<br><br>* https://review.openstack.org/#/q/topic:bp/placement-osc-plugin<br>    Placement plugin for osc<br><br>* https://review.openstack.org/#/c/492571/<br>    Make compute log less verbose with allocs autocorrection<br><br>* https://review.openstack.org/#/c/499539/<br>    Stack of functional test fixups<br><br>* https://review.openstack.org/#/c/495380/<br>    [placement] manage cache headers for /resource_providers<br><br>* https://review.openstack.org/#/c/511488/<br>    [placement] Confirm that empty resources query causes 400<br><br>* https://review.openstack.org/#/c/511485/<br>    [placement] add coverage for update of standard resource class<br><br>* https://review.openstack.org/#/q/topic:bp/allocation-candidates-limit<br>   Enable limiting GET /allocation_candidates<br><br>* https://review.openstack.org/#/c/513057/<br>   [placement] Clean up TODOs in allocations.yaml gabbit<br><br>* https://review.openstack.org/#/q/topic:bug/1578989<br>   move placement client in neutron to neutron-lib and add<br>   functionality<br><br>* https://review.openstack.org/#/c/494206/<br>   Remove the Pike migration code for [Ironic] flavor migration<br><br>* https://review.openstack.org/#/c/511342/<br>   placement: add API reference for create inventory<br><br># End<br><br>You only get a prize if you review all the things linked here. If you<br>do then your prize is a massive sense of accomplishment and<br>contribution.<br><br>-- <br>Chris Dent                      (⊙_⊙')         https://anticdent.org/<br>freenode: cdent                                         tw: @anticdent<br><br>------------------------------<br><br>Message: 3<br>Date: Fri, 20 Oct 2017 12:46:27 +0000<br>From: Jeremy Stanley <fungi@yuggoth.org><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [keystone][all][tc] v2.0 API removal<br>Message-ID: <20171020124626.GB28203@yuggoth.org><br>Content-Type: text/plain; charset="utf-8"<br><br>On 2017-10-20 10:52:36 +0800 (+0800), Yaguang Tang wrote:<br>> Keystone is one project that all other OpenStack projects use, so<br>> personally I think the change to remove the API which are widely<br>> used should be discussed at TC meeting .<br>[...]<br><br>The OpenStack Technical Committee ceased holding regular weekly<br>meetings around 6 months ago:<br><br>https://governance.openstack.org/tc/resolutions/20170425-drop-tc-weekly-meetings.html<br><br>Also, the TC is not generally in the business of making decisions on<br>behalf of projects and instead provides opt-in policy in the form of<br>"tags" which projects can choose to apply to their teams or<br>deliverables, such as:<br><br>https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html<br><br>As you can see, the Keystone team asserts the keystone API service<br>follows the deprecation model indicated there. Are you suggesting<br>that policy was not followed, or that it's merely insufficient?<br>-- <br>Jeremy Stanley<br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: signature.asc<br>Type: application/pgp-signature<br>Size: 949 bytes<br>Desc: Digital signature<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/71fbc8ae/attachment-0001.sig><br><br>------------------------------<br><br>Message: 4<br>Date: Fri, 20 Oct 2017 15:08:33 +0200<br>From: Bernard Cafarelli <bcafarel@redhat.com><br>To: OpenStack Development Mailing List<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [neutron] [stadium] Tempest plugin split goal<br>    for stadium projects<br>Message-ID:<br>    <CABHdKwqBUKosWp97r9zFMNqgCdcjMd5TP9UTda_o=L39S3tzzg@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>Hi neutrinos,<br><br>to follow up on the community goal efffort to split tempest plugins in<br>separate repos [1], I started the work for networking-sfc [2], aiming<br>for a new "networking-sfc-tempest-plugin" repository.<br><br>Armando had an interesting question that I am bringing to the wider<br>audience: for stadium projects, should we create one tempest repo per<br>project, or host all stadium tempest related tests in a single neutron<br>repo [3]?<br><br>In similar cases, we already currently have "common code" repos:<br>neutron-lib for API, and python-neutronclient for OSC code.<br><br>So what do you think?<br><br><br>[1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123268.html<br>[2] https://review.openstack.org/#/c/510553/<br>[3] https://git.openstack.org/cgit/openstack/neutron-tempest-plugin<br><br>-- <br>Bernard Cafarelli<br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Fri, 20 Oct 2017 22:10:00 +0900<br>From: Takashi Yamamoto <yamamoto@midokura.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [neutron][vpnaas] core reviewer proposal<br>Message-ID:<br>    <CAH=wFzRt7=29ttr9tgi_pLe0L5AZwD+xaGLpeSxL7svRkaYDbQ@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>Hi,<br><br>Unless anyone objects, i'll add the following people to neutron-vpnaas<br>core reviewers. [1]<br><br>- Cao Xuan Hoang <hoangcx@vn.fujitsu.com><br>- Akihiro Motoki <amotoki@gmail.com><br>- Miguel Lavalle <miguel@mlavalle.com><br><br>Hoang is the most active contributor for the project these days.<br><br>I don't bother to introduce Akihiro and Miguel as i guess everyone here<br>knows them. :-)<br><br>[1] https://review.openstack.org/#/admin/groups/502,members<br><br><br><br>------------------------------<br><br>Message: 6<br>Date: Fri, 20 Oct 2017 22:10:51 +0900<br>From: Takashi Yamamoto <yamamoto@midokura.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [neutron][networking-midonet] Core reviewers<br>    change    proposal<br>Message-ID:<br>    <CAH=wFzSOc_ijk5xQUyMHEHn0=KotY2WOBaJ-dnHCw3eRKo8D1A@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>Hi,<br><br>Unless anyone objects, I'll remove the following people from the list<br>of networking-midonet core reviewers.<br><br>- Joe Mills<br>- Michael Micucci<br><br>They made great contributions in the past (thank you!) but have not<br>reviewed any patches in the last 6 months. [2]<br><br>[1] https://review.openstack.org/#/admin/groups/607,members<br>[2] http://stackalytics.com/report/contribution/networking-midonet/180<br><br><br><br>------------------------------<br><br>Message: 7<br>Date: Fri, 20 Oct 2017 10:23:51 -0400<br>From: Doug Hellmann <doug@doughellmann.com><br>To: openstack-dev <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] Fwd: [Distutils][pbr] Announcement: Pip 10 is<br>    coming, and will move all internal APIs<br>Message-ID: <1508509327-sup-2738@lrrr.local><br>Content-Type: text/plain; charset=UTF-8<br><br>It sounds like the PyPI/PyPA folks are planning some major changes to<br>pip internals, soon.<br><br>I know pbr uses setuptools, and I don't think it uses pip, but if<br>someone has time to verify that it would be helpful.<br><br>We'll also want to watch out for breakage in normal use of pip 10. If<br>they're making changes this big, they may miss something in their own<br>test coverage that affects our jobs.<br><br>--- Begin forwarded message from Paul Moore ---<br>From: Paul Moore <p.f.moore@gmail.com><br>To: Distutils <distutils-sig@python.org>, pypa-dev <pypa-dev@googlegroups.com><br>Date: Fri, 20 Oct 2017 14:22:03 +0100<br>Subject: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs<br><br>We're in the process of starting to plan for a release of pip (the<br>long-awaited pip 10). We're likely still a month or two away from a<br>release, but now is the time for people to start ensuring that<br>everything works for them. One key change in the new version will be<br>that all of the internal APIs of pip will no longer be available, so<br>any code that currently calls functions in the "pip" namespace will<br>break. Calling pip's internal APIs has never been supported, and<br>always carried a risk of such breakage, so projects doing so should,<br>in theory, be prepared for such things. However, reality is not always<br>that simple, and we are aware that people will need time to deal with<br>the implications.<br><br>Just in case it's not clear, simply finding where the internal APIs<br>have moved to and calling them under the new names is *not* what<br>people should do. We can't stop people calling the internal APIs,<br>obviously, but the idea of this change is to give people the incentive<br>to find a supported approach, not just to annoy people who are doing<br>things we don't want them to ;-)<br><br>So please - if you're calling pip's internals in your code, take the<br>opportunity *now* to check out the in-development version of pip, and<br>ensure your project will still work when pip 10 is released.<br><br>And many thanks to anyone else who helps by testing out the new<br>version, as well :-)<br><br>Thanks,<br>Paul<br>--- End forwarded message ---<br><br><br><br>------------------------------<br><br>Message: 8<br>Date: Fri, 20 Oct 2017 16:41:53 +0200<br>From: Thierry Carrez <thierry@openstack.org><br>To: OpenStack Development Mailing List<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [tc] Technical Committee Status update,<br>    October 20th<br>Message-ID: <555a45b2-8e75-8ef8-04c7-f7532796fc9b@openstack.org><br>Content-Type: text/plain; charset=utf-8<br><br>Hi!<br><br>This is the weekly summary of Technical Committee initiatives. You can<br>find the full list of all open topics (updated twice a week) at:<br><br>https://wiki.openstack.org/wiki/Technical_Committee_Tracker<br><br>If you are working on something (or plan to work on something) that is<br>not on the tracker, feel free to add to it !<br><br><br>== TC Election still in progress ==<br><br>A few hours left to vote!<br>Note that your ballot email might have been classified as spam.<br><br><br>== Recently-approved changes ==<br><br>* New project team: OpenStack-Helm (helm charts for OpenStack) [1]<br>* Remove tox from PTI for python tarballs [2]<br>* Goal updates: kolla, ironic<br>* Retired repos: pylockfile<br>* New repos: contributor-guide, heat-dashboard, senlin-tempest-plugin<br><br>[1] https://review.openstack.org/#/c/500118/<br>[2] https://review.openstack.org/#/c/508693/<br><br>The most significant change this week is the officialization of the<br>"OpenStack-Helm" project team, a packaging team working on producing<br>Helm charts to deploy OpenStack using helm. This likely closes the list<br>of OpenStack project teams for the Queens cycle. The Glare team<br>application, in particular, was deferred to Rocky by its PTL.<br><br><br>== Under review ==<br><br>Our latest top-5 "help wanted" list proposed addition, "champions<br>and stewards" is still pretty much under review:<br><br>https://review.openstack.org/#/c/510656/<br><br><br>Monty's series of modifications to the PTI (project testing<br>interface) still had two open changes. Please review at:<br><br>* https://review.openstack.org/#/c/508694/<br>* https://review.openstack.org/#/c/509868/<br><br><br>== TC member actions for the coming week(s) ==<br><br>Monty should answer the feedback on the supported database version<br>resolution (https://review.openstack.org/493932) so that we can make<br>progress there -- or abandon it.<br><br><br>== Office hours ==<br><br>To be more inclusive of all timezones and more mindful of people for<br>which English is not the primary language, the Technical Committee<br>dropped its dependency on weekly meetings. So that you can still get<br>hold of TC members on IRC, we instituted a series of office hours on<br>#openstack-tc:<br><br>* 09:00 UTC on Tuesdays<br>* 01:00 UTC on Wednesdays<br>* 15:00 UTC on Thursdays<br><br>For the coming week, I expect the main topic of discussion to be the<br>onboarding of the newly-elected membership, as well as Summit preparations.<br><br>Cheers,<br><br>-- <br>Thierry Carrez (ttx)<br><br><br><br>------------------------------<br><br>Message: 9<br>Date: Fri, 20 Oct 2017 09:46:12 -0500<br>From: Lance Bragstad <lbragstad@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [policy] AWS IAM session<br>Message-ID: <64d8d01e-b544-3b8e-d30e-c110eb7a7866@gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>I just sent a calendar invite to everyone who responded to this thread<br>or voted in the agenda. The session will be recorded if you are unable<br>to make it.<br><br>Thanks!<br><br>On 10/18/2017 10:10 AM, Lance Bragstad wrote:<br>> Now that we have some good feedback on the doodle, it looks like we<br>> have two sessions that will work for everyone. One is October 25th<br>> from 15:00 - 16:00 UTC and the other is also the 25th from 16:00 - 17:00.<br>><br>> Let's shoot to meet at *15:00 UTC* on *October 25th* and if the<br>> meeting goes over, we have time allocated for that. Would anyone like<br>> a formal calendar invite? If so, I can send one out. The etherpad [0]<br>> will act as our "schedule", but we'll likely just work through the<br>> cases we've documented.<br>><br>> Thanks!<br>><br>> [0] https://etherpad.openstack.org/p/analyzing-other-policy-systems<br>><br>><br>> On 10/16/2017 08:45 AM, Lance Bragstad wrote:<br>>> Sending out a gentle reminder to vote for time slots that work for<br>>> you [0]. We'll keep the poll open for a few more days, or until we<br>>> reach quorum. Thanks!<br>>><br>>> [0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu<br>>><br>>> On 10/11/2017 01:48 PM, Lance Bragstad wrote:<br>>>> Oh - one note about the doodle [0]. All proposed times are in UTC,<br>>>> so just keep that in mind when selecting your availability.<br>>>><br>>>> Thanks!<br>>>><br>>>> [0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu<br>>>><br>>>> On 10/11/2017 01:44 PM, Lance Bragstad wrote:<br>>>>> In today's policy meeting we went through and started prepping for<br>>>>> the session. Relevant information has been captured in the etherpad<br>>>>> [0].<br>>>>><br>>>>> We're going to hold the meeting using *Google* *Hangouts*. I'll<br>>>>> update the etherpad with a link to the hangout once we settle on a<br>>>>> date. If you plan on attending, please *vote* *for* *available*<br>>>>> *times* [1]. I've proposed a bunch of time slots (4 each day for<br>>>>> the next two weeks) to try and find a time that works for everyone.<br>>>>> People from US, AU, and EU will be trying to attended, so we're not<br>>>>> going to find a perfect time for everyone. Having said that, *we're<br>>>>> going to record the session*.<br>>>>><br>>>>> Most of what we talked about in the meeting today uncovered the<br>>>>> need to go over the basics of AWS IAM. That should be something we<br>>>>> can do with a free account, which I'm going to sign up for. If we<br>>>>> need more time we can have another session or look at options for<br>>>>> upgrading the account.<br>>>>><br>>>>><br>>>>> [0] https://etherpad.openstack.org/p/analyzing-other-policy-systems<br>>>>> [1] https://doodle.com/poll/ntkpzgmcv3k6v5qu<br>>>>><br>>>>> On 10/09/2017 04:23 PM, Lance Bragstad wrote:<br>>>>>> I've put a scheduling session on the books for the next policy<br>>>>>> meeting [0][1]. Advertising it here since folks who want to be<br>>>>>> involved have responded to the thread.<br>>>>>><br>>>>>> Let's use this meeting time to iron out account details and figure<br>>>>>> out what exactly we want to get out of the session.<br>>>>>><br>>>>>><br>>>>>> [0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting<br>>>>>> [1] https://etherpad.openstack.org/p/keystone-policy-meeting<br>>>>>><br>>>>>> On 10/05/2017 02:24 AM, Colleen Murphy wrote:<br>>>>>>> On Tue, Oct 3, 2017 at 10:08 PM, Lance Bragstad<br>>>>>>> <lbragstad@gmail.com <mailto:lbragstad@gmail.com>> wrote:<br>>>>>>><br>>>>>>>     Hey all,<br>>>>>>><br>>>>>>>     It was mentioned in today's keystone meeting [0] that it<br>>>>>>>     would be useful<br>>>>>>>     to go through AWS IAM (or even GKE) as a group. With all the<br>>>>>>>     recent<br>>>>>>>     policy discussions and work, it seems useful to get our eyes<br>>>>>>>     on another<br>>>>>>>     system. The idea would be to spend time using a video<br>>>>>>>     conference/screen<br>>>>>>>     share to go through and play with policy together. The end<br>>>>>>>     result should<br>>>>>>>     keep us focused on the implementations we're working on<br>>>>>>>     today, but also<br>>>>>>>     provide clarity for the long-term vision of OpenStack's RBAC<br>>>>>>>     system.<br>>>>>>><br>>>>>>>     Are you interested in attending? If so, please respond to the<br>>>>>>>     thread.<br>>>>>>>     Once we have some interest, we can gauge when to hold the<br>>>>>>>     meeting, which<br>>>>>>>     tools we can use, and setting up a test IAM account.<br>>>>>>><br>>>>>>>     Thanks,<br>>>>>>><br>>>>>>>     Lance<br>>>>>>><br>>>>>>>     [0]<br>>>>>>>     http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119<br>>>>>>>     <http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119><br>>>>>>><br>>>>>>> Please count me in.<br>>>>>>><br>>>>>>> Colleen<br>>>>>>><br>>>>>>><br>>>>>>> __________________________________________________________________________<br>>>>>>> OpenStack Development Mailing List (not for usage questions)<br>>>>>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>>>>>><br>>>>><br>>>><br>>><br>><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/9cb6c0dd/attachment-0001.html><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: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/9cb6c0dd/attachment-0001.sig><br><br>------------------------------<br><br>Message: 10<br>Date: Fri, 20 Oct 2017 11:27:24 -0400<br>From: Mohammed Naser <mnaser@vexxhost.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [puppet] avoid rechecks<br>Message-ID:<br>    <CAEs876gq2PRS+Xkc=x1MUK79g8XJTzE8CW3bWKQx2LGEop2zbw@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi Arnaud,<br><br>Apologies for not following up with that email, things should be okay now<br>and we've mostly patched up our CI for Zuul v3 :)<br><br>Thanks,<br>Mohammed<br><br>On Fri, Oct 20, 2017 at 8:18 AM, Arnaud MORIN <arnaud.morin@gmail.com><br>wrote:<br><br>> Hi Mohammed and all,<br>><br>> Can we help with the puppet CI?<br>><br>> Cheers,<br>> Arnaud.<br>><br>> On 1 October 2017 at 17:27, Mohammed Naser <mnaser@vexxhost.com> wrote:<br>><br>>> Hi everyone,<br>>><br>>> As the Puppet modules CI is still in the process of getting plumbed<br>>> properly with Zuul v3, you'll notice many of your checks failing.  If<br>>> you notice a job that has a legacy- prefix, it is probably not<br>>> migrated yet and will likely fail, therefore, I'd avoid a recheck to<br>>> avoid taking up resources for a job that will fail.<br>>><br>>> If none of your jobs are prefixed with legacy- then you can do the<br>>> normal troubleshooting and recheck if it is a timeout of the job or a<br>>> connectivity issue.<br>>><br>>> I'll keep everyone updated at the progress of moving things over.<br>>><br>>> Thanks,<br>>> Mohammed<br>>><br>>> ____________________________________________________________<br>>> ______________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscrib<br>>> e<br>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>>><br>><br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>><br>><br><br><br>-- <br>Mohammed Naser — vexxhost<br>-----------------------------------------------------<br>D. 514-316-8872<br>D. 800-910-1726 ext. 200<br>E. mnaser@vexxhost.com<br>W. http://vexxhost.com<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/0af138b0/attachment-0001.html><br><br>------------------------------<br><br>Message: 11<br>Date: Fri, 20 Oct 2017 11:02:21 -0500<br>From: Matt Riedemann <mriedemos@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] Do you hate the new gerrit thing where the<br>    cursor    jumps all over?<br>Message-ID: <db23b0e9-68d4-cf00-e6b7-851af89c6269@gmail.com><br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br>When you're lower in a change trying to expand comments and it always <br>jumps you back up to the top?<br><br>Since not everyone might know about the solution, it's:<br><br>1. Go into settings<br>2. Diff Preference<br>3. Change "Render" from Fast to Slow.<br>4. Save<br><br>Get back to reviewing stuff without losing your mind.<br><br>-- <br><br>Thanks,<br><br>Matt<br><br><br><br>------------------------------<br><br>Message: 12<br>Date: Fri, 20 Oct 2017 18:12:03 +0200<br>From: Petr Kovar <pkovar@redhat.com><br>To: openstack-docs@lists.openstack.org,<br>    openstack-dev@lists.openstack.org<br>Subject: Re: [openstack-dev] [OpenStack-docs] [docs] Documentation<br>    meeting    Thursday<br>Message-ID: <20171020181203.abe35f94e6e9f131eaf11a16@redhat.com><br>Content-Type: text/plain; charset=US-ASCII<br><br>Below are the meeting minutes from yesterday's docs team meeting.<br><br>Because we ran out of time (too many items to cover!), the conversation<br>about site map automation continued in #openstack-doc after the meeting:<br><br>http://eavesdrop.openstack.org/irclogs/%23openstack-doc/%23openstack-doc.2017-10-19.log.html<br><br>===========================<br>#openstack-meeting: docteam<br>===========================<br><br><br>Meeting started by pkovar at 16:01:09 UTC.  The full logs are available<br>at<br>http://eavesdrop.openstack.org/meetings/docteam/2017/docteam.2017-10-19-16.01.log.html<br>.<br><br><br><br>Meeting summary<br>---------------<br><br>* Docs meeting time?  (pkovar, 16:06:12)<br>  * ACTION: pkovar to initiate a mtg time poll  (pkovar, 16:16:13)<br>  * reconsider removing the docs ML  (pkovar, 16:23:05)<br>  * decisions to be made in ML (-dev, preferably)  (pkovar, 16:23:42)<br>  * consider sending status updates  (pkovar, 16:24:39)<br><br>* Docs team vision document  (pkovar, 16:26:24)<br>  * LINK:<br>    https://etherpad.openstack.org/p/docs-i18n-ptg-queens-mission-statement<br>    (pkovar, 16:26:34)<br>  * LINK: https://docs.openstack.org/doc-contrib-guide/  (pkovar,<br>    16:27:58)<br>  * ACTION: pkovar to add the vision doc to doc contrib guide  (pkovar,<br>    16:30:50)<br><br>* Docs retention policy changes  (pkovar, 16:31:29)<br>  * LINK: https://review.openstack.org/#/c/507629  (pkovar, 16:31:47)<br>  * LINK: https://review.openstack.org/#/c/491868/ to derive series name<br>    by the theme  (pkovar, 16:36:38)<br>  * coordinate with tonyb and the stable team to avoid closing stable<br>    branches before adding badges to docs  (pkovar, 16:39:37)<br>  * LINK:<br>    https://etherpad.openstack.org/p/docs-i18n-ptg-queens-release-badges<br>    (jamesmcarthur, 16:40:20)<br>  * LINK:<br>    https://etherpad.openstack.org/p/docs-i18n-ptg-queens-release-badges<br>    (pkovar, 16:40:43)<br><br>* Contributor Portal  (pkovar, 16:43:46)<br>  * LINK:<br>    http://lists.openstack.org/pipermail/openstack-dev/2017-October/123740.html<br>    (pkovar, 16:44:03)<br>  * LINK: https://www.openstack.org/community/  (pkovar, 16:44:50)<br>  * LINK: https://docs.openstack.org/contributors  (pkovar, 16:45:01)<br>  * LINK: https://docs.openstack.org/doc-contrib-guide/  (pkovar,<br>    16:45:13)<br><br>* sitemap automation suggestions  (pkovar, 16:47:39)<br>  * LINK:<br>    http://lists.openstack.org/pipermail/openstack-dev/2017-October/123228.html<br>    (pkovar, 16:47:48)<br>  * ACTION: mguiney volunteered to help with sitemap automation, thanks<br>    (pkovar, 16:57:35)<br><br><br><br>Meeting ended at 17:00:10 UTC.<br><br><br><br>Action items, by person<br>-----------------------<br><br>* mguiney<br>  * mguiney volunteered to help with sitemap automation, thanks<br>* pkovar<br>  * pkovar to initiate a mtg time poll<br>  * pkovar to add the vision doc to doc contrib guide<br><br><br><br>People present (lines said)<br>---------------------------<br><br>* pkovar (93)<br>* dhellmann (58)<br>* jamesmcarthur (32)<br>* eumel8 (8)<br>* mguiney (8)<br>* bsilverman (7)<br>* openstack (4)<br>* thingee (1)<br><br><br><br>Generated by `MeetBot`_ 0.1.4<br><br><br><br>------------------------------<br><br>Message: 13<br>Date: Fri, 20 Oct 2017 18:33:46 +0200<br>From: Petr Kovar <pkovar@redhat.com><br>To: openstack-docs@lists.openstack.org<br>Cc: , openstack-dev@lists.openstack.org<br>Subject: [openstack-dev] [docs] Docs meeting time? (was: Documentation<br>    meeting Thursday)<br>Message-ID: <20171020183346.16e966ef88621ed2e83dff86@redhat.com><br>Content-Type: text/plain; charset=UTF-8<br><br>Chason, <br><br>Thanks for bringing this up. I definitely don't want contributors from Asia<br>to feel excluded. We discussed it in the docs meeting yesterday and it's<br>clear that finding a meeting time that would work for Asia, Europe and<br>America is a bit difficult, to say the least. <br><br>Anyhow, I went ahead and I set up a poll to better understand what are<br>people's preferences wrt meeting time:<br><br>http://whenisgood.net/qtqbz52<br><br>All, if you could indicate your time preference, that would be appreciated.<br><br>Results will appear here:<br><br>http://whenisgood.net/qtqbz52/results/ptgfrap<br><br>Thanks,<br>pk<br><br><br>On Thu, 19 Oct 2017 20:47:12 +0800<br>Chason <chason.chan@foxmail.com> wrote:<br><br>> Hi Petr,<br>> <br>> Is there any chance the meeting could be moved earlier one so Asian can make it?<br>> Thursday at 16:00 UTC is Friday at 1:00 here.<br>> <br>> Thanks,<br>> <br>> Chason<br>> <br>> > 在 2017年10月19日,下午8:00,openstack-docs-request@lists.openstack.org 写道:<br>> > <br>> > Send OpenStack-docs mailing list submissions to<br>> >     openstack-docs@lists.openstack.org<br>> > <br>> > To subscribe or unsubscribe via the World Wide Web, visit<br>> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs<br>> > or, via email, send a message with subject or body 'help' to<br>> >     openstack-docs-request@lists.openstack.org<br>> > <br>> > You can reach the person managing the list at<br>> >     openstack-docs-owner@lists.openstack.org<br>> > <br>> > When replying, please edit your Subject line so it is more specific<br>> > than "Re: Contents of OpenStack-docs digest..."<br>> > <br>> > <br>> > Today's Topics:<br>> > <br>> >   1. [docs] Documentation meeting Thursday (Petr Kovar)<br>> > <br>> > <br>> > ----------------------------------------------------------------------<br>> > <br>> > Message: 1<br>> > Date: Wed, 18 Oct 2017 15:07:39 +0200<br>> > From: Petr Kovar <pkovar@redhat.com><br>> > To: openstack-docs@lists.openstack.org<br>> > Cc: openstack-dev@lists.openstack.org<br>> > Subject: [OpenStack-docs] [docs] Documentation meeting Thursday<br>> > Message-ID: <20171018150739.28a243fd1691f243c3002da1@redhat.com><br>> > Content-Type: text/plain; charset=US-ASCII<br>> > <br>> > Hi all,<br>> > <br>> > The docs meeting will continue tomorrow, Thursday at 16:00 UTC in<br>> > #openstack-meeting, as scheduled. For more details, and the agenda, see the meeting page:<br>> > <br>> > https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting<br>> > <br>> > Cheers,<br>> > pk<br>> > <br>> > <br>> > <br>> > ------------------------------<br>> > <br>> > Subject: Digest Footer<br>> > <br>> > _______________________________________________<br>> > OpenStack-docs mailing list<br>> > OpenStack-docs@lists.openstack.org<br>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs<br>> > <br>> > <br>> > ------------------------------<br>> > <br>> > End of OpenStack-docs Digest, Vol 64, Issue 9<br>> > *********************************************<br>> <br>> <br>> <br>> <br>> _______________________________________________<br>> OpenStack-docs mailing list<br>> OpenStack-docs@lists.openstack.org<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs<br><br><br><br>------------------------------<br><br>Message: 14<br>Date: Sat, 21 Oct 2017 00:39:41 +0800<br>From: Yaguang Tang <heut2008@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [keystone][all][tc] v2.0 API removal<br>Message-ID:<br>    <CAPP2CaUj9GgjweB02W5qQbWD+jX=2cjSoNEqFpqXMzfv3VdWBg@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>I am not saying keystone team don't follow the policy. Just want to express<br>my concern for this big action. it's a cross project thing, so want to have<br>a widely agreement. from the user's aspect, I want to ask the keystone team<br>to keep the V2 API for a long time if we don't have<br>to spend to much effort to maintain it.<br><br>On Fri, Oct 20, 2017 at 8:46 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:<br><br>> On 2017-10-20 10:52:36 +0800 (+0800), Yaguang Tang wrote:<br>> > Keystone is one project that all other OpenStack projects use, so<br>> > personally I think the change to remove the API which are widely<br>> > used should be discussed at TC meeting .<br>> [...]<br>><br>> The OpenStack Technical Committee ceased holding regular weekly<br>> meetings around 6 months ago:<br>><br>> https://governance.openstack.org/tc/resolutions/20170425-<br>> drop-tc-weekly-meetings.html<br>><br>> Also, the TC is not generally in the business of making decisions on<br>> behalf of projects and instead provides opt-in policy in the form of<br>> "tags" which projects can choose to apply to their teams or<br>> deliverables, such as:<br>><br>> https://governance.openstack.org/tc/reference/tags/assert_<br>> follows-standard-deprecation.html<br>><br>> As you can see, the Keystone team asserts the keystone API service<br>> follows the deprecation model indicated there. Are you suggesting<br>> that policy was not followed, or that it's merely insufficient?<br>> --<br>> Jeremy Stanley<br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>><br>><br><br><br>-- <br>Tang Yaguang<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171021/1a9c7989/attachment-0001.html><br><br>------------------------------<br><br>Message: 15<br>Date: Fri, 20 Oct 2017 16:54:31 +0000<br>From: Chan Chason <chenxingcampus@outlook.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [docs] Docs meeting time? (was: Documentation<br>    meeting Thursday)<br>Message-ID:<br>    <PS1PR0601MB20127D3E2F8C59E0EC6F4E15DD430@PS1PR0601MB2012.apcprd06.prod.outlook.com><br>    <br>Content-Type: text/plain; charset="gb2312"<br><br>Great! I have indicated my time preference and hopefully we can get a time for all of us. :P<br><br>Thanks,<br><br>Chason<br><br>> 在 2017年10月21日,上午12:33,Petr Kovar <pkovar@redhat.com> 写道:<br>> <br>> Chason, <br>> <br>> Thanks for bringing this up. I definitely don't want contributors from Asia<br>> to feel excluded. We discussed it in the docs meeting yesterday and it's<br>> clear that finding a meeting time that would work for Asia, Europe and<br>> America is a bit difficult, to say the least. <br>> <br>> Anyhow, I went ahead and I set up a poll to better understand what are<br>> people's preferences wrt meeting time:<br>> <br>> http://whenisgood.net/qtqbz52<br>> <br>> All, if you could indicate your time preference, that would be appreciated.<br>> <br>> Results will appear here:<br>> <br>> http://whenisgood.net/qtqbz52/results/ptgfrap<br>> <br>> Thanks,<br>> pk<br>> <br>> <br>> On Thu, 19 Oct 2017 20:47:12 +0800<br>> Chason <chason.chan@foxmail.com> wrote:<br>> <br>>> Hi Petr,<br>>> <br>>> Is there any chance the meeting could be moved earlier one so Asian can make it?<br>>> Thursday at 16:00 UTC is Friday at 1:00 here.<br>>> <br>>> Thanks,<br>>> <br>>> Chason<br>>> <br>>>> 在 2017年10月19日,下午8:00,openstack-docs-request@lists.openstack.org 写道:<br>>>> <br>>>> Send OpenStack-docs mailing list submissions to<br>>>>     openstack-docs@lists.openstack.org<br>>>> <br>>>> To subscribe or unsubscribe via the World Wide Web, visit<br>>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs<br>>>> or, via email, send a message with subject or body 'help' to<br>>>>     openstack-docs-request@lists.openstack.org<br>>>> <br>>>> You can reach the person managing the list at<br>>>>     openstack-docs-owner@lists.openstack.org<br>>>> <br>>>> When replying, please edit your Subject line so it is more specific<br>>>> than "Re: Contents of OpenStack-docs digest..."<br>>>> <br>>>> <br>>>> Today's Topics:<br>>>> <br>>>>  1. [docs] Documentation meeting Thursday (Petr Kovar)<br>>>> <br>>>> <br>>>> ----------------------------------------------------------------------<br>>>> <br>>>> Message: 1<br>>>> Date: Wed, 18 Oct 2017 15:07:39 +0200<br>>>> From: Petr Kovar <pkovar@redhat.com><br>>>> To: openstack-docs@lists.openstack.org<br>>>> Cc: openstack-dev@lists.openstack.org<br>>>> Subject: [OpenStack-docs] [docs] Documentation meeting Thursday<br>>>> Message-ID: <20171018150739.28a243fd1691f243c3002da1@redhat.com><br>>>> Content-Type: text/plain; charset=US-ASCII<br>>>> <br>>>> Hi all,<br>>>> <br>>>> The docs meeting will continue tomorrow, Thursday at 16:00 UTC in<br>>>> #openstack-meeting, as scheduled. For more details, and the agenda, see the meeting page:<br>>>> <br>>>> https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting<br>>>> <br>>>> Cheers,<br>>>> pk<br>>>> <br>>>> <br>>>> <br>>>> ------------------------------<br>>>> <br>>>> Subject: Digest Footer<br>>>> <br>>>> _______________________________________________<br>>>> OpenStack-docs mailing list<br>>>> OpenStack-docs@lists.openstack.org<br>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs<br>>>> <br>>>> <br>>>> ------------------------------<br>>>> <br>>>> End of OpenStack-docs Digest, Vol 64, Issue 9<br>>>> *********************************************<br>>> <br>>> <br>>> <br>>> <br>>> _______________________________________________<br>>> OpenStack-docs mailing list<br>>> OpenStack-docs@lists.openstack.org<br>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs<br>> <br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br>------------------------------<br><br>Message: 16<br>Date: Fri, 20 Oct 2017 17:15:59 +0000<br>From: "Fox, Kevin M" <Kevin.Fox@pnnl.gov><br>To: "heut2008@gmail.com" <heut2008@gmail.com>, "OpenStack Development<br>    Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]<br>    [keystone][all] v2.0    API removal<br>Message-ID:<br>    <1A3C52DFCD06494D8528644858247BF01C018E10@EX10MBOX03.pnnl.gov><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>That is a very interesting question.<br><br>It comes from the angle of OpenStack the product more then from the standpoint of any one OpenStack project.<br><br>I know the TC's been shying away from these sorts of questions, but this one has a pretty big impact. TC?<br><br>Thanks,<br>Kevin<br>________________________________<br>From: Yaguang Tang [heut2008@gmail.com]<br>Sent: Thursday, October 19, 2017 7:59 PM<br>To: OpenStack Development Mailing List<br>Subject: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal<br><br>Should this kind of change  be discussed and have an agreement of the TC and User committee?<br><br>---------- Forwarded message ----------<br>From: Lance Bragstad <lbragstad@gmail.com<mailto:lbragstad@gmail.com>><br>Date: Fri, Oct 20, 2017 at 12:08 AM<br>Subject: [Openstack-operators] [keystone][all] v2.0 API removal<br>To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>, openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org><br><br><br><br>Hey all,<br><br>Now that we're finishing up the last few bits of v2.0 removal, I'd like to send out a reminder that Queens will not include the v2.0 keystone APIs except the ec2-api. Authentication and validation of v2.0 tokens has been removed (in addition to the public and admin APIs) after a lengthy deprecation period.<br><br>Let us know if you have any questions.<br><br>Thanks!<br><br>_______________________________________________<br>OpenStack-operators mailing list<br>OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br><br><br><br>--<br>Tang Yaguang<br><br><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/d76022f6/attachment-0001.html><br><br>------------------------------<br><br>Message: 17<br>Date: Fri, 20 Oct 2017 13:16:24 -0400<br>From: Jeremy Freudberg <jeremyfreudberg@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Do you hate the new gerrit thing where<br>    the cursor jumps all over?<br>Message-ID:<br>    <CAFntmSjoGDQrD_eGngOsyYWJ5Su+Jw3Tc3gX2aRNoqx07ZJw2A@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>I don't wanna turn this into a complaint session about new Gerrit. But<br>three little notes since the upgrade:<br><br>- I can't push the "e" key to go into editing mode anymore<br>- Cherry-picks change the gerrit topic (that's probably a feature)<br>- The patch I'm already looking at shows up under "Same Topic" (that's<br>probably a feature)<br><br><br>The only one that really kills me is the first one. Anyone know if the<br>keyboard shortcut changed, or if it's disabled but configurable, etc...?<br><br>On Fri, Oct 20, 2017 at 12:02 PM, Matt Riedemann <mriedemos@gmail.com><br>wrote:<br><br>> When you're lower in a change trying to expand comments and it always<br>> jumps you back up to the top?<br>><br>> Since not everyone might know about the solution, it's:<br>><br>> 1. Go into settings<br>> 2. Diff Preference<br>> 3. Change "Render" from Fast to Slow.<br>> 4. Save<br>><br>> Get back to reviewing stuff without losing your mind.<br>><br>> --<br>><br>> Thanks,<br>><br>> Matt<br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/55dea26c/attachment-0001.html><br><br>------------------------------<br><br>Message: 18<br>Date: Fri, 20 Oct 2017 10:27:38 -0700<br>From: Clark Boylan <cboylan@sapwetik.org><br>To: openstack-dev@lists.openstack.org<br>Subject: Re: [openstack-dev] Do you hate the new gerrit thing where<br>    the cursor jumps all over?<br>Message-ID:<br>    <1508520458.2152876.1145647736.2707BF5D@webmail.messagingengine.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On Fri, Oct 20, 2017, at 10:16 AM, Jeremy Freudberg wrote:<br>> I don't wanna turn this into a complaint session about new Gerrit. But<br>> three little notes since the upgrade:<br>> <br>> - I can't push the "e" key to go into editing mode anymore<br>> - Cherry-picks change the gerrit topic (that's probably a feature)<br>> - The patch I'm already looking at shows up under "Same Topic" (that's<br>> probably a feature)<br>> <br>> <br>> The only one that really kills me is the first one. Anyone know if the<br>> keyboard shortcut changed, or if it's disabled but configurable, etc...?<br><br>The help overlay on the diff screen (brought up by hitting '?') says it<br>is now "<Ctrl> + <Alt> + e : Open Inline Editor".<br><br>This seems to work for me in firefox on linux.<br><br>Hope this helps,<br>Clark<br><br><br><br>------------------------------<br><br>Message: 19<br>Date: Fri, 20 Oct 2017 17:43:02 +0000<br>From: Jeremy Stanley <fungi@yuggoth.org><br>To: openstack-dev@lists.openstack.org<br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]<br>    [keystone][all] v2.0 API removal<br>Message-ID: <20171020174302.GC28203@yuggoth.org><br>Content-Type: text/plain; charset="utf-8"<br><br>On 2017-10-20 10:59:36 +0800 (+0800), Yaguang Tang wrote:<br>> Should this kind of change  be discussed and have an agreement of<br>> the TC and User committee?<br>[...]<br><br>Looks like this thread has split since bouncing back in from the<br>operators ML, but I replied in the "other" dev ML thread for this<br>topic already:<br><br>http://lists.openstack.org/pipermail/openstack-dev/2017-October/123813.html<br><br>Do you have any suggested guidelines for the scope or scale of<br>impact for some deprecations and removals which should be held to a<br>higher standard? Would you be willing to work with the TC to update<br>the existing deprecation tag (or come up with an additional one) to<br>covers this additional policy?<br>-- <br>Jeremy Stanley<br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: signature.asc<br>Type: application/pgp-signature<br>Size: 949 bytes<br>Desc: Digital signature<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/5699af7a/attachment-0001.sig><br><br>------------------------------<br><br>Message: 20<br>Date: Fri, 20 Oct 2017 17:53:47 +0000<br>From: Jeremy Stanley <fungi@yuggoth.org><br>To: openstack-dev@lists.openstack.org<br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]<br>    [keystone][all] v2.0    API removal<br>Message-ID: <20171020175347.GD28203@yuggoth.org><br>Content-Type: text/plain; charset="utf-8"<br><br>On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:<br>[...]<br>> I know the TC's been shying away from these sorts of questions,<br>> but this one has a pretty big impact. TC?<br>[...]<br><br>The OpenStack Technical Committee isn't really a bludgeon with which<br>to beat teams when someone in the community finds fault with a<br>decision; it drafts/revises policy and arbitrates disputes between<br>teams. What sort of action are you seeking in regard to the Keystone<br>team finally acting this cycle on removal of their long-deprecated<br>legacy API, and with what choices of theirs do you disagree?<br><br>Do you feel the deprecation was not communicated widely enough? Do<br>you feel that SDKs haven't been updated with sufficient support for<br>the v3 API? Are you concerned that lack of v2 API support will<br>prevent organizations running the upcoming Queens release from<br>qualifying for interoperability trademarks? Something else entirely?<br>-- <br>Jeremy Stanley<br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: signature.asc<br>Type: application/pgp-signature<br>Size: 949 bytes<br>Desc: Digital signature<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/8d224658/attachment-0001.sig><br><br>------------------------------<br><br>Message: 21<br>Date: Fri, 20 Oct 2017 14:08:26 -0400<br>From: Jeremy Freudberg <jeremyfreudberg@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Do you hate the new gerrit thing where<br>    the cursor jumps all over?<br>Message-ID:<br>    <CAFntmSiVoKem0XFkRyzz11sZ7ANGoK9d0eeA=Fbfs00aLzXmXg@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Indeed it helps. Thanks!<br><br>On Fri, Oct 20, 2017 at 1:27 PM, Clark Boylan <cboylan@sapwetik.org> wrote:<br><br>> On Fri, Oct 20, 2017, at 10:16 AM, Jeremy Freudberg wrote:<br>> > I don't wanna turn this into a complaint session about new Gerrit. But<br>> > three little notes since the upgrade:<br>> ><br>> > - I can't push the "e" key to go into editing mode anymore<br>> > - Cherry-picks change the gerrit topic (that's probably a feature)<br>> > - The patch I'm already looking at shows up under "Same Topic" (that's<br>> > probably a feature)<br>> ><br>> ><br>> > The only one that really kills me is the first one. Anyone know if the<br>> > keyboard shortcut changed, or if it's disabled but configurable, etc...?<br>><br>> The help overlay on the diff screen (brought up by hitting '?') says it<br>> is now "<Ctrl> + <Alt> + e : Open Inline Editor".<br>><br>> This seems to work for me in firefox on linux.<br>><br>> Hope this helps,<br>> Clark<br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/8b948aad/attachment-0001.html><br><br>------------------------------<br><br>Message: 22<br>Date: Fri, 20 Oct 2017 11:17:52 -0700<br>From: Clark Boylan <cboylan@sapwetik.org><br>To: openstack-dev@lists.openstack.org<br>Subject: Re: [openstack-dev] Fwd: [Distutils][pbr] Announcement: Pip<br>    10 is coming, and will move all internal APIs<br>Message-ID:<br>    <1508523472.3134925.1145696440.0CC7B066@webmail.messagingengine.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:<br>> It sounds like the PyPI/PyPA folks are planning some major changes to<br>> pip internals, soon.<br>> <br>> I know pbr uses setuptools, and I don't think it uses pip, but if<br>> someone has time to verify that it would be helpful.<br>> <br>> We'll also want to watch out for breakage in normal use of pip 10. If<br>> they're making changes this big, they may miss something in their own<br>> test coverage that affects our jobs.<br>> <br><br>After a quick skim of PBR I don't think we use pip internals anywhere.<br>Its all executed via the command itself. That said we should test this<br>so I've put up https://review.openstack.org/513825 (others should feel<br>free to iterate on it if it doesn't work) to install latest pip master<br>in a devstack run.<br><br>Clark<br><br><br><br>------------------------------<br><br>Message: 23<br>Date: Fri, 20 Oct 2017 12:17:11 -0700<br>From: Clark Boylan <cboylan@sapwetik.org><br>To: openstack-dev@lists.openstack.org<br>Subject: Re: [openstack-dev] Fwd: [Distutils][pbr] Announcement: Pip<br>    10 is coming, and will move all internal APIs<br>Message-ID:<br>    <1508527031.3146731.1145751688.60C55938@webmail.messagingengine.com><br>Content-Type: text/plain; charset="utf-8"<br><br><br><br>On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote:<br>> On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:<br>> > It sounds like the PyPI/PyPA folks are planning some major changes to<br>> > pip internals, soon.<br>> > <br>> > I know pbr uses setuptools, and I don't think it uses pip, but if<br>> > someone has time to verify that it would be helpful.<br>> > <br>> > We'll also want to watch out for breakage in normal use of pip 10. If<br>> > they're making changes this big, they may miss something in their own<br>> > test coverage that affects our jobs.<br>> > <br>> <br>> After a quick skim of PBR I don't think we use pip internals anywhere.<br>> Its all executed via the command itself. That said we should test this<br>> so I've put up https://review.openstack.org/513825 (others should feel<br>> free to iterate on it if it doesn't work) to install latest pip master<br>> in a devstack run.<br><br>And it has already caught its first bug. Fix and details at<br>https://review.openstack.org/#/c/513832/.<br><br>Clark<br><br><br><br>------------------------------<br><br>Message: 24<br>Date: Fri, 20 Oct 2017 19:25:34 +0000<br>From: "Waines, Greg" <Greg.Waines@windriver.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [ironic] Support for single OpenStack system<br>    supporting VM and Baremetal Instances simultaneously ?<br>Message-ID: <9890703D-EFD0-4BA5-8947-171302BF0A64@windriver.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hey,<br><br>We are in the process of integrating OpenStack Ironic into our own OpenStack Distribution.<br><br>Is there support for a single OpenStack system supporting VM and Baremetal Instances simultaneously ?  ( in NEWTON ?  in PIKE ? )<br>I BELIEVE the answer is yes.<br>BUT can someone confirm ?<br><br>And then, if YES,<br>THEN in such a system<br><br>·         i know there is a nova-compute for each COMPUTE NODE, and<br><br>·         i know there is a nova-compute for ALL the IRONIC NODEs<br><br><br>·         QUESTION:<br><br>o    Is there still ONLY A SINGLE nova-scheduler ?<br><br>o    i.e. which, based on the baremetal extraspec, schedules over the COMPUTE NODES or the IRONIC NODES ?<br><br>Greg.<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/f50ba144/attachment-0001.html><br><br>------------------------------<br><br>Message: 25<br>Date: Sat, 21 Oct 2017 06:55:48 +1100<br>From: Ian Wienand <iwienand@redhat.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [infra] Short gerrit / zuul outage<br>    2017-10-20    20:00UTC<br>Message-ID: <cbb313c9-e54d-8f8b-3ad6-8ffc8e09631e@redhat.com><br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br>On 10/20/2017 03:46 PM, Ian Wienand wrote:<br>> We plan a short outage (<30 minutes) of gerrit and zuul on 2017-10-20<br>> 20:00UTC to facilitate project rename requests.<br><br>Note this has been postponed to a future (TBD) date<br><br>Thanks,<br><br>-i<br><br><br><br>------------------------------<br><br>Message: 26<br>Date: Fri, 20 Oct 2017 13:14:13 -0700<br>From: Clark Boylan <cboylan@sapwetik.org><br>To: openstack-dev@lists.openstack.org<br>Subject: Re: [openstack-dev] Fwd: [Distutils][pbr] Announcement: Pip<br>    10 is coming, and will move all internal APIs<br>Message-ID:<br>    <1508530453.4124986.1145802896.63B3365C@webmail.messagingengine.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote:<br>> On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:<br>> > It sounds like the PyPI/PyPA folks are planning some major changes to<br>> > pip internals, soon.<br>> > <br>> > I know pbr uses setuptools, and I don't think it uses pip, but if<br>> > someone has time to verify that it would be helpful.<br>> > <br>> > We'll also want to watch out for breakage in normal use of pip 10. If<br>> > they're making changes this big, they may miss something in their own<br>> > test coverage that affects our jobs.<br>> > <br>> <br>> After a quick skim of PBR I don't think we use pip internals anywhere.<br>> Its all executed via the command itself. That said we should test this<br>> so I've put up https://review.openstack.org/513825 (others should feel<br>> free to iterate on it if it doesn't work) to install latest pip master<br>> in a devstack run.<br><br>The current issue this change is facing can be seen at<br>http://logs.openstack.org/25/513825/4/check/legacy-tempest-dsvm-py35/c31deb2/logs/devstacklog.txt.gz#_2017-10-20_20_07_54_838.<br>The tl;dr is that for distutils installed packages (basically all the<br>distro installed python packges) pip refuses to uninstall them in order<br>to perform upgrades because it can't reliably determine where all the<br>files are. I think this is a new pip 10 behavior.<br><br>In the general case I think this means we can not rely on global pip<br>installs anymore. This may be a good thing to bring up with upstream<br>PyPA as I expect it will break a lot of people in a lot of places (it<br>will break infra for example too).<br><br>Clark<br><br><br><br>------------------------------<br><br>Message: 27<br>Date: Fri, 20 Oct 2017 15:15:34 -0500<br>From: Miguel Lavalle <miguel@mlavalle.com><br>To: OpenStack Development Mailing List<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev]  [neutron] - are you attending the Sydney<br>    summit?<br>Message-ID:<br>    <CAEzGLDh=68Gn__FAnex-TfBxwnKcgq=4sORe92scmr-M-CdwYA@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi,<br><br>If you are a Neutron developer attending the Sydney Summit, please add your<br>name to the following etherpad so we can plan a team social event and<br>easily coordinate in person meetings:<br><br>https://etherpad.openstack.org/p/neutron-sydney-summit-attendees<br><br>Safe travels and see you Down Under!<br><br>Cheers<br><br>Miguel<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/39a8f584/attachment-0001.html><br><br>------------------------------<br><br>Message: 28<br>Date: Fri, 20 Oct 2017 16:32:05 -0400<br>From: Doug Hellmann <doug@doughellmann.com><br>To: openstack-dev <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Fwd: [Distutils][pbr][devstack][qa]<br>    Announcement: Pip 10 is coming, and will move all internal APIs<br>Message-ID: <1508531248-sup-3881@lrrr.local><br>Content-Type: text/plain; charset=UTF-8<br><br>Excerpts from Clark Boylan's message of 2017-10-20 13:14:13 -0700:<br>> On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote:<br>> > On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:<br>> > > It sounds like the PyPI/PyPA folks are planning some major changes to<br>> > > pip internals, soon.<br>> > > <br>> > > I know pbr uses setuptools, and I don't think it uses pip, but if<br>> > > someone has time to verify that it would be helpful.<br>> > > <br>> > > We'll also want to watch out for breakage in normal use of pip 10. If<br>> > > they're making changes this big, they may miss something in their own<br>> > > test coverage that affects our jobs.<br>> > > <br>> > <br>> > After a quick skim of PBR I don't think we use pip internals anywhere.<br>> > Its all executed via the command itself. That said we should test this<br>> > so I've put up https://review.openstack.org/513825 (others should feel<br>> > free to iterate on it if it doesn't work) to install latest pip master<br>> > in a devstack run.<br>> <br>> The current issue this change is facing can be seen at<br>> http://logs.openstack.org/25/513825/4/check/legacy-tempest-dsvm-py35/c31deb2/logs/devstacklog.txt.gz#_2017-10-20_20_07_54_838.<br>> The tl;dr is that for distutils installed packages (basically all the<br>> distro installed python packges) pip refuses to uninstall them in order<br>> to perform upgrades because it can't reliably determine where all the<br>> files are. I think this is a new pip 10 behavior.<br>> <br>> In the general case I think this means we can not rely on global pip<br>> installs anymore. This may be a good thing to bring up with upstream<br>> PyPA as I expect it will break a lot of people in a lot of places (it<br>> will break infra for example too).<br>> <br>> Clark<br>> <br><br>Yes, it would be good for someone who understands the cases where we're<br>doing these sorts of global package installations using pip to post on<br>distutils-sig explaining the breakage and asking for some time to let us<br>work around the issue.<br><br>We have a couple of ways to mitigate it, depending on the situation.<br><br>1. Pin the affected packages to the system package versions in our<br>   constraints list.<br><br>2. Install into a virtualenv that ignores system packages, avoiding the<br>   need to upgrade at all.<br><br>3. Remove the system package before installing from pip (why is it there<br>   in the first place?).<br><br>It's not clear to me which is the best approach.  I've added<br>[devstack][qa] to the subject line to draw some more attention to<br>this thread from folks familiar with these jobs.<br><br>Doug<br><br><br><br>------------------------------<br><br>Message: 29<br>Date: Fri, 20 Oct 2017 20:43:59 +0000<br>From: Andrea Frittoli <andrea.frittoli@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [qa] Proposing changes to 17UTC team meeting<br>Message-ID:<br>    <CAB7WYGUUXNcbROknz_O4DCoZjC7poZyPdvJuRLgem9-FHqw42Q@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Dear all,<br><br>The current schedule for QA meetings and office hours is as follows<br>(alternating weeks):<br><br>Week1:<br>- Tue 9:00 UTC Office hours in #openstack-qa<br>- Tue 17:00 UTC Meeting in #openstack-meeting<br>Week2:<br>- Tue 8:00 UTC Meeting in #openstack-meeting<br><br>Since the 17:00 UTC as a rather low attendance, but not zero, I would<br>propose to drop that meeting in favour of a second office hours slot, so<br>that we have one slot every week and the meeting would be every<br>second week:<br><br>Week1:<br>- Tue 9:00 UTC Office hours in #openstack-qa<br>Week2:<br>- Tue 8:00 UTC Meeting in #openstack-meeting<br>- [TBD] Office hours in #openstack-qa<br><br>Proposals for the office hours schedule in the doodle [0]<br><br>Let me know your thoughts on this proposal and please vote for the<br>time slot in the doodle.<br><br>Thank you!<br><br>Andrea Frittoli (andreaf)<br><br>[0] https://doodle.com/poll/kf6b8847wa2s5mxv<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/9962ed9f/attachment-0001.html><br><br>------------------------------<br><br>Message: 30<br>Date: Fri, 20 Oct 2017 21:25:26 +0000<br>From: Kendall Nelson <kennelson11@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [All][Elections] Vote Vote Vote in the TC<br>    election!<br>Message-ID:<br>    <CAJ6yrQiTjFc5+-K-wCF_4nz7Ky0V7pbO8sjSKatua8Ui_EyE0g@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hello!<br><br>We are coming down to the last hours for voting in the TC election. Voting<br>ends 23:45 October 20th, 2017.<br><br>Search your gerrit preferred email address[0] for the following subject:<br>    Poll: Queens TC Election<br><br>That is your ballot and links you to the voting application. Please vote.<br>If you have voted, please encourage your colleagues to vote.<br><br>Candidate statements are linked to the names of all confirmed candidates:<br>http://governance.openstack.org/election/#<br><http://governance.openstack.org/election/#pike-tc-candidates>pike<br><http://governance.openstack.org/election/#pike-tc-candidates>-tc-candidates<br><http://governance.openstack.org/election/#pike-tc-candidates><br><br>What to do if you don't see the email and have a commit in at least one of<br>the official programs projects[1]:<br>  * check the trash of your gerrit Preferred Email address[0], in case it<br>went into trash or spam<br>  * wait a bit and check again, in case your email server is a bit slow<br>  * find the sha of at least one commit from the program project repos[1]<br>and email the election officials[2]. If we can confirm that you are<br>entitled to vote, we will add you to the voters list and you will be<br>emailed a ballot.<br><br>Please vote!<br><br>Thank you,<br><br>Kendall Nelson (diablo_rojo)<br><br>[0] Sign into review.openstack.org: Go to Settings > Contact<br>    Information. Look at the email listed as your Preferred Email.<br>    That is where the ballot has been sent.<br>[1]:<br>https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=<br><https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=oct-2017-elections><br>oct<br><https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=oct-2017-elections><br>-2017<br><https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=oct-2017-elections><br>-elections<br><https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=oct-2017-elections><br>[2] http://governance.openstack.org/election/#election-officials<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/69eeb2f1/attachment-0001.html><br><br>------------------------------<br><br>Message: 31<br>Date: Fri, 20 Oct 2017 17:50:15 -0400<br>From: Sam Yaple <samuel@yaple.net><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Fwd: [Distutils][pbr][devstack][qa]<br>    Announcement: Pip 10 is coming, and will move all internal APIs<br>Message-ID:<br>    <CAJ3CzQVG+R+DeYf89uGWEeK36w+n+t6AuAE5MD2S8_=nyiOJPA@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On Fri, Oct 20, 2017 at 4:32 PM, Doug Hellmann <doug@doughellmann.com><br>wrote:<br><br>> Excerpts from Clark Boylan's message of 2017-10-20 13:14:13 -0700:<br>> > On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote:<br>> > > On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:<br>> > > > It sounds like the PyPI/PyPA folks are planning some major changes to<br>> > > > pip internals, soon.<br>> > > ><br>> > > > I know pbr uses setuptools, and I don't think it uses pip, but if<br>> > > > someone has time to verify that it would be helpful.<br>> > > ><br>> > > > We'll also want to watch out for breakage in normal use of pip 10. If<br>> > > > they're making changes this big, they may miss something in their own<br>> > > > test coverage that affects our jobs.<br>> > > ><br>> > ><br>> > > After a quick skim of PBR I don't think we use pip internals anywhere.<br>> > > Its all executed via the command itself. That said we should test this<br>> > > so I've put up https://review.openstack.org/513825 (others should feel<br>> > > free to iterate on it if it doesn't work) to install latest pip master<br>> > > in a devstack run.<br>> ><br>> > The current issue this change is facing can be seen at<br>> > http://logs.openstack.org/25/513825/4/check/legacy-tempest-<br>> dsvm-py35/c31deb2/logs/devstacklog.txt.gz#_2017-10-20_20_07_54_838.<br>> > The tl;dr is that for distutils installed packages (basically all the<br>> > distro installed python packges) pip refuses to uninstall them in order<br>> > to perform upgrades because it can't reliably determine where all the<br>> > files are. I think this is a new pip 10 behavior.<br>> ><br>> > In the general case I think this means we can not rely on global pip<br>> > installs anymore. This may be a good thing to bring up with upstream<br>> > PyPA as I expect it will break a lot of people in a lot of places (it<br>> > will break infra for example too).<br>> ><br>> > Clark<br>> ><br>><br>> Yes, it would be good for someone who understands the cases where we're<br>> doing these sorts of global package installations using pip to post on<br>> distutils-sig explaining the breakage and asking for some time to let us<br>> work around the issue.<br>><br>> We have a couple of ways to mitigate it, depending on the situation.<br>><br>> 1. Pin the affected packages to the system package versions in our<br>>    constraints list.<br>><br>> 2. Install into a virtualenv that ignores system packages, avoiding the<br>>    need to upgrade at all.<br>><br>> 3. Remove the system package before installing from pip (why is it there<br>>    in the first place?).<br>><br>> It's not clear to me which is the best approach.  I've added<br>> [devstack][qa] to the subject line to draw some more attention to<br>> this thread from folks familiar with these jobs.<br>><br>> Doug<br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>><br><br>I have used option 2 with great success to avoid the issue of system<br>package conflicts for a couple of years now, back when pip would still<br>uninstall system packages for upgrades.<br><br>Option 3 is difficult to make work since so many packages have dependancies<br>on python-* packages, I abandoned that approach fairly quickly.<br><br>Thanks,<br>SamYaple<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/6907c2f9/attachment-0001.html><br><br>------------------------------<br><br>Message: 32<br>Date: Fri, 20 Oct 2017 22:50:53 +0000<br>From: "Fox, Kevin M" <Kevin.Fox@pnnl.gov><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]<br>    [keystone][all] v2.0    API removal<br>Message-ID:<br>    <1A3C52DFCD06494D8528644858247BF01C019FFD@EX10MBOX03.pnnl.gov><br>Content-Type: text/plain; charset="us-ascii"<br><br>No, I'm not saying its the TC teams job to bludgeon folks.<br><br>I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate. <br><br>I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.<br><br>Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?<br><br>Thanks,<br>Kevin<br>________________________________________<br>From: Jeremy Stanley [fungi@yuggoth.org]<br>Sent: Friday, October 20, 2017 10:53 AM<br>To: openstack-dev@lists.openstack.org<br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0        API removal<br><br>On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:<br>[...]<br>> I know the TC's been shying away from these sorts of questions,<br>> but this one has a pretty big impact. TC?<br>[...]<br><br>The OpenStack Technical Committee isn't really a bludgeon with which<br>to beat teams when someone in the community finds fault with a<br>decision; it drafts/revises policy and arbitrates disputes between<br>teams. What sort of action are you seeking in regard to the Keystone<br>team finally acting this cycle on removal of their long-deprecated<br>legacy API, and with what choices of theirs do you disagree?<br><br>Do you feel the deprecation was not communicated widely enough? Do<br>you feel that SDKs haven't been updated with sufficient support for<br>the v3 API? Are you concerned that lack of v2 API support will<br>prevent organizations running the upcoming Queens release from<br>qualifying for interoperability trademarks? Something else entirely?<br>--<br>Jeremy Stanley<br><br><br><br>------------------------------<br><br>Message: 33<br>Date: Fri, 20 Oct 2017 22:51:29 +0000<br>From: "Steven Dake (stdake)" <stdake@cisco.com><br>To: "sam@yaple.net" <sam@yaple.net>, "OpenStack Development Mailing<br>    List (not for usage questions)" <openstack-dev@lists.openstack.org>,<br>    Gabriele Cerami <gcerami@redhat.com><br>Subject: Re: [openstack-dev] [TripleO][Kolla] Concerns about<br>    containers images in DockerHub<br>Message-ID: <6F137552-59BD-40E2-B498-4564A6250B73@cisco.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Sam,<br><br>Agreed this matches my experience. Building one by one though will result in massive image size sprawl.<br><br>Regards<br>-steve<br><br>From: Sam Yaple <samuel@yaple.net><br>Reply-To: "sam@yaple.net" <sam@yaple.net>, "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org><br>Date: Thursday, October 19, 2017 at 10:37 PM<br>To: Gabriele Cerami <gcerami@redhat.com><br>Cc: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [TripleO][Kolla] Concerns about containers images in DockerHub<br><br><br><br>On Thu, Oct 19, 2017 at 11:23 PM, Gabriele Cerami <gcerami@redhat.com<mailto:gcerami@redhat.com>> wrote:<br>On 19 Oct, Sam Yaple wrote:<br>> So it seems tripleo is building *all* images and then pushing them.<br>> Reworking your number leads me to believe you will be consuming 10-15GB in<br>> total on Dockerhub. Kolla images are only the size that you posted when<br>> built as seperate services. Just keep building all the images at the same<br>> time and you wont get anywhere near the numbers you posted.<br><br>Makes sense, so considering the shared layers<br>- a size of 10-15GB per build.<br>- 4-6 builds rotated per release<br>- 3-4 releases<br><br>- a size of 1-2GB per build<br>- 4-6 builds rotated per release<br>- 3-4 releases<br><br>At worst you are looking at 48GB not 360GB. Dont worry so much there!<br><br>total size will be approximately be 360GB in the worst case, and 120GB in<br>the best case, which seems a bit more reasonable.<br><br>Thanks for he clarifications<br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/8378bafd/attachment-0001.html><br><br>------------------------------<br><br>Message: 34<br>Date: Fri, 20 Oct 2017 16:06:00 -0700<br>From: Tim Burke <tim@swiftstack.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Do you hate the new gerrit thing where<br>    the cursor jumps all over?<br>Message-ID: <C9C23ACB-2DFC-453E-A8AA-8475E448C7E3@swiftstack.com><br>Content-Type: text/plain; charset=us-ascii<br><br>OMG yes! I can actually search when looking at a diff now!<br><br>Thanks Matt.<br><br>Tim<br><br>> On Oct 20, 2017, at 9:02 AM, Matt Riedemann <mriedemos@gmail.com> wrote:<br>> <br>> When you're lower in a change trying to expand comments and it always jumps you back up to the top?<br>> <br>> Since not everyone might know about the solution, it's:<br>> <br>> 1. Go into settings<br>> 2. Diff Preference<br>> 3. Change "Render" from Fast to Slow.<br>> 4. Save<br>> <br>> Get back to reviewing stuff without losing your mind.<br>> <br>> -- <br>> <br>> Thanks,<br>> <br>> Matt<br>> <br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br><br><br>------------------------------<br><br>Message: 35<br>Date: Fri, 20 Oct 2017 23:59:15 +0000<br>From: Kendall Nelson <kennelson11@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [all] [elections] Technical Committee<br>    Election    Results<br>Message-ID:<br>    <CAJ6yrQg=OsmSwg4z11jy=vGCsBDL4C7vG-DhfiReJnRck018hw@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hello Everyone :)<br><br>Please join me in congratulating the 6 newly elected members of the<br>Technical Committee (TC)!<br><br>Colleen Murphy (cmurphy)<br>Doug Hellmann (dhellmann)<br>Emilien Macchi (emilienm)<br>Jeremy Stanley (fungi)<br>Julia Kreger (TheJulia)<br>Paul Belanger (pabelanger)<br><br>Full results:<br>http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae<br><br>Election process details and results are also available here:<br>https://governance.openstack.org/election/<br><br>Thank you to all of the candidates, having a good group of candidates helps<br>engage the community in our democratic process.<br><br>Thank you to all who voted and who encouraged others to vote. We need to<br>ensure your voice is heard.<br><br>Thank you for another great round.<br><br>-Kendall Nelson (diablo_rojo)<br><br>[1] https://review.openstack.org/#/c/513881/<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/a0767250/attachment-0001.html><br><br>------------------------------<br><br>Message: 36<br>Date: Sat, 21 Oct 2017 02:12:46 +0200<br>From: Ildiko Vancsa <ildiko.vancsa@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [all] [elections] Technical Committee<br>    Election Results<br>Message-ID: <714F6FEF-F841-4594-A7B6-364F926DB951@gmail.com><br>Content-Type: text/plain; charset=utf-8<br><br>Congratulations to our new TC members! :)<br><br>Best Regards,<br>Ildikó<br><br><br>> On 2017. Oct 21., at 1:59, Kendall Nelson <kennelson11@gmail.com> wrote:<br>> <br>> Hello Everyone :) <br>> <br>> Please join me in congratulating the 6 newly elected members of the Technical Committee (TC)!<br>> <br>> Colleen Murphy (cmurphy)<br>> Doug Hellmann (dhellmann)<br>> Emilien Macchi (emilienm)<br>> Jeremy Stanley (fungi)<br>> Julia Kreger (TheJulia)<br>> Paul Belanger (pabelanger)<br>> <br>> Full results: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae <br>> <br>> Election process details and results are also available here: https://governance.openstack.org/election/ <br>> <br>> Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process.<br>> <br>> Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard.<br>> <br>> Thank you for another great round.<br>> <br>> -Kendall Nelson (diablo_rojo)<br>> <br>> [1] https://review.openstack.org/#/c/513881/ <br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br><br><br>------------------------------<br><br>Message: 37<br>Date: Fri, 20 Oct 2017 17:16:31 -0700<br>From: Morgan Fainberg <morgan.fainberg@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]<br>    [keystone][all] v2.0 API removal<br>Message-ID:<br>    <CAGnj6atBqi5Vo0xpsuNo7+x4U=ixLoRfoQ1Xkq5+ZqVHNaDvBg@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>Let me clarify a few things regarding the V2.0 removal:<br><br>* This has been planned for years at this point. At one time (I am<br>looking for the documentation, once I find it I'll include it on this<br>thread) we worked with Nova and the TC to set forth a timeline on the<br>removal. Part of that agreement was that this was a one-time deal. We<br>would remove the V2.0 API in favor of the v3 API but would never<br>remove another API going forward.<br><br>   A few reasons for removing the V2.0 API that were discussed and<br>drove the decision:<br><br>   1) The V2.0 API had behavior that was explicitly breaking the security model:<br><br>       * A user could authenticate with a scope not the default<br>domain) which could lead to oddities in enforcement when using v2.0<br>APIs and introduced a number of edge cases. This could not be fixed<br>without breaking the V2.0 API contract and every single change to V3<br>and features required a lot of time to ensure V2.0 was not breaking<br>and had appropriate translations to/from the different data formats.<br><br>       * The V2.0 AUTH API included the token (secure) data in the URL<br>path, this means that all logs from apache (or other web servers and<br>wsgi apps) had to be considered privileged and could not be exposed<br>for debugging purposes (and in some environments may not be accessed<br>without significant access-controls). This also could not be fixed<br>without breaking the V2.0 API contract.<br><br>       * The V2.0 policy was effectively hard coded (effectively) to<br>use "admin" and "member" roles. Retrofitting the APIs to support fully<br>policy was extremely difficult and could break default behaviors<br>(easily) in many environments. This was also deemed to be mostly<br>unfix-able without breaking the V2.0 API contract.<br><br><br>     In short, the maintenance on V2.0 API was significant, it was a<br>lot of work to maintain especially since the API could not receive any<br>active development due to lacking basic features introduced in v3.0.<br>There were also a significant number of edge cases where v3 had some<br>very hack-y support for features (required in openstack services) via<br>auth to support the possibility of v2->v3 translations.<br><br><br>   2) V2.0 had been bit rotting. Many items had limited testing and<br>were found to be broken. Adding tests that were both V3 and V2.0 aware<br>added another layer of difficulty in maintaining the API, much of the<br>time we had to spin many new patches to ensure that we didn't break<br>v2.0 contracts with a non-breaking v3 change (or in fixing a v2 API<br>call, we would be somewhat forced into breaking the API contract).<br><br><br>   3) The Keystone team is acutely aware that this was a painful<br>transition and made the choice to drop the API even in that light. The<br>choice of "breaking the API contract" a number of times verses<br>lightening the developer load (we are strapped for resources working<br>on Keystone as are many services, the overhead and added load makes it<br>mostly untenable) and do a single (large) change with the<br>understanding that V3 APIs cannot be removed was preferable.<br><br><br>The TC agreed to this removal. The service teams agreed to this<br>removal. This was telegraphed as much as we could via deprecation and<br>many, many, many discussions on this topic. There really was no good<br>solution, we took the solution that was the best for OpenStack in our<br>opinion based upon the place where Keystone is.<br><br>We can confidently commit to the following:<br>  * v3 APIs (Even the ones we dislike) will not go away<br>  * barring a massive security hole, we will not break the API<br>contracts on V3] (we may add data, we will not remove/restructure<br>data)<br>  * If we implement microversions, you may see API changes (similar to<br>how nova works), but as of today, we do not implement microversions<br><br>We have worked with defcore/refstack, qa teams, all services (I think<br>we missed one, it has since been fixed), clients, SDK(s), etc to<br>ensure that as much support as possible is in place to make utilizing<br>V3 easy.<br><br><br><br><br>On Fri, Oct 20, 2017 at 3:50 PM, Fox, Kevin M <Kevin.Fox@pnnl.gov> wrote:<br>> No, I'm not saying its the TC teams job to bludgeon folks.<br>><br>> I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.<br>><br>> I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.<br>><br>> Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?<br>><br>> Thanks,<br>> Kevin<br>> ________________________________________<br>> From: Jeremy Stanley [fungi@yuggoth.org]<br>> Sent: Friday, October 20, 2017 10:53 AM<br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0        API removal<br>><br>> On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:<br>> [...]<br>>> I know the TC's been shying away from these sorts of questions,<br>>> but this one has a pretty big impact. TC?<br>> [...]<br>><br>> The OpenStack Technical Committee isn't really a bludgeon with which<br>> to beat teams when someone in the community finds fault with a<br>> decision; it drafts/revises policy and arbitrates disputes between<br>> teams. What sort of action are you seeking in regard to the Keystone<br>> team finally acting this cycle on removal of their long-deprecated<br>> legacy API, and with what choices of theirs do you disagree?<br>><br>> Do you feel the deprecation was not communicated widely enough? Do<br>> you feel that SDKs haven't been updated with sufficient support for<br>> the v3 API? Are you concerned that lack of v2 API support will<br>> prevent organizations running the upcoming Queens release from<br>> qualifying for interoperability trademarks? Something else entirely?<br>> --<br>> Jeremy Stanley<br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br><br>------------------------------<br><br>Message: 38<br>Date: Sat, 21 Oct 2017 11:20:29 +1100<br>From: Tony Breeds <tony@bakeyournoodle.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [all] [elections] Technical Committee<br>    Election Results<br>Message-ID: <20171021002027.GB2430@thor.bakeyournoodle.com><br>Content-Type: text/plain; charset="utf-8"<br><br><br>Hi All,<br>    With the election behind us it's somewhat traditional to look at<br>some simple stats from the elections:<br><br>+----------+-----------------------+-------------------+-----------------------+<br>| Election | Electorate  (delta %) | Voted   (delta %) | Turnout %   (delta %) |<br>+----------+-----------------------+-------------------+-----------------------+<br>|  10/2013 |       1106  (    nan) |   342   (    nan) |     30.92   (    nan) |<br>|  04/2014 |       1510  (  36.53) |   448   (  30.99) |     29.67   (  -4.05) |<br>|  10/2014 |       1893  (  25.36) |   506   (  12.95) |     26.73   (  -9.91) |<br>|  04/2015 |       2169  (  14.58) |   548   (   8.30) |     25.27   (  -5.48) |<br>|  10/2015 |       2759  (  27.20) |   619   (  12.96) |     22.44   ( -11.20) |<br>|  04/2016 |       3284  (  19.03) |   652   (   5.33) |     19.85   ( -11.51) |<br>|  10/2016 |       3517  (   7.10) |   801   (  22.85) |     22.78   (  14.71) |<br>|  04/2017 |       3191  (  -9.27) |   427   ( -46.69) |     13.38   ( -41.25) |<br>|  10/2017 |       2430  ( -23.85) |   420   (  -1.64) |     17.28   (  29.16) |<br>+----------+-----------------------+-------------------+-----------------------+<br><br>Election CIVS links<br> 10/2014: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4<br> 04/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688<br> 10/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4ef58718618691a0<br> 04/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a<br> 10/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010<br> 04/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_072c4cd7ff0673b5<br> 10/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae<br><br>I don't have a feel for with the Pike electorate decreased but my gut<br>feel is that it was organic drop-off possibly in part to the shorter<br>Ocata development cycle.  The Queens drop-off was due to a new[1]<br>membership API being available that meant we could validate Foundation<br>membership instead of using gerrit permission as a proxy.<br><br>I'd like to call out that with Pike we had a very dramatic decrease in<br>voter turnout both in absolute and relative terms.  As a community it's<br>worth trying to understand whether this is a problem and/or a trend that<br>needs to change.<br><br>Yours Tony.<br><br>[1] It wasn't that new it was also used during the PTL election[2]<br>[2] See:<br>    http://lists.openstack.org/pipermail/openstack-dev/2017-July/119786.html ; and<br>    http://lists.openstack.org/pipermail/openstack-dev/2017-August/120544.html<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: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171021/b590d987/attachment-0001.sig><br><br>------------------------------<br><br>Message: 39<br>Date: Fri, 20 Oct 2017 17:21:27 -0700<br>From: Morgan Fainberg <morgan.fainberg@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]<br>    [keystone][all] v2.0 API removal<br>Message-ID:<br>    <CAGnj6atmmK6KPhyy-Bvx6JMwNZ9-f0p+Jr_iW-tpUe8ykM_VCg@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>In addendum, the final v2.0 (EC2-API) path will eventually be removed<br>(mitaka +7, the "T" release). The v3 versions (where they exist) will<br>continue to be maintained and not removed.<br><br>On Fri, Oct 20, 2017 at 5:16 PM, Morgan Fainberg<br><morgan.fainberg@gmail.com> wrote:<br>> Let me clarify a few things regarding the V2.0 removal:<br>><br>> * This has been planned for years at this point. At one time (I am<br>> looking for the documentation, once I find it I'll include it on this<br>> thread) we worked with Nova and the TC to set forth a timeline on the<br>> removal. Part of that agreement was that this was a one-time deal. We<br>> would remove the V2.0 API in favor of the v3 API but would never<br>> remove another API going forward.<br>><br>>    A few reasons for removing the V2.0 API that were discussed and<br>> drove the decision:<br>><br>>    1) The V2.0 API had behavior that was explicitly breaking the security model:<br>><br>>        * A user could authenticate with a scope not the default<br>> domain) which could lead to oddities in enforcement when using v2.0<br>> APIs and introduced a number of edge cases. This could not be fixed<br>> without breaking the V2.0 API contract and every single change to V3<br>> and features required a lot of time to ensure V2.0 was not breaking<br>> and had appropriate translations to/from the different data formats.<br>><br>>        * The V2.0 AUTH API included the token (secure) data in the URL<br>> path, this means that all logs from apache (or other web servers and<br>> wsgi apps) had to be considered privileged and could not be exposed<br>> for debugging purposes (and in some environments may not be accessed<br>> without significant access-controls). This also could not be fixed<br>> without breaking the V2.0 API contract.<br>><br>>        * The V2.0 policy was effectively hard coded (effectively) to<br>> use "admin" and "member" roles. Retrofitting the APIs to support fully<br>> policy was extremely difficult and could break default behaviors<br>> (easily) in many environments. This was also deemed to be mostly<br>> unfix-able without breaking the V2.0 API contract.<br>><br>><br>>      In short, the maintenance on V2.0 API was significant, it was a<br>> lot of work to maintain especially since the API could not receive any<br>> active development due to lacking basic features introduced in v3.0.<br>> There were also a significant number of edge cases where v3 had some<br>> very hack-y support for features (required in openstack services) via<br>> auth to support the possibility of v2->v3 translations.<br>><br>><br>>    2) V2.0 had been bit rotting. Many items had limited testing and<br>> were found to be broken. Adding tests that were both V3 and V2.0 aware<br>> added another layer of difficulty in maintaining the API, much of the<br>> time we had to spin many new patches to ensure that we didn't break<br>> v2.0 contracts with a non-breaking v3 change (or in fixing a v2 API<br>> call, we would be somewhat forced into breaking the API contract).<br>><br>><br>>    3) The Keystone team is acutely aware that this was a painful<br>> transition and made the choice to drop the API even in that light. The<br>> choice of "breaking the API contract" a number of times verses<br>> lightening the developer load (we are strapped for resources working<br>> on Keystone as are many services, the overhead and added load makes it<br>> mostly untenable) and do a single (large) change with the<br>> understanding that V3 APIs cannot be removed was preferable.<br>><br>><br>> The TC agreed to this removal. The service teams agreed to this<br>> removal. This was telegraphed as much as we could via deprecation and<br>> many, many, many discussions on this topic. There really was no good<br>> solution, we took the solution that was the best for OpenStack in our<br>> opinion based upon the place where Keystone is.<br>><br>> We can confidently commit to the following:<br>>   * v3 APIs (Even the ones we dislike) will not go away<br>>   * barring a massive security hole, we will not break the API<br>> contracts on V3] (we may add data, we will not remove/restructure<br>> data)<br>>   * If we implement microversions, you may see API changes (similar to<br>> how nova works), but as of today, we do not implement microversions<br>><br>> We have worked with defcore/refstack, qa teams, all services (I think<br>> we missed one, it has since been fixed), clients, SDK(s), etc to<br>> ensure that as much support as possible is in place to make utilizing<br>> V3 easy.<br>><br>><br>><br>><br>> On Fri, Oct 20, 2017 at 3:50 PM, Fox, Kevin M <Kevin.Fox@pnnl.gov> wrote:<br>>> No, I'm not saying its the TC teams job to bludgeon folks.<br>>><br>>> I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.<br>>><br>>> I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.<br>>><br>>> Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?<br>>><br>>> Thanks,<br>>> Kevin<br>>> ________________________________________<br>>> From: Jeremy Stanley [fungi@yuggoth.org]<br>>> Sent: Friday, October 20, 2017 10:53 AM<br>>> To: openstack-dev@lists.openstack.org<br>>> Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0        API removal<br>>><br>>> On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:<br>>> [...]<br>>>> I know the TC's been shying away from these sorts of questions,<br>>>> but this one has a pretty big impact. TC?<br>>> [...]<br>>><br>>> The OpenStack Technical Committee isn't really a bludgeon with which<br>>> to beat teams when someone in the community finds fault with a<br>>> decision; it drafts/revises policy and arbitrates disputes between<br>>> teams. What sort of action are you seeking in regard to the Keystone<br>>> team finally acting this cycle on removal of their long-deprecated<br>>> legacy API, and with what choices of theirs do you disagree?<br>>><br>>> Do you feel the deprecation was not communicated widely enough? Do<br>>> you feel that SDKs haven't been updated with sufficient support for<br>>> the v3 API? Are you concerned that lack of v2 API support will<br>>> prevent organizations running the upcoming Queens release from<br>>> qualifying for interoperability trademarks? Something else entirely?<br>>> --<br>>> Jeremy Stanley<br>>><br>>> __________________________________________________________________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br><br>------------------------------<br><br>Message: 40<br>Date: Sat, 21 Oct 2017 00:28:11 +0000<br>From: "Fox, Kevin M" <Kevin.Fox@pnnl.gov><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]<br>    [keystone][all] v2.0 API removal<br>Message-ID:<br>    <1A3C52DFCD06494D8528644858247BF01C01A08D@EX10MBOX03.pnnl.gov><br>Content-Type: text/plain; charset="us-ascii"<br><br>Ok. Cool. Didn't know that. Sounds like all due diligence was done then (and maybe plus some :). Thanks for the background info.<br><br>Kevin<br>________________________________________<br>From: Morgan Fainberg [morgan.fainberg@gmail.com]<br>Sent: Friday, October 20, 2017 5:16 PM<br>To: OpenStack Development Mailing List (not for usage questions)<br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal<br><br>Let me clarify a few things regarding the V2.0 removal:<br><br>* This has been planned for years at this point. At one time (I am<br>looking for the documentation, once I find it I'll include it on this<br>thread) we worked with Nova and the TC to set forth a timeline on the<br>removal. Part of that agreement was that this was a one-time deal. We<br>would remove the V2.0 API in favor of the v3 API but would never<br>remove another API going forward.<br><br>   A few reasons for removing the V2.0 API that were discussed and<br>drove the decision:<br><br>   1) The V2.0 API had behavior that was explicitly breaking the security model:<br><br>       * A user could authenticate with a scope not the default<br>domain) which could lead to oddities in enforcement when using v2.0<br>APIs and introduced a number of edge cases. This could not be fixed<br>without breaking the V2.0 API contract and every single change to V3<br>and features required a lot of time to ensure V2.0 was not breaking<br>and had appropriate translations to/from the different data formats.<br><br>       * The V2.0 AUTH API included the token (secure) data in the URL<br>path, this means that all logs from apache (or other web servers and<br>wsgi apps) had to be considered privileged and could not be exposed<br>for debugging purposes (and in some environments may not be accessed<br>without significant access-controls). This also could not be fixed<br>without breaking the V2.0 API contract.<br><br>       * The V2.0 policy was effectively hard coded (effectively) to<br>use "admin" and "member" roles. Retrofitting the APIs to support fully<br>policy was extremely difficult and could break default behaviors<br>(easily) in many environments. This was also deemed to be mostly<br>unfix-able without breaking the V2.0 API contract.<br><br><br>     In short, the maintenance on V2.0 API was significant, it was a<br>lot of work to maintain especially since the API could not receive any<br>active development due to lacking basic features introduced in v3.0.<br>There were also a significant number of edge cases where v3 had some<br>very hack-y support for features (required in openstack services) via<br>auth to support the possibility of v2->v3 translations.<br><br><br>   2) V2.0 had been bit rotting. Many items had limited testing and<br>were found to be broken. Adding tests that were both V3 and V2.0 aware<br>added another layer of difficulty in maintaining the API, much of the<br>time we had to spin many new patches to ensure that we didn't break<br>v2.0 contracts with a non-breaking v3 change (or in fixing a v2 API<br>call, we would be somewhat forced into breaking the API contract).<br><br><br>   3) The Keystone team is acutely aware that this was a painful<br>transition and made the choice to drop the API even in that light. The<br>choice of "breaking the API contract" a number of times verses<br>lightening the developer load (we are strapped for resources working<br>on Keystone as are many services, the overhead and added load makes it<br>mostly untenable) and do a single (large) change with the<br>understanding that V3 APIs cannot be removed was preferable.<br><br><br>The TC agreed to this removal. The service teams agreed to this<br>removal. This was telegraphed as much as we could via deprecation and<br>many, many, many discussions on this topic. There really was no good<br>solution, we took the solution that was the best for OpenStack in our<br>opinion based upon the place where Keystone is.<br><br>We can confidently commit to the following:<br>  * v3 APIs (Even the ones we dislike) will not go away<br>  * barring a massive security hole, we will not break the API<br>contracts on V3] (we may add data, we will not remove/restructure<br>data)<br>  * If we implement microversions, you may see API changes (similar to<br>how nova works), but as of today, we do not implement microversions<br><br>We have worked with defcore/refstack, qa teams, all services (I think<br>we missed one, it has since been fixed), clients, SDK(s), etc to<br>ensure that as much support as possible is in place to make utilizing<br>V3 easy.<br><br><br><br><br>On Fri, Oct 20, 2017 at 3:50 PM, Fox, Kevin M <Kevin.Fox@pnnl.gov> wrote:<br>> No, I'm not saying its the TC teams job to bludgeon folks.<br>><br>> I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.<br>><br>> I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.<br>><br>> Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?<br>><br>> Thanks,<br>> Kevin<br>> ________________________________________<br>> From: Jeremy Stanley [fungi@yuggoth.org]<br>> Sent: Friday, October 20, 2017 10:53 AM<br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0        API removal<br>><br>> On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:<br>> [...]<br>>> I know the TC's been shying away from these sorts of questions,<br>>> but this one has a pretty big impact. TC?<br>> [...]<br>><br>> The OpenStack Technical Committee isn't really a bludgeon with which<br>> to beat teams when someone in the community finds fault with a<br>> decision; it drafts/revises policy and arbitrates disputes between<br>> teams. What sort of action are you seeking in regard to the Keystone<br>> team finally acting this cycle on removal of their long-deprecated<br>> legacy API, and with what choices of theirs do you disagree?<br>><br>> Do you feel the deprecation was not communicated widely enough? Do<br>> you feel that SDKs haven't been updated with sufficient support for<br>> the v3 API? Are you concerned that lack of v2 API support will<br>> prevent organizations running the upcoming Queens release from<br>> qualifying for interoperability trademarks? Something else entirely?<br>> --<br>> Jeremy Stanley<br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br><br>------------------------------<br><br>Message: 41<br>Date: Fri, 20 Oct 2017 21:08:51 -0500<br>From: "Cody A.W. Somerville" <cody.somerville@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]<br>    [keystone][all] v2.0 API removal<br>Message-ID:<br>    <CAF=aq-hxBnDazHri_LzRieGcJA59g0FvV9Z50kfOykEGWNf7Ng@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On Fri, Oct 20, 2017 at 7:16 PM, Morgan Fainberg <morgan.fainberg@gmail.com><br>wrote:<br><br>> Let me clarify a few things regarding the V2.0 removal:<br>><br>> * This has been planned for years at this point. At one time (I am<br>> looking for the documentation, once I find it I'll include it on this<br>> thread) we worked with Nova and the TC to set forth a timeline on the<br>> removal. Part of that agreement was that this was a one-time deal. We<br>> would remove the V2.0 API in favor of the v3 API but would never<br>> remove another API going forward.<br>><br><br><br>Glad to hear this. Does this apply to all projects? Deprecation and removal<br>of API versions or versions of features (especially before new version of<br>feature has parity and proven scale to older version of feature) has been a<br>pain point for large production public clouds in terms of keeping in sync<br>with upstream which then adversely affects the ability of that organization<br>to contribute back to upstream due to having to stay on older versions. It<br>can quickly become too painful, risky, and costly to ever reconcile<br>eventually leading to the organization no longer meaningful contributing to<br>projects where they've drifted too far all together. I consider this<br>scenario to be very unfortunate for the customer's of that public cloud as<br>well as the OpenStack project itself.<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/5ab79bc1/attachment-0001.html><br><br>------------------------------<br><br>Message: 42<br>Date: Fri, 20 Oct 2017 23:06:28 -0700<br>From: Michał Jastrzębski <inc007@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [TripleO][Kolla] Concerns about<br>    containers images in DockerHub<br>Message-ID:<br>    <CALc0zUBhpO18m5XLospXpNKRmVsxBDXTepyMuSNARhb=0kV6fQ@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Additionally you can build only images you need. Some of images we have are<br>quite.. niche. If you limit number of images to only those you care about,<br>that will lower total size significantly<br><br>On Oct 20, 2017 3:51 PM, "Steven Dake (stdake)" <stdake@cisco.com> wrote:<br><br>> Sam,<br>><br>><br>><br>> Agreed this matches my experience. Building one by one though will result<br>> in massive image size sprawl.<br>><br>><br>><br>> Regards<br>><br>> -steve<br>><br>><br>><br>> *From: *Sam Yaple <samuel@yaple.net><br>> *Reply-To: *"sam@yaple.net" <sam@yaple.net>, "OpenStack Development<br>> Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<br>> ><br>> *Date: *Thursday, October 19, 2017 at 10:37 PM<br>> *To: *Gabriele Cerami <gcerami@redhat.com><br>> *Cc: *"OpenStack Development Mailing List (not for usage questions)" <<br>> openstack-dev@lists.openstack.org><br>> *Subject: *Re: [openstack-dev] [TripleO][Kolla] Concerns about containers<br>> images in DockerHub<br>><br>><br>><br>><br>><br>><br>><br>> On Thu, Oct 19, 2017 at 11:23 PM, Gabriele Cerami <gcerami@redhat.com><br>> wrote:<br>><br>> On 19 Oct, Sam Yaple wrote:<br>> > So it seems tripleo is building *all* images and then pushing them.<br>> > Reworking your number leads me to believe you will be consuming 10-15GB<br>> in<br>> > total on Dockerhub. Kolla images are only the size that you posted when<br>> > built as seperate services. Just keep building all the images at the same<br>> > time and you wont get anywhere near the numbers you posted.<br>><br>> Makes sense, so considering the shared layers<br>> - a size of 10-15GB per build.<br>> - 4-6 builds rotated per release<br>> - 3-4 releases<br>><br>><br>><br>> - a size of 1-2GB per build<br>><br>> - 4-6 builds rotated per release<br>><br>> - 3-4 releases<br>><br>><br>><br>> At worst you are looking at 48GB not 360GB. Dont worry so much there!<br>><br>><br>> total size will be approximately be 360GB in the worst case, and 120GB in<br>> the best case, which seems a bit more reasonable.<br>><br>> Thanks for he clarifications<br>><br>><br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171020/cf0cab70/attachment-0001.html><br><br>------------------------------<br><br>Message: 43<br>Date: Sat, 21 Oct 2017 01:00:10 -0600<br>From: Diana Clarke <diana.joan.clarke@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: Re: [openstack-dev] [tc][election] Question for candidates:<br>    How do you think we can make our community more inclusive?<br>Message-ID:<br>    <CAEZAPrCiNHTN96-9U6O67O_ikf-aX4vPgBFjCRWRGfSPiF-Bug@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>Congrats on being elected to the TC, Colleen!<br><br>You mentioned earlier in this thread that, "a major problem in the<br>tech world is not just attracting underrepresented contributors, but<br>retaining them".<br><br>I'm curious if the TC has considered polling the people that have left<br>OpenStack for their experiences on this front.<br><br>Something along the lines of:<br><br>    "I see you contributed 20 patches in the last cycle, but haven't<br>contributed recently, why did you stop contributing?".<br><br>Given the recent layoffs, I suspect many of the responses will be<br>predicable, but you might find some worthwhile nuggets there<br>nonetheless.<br><br>Congrats again,<br><br>--diana<br><br>On Sun, Oct 15, 2017 at 3:38 AM, Colleen Murphy <colleen@gazlene.net> wrote:<br>> A major problem in the tech world is not just attracting underrepresented<br>> contributors, but retaining them. They leave their communities or careers<br>> because of bias problems. To my knowledge, that doesn't happen in OpenStack,<br>> but just because I can't see it doesn't mean it's not there. A long-term<br>> study of participation by underrepresented demographics will help us answer<br>> this and fix it if necessary.<br><br><br><br>------------------------------<br><br>Message: 44<br>Date: Sat, 21 Oct 2017 15:40:49 +0800<br>From: Fred Li <yongle.li@gmail.com><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] OpenStack Bug Smash for Queens<br>Message-ID:<br>    <CAC0=-7WKWcL_+K3SNiL2bqRL_TMK3PMLa7uuP8eq=vMAJ1r6Sw@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>Hi all OpenStackers,<br><br>Since April 2015, there have been 6 OpenStack Bug Smash events in<br>China. OpenStack Bug Smash has been a routine and exciting event by<br>OpenStacker expects. In the past 5 bug smashes, over 300 top<br>developers from many companies(Huawei,Intel,CMCC, IBM, Mirantis,<br>Awcloud, 99cloud, UnitedStack, EasyStack, LeTV, ZTE, and etc.)<br>contributed 600+ bugs to community. This achievement significantly<br>demonstrated the technical strength of Chinese engineers. Huawei,<br>Intel and those companies show the commitment of OpenStack Stability<br>to enterprise customers.<br><br>Now, the 7th OpenStack bug smash is coming. Intel, Huawei, Fiberhome<br>and CESI will host this event. Intel, Huawei and Fiberhome are all<br>OpenStack members[1].<br>Come to join other OpenStackers to make Queens a grand success!<br>Come to learn tips and gain a better understanding by working closely<br>with other talents.<br>Each focused project will have a core on standby to review patches and<br>vote for merges.<br><br>Queens Bug SmashObject: smash the critical and high bugs in key<br>projects. Focused projects: Nova, Neutron, Cinder, Keystone, Manila,<br>Heat, Telemetry, Karbor, Tricircle, and the ones you want to add.<br><br>To all the projects team leaders, you can discuss with your team<br>members in the project meeting and mark the bugs you expect OpenStack<br>Bug Smash Queens to fix. If you can arrange core reviewers to take<br>care of the patches during that week, that will be more efficient.<br><br>Date: from Nov 22 to Nov 24, which is 2 weeks prior to Queens-2 milestone[2].<br><br>Location: 中国湖北省武汉市洪山区邮科院路88号,烽火创新谷武汉国际创客中心五楼一号会议室 [3]<br><br><br>Please start to register in [4].<br>And start to list the bugs to be fixed in [5].<br><br>[1] https://www.openstack.org/foundation/companies/<br>[2] https://releases.openstack.org/queens/schedule.html<br>[3] https://www.google.co.jp/maps/place/88+You+Ke+Yuan+Lu,+GuangGu+ShangQuan,+Hongshan+Qu,+Wuhan+Shi,+Hubei+Sheng,+China,+430073/@30.5107646,114.392814,17z/data=!3m1!4b1!4m5!3m4!1s0x342ea4ce1537ed17:0x52ff45d6b5dba38c!8m2!3d30.51076!4d114.395008?hl=en<br>[4] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Queens-Wuhan<br>[5] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Queens-Wuhan-Bugs-List<br><br><br>Regards<br>Fred Li (李永乐)<br><br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>OpenStack-dev mailing list<br>OpenStack-dev@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br>------------------------------<br><br>End of OpenStack-dev Digest, Vol 66, Issue 36<br>*********************************************<br></div></div></div></div><p><br></p> </div>