hi,
the docker-distribution package can act as a smart proxy for docker
registries; and having a local cache inside the ci infra would help
speed up a lot of the jobs I am working with at the moment there.
Do we have the space to host a cache of this nature ? I'd think a 15 to
20 GB of space is all we need.
Could we then have dns inside the ci infra use this cache for the
dockerhub urls ?
Any objections to getting this in ?
regards
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
Hi,
I'd like to register new vm's/slaves for the libguestfs hypervisor:
- fedora-25 (libguestfs-ci-f25slave)
- opensuse-42.1 (libguestfs-ci-opensuse-42.1-slave01)
could you please provide credentials for them?
Thanks,
--
Pino Toscano
Hi Folks,
We'll do a short restart of the ci.centos.org Jenkins frontend on Friday
16-Dec-2016 at 8PM UTC to install some plugins.
This should be a short downtime and other services (duffy, agent
processes, etc) will not be affected.
If there are any questions please contact us in #centos-devel on
freenode.
Cheers!
--
Brian Stinson
CentOS CI Infrastructure Team
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Folks,
We just finished seeding CentOS Linux 7.1611 pre-release content onto
the ci.centos.org mirror. We are working to reinstall the existing duffy
pool with the new packages, and we should be completely switched over in
the next hour or so. Going forward from there, you may test your
projects against what will become the next CentOS Linux 7 release!
If you have feedback or questions, please let us know here, or find us
in #centos-devel on IRC.
Cheers!
- --
Brian Stinson
CentOS CI Infrastructure Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJYNRxPAAoJEIMGvNKzCweMO0YQAKqn6zcVVHDIwvUmfJD3t+vO
vJ0ECgaPTlTdXDPqGvTGeEAGalCkJAJXQaNA6Ant218EQHmGAU85JuvFWo+Q19x0
nr7SwOL9ZSiHzfBIfd8V4RO4mCV35NI/jlUPePVyO6VNkHFFBsSR2qm1Mxc7xs5Q
Xo4ul9vwEbZBS67lwTYApe4wgTfKHGraa8li9+pz9uAKGJbJtbFPfTnhQbU6ucL0
+BX42oogNNeyVqstJlrN1gGfn5mFaGfK3YOkoqbwGx7sEnAnP0HRmHcCZ755+eHb
fQ/mwXMJMN+2/0sUwo6Q0R9WnHqQDYZlxRUOHc7+dWH3EshbGywQYtCz7IStTIF0
pHH4aGhE90woLaKt9MGXmPQ+MAVRg4h1ix71bcUUFeJ6f00Ev7IEsavI0YfungA9
u8edv4Xv5kExfQpi2tXS2BggsW5BxGOTCuOjnPNqAKiMID/88kkfo/YtJVpE+3yk
Ylbb34jWhfwEOJwTa4JgWRJB/g6FXP3k0CublU2gecWcRofKzB2PfTW8D9XbIwkN
JAdpR0LwG0+Z5AWoy2tRCIqeJKdrr0xdnLANnZI0427fnzA4TmtRvn6cQ06dFKtn
Zs3wedi2PglZLmj3tWhussl45WDbbYoSoGXPY+YpwHgf8WheDRSVzYZJhQ6LPImA
WrXzA1r4kMx7utzpsus4
=j4Ys
-----END PGP SIGNATURE-----
Hi,
After getting new 7.3 packages in the jobs running in cloud-sig we
have started getting error "qemu-kvm: CPU feature arat not found"
while launching VMs in intel hardware.
According to information found in
https://bugzilla.redhat.com/show_bug.cgi?id=1371617, the root cause
for this is using libvirt from 7.3 with
qemu-kvm-ev-2.3.0 from virt-sig.
As there is not qemu-kvm-ev-2.6.0 available yet, this is making our
jobs to fail whenever they run in any intel server and the known
workaround is not so easy to implement.
Is there anyway we could disable cr repo at kickstart time for
specific jobs?, i think it's risky to enable in every job when there
are dependencies with packages from SIGs which are not included in cr
repo.
Best regards,
Alfredo
Hi,
It looks like centpkg is not installed in the jenkins nodes... is there
any reason for this?
--
(o- Julien Pivotto
//\ Config Management SIG
V_/_ https://frama.link/cfgmgmt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Nov 19 15:45, Julien Pivotto wrote:
> Hi all,
>
> I have started to bootstrap the CI jobs for the Jenkins Job Builder
>
> Job is at https://ci.centos.org/job/sig-configmanagement-jenkins-jobs/
>
> Git repo is at
> https://github.com/centos-sig-configmanagement/jenkins-jobs
>
> Jobs definitions are in jobs/
>
> --
> (o- Julien Pivotto
> //\ Config Management SIG
> V_/_ https://frama.link/cfgmgmt
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel(a)centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
Nice work so far!
Do you need to pin a specific version of JJB? If not, could you please
use the one installed on the agent machines? Virtualenvs are perfect if
you need them, but they become quite expensive in terms of disk space
when the number of jobs grows.
Cheers,
- --Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJYMJlYAAoJEIMGvNKzCweMx2oP/3uNKgghECevEcCd61ZTVhlF
IZ8w8J5FbK1esm4TNQQaZWHMpz5pPgWqRXgplyj9IQPs5fJYzh1oRDkbx3ILHW1Z
1W2Lxz0rsXN2ildfJEn+7a+T2vXzEejikr/XkrT5Dy8Fi00EG+wbg3lgkGgOlk+N
2PzI/V/LYV6jrBq3I/+GJ/WHPKbUp1UAy1EA336EE7Y9utH4s4A0tDJV0szfTxXC
JLf8v1l3hxCCD16xRhFhigRrUxxeVrufz80vTOHATIpbjrV6oPw05R2WU11Gmtd7
GpYu8e3iMgtbPRl3F11wPunE+ISaHwVn7DFqayltiE1BZwYc8N9+4lhBnsgBrWxB
Iu/zwyCW6Wv7JP4lBd4k+1kXHoXekVGswbOW0z4TdjzpTRCWMtvOr6Pp60a6Yoil
gDBh02+aL9pW7xxRtA8uOmOC/SBkx0F28M1N6EBz/o9e+wkRr6jdne3lso6kWrk2
XGVqJczrj5uGhLYUV7Aga7W1U5hn0VTMniSkQjNMagWG1RYr7x1GMGNYWMmHX/Ic
TzJhO24dlM+B+gm7Fd4RyUNLUgxPwExWvDwl44PBaEOBVSE7bQatN5+mLUAiUDIH
dwDrmwumIiJRiLLYpGgIm++6tOHBlWbsUcCVNMy20UGrK+0X0p4BbapwXdAMewMJ
5wd3q/tv9V+9hbeIEpKC
=nAKs
-----END PGP SIGNATURE-----
hi guys
What I would really like is to have the CentOS Linux 7.1611 ( based on
RHEL 7.3 sources ) be available and deployed on the CI nodes ahead of
when we GA - so that SIGs and other people who are invested with us,
have a chance to validate their content and also prep anything that
might be needed ahead of GA for 7.1611
Towards that goal - there are 2 stages we can do this in.
1) When CR/ repo content is ready, we enable that content directly in
the CI nodes. The CR repo represents the next-release content, but
shipped as a repo in the existing release tree. This allows folks to
'yum update' and get the content ahead of GA. In our case, on the CI
nodes, we would run the yum upgrade as a part of the install process, so
while the deployment would have been with the previous installer, the
booted machine would be running the new kernel + new packages. And any
yum operation from here on, would include the newer content.
2) this stage would come a few days down the road, when we have the
installer in place and the new CI deployments are then run with the new
installer
Since the installer is typically the last thing that we build, stage2
might be a few more days out, but we should be able to start seeding up
stage1 above, in the next day or two. I will announce it here once this
content is in place.
What is important is that when things break with the new code, please
let us know - this list is fine, we will track here, but also the
centos-devel list is a good place to talk about it. For real time chat,
#centos-devel on irc.freenode.net
Does anyone have thoughts around this ?
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc