<div dir="ltr"><div class="gmail_default"><font face="monospace, monospace"><a href="mailto:1392607554@qq.com">1392607554@qq.com</a> is zhubingbing, he configured him mail client in a wrong.</font><br></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">So this vote is valid. ;)</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 12, 2017 at 12:36 AM, Steven Dake (stdake) <span dir="ltr"><<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_7732361823907893273WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Hello,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I’m not sure who
<a href="mailto:1392607554@qq.com" target="_blank">1392607554@qq.com</a> is. Could you identify yourself please for the mailing list? Note only core reviewers may vote on core reviewer nominations and you may be a core reviewer, so as I core reviewer, I want to verify you
are indeed a core reviewer such that your vote is counted. I think I know who you are, but I am not certain.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Thanks<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">-steve<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<blockquote style="border:none;border-left:solid #b5c4df 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in">
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">1392607554 <<a href="mailto:1392607554@qq.com" target="_blank">1392607554@qq.com</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
<b>Date: </b>Wednesday, March 8, 2017 at 8:49 PM<br>
<b>To: </b>OpenStack-dev-request <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [kolla] Proposing duonghq for core<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">+1<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial Narrow"">------------------ Original --<wbr>----------------<u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="background:#efefef"><b><span style="font-size:9.0pt">From:
</span></b><span style="font-size:9.0pt"> "OpenStack-dev-request";<<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">open<wbr>stack-dev-request@lists.<wbr>openstack.org</a>>;<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:#efefef"><b><span style="font-size:9.0pt">Date:
</span></b><span style="font-size:9.0pt"> Thu, Mar 9, 2017 03:25 AM<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:#efefef"><b><span style="font-size:9.0pt">To:
</span></b><span style="font-size:9.0pt"> "openstack-dev"<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-<wbr>dev@lists.openstack.org</a>>;
<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:#efefef"><b><span style="font-size:9.0pt">Subject:
</span></b><span style="font-size:9.0pt"> OpenStack-dev Digest, Vol 59, Issue 24<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<wbr>org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.<wbr>openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org" target="_blank">openstack-dev-owner@lists.<wbr>openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. [acceleration] No team meeting today, resume next Wed<br>
(Zhipeng Huang)<br>
2. Re: [ironic] OpenStack client default ironic API version<br>
(Dmitry Tantsur)<br>
3. Re: [release][tripleo][fuel][<wbr>kolla][ansible] Ocata Release<br>
countdown for R+2 Week, 6-10 March (Doug Hellmann)<br>
4. Re: [tc][appcat][murano][app-<wbr>catalog] The future of the App<br>
Catalog (Ian Cordasco)<br>
5. Re: [telemetry][requirements] ceilometer grenade gate failure<br>
(gordon chung)<br>
6. Re: [acceleration] No team meeting today, resume next Wed<br>
(Harm Sluiman)<br>
7. [trove] today weekly meeting (Amrith Kumar)<br>
8. Re: [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud<br>
archive ocata repo bust (Corey Bryant)<br>
9. Re: [ironic] OpenStack client default ironic API version<br>
(Mario Villaplana)<br>
10. [neutron] [infra] Depends-on tag effect (Hirofumi Ichihara)<br>
11. Re: [nova] Question to clarify versioned notifications<br>
(Matt Riedemann)<br>
12. Re: [neutron] [infra] Depends-on tag effect (ZZelle)<br>
13. Re: [tc][appcat] The future of the App Catalog (Jay Pipes)<br>
14. [nova][placement-api] Is there any document about<br>
openstack-placement-api for installation and configure? (Yu Wei)<br>
15. Re: [neutron] [infra] Depends-on tag effect (Andreas Jaeger)<br>
16. Re: [TripleO][Heat] Selectively disabling deployment<br>
resources (James Slagle)<br>
17. [ironic] Pike PTG report (Dmitry Tantsur)<br>
18. Re: [nova][placement-api] Is there any document about<br>
openstack-placement-api for installation and configure? (Chris Dent)<br>
19. [cinder][glance][horizon][<wbr>keystone][nova][qa][swift] Feedback<br>
needed: Removal of legacy per-project vanity domain redirects<br>
(Monty Taylor)<br>
20. Re: [nova][placement-api] Is there any document about<br>
openstack-placement-api for installation and configure? (Yu Wei)<br>
21. Re: [nova][placement-api] Is there any document about<br>
openstack-placement-api for installation and configure? (Chris Dent)<br>
22. Re: [neutron] [infra] Depends-on tag effect (Hirofumi Ichihara)<br>
23. Re: [cinder][glance][horizon][<wbr>keystone][nova][qa][swift]<br>
Feedback needed: Removal of legacy per-project vanity domain<br>
redirects (Lance Bragstad)<br>
24. Re: [nova][placement-api] Is there any document about<br>
openstack-placement-api for installation and configure? (Yu Wei)<br>
25. Re: [puppet] puppet-cep beaker test (Scheglmann, Stefan)<br>
26. Re: [puppet] puppet-cep beaker test (Alex Schultz)<br>
27. Re: [tc][appcat] The future of the App Catalog<br>
(David Moreau Simard)<br>
28. Re: [cinder][glance][horizon][<wbr>keystone][nova][qa][swift]<br>
Feedback needed: Removal of legacy per-project vanity domain<br>
redirects (Brian Rosmaita)<br>
29. Re: [nova][placement-api] Is there any document about<br>
openstack-placement-api for installation and configure? (Chris Dent)<br>
30. Re: [cinder][glance][horizon][<wbr>keystone][nova][qa][swift]<br>
Feedback needed: Removal of legacy per-project vanity domain<br>
redirects (Daniel P. Berrange)<br>
31. Re: [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud<br>
archive ocata repo bust (Jeffrey Zhang)<br>
32. Re: [TripleO][Heat] Selectively disabling deployment<br>
resources (James Slagle)<br>
33. Re: [neutron] [infra] Depends-on tag effect (Armando M.)<br>
34. Re: [ironic] OpenStack client default ironic API version<br>
(Jim Rollenhagen)<br>
35. Re: [tc][appcat] The future of the App Catalog (Fox, Kevin M)<br>
36. Re: [kolla] Proposing duonghq for core (Kwasniewska, Alicja)<br>
37. Re: [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud<br>
archive ocata repo bust (Corey Bryant)<br>
38. Re: [infra][tripleo] initial discussion for a new periodic<br>
pipeline (Jeremy Stanley)<br>
39. [requirements] pycrypto is dead, long live pycryptodome... or<br>
cryptography... (Matthew Thode)<br>
40. Re: [cinder][glance][horizon][<wbr>keystone][nova][qa][swift]<br>
Feedback needed: Removal of legacy per-project vanity domain<br>
redirects (Andreas Jaeger)<br>
41. [kolla] kolla 4.0.0.0rc2 (ocata) (<a href="mailto:no-reply@openstack.org" target="_blank">no-reply@openstack.org</a>)<br>
42. Re: [requirements] pycrypto is dead, long live<br>
pycryptodome... or cryptography... (Davanum Srinivas)<br>
43. [kolla] kolla-ansible 4.0.0.0rc2 (ocata) (<a href="mailto:no-reply@openstack.org" target="_blank">no-reply@openstack.org</a>)<br>
44. Re: [cinder][glance][horizon][<wbr>keystone][nova][qa][swift]<br>
Feedback needed: Removal of legacy per-project vanity domain<br>
redirects (Steve Martinelli)<br>
45. Re: [requirements] pycrypto is dead, long live<br>
pycryptodome... or cryptography... (Matthew Thode)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Wed, 8 Mar 2017 20:22:29 +0800<br>
From: Zhipeng Huang <<a href="mailto:zhipengh512@gmail.com" target="_blank">zhipengh512@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] [acceleration] No team meeting today, resume<br>
next Wed<br>
Message-ID:<br>
<CAHZqm+VCPs-yU5_<wbr>EQp41VS4Pm2Va9pqe4nuOK=<a href="mailto:r5cLnuxLLuSg@mail.gmail.com" target="_blank">r5cLnux<wbr>LLuSg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi team,<br>
<br>
As agreed per our PTG/VTG session, we will have the team meeting two weeks<br>
after to give people enough time to prepare the BPs we discussed.<br>
<br>
Therefore there will be no team meeting today, and the next meeting is on<br>
next Wed.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/813cb6b7/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/813cb6b7/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 8 Mar 2017 13:40:37 +0100<br>
From: Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: Re: [openstack-dev] [ironic] OpenStack client default ironic<br>
API version<br>
Message-ID: <<a href="mailto:f33ad8bf-73ef-bfe6-61d4-7f6ec03f8758@redhat.com" target="_blank">f33ad8bf-73ef-bfe6-61d4-<wbr>7f6ec03f8758@redhat.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 03/07/2017 04:59 PM, Loo, Ruby wrote:<br>
> On 2017-03-06, 3:46 PM, "Mario Villaplana" <<a href="mailto:mario.villaplana@gmail.com" target="_blank">mario.villaplana@gmail.com</a>> wrote:<br>
><br>
> Hi ironic,<br>
><br>
> At the PTG, an issue regarding the default version of the ironic API<br>
> used in our python-openstackclient plugin was discussed. [0] In short,<br>
> the issue is that we default to a very old API version when the user<br>
> doesn't otherwise specify it. This limits discoverability of new<br>
> features and makes the client more difficult to use for deployments<br>
> running the latest version of the code.<br>
><br>
> We came to the following consensus:<br>
><br>
> 1. For a deprecation period, we should log a warning whenever the user<br>
> doesn't specify an API version, informing them of this change.<br>
><br>
> 2. After the deprecation period:<br>
><br>
> a) OSC baremetal plugin will default to the latest available version<br>
><br>
> I think OSC and ironic CLI have the same behaviour -- are we only interested in OSC or are we interested in both, except that we also want to at some point soon perhaps, deprecate ironic CLI?<br>
<br>
I think we should only touch OSC, because of planned deprecation you mention.<br>
<br>
><br>
> Also, by 'latest available version', the OSC plugin knows (or thinks it knows) what the latest version is [1]. Will you be using that, or 'latest'?<br>
<br>
It will pass "latest" to the API, so it may end up with a version the client <br>
side does not know about. This is intended, I think. It does have some <br>
consequences if we make breaking changes like removing parameters. As we're not <br>
overly keen on breaking changes anyway, this may not be a huge concern.<br>
<br>
><br>
> b) Specifying just macroversion will default to latest microversion<br>
> within that macroversion (example: --os-baremetal-api-version=1 would<br>
> default to 1.31 if 1.31 is the last microversion with 1 macroversion,<br>
> even if we have API 2.2 supported)<br>
><br>
> I have a patch up for review with the deprecation warning:<br>
> <a href="https://review.openstack.org/442153" target="_blank">https://review.openstack.org/<wbr>442153</a><br>
><br>
> Do you have an RFE? I'd like a spec for this too please.<br>
<br>
Dunno if this change really requires a spec, but if you want one - let's have one :)<br>
<br>
We should have an RFE anyway, obviously.<br>
<br>
><br>
> Please comment on that patch with any concerns.<br>
><br>
> We also still have yet to decide what a suitable deprecation period is<br>
> for this change, as far as I'm aware. Please respond to this email<br>
> with any suggestions on the deprecation period.<br>
><br>
> Thanks,<br>
> Mario<br>
><br>
><br>
> [0] <a href="https://etherpad.openstack.org/p/ironic-pike-ptg-operations" target="_blank">https://etherpad.openstack.<wbr>org/p/ironic-pike-ptg-<wbr>operations</a> L30<br>
><br>
> Thank YOU!<br>
><br>
> --ruby<br>
><br>
> [1] <a href="https://github.com/openstack/python-ironicclient/blob/f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L29" target="_blank">https://github.com/openstack/<wbr>python-ironicclient/blob/<wbr>f242c6af3b295051019aeabb4ec7cf<wbr>82eb085874/ironicclient/osc/<wbr>plugin.py#L29</a><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 08 Mar 2017 07:52:23 -0500<br>
From: Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>><br>
To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [release][tripleo][fuel][<wbr>kolla][ansible]<br>
Ocata Release countdown for R+2 Week, 6-10 March<br>
Message-ID: <1488977242-sup-5435@lrrr.<wbr>local><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Excerpts from Vladimir Kuklin's message of 2017-03-08 01:20:21 +0300:<br>
> Doug<br>
> <br>
> I have proposed the change for Fuel RC2 [0], but it has W-1 set as I am<br>
> waiting for the final tests result. If everything goes alright, I will<br>
> check the Worfklow off and this RC2 can be the cut as the release.<br>
<br>
I've approved the RC2 tag and prepared<br>
<a href="https://review.openstack.org/443116" target="_blank">https://review.openstack.org/<wbr>443116</a> with the final release tag. Please<br>
+1 if that looks OK. I will approve it tomorrow.<br>
<br>
Doug<br>
<br>
> <br>
> [0] <a href="https://review.openstack.org/#/c/442775/" target="_blank">https://review.openstack.org/#<wbr>/c/442775/</a><br>
> <br>
> On Tue, Mar 7, 2017 at 3:39 AM, Jeffrey Zhang <<a href="mailto:zhang.lei.fly@gmail.com" target="_blank">zhang.lei.fly@gmail.com</a>><br>
> wrote:<br>
> <br>
> > Sorry for late. But Kolla project need a new release candidate. I will<br>
> > push it today.<br>
> ><br>
> > On Tue, Mar 7, 2017 at 6:27 AM, Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>><br>
> > wrote:<br>
> ><br>
> >> Excerpts from Doug Hellmann's message of 2017-03-06 11:00:15 -0500:<br>
> >> > Excerpts from Doug Hellmann's message of 2017-03-02 18:24:12 -0500:<br>
> >> > ><br>
> >> > > Release Tasks<br>
> >> > > -------------<br>
> >> > ><br>
> >> > > Liaisons for cycle-trailing projects should prepare their final<br>
> >> > > release candidate tags by Monday 6 March. The release team will<br>
> >> > > prepare a patch showing the final release versions on Wednesday 7<br>
> >> > > March, and PTLs and liaisons for affected projects should +1. We<br>
> >> > > will then approve the final releases on Thursday 8 March.<br>
> >> ><br>
> >> > We have 13 cycle-trailing deliverables without final releases for Ocata.<br>
> >> > All have at least one release candidate, so if no new release candidates<br>
> >> > are proposed *today* I will prepare a patch using these versions as the<br>
> >> > final and we will approve that early Wednesday.<br>
> >> ><br>
> >> > If you know that you need a new release candidate, please speak up now.<br>
> >> ><br>
> >> > If you know that you do not need a new release candidate, please also<br>
> >> > let me know that.<br>
> >> ><br>
> >> > Thanks!<br>
> >> > Doug<br>
> >> ><br>
> >> > $ list-deliverables --series ocata --missing-final -v<br>
> >> > fuel fuel 11.0.0.0rc1 other<br>
> >> cycle-trailing<br>
> >> > instack-undercloud tripleo 6.0.0.0rc1 other<br>
> >> cycle-trailing<br>
> >> > kolla-ansible kolla 4.0.0.0rc1 other<br>
> >> cycle-trailing<br>
> >> > kolla kolla 4.0.0.0rc1 other<br>
> >> cycle-trailing<br>
> >> > openstack-ansible OpenStackAnsible 15.0.0.0rc1 other<br>
> >> cycle-trailing<br>
> >> > os-apply-config tripleo 6.0.0.0rc1 other<br>
> >> cycle-with-milestones<br>
> >> > os-cloud-config tripleo 6.0.0.0rc1 other<br>
> >> cycle-with-milestones<br>
> >> > os-collect-config tripleo 6.0.0.0rc1 other<br>
> >> cycle-with-milestones<br>
> >> > os-net-config tripleo 6.0.0.0rc1 other<br>
> >> cycle-with-milestones<br>
> >> > os-refresh-config tripleo 6.0.0.0rc1 other<br>
> >> cycle-with-milestones<br>
> >> > tripleo-heat-templates tripleo 6.0.0.0rc1 other<br>
> >> cycle-trailing<br>
> >> > tripleo-image-elements tripleo 6.0.0.0rc1 other<br>
> >> cycle-trailing<br>
> >> > tripleo-puppet-elements tripleo 6.0.0.0rc1 other<br>
> >> cycle-trailing<br>
> >> ><br>
> >><br>
> >> I have lined up patches with the final release tags for all 3 projects.<br>
> >> Please review and +1 or propose a new patch with an updated release<br>
> >> candidate.<br>
> >><br>
> >> Ansible: <a href="https://review.openstack.org/442138" target="_blank">https://review.openstack.org/<wbr>442138</a><br>
> >> Kolla: <a href="https://review.openstack.org/442137" target="_blank">https://review.openstack.org/<wbr>442137</a><br>
> >> TripleO: <a href="https://review.openstack.org/442129" target="_blank">https://review.openstack.org/<wbr>442129</a><br>
> >><br>
> >> Doug<br>
> >><br>
> >> ______________________________<wbr>______________________________<br>
> >> ______________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscrib" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscrib</a><br>
> >> e<br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> >><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Regards,<br>
> > Jeffrey Zhang<br>
> > Blog: <a href="http://xcodest.me" target="_blank">http://xcodest.me</a><br>
> ><br>
> > ______________________________<wbr>______________________________<wbr>______________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> ><br>
> ><br>
> <br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 8 Mar 2017 08:25:21 -0500<br>
From: Ian Cordasco <<a href="mailto:sigmavirus24@gmail.com" target="_blank">sigmavirus24@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [tc][appcat][murano][app-<wbr>catalog] The<br>
future of the App Catalog<br>
Message-ID:<br>
<CAORZOQZ-ZC4x9sd=E12v8+4Tj+<wbr>v6yoFnEJDWpc=<a href="mailto:bq4m3tSmefw@mail.gmail.com" target="_blank">bq4m3tSmefw@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
-----Original Message-----<br>
From:?Christopher Aedo <<a href="mailto:doc@aedo.net" target="_blank">doc@aedo.net</a>><br>
Reply:?OpenStack Development Mailing List (not for usage questions)<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Date:?March 7, 2017 at 22:11:22<br>
To:?OpenStack Development Mailing List (not for usage questions)<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject:? Re: [openstack-dev] [tc][appcat][murano][app-<wbr>catalog] The<br>
future of the App Catalog<br>
<br>
> On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez wrote:<br>
> > Hello everyone,<br>
> ><br>
> > The App Catalog was created early 2015 as a marketplace of pre-packaged<br>
> > applications that you can deploy using Murano. Initially a demo by<br>
> > Mirantis, it was converted into an open upstream project team, and<br>
> > deployed as a "beta" as <a href="http://apps.openstack.org" target="_blank">apps.openstack.org</a>.<br>
> ><br>
> > Since then it grew additional categories (Glance images, Heat & Tosca<br>
> > templates), but otherwise did not pick up a lot of steam. The website<br>
> > (still labeled "beta") features 45 glance images, 6 Tosca templates, 13<br>
> > heat templates and 94 murano packages (~30% of which are just thin<br>
> > wrappers around Docker containers). Traffic stats show around 100 visits<br>
> > per week, 75% of which only read the index page.<br>
> ><br>
> > In parallel, Docker developed a pretty successful containerized<br>
> > application marketplace (the Docker Hub), with hundreds of thousands of<br>
> > regularly-updated apps. Keeping the App Catalog around (including its<br>
> > thinly-wrapped Docker container Murano packages) make us look like we<br>
> > are unsuccessfully trying to compete with that ecosystem, while<br>
> > OpenStack is in fact completely complementary.<br>
><br>
> Without something like Murano "thinly wrapping" docker apps, how would<br>
> you propose current users of OpenStack clouds deploy docker apps? Or<br>
> any other app for that matter? It seems a little unfair to talk about<br>
> murano apps this way when no reasonable alternative exists for easily<br>
> deploying docker apps. When I look back at the recent history of how<br>
> we've handled containers (nova-docker, magnum, kubernetes, etc) it<br>
> does not seem like we're making it easy for the folks who want to<br>
> deploy a container on their cloud...<br>
><br>
> Please understand I am not pleading to keep the Community App Catalog<br>
> alive in perpetuity. This just sounds like an unfair point of<br>
> comparison. One of the biggest challenges we've faced with the app<br>
> catalog since day one is that there is no such thing as a simple<br>
> definition of an "OpenStack Application". OpenStack is an IaaS before<br>
> anything else, and to my knowledge there is no universally accepted<br>
> application deployment mechanism for OpenStack clouds. Heat doesn't<br>
> solve that problem as its very operator focused, and while being very<br>
> popular and used heavily, it's not used as a way to share generic<br>
> templates suitable for deploying apps across different clouds. Murano<br>
> is not widely adopted (last time I checked it's not available on any<br>
> public clouds, though I hear it is actually used on a several<br>
> university clouds, and it's also used on a few private clouds I'm<br>
> aware of.)<br>
><br>
> As a place to find things that run on OpenStack clouds, the app<br>
> catalog did a reasonable job. If anything, the experiment showed that<br>
> there is no community looking for a place to share OpenStack-specific<br>
> applications. There are definitely communities for PaaS layers (cloud<br>
> foundry, mesosphere, docker, kubernetes), but I don't see any<br>
> community for openstack-native applications that can be deployed on<br>
> any cloud, nor a commonly accepted way to deploy them.<br>
><br>
> > In the past we have retired projects that were dead upstream. The App<br>
> > Catalog is not in this case: it has an active maintenance team, which<br>
> > has been successfully maintaining the framework and accepting<br>
> > applications. If we end up retiring the App Catalog, it would clearly<br>
> > not be a reflection on that team performance, which has been stellar<br>
> > despite limited resources. It would be because the beta was arguably not<br>
> > successful in building an active marketplace of applications, and<br>
> > because its continuous existence is not a great fit from a strategy<br>
> > perspective. Such removal would be a first for our community, but I<br>
> > think it's now time to consider it.<br>
> ><br>
> > Before we discuss or decide anything at the TC level, I'd like to<br>
> > collect everyone thoughts (and questions) on this. Please feel free to<br>
> > reply to this thread (or reach out to me privately if you prefer). Thanks !<br>
><br>
> As the former PTL I am obviously a little bit biased. Even though my<br>
> focus has shifted and I've stepped away from the app catalog, I had<br>
> been spending a lot of time trying to figure out how to make<br>
> applications an easy to run thing on OpenStack. I've also been trying<br>
> to find a community of people who are looking for that, and it doesn't<br>
> seem like they've materialized; possibly because that community<br>
> doesn't exist? Or else we just haven't been able to figure out where<br>
> they're hiding ;)<br>
><br>
> The one consideration that is pretty important here is what this would<br>
> mean to the Murano community. Those folks have been contributed time<br>
> and resources to the app catalog project. They've also standardized<br>
> on the app catalog as the distribution mechanism, intending to make<br>
> the app catalog UI a native component for Murano. We do need to make<br>
> sure that if the app catalog is retired, it doesn't hamper or impact<br>
> people who have already deployed Murano and are counting on finding<br>
> the apps in the app catalog.<br>
<br>
All of this is true. But Murano still doesn't have a stable way to<br>
store artifacts. In fact, it seems like Murano relies on a lot of<br>
unstable OpenStack infrastructure. While lots of people have<br>
contributed time, energy, sweat, and tears to the project there are<br>
still plenty of things that make Murano less than desirable. Perhaps<br>
that's why the project has found so few adopters. I'm sure there are<br>
plenty of people who want to use an OpenStack cloud to deploy<br>
applications. In fact, I know there are companies that try to provide<br>
that kind of support via Heat templates. All that said, I don't think<br>
allowing for competition with Murano is a bad thing.<br>
<br>
--<br>
Ian Cordasco<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 8 Mar 2017 13:27:12 +0000<br>
From: gordon chung <<a href="mailto:gord@live.ca" target="_blank">gord@live.ca</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [telemetry][requirements] ceilometer<br>
grenade gate failure<br>
Message-ID:<br>
<<a href="mailto:BN6PR16MB1697E72DC578DC1FD8C24E6ADE2E0@BN6PR16MB1697.namprd16.prod.outlook.com" target="_blank">BN6PR16MB1697E72DC578DC1FD8C2<wbr>4E6ADE2E0@BN6PR16MB1697.<wbr>namprd16.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
<br>
<br>
On 07/03/17 11:16 PM, Tony Breeds wrote:<br>
> Sure.<br>
><br>
> I've approved it but it's blocked behind <a href="https://review.openstack.org/#/c/442886/1" target="_blank">https://review.openstack.org/#<wbr>/c/442886/1</a><br>
<br>
awesome! thanks Tony!<br>
<br>
cheers,<br>
<br>
-- <br>
gord<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 8 Mar 2017 09:01:00 -0500<br>
From: Harm Sluiman <<a href="mailto:harm.sluiman@gmail.com" target="_blank">harm.sluiman@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [acceleration] No team meeting today,<br>
resume next Wed<br>
Message-ID: <<a href="mailto:DC117932-5897-4A7F-B521-522E06D2115F@gmail.com" target="_blank">DC117932-5897-4A7F-B521-<wbr>522E06D2115F@gmail.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Thanks for the update. Unfortunately I could not attend and can't seem to find a summary or anything about what took place. A pointer would be appreciated please ;-)<br>
<br>
Thanks for your time<br>
Harm Sluiman<br>
<a href="mailto:harm.sluiman@gmail.com" target="_blank">harm.sluiman@gmail.com</a><br>
<br>
<br>
> On Mar 8, 2017, at 7:22 AM, Zhipeng Huang <<a href="mailto:zhipengh512@gmail.com" target="_blank">zhipengh512@gmail.com</a>> wrote:<br>
> <br>
> Hi team,<br>
> <br>
> As agreed per our PTG/VTG session, we will have the team meeting two weeks after to give people enough time to prepare the BPs we discussed.<br>
> <br>
> Therefore there will be no team meeting today, and the next meeting is on next Wed.<br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 8 Mar 2017 09:03:21 -0500<br>
From: "Amrith Kumar" <<a href="mailto:amrith.kumar@gmail.com" target="_blank">amrith.kumar@gmail.com</a>><br>
To: <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] [trove] today weekly meeting<br>
Message-ID: <00bf01d29814$bf3fe810$<wbr>3dbfb830$@<a href="http://gmail.com" target="_blank">gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
While I try to schedule my life to not conflict with the weekly Trove<br>
meeting, it appears that Wednesday afternoon at 1pm is a particularly<br>
popular time for people to want to meet me.<br>
<br>
<br>
<br>
This week, and next week are no exception. While I'd tried to avoid these<br>
conflicts, I've managed to be unable to do it (again).<br>
<br>
<br>
<br>
Nikhil (slicknik) has kindly agreed to run the meeting today, same place,<br>
same time as always.<br>
<br>
<br>
<br>
Thanks Nikhil.<br>
<br>
<br>
<br>
-amrith<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/f20b7aec/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/f20b7aec/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Wed, 8 Mar 2017 09:03:27 -0500<br>
From: Corey Bryant <<a href="mailto:corey.bryant@canonical.com" target="_blank">corey.bryant@canonical.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Cc: openstack <<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><wbr>><br>
Subject: Re: [openstack-dev] [kolla][ubuntu][libvirt] Is libvirt 2.5.0<br>
in ubuntu cloud archive ocata repo bust<br>
Message-ID:<br>
<<a href="mailto:CADn0iZ2udvnhnDiwFSG90frHBncCFN6X0ZwBvXRTCFpoh2_reg@mail.gmail.com" target="_blank">CADn0iZ2udvnhnDiwFSG90frHBncC<wbr>FN6X0ZwBvXRTCFpoh2_reg@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Tue, Mar 7, 2017 at 10:28 PM, Jeffrey Zhang <<a href="mailto:zhang.lei.fly@gmail.com" target="_blank">zhang.lei.fly@gmail.com</a>><br>
wrote:<br>
<br>
> Kolla deploy ubuntu gate is red now. here is the related bug[0].<br>
><br>
> libvirt failed to access the console.log file when booting instance. After<br>
> made some debugging, i got following.<br>
><br>
><br>
Jeffrey, This is likely fixed in ocata-proposed and should be promoted to<br>
ocata-updates soon after testing completes.<br>
<a href="https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1667033" target="_blank">https://bugs.launchpad.net/<wbr>ubuntu/+source/libvirt/+bug/<wbr>1667033</a>.<br>
<br>
Corey<br>
<br>
<br>
# how console.log works<br>
> nova create a empty console.log with nova:nova ( this is another bug<br>
> workaround actually[1]), then libvirt ( running with root ) will change the<br>
> file owner to qemu process user/group ( configured by dynamic_ownership ).<br>
> Now qemu process can write logs into this file.<br>
><br>
> # what's wrong now<br>
> libvirt 2.5.0 stop change the file owner, then qemu/libvirt failed to write<br>
> logs into console.log file<br>
><br>
> # other test<br>
><br>
> * ubuntu + fallback libvirt 1.3.x works [2]<br>
> * ubuntu + libvirt 2.5.0 + chang the qemu process user/group to<br>
> nova:nova works, too.[3]<br>
> * centos + libvirt 2.0.0 works, never saw such issue in centos.<br>
><br>
> # conclusion<br>
> I guess there are something wrong in libvirt 2.5.0 with dynamic_ownership<br>
><br>
><br>
> [0] <a href="https://bugs.launchpad.net/kolla-ansible/+bug/1668654" target="_blank">https://bugs.launchpad.net/<wbr>kolla-ansible/+bug/1668654</a><br>
> [1] <a href="https://github.com/openstack/nova/blob/master/" target="_blank">https://github.com/openstack/<wbr>nova/blob/master/</a><br>
> nova/virt/libvirt/driver.py#<wbr>L2922,L2952<br>
> [2] <a href="https://review.openstack.org/442673" target="_blank">https://review.openstack.org/<wbr>442673</a><br>
> [3] <a href="https://review.openstack.org/442850" target="_blank">https://review.openstack.org/<wbr>442850</a><br>
><br>
> --<br>
> Regards,<br>
> Jeffrey Zhang<br>
> Blog: <a href="http://xcodest.me" target="_blank">http://xcodest.me</a><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/d6d12817/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/d6d12817/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Wed, 8 Mar 2017 09:05:07 -0500<br>
From: Mario Villaplana <<a href="mailto:mario.villaplana@gmail.com" target="_blank">mario.villaplana@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [ironic] OpenStack client default ironic<br>
API version<br>
Message-ID:<br>
<CAHii5L4CVPRz=g==<a href="mailto:5rQHp_Nq6i_LNZbfCKEFGq_dhjjqytmt3Q@mail.gmail.com" target="_blank">5rQHp_Nq6i_<wbr>LNZbfCKEFGq_dhjjqytmt3Q@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
We want to deprecate ironic CLI soon, but I would prefer if that were<br>
discussed on a separate thread if possible, aside from concerns about<br>
versioning in ironic CLI. Feature parity should exist in Pike, then we<br>
can issue a warning in Queens and deprecate the cycle after. More<br>
information is on L56:<br>
<a href="https://etherpad.openstack.org/p/ironic-pike-ptg-operations" target="_blank">https://etherpad.openstack.<wbr>org/p/ironic-pike-ptg-<wbr>operations</a><br>
<br>
I'm a bit torn on whether to use the API version coded in the OSC<br>
plugin or not. On one hand, it'd be good to be able to test out new<br>
features as soon as they're available. On the other hand, it's<br>
possible that the client won't know how to parse certain items after a<br>
microversion bump. I think I prefer using the hard-coded version to<br>
avoid breakage, but we'd have to be disciplined about updating the<br>
client when the API version is bumped (if needed). Opinions on this<br>
are welcome. In either case, I think the deprecation warning could<br>
land without specifying that.<br>
<br>
I'll certainly make an RFE when I update the patch later this week,<br>
great suggestion.<br>
<br>
I can make a spec, but it might be mostly empty except for the client<br>
impact section. Also, this is a < 40 line change. :)<br>
<br>
Mario<br>
<br>
On Tue, Mar 7, 2017 at 10:59 AM, Loo, Ruby <<a href="mailto:ruby.loo@intel.com" target="_blank">ruby.loo@intel.com</a>> wrote:<br>
> On 2017-03-06, 3:46 PM, "Mario Villaplana" <<a href="mailto:mario.villaplana@gmail.com" target="_blank">mario.villaplana@gmail.com</a>> wrote:<br>
><br>
> Hi ironic,<br>
><br>
> At the PTG, an issue regarding the default version of the ironic API<br>
> used in our python-openstackclient plugin was discussed. [0] In short,<br>
> the issue is that we default to a very old API version when the user<br>
> doesn't otherwise specify it. This limits discoverability of new<br>
> features and makes the client more difficult to use for deployments<br>
> running the latest version of the code.<br>
><br>
> We came to the following consensus:<br>
><br>
> 1. For a deprecation period, we should log a warning whenever the user<br>
> doesn't specify an API version, informing them of this change.<br>
><br>
> 2. After the deprecation period:<br>
><br>
> a) OSC baremetal plugin will default to the latest available version<br>
><br>
> I think OSC and ironic CLI have the same behaviour -- are we only interested in OSC or are we interested in both, except that we also want to at some point soon perhaps, deprecate ironic CLI?<br>
><br>
> Also, by 'latest available version', the OSC plugin knows (or thinks it knows) what the latest version is [1]. Will you be using that, or 'latest'?<br>
><br>
> b) Specifying just macroversion will default to latest microversion<br>
> within that macroversion (example: --os-baremetal-api-version=1 would<br>
> default to 1.31 if 1.31 is the last microversion with 1 macroversion,<br>
> even if we have API 2.2 supported)<br>
><br>
> I have a patch up for review with the deprecation warning:<br>
> <a href="https://review.openstack.org/442153" target="_blank">https://review.openstack.org/<wbr>442153</a><br>
><br>
> Do you have an RFE? I'd like a spec for this too please.<br>
><br>
> Please comment on that patch with any concerns.<br>
><br>
> We also still have yet to decide what a suitable deprecation period is<br>
> for this change, as far as I'm aware. Please respond to this email<br>
> with any suggestions on the deprecation period.<br>
><br>
> Thanks,<br>
> Mario<br>
><br>
><br>
> [0] <a href="https://etherpad.openstack.org/p/ironic-pike-ptg-operations" target="_blank">https://etherpad.openstack.<wbr>org/p/ironic-pike-ptg-<wbr>operations</a> L30<br>
><br>
> Thank YOU!<br>
><br>
> --ruby<br>
><br>
> [1] <a href="https://github.com/openstack/python-ironicclient/blob/f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L29" target="_blank">https://github.com/openstack/<wbr>python-ironicclient/blob/<wbr>f242c6af3b295051019aeabb4ec7cf<wbr>82eb085874/ironicclient/osc/<wbr>plugin.py#L29</a><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Wed, 8 Mar 2017 23:16:54 +0900<br>
From: Hirofumi Ichihara <<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.<wbr>jp</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: [openstack-dev] [neutron] [infra] Depends-on tag effect<br>
Message-ID: <<a href="mailto:00bc73ee-06bc-76e2-ea11-dd0b0a321314@lab.ntt.co.jp" target="_blank">00bc73ee-06bc-76e2-ea11-<wbr>dd0b0a321314@lab.ntt.co.jp</a>><br>
Content-Type: text/plain; charset=iso-2022-jp; format=flowed;<br>
delsp=yes<br>
<br>
Hi,<br>
<br>
I thought that we can post neutron patch depending on neutron-lib patch <br>
under review.<br>
However, I saw it doesn't work[1, 2]. In the patches, neutron patch[1] <br>
has Depends-on tag with neutron-lib patch[2] but the pep8 and unit test <br>
fails because the test doesn't use the neutron-lib patch.<br>
<br>
Please correct me if it's my misunderstanding.<br>
<br>
[1]: <a href="https://review.openstack.org/#/c/424340/" target="_blank">https://review.openstack.org/#<wbr>/c/424340/</a><br>
[2]: <a href="https://review.openstack.org/#/c/424868/" target="_blank">https://review.openstack.org/#<wbr>/c/424868/</a><br>
<br>
Thanks,<br>
Hirofumi<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Wed, 8 Mar 2017 08:33:16 -0600<br>
From: Matt Riedemann <<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: Re: [openstack-dev] [nova] Question to clarify versioned<br>
notifications<br>
Message-ID: <<a href="mailto:3e95e057-b332-6c65-231b-f26001f6d5a8@gmail.com" target="_blank">3e95e057-b332-6c65-231b-<wbr>f26001f6d5a8@gmail.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 3/8/2017 4:19 AM, Balazs Gibizer wrote:<br>
><br>
> Honestly, If searchlight needs to be adapted to the versioned<br>
> notifications then the smallest thing to change is to handle the removed<br>
> prefix from the event_type. The biggest difference is the format and the<br>
> content of the payload. In the legacy notifications the payload was a<br>
> simply json dict in the versioned notification the payload is a json<br>
> serialized ovo. Which means quite a different data structure. E.g. extra<br>
> keys, deeper nesting, etc.<br>
><br>
> Cheers,<br>
> gibi<br>
><br>
<br>
Heh, yeah, I agree. Thanks for the confirmation and details. I was just <br>
making sure I had this all straight since I was jumping around from <br>
specs and docs and code quite a bit yesterday piecing this together and <br>
wanted to make sure I had it straight. Plus you don't apparently work 20 <br>
hours a day gibi so I couldn't ask you in IRC. :)<br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Wed, 8 Mar 2017 15:40:53 +0100<br>
From: ZZelle <<a href="mailto:zzelle@gmail.com" target="_blank">zzelle@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron] [infra] Depends-on tag effect<br>
Message-ID:<br>
<CAMS-<wbr>DWhB3PWdoCLFsOx5ss7eYSa7dMsWr-<wbr>6+R=<a href="mailto:FuOmDMGjvaYw@mail.gmail.com" target="_blank">FuOmDMGjvaYw@mail.gmail.<wbr>com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
iiuc, neutron uses a released version of neutron-lib not neutron-lib master<br>
... So the change should depends on a change in requirements repo<br>
incrementing neutron-lib version<br>
<br>
On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara <<br>
<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.<wbr>jp</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> I thought that we can post neutron patch depending on neutron-lib patch<br>
> under review.<br>
> However, I saw it doesn't work[1, 2]. In the patches, neutron patch[1] has<br>
> Depends-on tag with neutron-lib patch[2] but the pep8 and unit test fails<br>
> because the test doesn't use the neutron-lib patch.<br>
><br>
> Please correct me if it's my misunderstanding.<br>
><br>
> [1]: <a href="https://review.openstack.org/#/c/424340/" target="_blank">https://review.openstack.org/#<wbr>/c/424340/</a><br>
> [2]: <a href="https://review.openstack.org/#/c/424868/" target="_blank">https://review.openstack.org/#<wbr>/c/424868/</a><br>
><br>
> Thanks,<br>
> Hirofumi<br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/64fe77fc/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/64fe77fc/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Wed, 8 Mar 2017 09:41:05 -0500<br>
From: Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: Re: [openstack-dev] [tc][appcat] The future of the App<br>
Catalog<br>
Message-ID: <<a href="mailto:c8147907-6d4b-6bac-f9b3-6b8b07d75494@gmail.com" target="_blank">c8147907-6d4b-6bac-f9b3-<wbr>6b8b07d75494@gmail.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 03/06/2017 06:26 AM, Thierry Carrez wrote:<br>
> Hello everyone,<br>
><br>
> The App Catalog was created early 2015 as a marketplace of pre-packaged<br>
> applications that you can deploy using Murano. Initially a demo by<br>
> Mirantis, it was converted into an open upstream project team, and<br>
> deployed as a "beta" as <a href="http://apps.openstack.org" target="_blank">apps.openstack.org</a>.<br>
><br>
> Since then it grew additional categories (Glance images, Heat & Tosca<br>
> templates), but otherwise did not pick up a lot of steam. The website<br>
> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13<br>
> heat templates and 94 murano packages (~30% of which are just thin<br>
> wrappers around Docker containers). Traffic stats show around 100 visits<br>
> per week, 75% of which only read the index page.<br>
><br>
> In parallel, Docker developed a pretty successful containerized<br>
> application marketplace (the Docker Hub), with hundreds of thousands of<br>
> regularly-updated apps. Keeping the App Catalog around (including its<br>
> thinly-wrapped Docker container Murano packages) make us look like we<br>
> are unsuccessfully trying to compete with that ecosystem, while<br>
> OpenStack is in fact completely complementary.<br>
><br>
> In the past we have retired projects that were dead upstream. The App<br>
> Catalog is not in this case: it has an active maintenance team, which<br>
> has been successfully maintaining the framework and accepting<br>
> applications. If we end up retiring the App Catalog, it would clearly<br>
> not be a reflection on that team performance, which has been stellar<br>
> despite limited resources. It would be because the beta was arguably not<br>
> successful in building an active marketplace of applications, and<br>
> because its continuous existence is not a great fit from a strategy<br>
> perspective. Such removal would be a first for our community, but I<br>
> think it's now time to consider it.<br>
><br>
> Before we discuss or decide anything at the TC level, I'd like to<br>
> collect everyone thoughts (and questions) on this. Please feel free to<br>
> reply to this thread (or reach out to me privately if you prefer). Thanks !<br>
<br>
Mirantis' position is that the App Catalog was a good idea, but we agree <br>
with you that other application repositories like DockerHub and Quay.io <br>
are both more useful and more actively used.<br>
<br>
The OpenStack App Catalog does indeed seem to unnecessarily compete with <br>
those application repositories, and we would support its retirement if <br>
that is what the community would like to do. We'll provide resources and <br>
help in winding anything down if needed.<br>
<br>
Best,<br>
-jay<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Wed, 8 Mar 2017 14:59:41 +0000<br>
From: Yu Wei <<a href="mailto:yu2003w@hotmail.com" target="_blank">yu2003w@hotmail.com</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] [nova][placement-api] Is there any document<br>
about openstack-placement-api for installation and configure?<br>
Message-ID:<br>
<<a href="mailto:HK2PR03MB0561E869146E75415BAD8DFBB52E0@HK2PR03MB0561.apcprd03.prod.outlook.com" target="_blank">HK2PR03MB0561E869146E75415BAD<wbr>8DFBB52E0@HK2PR03MB0561.<wbr>apcprd03.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Guys,<br>
I'm new to openstack.<br>
I tried to install openstack-ocata.<br>
As placement-api is required since Ocata, is there any detailed document <br>
about how to install and configure placement-api?<br>
<br>
Thanks,<br>
Jared<br>
<br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Wed, 8 Mar 2017 15:59:59 +0100<br>
From: Andreas Jaeger <<a href="mailto:aj@suse.com" target="_blank">aj@suse.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron] [infra] Depends-on tag effect<br>
Message-ID: <<a href="mailto:c141c37b-53df-0983-5857-9980b6e2b16e@suse.com" target="_blank">c141c37b-53df-0983-5857-<wbr>9980b6e2b16e@suse.com</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
On 2017-03-08 15:40, ZZelle wrote:<br>
> Hi,<br>
> <br>
> iiuc, neutron uses a released version of neutron-lib not neutron-lib<br>
> master ... So the change should depends on a change in requirements repo<br>
> incrementing neutron-lib version<br>
<br>
This is documented also at - together with some other caveats:<br>
<br>
<a href="https://docs.openstack.org/infra/manual/developers.html#limitations-and-caveats" target="_blank">https://docs.openstack.org/<wbr>infra/manual/developers.html#<wbr>limitations-and-caveats</a><br>
<br>
<br>
Note a depends-on requirements won't work either - you really need to<br>
release it. Or you need to change the test to pull neutron-lib from source,<br>
<br>
Andreas<br>
> <br>
> On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara<br>
> <<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.<wbr>jp</a><br>
> <mailto:<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.<wbr>ntt.co.jp</a>>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> I thought that we can post neutron patch depending on neutron-lib<br>
> patch under review.<br>
> However, I saw it doesn't work[1, 2]. In the patches, neutron<br>
> patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8<br>
> and unit test fails because the test doesn't use the neutron-lib patch.<br>
> <br>
> Please correct me if it's my misunderstanding.<br>
> <br>
> [1]: <a href="https://review.openstack.org/#/c/424340/" target="_blank">https://review.openstack.org/#<wbr>/c/424340/</a><br>
> <<a href="https://review.openstack.org/#/c/424340/" target="_blank">https://review.openstack.org/<wbr>#/c/424340/</a>><br>
> [2]: <a href="https://review.openstack.org/#/c/424868/" target="_blank">https://review.openstack.org/#<wbr>/c/424868/</a><br>
> <<a href="https://review.openstack.org/#/c/424868/" target="_blank">https://review.openstack.org/<wbr>#/c/424868/</a>><br>
> <br>
> Thanks,<br>
> Hirofumi<br>
> <br>
> <br>
> <br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
> <br>
> <br>
> <br>
> <br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> <br>
<br>
<br>
-- <br>
Andreas Jaeger aj@{<a href="http://suse.com" target="_blank">suse.com</a>,<a href="http://opensuse.org" target="_blank">opensuse.org</a>} Twitter: jaegerandi<br>
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany<br>
GF: Felix Imend?rffer, Jane Smithard, Graham Norton,<br>
HRB 21284 (AG N?rnberg)<br>
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Wed, 8 Mar 2017 10:05:45 -0500<br>
From: James Slagle <<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [TripleO][Heat] Selectively disabling<br>
deployment resources<br>
Message-ID:<br>
<<a href="mailto:CAHV77z-JdSvgfUc7RORCXmz13kcRGR5u2grtX%2BMyZR-dPKV0Ug@mail.gmail.com" target="_blank">CAHV77z-<wbr>JdSvgfUc7RORCXmz13kcRGR5u2grtX<wbr>+MyZR-dPKV0Ug@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Tue, Mar 7, 2017 at 7:24 PM, Zane Bitter <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>> wrote:<br>
> On 07/03/17 14:34, James Slagle wrote:<br>
>><br>
>> I've been working on this spec for TripleO:<br>
>> <a href="https://review.openstack.org/#/c/431745/" target="_blank">https://review.openstack.org/#<wbr>/c/431745/</a><br>
>><br>
>> which allows users to selectively disable Heat deployment resources<br>
>> for a given server (or server in the case of a *DeloymentGroup<br>
>> resource).<br>
><br>
><br>
> I'm not completely clear on what this means. You can selectively disable<br>
> resources with conditionals. But I think you mean that you want to<br>
> selectively disable *changes* to resources?<br>
<br>
Yes, that's right. The reason I can't use conditionals is that I still<br>
want the SoftwareDeploymentGroup resources to be updated, but I may<br>
want to selectively exclude servers from the group that is passed in<br>
via the servers property. E.g., instead of updating the deployment<br>
metadata for *all* computes, I may want to exclude a single compute<br>
that is temporarily unreachable, without that failing the whole<br>
stack-update.<br>
<br>
>> I started by taking an approach that would be specific to TripleO.<br>
>> Basically mapping all the deployment resources to a nested stack<br>
>> containing the logic to selectively disable servers from the<br>
>> deployment (using yaql) based on a provided parameter value. Here's<br>
>> the main patch: <a href="https://review.openstack.org/#/c/442681/" target="_blank">https://review.openstack.org/#<wbr>/c/442681/</a><br>
>><br>
>> After considering that complexity, particularly the yaql expression,<br>
>> I'm wondering if it would be better to add this support natively to<br>
>> Heat.<br>
>><br>
>> I was looking at the restricted_actions key in the resource_registry<br>
>> and was thinking this might be a reasonable place to add such support.<br>
>> It would require some changes to how restricted_actions work.<br>
>><br>
>> One change would be a method for specifying that restricted_actions<br>
>> should not fail the stack operation if an action would have otherwise<br>
>> been triggered. Currently the behavior is to raise an exception and<br>
>> mark the stack failed if an action needs to be taken but has been<br>
>> marked restricted. That would need to be tweaked to allow specifying<br>
>> that that we don't want the stack to fail. One thought would be to<br>
>> change the allowed values of restricted_actions to:<br>
>><br>
>> replace_fail<br>
>> replace_ignore<br>
>> update_fail<br>
>> update_ignore<br>
>> replace<br>
>> update<br>
>><br>
>> where replace and update were synonyms for replace_fail/update_fail to<br>
>> maintain backwards compatibility.<br>
><br>
><br>
> Anything that involves the resource definition in the template changing but<br>
> Heat not modifying the resource is problematic, because that messes with<br>
> Heat's internal bookkeeping.<br>
<br>
I don't think this case would violate that principle. The template +<br>
environment files would match what Heat has done. After an update, the<br>
2 would be in sync as to what servers the updated Deployment resource<br>
was triggered.<br>
<br>
><br>
>> Another change would be to add logic to the Deployment resources<br>
>> themselves to consider if any restricted_actions have been set on an<br>
>> Server resources before triggering an updated deployment for a given<br>
>> server.<br>
><br>
><br>
> Why not just a property, "no_new_deployments_please: true"?<br>
<br>
That would actually work and be pretty straightforward I think. We<br>
could have a map parameter with server names and the property that the<br>
user could use to set the value.<br>
<br>
The reason why I was initially not considering this route was because<br>
it doesn't allow the user to disable only some deployments for a given<br>
server. It's all or nothing. However, it's much simpler than a totally<br>
flexible option, and it addresses 2 of the largest use cases of this<br>
feature. I'll look into this route a bit more.<br>
<br>
-- <br>
-- James Slagle<br>
--<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Wed, 8 Mar 2017 16:06:59 +0100<br>
From: Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] [ironic] Pike PTG report<br>
Message-ID: <<a href="mailto:23821f81-9509-3600-6b9c-693984aa0132@redhat.com" target="_blank">23821f81-9509-3600-6b9c-<wbr>693984aa0132@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hi all!<br>
<br>
I've finished my Pike PTG report. It is spread over four blog posts:<br>
<br>
<a href="http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-1.html" target="_blank">http://dtantsur.github.io/<wbr>posts/ironic-ptg-atlanta-2017-<wbr>1.html</a><br>
<a href="http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-2.html" target="_blank">http://dtantsur.github.io/<wbr>posts/ironic-ptg-atlanta-2017-<wbr>2.html</a><br>
<a href="http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-3.html" target="_blank">http://dtantsur.github.io/<wbr>posts/ironic-ptg-atlanta-2017-<wbr>3.html</a><br>
<a href="http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-4.html" target="_blank">http://dtantsur.github.io/<wbr>posts/ironic-ptg-atlanta-2017-<wbr>4.html</a><br>
<br>
It was a lot of typing, please pardon mistakes. The whole text (in RST format) <br>
for archiving purposes is copy-pasted in the end of this message.<br>
<br>
Please feel free to respond here or in the blog comments.<br>
<br>
Cheers,<br>
Dmitry<br>
<br>
<br>
Ongoing work and status updates<br>
------------------------------<wbr>-<br>
<br>
Etherpad: <a href="https://etherpad.openstack.org/p/ironic-pike-ptg-ongoing-work" target="_blank">https://etherpad.openstack.<wbr>org/p/ironic-pike-ptg-ongoing-<wbr>work</a>.<br>
<br>
We spent the first half of Wednesday discussing this. There was a lot of<br>
incomplete work left from Ocata, and some major ongoing work that we did not<br>
even plan to finish in Ocata.<br>
<br>
Boot-from-volume<br>
~~~~~~~~~~~~~~~~<br>
<br>
Got some progress, most of the Ironic patches are up. Desperately needs review<br>
and testing, though. The Nova part is also lagging behind, and should be<br>
brought to the Nova team attention.<br>
<br>
**Actions**<br>
**mgoddard** and **dtantsur** volunteered to help with testing, while<br>
**mjturek**, **hsiina** and **crushil** volunteered to do some coding.<br>
**Goals for Pike**<br>
finish the first (iSCSI using iPXE) case and the Nova part.<br>
<br>
Networking<br>
~~~~~~~~~~<br>
<br>
A lot of progress here during Ocata, completed bonding and attach/detach API.<br>
<br>
VLAN-aware instances should work. However, it requires an expensive ToR switch,<br>
supporting VLAN/VLAN and VLAN/VXLAN rewriting, and, of course ML2 plugin<br>
support. Also, reusing an existing segmentation ID requires more work: we have<br>
no current way to put the right ID in the configdrive.<br>
<br>
**Actions**<br>
**vsaienko**, **armando** and **kevinbenton** are looking into the Neutron<br>
part of the configdrive problem.<br>
<br>
Routed networks support require Ironic to be aware of which physical network(s)<br>
each node is connected to.<br>
<br>
**Goals for Pike**<br>
* model physical networks on Ironic ports,<br>
* update VIF attach logic to no longer attach things to wrong physnets.<br>
<br>
We discussed introducing notifications from Neutron to Ironic about events<br>
of interest for us. We are going to use the same model as between Neutron and<br>
Nova: create a Neutron plugin that filters out interesting events and posts<br>
to a new Ironic API endpoint.<br>
<br>
**Goals for Pike**<br>
have this notification system in place.<br>
<br>
Finally, we agreed that we need to work on a reference architecture document,<br>
describing the best practices of deploying Ironic, especially around<br>
multi-tenant networking setup.<br>
<br>
**Actions**<br>
**jroll** to kickstart this document, **JayF** and **mariojv** to help.<br>
<br>
Rolling upgrades<br>
~~~~~~~~~~~~~~~~<br>
<br>
Missed Ocata by a small margin. The code is up and needs reviewing. The CI<br>
is waiting for the multinode job to start working (should be close as well).<br>
<br>
**Goals for Pike**<br>
rolling upgrade Ocata -> Pike.<br>
<br>
Driver composition reform<br>
~~~~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
Most of the code landed in Ocata already. Some client changes landed in Pike,<br>
some are still on review. As we released Ocata with the driver composition<br>
changes being experimental, we are not ready to deprecate old-style drivers in<br>
Pike. Documentation is also still lacking.<br>
<br>
**Goals for Pike**<br>
* make new-style dynamic drivers the recommend way of writing and using<br>
drivers,<br>
* fill in missing documentation,<br>
* *recommend* vendors to have hardware types for their hardware, as well<br>
as 3rdparty CI support for it.<br>
**Important decisions**<br>
* no new classic drivers are accepted in-tree (please check when accepting<br>
specifications),<br>
* no new interfaces additions for classic drivers(``volume_interface`` is<br>
the last accepted from them),<br>
* remove the SSH drivers by Pike final (probably around M3).<br>
<br>
Ironic Inspector HA<br>
~~~~~~~~~~~~~~~~~~~<br>
<br>
Preliminary work (switch to a real state machine) done in Ocata. Splitting the<br>
service into API and conductor/engine parts correlates with the WSGI<br>
cross-project goal.<br>
<br>
We also had a deeper discussion about ironic-inspector architecture earlier<br>
that week, where we were `looking<br>
<<a href="https://etherpad.openstack.org/p/ironic-pike-ptg-inspector-arch" target="_blank">https://etherpad.openstack.<wbr>org/p/ironic-pike-ptg-<wbr>inspector-arch</a>>`_ into<br>
potential future work to make ironic-inspector both HA and multi-tenancy<br>
friendly. It was suggested to split *discovery* process (simple process to<br>
detect MACs and/or power credentials) and *inspection* process (full process<br>
when a MAC is known).<br>
<br>
**Goals for Pike**<br>
* switch locking to ``tooz`` (with Redis probably being the default<br>
backend for now),<br>
* split away API process with WSGI support,<br>
* leader election using ``tooz`` for periodic tasks,<br>
* stop messing with ``iptables`` and start directly managing ``dnsmasq``<br>
instead (similarly to how Neutron does it),<br>
* try using ``dnsmasq`` in active/active configuration with<br>
non-intersecting IP addresses pools from the same subnet.<br>
**Actions**<br>
also **sambetts** will write a spec on a potential workflow split.<br>
<br>
Ironic UI<br>
~~~~~~~~~<br>
<br>
The project got some important features implemented, and an RDO package<br>
emerged during Ocata. Still, it desperately needs volunteers for coding and<br>
testing. A `spreadsheet<br>
<<a href="https://docs.google.com/spreadsheets/d/1petifqVxOT70H2Krz7igV2m9YqgXaAiCHR8CXgoi9a0/edit?usp=sharing" target="_blank">https://docs.google.com/<wbr>spreadsheets/d/<wbr>1petifqVxOT70H2Krz7igV2m9YqgXa<wbr>AiCHR8CXgoi9a0/edit?usp=<wbr>sharing</a>>`_<br>
captures the current (as of beginning of Pike) status of features.<br>
<br>
**Actions**<br>
**dtantsur**, **davidlenwell**, **bradjones** and **crushil** agreed to<br>
dedicate some time to the UI.<br>
<br>
Rescue<br>
~~~~~~<br>
<br>
Most of the patches are up, the feature is tested with the CoreOS-based<br>
ramdisk for now. Still, the ramdisk side poses a problem: while using DHCP is<br>
easy, static network configuration seems not. It's especially problematic in<br>
CoreOS. Might be much easier in the DIB-based ramdisk, but we don't support it<br>
officially in the Ironic community.<br>
<br>
RedFish driver<br>
~~~~~~~~~~~~~~<br>
<br>
We want to get a driver supporting RedFish soon. There was some critics raised<br>
around the currently proposed python-redfish library. As an alternative,<br>
`a new library <<a href="https://github.com/openstack/sushy" target="_blank">https://github.com/openstack/<wbr>sushy</a>>`_ was written. Is it<br>
lightweight, covered by unit tests and only contain what Ironic needs.<br>
We agreed to start our driver implementation with it, and switch to the<br>
python-redfish library when/if it is ready to be consumed by us.<br>
<br>
We postponed discussing advanced features like nodes composition till after<br>
we get the basic driver in.<br>
<br>
Small status updates<br>
~~~~~~~~~~~~~~~~~~~~<br>
<br>
* Of the API evolution initiative, only E-Tag work got some progress. The spec<br>
needs reviewing now.<br>
<br>
* Node tags work needs review and is close to landing. We decided to discuss<br>
port tags as part of a separate RFE, if anybody is interested.<br>
<br>
* IPA API versioning also needs reviews, there are several moderately<br>
contentions points about it. It was suggested that we only support one<br>
direction of IPA/ironic upgrades to simplify testing. We'll probably only<br>
support old IPA with new ironic, which is already tested by our grenade job.<br>
<br>
CI and testing<br>
--------------<br>
<br>
Etherpad: <a href="https://etherpad.openstack.org/p/ironic-pike-ptg-ci-testing" target="_blank">https://etherpad.openstack.<wbr>org/p/ironic-pike-ptg-ci-<wbr>testing</a><br>
<br>
Missing CI coverage<br>
~~~~~~~~~~~~~~~~~~~<br>
<br>
UEFI<br>
Cirros finally released a stable version with UEFI support built in.<br>
A non-voting job is running with partition images, should be made voting<br>
soon. A test with whole disk images will be introduced as part of<br>
`standalone tests <<a href="https://review.openstack.org/#/c/423556/" target="_blank">https://review.openstack.org/<wbr>#/c/423556/</a>>`_.<br>
Local bootloader<br>
Requires small enough instance images with Grub2 present (Cirros does not<br>
have it). We agreed to create a new repository with scripts to build<br>
suitable images. Potentially can be shared with other teams (e.g. Neutron).<br>
<br>
Actions: **lucasagomes** and/or **vsaienko** to look into it.<br>
Adopt state<br>
Tests have been up for some time, but have ordering issues with nova-based<br>
tests. Suggesting **TheJulia** to move them to `standalone tests`_.<br>
Root device hints<br>
Not covered by any CI. Will need modifying how we create virtual machines.<br>
First step is to get size-based hints work. Check two cases: with size<br>
strictly equal and greater than requested.<br>
<br>
Actions: **dtantsur** to look into it.<br>
Capabilities-based scheduling<br>
This may actually go to Nova gate, not ours. Still, it relies on some code<br>
in our driver, so we'd better cover it to ensure that the placement API<br>
changes don't break it.<br>
<br>
Actions: **vsaienko** to look into it.<br>
Port groups<br>
The same image problem as with local boot - the same action item to create<br>
a repository with build scripts to build our images.<br>
VLAN-aware instances<br>
The same image problem + requires `reworking our network simulation code<br>
<<a href="https://review.openstack.org/#/c/392959/" target="_blank">https://review.openstack.org/<wbr>#/c/392959/</a>>`_.<br>
Conductor take over and hash ring<br>
Requires a separate multi-node job.<br>
<br>
Action: **vsaienko** to investigate.<br>
<br>
DIB-based IPA image<br>
^^^^^^^^^^^^^^^^^^^<br>
<br>
Currently the ``ironic-agent`` element to build such image is in the DIB<br>
repository outside of our control. If we want to properly support it, we need<br>
to gate on its changes, and to gate IPA changes on its job. Some time ago we<br>
had a tentative agreement to move the element to our tree.<br>
<br>
It was blocked by the fact that DIB rarely or never removes elements, and does<br>
not have a way to properly de-duplicate elements with the same name.<br>
<br>
An obvious solution we are going to propose is to take this element in IPA<br>
tree under a different name (``ironic-python-agent``?). The old element will<br>
get deprecated and only critical fixes will be accepted for it.<br>
<br>
Action<br>
**dtantsur** to (re)start this discussion with the TripleO and DIB teams.<br>
<br>
API microversions testing<br>
^^^^^^^^^^^^^^^^^^^^^^^^^<br>
<br>
We are not sure we have tests covering all microversions. We seem to have API<br>
tests using ``fake`` driver that cover at least some of them. We should start<br>
paying more attention to this part of our testing.<br>
<br>
Actions<br>
**dtantsur** to check if these tests are up-to-date and split them to a<br>
separate CI job.<br>
**pas-ha** to write API tests for internal API (i.e. lookup/heartbeat).<br>
<br>
Global OpenStack goals<br>
~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
Splitting away tempest plugins<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
<br>
It did not end up a goal for Pike, and there are still some concerns in the<br>
community. Still, as we already apply ugly hacks in our jobs to use the<br>
tempest plugin from master, we agreed to proceed with the split.<br>
<br>
To simplify both maintenance and consuming our tests, we agreed to merge<br>
ironic and ironic-inspector plugins. The introspection tests will or will<br>
not run based on ironic-inspector presence.<br>
<br>
We propose having a merged core team (i.e. ironic-inspector-core which<br>
already includes ironic-core) for this repository. We trust people who<br>
only have core rights on ironic-inspector to not approve things they're<br>
not authorized to approve.<br>
<br>
Python 3 support<br>
^^^^^^^^^^^^^^^^<br>
<br>
We've been running Python 3 unit tests for quite some time. Additionally,<br>
ironic-inspector runs a non-voting Python 3 functional test. Ironic has an<br>
experimental job which fails, apparently, because of swift. We can start with<br>
switching this job to the ``pxe_ipmitool`` driver (not requiring swift).<br>
Inspector does not have a Python 3 integration tests job proposed yet.<br>
<br>
Actions<br>
**JayF** and **hurricanerix** will drive this work in both ironic and<br>
ironic-inspector.<br>
<br>
**lucasagomes** to check pyghmi and virtualbmc compatibility.<br>
<br>
**krtaylor** and/or **mjturek** to check MoltenIron.<br>
<br>
We agreed that Bifrost is out of scope for this task. Its Python 3<br>
compatibility mostly depends on one of Ansible anyway. Similarly, for the UI<br>
we need horizon to be fully Python 3 compatible first.<br>
<br>
Important decisions<br>
We recommend vendors to make their libraries compatible with Python 3.<br>
It may become a strict requirement in one of the coming releases.<br>
<br>
API behind WSGI container<br>
^^^^^^^^^^^^^^^^^^^^^^^^^<br>
<br>
This seems quite straightforward. The work has started to switch ironic CI to<br>
WSGI already. For ironic-inspector it's going to be done as part of the HA<br>
work.<br>
<br>
Operations<br>
----------<br>
<br>
Etherpad: <a href="https://etherpad.openstack.org/p/ironic-pike-ptg-operations" target="_blank">https://etherpad.openstack.<wbr>org/p/ironic-pike-ptg-<wbr>operations</a><br>
<br>
OSC plugin and API versioning<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
Currently we default the OSC plugin (and old client too) to a really old API<br>
version. We agreed that this situation is not desired, and that we should take<br>
the same approach as Nova and default to the latest version. We are planning<br>
to announce the change this cycle, both via the ML and via a warning issues<br>
when no versions are specified.<br>
<br>
Next, in the Queens cycle, we will have to make the change, bearing in mind<br>
that OSC does not support values like ``latest`` for API versions. So the plan<br>
is as follows:<br>
<br>
* make the default ``--os-baremetal-api-version=<wbr>1`` in<br>
<br>
<a href="https://github.com/openstack/python-ironicclient/blob/f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L67" target="_blank">https://github.com/openstack/<wbr>python-ironicclient/blob/<wbr>f242c6af3b295051019aeabb4ec7cf<wbr>82eb085874/ironicclient/osc/<wbr>plugin.py#L67</a><br>
<br>
* when instantiating the ironic client in the OSC plugin, replace '1' with<br>
'latest':<br>
<br>
<a href="https://github.com/openstack/python-ironicclient/blob/f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L41" target="_blank">https://github.com/openstack/<wbr>python-ironicclient/blob/<wbr>f242c6af3b295051019aeabb4ec7cf<wbr>82eb085874/ironicclient/osc/<wbr>plugin.py#L41</a><br>
<br>
* when handling ``--os-baremetal-api-version=<wbr>latest``, replace it with ``1``,<br>
so that it's later replaced with ``latest`` again:<br>
<br>
<a href="https://github.com/openstack/python-ironicclient/blob/f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L85" target="_blank">https://github.com/openstack/<wbr>python-ironicclient/blob/<wbr>f242c6af3b295051019aeabb4ec7cf<wbr>82eb085874/ironicclient/osc/<wbr>plugin.py#L85</a><br>
<br>
As a side effect, that will make ``1`` equivalent to ``latest`` as well.<br>
<br>
It was also suggested to have an new command, displaying both server supported<br>
and client supported API versions.<br>
<br>
Deprecating the standalone ironic CLI in favor of the OSC plugin<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~<br>
<br>
We do not want to maintain two CLI in the long run. We agreed to start<br>
thinking about deprecating the old ``ironic`` command. Main concerns:<br>
<br>
* lack of feature parity,<br>
<br>
* ugly way to work without authentication, for example::<br>
<br>
openstack baremetal --os-url <a href="http://ironic" target="_blank">http://ironic</a> --os-token fake <COMMAND><br>
<br>
Plan for Pike<br>
* Ensure complete feature parity between two clients.<br>
* Only use ``openstack baremetal`` commands in the documentation.<br>
<br>
The actual deprecation is planned for Queens.<br>
<br>
RAID configuration enhancements<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~<br>
<br>
A few suggestions were made:<br>
<br>
* Support ordered list of logical disk definition. The first possible<br>
configuration is applied to the node. For example:<br>
<br>
* Top of list - RAID 10 but we don't have enough drives<br>
* Fallback to next preference in list - RAID 1 on a pair of available drives<br>
* Finally, JBOD or RAID 0 on only available drive<br>
<br>
* Specify the number of instances for a logical disk definition to create.<br>
<br>
* Specify backing physical disks by stating preference for the smallest, e.g.<br>
smallest like-sized pair or two smallest disks.<br>
<br>
* Specify location of physical disks, e.g. first two or last two as perceived<br>
by the hardware, front/rear/internal location.<br>
<br>
Actions<br>
**rpioso** will write RFE(s)<br>
<br>
Smaller topics<br>
~~~~~~~~~~~~~~<br>
<br>
Non-aborteable clean steps stuck in ``clean wait`` state<br>
We discussed a potential ``force-abort`` functionality, but the only thing<br>
we agreed on is check that all current clean steps are marked as<br>
``abortable`` if they really are.<br>
<br>
Status of long-running cleaning operations<br>
There is a request to be able to get status of e.g. disk shredding (which<br>
may take hours). We found out that the current IPA API design essentially<br>
prevents running several commands in parallel. We agreed that we need IPA<br>
API versioning first, and that this work is not a huge priority right now.<br>
<br>
OSC command for listing driver and RAID properties<br>
We cannot agree on the exact form of these two commands. The primary<br>
candidates discussed on the PTG were::<br>
<br>
openstack baremetal driver property list <DRIVER><br>
openstack baremetal driver property show <DRIVER><br>
<br>
We agreed to move this to the spec: <a href="https://review.openstack.org/439907" target="_blank">https://review.openstack.org/<wbr>439907</a>.<br>
<br>
Abandoning an active node<br>
I.e. an opposite to adopt. It's unclear how such operation would play with<br>
nova, maybe it's only useful for a standalone case.<br>
<br>
Future Work<br>
-----------<br>
<br>
Etherpad: <a href="https://etherpad.openstack.org/p/ironic-pike-ptg-future-work" target="_blank">https://etherpad.openstack.<wbr>org/p/ironic-pike-ptg-future-<wbr>work</a>.<br>
<br>
Neutron event processing<br>
~~~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
RFE: <a href="https://bugs.launchpad.net/ironic/+bug/1304673" target="_blank">https://bugs.launchpad.net/<wbr>ironic/+bug/1304673</a>, spec:<br>
<a href="https://review.openstack.org/343684" target="_blank">https://review.openstack.org/<wbr>343684</a>.<br>
<br>
We need to wait for certain events from neutron (like port bindings).<br>
Currently we just wait some time, and hope it went well. We agreed to follow<br>
the same pattern that nova does for neutron to nova notifications.<br>
The neutron part is<br>
<a href="https://github.com/openstack/neutron/blob/master/neutron/notifiers/nova.py" target="_blank">https://github.com/openstack/<wbr>neutron/blob/master/neutron/<wbr>notifiers/nova.py</a>.<br>
We agreed with the Neutron team that notifier and the other ironic-specific<br>
stuff for neutron would live in a separate repo under Baremetal governance.<br>
Draft code is <a href="https://review.openstack.org/#/c/357780" target="_blank">https://review.openstack.org/#<wbr>/c/357780</a>.<br>
<br>
Splitting node.properties[capabilities] into a separate table<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~<br>
<br>
This is something we've planned on for long time. Currently, it's not possible<br>
to update capabilities atomically, and the format is quite hard to work with:<br>
``k1:v1,k2:v2``. We discussed going away from using word ``capability``. It's<br>
already overused in the OpenStack world, and nova is switching to the notion<br>
of "traits". It also looks like traits will be qualitative-only while, we have<br>
proposals from quantitative capabilities (like ``gpu_count``).<br>
<br>
It was proposed to model a typical CRUD API for traits in Ironic::<br>
<br>
GET /v1/nodes/<NODE>/traits<br>
POST /v1/nodes/<NODE>/traits<br>
GET /v1/nodes/<NODE>/traits/<<wbr>trait><br>
DELETE /v1/nodes/<NODE>/traits/<<wbr>trait><br>
<br>
In API versions before this addition, we would make<br>
``properties/capabilities`` a transparent proxy to new tables.<br>
<br>
It was noted that the database change can be done first, with API change<br>
following it.<br>
<br>
Actions<br>
**rloo** to propose two separate RFEs for database and API parts.<br>
<br>
Avoid changing behavior based on properties[capabilities]<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
Currently our capabilities have a dual role. They serve both for scheduling<br>
(to inform nova of what nodes can) and for making decisions based on flavor<br>
(e.g. request UEFI boot). It is complicated by the fact that sometimes the<br>
same capability (e.g. UEFI) can be of both types depending on a driver.<br>
This is quite confusing for users, and may be incompatible with future changes<br>
both in ironic and nova.<br>
<br>
For things like boot option and (potentially) BIOS setting, we need to be able<br>
to get requests from flavors and/or nova boot arguments without abusing<br>
capabilities for it. Maybe similar to how NUMA support does it:<br>
<a href="https://docs.openstack.org/admin-guide/compute-cpu-topologies.html" target="_blank">https://docs.openstack.org/<wbr>admin-guide/compute-cpu-<wbr>topologies.html</a>.<br>
<br>
For example::<br>
<br>
flavor.extra_specs[traits:has_<wbr>ssd]=True<br>
<br>
(tells the scheduler to find a node with SSD disk; does not change<br>
behavior/config of node)<br>
<br>
::<br>
<br>
flavor.extra_specs[<wbr>configuration:use_uefi]=True<br>
<br>
(configures the node to boot UEFI; has no impact on scheduling)<br>
<br>
::<br>
<br>
flavor.extra_specs[traits:has_<wbr>uefi]=True<br>
flavor.extra_specs[<wbr>configuration:use_uefi]=True<br>
<br>
(tells the scheduler to find a node supporting UEFI; if this support is<br>
dynamic, configures the node to enable UEFI boot).<br>
<br>
Actions<br>
**jroll** to start conversation with nova folks about how/if to have a<br>
replacement for this elsewhere.<br>
<br>
Stop accepting driver features relying on ``properties[capabilities]`` (as<br>
opposed to ``instance_info[capabilities]`<wbr>`).<br>
<br>
Potential actions<br>
* Remove ``instance_info[capabilities]`<wbr>` into<br>
``instance_info[configuration]<wbr>`` for clarity.<br>
<br>
Deploy-time RAID<br>
~~~~~~~~~~~~~~~~<br>
<br>
This was discussed on the last design summit. Since then we've got a `nova<br>
spec <<a href="https://review.openstack.org/408151" target="_blank">https://review.openstack.org/<wbr>408151</a>>`_, which, however, hasn't got many<br>
reviews so far. The spec continues using ``block_device_mapping_v2``, other<br>
options apparently were not considered.<br>
<br>
We discussed how to inform Nova whether or not RAID can be built for<br>
a particular node. Ideally, we need to tell the scheduler about many things:<br>
RAID support, disk number, disk sizes. We decided that it's an overkill, at<br>
least for the beginning. We'll only rely on a "supports RAID" trait for now.<br>
<br>
It's still unclear what to do about ``local_gb`` property, but with planned<br>
Nova changes it may not be required any more.<br>
<br>
Advanced partitioning<br>
~~~~~~~~~~~~~~~~~~~~~<br>
<br>
There is a desire for flexible partitioning in ironic, both in case of<br>
partition and whole disk images (in the latter case - partition other disks).<br>
Generally, there was no consensus on the PTG. Some people were very much in<br>
favor of this feature, some - quite against. It's unclear how to pass<br>
partitioning information from Nova. There is a concern that such feature will<br>
get us too much into OS-specific details. We agreed that someone interested<br>
will collect the requirements, create a more detailed proposal, and we'll<br>
discuss it on the next PTG.<br>
<br>
Splitting nodes into separate pools<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~~<br>
<br>
This feature is about dedicating some nodes to a tenant, essentially adding a<br>
tenant_id field to nodes. This can be helpful e.g. for a hardware provider to<br>
reserve hardware for a tenant, so that it's always available.<br>
<br>
This seems relatively easy to implement in Ironic. We need a new field on<br>
nodes, then only show non-admin users their hardware. A bit trickier to make<br>
it work with Nova. We agreed to investigate passing a token from Nova to<br>
Ironic, as opposed to always using a service user admin token.<br>
<br>
Actions<br>
**vdrok** to work out the details and propose a spec.<br>
<br>
Requirements for routed networks<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~<br>
<br>
We discussed requirements for achieving routed architecture like<br>
spine-and-leaf. It seems that most of the requirements are already in our<br>
plans. The outstanding items are:<br>
<br>
* Multiple subnets support for ironic-inspector. Can be solved in<br>
``dnsmasq.conf`` level, an appropriate change was merged into<br>
puppet-ironic.<br>
<br>
* Per-node provision and cleaning networks. There is an RFE, somebody just<br>
has to do the work.<br>
<br>
This does not seem to be a Pike goal for us, but many of the dependencies<br>
are planned for Pike.<br>
<br>
Configuring BIOS setting for nodes<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~<br>
<br>
Preparing a node to be configured to serve a certain rule by tweaking its<br>
settings. Currently, it is implemented by the Drac driver in a vendor pass-thru.<br>
<br>
We agreed that such feature would better fit cleaning, rather then<br>
pre-deployment. Thus, it does not depend on deploy steps. It was suggested to<br>
extend the management interface to support passing it an arbitrary JSON with<br>
configuration. Then a clean step would pick it (similar to RAID).<br>
<br>
Actions<br>
**rpioso** to write a spec for this feature.<br>
<br>
Deploy steps<br>
~~~~~~~~~~~~<br>
<br>
We discussed `the deploy steps proposal <<a href="https://review.openstack.org/412523" target="_blank">https://review.openstack.org/<wbr>412523</a>>`_<br>
in depth. We agreed on partially splitting the deployment procedure into<br>
pluggable bits. We will leave the very core of the deployment - flashing the<br>
image onto a target disk - hardcoded, at least for now. The drivers will be<br>
able to define steps to run before and after this core deployment. Pre- and<br>
post-deployment steps will have different priorities ranges, something like::<br>
<br>
0 < pre-max/deploy-min < deploy-max/post-min < infinity<br>
<br>
We plan on making partitioning a pre-deploy step, and installing a bootloader<br>
a post-deploy step. We will not allow IPA hardware managers to define deploy<br>
steps, at least for now.<br>
<br>
Actions<br>
**yolanda** is planning to work on this feature, **rloo** and **TheJulia**<br>
to help.<br>
<br>
Authenticating IPA<br>
~~~~~~~~~~~~~~~~~~<br>
<br>
IPA HTTP endpoints, and the endpoints Ironic provides for ramdisk callbacks<br>
are completely insecure right now. We hesitated to add any authentication to<br>
them, as any secrets published for the ramdisk to use (be it part of kernel<br>
command line or image itself) are readily available to anyone on the network.<br>
<br>
We agreed on several things to look into:<br>
<br>
* A random CSRF-like token to use for each node. This will somewhat limit the<br>
attack surface by requiring an attacker to intercept a token for the<br>
specific node, rather then just access the endpoints.<br>
<br>
* Document splitting out public and private Ironic API as part of our future<br>
reference architecture guide.<br>
<br>
* Make sure we support TLS between Ironic and IPA, which is particularly<br>
helpful when virtual media is used (and secrets are not leaked).<br>
<br>
Actions<br>
**jroll** and **joanna** to look into the random token idea.<br>
**jroll** to write an RFE for TLS between IPA and Ironic.<br>
<br>
Smaller things<br>
~~~~~~~~~~~~~~<br>
<br>
Using ansible-networking as a ML2 driver for ironic-neutron integration work<br>
It was suggested to make it one of backends for<br>
``networking-generic-switch`` in addition to ``netmiko``. Potential<br>
concurrency issues when using SSH were raised, and still require a solution.<br>
<br>
Extending and standardizing the list of capabilities the drivers may discover<br>
It was proposed to use `os-traits <<a href="https://github.com/jaypipes/os-traits" target="_blank">https://github.com/jaypipes/<wbr>os-traits</a>>`_<br>
for standardizing qualitative capabilities. **jroll** will look into<br>
quantitative capabilities.<br>
<br>
Pluggable interface for long-running processes<br>
This was proposed as an optional way to mitigate certain problems with<br>
local long-running services, like console. E.g. if a conductor crashes,<br>
its console services keep running. It was noted that this is a bug to be<br>
fixed (**TheJulia** volunteered to triage it).<br>
The proposed solution involved optionally run processes on a remote<br>
cluster, e.g. k8s. Concerns were voiced on the PTG around complicating<br>
support matrix and adding more decisions to make for operators.<br>
There was no apparent consensus on implementing this feature due to that.<br>
<br>
Setting specific boot device for PXE booting<br>
It was found to be already solved by setting ``pxe_enabled`` on ports.<br>
We just need to update ironic-inspector to set this flag.<br>
<br>
Priorities and planning<br>
-----------------------<br>
<br>
The suggested priorities list is now finalized in<br>
<a href="https://review.openstack.org/439710" target="_blank">https://review.openstack.org/<wbr>439710</a>.<br>
<br>
We also agreed on the following priorities for ironic-inspector subteam:<br>
<br>
* Inspector HA (**milan**)<br>
* Community goal - python 3.5 (**JayF**, **hurricanerix**)<br>
* Community goal - devstack+apache+wsgi (**aarefiev**, **ovoshchana**)<br>
* Inspector needs to update ``pxe_enabled`` flag on ports (**dtantsur**)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Wed, 8 Mar 2017 15:07:06 +0000 (GMT)<br>
From: Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org" target="_blank">cdent+os@anticdent.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova][placement-api] Is there any<br>
document about openstack-placement-api for installation and configure?<br>
Message-ID: <alpine.OSX.2.20.<wbr>1703081500570.59117@shine.<wbr>local><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On Wed, 8 Mar 2017, Yu Wei wrote:<br>
<br>
> I'm new to openstack.<br>
> I tried to install openstack-ocata.<br>
> As placement-api is required since Ocata, is there any detailed document<br>
> about how to install and configure placement-api?<br>
<br>
There are two different things which might be useful to you. Some<br>
nova "in-tree" docs about placement:<br>
<br>
<a href="https://docs.openstack.org/developer/nova/placement.html" target="_blank">https://docs.openstack.org/<wbr>developer/nova/placement.html</a><br>
<a href="https://docs.openstack.org/developer/nova/placement_dev.html" target="_blank">https://docs.openstack.org/<wbr>developer/nova/placement_dev.<wbr>html</a><br>
<br>
and some in progress documents about installing placement:<br>
<br>
<a href="https://review.openstack.org/#/c/438328/" target="_blank">https://review.openstack.org/#<wbr>/c/438328/</a><br>
<br>
That latter has some errors that are in the process of being fixed,<br>
so make sure you read the associated comments.<br>
<br>
-- <br>
Chris Dent ?\_(?)_/? <a href="https://anticdent.org/" target="_blank">https://anticdent.org/</a><br>
freenode: cdent <wbr> tw: @anticdent<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Wed, 8 Mar 2017 09:12:59 -0600<br>
From: Monty Taylor <<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev]<br>
[cinder][glance][horizon][<wbr>keystone][nova][qa][swift] Feedback needed:<br>
Removal of legacy per-project vanity domain redirects<br>
Message-ID: <<a href="mailto:9b5cf68a-39bf-5d33-2f4c-77c5f5ff7f78@inaugust.com" target="_blank">9b5cf68a-39bf-5d33-2f4c-<wbr>77c5f5ff7f78@inaugust.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hey all,<br>
<br>
We have a set of old vanity redirect URLs from back when we made a URL<br>
for each project:<br>
<br>
<a href="http://cinder.openstack.org" target="_blank">cinder.openstack.org</a><br>
<a href="http://glance.openstack.org" target="_blank">glance.openstack.org</a><br>
<a href="http://horizon.openstack.org" target="_blank">horizon.openstack.org</a><br>
<a href="http://keystone.openstack.org" target="_blank">keystone.openstack.org</a><br>
<a href="http://nova.openstack.org" target="_blank">nova.openstack.org</a><br>
<a href="http://qa.openstack.org" target="_blank">qa.openstack.org</a><br>
<a href="http://swift.openstack.org" target="_blank">swift.openstack.org</a><br>
<br>
They are being served from an old server we'd like to retire. Obviously,<br>
moving a set of http redirects is trivial, but these domains have been<br>
deprecated for about 4 now, so we figured we'd clean house if we can.<br>
<br>
We know that the swift team has previously expressed that there are<br>
links out in the wild pointing to swift.o.o/content that still work and<br>
that they don't want to break anyone, which is fine. (although if the<br>
swift team has changed their minds, that's also welcome)<br>
<br>
for the rest of you, can we kill these rather than transfer them?<br>
<br>
Thanks!<br>
Monty<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Wed, 8 Mar 2017 15:29:05 +0000<br>
From: Yu Wei <<a href="mailto:yu2003w@hotmail.com" target="_blank">yu2003w@hotmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova][placement-api] Is there any<br>
document about openstack-placement-api for installation and configure?<br>
Message-ID:<br>
<<a href="mailto:HK2PR03MB056153C43DF0C645B2037225B52E0@HK2PR03MB0561.apcprd03.prod.outlook.com" target="_blank">HK2PR03MB056153C43DF0C645B203<wbr>7225B52E0@HK2PR03MB0561.<wbr>apcprd03.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
@Chris, Thanks for replying.<br>
<br>
When I tried to configure placement-api, I met following problems,<br>
<br>
AH01630: client denied by server configuration: /usr/bin/nova-placement-api<br>
<br>
I will read the links you pointed out.<br>
<br>
Thanks again,<br>
<br>
Jared<br>
<br>
<br>
On 2017?03?08? 23:07, Chris Dent wrote:<br>
On Wed, 8 Mar 2017, Yu Wei wrote:<br>
<br>
I'm new to openstack.<br>
I tried to install openstack-ocata.<br>
As placement-api is required since Ocata, is there any detailed document<br>
about how to install and configure placement-api?<br>
<br>
There are two different things which might be useful to you. Some<br>
nova "in-tree" docs about placement:<br>
<br>
<a href="https://docs.openstack.org/developer/nova/placement.html" target="_blank">https://docs.openstack.org/<wbr>developer/nova/placement.html</a><br>
<a href="https://docs.openstack.org/developer/nova/placement_dev.html" target="_blank">https://docs.openstack.org/<wbr>developer/nova/placement_dev.<wbr>html</a><br>
<br>
and some in progress documents about installing placement:<br>
<br>
<a href="https://review.openstack.org/#/c/438328/" target="_blank">https://review.openstack.org/#<wbr>/c/438328/</a><br>
<br>
That latter has some errors that are in the process of being fixed,<br>
so make sure you read the associated comments.<br>
<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-<wbr>dev-request@lists.openstack.<wbr>org</a>?subject:unsubscribe><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/cd8b8a70/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/cd8b8a70/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Wed, 8 Mar 2017 15:35:34 +0000 (GMT)<br>
From: Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org" target="_blank">cdent+os@anticdent.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova][placement-api] Is there any<br>
document about openstack-placement-api for installation and configure?<br>
Message-ID: <alpine.OSX.2.20.<wbr>1703081532490.59117@shine.<wbr>local><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On Wed, 8 Mar 2017, Yu Wei wrote:<br>
<br>
> When I tried to configure placement-api, I met following problems,<br>
><br>
> AH01630: client denied by server configuration: /usr/bin/nova-placement-api<br>
<br>
That can be fixed by doing (somewhere in your apache config):<br>
<br>
<Directory /usr/bin><br>
Require all granted<br>
</Directory><br>
<br>
but rather than doing that you may wish to move nova-placement-api<br>
to a less global directory and grant access to that directory.<br>
Providing wide access to /usr/bin is not a great idea.<br>
<br>
-- <br>
Chris Dent ?\_(?)_/? <a href="https://anticdent.org/" target="_blank">https://anticdent.org/</a><br>
freenode: cdent <wbr> tw: @anticdent<br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Thu, 9 Mar 2017 00:39:03 +0900<br>
From: Hirofumi Ichihara <<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.<wbr>jp</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron] [infra] Depends-on tag effect<br>
Message-ID: <<a href="mailto:6664232b-37bc-9a2b-f06e-812318f62b67@lab.ntt.co.jp" target="_blank">6664232b-37bc-9a2b-f06e-<wbr>812318f62b67@lab.ntt.co.jp</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
<br>
<br>
On 2017/03/08 23:59, Andreas Jaeger wrote:<br>
> On 2017-03-08 15:40, ZZelle wrote:<br>
>> Hi,<br>
>><br>
>> iiuc, neutron uses a released version of neutron-lib not neutron-lib<br>
>> master ... So the change should depends on a change in requirements repo<br>
>> incrementing neutron-lib version<br>
> This is documented also at - together with some other caveats:<br>
><br>
> <a href="https://docs.openstack.org/infra/manual/developers.html#limitations-and-caveats" target="_blank">https://docs.openstack.org/<wbr>infra/manual/developers.html#<wbr>limitations-and-caveats</a><br>
Thank you for the pointer. I understand.<br>
<br>
Hirofumi<br>
<br>
><br>
><br>
> Note a depends-on requirements won't work either - you really need to<br>
> release it. Or you need to change the test to pull neutron-lib from source,<br>
><br>
> Andreas<br>
>> On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara<br>
>> <<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.<wbr>jp</a><br>
>> <mailto:<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.<wbr>ntt.co.jp</a>>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I thought that we can post neutron patch depending on neutron-lib<br>
>> patch under review.<br>
>> However, I saw it doesn't work[1, 2]. In the patches, neutron<br>
>> patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8<br>
>> and unit test fails because the test doesn't use the neutron-lib patch.<br>
>><br>
>> Please correct me if it's my misunderstanding.<br>
>><br>
>> [1]: <a href="https://review.openstack.org/#/c/424340/" target="_blank">https://review.openstack.org/#<wbr>/c/424340/</a><br>
>> <<a href="https://review.openstack.org/#/c/424340/" target="_blank">https://review.openstack.org/<wbr>#/c/424340/</a>><br>
>> [2]: <a href="https://review.openstack.org/#/c/424868/" target="_blank">https://review.openstack.org/#<wbr>/c/424868/</a><br>
>> <<a href="https://review.openstack.org/#/c/424868/" target="_blank">https://review.openstack.org/<wbr>#/c/424868/</a>><br>
>><br>
>> Thanks,<br>
>> Hirofumi<br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
>><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
><br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Wed, 8 Mar 2017 09:50:34 -0600<br>
From: Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev]<br>
[cinder][glance][horizon][<wbr>keystone][nova][qa][swift] Feedback needed:<br>
Removal of legacy per-project vanity domain redirects<br>
Message-ID:<br>
<<a href="mailto:CAE6oFcGTu7tesJO28aB8sr2vfS-XRhfm_OYhZ_%2BVVqGb1fTmkQ@mail.gmail.com" target="_blank">CAE6oFcGTu7tesJO28aB8sr2vfS-<wbr>XRhfm_OYhZ_+VVqGb1fTmkQ@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
>From a keystone-perspective, I'm fine killing <a href="http://keystone.openstack.org" target="_blank">keystone.openstack.org</a>.<br>
Unless another team member with more context/history has a reason to keep<br>
it around.<br>
<br>
On Wed, Mar 8, 2017 at 9:12 AM, Monty Taylor <<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>> wrote:<br>
<br>
> Hey all,<br>
><br>
> We have a set of old vanity redirect URLs from back when we made a URL<br>
> for each project:<br>
><br>
> <a href="http://cinder.openstack.org" target="_blank">cinder.openstack.org</a><br>
> <a href="http://glance.openstack.org" target="_blank">glance.openstack.org</a><br>
> <a href="http://horizon.openstack.org" target="_blank">horizon.openstack.org</a><br>
> <a href="http://keystone.openstack.org" target="_blank">keystone.openstack.org</a><br>
> <a href="http://nova.openstack.org" target="_blank">nova.openstack.org</a><br>
> <a href="http://qa.openstack.org" target="_blank">qa.openstack.org</a><br>
> <a href="http://swift.openstack.org" target="_blank">swift.openstack.org</a><br>
><br>
> They are being served from an old server we'd like to retire. Obviously,<br>
> moving a set of http redirects is trivial, but these domains have been<br>
> deprecated for about 4 now, so we figured we'd clean house if we can.<br>
><br>
> We know that the swift team has previously expressed that there are<br>
> links out in the wild pointing to swift.o.o/content that still work and<br>
> that they don't want to break anyone, which is fine. (although if the<br>
> swift team has changed their minds, that's also welcome)<br>
><br>
> for the rest of you, can we kill these rather than transfer them?<br>
><br>
> Thanks!<br>
> Monty<br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/ea4f7d2d/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/ea4f7d2d/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Wed, 8 Mar 2017 15:55:19 +0000<br>
From: Yu Wei <<a href="mailto:yu2003w@hotmail.com" target="_blank">yu2003w@hotmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova][placement-api] Is there any<br>
document about openstack-placement-api for installation and configure?<br>
Message-ID:<br>
<<a href="mailto:HK2PR03MB0561C71A3A7EB17971201AD0B52E0@HK2PR03MB0561.apcprd03.prod.outlook.com" target="_blank">HK2PR03MB0561C71A3A7EB1797120<wbr>1AD0B52E0@HK2PR03MB0561.<wbr>apcprd03.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
It seems that nova-placement-api acts as a CGI module.<br>
<br>
Is it?<br>
<br>
On 2017?03?08? 23:35, Chris Dent wrote:<br>
On Wed, 8 Mar 2017, Yu Wei wrote:<br>
<br>
When I tried to configure placement-api, I met following problems,<br>
<br>
AH01630: client denied by server configuration: /usr/bin/nova-placement-api<br>
<br>
That can be fixed by doing (somewhere in your apache config):<br>
<br>
<Directory /usr/bin><br>
Require all granted<br>
</Directory><br>
<br>
but rather than doing that you may wish to move nova-placement-api<br>
to a less global directory and grant access to that directory.<br>
Providing wide access to /usr/bin is not a great idea.<br>
<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-<wbr>dev-request@lists.openstack.<wbr>org</a>?subject:unsubscribe><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/e9888a76/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/e9888a76/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Wed, 8 Mar 2017 16:02:12 +0000<br>
From: "Scheglmann, Stefan" <<a href="mailto:scheglmann@strato.de" target="_blank">scheglmann@strato.de</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [puppet] puppet-cep beaker test<br>
Message-ID: <<a href="mailto:AA214AA9-86CB-4DC6-8BDE-627F9067D6F8@strato.de" target="_blank">AA214AA9-86CB-4DC6-8BDE-<wbr>627F9067D6F8@strato.de</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hey Alex,<br>
<br>
thx for the reply, unfortunately it doesn?t seem to work. Adding PUPPET_MAJ_VERSION to the call seems not to have any effect.<br>
<br>
<br>
Stefan<br>
> On Tue, Mar 7, 2017 at 7:09 AM, Scheglmann, Stefan <<a href="mailto:scheglmann@strato.de" target="_blank">scheglmann@strato.de</a>> wrote:<br>
>> Hi,<br>
>> <br>
>> currently got some problems running the beaker test for the puppet-cep module. Working on OSX using Vagrant version 1.8.6 and VirtualBox version 5.1.14. Call is 'BEAKER_destroy=no BEAKER_debug=1 bundle exec --verbose rspec spec/acceptance? output in <a href="http://pastebin.com/w5ifgrvd" target="_blank">http://pastebin.com/w5ifgrvd</a><br>
>> <br>
> <br>
> Try running:<br>
> PUPPET_MAJ_VERSION=4 BEAKER_destroy=no BEAKER_debug=1 bundle exec<br>
> --verbose rspec spec/acceptance<br>
> <br>
> Thanks,<br>
> -Alex<br>
> <br>
<br>
Tried this, this just changes the trace a bit, now it seems like that it worked in the first place but then failed for the same reason.<br>
Trace here:<br>
<br>
<br>
>> Trace:<br>
>> An error occurred in a `before(:suite)` hook.<br>
>> Failure/Error: raise CommandFailure, "Host '#{self}' exited with #{result.exit_code} running:\n #{cmdline}\nLast #{@options[:trace_limit]} lines of output were:\n#{result.formatted_<wbr>output(@options[:trace_limit])<wbr>}"<br>
>> Beaker::Host::CommandFailure:<br>
>> Host 'first' exited with 127 running:<br>
>> ZUUL_REF= ZUUL_BRANCH= ZUUL_URL= PUPPET_MAJ_VERSION= bash openstack/puppet-openstack-<wbr>integration/install_modules.sh<br>
>> Last 10 lines of output were:<br>
>> + '[' -n 'SHELLOPTS=braceexpand:<wbr>hashall:interactive-comments:<wbr>xtrace<br>
>> if [ -n "$(set | grep xtrace)" ]; then<br>
>> local enable_xtrace='\''yes'\'';<br>
>> if [ -n "${enable_xtrace}" ]; then' ']'<br>
>> + set +x<br>
>> ------------------------------<wbr>------------------------------<wbr>--------------------<br>
>> | Install r10k <wbr> <wbr> |<br>
>> ------------------------------<wbr>------------------------------<wbr>--------------------<br>
>> + gem install fast_gettext -v '< 1.2.0'<br>
>> openstack/puppet-openstack-<wbr>integration/install_modules.<wbr>sh: line 29: gem: command not found<br>
>> <br>
>> It seems like that the box beaker is using (puppetlabs/ubuntu-14.04-64-<wbr>nocm), somehow ends up with has puppet 4.x installed. I could not exactly pin down how this happens, cause when i sin up some VM just from that base box and install puppet, i end up with
3.4. But during the beaker tests it ends up with puppet 4 and in puppet 4 some paths have changed. /opt/puppetlabs/bin is just for the 'public' applications and the ?private' ones like gem or ruby are in /opt/puppetlabs/puppet/bin. Therefore the openstack/puppet-openstack-<wbr>integration/install_modules.sh
script fails on installation of r10k, cause it cannot find gem and later on it fails on the r10k call cause it is also installed to /opt/puppetlabs/puppet/bin.<br>
>> Symlinking gem and r10k in an provisioned machine, and rerun the tests fixes the problem. Currently i am doing all this cause i added some functionalities for the puppet-cep manifests to support bluestone/rocksdb and some additional config params which i
would like to see in upstream.<br>
>> <br>
>> <br>
>> Greets Stefan<br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Wed, 8 Mar 2017 09:15:04 -0700<br>
From: Alex Schultz <<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [puppet] puppet-cep beaker test<br>
Message-ID:<br>
<<wbr>CAFsb3b4rG0ribX0bRvcnO6349ydM+<wbr>zv5RsE2=<a href="mailto:X8zoOGMOms9pg@mail.gmail.com" target="_blank">X8zoOGMOms9pg@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Wed, Mar 8, 2017 at 9:02 AM, Scheglmann, Stefan <<a href="mailto:scheglmann@strato.de" target="_blank">scheglmann@strato.de</a>> wrote:<br>
> Hey Alex,<br>
><br>
> thx for the reply, unfortunately it doesn?t seem to work. Adding PUPPET_MAJ_VERSION to the call seems not to have any effect.<br>
><br>
<br>
I just read the bottom part of the original message and it's getting a<br>
14.04 box from puppet-ceph/spec/acceptance/<wbr>nodesets/default.yml. You<br>
could try changing that to 16.04. For our CI we're using the<br>
nodepool-xenial.yml via BEAKER_set=nodepool-xenial.yml but that<br>
assumes you're running on localhost. You could try grabbing the 1604<br>
configuration from puppet-openstack_extras[0] and putting that in your<br>
spec/acceptance/nodesets folder to see if that works for you. Then you<br>
should able to run:<br>
<br>
PUPPET_MAJ_VERSION=4 BEAKER_destroy=no BEAKER_debug=1<br>
BEAKER_set=ubuntu-server-1604-<wbr>x86 bundle exec --verbose rspec<br>
spec/acceptance<br>
<br>
If you run in to more problems, you may want to try hopping on IRC and<br>
we can help you in #puppet-openstack on freenode.<br>
<br>
Thanks,<br>
-Alex<br>
<br>
[0] <a href="https://github.com/openstack/puppet-openstack_extras/blob/master/spec/acceptance/nodesets/ubuntu-server-1604-x64.yml" target="_blank">https://github.com/openstack/<wbr>puppet-openstack_extras/blob/<wbr>master/spec/acceptance/<wbr>nodesets/ubuntu-server-1604-<wbr>x64.yml</a><br>
<br>
<br>
><br>
> Stefan<br>
>> On Tue, Mar 7, 2017 at 7:09 AM, Scheglmann, Stefan <<a href="mailto:scheglmann@strato.de" target="_blank">scheglmann@strato.de</a>> wrote:<br>
>>> Hi,<br>
>>><br>
>>> currently got some problems running the beaker test for the puppet-cep module. Working on OSX using Vagrant version 1.8.6 and VirtualBox version 5.1.14. Call is 'BEAKER_destroy=no BEAKER_debug=1 bundle exec --verbose rspec spec/acceptance? output in <a href="http://pastebin.com/w5ifgrvd" target="_blank">http://pastebin.com/w5ifgrvd</a><br>
>>><br>
>><br>
>> Try running:<br>
>> PUPPET_MAJ_VERSION=4 BEAKER_destroy=no BEAKER_debug=1 bundle exec<br>
>> --verbose rspec spec/acceptance<br>
>><br>
>> Thanks,<br>
>> -Alex<br>
>><br>
><br>
> Tried this, this just changes the trace a bit, now it seems like that it worked in the first place but then failed for the same reason.<br>
> Trace here:<br>
><br>
><br>
>>> Trace:<br>
>>> An error occurred in a `before(:suite)` hook.<br>
>>> Failure/Error: raise CommandFailure, "Host '#{self}' exited with #{result.exit_code} running:\n #{cmdline}\nLast #{@options[:trace_limit]} lines of output were:\n#{result.formatted_<wbr>output(@options[:trace_limit])<wbr>}"<br>
>>> Beaker::Host::CommandFailure:<br>
>>> Host 'first' exited with 127 running:<br>
>>> ZUUL_REF= ZUUL_BRANCH= ZUUL_URL= PUPPET_MAJ_VERSION= bash openstack/puppet-openstack-<wbr>integration/install_modules.sh<br>
>>> Last 10 lines of output were:<br>
>>> + '[' -n 'SHELLOPTS=braceexpand:<wbr>hashall:interactive-comments:<wbr>xtrace<br>
>>> if [ -n "$(set | grep xtrace)" ]; then<br>
>>> local enable_xtrace='\''yes'\'';<br>
>>> if [ -n "${enable_xtrace}" ]; then' ']'<br>
>>> + set +x<br>
>>> ------------------------------<wbr>------------------------------<wbr>--------------------<br>
>>> | Install r10k <wbr> <wbr> |<br>
>>> ------------------------------<wbr>------------------------------<wbr>--------------------<br>
>>> + gem install fast_gettext -v '< 1.2.0'<br>
>>> openstack/puppet-openstack-<wbr>integration/install_modules.<wbr>sh: line 29: gem: command not found<br>
>>><br>
>>> It seems like that the box beaker is using (puppetlabs/ubuntu-14.04-64-<wbr>nocm), somehow ends up with has puppet 4.x installed. I could not exactly pin down how this happens, cause when i sin up some VM just from that base box and install puppet, i end up
with 3.4. But during the beaker tests it ends up with puppet 4 and in puppet 4 some paths have changed. /opt/puppetlabs/bin is just for the 'public' applications and the ?private' ones like gem or ruby are in /opt/puppetlabs/puppet/bin. Therefore the openstack/puppet-openstack-<wbr>integration/install_modules.sh
script fails on installation of r10k, cause it cannot find gem and later on it fails on the r10k call cause it is also installed to /opt/puppetlabs/puppet/bin.<br>
>>> Symlinking gem and r10k in an provisioned machine, and rerun the tests fixes the problem. Currently i am doing all this cause i added some functionalities for the puppet-cep manifests to support bluestone/rocksdb and some additional config params which
i would like to see in upstream.<br>
>>><br>
>>><br>
>>> Greets Stefan<br>
>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Wed, 8 Mar 2017 11:23:50 -0500<br>
From: David Moreau Simard <<a href="mailto:dms@redhat.com" target="_blank">dms@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [tc][appcat] The future of the App<br>
Catalog<br>
Message-ID:<br>
<<a href="mailto:CAH7C%2BPoe%2Bu86P2myBqAybQdcrcAEFTbS0gZapuaXMjXrotGqWA@mail.gmail.com" target="_blank">CAH7C+Poe+<wbr>u86P2myBqAybQdcrcAEFTbS0gZapua<wbr>XMjXrotGqWA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
The App Catalog, to me, sounds sort of like a weird message that<br>
OpenStack somehow requires applications to be<br>
packaged/installed/deployed differently.<br>
If anything, perhaps we should spend more effort on advertising that<br>
OpenStack provides bare metal or virtual compute resources and that<br>
apps will work just like any other places.<br>
<br>
David Moreau Simard<br>
Senior Software Engineer | Openstack RDO<br>
<br>
dmsimard = [irc, github, twitter]<br>
<br>
<br>
On Wed, Mar 8, 2017 at 9:41 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
> On 03/06/2017 06:26 AM, Thierry Carrez wrote:<br>
>><br>
>> Hello everyone,<br>
>><br>
>> The App Catalog was created early 2015 as a marketplace of pre-packaged<br>
>> applications that you can deploy using Murano. Initially a demo by<br>
>> Mirantis, it was converted into an open upstream project team, and<br>
>> deployed as a "beta" as <a href="http://apps.openstack.org" target="_blank">apps.openstack.org</a>.<br>
>><br>
>> Since then it grew additional categories (Glance images, Heat & Tosca<br>
>> templates), but otherwise did not pick up a lot of steam. The website<br>
>> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13<br>
>> heat templates and 94 murano packages (~30% of which are just thin<br>
>> wrappers around Docker containers). Traffic stats show around 100 visits<br>
>> per week, 75% of which only read the index page.<br>
>><br>
>> In parallel, Docker developed a pretty successful containerized<br>
>> application marketplace (the Docker Hub), with hundreds of thousands of<br>
>> regularly-updated apps. Keeping the App Catalog around (including its<br>
>> thinly-wrapped Docker container Murano packages) make us look like we<br>
>> are unsuccessfully trying to compete with that ecosystem, while<br>
>> OpenStack is in fact completely complementary.<br>
>><br>
>> In the past we have retired projects that were dead upstream. The App<br>
>> Catalog is not in this case: it has an active maintenance team, which<br>
>> has been successfully maintaining the framework and accepting<br>
>> applications. If we end up retiring the App Catalog, it would clearly<br>
>> not be a reflection on that team performance, which has been stellar<br>
>> despite limited resources. It would be because the beta was arguably not<br>
>> successful in building an active marketplace of applications, and<br>
>> because its continuous existence is not a great fit from a strategy<br>
>> perspective. Such removal would be a first for our community, but I<br>
>> think it's now time to consider it.<br>
>><br>
>> Before we discuss or decide anything at the TC level, I'd like to<br>
>> collect everyone thoughts (and questions) on this. Please feel free to<br>
>> reply to this thread (or reach out to me privately if you prefer). Thanks<br>
>> !<br>
><br>
><br>
> Mirantis' position is that the App Catalog was a good idea, but we agree<br>
> with you that other application repositories like DockerHub and Quay.io are<br>
> both more useful and more actively used.<br>
><br>
> The OpenStack App Catalog does indeed seem to unnecessarily compete with<br>
> those application repositories, and we would support its retirement if that<br>
> is what the community would like to do. We'll provide resources and help in<br>
> winding anything down if needed.<br>
><br>
> Best,<br>
> -jay<br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Wed, 8 Mar 2017 11:23:50 -0500<br>
From: Brian Rosmaita <<a href="mailto:rosmaita.fossdev@gmail.com" target="_blank">rosmaita.fossdev@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev]<br>
[cinder][glance][horizon][<wbr>keystone][nova][qa][swift] Feedback needed:<br>
Removal of legacy per-project vanity domain redirects<br>
Message-ID: <<a href="mailto:ddb8d3a0-85b3-fd6f-31e1-5724b51b99c3@gmail.com" target="_blank">ddb8d3a0-85b3-fd6f-31e1-<wbr>5724b51b99c3@gmail.com</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
On 3/8/17 10:12 AM, Monty Taylor wrote:<br>
> Hey all,<br>
> <br>
> We have a set of old vanity redirect URLs from back when we made a URL<br>
> for each project:<br>
> <br>
> <a href="http://cinder.openstack.org" target="_blank">cinder.openstack.org</a><br>
> <a href="http://glance.openstack.org" target="_blank">glance.openstack.org</a><br>
> <a href="http://horizon.openstack.org" target="_blank">horizon.openstack.org</a><br>
> <a href="http://keystone.openstack.org" target="_blank">keystone.openstack.org</a><br>
> <a href="http://nova.openstack.org" target="_blank">nova.openstack.org</a><br>
> <a href="http://qa.openstack.org" target="_blank">qa.openstack.org</a><br>
> <a href="http://swift.openstack.org" target="_blank">swift.openstack.org</a><br>
> <br>
> They are being served from an old server we'd like to retire. Obviously,<br>
> moving a set of http redirects is trivial, but these domains have been<br>
> deprecated for about 4 now, so we figured we'd clean house if we can.<br>
> <br>
> We know that the swift team has previously expressed that there are<br>
> links out in the wild pointing to swift.o.o/content that still work and<br>
> that they don't want to break anyone, which is fine. (although if the<br>
> swift team has changed their minds, that's also welcome)<br>
> <br>
> for the rest of you, can we kill these rather than transfer them?<br>
<br>
My concern is that <a href="http://glance.openstack.org" target="_blank">glance.openstack.org</a> is easy to remember and type, so<br>
I imagine there are links out there that we have no control over using<br>
that URL. So what are the consequences of it 404'ing or "site cannot be<br>
reached" in a browser?<br>
<br>
glance.o.o currently redirects to docs.o.o/developer/glance<br>
<br>
If glance.o.o failed for me, I'd next try <a href="http://openstack.org" target="_blank">openstack.org</a> (or<br>
<a href="http://www.openstack.org" target="_blank">www.openstack.org</a>). Those would give me a page with a top bar of links,<br>
one of which is DOCS. If I took that link, I'd get the docs home page.<br>
<br>
There's a search bar there; typing in 'glance' gets me<br>
docs.o.o/developer/glance as the first hit.<br>
<br>
If instead I scroll past the search bar, I have to scroll down to<br>
"Project-Specific Guides" and follow "Services & Libraries" -><br>
"Openstack Services" -> "image service (glance) -> docs.o.o/developer/glance<br>
<br>
Which sounds kind of bad ... until I type "glance docs" into google.<br>
Right now the first hit is docs.o.o/developer/glance. And all the kids<br>
these days use the google. So by trying to be clever and hack the URL,<br>
I could get lost, but if I just google 'glance docs', I find what I'm<br>
looking for right away.<br>
<br>
So I'm willing to go with the majority on this, with the caveat that if<br>
one or two teams keep the redirect, it's going to be confusing to end<br>
users if the redirect doesn't work for other projects.<br>
<br>
cheers,<br>
brian<br>
<br>
> <br>
> Thanks!<br>
> Monty<br>
> <br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> <br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Wed, 8 Mar 2017 16:27:56 +0000 (GMT)<br>
From: Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org" target="_blank">cdent+os@anticdent.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova][placement-api] Is there any<br>
document about openstack-placement-api for installation and configure?<br>
Message-ID: <alpine.OSX.2.20.<wbr>1703081625580.59117@shine.<wbr>local><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On Wed, 8 Mar 2017, Yu Wei wrote:<br>
<br>
> It seems that nova-placement-api acts as a CGI module.<br>
><br>
> Is it?<br>
<br>
It's a WSGI application module, which is configured and accessed via<br>
some mod wsgi configuration settings, if you're using mod_wsgi with<br>
apache2:<br>
<br>
<a href="https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html" target="_blank">https://modwsgi.readthedocs.<wbr>io/en/develop/configuration-<wbr>directives/WSGIDaemonProcess.<wbr>html</a><br>
<a href="https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIScriptAlias.html" target="_blank">https://modwsgi.readthedocs.<wbr>io/en/develop/configuration-<wbr>directives/WSGIScriptAlias.<wbr>html</a><br>
<br>
It's a similar concept with other WSGI servers.<br>
<br>
-- <br>
Chris Dent ?\_(?)_/? <a href="https://anticdent.org/" target="_blank">https://anticdent.org/</a><br>
freenode: cdent <wbr> tw: @anticdent<br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Wed, 8 Mar 2017 16:31:23 +0000<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev]<br>
[cinder][glance][horizon][<wbr>keystone][nova][qa][swift] Feedback needed:<br>
Removal of legacy per-project vanity domain redirects<br>
Message-ID: <<a href="mailto:20170308163123.GT7470@redhat.com" target="_blank">20170308163123.GT7470@redhat.<wbr>com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On Wed, Mar 08, 2017 at 09:12:59AM -0600, Monty Taylor wrote:<br>
> Hey all,<br>
> <br>
> We have a set of old vanity redirect URLs from back when we made a URL<br>
> for each project:<br>
> <br>
> <a href="http://cinder.openstack.org" target="_blank">cinder.openstack.org</a><br>
> <a href="http://glance.openstack.org" target="_blank">glance.openstack.org</a><br>
> <a href="http://horizon.openstack.org" target="_blank">horizon.openstack.org</a><br>
> <a href="http://keystone.openstack.org" target="_blank">keystone.openstack.org</a><br>
> <a href="http://nova.openstack.org" target="_blank">nova.openstack.org</a><br>
> <a href="http://qa.openstack.org" target="_blank">qa.openstack.org</a><br>
> <a href="http://swift.openstack.org" target="_blank">swift.openstack.org</a><br>
> <br>
> They are being served from an old server we'd like to retire. Obviously,<br>
> moving a set of http redirects is trivial, but these domains have been<br>
> deprecated for about 4 now, so we figured we'd clean house if we can.<br>
> <br>
> We know that the swift team has previously expressed that there are<br>
> links out in the wild pointing to swift.o.o/content that still work and<br>
> that they don't want to break anyone, which is fine. (although if the<br>
> swift team has changed their minds, that's also welcome)<br>
> <br>
> for the rest of you, can we kill these rather than transfer them?<br>
<br>
Does the server have any access log that could provide stats on whether<br>
any of the subdomains are a receiving a meaningful amount of traffic ?<br>
Easy to justify removing them if they're not seeing any real traffic.<br>
<br>
If there's any referrer logs present, that might highlight which places<br>
still have outdated links that need updating to kill off remaining<br>
traffic.<br>
<br>
Regards,<br>
Daniel<br>
-- <br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/<wbr>dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> <wbr> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> <wbr> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~<wbr>danberr/</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Thu, 9 Mar 2017 00:50:56 +0800<br>
From: Jeffrey Zhang <<a href="mailto:zhang.lei.fly@gmail.com" target="_blank">zhang.lei.fly@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Cc: openstack <<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><wbr>><br>
Subject: Re: [openstack-dev] [kolla][ubuntu][libvirt] Is libvirt 2.5.0<br>
in ubuntu cloud archive ocata repo bust<br>
Message-ID:<br>
<CAATxhGe9fo7PDr_<wbr>WGapp85LKz4Uj9LdMPVRzz=<a href="mailto:qZd0ub2d2_Yw@mail.gmail.com" target="_blank">qZd0ub2<wbr>d2_Yw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thanks Corey, But i tried ocata proposed repo, the issue is still happening.<br>
<br>
On Wed, Mar 8, 2017 at 10:03 PM, Corey Bryant <<a href="mailto:corey.bryant@canonical.com" target="_blank">corey.bryant@canonical.com</a>><br>
wrote:<br>
<br>
><br>
><br>
> On Tue, Mar 7, 2017 at 10:28 PM, Jeffrey Zhang <<a href="mailto:zhang.lei.fly@gmail.com" target="_blank">zhang.lei.fly@gmail.com</a>><br>
> wrote:<br>
><br>
>> Kolla deploy ubuntu gate is red now. here is the related bug[0].<br>
>><br>
>> libvirt failed to access the console.log file when booting instance. After<br>
>> made some debugging, i got following.<br>
>><br>
>><br>
> Jeffrey, This is likely fixed in ocata-proposed and should be promoted to<br>
> ocata-updates soon after testing completes. <a href="https://bugs.launchpad.net/" target="_blank">https://bugs.launchpad.net/</a><br>
> ubuntu/+source/libvirt/+bug/<wbr>1667033.<br>
><br>
> Corey<br>
><br>
><br>
> # how console.log works<br>
>> nova create a empty console.log with nova:nova ( this is another bug<br>
>> workaround actually[1]), then libvirt ( running with root ) will change<br>
>> the<br>
>> file owner to qemu process user/group ( configured by dynamic_ownership<br>
>> ).<br>
>> Now qemu process can write logs into this file.<br>
>><br>
>> # what's wrong now<br>
>> libvirt 2.5.0 stop change the file owner, then qemu/libvirt failed to<br>
>> write<br>
>> logs into console.log file<br>
>><br>
>> # other test<br>
>><br>
>> * ubuntu + fallback libvirt 1.3.x works [2]<br>
>> * ubuntu + libvirt 2.5.0 + chang the qemu process user/group to<br>
>> nova:nova works, too.[3]<br>
>> * centos + libvirt 2.0.0 works, never saw such issue in centos.<br>
>><br>
>> # conclusion<br>
>> I guess there are something wrong in libvirt 2.5.0 with dynamic_ownership<br>
>><br>
>><br>
>> [0] <a href="https://bugs.launchpad.net/kolla-ansible/+bug/1668654" target="_blank">https://bugs.launchpad.net/<wbr>kolla-ansible/+bug/1668654</a><br>
>> [1] <a href="https://github.com/openstack/nova/blob/master/nova/virt/" target="_blank">https://github.com/openstack/<wbr>nova/blob/master/nova/virt/</a><br>
>> libvirt/driver.py#L2922,L2952<br>
>> [2] <a href="https://review.openstack.org/442673" target="_blank">https://review.openstack.org/<wbr>442673</a><br>
>> [3] <a href="https://review.openstack.org/442850" target="_blank">https://review.openstack.org/<wbr>442850</a><br>
>><br>
>> --<br>
>> Regards,<br>
>> Jeffrey Zhang<br>
>> Blog: <a href="http://xcodest.me" target="_blank">http://xcodest.me</a><br>
>><br>
>> ______________________________<wbr>______________________________<br>
>> ______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscrib" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscrib</a><br>
>> e<br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
>><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
<br>
<br>
-- <br>
Regards,<br>
Jeffrey Zhang<br>
Blog: <a href="http://xcodest.me" target="_blank">http://xcodest.me</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170309/8cf01a23/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170309/8cf01a23/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 32<br>
Date: Wed, 8 Mar 2017 12:08:11 -0500<br>
From: James Slagle <<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [TripleO][Heat] Selectively disabling<br>
deployment resources<br>
Message-ID:<br>
<CAHV77z9oPkjrZ=e1TMJLDC3PZS=<wbr>df01NEA1_ihAee=<a href="mailto:ymbz-X-Q@mail.gmail.com" target="_blank">ymbz-X-Q@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Wed, Mar 8, 2017 at 4:08 AM, Steven Hardy <<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>> wrote:<br>
> On Tue, Mar 07, 2017 at 02:34:50PM -0500, James Slagle wrote:<br>
>> I've been working on this spec for TripleO:<br>
>> <a href="https://review.openstack.org/#/c/431745/" target="_blank">https://review.openstack.org/#<wbr>/c/431745/</a><br>
>><br>
>> which allows users to selectively disable Heat deployment resources<br>
>> for a given server (or server in the case of a *DeloymentGroup<br>
>> resource).<br>
>><br>
>> Some of the main use cases in TripleO for such a feature are scaling<br>
>> out compute nodes where you do not need to rerun Puppet (or make any<br>
>> changes at all) on non-compute nodes, or to exclude nodes from hanging<br>
>> a stack-update if you know they are unreachable or degraded for some<br>
>> reason. There are others, but those are 2 of the major use cases.<br>
><br>
> Thanks for raising this, I know it's been a pain point for some users of<br>
> TripleO.<br>
><br>
> However I think we're conflating two different issues here:<br>
><br>
> 1. Don't re-run puppet (or yum update) when no other changes have happened<br>
><br>
> 2. Disable deployment resources when changes have happened<br>
<br>
Yea, possibly, but (1) doesn't really solve the use cases in the spec.<br>
It'd certainly be a small improvement, but it's not really what users<br>
are asking for.<br>
<br>
(2) is much more difficult to reason about because we in fact have to<br>
execute puppet to fully determine if changes have happened.<br>
<br>
I don't really think these two are conflated. For some purposes, the<br>
2nd is just a more abstract definition of the first. For better or<br>
worse, part of the reason people are asking for this feature is<br>
because they don't want to undo manual changes. While that's not<br>
something we should really spend a lot of time solving for, the fact<br>
is that OpenStack architecture allows for horizontally scaling compute<br>
nodes without have to touch every other single node in your deployment<br>
but TripleO can't take advantage of that.<br>
<br>
So, just giving users a way to opt out of the generated unique<br>
identifier triggering the puppet applys and other deployments,<br>
wouldn't help them if they unintentionally changed some other hiera<br>
data that triggers a deployment.<br>
<br>
Plus, we have some deployments that are going to execute every time<br>
outside of unique identifiers being generated (hosts-config.yaml).<br>
<br>
> (1) is actually very simple, and is the default behavior of Heat<br>
> (SoftwareDeployment resources never update unless either the config<br>
> referenced or the input_values change). We just need to provide an option<br>
> to disable the DeployIdentifier/<wbr>UpdateIdentifier timestamps from being<br>
> generated in tripleoclient.<br>
><br>
> (2) is harder, because the whole point of SoftwareDeploymentGroup is to run<br>
> the exact same configuration on a group of servers, with no exceptions.<br>
><br>
> As Zane mentions (2) is related to the way ResourceGroup works, but the<br>
> problem here isn't ResourceGroup per-se, as it would in theory be pretty<br>
> easy to reimplement SoftwareDeploymentGroup to generate it's nested stack<br>
> without inheriting from ResourceGroup (which may be needed if you want a<br>
> flag to make existing Deployments in the group immutable).<br>
><br>
> I'd suggest we solve (1) and do some testing, it may be enough to solve the<br>
> "don't change computes on scale-out" case at least?<br>
<br>
Possibly, as long as no other deployments are triggered. I think of<br>
the use case more as:<br>
<br>
add a compute node(s), don't touch any existing nodes to minimize risk<br>
<br>
as opposed to:<br>
<br>
add a compute node(s), don't re-run puppet on any existing nodes as I<br>
know that it's not needed<br>
<br>
For the scale out case, the desire to minimize risk is a big part of<br>
why other nodes don't need to be touched.<br>
<br>
><br>
> One way to potentially solve (2) would be to unroll the<br>
> SoftwareDeploymentGroup resources and instead generate the Deployment<br>
> resources via jinja2 - this would enable completely removing them on update<br>
> if that's what is desired, similar to what we already do for upgrades to<br>
> e.g not upgrade any compute nodes.<br>
<br>
Thanks, I hadn't considered that approach, but will look into it. I'd<br>
guess you'd still need a parameter or map data fed into the jinja2<br>
templating, so that it would not generate the deployment resources<br>
based on what was desired to be disabled. Or, this could use<br>
conditionals perhaps.<br>
<br>
<br>
<br>
-- <br>
-- James Slagle<br>
--<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 33<br>
Date: Wed, 8 Mar 2017 09:33:29 -0800<br>
From: "Armando M." <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron] [infra] Depends-on tag effect<br>
Message-ID:<br>
<<a href="mailto:CAK%2BRQeao6355sxRxDiOcfy18VaarTndyiypzXy1z1TB6dbJcVQ@mail.gmail.com" target="_blank">CAK+<wbr>RQeao6355sxRxDiOcfy18VaarTndyi<wbr>ypzXy1z1TB6dbJcVQ@mail.gmail.<wbr>com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On 8 March 2017 at 07:39, Hirofumi Ichihara <<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.<wbr>jp</a><br>
> wrote:<br>
<br>
><br>
><br>
> On 2017/03/08 23:59, Andreas Jaeger wrote:<br>
><br>
>> On 2017-03-08 15:40, ZZelle wrote:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> iiuc, neutron uses a released version of neutron-lib not neutron-lib<br>
>>> master ... So the change should depends on a change in requirements repo<br>
>>> incrementing neutron-lib version<br>
>>><br>
>> This is documented also at - together with some other caveats:<br>
>><br>
>> <a href="https://docs.openstack.org/infra/manual/developers.html#limi" target="_blank">https://docs.openstack.org/<wbr>infra/manual/developers.html#<wbr>limi</a><br>
>> tations-and-caveats<br>
>><br>
> Thank you for the pointer. I understand.<br>
<br>
<br>
You can do the reverse as documented in [1]: i.e. file a dummy patch<br>
against neutron-lib that pulls in both neutron's and neutron-lib changes.<br>
One example is [2]<br>
<br>
[1] <a href="https://docs.openstack.org/developer/neutron-lib/review-guidelines.html" target="_blank">https://docs.openstack.org/<wbr>developer/neutron-lib/review-<wbr>guidelines.html</a><br>
[2] <a href="https://review.openstack.org/#/c/386846/" target="_blank">https://review.openstack.org/#<wbr>/c/386846/</a><br>
<br>
<br>
><br>
> Hirofumi<br>
><br>
><br>
><br>
>><br>
>> Note a depends-on requirements won't work either - you really need to<br>
>> release it. Or you need to change the test to pull neutron-lib from<br>
>> source,<br>
>><br>
>> Andreas<br>
>><br>
>>> On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara<br>
>>> <<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.<wbr>jp</a><br>
>>> <mailto:<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.<wbr>ntt.co.jp</a>>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I thought that we can post neutron patch depending on neutron-lib<br>
>>> patch under review.<br>
>>> However, I saw it doesn't work[1, 2]. In the patches, neutron<br>
>>> patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8<br>
>>> and unit test fails because the test doesn't use the neutron-lib<br>
>>> patch.<br>
>>><br>
>>> Please correct me if it's my misunderstanding.<br>
>>><br>
>>> [1]: <a href="https://review.openstack.org/#/c/424340/" target="_blank">https://review.openstack.org/#<wbr>/c/424340/</a><br>
>>> <<a href="https://review.openstack.org/#/c/424340/" target="_blank">https://review.openstack.org/<wbr>#/c/424340/</a>><br>
>>> [2]: <a href="https://review.openstack.org/#/c/424868/" target="_blank">https://review.openstack.org/#<wbr>/c/424868/</a><br>
>>> <<a href="https://review.openstack.org/#/c/424868/" target="_blank">https://review.openstack.org/<wbr>#/c/424868/</a>><br>
>>><br>
>>> Thanks,<br>
>>> Hirofumi<br>
>>><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_____________________________<br>
>>> _______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>> <<a href="http://OpenStack-dev-request@lists.openstack.org" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org</a>?<br>
>>> subject:unsubscribe><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> ______________________________<wbr>______________________________<br>
>>> ______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: OpenStack-dev-request@lists.op<br>
>>> <a href="http://enstack.org?subject:unsubscribe" target="_blank">enstack.org?subject:<wbr>unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>><br>
>>><br>
>><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/b2c20643/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/b2c20643/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 34<br>
Date: Wed, 8 Mar 2017 12:38:01 -0500<br>
From: Jim Rollenhagen <<a href="mailto:jim@jimrollenhagen.com" target="_blank">jim@jimrollenhagen.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [ironic] OpenStack client default ironic<br>
API version<br>
Message-ID:<br>
<CAJCXu8eXJwEH_r-<wbr>iPFFUzTMJa9Gq7QUqmtR74s6KFrKW=<a href="mailto:2%2BAyQ@mail.gmail.com" target="_blank"><wbr>2+AyQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Wed, Mar 8, 2017 at 9:05 AM, Mario Villaplana <<a href="mailto:mario.villaplana@gmail.com" target="_blank">mario.villaplana@gmail.com</a><br>
> wrote:<br>
<br>
> We want to deprecate ironic CLI soon, but I would prefer if that were<br>
> discussed on a separate thread if possible, aside from concerns about<br>
> versioning in ironic CLI. Feature parity should exist in Pike, then we<br>
> can issue a warning in Queens and deprecate the cycle after. More<br>
> information is on L56:<br>
> <a href="https://etherpad.openstack.org/p/ironic-pike-ptg-operations" target="_blank">https://etherpad.openstack.<wbr>org/p/ironic-pike-ptg-<wbr>operations</a><br>
><br>
> I'm a bit torn on whether to use the API version coded in the OSC<br>
> plugin or not. On one hand, it'd be good to be able to test out new<br>
> features as soon as they're available. On the other hand, it's<br>
> possible that the client won't know how to parse certain items after a<br>
> microversion bump. I think I prefer using the hard-coded version to<br>
> avoid breakage, but we'd have to be disciplined about updating the<br>
> client when the API version is bumped (if needed). Opinions on this<br>
> are welcome. In either case, I think the deprecation warning could<br>
> land without specifying that.<br>
><br>
<br>
I agree, I think we should pin it, otherwise it's one more hump to<br>
overcome when we do want to make a breaking change.<br>
<br>
FWIW, nova pins (both clients) to the max the client knows about,<br>
specifically for this reason:<br>
<a href="https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/client.py#L52-L57" target="_blank">https://github.com/openstack/<wbr>python-openstackclient/blob/<wbr>master/openstackclient/<wbr>compute/client.py#L52-L57</a><br>
<a href="https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L23-L28" target="_blank">https://github.com/openstack/<wbr>python-novaclient/blob/master/<wbr>novaclient/__init__.py#L23-L28</a><br>
<br>
<br>
> I'll certainly make an RFE when I update the patch later this week,<br>
> great suggestion.<br>
><br>
> I can make a spec, but it might be mostly empty except for the client<br>
> impact section. Also, this is a < 40 line change. :)<br>
><br>
<br>
I tend to think a spec is a bit overkill for this, but I won't deny Ruby's<br>
request.<br>
Ping me when it's up and I'm happy to review it ASAP.<br>
<br>
// jim<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/275471ee/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/275471ee/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 35<br>
Date: Wed, 8 Mar 2017 17:42:02 +0000<br>
From: "Fox, Kevin M" <<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [tc][appcat] The future of the App<br>
Catalog<br>
Message-ID:<br>
<<a href="mailto:1A3C52DFCD06494D8528644858247BF01BECDB80@EX10MBOX03.pnnl.gov" target="_blank">1A3C52DFCD06494D8528644858247<wbr>BF01BECDB80@EX10MBOX03.pnnl.<wbr>gov</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
For the OpenStack Applications Catalog to be successful in its mission, it required other parts of OpenStack to consider the use case a priority. Over the years it became quite clear to me that a significant part of the OpenStack community does not want OpenStack
to become a place where cloud native applications would be built/packaged/provided to users using OpenStacks apis but instead just a place to run virtual machines on which you might deploy a cloud native platform to handle that use case. As time goes on, and
COE's gain multitenancy, I see a big contraction in the number of OpenStack deployments or deployed node count and a shifting of OpenStack based workloads more towards managing pet vm's, as the cloud native stuff moves more and more towards containers/COE's
which don't actually need vm's.<br>
<br>
This I think will bring the issue to a head in the OpenStack community soon. What is OpenStack? Is it purely an IaaS implementation? Its pretty good at that now. But something that will be very niche soon I think. Is it an Cloud Operating system? The community
seems to have made that a resounding no. Is it an OpenSource competitor to AWS? Today, its getting further and further behind in that. If nothing changes, that will be impossible.<br>
<br>
My 2 cents? I think the world does need an OpenSource implementation of what AWS provides. That can't happen on the path we're all going down now. We're struggling with division of vision between the two ideologies and lack of decision around a COE, causing
us to spend a huge amount of effort on things like Trove/Sahara/etc to reproduce functionality in AWS, but not being as agile as AWS so we can't ever make headway. If we want to be an OpenSource AWS competitor, that requires us to make some hard calls, pick
a COE (Kubernetes has won that space I believe), start integrating it quickly, and retool advanced services like Trove/Sahara/etc to target the COE rather then VM's for deployment. This should greatly enhance our ability to produce functional solutions quickly.<br>
<br>
But, its ultimately the Community who decide what OpenStack will become. If we're ok with the path its headed down, to basically just be an IaaS, that's fine with me. I'd just like it to be a conscious decision rather then one that just happens. If thats the
way it goes, lets just decide on it now, and let the folks that are spinning their wheels move on to a system that will help them make headway in their goals. It will be better for everyone.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
______________________________<wbr>__________<br>
From: David Moreau Simard [<a href="mailto:dms@redhat.com" target="_blank">dms@redhat.com</a>]<br>
Sent: Wednesday, March 08, 2017 8:23 AM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog<br>
<br>
The App Catalog, to me, sounds sort of like a weird message that<br>
OpenStack somehow requires applications to be<br>
packaged/installed/deployed differently.<br>
If anything, perhaps we should spend more effort on advertising that<br>
OpenStack provides bare metal or virtual compute resources and that<br>
apps will work just like any other places.<br>
<br>
David Moreau Simard<br>
Senior Software Engineer | Openstack RDO<br>
<br>
dmsimard = [irc, github, twitter]<br>
<br>
<br>
On Wed, Mar 8, 2017 at 9:41 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
> On 03/06/2017 06:26 AM, Thierry Carrez wrote:<br>
>><br>
>> Hello everyone,<br>
>><br>
>> The App Catalog was created early 2015 as a marketplace of pre-packaged<br>
>> applications that you can deploy using Murano. Initially a demo by<br>
>> Mirantis, it was converted into an open upstream project team, and<br>
>> deployed as a "beta" as <a href="http://apps.openstack.org" target="_blank">apps.openstack.org</a>.<br>
>><br>
>> Since then it grew additional categories (Glance images, Heat & Tosca<br>
>> templates), but otherwise did not pick up a lot of steam. The website<br>
>> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13<br>
>> heat templates and 94 murano packages (~30% of which are just thin<br>
>> wrappers around Docker containers). Traffic stats show around 100 visits<br>
>> per week, 75% of which only read the index page.<br>
>><br>
>> In parallel, Docker developed a pretty successful containerized<br>
>> application marketplace (the Docker Hub), with hundreds of thousands of<br>
>> regularly-updated apps. Keeping the App Catalog around (including its<br>
>> thinly-wrapped Docker container Murano packages) make us look like we<br>
>> are unsuccessfully trying to compete with that ecosystem, while<br>
>> OpenStack is in fact completely complementary.<br>
>><br>
>> In the past we have retired projects that were dead upstream. The App<br>
>> Catalog is not in this case: it has an active maintenance team, which<br>
>> has been successfully maintaining the framework and accepting<br>
>> applications. If we end up retiring the App Catalog, it would clearly<br>
>> not be a reflection on that team performance, which has been stellar<br>
>> despite limited resources. It would be because the beta was arguably not<br>
>> successful in building an active marketplace of applications, and<br>
>> because its continuous existence is not a great fit from a strategy<br>
>> perspective. Such removal would be a first for our community, but I<br>
>> think it's now time to consider it.<br>
>><br>
>> Before we discuss or decide anything at the TC level, I'd like to<br>
>> collect everyone thoughts (and questions) on this. Please feel free to<br>
>> reply to this thread (or reach out to me privately if you prefer). Thanks<br>
>> !<br>
><br>
><br>
> Mirantis' position is that the App Catalog was a good idea, but we agree<br>
> with you that other application repositories like DockerHub and Quay.io are<br>
> both more useful and more actively used.<br>
><br>
> The OpenStack App Catalog does indeed seem to unnecessarily compete with<br>
> those application repositories, and we would support its retirement if that<br>
> is what the community would like to do. We'll provide resources and help in<br>
> winding anything down if needed.<br>
><br>
> Best,<br>
> -jay<br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 36<br>
Date: Wed, 8 Mar 2017 17:52:43 +0000<br>
From: "Kwasniewska, Alicja" <<a href="mailto:alicja.kwasniewska@intel.com" target="_blank">alicja.kwasniewska@intel.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [kolla] Proposing duonghq for core<br>
Message-ID: <<a href="mailto:E5DE2A5A-DCA7-4900-BFB7-4849CE6D9DAF@intel.com" target="_blank">E5DE2A5A-DCA7-4900-BFB7-<wbr>4849CE6D9DAF@intel.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1<br>
<br>
From: Mauricio Lima <<a href="mailto:mauriciolimab@gmail.com" target="_blank">mauriciolimab@gmail.com</a><<wbr>mailto:<a href="mailto:mauriciolimab@gmail.com" target="_blank">mauriciolimab@gmail.com</a><wbr>>><br>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack<wbr>-dev@lists.openstack.org</a>>><br>
Date: Wednesday, March 8, 2017 at 5:34 AM<br>
To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack<wbr>-dev@lists.openstack.org</a>>><br>
Subject: Re: [openstack-dev] [kolla] Proposing duonghq for core<br>
<br>
+1<br>
<br>
2017-03-08 7:34 GMT-03:00 Christian Berendt <<a href="mailto:berendt@betacloud-solutions.de" target="_blank">berendt@betacloud-solutions.<wbr>de</a><mailto:<a href="mailto:berendt@betacloud-solutions.de" target="_blank">berendt@betacloud-<wbr>solutions.de</a>>>:<br>
+1<br>
<br>
> On 8 Mar 2017, at 07:41, Micha? Jastrz?bski <<a href="mailto:inc007@gmail.com" target="_blank">inc007@gmail.com</a><mailto:<a href="mailto:inc007@gmail.com" target="_blank">inc00<wbr>7@gmail.com</a>>> wrote:<br>
><br>
> Hello,<br>
><br>
> I'd like to start voting to include Duong (duonghq) in Kolla and<br>
> Kolla-ansible core teams. Voting will be open for 2 weeks (ends at<br>
> 21st of March).<br>
><br>
> Consider this my +1 vote.<br>
><br>
> Cheers,<br>
> Michal<br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-<wbr>dev-request@lists.openstack.<wbr>org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
--<br>
Christian Berendt<br>
Chief Executive Officer (CEO)<br>
<br>
Mail: <a href="mailto:berendt@betacloud-solutions.de" target="_blank">berendt@betacloud-solutions.de</a><wbr><mailto:<a href="mailto:berendt@betacloud-solutions.de" target="_blank">berendt@betacloud-<wbr>solutions.de</a>><br>
Web: <a href="https://www.betacloud-solutions.de" target="_blank">https://www.betacloud-<wbr>solutions.de</a><br>
<br>
Betacloud Solutions GmbH<br>
Teckstrasse 62 / 70190 Stuttgart / Deutschland<br>
<br>
Gesch?ftsf?hrer: Christian Berendt<br>
Unternehmenssitz: Stuttgart<br>
Amtsgericht: Stuttgart, HRB 756139<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-<wbr>dev-request@lists.openstack.<wbr>org?subject:unsubscribe</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/9a7973c9/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/9a7973c9/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 37<br>
Date: Wed, 8 Mar 2017 13:17:14 -0500<br>
From: Corey Bryant <<a href="mailto:corey.bryant@canonical.com" target="_blank">corey.bryant@canonical.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Cc: openstack <<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><wbr>><br>
Subject: Re: [openstack-dev] [kolla][ubuntu][libvirt] Is libvirt 2.5.0<br>
in ubuntu cloud archive ocata repo bust<br>
Message-ID:<br>
<CADn0iZ1aS=<a href="mailto:riCG1_nqWi9X8OPU5VPMt0DkfCxk2TE5C2izc1yQ@mail.gmail.com" target="_blank">riCG1_<wbr>nqWi9X8OPU5VPMt0DkfCxk2TE5C2iz<wbr>c1yQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Wed, Mar 8, 2017 at 11:50 AM, Jeffrey Zhang <<a href="mailto:zhang.lei.fly@gmail.com" target="_blank">zhang.lei.fly@gmail.com</a>><br>
wrote:<br>
<br>
> Thanks Corey, But i tried ocata proposed repo, the issue is still<br>
> happening.<br>
><br>
<br>
In that case, would you mind opening a bug if you haven't already?<br>
<br>
Thanks,<br>
Corey<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/1ae05ae9/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/1ae05ae9/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 38<br>
Date: Wed, 8 Mar 2017 18:29:52 +0000<br>
From: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [infra][tripleo] initial discussion for a<br>
new periodic pipeline<br>
Message-ID: <<a href="mailto:20170308182952.GG12827@yuggoth.org" target="_blank">20170308182952.GG12827@<wbr>yuggoth.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On 2017-03-07 10:12:58 -0500 (-0500), Wesley Hayutin wrote:<br>
> The TripleO team would like to initiate a conversation about the<br>
> possibility of creating a new pipeline in Openstack Infra to allow<br>
> a set of jobs to run periodically every four hours<br>
[...]<br>
<br>
The request doesn't strike me as contentious/controversial. Why not<br>
just propose your addition to the zuul/layout.yaml file in the<br>
openstack-infra/project-config repo and hash out any resulting<br>
concerns via code review?<br>
-- <br>
Jeremy Stanley<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 39<br>
Date: Wed, 8 Mar 2017 13:03:58 -0600<br>
From: Matthew Thode <<a href="mailto:prometheanfire@gentoo.org" target="_blank">prometheanfire@gentoo.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] [requirements] pycrypto is dead, long live<br>
pycryptodome... or cryptography...<br>
Message-ID: <<a href="mailto:cba43a52-7c71-5ad0-15c1-5127ff4c302e@gentoo.org" target="_blank">cba43a52-7c71-5ad0-15c1-<wbr>5127ff4c302e@gentoo.org</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
So, pycrypto upstream is dead and has been for a while, we should look<br>
at moving off of it for both bugfix and security reasons.<br>
<br>
Currently it's used by the following.<br>
<br>
barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,<br>
kolla, openstack-ansible, and a couple of other smaller places.<br>
<br>
Development of it was forked into pycryptodome, which is supposed to be<br>
a drop in replacement. The problem is that due to co-installability<br>
requirements we can't have half of packages out there using pycrypto and<br>
the other half using pycryptodome. We'd need to hard switch everyone as<br>
both packages install into the same namespace.<br>
<br>
Another alternative would be to use something like cryptography instead,<br>
though it is not a drop in replacement, the migration would be able to<br>
be done piecemeal.<br>
<br>
I'd be interested in hearing about migration plans, especially from the<br>
affected projects.<br>
<br>
-- <br>
Matthew Thode (prometheanfire)<br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 833 bytes<br>
Desc: OpenPGP digital signature<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/60a34707/attachment-0001.pgp" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/60a34707/<wbr>attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 40<br>
Date: Wed, 8 Mar 2017 20:04:10 +0100<br>
From: Andreas Jaeger <<a href="mailto:aj@suse.com" target="_blank">aj@suse.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev]<br>
[cinder][glance][horizon][<wbr>keystone][nova][qa][swift] Feedback needed:<br>
Removal of legacy per-project vanity domain redirects<br>
Message-ID: <<a href="mailto:9617a5f5-2f01-c713-c1bf-86c6308422f3@suse.com" target="_blank">9617a5f5-2f01-c713-c1bf-<wbr>86c6308422f3@suse.com</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
On 2017-03-08 17:23, Brian Rosmaita wrote:<br>
> On 3/8/17 10:12 AM, Monty Taylor wrote:<br>
>> Hey all,<br>
>><br>
>> We have a set of old vanity redirect URLs from back when we made a URL<br>
>> for each project:<br>
>><br>
>> <a href="http://cinder.openstack.org" target="_blank">cinder.openstack.org</a><br>
>> <a href="http://glance.openstack.org" target="_blank">glance.openstack.org</a><br>
>> <a href="http://horizon.openstack.org" target="_blank">horizon.openstack.org</a><br>
>> <a href="http://keystone.openstack.org" target="_blank">keystone.openstack.org</a><br>
>> <a href="http://nova.openstack.org" target="_blank">nova.openstack.org</a><br>
>> <a href="http://qa.openstack.org" target="_blank">qa.openstack.org</a><br>
>> <a href="http://swift.openstack.org" target="_blank">swift.openstack.org</a><br>
>><br>
>> They are being served from an old server we'd like to retire. Obviously,<br>
>> moving a set of http redirects is trivial, but these domains have been<br>
>> deprecated for about 4 now, so we figured we'd clean house if we can.<br>
>><br>
>> We know that the swift team has previously expressed that there are<br>
>> links out in the wild pointing to swift.o.o/content that still work and<br>
>> that they don't want to break anyone, which is fine. (although if the<br>
>> swift team has changed their minds, that's also welcome)<br>
>><br>
>> for the rest of you, can we kill these rather than transfer them?<br>
> <br>
> My concern is that <a href="http://glance.openstack.org" target="_blank">glance.openstack.org</a> is easy to remember and type, so<br>
> I imagine there are links out there that we have no control over using<br>
> that URL. So what are the consequences of it 404'ing or "site cannot be<br>
> reached" in a browser?<br>
> <br>
> glance.o.o currently redirects to docs.o.o/developer/glance<br>
> <br>
> If glance.o.o failed for me, I'd next try <a href="http://openstack.org" target="_blank">openstack.org</a> (or<br>
> <a href="http://www.openstack.org" target="_blank">www.openstack.org</a>). Those would give me a page with a top bar of links,<br>
> one of which is DOCS. If I took that link, I'd get the docs home page.<br>
> <br>
> There's a search bar there; typing in 'glance' gets me<br>
> docs.o.o/developer/glance as the first hit.<br>
> <br>
> If instead I scroll past the search bar, I have to scroll down to<br>
> "Project-Specific Guides" and follow "Services & Libraries" -><br>
> "Openstack Services" -> "image service (glance) -> docs.o.o/developer/glance<br>
> <br>
> Which sounds kind of bad ... until I type "glance docs" into google.<br>
> Right now the first hit is docs.o.o/developer/glance. And all the kids<br>
> these days use the google. So by trying to be clever and hack the URL,<br>
> I could get lost, but if I just google 'glance docs', I find what I'm<br>
> looking for right away.<br>
> <br>
> So I'm willing to go with the majority on this, with the caveat that if<br>
> one or two teams keep the redirect, it's going to be confusing to end<br>
> users if the redirect doesn't work for other projects.<br>
<br>
Very few people know about these URLs at all and there are only a few<br>
places that use it in openstack (I just send a few patches for those).<br>
If you google for "openstack glance", you won't get this URL at all,<br>
<br>
Andreas<br>
-- <br>
Andreas Jaeger aj@{<a href="http://suse.com" target="_blank">suse.com</a>,<a href="http://opensuse.org" target="_blank">opensuse.org</a>} Twitter: jaegerandi<br>
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany<br>
GF: Felix Imend?rffer, Jane Smithard, Graham Norton,<br>
HRB 21284 (AG N?rnberg)<br>
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 41<br>
From: <a href="mailto:no-reply@openstack.org" target="_blank">no-reply@openstack.org</a><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: [openstack-dev] [kolla] kolla 4.0.0.0rc2 (ocata)<br>
Message-ID:<br>
<<a href="mailto:mailman.43.1489001100.16299.openstack-dev@lists.openstack.org" target="_blank">mailman.43.1489001100.16299.<wbr>openstack-dev@lists.openstack.<wbr>org</a>><br>
<br>
<br>
Hello everyone,<br>
<br>
A new release candidate for kolla for the end of the Ocata<br>
cycle is available! You can find the source code tarball at:<br>
<br>
<a href="https://tarballs.openstack.org/kolla/" target="_blank">https://tarballs.openstack.<wbr>org/kolla/</a><br>
<br>
Unless release-critical issues are found that warrant a release<br>
candidate respin, this candidate will be formally released as the<br>
final Ocata release. You are therefore strongly<br>
encouraged to test and validate this tarball!<br>
<br>
Alternatively, you can directly test the stable/ocata release<br>
branch at:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/kolla/log/?h=stable/ocata" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/kolla/log/?h=stable/<wbr>ocata</a><br>
<br>
Release notes for kolla can be found at:<br>
<br>
<a href="http://docs.openstack.org/releasenotes/kolla/" target="_blank">http://docs.openstack.org/<wbr>releasenotes/kolla/</a><br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 42<br>
Date: Wed, 8 Mar 2017 14:11:59 -0500<br>
From: Davanum Srinivas <<a href="mailto:davanum@gmail.com" target="_blank">davanum@gmail.com</a>><br>
To: <a href="mailto:prometheanfire@gentoo.org" target="_blank">prometheanfire@gentoo.org</a>, "OpenStack Development Mailing List<br>
(not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [requirements] pycrypto is dead, long<br>
live pycryptodome... or cryptography...<br>
Message-ID:<br>
<CANw6fcGdUcLiUme3mVEdf-EL=<a href="mailto:gsFYzGj6y0soR4313atLAWUFg@mail.gmail.com" target="_blank">gsF<wbr>YzGj6y0soR4313atLAWUFg@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Matthew,<br>
<br>
Please see the last time i took inventory:<br>
<a href="https://review.openstack.org/#/q/pycryptodome+owner:dims-v" target="_blank">https://review.openstack.org/#<wbr>/q/pycryptodome+owner:dims-v</a><br>
<br>
Thanks,<br>
Dims<br>
<br>
On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode <<a href="mailto:prometheanfire@gentoo.org" target="_blank">prometheanfire@gentoo.org</a>> wrote:<br>
> So, pycrypto upstream is dead and has been for a while, we should look<br>
> at moving off of it for both bugfix and security reasons.<br>
><br>
> Currently it's used by the following.<br>
><br>
> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,<br>
> kolla, openstack-ansible, and a couple of other smaller places.<br>
><br>
> Development of it was forked into pycryptodome, which is supposed to be<br>
> a drop in replacement. The problem is that due to co-installability<br>
> requirements we can't have half of packages out there using pycrypto and<br>
> the other half using pycryptodome. We'd need to hard switch everyone as<br>
> both packages install into the same namespace.<br>
><br>
> Another alternative would be to use something like cryptography instead,<br>
> though it is not a drop in replacement, the migration would be able to<br>
> be done piecemeal.<br>
><br>
> I'd be interested in hearing about migration plans, especially from the<br>
> affected projects.<br>
><br>
> --<br>
> Matthew Thode (prometheanfire)<br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
<br>
<br>
-- <br>
Davanum Srinivas :: <a href="https://twitter.com/dims" target="_blank">https://twitter.com/dims</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 43<br>
From: <a href="mailto:no-reply@openstack.org" target="_blank">no-reply@openstack.org</a><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: [openstack-dev] [kolla] kolla-ansible 4.0.0.0rc2 (ocata)<br>
Message-ID:<br>
<<a href="mailto:mailman.44.1489001100.16299.openstack-dev@lists.openstack.org" target="_blank">mailman.44.1489001100.16299.<wbr>openstack-dev@lists.openstack.<wbr>org</a>><br>
<br>
<br>
Hello everyone,<br>
<br>
A new release candidate for kolla-ansible for the end of the Ocata<br>
cycle is available! You can find the source code tarball at:<br>
<br>
<a href="https://tarballs.openstack.org/kolla-ansible/" target="_blank">https://tarballs.openstack.<wbr>org/kolla-ansible/</a><br>
<br>
Unless release-critical issues are found that warrant a release<br>
candidate respin, this candidate will be formally released as the<br>
final Ocata release. You are therefore strongly<br>
encouraged to test and validate this tarball!<br>
<br>
Alternatively, you can directly test the stable/ocata release<br>
branch at:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/kolla-ansible/log/?h=stable/ocata" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/kolla-ansible/log/?<wbr>h=stable/ocata</a><br>
<br>
Release notes for kolla-ansible can be found at:<br>
<br>
<a href="http://docs.openstack.org/releasenotes/kolla-ansible/" target="_blank">http://docs.openstack.org/<wbr>releasenotes/kolla-ansible/</a><br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 44<br>
Date: Wed, 8 Mar 2017 14:17:59 -0500<br>
From: Steve Martinelli <<a href="mailto:s.martinelli@gmail.com" target="_blank">s.martinelli@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev]<br>
[cinder][glance][horizon][<wbr>keystone][nova][qa][swift] Feedback needed:<br>
Removal of legacy per-project vanity domain redirects<br>
Message-ID:<br>
<CAHc_MXFwSyZE8Uisk6gkw=<a href="mailto:TiZvZduS-_PE0DAWVuqb0CfrEzSQ@mail.gmail.com" target="_blank">TiZvZd<wbr>uS-_PE0DAWVuqb0CfrEzSQ@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Wed, Mar 8, 2017 at 2:04 PM, Andreas Jaeger <<a href="mailto:aj@suse.com" target="_blank">aj@suse.com</a>> wrote:<br>
><br>
> Very few people know about these URLs at all and there are only a few<br>
> places that use it in openstack (I just send a few patches for those).<br>
><br>
<br>
++<br>
<br>
I had no idea they existed...<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/984fa20f/attachment-0001.html" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/984fa20f/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 45<br>
Date: Wed, 8 Mar 2017 13:24:50 -0600<br>
From: Matthew Thode <<a href="mailto:prometheanfire@gentoo.org" target="_blank">prometheanfire@gentoo.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [requirements] pycrypto is dead, long<br>
live pycryptodome... or cryptography...<br>
Message-ID: <<a href="mailto:b6af5257-85dd-28be-2629-0ada5af81b7c@gentoo.org" target="_blank">b6af5257-85dd-28be-2629-<wbr>0ada5af81b7c@gentoo.org</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I'm aware, iirc it was brought up when pysaml2 had to be fixed due to a<br>
CVE. This thread is more looking for a long term fix.<br>
<br>
On 03/08/2017 01:11 PM, Davanum Srinivas wrote:<br>
> Matthew,<br>
> <br>
> Please see the last time i took inventory:<br>
> <a href="https://review.openstack.org/#/q/pycryptodome+owner:dims-v" target="_blank">https://review.openstack.org/#<wbr>/q/pycryptodome+owner:dims-v</a><br>
> <br>
> Thanks,<br>
> Dims<br>
> <br>
> On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode <<a href="mailto:prometheanfire@gentoo.org" target="_blank">prometheanfire@gentoo.org</a>> wrote:<br>
>> So, pycrypto upstream is dead and has been for a while, we should look<br>
>> at moving off of it for both bugfix and security reasons.<br>
>><br>
>> Currently it's used by the following.<br>
>><br>
>> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,<br>
>> kolla, openstack-ansible, and a couple of other smaller places.<br>
>><br>
>> Development of it was forked into pycryptodome, which is supposed to be<br>
>> a drop in replacement. The problem is that due to co-installability<br>
>> requirements we can't have half of packages out there using pycrypto and<br>
>> the other half using pycryptodome. We'd need to hard switch everyone as<br>
>> both packages install into the same namespace.<br>
>><br>
>> Another alternative would be to use something like cryptography instead,<br>
>> though it is not a drop in replacement, the migration would be able to<br>
>> be done piecemeal.<br>
>><br>
>> I'd be interested in hearing about migration plans, especially from the<br>
>> affected projects.<br>
>><br>
>> --<br>
>> Matthew Thode (prometheanfire)<br>
>><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
> <br>
> <br>
> <br>
<br>
<br>
-- <br>
Matthew Thode (prometheanfire)<br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 833 bytes<br>
Desc: OpenPGP digital signature<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/b44eb072/attachment.pgp" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20170308/b44eb072/<wbr>attachment.pgp</a>><br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<wbr>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 59, Issue 24<br>
******************************<wbr>***************<u></u><u></u></p>
</div>
</blockquote>
</div>
</div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-size:13px;border-collapse:collapse"><font face="monospace, monospace">Regards,</font></span></div><div><span style="font-size:13px;border-collapse:collapse"><font face="monospace, monospace">Jeffrey Zhang</font></span></div><div><span style="font-family:monospace,monospace;font-size:12.8px">Blog: </span><a href="http://xcodest.me/" style="font-family:monospace,monospace;font-size:12.8px" target="_blank">http://xcodest.me</a><font face="monospace, monospace"><br></font></div></div></div></div></div></div></div></div></div>
</div>