Here is the implementation of the puppet "command" that outputs only stdout and drops the stderr unless an error have happened. https://github.com/dmitryilyin/puppet-neutron/commit/b55f36a8da62fc207a91b358c396c03c8c58981b
2015-10-22 17:59 GMT+03:00 Matt Fischer <m...@mattfischer.com>: > On Thu, Oct 22, 2015 at 12:52 AM, Sergey Vasilenko < > svasile...@mirantis.com> wrote: > >> >> On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer <m...@mattfischer.com> >> wrote: >> >>> 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. >> >> >> 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. >> >> IMHO it's a very serious bug, that potential affect openstack puppet >> modules. >> >> I see 3 way for fix it: >> >> 1. 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. >> 2. 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). >> 3. 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: >> https://review.openstack.org/#/c/238156/ . Anyway json more >> formalized format for data exchange, than plain text. >> >> IMHO way #1 is a best solution, but not easy. >> >> > 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... > > 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. > > This would be a good quick discussion in Tokyo if you guys will be there. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
