-----Original Message----- From: Tony Breeds <t...@bakeyournoodle.com> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>, OpenStack Development Mailing List <openstack-dev@lists.openstack.org> Date: November 28, 2016 at 00:19:36 To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org> Subject: [openstack-dev] [glance][oslo] oslo.log 3.17.0 use_stderr default change
> Hello Glance team! Hello Tony! > About a month ago the oslo team released 3.17.0 of oslo.log which contains [1] > which switches the default for use_stderr from True to False. It hasn't made > it into upper-constraints.txt because glance is failing[2]. There are 2 easy > fixes: > > 1) switch the glance test to look at stdout rather then stderr ; or > 2) update the glance config files to explictly set "use_stderr = true" > > I feel like Option 2 is correct as clearly preserves the existing behaviour > the > operators/deployers can opt out if they want. So, I'm not entirely certain we actually want use_stderr on for everything by default. If you look at that failing test, it's asserting there's stderr output from running one of Glance's administrative commands (in this case glance-replicator, but it could apply to any of the other ones). I think, what we *probably* want is just to have stderr default to True for commands in glance.cmd (probably excluding glance-api and glance-registry) so that operators running those commands continue to see output. I've been looking at this a little, and I think what we want is to do CONF.set_override(name='use_stderr', default=True, enforce_type=True) Does this sound reasonable to everyone else? If so, I already made https://review.openstack.org/403775 which does this and adds an upgrade release note to document the change. I don't want it to be merged without appropriate discussion, so I've -1'd the Workflow. -- Ian Cordasco __________________________________________________________________________ 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
