Error on image build but error log is not complete

[gioppoluca]

I'm trying to build an image using a working set of files (it builds locally on my machine).

I try to go to the API and get the info of the build but the log is truncated and cannot understand what the error is.

[j-fuentes]

Are you retrieving the error log with the API or inspecting the file?

[gioppoluca]

I use the /builder/images/{tk}/detail
API
And in the log field the info is truncated

[gioppoluca]

it just says build finished unsuccessfully in the description

[j-fuentes]

Yes, that field is limited.

Because of that, I recommend for debug purposes to read from the log file.

But I am not sure if the file is overwritted with build finished unsuccessfully. Could you check it?

[gioppoluca]

mmm I see that you rename the puppet manifest to a "manifest.pp" but in the dockerfile I generate I have the generated name (webdk.pp).
Did we decide to change the name of the manifest inside the dockerfile?
If yes what is the expected content? path included

[gioppoluca]

can I advice you to leave the name of the puppet manifest as it is so the generated content will be good both when testing using crane and by hand (if you rename the dockerfile used by hand will not find the manifest.pp and I cannot have multiple manifest.pp in the same folder and I use a single folder for the generation)

[j-fuentes]

We decided to use standard names.

The Dockerfile can read the manifest.pp file from images/<name of the image>/manifest.pp.

But yes, I can left the name as is.

[gioppoluca]

also for me the webdk.pp manifest is in the root of the build context and not into a images/changed_generated_name folder
If you keef files as sent and use the -f flag for the build you can leave all in the context root and execute the builds without any problem keeping just the logs and all that things in the separated folders.
Leveraging on the -f flag could help

[gioppoluca]

The fact is that I have no knowledge of the crane environment and with the generated files as they are I need to be able to test both using crane AND by-hand.

[gioppoluca]

BTW we really need to be able to send the entire log back to the orchestrator or the service provider will not be albe to understand the error and he will not be able to access to the file system of the orchestrator

[j-fuentes]

yes, but do you want the entire log error in a http response? It could be a big big response.

[j-fuentes]

Should be fixed now (jmcerpa@25e8fe2).

[gioppoluca]

Verify and close

[jmcerpa]

In the last dockService I add methods that allow managers to receive logs from crane. Manager can receive logs about image build and contexts, for example.
These methods are contextDetails, ImageDetails ...
Manager will receive a JSON, if you read the key "log" and "error_log" you can see what is happening in crane.
In this way, manager has more control over the process.
The old methods (getBuildInfo, getContexInfo...) receive a description, so you could not read the logs.

[jmcerpa]

When the manager receives these logs stored in elasticsearch?