<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 3 Mar 2020, at 19:55, Tim Bell <<a href="mailto:tim.bell@cern.ch" class="">tim.bell@cern.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 3 Mar 2020, at 19:20, Albert Braden <<a href="mailto:Albert.Braden@synopsys.com" class="">Albert.Braden@synopsys.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)" class="">
<style class=""><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div lang="EN-US" link="blue" vlink="purple" class="">
<div class="WordSection1"><p class="MsoNormal">Sean, thank you for clarifying that.<o:p class=""></o:p></p><p class="MsoNormal"><o:p class=""> </o:p></p><p class="MsoNormal">Was my understanding that the community decided to focus on the unified client incorrect? Is the unified/individual client debate still a matter of controversy? Is it possible that the unified client will be deprecated in favor of individual
clients after more discussion? I haven’t looked at any of the individual clients since 2018 (except for osc-placement which is kind of a special case), because I thought they were all going away and could be safely ignored until they did, and I haven’t included
any information about the individual clients in the documentation that I write for our users, and if they ask I have been telling them to not use the individual clients. Do I need to start looking at individual clients again, and telling our users to use them
in some cases?<o:p class=""></o:p></p><p class="MsoNormal"><o:p class=""> </o:p></p><div class=""><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div>I remember a forum discussion where a community goal was proposed to focus on OSC rather than individual project CLIs (I think Matt and I were proposers). There were concerns on the effort to do this and that it would potentially be multi-cycle.</div></div></div></blockquote><div><br class=""></div>BTW, I found the etherpad from Berlin (<a href="https://etherpad.openstack.org/p/BER-t-series-goals" class="">https://etherpad.openstack.org/p/BER-t-series-goals</a>) and the associated mailing list discussion at <a href="http://lists.openstack.org/pipermail/openstack-dev/2018-September/135107.html" class="">http://lists.openstack.org/pipermail/openstack-dev/2018-September/135107.html</a></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">My experience in discussion with the CERN user community and other OpenStack operators is that OSC is felt to be the right solution for the end user facing parts of the cloud (admin commands could be another discussion if necessary). Experienced admin operators can remember that glance looks after images and nova looks after instances. Our average user can get very confused, especially given that OSC supports additional options for authentication (such as Kerberos and Certificates along with clouds.yaml) so users need to re-authenticate with a different openrc to work on their project.</div><div class=""><br class=""></div><div class="">While I understand there are limited resources all round, I would prefer that we focus on adding new project functions to OSC which will eventually lead to feature parity.</div><div class=""><br class=""></div><div class="">Attracting ‘drive-by’ contributions from operations staff for OSC work (it's<span style="caret-color: rgb(0, 0, 0);" class=""> more likely to be achieved if it makes the operations work less e.g. save on special end user documentation by contributing code). This is demonstrated from the CERN team</span> contribution to the OSC ‘coe' and ‘share' functionality along with lots of random OSC updates as listed hat <a href="https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient" class="">https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient</a>) </div><div class=""><br class=""></div><div class="">BTW, I also would vote for =auto as the default.</div><div class=""><br class=""></div><div class="">Tim</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div lang="EN-US" link="blue" vlink="purple" class=""><div class="WordSection1"><p class="MsoNormal">We are on Rocky now but I expect that we will upgrade as necessary to stay on supported versions.<o:p class=""></o:p></p><p class="MsoNormal"><o:p class=""> </o:p></p>
<div class="">
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in" class=""><p class="MsoNormal"><b class="">From:</b> Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com" class="">sean.mcginnis@gmx.com</a>> <br class="">
<b class="">Sent:</b> Tuesday, March 3, 2020 9:50 AM<br class="">
<b class="">To:</b> <a href="mailto:openstack-discuss@lists.openstack.org" class="">openstack-discuss@lists.openstack.org</a><br class="">
<b class="">Subject:</b> Re: OSC future (formerly [glance] Different checksum between CLI and curl)<o:p class=""></o:p></p>
</div>
</div><p class="MsoNormal"><o:p class=""> </o:p></p>
<div class=""><p class="MsoNormal">On 3/3/20 11:28 AM, Albert Braden wrote:<o:p class=""></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" class=""><p class="MsoNormal">Am I understanding correctly that the Openstack community decided to focus on the unified client, and to deprecate the individual clients, and that the Glance team did not agree with this decision, and that the Glance team is now having
a pissing match with the rest of the community, and is unilaterally deciding to continue developing the Glance client and refusing to work on the unified client, or is something different going on? I would ask everyone involved to remember that we operators
are down here, and the yellow rain falling on our heads does not smell very good.<o:p class=""></o:p></p>
</blockquote><p class="">I definitely would not characterize it that way.<o:p class=""></o:p></p><p class="">With trying not to put too much personal bias into it, here's what I would say the situation is:<o:p class=""></o:p></p><p class="MsoNormal" style="margin-bottom:12.0pt">- Some part of the community has said OSC should be the only CLI and that individual CLIs should go away<br class="">
- Glance is a very small team with very, very limited resources<br class="">
- The OSC team is a very small team with very, very limited resources<br class="">
- CLI capabilities need to be exposed for Glance changes and the easiest way to get them out for the is by updating the Glance CLI<br class="">
- No one from the OSC team has been able to proactively help to make sure these changes make it into the OSC client (see bullet 3)<br class="">
- There exists a sizable functionality gap between per-project CLIs and what OSC provides, and although a few people have done a lot of great work to close that gap, there is still a lot to be done and does not appear the gap will close at any point in the
near future based on the current trends<br class="">
<br class="">
<o:p class=""></o:p></p>
</div>
</div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>