On 23/10/15 01:59, Matt Fischer wrote: > On Thu, Oct 22, 2015 at 12:52 AM, Sergey Vasilenko > <svasile...@mirantis.com <mailto:svasile...@mirantis.com>> wrote: > > > On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer <m...@mattfischer.com > <mailto: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. > There is another middle way: using neutron API directly. Because from what I've experienced anything JSON we pass/receive to/from the API is directly converted in hashes, no processing to be done. But more importantly in the case of the issue here, the errors/responses are clearly separated from the beginning.
> > 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. > Unfortunately I won't be there but I believe this should be added to the "Scalability issues - Ruby library VS OSclient" topic to be discussed on Wednesday/Thursday. > > > __________________________________________________________________________ > 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
