On 21 Oct 2015, at 11:39, Marius Cornea <mcornea(a)redhat.com>
wrote:
----- Original Message -----
> From: "Ihar Hrachyshka" <ihrachys(a)redhat.com>
> To: "Alan Pevec" <apevec(a)gmail.com>
> Cc: "Rdo-list(a)redhat.com" <rdo-list(a)redhat.com>
> Sent: Wednesday, October 21, 2015 10:50:59 AM
> Subject: Re: [Rdo-list] Failed to deploy overcloud with network isolation on BM.
>
> May I ask all bug reporters to attach logs and config files to bugs? It’s so
> often the case that logs cited are not enough to understand what’s going on,
> and there is no idea which configuration components were using.
Just to bring some context on this, with RDO Manager deployments pulling the logs is not
an easy task:
1. We cannot straightforward scp the log files. You can SSH to the overcloud nodes using
the heat-admin user and the private key of the undercloud stack user.
The heat-admin user doesn't have permissions to access the log/config files so you
need to use sudo to get them accessible or enable root login. Then scp them to the
undercloud node and use that to scp on your machine and upload to BZ.
If there's an easier way to pull the logs from the overcloud nodes I'd be more
than happy to use it.
It sounds like a huge usability issue. How are deployers supposed to debug issues with
their cloud if they can’t easily access logs?
2. A failed deployment doesn't point to the failed component so when something goes
wrong you need to identify it which is not always something trivial.
The deploy command (with its arguments and environment files) should describe the best
what components are being used and configured.
Sure. But I see neutron failures mentioned in the bug, so I would assume that neutron logs
can reveal the issue.
Ihar