[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