[rdo-dev] Queens release notes, help needed
TL;DR: Need help filling out https://etherpad.openstack.org/p/rdo-queens-release (Deadline: February 26) As we approach the Queens release, we need to be looking through the release checklist at http://rdoproject.org/rdo/release-checklist/ This is the non-technical side of things: telling people about the work that's been happening for the last six months. Part of that is writing the release announcement. See https://blogs.rdoproject.org/2017/09/rdo-pike-released/ for what we did last time I can use your help in filling out the sections that talk about what happened in Queens. What are you particularly proud of? What's new in RDO? What do you want to be sure all of our users know about? Thanks! -- Rich Bowen - rbo...@redhat.com @RDOcommunity // @CentOSProject // @rbowen ___ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org
Re: [rdo-dev] [ppc64le] Some greenlet packages seem to be wrong arch
On 2/13/18 11:51 AM, Haïkel Guémar wrote: On 02/13/2018 05:00 PM, Michael Turek wrote: Hey RDO, Continued to play with the build of RDO in rdotrunk [0] and noticed another problem with the deps [1]. If you ctrl+f for x86_64, you'll see that the following packages are listed as (and I'm assuming actually are) x86_64 builds: python-greenlet-debuginfo-0.4.12-1.el7.x86_64.rpm python2-greenlet-0.4.12-1.el7.x86_64.rpm python2-greenlet-devel-0.4.12-1.el7.x86_64.rpm Where do you see these? The link [0] are continuous builds from DLRN instance (not CBS) which is x86_64 only which is fine as most stuff built there are noarch though. Sorry for the confusion Haïkel, See link [1] for what I'm talking about https://trunk.rdoproject.org/centos7-queens/deps/latest/ppc64le/ Thanks, Mike Good news is, I checked out the koji build for the package and it looks like it's already built [2]. I'm not sure how to fix such a problem so if anyone could point me in the right direction, I'd really appreciate it. Also, if I should be opening bugs somewhere rather than pointing them out here please let me know! Thanks, Mike Turek [0] https://trunk.rdoproject.org/centos7-queens/current/ [1] https://trunk.rdoproject.org/centos7-queens/deps/latest/ppc64le/ [2] https://cbs.centos.org/koji/buildinfo?buildID=21455 ___ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org ___ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org ___ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org
Re: [rdo-dev] [ppc64le] Some greenlet packages seem to be wrong arch
On 02/13/2018 05:00 PM, Michael Turek wrote: Hey RDO, Continued to play with the build of RDO in rdotrunk [0] and noticed another problem with the deps [1]. If you ctrl+f for x86_64, you'll see that the following packages are listed as (and I'm assuming actually are) x86_64 builds: python-greenlet-debuginfo-0.4.12-1.el7.x86_64.rpm python2-greenlet-0.4.12-1.el7.x86_64.rpm python2-greenlet-devel-0.4.12-1.el7.x86_64.rpm Where do you see these? The link [0] are continuous builds from DLRN instance (not CBS) which is x86_64 only which is fine as most stuff built there are noarch though. Good news is, I checked out the koji build for the package and it looks like it's already built [2]. I'm not sure how to fix such a problem so if anyone could point me in the right direction, I'd really appreciate it. Also, if I should be opening bugs somewhere rather than pointing them out here please let me know! Thanks, Mike Turek [0] https://trunk.rdoproject.org/centos7-queens/current/ [1] https://trunk.rdoproject.org/centos7-queens/deps/latest/ppc64le/ [2] https://cbs.centos.org/koji/buildinfo?buildID=21455 ___ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org ___ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org
[rdo-dev] [ppc64le] Some greenlet packages seem to be wrong arch
Hey RDO, Continued to play with the build of RDO in rdotrunk [0] and noticed another problem with the deps [1]. If you ctrl+f for x86_64, you'll see that the following packages are listed as (and I'm assuming actually are) x86_64 builds: python-greenlet-debuginfo-0.4.12-1.el7.x86_64.rpm python2-greenlet-0.4.12-1.el7.x86_64.rpm python2-greenlet-devel-0.4.12-1.el7.x86_64.rpm Good news is, I checked out the koji build for the package and it looks like it's already built [2]. I'm not sure how to fix such a problem so if anyone could point me in the right direction, I'd really appreciate it. Also, if I should be opening bugs somewhere rather than pointing them out here please let me know! Thanks, Mike Turek [0] https://trunk.rdoproject.org/centos7-queens/current/ [1] https://trunk.rdoproject.org/centos7-queens/deps/latest/ppc64le/ [2] https://cbs.centos.org/koji/buildinfo?buildID=21455 ___ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org
Re: [rdo-dev] Long queue in RDO SF
On February 13, 2018 12:52 pm, Jakub Ruzicka wrote: On Mon, Feb 12, 2018 at 5:08 PM, Tristan Cacqueray wrote: On February 12, 2018 8:59 am, Javier Pena wrote: [snip] My only doubt is why this does not show up as "NOT_REGISTERED" in Zuul as it did before. This is because we changed check_job_registration to False in zuul.conf to make Zuul always queue new job. We did that because during previous nodepool outage, zuul would fail with NOT_REGISTERED when no slaves where online (zuul(v2) only register job for available labels). Perhaps we could add a check for missing jjb job in zuul.yaml, or revert that check_job_registration back to true. I was previsously confused by NOT_REGISTERED on wrong configuration too, but it's still better than having the job stuck. That said, I didn't know howto debug this error, someone with experience told me howto fix based on guesswork. So do I understand it correctly that Zuul has no good way of communicating job configuration errors? This is the design of the zuul(v2) gearman architecture, jobs only get registered when the associated label are available. So when nodepool or jenkins get restarted, it can take a few minutes before slave are online, and any change getting queued in that period will get the NOT_REGISTERED error. Isn't this possibly an issue to be solved in upstream Zuul? Something like returning CONFIG_ERROR that is clickable and leads to a log of config errors. The only way would be to prevent adding unknown job to the pipeline in the first place. Though this would a temporary measure until the migration to zuul(v3) which does exactly that by default. Regards, -Tristan pgpGymIpWOVTH.pgp Description: PGP signature ___ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org
Re: [rdo-dev] Long queue in RDO SF
On Mon, Feb 12, 2018 at 5:08 PM, Tristan Cacqueray wrote: > On February 12, 2018 8:59 am, Javier Pena wrote: > [snip] > >> My only doubt is why this does not show up as "NOT_REGISTERED" in Zuul as >> it did before. >> > > This is because we changed check_job_registration to False in zuul.conf > to make Zuul always queue new job. We did that because during previous > nodepool outage, zuul would fail with NOT_REGISTERED when no slaves > where online (zuul(v2) only register job for available labels). > > Perhaps we could add a check for missing jjb job in zuul.yaml, or revert > that check_job_registration back to true. I was previsously confused by NOT_REGISTERED on wrong configuration too, but it's still better than having the job stuck. That said, I didn't know howto debug this error, someone with experience told me howto fix based on guesswork. So do I understand it correctly that Zuul has no good way of communicating job configuration errors? Isn't this possibly an issue to be solved in upstream Zuul? Something like returning CONFIG_ERROR that is clickable and leads to a log of config errors. Cheers, Jakub ___ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org
