<html><head></head><body><div class="ydpb27bc42yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
<div><br></div><div><br></div><div><div><div><br></div><div><div dir="ltr" data-setdir="false"><div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" dir="ltr" data-setdir="false" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;">Hi all,</span></div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" dir="ltr" data-setdir="false" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;"><br></span></div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" dir="ltr" data-setdir="false" style="margin: 0px; padding: 0px;"><font color="#222222"><span style="background-color: rgb(233, 206, 206);">We are in-midst of transition from OSF to OIF and hence decided, not to add more add-ons for Victoria. </span></font></div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" dir="ltr" data-setdir="false" style="margin: 0px; padding: 0px;"><font color="#222222"><span style="background-color: rgb(233, 206, 206);"><br></span></font></div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" dir="ltr" data-setdir="false" style="margin: 0px; padding: 0px;"><font color="#222222"><span style="background-color: rgb(233, 206, 206);">Note the value and efforts involved in Refstack & Tempest process was in question and answer is we need to identify pointers in Marketplace to confirm the claims for current Marketpalce efforts. </span></font></div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" dir="ltr" data-setdir="false" style="margin: 0px; padding: 0px;"><font color="#222222"><span style="background-color: rgb(233, 206, 206);"><br></span></font></div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" dir="ltr" data-setdir="false" style="margin: 0px; padding: 0px;"><font color="#222222"><span style="background-color: rgb(233, 206, 206);"><span style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Here is the summary of Interop WG call today. </span><br></span></font></div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;"><br></span></div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" dir="ltr" data-setdir="false" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;"><span class="ydpe9a6b10dauthor-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; line-height: 17.5px; font-family: Cantarell, Roboto, Open Sans, Helvetica Neue, Arial, sans-serif; font-size: 14px; padding-right: 0px !important; padding-left: 0px !important;">1. Interop Guidelines for 2020.10.json - 2020.10.json (</span><span class="ydpe9a6b10dauthor-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z ydpe9a6b10durl" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; line-height: 17.5px; font-family: Cantarell, Roboto, Open Sans, Helvetica Neue, Arial, sans-serif; font-size: 14px; padding-right: 0px !important; padding-left: 0px !important;"><a href="https://opendev.org/osf/interop)" style="color: inherit; text-decoration-line: underline; margin: 0px; padding: 0px; background-color: transparent; cursor: pointer !important;" rel="nofollow" target="_blank">https://opendev.org/osf/interop)</a></span><span class="ydpe9a6b10dauthor-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; line-height: 17.5px; font-family: Cantarell, Roboto, Open Sans, Helvetica Neue, Arial, sans-serif; font-size: 14px; padding-right: 0px !important; padding-left: 0px !important;"> - Arkady to try submit to osf/interop - escale to osf staff if needed ( refer <a href="https://review.opendev.org/#/c/762705/1/2020.11.json" rel="nofollow" target="_blank" class="">https://review.opendev.org/#/c/762705/1/2020.11.json</a> )- Need pointers to results in Markets</span><div><br></div></span></div><div id="ydpb689d9c0magicdomid864" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;">2. Interop add-on Guidelines for existing - </span><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z ydpb689d9c0url" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;"><a href="https://opendev.org/osf/interop/src/branch/master/add-ons" style="color: inherit; text-decoration-line: underline; margin: 0px; padding: 0px; background-color: transparent; cursor: pointer !important;" rel="nofollow" target="_blank">https://opendev.org/osf/interop/src/branch/master/add-ons</a></span></div><div id="ydpb689d9c0magicdomid1206" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;">2.a DNS (Designate) - dns.2020.10.json - Need pointers to results </span></div><div id="ydpb689d9c0magicdomid1230" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;">2.b Orchestration(Heat) -orchestration.2020.10.json - Need pointers results</span></div><div id="ydpb689d9c0magicdomid983" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;" dir="ltr" data-setdir="false"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;"><br></span></div><div id="ydpb689d9c0magicdomid983" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;" dir="ltr" data-setdir="false"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;"><br></span></div><div id="ydpb689d9c0magicdomid983" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;" dir="ltr" data-setdir="false"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;">3. Interop add-on guidelines for new proposals - </span><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z ydpb689d9c0url" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;"><a href="https://www.openstack.org/marketplace/" style="color: inherit; text-decoration-line: underline; margin: 0px; padding: 0px; background-color: transparent; cursor: pointer !important;" rel="nofollow" target="_blank" class="">https://www.openstack.org/marketplace/</a></span></div><div id="ydpb689d9c0magicdomid1101" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;">3.a FileSystem (Manila) - No plans for Victoria</span></div><div id="ydpb689d9c0magicdomid1125" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;">3.b Metal as a Service (Ironic) - No plans for Victoria</span></div><div id="ydpb689d9c0magicdomid1125" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;"><br></span></div><div id="ydpb689d9c0magicdomid1125" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;"><br></span></div><div id="ydpb689d9c0magicdomid1178" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><span class="ydpb689d9c0author-a-z82zyz71zuogrz67zz79ztbz69zz88zuwz68z" style="margin: 0px; padding-top: 0px; padding-bottom: 0px; background-color: rgb(233, 206, 206); color: rgb(34, 34, 34); line-height: 17.5px; padding-right: 0px !important; padding-left: 0px !important;">4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals - Need Board level guidelines from Foundation </span></div><div id="ydpb689d9c0magicdomid968" class="ydpb689d9c0ace-line" style="margin: 0px; padding: 0px;"><br style="margin: 0px; padding: 0px; color: rgb(62, 62, 62); font-family: Cantarell, Roboto, Open Sans, Helvetica Neue, Arial, sans-serif; font-size: 14px;"></div></div><br></div><div dir="ltr" data-setdir="false">Call for volunteers again to ensure we transit from OSF to OIF and please do reply your ideas by email for</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">1. un-linking orchestration from Heat to Mangnum or Kubernetes as baseline for containers</div><div dir="ltr" data-setdir="false">2. Adding new program for BareMetal as a Service with Ironic , bifrost , metal3 etc.</div><div dir="ltr" data-setdir="false">3. Putting Integrated OpenStack Integrated logo program on autopilot or terminate the same at Victoria.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Thanks</div><div dir="ltr" data-setdir="false">Prakash</div><div dir="ltr" data-setdir="false">For Interop WG OSF/OIF</div><div dir="ltr" data-setdir="false"><br style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"></div></div></div></div><div><br></div><div><br></div>
</div><div id="ydp92884c51yahoo_quoted_5989047430" class="ydp92884c51yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Friday, November 13, 2020, 11:04:48 AM PST, openstack-discuss-request@lists.openstack.org <openstack-discuss-request@lists.openstack.org> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Send openstack-discuss mailing list submissions to<br></div><div dir="ltr"> <a href="mailto:openstack-discuss@lists.openstack.org" rel="nofollow" target="_blank">openstack-discuss@lists.openstack.org</a><br></div><div dir="ltr"><br></div><div dir="ltr">To subscribe or unsubscribe via the World Wide Web, visit<br></div><div dir="ltr"> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss" rel="nofollow" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss</a><br></div><div dir="ltr">or, via email, send a message with subject or body 'help' to<br></div><div dir="ltr"> <a href="mailto:openstack-discuss-request@lists.openstack.org" rel="nofollow" target="_blank">openstack-discuss-request@lists.openstack.org</a><br></div><div dir="ltr"><br></div><div dir="ltr">You can reach the person managing the list at<br></div><div dir="ltr"> <a href="mailto:openstack-discuss-owner@lists.openstack.org" rel="nofollow" target="_blank">openstack-discuss-owner@lists.openstack.org</a><br></div><div dir="ltr"><br></div><div dir="ltr">When replying, please edit your Subject line so it is more specific<br></div><div dir="ltr">than "Re: Contents of openstack-discuss digest..."<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Today's Topics:<br></div><div dir="ltr"><br></div><div dir="ltr"> 1. Re: [release][infra] Discrepancy between release jobs and the<br></div><div dir="ltr"> "normal" jobs CI in terms of distro (Jeremy Stanley)<br></div><div dir="ltr"> 2. [OpenStack][InteropWG] Weekly Interop meeting Agenda for<br></div><div dir="ltr"> Victoria Interop Guidelines in next hr (prakash RAMCHANDRAN)<br></div><div dir="ltr"> 3. Re: [release][infra] Discrepancy between release jobs and the<br></div><div dir="ltr"> "normal" jobs CI in terms of distro (Jeremy Stanley)<br></div><div dir="ltr"> 4. Re:<br></div><div dir="ltr"> [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova<br></div><div dir="ltr"> enforces that no DB credentials are allowed for the nova-compute<br></div><div dir="ltr"> service (Oliver Walsh)<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">----------------------------------------------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 1<br></div><div dir="ltr">Date: Fri, 13 Nov 2020 17:20:44 +0000<br></div><div dir="ltr">From: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" rel="nofollow" target="_blank">fungi@yuggoth.org</a>><br></div><div dir="ltr">To: <a href="mailto:openstack-discuss@lists.openstack.org" rel="nofollow" target="_blank">openstack-discuss@lists.openstack.org</a><br></div><div dir="ltr">Subject: Re: [release][infra] Discrepancy between release jobs and the<br></div><div dir="ltr"> "normal" jobs CI in terms of distro<br></div><div dir="ltr">Message-ID: <<a href="mailto:20201113172044.c6cgt7rdy6m6mkeu@yuggoth.org" rel="nofollow" target="_blank">20201113172044.c6cgt7rdy6m6mkeu@yuggoth.org</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">On 2020-11-13 13:58:18 +0100 (+0100), Radosław Piliszek wrote:<br></div><div dir="ltr">[...]<br></div><div dir="ltr">> I believe it would be a rare situation but surely testing something on<br></div><div dir="ltr">> Bionic and trying to release on Focal might have its quirks.<br></div><div dir="ltr"><br></div><div dir="ltr">Honestly, I think the real problem here is that we have a bunch of<br></div><div dir="ltr">unnecessary cruft in the release-openstack-python job held over from<br></div><div dir="ltr">when we used to use tox to create release artifacts. If you look<br></div><div dir="ltr">through the log of a successful build you'll see that we're not<br></div><div dir="ltr">actually running tox or installing the projects being released, but<br></div><div dir="ltr">we're using the ensure-tox and bindep roles anyway. We may not even<br></div><div dir="ltr">need ensure-pip in there. The important bits of the job are that it<br></div><div dir="ltr">checks out the correct state of the repository and then runs<br></div><div dir="ltr">`python3 setup.py sdist bdist_wheel` and then pulls the resulting<br></div><div dir="ltr">files back to the executor to be published. That should be fairly<br></div><div dir="ltr">consistent no matter what project is being built and no matter what<br></div><div dir="ltr">distro it's being built on.<br></div><div dir="ltr">-- <br></div><div dir="ltr">Jeremy Stanley<br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">A non-text attachment was scrubbed...<br></div><div dir="ltr">Name: signature.asc<br></div><div dir="ltr">Type: application/pgp-signature<br></div><div dir="ltr">Size: 833 bytes<br></div><div dir="ltr">Desc: not available<br></div><div dir="ltr">URL: <<a href="http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/5fa6322b/attachment-0001.sig" rel="nofollow" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/5fa6322b/attachment-0001.sig</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 2<br></div><div dir="ltr">Date: Fri, 13 Nov 2020 17:21:06 +0000 (UTC)<br></div><div dir="ltr">From: prakash RAMCHANDRAN <<a href="mailto:pramchan@yahoo.com" rel="nofollow" target="_blank">pramchan@yahoo.com</a>><br></div><div dir="ltr">To: "<a href="mailto:openstack-discuss@lists.openstack.org" rel="nofollow" target="_blank">openstack-discuss@lists.openstack.org</a>"<br></div><div dir="ltr"> <<a href="mailto:openstack-discuss@lists.openstack.org" rel="nofollow" target="_blank">openstack-discuss@lists.openstack.org</a>><br></div><div dir="ltr">Subject: [OpenStack][InteropWG] Weekly Interop meeting Agenda for<br></div><div dir="ltr"> Victoria Interop Guidelines in next hr<br></div><div dir="ltr">Message-ID: <<a href="mailto:435519786.5170730.1605288066630@mail.yahoo.com" rel="nofollow" target="_blank">435519786.5170730.1605288066630@mail.yahoo.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Hi all,<br></div><div dir="ltr">Please join me in next hour weekly Interop WG meetingInterop Working Group - Weekly Friday 10-11 AM PST Link: <a href="https://meetpad.opendev.org/Interop-WG-weekly-meetin" rel="nofollow" target="_blank">https://meetpad.opendev.org/Interop-WG-weekly-meetin</a><br></div><div dir="ltr"><br></div><div dir="ltr">Agenda: 1. Interop Guidelines for 2020.10.json 2. Interop add-on Guidelines for existing2.a DNS (Designate) 2.b Orchestration(Heat)3. Interop add-on guidelines for new proposals3.a FileSystem (Manila)3.b Metal as a Service (Ironic)4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals<br></div><div dir="ltr"><br></div><div dir="ltr">ThanksPrakashFor Interop WGOpenDev Etherpad<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">| <br></div><div dir="ltr">| <br></div><div dir="ltr">| | <br></div><div dir="ltr">OpenDev Etherpad<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"> |<br></div><div dir="ltr"><br></div><div dir="ltr"> |<br></div><div dir="ltr"><br></div><div dir="ltr"> |<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/71daaaad/attachment-0001.html" rel="nofollow" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/71daaaad/attachment-0001.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 3<br></div><div dir="ltr">Date: Fri, 13 Nov 2020 18:18:05 +0000<br></div><div dir="ltr">From: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" rel="nofollow" target="_blank">fungi@yuggoth.org</a>><br></div><div dir="ltr">To: <a href="mailto:openstack-discuss@lists.openstack.org" rel="nofollow" target="_blank">openstack-discuss@lists.openstack.org</a><br></div><div dir="ltr">Subject: Re: [release][infra] Discrepancy between release jobs and the<br></div><div dir="ltr"> "normal" jobs CI in terms of distro<br></div><div dir="ltr">Message-ID: <<a href="mailto:20201113181805.wwwlhkqxalbrrbxz@yuggoth.org" rel="nofollow" target="_blank">20201113181805.wwwlhkqxalbrrbxz@yuggoth.org</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">On 2020-11-13 17:20:44 +0000 (+0000), Jeremy Stanley wrote:<br></div><div dir="ltr">[...]<br></div><div dir="ltr">> Honestly, I think the real problem here is that we have a bunch of<br></div><div dir="ltr">> unnecessary cruft in the release-openstack-python job held over<br></div><div dir="ltr">> from when we used to use tox to create release artifacts. If you<br></div><div dir="ltr">> look through the log of a successful build you'll see that we're<br></div><div dir="ltr">> not actually running tox or installing the projects being<br></div><div dir="ltr">> released, but we're using the ensure-tox and bindep roles anyway.<br></div><div dir="ltr">[...]<br></div><div dir="ltr"><br></div><div dir="ltr">This solution has been proposed: <a href="https://review.opendev.org/762699" rel="nofollow" target="_blank">https://review.opendev.org/762699</a><br></div><div dir="ltr">-- <br></div><div dir="ltr">Jeremy Stanley<br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">A non-text attachment was scrubbed...<br></div><div dir="ltr">Name: signature.asc<br></div><div dir="ltr">Type: application/pgp-signature<br></div><div dir="ltr">Size: 833 bytes<br></div><div dir="ltr">Desc: not available<br></div><div dir="ltr">URL: <<a href="http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/9332bde8/attachment-0001.sig" rel="nofollow" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/9332bde8/attachment-0001.sig</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 4<br></div><div dir="ltr">Date: Fri, 13 Nov 2020 19:02:14 +0000<br></div><div dir="ltr">From: Oliver Walsh <<a href="mailto:owalsh@redhat.com" rel="nofollow" target="_blank">owalsh@redhat.com</a>><br></div><div dir="ltr">To: Balázs Gibizer <<a href="mailto:balazs.gibizer@est.tech" rel="nofollow" target="_blank">balazs.gibizer@est.tech</a>><br></div><div dir="ltr">Cc: Javier Pena <<a href="mailto:jpena@redhat.com" rel="nofollow" target="_blank">jpena@redhat.com</a>>, openstack maillist<br></div><div dir="ltr"> <<a href="mailto:openstack-discuss@lists.openstack.org" rel="nofollow" target="_blank">openstack-discuss@lists.openstack.org</a>>, Thomas Goirand<br></div><div dir="ltr"> <<a href="mailto:zigo@debian.org" rel="nofollow" target="_blank">zigo@debian.org</a>><br></div><div dir="ltr">Subject: Re:<br></div><div dir="ltr"> [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova<br></div><div dir="ltr"> enforces that no DB credentials are allowed for the nova-compute<br></div><div dir="ltr"> service<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <CALv8kgEi7g_NeON8xVqpHp1T=P4M=ueyvYQ2Q6TAu2wYNA=<a href="mailto:5jw@mail.gmail.com" rel="nofollow" target="_blank">5jw@mail.gmail.com</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="utf-8"<br></div><div dir="ltr"><br></div><div dir="ltr">On Fri 13 Nov 2020, 16:18 Oliver Walsh, <<a href="mailto:owalsh@redhat.com" rel="nofollow" target="_blank">owalsh@redhat.com</a>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer <<a href="mailto:balazs.gibizer@est.tech" rel="nofollow" target="_blank">balazs.gibizer@est.tech</a>><br></div><div dir="ltr">> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> On Thu, Nov 12, 2020 at 06:09, Javier Pena <<a href="mailto:jpena@redhat.com" rel="nofollow" target="_blank">jpena@redhat.com</a>> wrote:<br></div><div dir="ltr">>> >> On 11/11/20 5:35 PM, Balázs Gibizer wrote:<br></div><div dir="ltr">>> >> > Dear packagers and deployment engine developers,<br></div><div dir="ltr">>> >> ><br></div><div dir="ltr">>> >> > Since Icehouse nova-compute service does not need any database<br></div><div dir="ltr">>> >> > configuration as it uses the message bus to access data in the<br></div><div dir="ltr">>> >> database<br></div><div dir="ltr">>> >> > via the conductor service. Also, the nova configuration guide<br></div><div dir="ltr">>> >> states<br></div><div dir="ltr">>> >> > that the nova-compute service should not have the<br></div><div dir="ltr">>> >> > [api_database]connection config set. Having any DB credentials<br></div><div dir="ltr">>> >> > configured for the nova-compute is a security risk as well since<br></div><div dir="ltr">>> >> that<br></div><div dir="ltr">>> >> > service runs close to the hypervisor. Since Rocky[1] nova-compute<br></div><div dir="ltr">>> >> > service fails if you configure API DB credentials and set<br></div><div dir="ltr">>> >> upgrade_level<br></div><div dir="ltr">>> >> > config to 'auto'.<br></div><div dir="ltr">>> >> ><br></div><div dir="ltr">>> >> > Now we are proposing a patch[2] that makes nova-compute fail at<br></div><div dir="ltr">>> >> startup<br></div><div dir="ltr">>> >> > if the [database]connection or the [api_database]connection is<br></div><div dir="ltr">>> >> > configured. We know that this breaks at least the rpm packaging,<br></div><div dir="ltr">>> >> debian<br></div><div dir="ltr">>> >> > packaging, and puppet-nova. The problem there is that in an<br></div><div dir="ltr">>> >> all-in-on<br></div><div dir="ltr">>> >> > deployment scenario the nova.conf file generated by these tools is<br></div><div dir="ltr">>> >> > shared between all the nova services and therefore nova-compute<br></div><div dir="ltr">>> >> sees DB<br></div><div dir="ltr">>> >> > credentials. As a counter-example, devstack generates a separate<br></div><div dir="ltr">>> >> > nova-cpu.conf and passes that to the nova-compute service even in<br></div><div dir="ltr">>> >> an<br></div><div dir="ltr">>> >> > all-in-on setup.<br></div><div dir="ltr">>> >> ><br></div><div dir="ltr">>> >> > The nova team would like to merge [2] during Wallaby but we are<br></div><div dir="ltr">>> >> OK to<br></div><div dir="ltr">>> >> > delay the patch until Wallaby Milestone 2 so that the packagers<br></div><div dir="ltr">>> >> and<br></div><div dir="ltr">>> >> > deployment tools can catch up. Please let us know if you are<br></div><div dir="ltr">>> >> impacted<br></div><div dir="ltr">>> >> > and provide a way to track when you are ready with the<br></div><div dir="ltr">>> >> modification that<br></div><div dir="ltr">>> >> > allows [2] to be merged.<br></div><div dir="ltr">>> >> ><br></div><div dir="ltr">>> >> > There was a long discussion on #openstack-nova today[3] around<br></div><div dir="ltr">>> >> this<br></div><div dir="ltr">>> >> > topic. So you can find more detailed reasoning there[3].<br></div><div dir="ltr">>> >> ><br></div><div dir="ltr">>> >> > Cheers,<br></div><div dir="ltr">>> >> > gibi<br></div><div dir="ltr">>> >><br></div><div dir="ltr">>> >> IMO, that's ok if, and only if, we all agree on how to implement it.<br></div><div dir="ltr">>> >> Best would be if we (all downstream distro + config management)<br></div><div dir="ltr">>> >> agree on<br></div><div dir="ltr">>> >> how to implement this.<br></div><div dir="ltr">>> >><br></div><div dir="ltr">>> >> How about, we all implement a /etc/nova/nova-db.conf, and get all<br></div><div dir="ltr">>> >> services that need db access to use it (ie: starting them with<br></div><div dir="ltr">>> >> --config-file=/etc/nova/nova-db.conf)?<br></div><div dir="ltr">>> >><br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> > Hi,<br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> > This is going to be an issue for those services we run as a WSGI app.<br></div><div dir="ltr">>> > Looking at [1], I see<br></div><div dir="ltr">>> > the app has a hardcoded list of config files to read (api-paste.ini<br></div><div dir="ltr">>> > and nova.conf), so we'd<br></div><div dir="ltr">>> > need to modify it at the installer level.<br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> > Personally, I like the nova-db.conf way, since it looks like it<br></div><div dir="ltr">>> > reduces the amount of work<br></div><div dir="ltr">>> > required for all-in-one installers to adapt, but that requires some<br></div><div dir="ltr">>> > code change. Would the<br></div><div dir="ltr">>> > Nova team be happy with adding a nova-db.conf file to that list?<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Devstack solves the all-in-one case by using these config files:<br></div><div dir="ltr">>><br></div><div dir="ltr">>> * nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and<br></div><div dir="ltr">>> nova-metadata-api<br></div><div dir="ltr">><br></div><div dir="ltr">> * nova.conf for the nova-scheduler and the top level nova-conductor<br></div><div dir="ltr">>> (super conductor)<br></div><div dir="ltr">>> * nova-cell<cell-id>.conf for the cell level nova-conductor and the<br></div><div dir="ltr">>> proxy services, e.g. nova-novncproxy<br></div><div dir="ltr">><br></div><div dir="ltr">> * nova-cpu.conf for the nova-compute service<br></div><div dir="ltr">>><br></div><div dir="ltr">><br></div><div dir="ltr">> IIUC for nova-metadata-api "it depends":<br></div><div dir="ltr">> local_metadata_per_cell=True it needs nova-cell<cell-id>.conf<br></div><div dir="ltr">> local_metadata_per_cell=False it needs nova.conf<br></div><div dir="ltr">><br></div><div dir="ltr">> Cheers,<br></div><div dir="ltr">> Ollie<br></div><div dir="ltr">><br></div><div dir="ltr"><br></div><div dir="ltr">Also Sean and Dan mentioned the other day that the cell level<br></div><div dir="ltr">nova-conductor requires api db access, which I really did not expect.<br></div><div dir="ltr"><br></div><div dir="ltr">Cheers,<br></div><div dir="ltr">Ollie<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">><br></div><div dir="ltr">>><br></div><div dir="ltr">>> The nova team suggest to use a similar strategy to separate files. So<br></div><div dir="ltr">><br></div><div dir="ltr">> at the moment we are not planning to change what config files the wsgi<br></div><div dir="ltr">>> apps will read.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Cheers,<br></div><div dir="ltr">>> gibi<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> > Regards,<br></div><div dir="ltr">>> > Javier<br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> > [1] -<br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> <a href="https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30" rel="nofollow" target="_blank">https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30</a><br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> >> If I understand well, these services would need access to db:<br></div><div dir="ltr">>> >> - conductor<br></div><div dir="ltr">>> >> - scheduler<br></div><div dir="ltr">>> >> - novncproxy<br></div><div dir="ltr">>> >> - serialproxy<br></div><div dir="ltr">>> >> - spicehtml5proxy<br></div><div dir="ltr">>> >> - api<br></div><div dir="ltr">>> >> - api-metadata<br></div><div dir="ltr">>> >><br></div><div dir="ltr">>> >> Is this list correct? Or is there some services that also don't<br></div><div dir="ltr">>> >> need it?<br></div><div dir="ltr">>> >><br></div><div dir="ltr">>> >> Cheers,<br></div><div dir="ltr">>> >><br></div><div dir="ltr">>> >> Thomas Goirand (zigo)<br></div><div dir="ltr">>> >><br></div><div dir="ltr">>> >><br></div><div dir="ltr">>> ><br></div><div dir="ltr">>> ><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">-------------- next part --------------<br></div><div dir="ltr">An HTML attachment was scrubbed...<br></div><div dir="ltr">URL: <<a href="http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/f1200424/attachment.html" rel="nofollow" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/f1200424/attachment.html</a>><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Subject: Digest Footer<br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">openstack-discuss mailing list<br></div><div dir="ltr"><a href="mailto:openstack-discuss@lists.openstack.org" rel="nofollow" target="_blank">openstack-discuss@lists.openstack.org</a><br></div><div dir="ltr"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss" rel="nofollow" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss</a><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">End of openstack-discuss Digest, Vol 25, Issue 80<br></div><div dir="ltr">*************************************************<br></div></div>
</div>
</div></body></html>