11:37 a.m.
On Tue, Feb 22, 2022 at 03:19:58PM +0100, Erik Skultety wrote:
> Note that I have adjusted the value of log_filters to match what
is
> recommended in
>
> https://libvirt.org/kbase/debuglogs.html#less-verbose-logging-for-qemu-vms
>
> but maybe there's a reason you had picked a different set of filters.
I didn't even know we document this, so I always use the filters I empirically
settled with. Given the general feeling about warnings usefulness in libvirt
logs I either use 1 for debug logs or 4 for errors.
If you feel strong I should use what we recommend on that page, I'll go with
that, but I'll add '4:util.threadjob' as well as threadjobs are also verbose
and don't add any value.
Maybe change the page so 4:util.threadjob is included in the
recommended configuration? Other than that, if you feel that your set
of filters will work best for the situation at hand you don't need to
change them.
> > +libvirt-perl-bindings:
> > + stage: bindings
> > + trigger:
> > + project: eskultety/libvirt-perl
> > + branch: multi-project-ci
> > + strategy: depend
> > +
> > +
> > +centos-stream-8-tests:
> > + extends: .tests
> > + needs:
> > + - libvirt-perl-bindings
> > + - pipeline: $PARENT_PIPELINE_ID
> > + job: x86_64-centos-stream-8
> > + - project: eskultety/libvirt-perl
> > + job: x86_64-centos-stream-8
> > + ref: multi-project-ci
> > + artifacts: true
>
> IIUC from the documentation and from reading around, using
> strategy:depend will cause the local job to reflect the status of the
> triggered pipeline. So far so good.
>
> What I am unclear about is, is there any guarantee that using
> artifact:true with a job from an external project's pipeline will
> expose the artifacts from the job that was executed as part of the
> specific pipeline that we've just triggered ourselves as opposed to
> some other pipeline that might have already been completed in the
> past of might have completed in the meantime?
Not just by using artifact:true or strategy:depend. The important bit is having
'libvirt-perl-bindings' in the job's needs list. Let me explain, if you
don't
put the bindings trigger job to the requirements list of another job
(centos-stream-8-tests in this case) what will happen is that the trigger job
will be waiting for the external pipeline to finish, but centos-stream-8-tests
job would execute basically as soon as the container project builds are
finished because artifacts:true would download the latest RPM artifacts from an
earlier build...
No, I got that part. My question was whether
other-project-pipeline:
trigger:
project: other-project
strategy: depend
our-job:
needs:
- other-project-pipeline
- project: other-project
job: other-project-job
artifacts: true
actually guarantees that the instance of other-project-job whose
artifacts are available to our-job is the same one that was started
as part of the pipeline triggered by the other-project-pipeline job.
Looking at the YAML I wouldn't bet on this being the case, but
perhaps I've missed this guarantee being documented somewhere?
> Taking a step back, why exactly are we triggering a rebuild of
> libvirt-perl in the first place? Once we change that project's
> pipeline so that RPMs are published as artifacts, can't we just grab
> the ones from the latest successful pipeline? Maybe you've already
> explained why you did things this way and I just missed it!
...which brings us here. Well, I adopted the mantra that all libvirt-friends
projects depend on libvirt and given that we need libvirt-perl bindings to test
upstream, I'd like to always have the latest bindings available to test with
the current upstream build. The other reason why I did the way you commented on
is that during development of the proposal many times I had to make changes to
both libvirt and libvirt-perl in lockstep and it was tremendously frustrating
to wait for the pipeline to get to the integration stage only to realize that
the integration job didn't wait for the latest bindings and instead picked up
the previous latest artifacts which I knew were either faulty or didn't contain
the necessary changes yet.
Of course that would be annoying when you're making changes to both
projects at the same time, but is that a scenario that we can expect
to be common once the integration tests are in place?
To be clear, I'm not necessarily against the way you're doing things
right now, it's just that it feels like using the artifacts from the
latest successful libvirt-perl pipeline would lower complexity, avoid
burning additional resources and reduce wait times.
If the only only downside is having a worse experience when making
changes to the pipeline, and we can expect that to be infrequent
enough, perhaps that's a reasonable tradeoff.
> > + variables:
> > + DISTRO: centos-stream-8
>
> This variable doesn't seem to be used anywhere, so I assume it's a
> leftover from development. Maybe you tried to implement the .test
> template so that using it didn't require as much repetition and
> unfortunately it didn't work out?
Oh but it is. This is how the gitlab provisioner script knows which distro to
provision, it's equivalent to lcitool's target.
I've looked at
https://gitlab.com/eskultety/libvirt-gitlab-executor
and understand how this value is used now, but without the additional
context it's basically impossible to figure out its purpose. Please
make sure you document it somehow.
> > + tags:
> > + - centos-stream-vm
>
> IIUC this is used both by the GitLab scheduler to pick suitable nodes
> on which to execute the job (our own hardware in this case) and also
> by the runner to decide which template to use for the VM.
>
> So shouldn't this be more specific? I would expect something like
>
> tags:
> - centos-stream-8-vm
What's the point, we'd have to constantly refresh the tags if the platforms
come and go given our support, whereas fedora-vm and centos-stream-vm cover all
currently supported versions - always!
Other than that, I'm not sure that tags are passed on to the gitlab job itself,
I may have missed it, but unless the tags are exposed as env variables, the
provisioner script wouldn't know which template to provision. Also, the tag is
supposed to annotate the baremetal host in this case, so in that context having
'-vm' in the tag name makes sense, but doesn't for the provisioner script
which
relies on/tries to be compatible with lcitool as much as possible.
Okay, my misunderstanding was caused by not figuring out the purpose
of DISTRO. I agree that more specific tags are not necessary.
Should we make them *less* specific instead? As in, is there any
reason for having different tags for Fedora and CentOS jobs as
opposed to using a generic "this needs to run in a VM" tag for both?
--
Andrea Bolognani / Red Hat / Virtualization