<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 22, 2015 at 12:52 AM, Sergey Vasilenko <span dir="ltr"><<a href="mailto:svasilenko@mirantis.com" target="_blank">svasilenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer <span dir="ltr"><<a href="mailto:matt@mattfischer.com" target="_blank">matt@mattfischer.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I thought we had code in other places that split out stderr and only logged it if there was an actual error but I cannot find the reference now. I think that matches the original proposal. Not sure I like idea #3.</blockquote></div><br></span>Matthew, this topic not about SSL. ANY warnings, ANY output to stderr from CLI may corrupt work of providers from puppet-* modules for openstack components. </div><div class="gmail_extra"><br></div><div class="gmail_extra">IMHO it's a very serious bug, that potential affect openstack puppet modules.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I see 3 way for fix it:</div><div class="gmail_extra"><ol><li>Long way. big patch to puppet core for add ability to collect stderr and stdout separately. But most of existing puppet providers waits that stderr and stdout was mixed when handle errors of execution (non-zero return code). Such patch will broke backward compatibility, if will be enabled by default.</li><li>Middle way. We should write code for redefine 'commands' method. New commands should collect stderr and stdout separately, but if error happens return stderr (with ability access to stdout too).</li><li>Short way. Modify existing providers to use json output instead plain-text or csv. JSON output may be separated from any garbage (warnings) slightly. I make this patch as example of this way: <a href="https://review.openstack.org/#/c/238156/" target="_blank">https://review.openstack.org/#/c/238156/</a> . Anyway json more formalized format for data exchange, than plain text.</li></ol><div><div><div>IMHO way #1 is a best solution, but not easy.</div><span class="HOEnZb"><font color="#888888"><div dir="ltr"><div><br></div></div></font></span></div></div></div></div></blockquote><div><br></div><div>I must confess that I'm a bit confused about this. It wasn't a secret that we're calling out to commands and parsing the output. It's been discussed over and over on this list as recently as last week, so this has been a known possible issue for quite a long time. In my original email I was agreeing with you, so I'm not sure why we're arguing now. Anyway...</div><div><br></div><div>I think we need to split stderr and stdout and log stderr on errors, your idea #2. Using json like openstack-client can do does not solve this problem for us, you still can end up with a bunch of junk on stderr.</div><div><br></div><div>This would be a good quick discussion in Tokyo if you guys will be there.</div><div> </div></div></div></div>