Open Stack

On 10/23/2015 02:17 PM, Dmitry Ilyin wrote:
> 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
+1

I believe such logic should be in puppet-openstacklib and all providers 
in puppet-openstack should inherit from it.

Regards,
Martin

>
> 2015-10-22 17:59 GMT+03:00 Matt Fischer <matt at mattfischer.com 
> <mailto:matt at mattfischer.com>>:
>
>     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.
>
>
>     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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151029/b9889e50/attachment-0001.html>