This will ensure libvirt maintains the minimum amount of
compatibility with CentOS 6 that running its website on that
platform requires.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
guests/host_vars/libvirt-centos-6/main.yml | 1 +
projects/libvirt.yaml | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/guests/host_vars/libvirt-centos-6/main.yml b/guests/host_vars/libvirt-centos-6/main.yml
index 422d033..8261c3d 100644
--- a/guests/host_vars/libvirt-centos-6/main.yml
+++ b/guests/host_vars/libvirt-centos-6/main.yml
@@ -4,6 +4,7 @@ PYTHONPATH: $VIRT_PREFIX/lib64/python2.6/site-packages
projects:
- libvirt
+ - libvirt+website
- libvirt-cim
- libvirt-perl
- libvirt-python
diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml
index 13f39f9..427cf6a 100644
--- a/projects/libvirt.yaml
+++ b/projects/libvirt.yaml
@@ -43,3 +43,7 @@
parent_jobs:
machines:
- libvirt-fedora-rawhide
+ - autotools-website-job:
+ parent_jobs:
+ machines:
+ - libvirt-centos-6
--
2.14.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Apr 12, 2018 at 05:59:28PM +0200, Andrea Bolognani wrote:
> This will ensure libvirt maintains the minimum amount of
> compatibility with CentOS 6 that running its website on that
> platform requires.
>
> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
> guests/host_vars/libvirt-centos-6/main.yml | 1 +
> projects/libvirt.yaml | 4 ++++
> 2 files changed, 5 insertions(+)
>
> diff --git a/guests/host_vars/libvirt-centos-6/main.yml b/guests/host_vars/libvirt-centos-6/main.yml
> index 422d033..8261c3d 100644
> --- a/guests/host_vars/libvirt-centos-6/main.yml
> +++ b/guests/host_vars/libvirt-centos-6/main.yml
> @@ -4,6 +4,7 @@ PYTHONPATH: $VIRT_PREFIX/lib64/python2.6/site-packages
>
> projects:
> - libvirt
> + - libvirt+website
> - libvirt-cim
> - libvirt-perl
> - libvirt-python
> diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml
> index 13f39f9..427cf6a 100644
> --- a/projects/libvirt.yaml
> +++ b/projects/libvirt.yaml
> @@ -43,3 +43,7 @@
> parent_jobs:
> machines:
> - libvirt-fedora-rawhide
> + - autotools-website-job:
Use 'generic-build-job' here
> + parent_jobs:
> + machines:
> + - libvirt-centos-6
And just add
command: |
mkdir build && cd build
../autogen.sh --without-libvirtd --without-macvtap
$MAKE -j{smp} -C docs
$MAKE -j{smp} dist
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2018-04-17 at 10:54 +0100, Daniel P. Berrangé wrote:
> On Thu, Apr 12, 2018 at 05:59:28PM +0200, Andrea Bolognani wrote:
> > diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml
> > index 13f39f9..427cf6a 100644
> > --- a/projects/libvirt.yaml
> > +++ b/projects/libvirt.yaml
> > @@ -43,3 +43,7 @@
> > parent_jobs:
> > machines:
> > - libvirt-fedora-rawhide
> > + - autotools-website-job:
>
> Use 'generic-build-job' here
>
> > + parent_jobs:
> > + machines:
> > + - libvirt-centos-6
>
> And just add
>
> command: |
> mkdir build && cd build
> ../autogen.sh --without-libvirtd --without-macvtap
> $MAKE -j{smp} -C docs
> $MAKE -j{smp} dist
Okay.
Do you want me to send v2, or can I just squash this in and push?
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Apr 17, 2018 at 12:13:01PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-17 at 10:54 +0100, Daniel P. Berrangé wrote:
> > On Thu, Apr 12, 2018 at 05:59:28PM +0200, Andrea Bolognani wrote:
> > > diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml
> > > index 13f39f9..427cf6a 100644
> > > --- a/projects/libvirt.yaml
> > > +++ b/projects/libvirt.yaml
> > > @@ -43,3 +43,7 @@
> > > parent_jobs:
> > > machines:
> > > - libvirt-fedora-rawhide
> > > + - autotools-website-job:
> >
> > Use 'generic-build-job' here
> >
> > > + parent_jobs:
> > > + machines:
> > > + - libvirt-centos-6
> >
> > And just add
> >
> > command: |
> > mkdir build && cd build
> > ../autogen.sh --without-libvirtd --without-macvtap
> > $MAKE -j{smp} -C docs
> > $MAKE -j{smp} dist
>
> Okay.
>
> Do you want me to send v2, or can I just squash this in and push?
Fine to squash it unless you notice something complicated needs
furtehr changing.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2018-04-17 at 11:19 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 17, 2018 at 12:13:01PM +0200, Andrea Bolognani wrote:
> > Do you want me to send v2, or can I just squash this in and push?
>
> Fine to squash it unless you notice something complicated needs
> furtehr changing.
Hm, Jenkins Job Builder is actually not happy with that:
ERROR:jenkins_jobs.parser:Duplicate definitions for
job 'libvirt-master-build' specified
which makes sense because generic-build-jobs has
name: '{name}-{branch}-build'
I could trick it into using a different name with
- generic-build-job:
name: libvirt-website
...
but then it would try to fetch new revisions from
git://n64.pufty.ci.centos.org/libvirt-website.git
which of course doesn't exist...
Given the situation, my original approach might be the best
solution to the problem after all. What's your take?
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Apr 17, 2018 at 12:41:09PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-17 at 11:19 +0100, Daniel P. Berrangé wrote:
> > On Tue, Apr 17, 2018 at 12:13:01PM +0200, Andrea Bolognani wrote:
> > > Do you want me to send v2, or can I just squash this in and push?
> >
> > Fine to squash it unless you notice something complicated needs
> > furtehr changing.
>
> Hm, Jenkins Job Builder is actually not happy with that:
>
> ERROR:jenkins_jobs.parser:Duplicate definitions for
> job 'libvirt-master-build' specified
>
> which makes sense because generic-build-jobs has
>
> name: '{name}-{branch}-build'
>
> I could trick it into using a different name with
>
> - generic-build-job:
> name: libvirt-website
> ...
>
> but then it would try to fetch new revisions from
>
> git://n64.pufty.ci.centos.org/libvirt-website.git
>
> which of course doesn't exist...
>
> Given the situation, my original approach might be the best
> solution to the problem after all. What's your take?
Hmm, this is a problem with us repurposing 'name' as a parameter
for the template, when it is also a declared field.
eg the core issue is this:
name: '{name}-{branch}-build'
We should address this by changing the parameter name to be
'projname', so it doesn't clash with the official 'name'
field used as the job name.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2018-04-17 at 13:08 +0100, Daniel P. Berrangé wrote:
> Hmm, this is a problem with us repurposing 'name' as a parameter
> for the template, when it is also a declared field.
>
> eg the core issue is this:
>
> name: '{name}-{branch}-build'
>
> We should address this by changing the parameter name to be
> 'projname', so it doesn't clash with the official 'name'
> field used as the job name.
Are you sure? It seems to me like the problem stems from the fact
that we have both
- job-template:
id: autotools-build-job
name: '{name}-{branch}-build'
and
- job-template:
id: generic-build-job
name: '{name}-{branch}-build'
Even if we had a separate 'projname' parameter, the names of the
generated jobs would end up being the same.
I guess we could come up with a
- job-template:
id: generic-command-job
name: '{name}-{branch}-{unique}'
but that template would need to include the scm: configuration and
everything else...
Basically, it would end up looking pretty much exactly like like
generic-build-job or the autotools-website-job I proposed. Having
a more generic version of that would be a net win if we had a
bunch of these oddball jobs, but with a single one (which we will
hopefully be able to drop at some point in the not-too-distant
future!) on the table we might as well not bother.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Apr 17, 2018 at 02:52:08PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-17 at 13:08 +0100, Daniel P. Berrangé wrote:
> > Hmm, this is a problem with us repurposing 'name' as a parameter
> > for the template, when it is also a declared field.
> >
> > eg the core issue is this:
> >
> > name: '{name}-{branch}-build'
> >
> > We should address this by changing the parameter name to be
> > 'projname', so it doesn't clash with the official 'name'
> > field used as the job name.
>
> Are you sure? It seems to me like the problem stems from the fact
> that we have both
>
> - job-template:
> id: autotools-build-job
> name: '{name}-{branch}-build'
>
> and
>
> - job-template:
> id: generic-build-job
> name: '{name}-{branch}-build'
>
> Even if we had a separate 'projname' parameter, the names of the
> generated jobs would end up being the same.
I meant that if we had 'projname' parameter, then we have the
ability to override the job name using:
'name: libvirt-master-website'
without affecting all the expansion of all the other bits of the
template, as they now get driven by {projname} instead.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2018-04-17 at 14:11 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 17, 2018 at 02:52:08PM +0200, Andrea Bolognani wrote:
> > Are you sure? It seems to me like the problem stems from the fact
> > that we have both
> >
> > - job-template:
> > id: autotools-build-job
> > name: '{name}-{branch}-build'
> >
> > and
> >
> > - job-template:
> > id: generic-build-job
> > name: '{name}-{branch}-build'
> >
> > Even if we had a separate 'projname' parameter, the names of the
> > generated jobs would end up being the same.
>
> I meant that if we had 'projname' parameter, then we have the
> ability to override the job name using:
>
> 'name: libvirt-master-website'
>
> without affecting all the expansion of all the other bits of the
> template, as they now get driven by {projname} instead.
Okay, I see what you mean now.
I'm not sure I would necessarily consider it a better approach,
though: it requires making *all* project definitions uglier ('name'
just looks more natural than 'projname' IMHO), with a bunch of churn
to get there, and after all that trouble the libvirt-master-website
job still needs to break the template abstraction in order to work
at all.
All to avoid bit duplicating one more time a bunch of YAML that's
already copied and pasted pretty much verbatim several times over.
tl;dr I still like my approach better, but if you're absolutely
opposed to it I'll begrudgingly take a stab at implementing
your proposal for the sake of sidelining CentOS 6 further :)
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Apr 17, 2018 at 03:28:38PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-17 at 14:11 +0100, Daniel P. Berrangé wrote:
> > On Tue, Apr 17, 2018 at 02:52:08PM +0200, Andrea Bolognani wrote:
> > > Are you sure? It seems to me like the problem stems from the fact
> > > that we have both
> > >
> > > - job-template:
> > > id: autotools-build-job
> > > name: '{name}-{branch}-build'
> > >
> > > and
> > >
> > > - job-template:
> > > id: generic-build-job
> > > name: '{name}-{branch}-build'
> > >
> > > Even if we had a separate 'projname' parameter, the names of the
> > > generated jobs would end up being the same.
> >
> > I meant that if we had 'projname' parameter, then we have the
> > ability to override the job name using:
> >
> > 'name: libvirt-master-website'
> >
> > without affecting all the expansion of all the other bits of the
> > template, as they now get driven by {projname} instead.
>
> Okay, I see what you mean now.
>
> I'm not sure I would necessarily consider it a better approach,
> though: it requires making *all* project definitions uglier ('name'
> just looks more natural than 'projname' IMHO), with a bunch of churn
> to get there, and after all that trouble the libvirt-master-website
> job still needs to break the template abstraction in order to work
> at all.
Personally I'd like to do the name -> jobname change regardless,
but I don't think its actually needed after all.
Instead just change the templates from doing
name: '{name}-{branch}-build'
to
name: '{name}-{branch}-build{jobsuffix}'
Then the website job can just set
jobsuffix: website
and everything else can leave it unset
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2018-04-17 at 14:33 +0100, Daniel P. Berrangé wrote:
> Instead just change the templates from doing
>
> name: '{name}-{branch}-build'
>
> to
>
> name: '{name}-{branch}-build{jobsuffix}'
>
> Then the website job can just set
>
> jobsuffix: website
>
> and everything else can leave it unset
This one I like better :)
We could go one further and use
name: '{name}-{branch}-build{variant}'
for the generic-build-job template and
variant: +website
for this specific job, then change the autotools-mingw-job
template to use
name: '{name}-{branch}-build+mingw'
to align the job names with the project names at the Ansible
level.
We could then even think about dropping autotools-mingw-job
altogether and instead use generic-build-job there as well,
like
- project:
name: libvirt
jobs:
- generic-build-job:
variant: +mingw
command: '{mingw_build}'
where 'mingw_build' would be defined globally.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Apr 17, 2018 at 03:57:04PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-17 at 14:33 +0100, Daniel P. Berrangé wrote:
> > Instead just change the templates from doing
> >
> > name: '{name}-{branch}-build'
> >
> > to
> >
> > name: '{name}-{branch}-build{jobsuffix}'
> >
> > Then the website job can just set
> >
> > jobsuffix: website
> >
> > and everything else can leave it unset
>
> This one I like better :)
>
> We could go one further and use
>
> name: '{name}-{branch}-build{variant}'
>
> for the generic-build-job template and
>
> variant: +website
>
> for this specific job, then change the autotools-mingw-job
> template to use
>
> name: '{name}-{branch}-build+mingw'
>
> to align the job names with the project names at the Ansible
> level.
Yes, that would be reasonable, though I prefer '-' rather than '+',
since we're already using '-' to separate the first three terms
that make up the job name - no reason why the variant should be
treated differently in the naming scheme.
>
> We could then even think about dropping autotools-mingw-job
> altogether and instead use generic-build-job there as well,
> like
>
> - project:
> name: libvirt
> jobs:
> - generic-build-job:
> variant: +mingw
> command: '{mingw_build}'
>
> where 'mingw_build' would be defined globally.
I don't think that's desirable as {mingw_build} ends up duplicating
the shell commands defined by the autotools-build-job template.
Instead we shoudl make use of existing parameterization of the
existing autotools template
- project:
name: libvirt
jobs:
- autotools-build-job:
variant: +mingw
local_env: {mingw32_env}
autogen_args: {mingw32_autogen}
With
mingw32_env: |
export PKG_CONFIG_LIBDIR="/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig"
export PKG_CONFIG_PATH="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig" \
export PREFIX=$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw
mingw32_autogen: --host=i686-w64-mingw32
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2018-04-17 at 15:02 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 17, 2018 at 03:57:04PM +0200, Andrea Bolognani wrote:
> > We could go one further and use
> >
> > name: '{name}-{branch}-build{variant}'
> >
> > for the generic-build-job template and
> >
> > variant: +website
> >
> > for this specific job, then change the autotools-mingw-job
> > template to use
> >
> > name: '{name}-{branch}-build+mingw'
> >
> > to align the job names with the project names at the Ansible
> > level.
>
> Yes, that would be reasonable, though I prefer '-' rather than '+',
> since we're already using '-' to separate the first three terms
> that make up the job name - no reason why the variant should be
> treated differently in the naming scheme.
I went for '+' in the Ansible part because using '-' would
introduce ambiguity: is 'libvirt-mingw' a variant of libvirt, or
just a completely different project like 'libvirt-dbus'?
In the case of Jenkins jobs, we have already lost that battle
thanks to jobs like virt-manager-master-build, so I guess it's
okay to keep using '-' :)
> > We could then even think about dropping autotools-mingw-job
> > altogether and instead use generic-build-job there as well,
> > like
> >
> > - project:
> > name: libvirt
> > jobs:
> > - generic-build-job:
> > variant: +mingw
> > command: '{mingw_build}'
> >
> > where 'mingw_build' would be defined globally.
>
> I don't think that's desirable as {mingw_build} ends up duplicating
> the shell commands defined by the autotools-build-job template.
>
> Instead we shoudl make use of existing parameterization of the
> existing autotools template
>
> - project:
> name: libvirt
> jobs:
> - autotools-build-job:
> variant: +mingw
> local_env: {mingw32_env}
> autogen_args: {mingw32_autogen}
>
> With
>
> mingw32_env: |
> export PKG_CONFIG_LIBDIR="/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig"
> export PKG_CONFIG_PATH="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig" \
> export PREFIX=$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw
>
> mingw32_autogen: --host=i686-w64-mingw32
Yeah, that looks good too.
It'll lead to having separate -mingw32 and -mingw64 jobs, though:
personally I don't have a problem with that, just making sure you
don't either.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Apr 17, 2018 at 04:21:19PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-17 at 15:02 +0100, Daniel P. Berrangé wrote:
> > On Tue, Apr 17, 2018 at 03:57:04PM +0200, Andrea Bolognani wrote:
> > > We could go one further and use
> > >
> > > name: '{name}-{branch}-build{variant}'
> > >
> > > for the generic-build-job template and
> > >
> > > variant: +website
> > >
> > > for this specific job, then change the autotools-mingw-job
> > > template to use
> > >
> > > name: '{name}-{branch}-build+mingw'
> > >
> > > to align the job names with the project names at the Ansible
> > > level.
> >
> > Yes, that would be reasonable, though I prefer '-' rather than '+',
> > since we're already using '-' to separate the first three terms
> > that make up the job name - no reason why the variant should be
> > treated differently in the naming scheme.
>
> I went for '+' in the Ansible part because using '-' would
> introduce ambiguity: is 'libvirt-mingw' a variant of libvirt, or
> just a completely different project like 'libvirt-dbus'?
>
> In the case of Jenkins jobs, we have already lost that battle
> thanks to jobs like virt-manager-master-build, so I guess it's
> okay to keep using '-' :)
>
> > > We could then even think about dropping autotools-mingw-job
> > > altogether and instead use generic-build-job there as well,
> > > like
> > >
> > > - project:
> > > name: libvirt
> > > jobs:
> > > - generic-build-job:
> > > variant: +mingw
> > > command: '{mingw_build}'
> > >
> > > where 'mingw_build' would be defined globally.
> >
> > I don't think that's desirable as {mingw_build} ends up duplicating
> > the shell commands defined by the autotools-build-job template.
> >
> > Instead we shoudl make use of existing parameterization of the
> > existing autotools template
> >
> > - project:
> > name: libvirt
> > jobs:
> > - autotools-build-job:
> > variant: +mingw
> > local_env: {mingw32_env}
> > autogen_args: {mingw32_autogen}
> >
> > With
> >
> > mingw32_env: |
> > export PKG_CONFIG_LIBDIR="/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig"
> > export PKG_CONFIG_PATH="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig" \
> > export PREFIX=$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw
> >
> > mingw32_autogen: --host=i686-w64-mingw32
>
> Yeah, that looks good too.
>
> It'll lead to having separate -mingw32 and -mingw64 jobs, though:
> personally I don't have a problem with that, just making sure you
> don't either.
I think that is a benefit :-) There's no reason beyond historical
accident to lump them together !
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.