[openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands
Gilles Dubreuil
gilles at redhat.com
Tue Oct 27 09:17:57 UTC 2015
On 23/10/15 01:59, Matt Fischer wrote:
> On Thu, Oct 22, 2015 at 12:52 AM, Sergey Vasilenko
> <svasilenko at mirantis.com <mailto:svasilenko at mirantis.com>> wrote:
>
>
> On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer <matt at mattfischer.com
> <mailto:matt at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list