On 12/12/19 7:04 AM, Thanh ha wrote:
On Thu, 12 Dec 2019 at 09:38, Robert Varga <nite@...
On 12/12/2019 14:50, Thanh Ha wrote:
> On Thu, 12 Dec 2019 at 03:56, Robert Varga <nite@...
> <mailto:nite@... <mailto:nite@...>>> wrote:
> is there a simple way to know what is the content of a built
> I mean
> does tell me there is a new image, but there is nothing in the
> which would tell me what the actual content is.
> That really makes it a matter of guessing as to what the delta
> "ZZCI - CentOS 7 - builder - x86_64 - 20190924-232354.3819"
> in use) and "ZZCI - CentOS 7 - builder - x86_64 -
> (produced by the build above) really is.
> Hi Robert,
> Not a super convenient way but you can use the packages_end.diff:
Yeah, that's what I assumed would be the answer, but these files are
produced for every build:
> This tells you which packages were installed into the image in that
> particular build. The hard part is tracking down the logs for the
hence correction: this tells me what packages were installed into the
image that ran the the job.
What I am after is something different: the packer job created a new
image for potential use in jobs (turtles all the way down) -- and I want
to know the contents of that new image.
One way would be to try sandbox with that image (and look at
packages_end of that job), except it seems I am too lame to be able to
get that running.
This will be difficult without LF's help. So as you have found, the
builder profiles available in Jenkins are defined here:
which when updated triggers a Jenkins job to reconfigure it's global
configuration to add / update the profiles defined in these cfg files.
What we need in this case then is to have someone with admin privileges
manually intervene and add temporary build profiles in the Jenkins
sandbox and then run a job to produce the output on each builder we want
to get the package_end.txt for.
(or skip Jenkins entirely and just have an LF admin launch the 2
different VMs manually and email us the results)
There's another option, since the sandbox also needs the ability to do
multi-node tests that means that the cloud credentials can be used to
craft a job to launch the newly defined instance as a multi-node
instance and have a script to just go pull the package listing.
It's still work in any case.
If someone can come up with a way to get packer to eject that
information during the build (via ansible) then we could capture it in
the build job. I suppose an enhancement to the image build job would be
to after finishing creating the image to then launch a clean instance on
the new image and then capture the package listing.
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation