[ovirt-devel] Re: Gerrit Hooks will Start to Check for "Bug-Url" Keyword Explicitly
On Wed, Feb 6, 2019 at 5:53 PM Nir Soffer wrote:
>
> On Wed, Feb 6, 2019 at 5:33 PM Greg Sheremeta wrote:
>>
>> On Wed, Feb 6, 2019 at 10:18 AM Anton Marchukov wrote:
>>>
>>> Hello All.
>>>
>>> Also. Based on the comments I am going to do the exact match, thus it will
>>> require the following:
>>>
>>> 1. "Bug-Url:" should be at the beginning of the new line with no spaces
>>> allowed in between.
>>> 2. No space is allowed between "Bug-Url" and ":".
>>> 3. I will allow space characters (or tab characters) between ":" and the
>>> bug URL. Thought I can make even more strict and e.g. allow only one space.
>>
>>
>> +1 to all the above. Seems harmless to allow [\t ]+ between : and URL.
>> Although I've never used tab.
>>
>>>
>>>
>>> I am just not sure how far the agreement and expectation was for this
>>> keyword, so feel free to comment and let me know.
>
>
> Thanks for fixing this.
>
> Do we have some documentation for these requirements?
> Is it linked from our contributions guidelines?
Now searched [1] and found [2]. Not extremely detailed.
I personally use for many years a git hook originally written by
Alon Bar Lev, that checks that the Bug-Url: is reachable. Attached.
AFAIK this is the most "official statement" about Bug-Url syntax -
I am pretty certain that at least all of my own patches follow
its syntax wrt syntax. It's not that strict either - the relevant
line is:
cat "${COMMIT}" | grep 'Bug-Url:' | sed 's/.*Bug-Url:[ \t]*\([^
\t]*\).*/\1/' | while read URL; do
At the time, Alon shared it with other developers, so it's likely
still in use by others as well. It might make sense to add it to
some official oVirt repo and document how to use it, probably by
simply adding it to the existing hook [3]. The only downside for
using it is that it slows down each commit, by having to query
bugzilla. I admit that this is so annoying (takes 1-2 seconds)
that I sometimes defer adding Bug-Url: to later stages of
development, so that the initial drafts are faster to commit...
Best regards,
[1]
https://www.google.com/search?q=site%3Awww.ovirt.org+%22bug-url%22&ie=utf-8&oe=utf-8&client=firefox-b-ab
[2] https://www.ovirt.org/develop/dev-process/devprocess.html
[3]
https://www.ovirt.org/develop/dev-process/working-with-gerrit.html#installing-the-change-id-hook
>
>>>
>>> On Wed, Feb 6, 2019 at 3:01 PM Anton Marchukov wrote:
Thanks for comments. Yeah, I think since it does not produce extra side
effect over the previous behaviour in dead case just something will stop
working based on the old assumptions rather than it starts moving
incorrect bugs around.
I have prepared a change [1], will give it some test on staging gerrit
first and then merge and deploy to production gerrit.
[1] https://gerrit.ovirt.org/#/c/97605/
On Wed, Feb 6, 2019 at 11:41 AM Yedidyah Bar David wrote:
>
> On Wed, Feb 6, 2019 at 12:36 PM Anton Marchukov
> wrote:
> >
> > Hello All.
> >
> > I have checked the hooks code. And it indeed just extracts all the
> > links pointing to bugzilla. This is not correct and fails when somebody
> > just mentions a bug in commit message.
> >
> > We are about to fix this and adjust the regexp used to explicitly check
> > for "Bug-Url" keyword. I think this is the expected behavior for
> > everybody.
>
> +1
>
> >
> > But just in case I am sending this pre-announcement about the change.
> > Let me know if you anticipate any problems.
>
> I think we'll have enough time to fix such problems. It will only affect
> new patches, history would remain as-is. So main risk is if people had
> tools/hooks/habits to link to BZs without 'Bug-Url' and expected that to
> work, and it will now be ignored. Small risk, imo.
>
> Thanks!
>
> >
> > Thanks.
> >
> > On Tue, Feb 5, 2019 at 10:16 AM Nir Soffer wrote:
> >>
> >> If a commit message mention another bug, the CI script try to add the
> >> patch
> >> to the bug in the commit message, and change the bug to POST.
> >>
> >> Mentioning another bug in a commit message is good practice, making it
> >> easier to follow, and avoiding unclear forms like "bug 100" or
> >> "BZ#100",
> >> or even worse shortened urls like https://goo.gl/bPuFGo.
> >>
> >> Does it make sense that we cannot link to Red Hat bugzilla like god
> >> intended?
> >>
> >> Here is a proof:
> >> https://gerrit.ovirt.org/c/97568/
> >>
> >> gerrit-hooks
> >> Patch Set 1:
> >>
> >> Check Bug-Url::1000::WARN, failed to get bug info (private bug
> >> or bug doesn't exist
> >> Check Product::IGNORE, not relevant for branch: master
> >> Check TM::IGNORE, not relevant for branch: master
> >> Check Backport::IGNORE, not relevant for branch: master
> >> Set POST::#1000::WARN, f
[ovirt-devel] Nicer URLs in jenkins
Jenkinks OST URLs are too ugly. When looking for OST manual job, we go to: https://jenkins.ovirt.org/view/oVirt%20system%20tests/ This should be something like: https://jenkins.ovirt.org/view/ost/ Or https://jenkins.ovirt.org/view/ovirt-system-tests Then we click on "ovirt-system-tests_manual" which links to: https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests_manual/ Here we can easily make the url much nicer by modifying the URL to: https://jenkins.ovirt.org/job/ovirt-system-tests_manual/ Now we can start a build, and easily get a nice URL for the build to paste on gerrit, like: https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4025/ So this looks like an easy fix, make the links point to https://jenkins.ovirt.org/job/ Why should we make URLs nicer? Ugly URLs are a broken window: https://en.wikipedia.org/wiki/Broken_windows_theory Nir ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/UUZ5FZ5UTH5UNUUQSRPTG6N3ZE43LWVD/
[ovirt-devel] Re: imageio proxy and engine dev setup
On Wed, Feb 6, 2019 at 12:43 PM Greg Sheremeta wrote: > > > On Wed, Feb 6, 2019, 5:26 AM Fedor Gavrilov wrote: > >> Thanks, Roy! I will try setting it up according to what you suggested. >> Last attempt failed indeed: according to logs, both daemon and proxy >> tried establishing a connection with each other with some 200 OK in logs, >> no error messages but nevertheless upload did not happen after all. >> >> Speaking about it, does anyone know more straightforward way to have ISO >> disk on data domain? I am not as much interested in debugging ISO upload >> but rather attaching it to VM. >> > > +1, rsync to the iso domain directory has always been useful for me. How > do we do similar with data domains? > This is much more complicated specially with block storage when there is no file system. this is why we wrote imageio :-) > > >> Thanks, >> Fedor >> >> - Исходное сообщение - >> От: "Roy Golan" >> Кому: "Nir Soffer" >> Копия: "devel" , "Fedor Gavrilov" >> Отправленные: Среда, 6 Февраль 2019 г 9:47:27 >> Тема: [ovirt-devel] Re: imageio proxy and engine dev setup >> >> >> >> On Tue, 5 Feb 2019 at 20:58, Nir Soffer < nsof...@redhat.com > wrote: >> >> >> >> On Tue, Feb 5, 2019 at 6:46 PM Fedor Gavrilov < fgavr...@redhat.com > >> wrote: >> >> >> Right! >> >> Oh, it just occured to me that imageio prject is two parts and they >> expect me to be in proxy/ directory in the installation docs. >> There is indeed a make-install goal there :) >> >> Tried running it and it seems now setup script recognizes it now. >> >> Right, the instructions should be improved to show all the steps. >> >> This should work: >> >> git clone ... >> cd ovirt-imageio >> make >> cd proxy >> make install-dev ENGINE_PREFIX=/home/nsoffer/ovirt-engine >> >> /home/nsoffer/ovirt-engine/bin/engine-setup >> (configure it...) >> >> There are 2 bugs here - 1. the engine will fail to talk with the proxy >> because the default proxy >> address is localhost:54323 which will fail ssl verification. This needs >> to be address in the >> engine setup plugin >> 2. The engine will not fail an attempt to upload when it can't actually >> communicate with the proxy. ImageTransfer needs validation there. >> >> To fix it you need to: >> $ENGINE_PREFIX/bin/engine-config -s >> ImageProxyAddress=OVIRT-ENGINE-FQDN:54323 >> >> >> >> >> export PYTHONPATH=/home/nsoffer/src/ovirt-imageio/common >> ./ovirt-imageio-proxy >> >> Nir >> >> >> >> >> Thanks! >> Fedor Gavrilov >> >> - Исходное сообщение - >> От: "Fedor Gavrilov" < fgavr...@redhat.com > >> Кому: "Nir Soffer" < nsof...@redhat.com > >> Копия: "devel" < devel@ovirt.org > >> Отправленные: Вторник, 5 Февраль 2019 г 17:33:15 >> Тема: [ovirt-devel] Re: imageio proxy and engine dev setup >> >> Hi, >> >> I tried that already unfortunately. Executing make install-dev from >> imageio sources directory complains about no such target. >> Autocomplete for make suggests the following: >> >> [fgavrilo@localhost ovirt-imageio]$ make >> all check clean common daemon dist proxy rpm srpm >> >> Wasn't successful with these targets either. >> >> Fedor Gavrilov >> >> - Исходное сообщение - >> От: "Nir Soffer" < nsof...@redhat.com > >> Кому: "Fedor Gavrilov" < fgavr...@redhat.com > >> Копия: "devel" < devel@ovirt.org >, "Daniel Erez" < de...@redhat.com >, >> "Roy Golan" < rgo...@redhat.com > >> Отправленные: Вторник, 5 Февраль 2019 г 17:18:42 >> Тема: Re: [ovirt-devel] imageio proxy and engine dev setup >> >> On Tue, Feb 5, 2019 at 5:05 PM Fedor Gavrilov < fgavr...@redhat.com > >> wrote: >> >> > Hi, >> > >> > It seems to be rather difficult to have development setup for the >> engine >> > with imageio proxy. >> > engine-setup script never asks about it, running it again with >> > --reconfigure-optional-components changes nothing and answers file >> contains >> > no mention of imageio (thus, >> > https://bugzilla.redhat.com/show_bug.cgi?id=1446094 does not look to >> be >> > fixed for dev setups). There is no package to install separately >> either. >> > >> > Quite confused now. Do you happen to know what am I missing? >> > >> >> Installing with development engine (not installed with rpms) is >> documented >> here: >> >> >> >> http://ovirt.github.io/ovirt-imageio/installation.html#installation-with-ovirt-engine-developer-environment >> >> >> > >> > Fedor Gavrilov >> > ___ >> > Devel mailing list -- devel@ovirt.org >> > To unsubscribe send an email to devel-le...@ovirt.org >> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> > oVirt Code of Conduct: >> > https://www.ovirt.org/community/about/community-guidelines/ >> > List Archives: >> > >> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JTLEMRZMGMNNLKNCJ45L2VJO5EANY56W/ >> > >> ___ >> Devel mailing list -- devel@ovirt.org >> To unsubscribe send an email to devel-le...@ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-po
[ovirt-devel] Re: imageio proxy and engine dev setup
On Wed, Feb 6, 2019 at 12:24 PM Fedor Gavrilov wrote: First, please keep Daniel in the CC, this is your best chance to get a help on this, and a good practice for most issues :-) Thanks, Roy! I will try setting it up according to what you suggested. > Last attempt failed indeed: according to logs, both daemon and proxy tried > establishing a connection with each other with some 200 OK in logs, no > error messages but nevertheless upload did not happen after all. > Did you restart engine after changing the config? Did you add engine CA to the browser? Did you check the browser console.log? Can you share your logs? > Speaking about it, does anyone know more straightforward way to have ISO > disk on data domain? Uploading from the UI is the most straightforward way. But you need to get a working setup first. I am not as much interested in debugging ISO upload but rather attaching it > to VM. > Sad that you are not interested in this yet, but in the meantime you can use the ovirt SDK upload_disk.py example. 1. install first the ovirt python sdk version 4: dnf install python3-ovirt-engine-sdk4 2. Download the upload disk example: https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_disk.py 3. Change the configuration to match your setup (e.g. storage domain name) 4. Upload: python upload_disk.py --direct /path/to/disk.iso Note that --direct goes directly to the host, this is faster compared with going to the proxy. I think we should have a proper command line tool that make all this much easier. We have this RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1626262 Maybe you can be interested in implementing this? Nir ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/DNPVUBWNZJCQ46XWMNDB5EXZGCLM6SZP/
[ovirt-devel] Re: Gerrit Hooks will Start to Check for "Bug-Url" Keyword Explicitly
On Wed, Feb 6, 2019 at 5:33 PM Greg Sheremeta wrote: > On Wed, Feb 6, 2019 at 10:18 AM Anton Marchukov > wrote: > >> Hello All. >> >> Also. Based on the comments I am going to do the exact match, thus it >> will require the following: >> >> 1. "Bug-Url:" should be at the beginning of the new line with no spaces >> allowed in between. >> 2. No space is allowed between "Bug-Url" and ":". >> 3. I will allow space characters (or tab characters) between ":" and the >> bug URL. Thought I can make even more strict and e.g. allow only one space. >> > > +1 to all the above. Seems harmless to allow [\t ]+ between : and URL. > Although I've never used tab. > > >> >> I am just not sure how far the agreement and expectation was for this >> keyword, so feel free to comment and let me know. >> > Thanks for fixing this. Do we have some documentation for these requirements? Is it linked from our contributions guidelines? >> On Wed, Feb 6, 2019 at 3:01 PM Anton Marchukov >> wrote: >> >>> Thanks for comments. Yeah, I think since it does not produce extra side >>> effect over the previous behaviour in dead case just something will stop >>> working based on the old assumptions rather than it starts moving incorrect >>> bugs around. >>> >>> I have prepared a change [1], will give it some test on staging gerrit >>> first and then merge and deploy to production gerrit. >>> >>> [1] https://gerrit.ovirt.org/#/c/97605/ >>> >>> On Wed, Feb 6, 2019 at 11:41 AM Yedidyah Bar David >>> wrote: >>> On Wed, Feb 6, 2019 at 12:36 PM Anton Marchukov wrote: > > Hello All. > > I have checked the hooks code. And it indeed just extracts all the links pointing to bugzilla. This is not correct and fails when somebody just mentions a bug in commit message. > > We are about to fix this and adjust the regexp used to explicitly check for "Bug-Url" keyword. I think this is the expected behavior for everybody. +1 > > But just in case I am sending this pre-announcement about the change. Let me know if you anticipate any problems. I think we'll have enough time to fix such problems. It will only affect new patches, history would remain as-is. So main risk is if people had tools/hooks/habits to link to BZs without 'Bug-Url' and expected that to work, and it will now be ignored. Small risk, imo. Thanks! > > Thanks. > > On Tue, Feb 5, 2019 at 10:16 AM Nir Soffer wrote: >> >> If a commit message mention another bug, the CI script try to add the patch >> to the bug in the commit message, and change the bug to POST. >> >> Mentioning another bug in a commit message is good practice, making it >> easier to follow, and avoiding unclear forms like "bug 100" or "BZ#100", >> or even worse shortened urls like https://goo.gl/bPuFGo. >> >> Does it make sense that we cannot link to Red Hat bugzilla like god >> intended? >> >> Here is a proof: >> https://gerrit.ovirt.org/c/97568/ >> >> gerrit-hooks >> Patch Set 1: >> >> Check Bug-Url::1000::WARN, failed to get bug info (private bug or bug doesn't exist >> Check Product::IGNORE, not relevant for branch: master >> Check TM::IGNORE, not relevant for branch: master >> Check Backport::IGNORE, not relevant for branch: master >> Set POST::#1000::WARN, failed to get bug info (private bug or bug doesn't exist) >> Update Tracker::#1000::WARN, failed to get bug info (private bug or bug doesn't exist) >> CI scripts should process urls only inside Bug-Url: tag. >> >> Expected behavior: >> Extract bug urls *only* from Bug-Url: label. >> >> The same issue exists with Related-To: label. >> >> This is not a new bug. I reported it few years ago but for some reason the issue >> was not understood. >> >> Nir >> ___ >> Infra mailing list -- in...@ovirt.org >> To unsubscribe send an email to infra-le...@ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: https://lists.ovirt.org/archives/list/in...@ovirt.org/message/YZKHQTISCF6W3GNXOTWWO3IE4T24SZQQ/ > > > > -- > Anton Marchukov > Team Lead - Release Management - RHV DevOps - Red Hat > > ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https:/
[ovirt-devel] Re: Gerrit Hooks will Start to Check for "Bug-Url" Keyword Explicitly
On Wed, Feb 6, 2019 at 10:18 AM Anton Marchukov wrote: > Hello All. > > Also. Based on the comments I am going to do the exact match, thus it will > require the following: > > 1. "Bug-Url:" should be at the beginning of the new line with no spaces > allowed in between. > 2. No space is allowed between "Bug-Url" and ":". > 3. I will allow space characters (or tab characters) between ":" and the > bug URL. Thought I can make even more strict and e.g. allow only one space. > +1 to all the above. Seems harmless to allow [\t ]+ between : and URL. Although I've never used tab. > > I am just not sure how far the agreement and expectation was for this > keyword, so feel free to comment and let me know. > > On Wed, Feb 6, 2019 at 3:01 PM Anton Marchukov > wrote: > >> Thanks for comments. Yeah, I think since it does not produce extra side >> effect over the previous behaviour in dead case just something will stop >> working based on the old assumptions rather than it starts moving incorrect >> bugs around. >> >> I have prepared a change [1], will give it some test on staging gerrit >> first and then merge and deploy to production gerrit. >> >> [1] https://gerrit.ovirt.org/#/c/97605/ >> >> On Wed, Feb 6, 2019 at 11:41 AM Yedidyah Bar David >> wrote: >> >>> On Wed, Feb 6, 2019 at 12:36 PM Anton Marchukov >>> wrote: >>> > >>> > Hello All. >>> > >>> > I have checked the hooks code. And it indeed just extracts all the >>> links pointing to bugzilla. This is not correct and fails when somebody >>> just mentions a bug in commit message. >>> > >>> > We are about to fix this and adjust the regexp used to explicitly >>> check for "Bug-Url" keyword. I think this is the expected behavior for >>> everybody. >>> >>> +1 >>> >>> > >>> > But just in case I am sending this pre-announcement about the change. >>> Let me know if you anticipate any problems. >>> >>> I think we'll have enough time to fix such problems. It will only affect >>> new patches, history would remain as-is. So main risk is if people had >>> tools/hooks/habits to link to BZs without 'Bug-Url' and expected that to >>> work, and it will now be ignored. Small risk, imo. >>> >>> Thanks! >>> >>> > >>> > Thanks. >>> > >>> > On Tue, Feb 5, 2019 at 10:16 AM Nir Soffer wrote: >>> >> >>> >> If a commit message mention another bug, the CI script try to add the >>> patch >>> >> to the bug in the commit message, and change the bug to POST. >>> >> >>> >> Mentioning another bug in a commit message is good practice, making it >>> >> easier to follow, and avoiding unclear forms like "bug 100" or >>> "BZ#100", >>> >> or even worse shortened urls like https://goo.gl/bPuFGo. >>> >> >>> >> Does it make sense that we cannot link to Red Hat bugzilla like god >>> >> intended? >>> >> >>> >> Here is a proof: >>> >> https://gerrit.ovirt.org/c/97568/ >>> >> >>> >> gerrit-hooks >>> >> Patch Set 1: >>> >> >>> >> Check Bug-Url::1000::WARN, failed to get bug info (private >>> bug or bug doesn't exist >>> >> Check Product::IGNORE, not relevant for branch: master >>> >> Check TM::IGNORE, not relevant for branch: master >>> >> Check Backport::IGNORE, not relevant for branch: master >>> >> Set POST::#1000::WARN, failed to get bug info (private bug or >>> bug doesn't exist) >>> >> Update Tracker::#1000::WARN, failed to get bug info (private >>> bug or bug doesn't exist) >>> >> CI scripts should process urls only inside Bug-Url: tag. >>> >> >>> >> Expected behavior: >>> >> Extract bug urls *only* from Bug-Url: label. >>> >> >>> >> The same issue exists with Related-To: label. >>> >> >>> >> This is not a new bug. I reported it few years ago but for some >>> reason the issue >>> >> was not understood. >>> >> >>> >> Nir >>> >> ___ >>> >> Infra mailing list -- in...@ovirt.org >>> >> To unsubscribe send an email to infra-le...@ovirt.org >>> >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>> >> oVirt Code of Conduct: >>> https://www.ovirt.org/community/about/community-guidelines/ >>> >> List Archives: >>> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/YZKHQTISCF6W3GNXOTWWO3IE4T24SZQQ/ >>> > >>> > >>> > >>> > -- >>> > Anton Marchukov >>> > Team Lead - Release Management - RHV DevOps - Red Hat >>> > >>> > ___ >>> > Devel mailing list -- devel@ovirt.org >>> > To unsubscribe send an email to devel-le...@ovirt.org >>> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>> > oVirt Code of Conduct: >>> https://www.ovirt.org/community/about/community-guidelines/ >>> > List Archives: >>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MFPBLV2MJEG7QNONFOU3KMV2DAUWP5SM/ >>> >>> >>> >>> -- >>> Didi >>> >> >> >> -- >> Anton Marchukov >> Team Lead - Release Management - RHV DevOps - Red Hat >> >> > > -- > Anton Marchukov > Team Lead - Release Management - RHV DevOps - Red Hat > >
[ovirt-devel] Re: Gerrit Hooks will Start to Check for "Bug-Url" Keyword Explicitly
Hello All. Also. Based on the comments I am going to do the exact match, thus it will require the following: 1. "Bug-Url:" should be at the beginning of the new line with no spaces allowed in between. 2. No space is allowed between "Bug-Url" and ":". 3. I will allow space characters (or tab characters) between ":" and the bug URL. Thought I can make even more strict and e.g. allow only one space. I am just not sure how far the agreement and expectation was for this keyword, so feel free to comment and let me know. On Wed, Feb 6, 2019 at 3:01 PM Anton Marchukov wrote: > Thanks for comments. Yeah, I think since it does not produce extra side > effect over the previous behaviour in dead case just something will stop > working based on the old assumptions rather than it starts moving incorrect > bugs around. > > I have prepared a change [1], will give it some test on staging gerrit > first and then merge and deploy to production gerrit. > > [1] https://gerrit.ovirt.org/#/c/97605/ > > On Wed, Feb 6, 2019 at 11:41 AM Yedidyah Bar David > wrote: > >> On Wed, Feb 6, 2019 at 12:36 PM Anton Marchukov >> wrote: >> > >> > Hello All. >> > >> > I have checked the hooks code. And it indeed just extracts all the >> links pointing to bugzilla. This is not correct and fails when somebody >> just mentions a bug in commit message. >> > >> > We are about to fix this and adjust the regexp used to explicitly check >> for "Bug-Url" keyword. I think this is the expected behavior for everybody. >> >> +1 >> >> > >> > But just in case I am sending this pre-announcement about the change. >> Let me know if you anticipate any problems. >> >> I think we'll have enough time to fix such problems. It will only affect >> new patches, history would remain as-is. So main risk is if people had >> tools/hooks/habits to link to BZs without 'Bug-Url' and expected that to >> work, and it will now be ignored. Small risk, imo. >> >> Thanks! >> >> > >> > Thanks. >> > >> > On Tue, Feb 5, 2019 at 10:16 AM Nir Soffer wrote: >> >> >> >> If a commit message mention another bug, the CI script try to add the >> patch >> >> to the bug in the commit message, and change the bug to POST. >> >> >> >> Mentioning another bug in a commit message is good practice, making it >> >> easier to follow, and avoiding unclear forms like "bug 100" or >> "BZ#100", >> >> or even worse shortened urls like https://goo.gl/bPuFGo. >> >> >> >> Does it make sense that we cannot link to Red Hat bugzilla like god >> >> intended? >> >> >> >> Here is a proof: >> >> https://gerrit.ovirt.org/c/97568/ >> >> >> >> gerrit-hooks >> >> Patch Set 1: >> >> >> >> Check Bug-Url::1000::WARN, failed to get bug info (private bug >> or bug doesn't exist >> >> Check Product::IGNORE, not relevant for branch: master >> >> Check TM::IGNORE, not relevant for branch: master >> >> Check Backport::IGNORE, not relevant for branch: master >> >> Set POST::#1000::WARN, failed to get bug info (private bug or >> bug doesn't exist) >> >> Update Tracker::#1000::WARN, failed to get bug info (private >> bug or bug doesn't exist) >> >> CI scripts should process urls only inside Bug-Url: tag. >> >> >> >> Expected behavior: >> >> Extract bug urls *only* from Bug-Url: label. >> >> >> >> The same issue exists with Related-To: label. >> >> >> >> This is not a new bug. I reported it few years ago but for some reason >> the issue >> >> was not understood. >> >> >> >> Nir >> >> ___ >> >> Infra mailing list -- in...@ovirt.org >> >> To unsubscribe send an email to infra-le...@ovirt.org >> >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> >> List Archives: >> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/YZKHQTISCF6W3GNXOTWWO3IE4T24SZQQ/ >> > >> > >> > >> > -- >> > Anton Marchukov >> > Team Lead - Release Management - RHV DevOps - Red Hat >> > >> > ___ >> > Devel mailing list -- devel@ovirt.org >> > To unsubscribe send an email to devel-le...@ovirt.org >> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> > oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> > List Archives: >> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MFPBLV2MJEG7QNONFOU3KMV2DAUWP5SM/ >> >> >> >> -- >> Didi >> > > > -- > Anton Marchukov > Team Lead - Release Management - RHV DevOps - Red Hat > > -- Anton Marchukov Team Lead - Release Management - RHV DevOps - Red Hat ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/
[ovirt-devel] Re: Gerrit Hooks will Start to Check for "Bug-Url" Keyword Explicitly
Thanks for comments. Yeah, I think since it does not produce extra side effect over the previous behaviour in dead case just something will stop working based on the old assumptions rather than it starts moving incorrect bugs around. I have prepared a change [1], will give it some test on staging gerrit first and then merge and deploy to production gerrit. [1] https://gerrit.ovirt.org/#/c/97605/ On Wed, Feb 6, 2019 at 11:41 AM Yedidyah Bar David wrote: > On Wed, Feb 6, 2019 at 12:36 PM Anton Marchukov > wrote: > > > > Hello All. > > > > I have checked the hooks code. And it indeed just extracts all the links > pointing to bugzilla. This is not correct and fails when somebody just > mentions a bug in commit message. > > > > We are about to fix this and adjust the regexp used to explicitly check > for "Bug-Url" keyword. I think this is the expected behavior for everybody. > > +1 > > > > > But just in case I am sending this pre-announcement about the change. > Let me know if you anticipate any problems. > > I think we'll have enough time to fix such problems. It will only affect > new patches, history would remain as-is. So main risk is if people had > tools/hooks/habits to link to BZs without 'Bug-Url' and expected that to > work, and it will now be ignored. Small risk, imo. > > Thanks! > > > > > Thanks. > > > > On Tue, Feb 5, 2019 at 10:16 AM Nir Soffer wrote: > >> > >> If a commit message mention another bug, the CI script try to add the > patch > >> to the bug in the commit message, and change the bug to POST. > >> > >> Mentioning another bug in a commit message is good practice, making it > >> easier to follow, and avoiding unclear forms like "bug 100" or > "BZ#100", > >> or even worse shortened urls like https://goo.gl/bPuFGo. > >> > >> Does it make sense that we cannot link to Red Hat bugzilla like god > >> intended? > >> > >> Here is a proof: > >> https://gerrit.ovirt.org/c/97568/ > >> > >> gerrit-hooks > >> Patch Set 1: > >> > >> Check Bug-Url::1000::WARN, failed to get bug info (private bug > or bug doesn't exist > >> Check Product::IGNORE, not relevant for branch: master > >> Check TM::IGNORE, not relevant for branch: master > >> Check Backport::IGNORE, not relevant for branch: master > >> Set POST::#1000::WARN, failed to get bug info (private bug or > bug doesn't exist) > >> Update Tracker::#1000::WARN, failed to get bug info (private > bug or bug doesn't exist) > >> CI scripts should process urls only inside Bug-Url: tag. > >> > >> Expected behavior: > >> Extract bug urls *only* from Bug-Url: label. > >> > >> The same issue exists with Related-To: label. > >> > >> This is not a new bug. I reported it few years ago but for some reason > the issue > >> was not understood. > >> > >> Nir > >> ___ > >> Infra mailing list -- in...@ovirt.org > >> To unsubscribe send an email to infra-le...@ovirt.org > >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >> oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > >> List Archives: > https://lists.ovirt.org/archives/list/in...@ovirt.org/message/YZKHQTISCF6W3GNXOTWWO3IE4T24SZQQ/ > > > > > > > > -- > > Anton Marchukov > > Team Lead - Release Management - RHV DevOps - Red Hat > > > > ___ > > Devel mailing list -- devel@ovirt.org > > To unsubscribe send an email to devel-le...@ovirt.org > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MFPBLV2MJEG7QNONFOU3KMV2DAUWP5SM/ > > > > -- > Didi > -- Anton Marchukov Team Lead - Release Management - RHV DevOps - Red Hat ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/37VM4RPI2UCSLHVWPFZ32KOGW44KGPWD/
[ovirt-devel] Re: Silent errors in storage code on Vdsm startup
On Wed, Feb 6, 2019 at 11:11 AM Milan Zamazal wrote: > Nir Soffer writes: > > > Even if you port entire vdsm to python 3, sanlock does not ship yet > > python 3 bindings, so you cannot have any storage except local storage, > > iso domain and export domain. > > I started working on porting sanlock Python bindings to Python 3 in > order to be able to access storage. I have only my private dirty > changes at the moment; if they prove to be working at least partially, I > can make patches based on them and post them. > Cool! Marian from the LVM team has started to work on this but did post any patches yet. Lets continue the discussion about sanlock for python 3 in sanlock-devel mailing list: https://lists.fedorahosted.org/archives/list/sanlock-de...@lists.fedorahosted.org/ > > > Can you check if https://gerrit.ovirt.org/c/97590/ fixes this issue? > > Yes, Vdsm starts with that patch and I can go on with my Python 3 work. > > Thank you for explanation and help! > > Milan > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/BI4DEHHOMUSGE7V4V6ITWP7NVNSBSIBT/
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, Feb 6, 2019 at 11:05 AM Barak Korren wrote: > > > בתאריך יום ד׳, 6 בפבר׳ 2019, 12:25, מאת Simone Tiraboschi < > stira...@redhat.com>: > >> >> >> On Wed, Feb 6, 2019 at 11:17 AM Barak Korren wrote: >> >>> >>> >>> On Wed, 6 Feb 2019 at 11:57, Simone Tiraboschi >>> wrote: >>> On Wed, Feb 6, 2019 at 10:44 AM Barak Korren wrote: > > > On Wed, 6 Feb 2019 at 11:34, Simone Tiraboschi > wrote: > >> >> >> On Wed, Feb 6, 2019 at 10:23 AM Barak Korren >> wrote: >> >>> >>> >>> On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi >>> wrote: >>> On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg wrote: > On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi < > stira...@redhat.com> wrote: > > > > > > > > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg > wrote: > >> > >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi < > stira...@redhat.com> wrote: > >> > > >> > > >> > > >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron > wrote: > >> >> > >> >> Hi, > >> >> > >> >> Please note that ovirt-ansible-hosted-engine-setup has a > versioning problem with the package and is causing bootstrap to fail > for > upgrade suite [1] > >> >> > >> >> This is effecting all projects, its been reported to the > developers and should be fixed as soon as possible. > >> >> > >> >> you can view CQ status here: > >> >> > https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ > >> >> > >> >> [1] http://pastebin.test.redhat.com/708086 > >> > >> It is unfair to refer to an internal pastebin here. It is also > not > >> very sensible, as it is quite short. > >> > >> 2019-02-05 11:23:51,390-0500 ERROR > >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 > Yum > >> > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context > >> context._executeMethod:142 method exception > >> Traceback (most recent call last): > >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line > 132, > >> in _executeMethod > >> method['method']() > >> File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > >> line 248, in _packages > >> self.processTransaction() > >> File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > >> line 262, in processTransaction > >> if self._miniyum.buildTransaction(): > >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line > 920, > >> in buildTransaction > >> raise yum.Errors.YumBaseError(msg) > >> YumBaseError: > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context > >> context._executeMethod:151 Failed to execute stage 'Package > >> installation': > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,413-0500 DEBUG > >> otopi.plugins.otopi.debug.debug_failure.debug_failure > >> debug_failure._notification:100 tcp connections: > >> > >> >> > >> > > >> > The issue is that on github we already have > >> > VERSION="1.0.10" > >> > as we can see in > >> > > https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 > >> > > >> > And this has been bumped before the commit that now is > reported as broken. > >> > > >> > CI instead is still building the package as 1.0.9 ignoring > the commit that bumped the version. > >> > Honestly I don't know how I can fix it if the version value > is already the desired one in the source code. > >> > >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only > >> > https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm > >> Not even under "tested": > >> > https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.2019012
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
בתאריך יום ד׳, 6 בפבר׳ 2019, 12:25, מאת Simone Tiraboschi < stira...@redhat.com>: > > > On Wed, Feb 6, 2019 at 11:17 AM Barak Korren wrote: > >> >> >> On Wed, 6 Feb 2019 at 11:57, Simone Tiraboschi >> wrote: >> >>> >>> >>> On Wed, Feb 6, 2019 at 10:44 AM Barak Korren wrote: >>> On Wed, 6 Feb 2019 at 11:34, Simone Tiraboschi wrote: > > > On Wed, Feb 6, 2019 at 10:23 AM Barak Korren > wrote: > >> >> >> On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi >> wrote: >> >>> >>> >>> On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg >>> wrote: >>> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi < stira...@redhat.com> wrote: > > > > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg wrote: >> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi < stira...@redhat.com> wrote: >> > >> > >> > >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: >> >> >> >> Hi, >> >> >> >> Please note that ovirt-ansible-hosted-engine-setup has a versioning problem with the package and is causing bootstrap to fail for upgrade suite [1] >> >> >> >> This is effecting all projects, its been reported to the developers and should be fixed as soon as possible. >> >> >> >> you can view CQ status here: >> >> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ >> >> >> >> [1] http://pastebin.test.redhat.com/708086 >> >> It is unfair to refer to an internal pastebin here. It is also not >> very sensible, as it is quite short. >> >> 2019-02-05 11:23:51,390-0500 ERROR >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context >> context._executeMethod:142 method exception >> Traceback (most recent call last): >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, >> in _executeMethod >> method['method']() >> File "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> line 248, in _packages >> self.processTransaction() >> File "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> line 262, in processTransaction >> if self._miniyum.buildTransaction(): >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, >> in buildTransaction >> raise yum.Errors.YumBaseError(msg) >> YumBaseError: [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context >> context._executeMethod:151 Failed to execute stage 'Package >> installation': [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> 2019-02-05 11:23:51,413-0500 DEBUG >> otopi.plugins.otopi.debug.debug_failure.debug_failure >> debug_failure._notification:100 tcp connections: >> >> >> >> > >> > The issue is that on github we already have >> > VERSION="1.0.10" >> > as we can see in >> > https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 >> > >> > And this has been bumped before the commit that now is reported as broken. >> > >> > CI instead is still building the package as 1.0.9 ignoring the commit that bumped the version. >> > Honestly I don't know how I can fix it if the version value is already the desired one in the source code. >> >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only >> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> Not even under "tested": >> https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> >> Simone, can you doublecheck that its artifacts have been built and >> have been accepted by the change queue? > >
[ovirt-devel] Re: imageio proxy and engine dev setup
On Wed, Feb 6, 2019, 5:26 AM Fedor Gavrilov wrote: > Thanks, Roy! I will try setting it up according to what you suggested. > Last attempt failed indeed: according to logs, both daemon and proxy tried > establishing a connection with each other with some 200 OK in logs, no > error messages but nevertheless upload did not happen after all. > > Speaking about it, does anyone know more straightforward way to have ISO > disk on data domain? I am not as much interested in debugging ISO upload > but rather attaching it to VM. > +1, rsync to the iso domain directory has always been useful for me. How do we do similar with data domains? > Thanks, > Fedor > > - Исходное сообщение - > От: "Roy Golan" > Кому: "Nir Soffer" > Копия: "devel" , "Fedor Gavrilov" > Отправленные: Среда, 6 Февраль 2019 г 9:47:27 > Тема: [ovirt-devel] Re: imageio proxy and engine dev setup > > > > On Tue, 5 Feb 2019 at 20:58, Nir Soffer < nsof...@redhat.com > wrote: > > > > On Tue, Feb 5, 2019 at 6:46 PM Fedor Gavrilov < fgavr...@redhat.com > > wrote: > > > Right! > > Oh, it just occured to me that imageio prject is two parts and they expect > me to be in proxy/ directory in the installation docs. > There is indeed a make-install goal there :) > > Tried running it and it seems now setup script recognizes it now. > > Right, the instructions should be improved to show all the steps. > > This should work: > > git clone ... > cd ovirt-imageio > make > cd proxy > make install-dev ENGINE_PREFIX=/home/nsoffer/ovirt-engine > > /home/nsoffer/ovirt-engine/bin/engine-setup > (configure it...) > > There are 2 bugs here - 1. the engine will fail to talk with the proxy > because the default proxy > address is localhost:54323 which will fail ssl verification. This needs to > be address in the > engine setup plugin > 2. The engine will not fail an attempt to upload when it can't actually > communicate with the proxy. ImageTransfer needs validation there. > > To fix it you need to: > $ENGINE_PREFIX/bin/engine-config -s > ImageProxyAddress=OVIRT-ENGINE-FQDN:54323 > > > > > export PYTHONPATH=/home/nsoffer/src/ovirt-imageio/common > ./ovirt-imageio-proxy > > Nir > > > > > Thanks! > Fedor Gavrilov > > - Исходное сообщение - > От: "Fedor Gavrilov" < fgavr...@redhat.com > > Кому: "Nir Soffer" < nsof...@redhat.com > > Копия: "devel" < devel@ovirt.org > > Отправленные: Вторник, 5 Февраль 2019 г 17:33:15 > Тема: [ovirt-devel] Re: imageio proxy and engine dev setup > > Hi, > > I tried that already unfortunately. Executing make install-dev from > imageio sources directory complains about no such target. > Autocomplete for make suggests the following: > > [fgavrilo@localhost ovirt-imageio]$ make > all check clean common daemon dist proxy rpm srpm > > Wasn't successful with these targets either. > > Fedor Gavrilov > > - Исходное сообщение - > От: "Nir Soffer" < nsof...@redhat.com > > Кому: "Fedor Gavrilov" < fgavr...@redhat.com > > Копия: "devel" < devel@ovirt.org >, "Daniel Erez" < de...@redhat.com >, > "Roy Golan" < rgo...@redhat.com > > Отправленные: Вторник, 5 Февраль 2019 г 17:18:42 > Тема: Re: [ovirt-devel] imageio proxy and engine dev setup > > On Tue, Feb 5, 2019 at 5:05 PM Fedor Gavrilov < fgavr...@redhat.com > > wrote: > > > Hi, > > > > It seems to be rather difficult to have development setup for the engine > > with imageio proxy. > > engine-setup script never asks about it, running it again with > > --reconfigure-optional-components changes nothing and answers file > contains > > no mention of imageio (thus, > > https://bugzilla.redhat.com/show_bug.cgi?id=1446094 does not look to be > > fixed for dev setups). There is no package to install separately either. > > > > Quite confused now. Do you happen to know what am I missing? > > > > Installing with development engine (not installed with rpms) is documented > here: > > > > http://ovirt.github.io/ovirt-imageio/installation.html#installation-with-ovirt-engine-developer-environment > > > > > > Fedor Gavrilov > > ___ > > Devel mailing list -- devel@ovirt.org > > To unsubscribe send an email to devel-le...@ovirt.org > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > > oVirt Code of Conduct: > > https://www.ovirt.org/community/about/community-guidelines/ > > List Archives: > > > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JTLEMRZMGMNNLKNCJ45L2VJO5EANY56W/ > > > ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/HVEXCKBLSRDRTSLHM2SYCHFQVVQQEBUF/ > > ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-le...@ovirt.or
[ovirt-devel] Re: Gerrit Hooks will Start to Check for "Bug-Url" Keyword Explicitly
On Wed, Feb 6, 2019 at 12:36 PM Anton Marchukov wrote: > > Hello All. > > I have checked the hooks code. And it indeed just extracts all the links > pointing to bugzilla. This is not correct and fails when somebody just > mentions a bug in commit message. > > We are about to fix this and adjust the regexp used to explicitly check for > "Bug-Url" keyword. I think this is the expected behavior for everybody. +1 > > But just in case I am sending this pre-announcement about the change. Let me > know if you anticipate any problems. I think we'll have enough time to fix such problems. It will only affect new patches, history would remain as-is. So main risk is if people had tools/hooks/habits to link to BZs without 'Bug-Url' and expected that to work, and it will now be ignored. Small risk, imo. Thanks! > > Thanks. > > On Tue, Feb 5, 2019 at 10:16 AM Nir Soffer wrote: >> >> If a commit message mention another bug, the CI script try to add the patch >> to the bug in the commit message, and change the bug to POST. >> >> Mentioning another bug in a commit message is good practice, making it >> easier to follow, and avoiding unclear forms like "bug 100" or >> "BZ#100", >> or even worse shortened urls like https://goo.gl/bPuFGo. >> >> Does it make sense that we cannot link to Red Hat bugzilla like god >> intended? >> >> Here is a proof: >> https://gerrit.ovirt.org/c/97568/ >> >> gerrit-hooks >> Patch Set 1: >> >> Check Bug-Url::1000::WARN, failed to get bug info (private bug or >> bug doesn't exist >> Check Product::IGNORE, not relevant for branch: master >> Check TM::IGNORE, not relevant for branch: master >> Check Backport::IGNORE, not relevant for branch: master >> Set POST::#1000::WARN, failed to get bug info (private bug or bug >> doesn't exist) >> Update Tracker::#1000::WARN, failed to get bug info (private bug or >> bug doesn't exist) >> CI scripts should process urls only inside Bug-Url: tag. >> >> Expected behavior: >> Extract bug urls *only* from Bug-Url: label. >> >> The same issue exists with Related-To: label. >> >> This is not a new bug. I reported it few years ago but for some reason the >> issue >> was not understood. >> >> Nir >> ___ >> Infra mailing list -- in...@ovirt.org >> To unsubscribe send an email to infra-le...@ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/YZKHQTISCF6W3GNXOTWWO3IE4T24SZQQ/ > > > > -- > Anton Marchukov > Team Lead - Release Management - RHV DevOps - Red Hat > > ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MFPBLV2MJEG7QNONFOU3KMV2DAUWP5SM/ -- Didi ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/F56JQUY26FU5ERYMDNIKW6SUDRYV56L4/
[ovirt-devel] Gerrit Hooks will Start to Check for "Bug-Url" Keyword Explicitly
Hello All. I have checked the hooks code. And it indeed just extracts all the links pointing to bugzilla. This is not correct and fails when somebody just mentions a bug in commit message. We are about to fix this and adjust the regexp used to explicitly check for "Bug-Url" keyword. I think this is the expected behavior for everybody. But just in case I am sending this pre-announcement about the change. Let me know if you anticipate any problems. Thanks. On Tue, Feb 5, 2019 at 10:16 AM Nir Soffer wrote: > If a commit message mention another bug, the CI script try to add the patch > to the bug in the commit message, and change the bug to POST. > > Mentioning another bug in a commit message is good practice, making it > easier to follow, and avoiding unclear forms like "bug 100" or > "BZ#100", > or even worse shortened urls like https://goo.gl/bPuFGo. > > Does it make sense that we cannot link to Red Hat bugzilla like god > intended? > > Here is a proof: > https://gerrit.ovirt.org/c/97568/ > > gerrit-hooks > Patch Set 1: > > Check Bug-Url::1000::WARN, failed to get bug info (private bug or > bug doesn't exist > Check Product::IGNORE, not relevant for branch: master > Check TM::IGNORE, not relevant for branch: master > Check Backport::IGNORE, not relevant for branch: master > Set POST::#1000::WARN, failed to get bug info (private bug or bug > doesn't exist) > Update Tracker::#1000::WARN, failed to get bug info (private bug > or bug doesn't exist) > CI scripts should process urls only inside Bug-Url: tag. > > Expected behavior: > Extract bug urls *only* from Bug-Url: label. > > The same issue exists with Related-To: label. > > This is not a new bug. I reported it few years ago but for some reason the > issue > was not understood. > > Nir > ___ > Infra mailing list -- in...@ovirt.org > To unsubscribe send an email to infra-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/in...@ovirt.org/message/YZKHQTISCF6W3GNXOTWWO3IE4T24SZQQ/ > -- Anton Marchukov Team Lead - Release Management - RHV DevOps - Red Hat ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MFPBLV2MJEG7QNONFOU3KMV2DAUWP5SM/
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, Feb 6, 2019 at 11:17 AM Barak Korren wrote: > > > On Wed, 6 Feb 2019 at 11:57, Simone Tiraboschi > wrote: > >> >> >> On Wed, Feb 6, 2019 at 10:44 AM Barak Korren wrote: >> >>> >>> >>> On Wed, 6 Feb 2019 at 11:34, Simone Tiraboschi >>> wrote: >>> On Wed, Feb 6, 2019 at 10:23 AM Barak Korren wrote: > > > On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi > wrote: > >> >> >> On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg >> wrote: >> >>> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi < >>> stira...@redhat.com> wrote: >>> > >>> > >>> > >>> > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg >>> wrote: >>> >> >>> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi < >>> stira...@redhat.com> wrote: >>> >> > >>> >> > >>> >> > >>> >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron >>> wrote: >>> >> >> >>> >> >> Hi, >>> >> >> >>> >> >> Please note that ovirt-ansible-hosted-engine-setup has a >>> versioning problem with the package and is causing bootstrap to fail for >>> upgrade suite [1] >>> >> >> >>> >> >> This is effecting all projects, its been reported to the >>> developers and should be fixed as soon as possible. >>> >> >> >>> >> >> you can view CQ status here: >>> >> >> >>> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ >>> >> >> >>> >> >> [1] http://pastebin.test.redhat.com/708086 >>> >> >>> >> It is unfair to refer to an internal pastebin here. It is also not >>> >> very sensible, as it is quite short. >>> >> >>> >> 2019-02-05 11:23:51,390-0500 ERROR >>> >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum >>> >> >>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >>> >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context >>> >> context._executeMethod:142 method exception >>> >> Traceback (most recent call last): >>> >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line >>> 132, >>> >> in _executeMethod >>> >> method['method']() >>> >> File >>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >>> >> line 248, in _packages >>> >> self.processTransaction() >>> >> File >>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >>> >> line 262, in processTransaction >>> >> if self._miniyum.buildTransaction(): >>> >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line >>> 920, >>> >> in buildTransaction >>> >> raise yum.Errors.YumBaseError(msg) >>> >> YumBaseError: >>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >>> >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context >>> >> context._executeMethod:151 Failed to execute stage 'Package >>> >> installation': >>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >>> >> 2019-02-05 11:23:51,413-0500 DEBUG >>> >> otopi.plugins.otopi.debug.debug_failure.debug_failure >>> >> debug_failure._notification:100 tcp connections: >>> >> >>> >> >> >>> >> > >>> >> > The issue is that on github we already have >>> >> > VERSION="1.0.10" >>> >> > as we can see in >>> >> > >>> https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 >>> >> > >>> >> > And this has been bumped before the commit that now is reported >>> as broken. >>> >> > >>> >> > CI instead is still building the package as 1.0.9 ignoring the >>> commit that bumped the version. >>> >> > Honestly I don't know how I can fix it if the version value is >>> already the desired one in the source code. >>> >> >>> >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only >>> >> >>> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >>> >> Not even under "tested": >>> >> >>> https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >>> >> >>> >> Simone, can you doublecheck that its artifacts have been built and >>> >> have been accepted by the change queue? >>> > >>> > >>> > It has been built here once as 1.0.10: >>> > >>> https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ >>> > >>> > then on the next commit, CI started building it again as 1.0.9 >>> al
[ovirt-devel] Re: imageio proxy and engine dev setup
Thanks, Roy! I will try setting it up according to what you suggested. Last attempt failed indeed: according to logs, both daemon and proxy tried establishing a connection with each other with some 200 OK in logs, no error messages but nevertheless upload did not happen after all. Speaking about it, does anyone know more straightforward way to have ISO disk on data domain? I am not as much interested in debugging ISO upload but rather attaching it to VM. Thanks, Fedor - Исходное сообщение - От: "Roy Golan" Кому: "Nir Soffer" Копия: "devel" , "Fedor Gavrilov" Отправленные: Среда, 6 Февраль 2019 г 9:47:27 Тема: [ovirt-devel] Re: imageio proxy and engine dev setup On Tue, 5 Feb 2019 at 20:58, Nir Soffer < nsof...@redhat.com > wrote: On Tue, Feb 5, 2019 at 6:46 PM Fedor Gavrilov < fgavr...@redhat.com > wrote: Right! Oh, it just occured to me that imageio prject is two parts and they expect me to be in proxy/ directory in the installation docs. There is indeed a make-install goal there :) Tried running it and it seems now setup script recognizes it now. Right, the instructions should be improved to show all the steps. This should work: git clone ... cd ovirt-imageio make cd proxy make install-dev ENGINE_PREFIX=/home/nsoffer/ovirt-engine /home/nsoffer/ovirt-engine/bin/engine-setup (configure it...) There are 2 bugs here - 1. the engine will fail to talk with the proxy because the default proxy address is localhost:54323 which will fail ssl verification. This needs to be address in the engine setup plugin 2. The engine will not fail an attempt to upload when it can't actually communicate with the proxy. ImageTransfer needs validation there. To fix it you need to: $ENGINE_PREFIX/bin/engine-config -s ImageProxyAddress=OVIRT-ENGINE-FQDN:54323 export PYTHONPATH=/home/nsoffer/src/ovirt-imageio/common ./ovirt-imageio-proxy Nir Thanks! Fedor Gavrilov - Исходное сообщение - От: "Fedor Gavrilov" < fgavr...@redhat.com > Кому: "Nir Soffer" < nsof...@redhat.com > Копия: "devel" < devel@ovirt.org > Отправленные: Вторник, 5 Февраль 2019 г 17:33:15 Тема: [ovirt-devel] Re: imageio proxy and engine dev setup Hi, I tried that already unfortunately. Executing make install-dev from imageio sources directory complains about no such target. Autocomplete for make suggests the following: [fgavrilo@localhost ovirt-imageio]$ make all check clean common daemon dist proxy rpm srpm Wasn't successful with these targets either. Fedor Gavrilov - Исходное сообщение - От: "Nir Soffer" < nsof...@redhat.com > Кому: "Fedor Gavrilov" < fgavr...@redhat.com > Копия: "devel" < devel@ovirt.org >, "Daniel Erez" < de...@redhat.com >, "Roy Golan" < rgo...@redhat.com > Отправленные: Вторник, 5 Февраль 2019 г 17:18:42 Тема: Re: [ovirt-devel] imageio proxy and engine dev setup On Tue, Feb 5, 2019 at 5:05 PM Fedor Gavrilov < fgavr...@redhat.com > wrote: > Hi, > > It seems to be rather difficult to have development setup for the engine > with imageio proxy. > engine-setup script never asks about it, running it again with > --reconfigure-optional-components changes nothing and answers file contains > no mention of imageio (thus, > https://bugzilla.redhat.com/show_bug.cgi?id=1446094 does not look to be > fixed for dev setups). There is no package to install separately either. > > Quite confused now. Do you happen to know what am I missing? > Installing with development engine (not installed with rpms) is documented here: http://ovirt.github.io/ovirt-imageio/installation.html#installation-with-ovirt-engine-developer-environment > > Fedor Gavrilov > ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JTLEMRZMGMNNLKNCJ45L2VJO5EANY56W/ > > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/HVEXCKBLSRDRTSLHM2SYCHFQVVQQEBUF/ ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IPWTKN6Y2GGF3JBTZXH2RG75E2EDC4DX/ ___ Devel mailing list -- dev
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, 6 Feb 2019 at 11:57, Simone Tiraboschi wrote: > > > On Wed, Feb 6, 2019 at 10:44 AM Barak Korren wrote: > >> >> >> On Wed, 6 Feb 2019 at 11:34, Simone Tiraboschi >> wrote: >> >>> >>> >>> On Wed, Feb 6, 2019 at 10:23 AM Barak Korren wrote: >>> On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi wrote: > > > On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg > wrote: > >> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi < >> stira...@redhat.com> wrote: >> > >> > >> > >> > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg >> wrote: >> >> >> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi < >> stira...@redhat.com> wrote: >> >> > >> >> > >> >> > >> >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron >> wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Please note that ovirt-ansible-hosted-engine-setup has a >> versioning problem with the package and is causing bootstrap to fail for >> upgrade suite [1] >> >> >> >> >> >> This is effecting all projects, its been reported to the >> developers and should be fixed as soon as possible. >> >> >> >> >> >> you can view CQ status here: >> >> >> >> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ >> >> >> >> >> >> [1] http://pastebin.test.redhat.com/708086 >> >> >> >> It is unfair to refer to an internal pastebin here. It is also not >> >> very sensible, as it is quite short. >> >> >> >> 2019-02-05 11:23:51,390-0500 ERROR >> >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum >> >> >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context >> >> context._executeMethod:142 method exception >> >> Traceback (most recent call last): >> >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line >> 132, >> >> in _executeMethod >> >> method['method']() >> >> File >> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> >> line 248, in _packages >> >> self.processTransaction() >> >> File >> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> >> line 262, in processTransaction >> >> if self._miniyum.buildTransaction(): >> >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line >> 920, >> >> in buildTransaction >> >> raise yum.Errors.YumBaseError(msg) >> >> YumBaseError: >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context >> >> context._executeMethod:151 Failed to execute stage 'Package >> >> installation': >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> >> 2019-02-05 11:23:51,413-0500 DEBUG >> >> otopi.plugins.otopi.debug.debug_failure.debug_failure >> >> debug_failure._notification:100 tcp connections: >> >> >> >> >> >> >> > >> >> > The issue is that on github we already have >> >> > VERSION="1.0.10" >> >> > as we can see in >> >> > >> https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 >> >> > >> >> > And this has been bumped before the commit that now is reported >> as broken. >> >> > >> >> > CI instead is still building the package as 1.0.9 ignoring the >> commit that bumped the version. >> >> > Honestly I don't know how I can fix it if the version value is >> already the desired one in the source code. >> >> >> >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only >> >> >> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> >> Not even under "tested": >> >> >> https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> >> >> >> Simone, can you doublecheck that its artifacts have been built and >> >> have been accepted by the change queue? >> > >> > >> > It has been built here once as 1.0.10: >> > >> https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ >> > >> > then on the next commit, CI started building it again as 1.0.9 >> although in the source code we have 1.0.10 and so this issue. >> >> I don't understand the issue yet (that's not surprising as I do not >> know what is that "ghpush" job). Which CI job
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, Feb 6, 2019 at 10:44 AM Barak Korren wrote: > > > On Wed, 6 Feb 2019 at 11:34, Simone Tiraboschi > wrote: > >> >> >> On Wed, Feb 6, 2019 at 10:23 AM Barak Korren wrote: >> >>> >>> >>> On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi >>> wrote: >>> On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg wrote: > On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi > wrote: > > > > > > > > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg > wrote: > >> > >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi < > stira...@redhat.com> wrote: > >> > > >> > > >> > > >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: > >> >> > >> >> Hi, > >> >> > >> >> Please note that ovirt-ansible-hosted-engine-setup has a > versioning problem with the package and is causing bootstrap to fail for > upgrade suite [1] > >> >> > >> >> This is effecting all projects, its been reported to the > developers and should be fixed as soon as possible. > >> >> > >> >> you can view CQ status here: > >> >> > https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ > >> >> > >> >> [1] http://pastebin.test.redhat.com/708086 > >> > >> It is unfair to refer to an internal pastebin here. It is also not > >> very sensible, as it is quite short. > >> > >> 2019-02-05 11:23:51,390-0500 ERROR > >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum > >> > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context > >> context._executeMethod:142 method exception > >> Traceback (most recent call last): > >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, > >> in _executeMethod > >> method['method']() > >> File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > >> line 248, in _packages > >> self.processTransaction() > >> File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > >> line 262, in processTransaction > >> if self._miniyum.buildTransaction(): > >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, > >> in buildTransaction > >> raise yum.Errors.YumBaseError(msg) > >> YumBaseError: > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context > >> context._executeMethod:151 Failed to execute stage 'Package > >> installation': > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,413-0500 DEBUG > >> otopi.plugins.otopi.debug.debug_failure.debug_failure > >> debug_failure._notification:100 tcp connections: > >> > >> >> > >> > > >> > The issue is that on github we already have > >> > VERSION="1.0.10" > >> > as we can see in > >> > > https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 > >> > > >> > And this has been bumped before the commit that now is reported > as broken. > >> > > >> > CI instead is still building the package as 1.0.9 ignoring the > commit that bumped the version. > >> > Honestly I don't know how I can fix it if the version value is > already the desired one in the source code. > >> > >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only > >> > https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm > >> Not even under "tested": > >> > https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm > >> > >> Simone, can you doublecheck that its artifacts have been built and > >> have been accepted by the change queue? > > > > > > It has been built here once as 1.0.10: > > > https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ > > > > then on the next commit, CI started building it again as 1.0.9 > although in the source code we have 1.0.10 and so this issue. > > I don't understand the issue yet (that's not surprising as I do not > know what is that "ghpush" job). Which CI job has built the wrong > version? can you share its logs? who owns it? > In the git log I see: commit b5a6c1db135d81d75f3330160e7ef4a84c97fd60 (HEAD -> master, upstream/master, origin/master, origin/HEA
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, 6 Feb 2019 at 11:34, Simone Tiraboschi wrote: > > > On Wed, Feb 6, 2019 at 10:23 AM Barak Korren wrote: > >> >> >> On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi >> wrote: >> >>> >>> >>> On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg >>> wrote: >>> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi wrote: > > > > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg wrote: >> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi < stira...@redhat.com> wrote: >> > >> > >> > >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: >> >> >> >> Hi, >> >> >> >> Please note that ovirt-ansible-hosted-engine-setup has a versioning problem with the package and is causing bootstrap to fail for upgrade suite [1] >> >> >> >> This is effecting all projects, its been reported to the developers and should be fixed as soon as possible. >> >> >> >> you can view CQ status here: >> >> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ >> >> >> >> [1] http://pastebin.test.redhat.com/708086 >> >> It is unfair to refer to an internal pastebin here. It is also not >> very sensible, as it is quite short. >> >> 2019-02-05 11:23:51,390-0500 ERROR >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context >> context._executeMethod:142 method exception >> Traceback (most recent call last): >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, >> in _executeMethod >> method['method']() >> File "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> line 248, in _packages >> self.processTransaction() >> File "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> line 262, in processTransaction >> if self._miniyum.buildTransaction(): >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, >> in buildTransaction >> raise yum.Errors.YumBaseError(msg) >> YumBaseError: [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context >> context._executeMethod:151 Failed to execute stage 'Package >> installation': [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> 2019-02-05 11:23:51,413-0500 DEBUG >> otopi.plugins.otopi.debug.debug_failure.debug_failure >> debug_failure._notification:100 tcp connections: >> >> >> >> > >> > The issue is that on github we already have >> > VERSION="1.0.10" >> > as we can see in >> > https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 >> > >> > And this has been bumped before the commit that now is reported as broken. >> > >> > CI instead is still building the package as 1.0.9 ignoring the commit that bumped the version. >> > Honestly I don't know how I can fix it if the version value is already the desired one in the source code. >> >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only >> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> Not even under "tested": >> https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> >> Simone, can you doublecheck that its artifacts have been built and >> have been accepted by the change queue? > > > It has been built here once as 1.0.10: > https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ > > then on the next commit, CI started building it again as 1.0.9 although in the source code we have 1.0.10 and so this issue. I don't understand the issue yet (that's not surprising as I do not know what is that "ghpush" job). Which CI job has built the wrong version? can you share its logs? who owns it? >>> >>> In the git log I see: >>> commit b5a6c1db135d81d75f3330160e7ef4a84c97fd60 (HEAD -> master, >>> upstream/master, origin/master, origin/HEAD, nolog) >>> Author: Simone Tiraboschi >>> Date: Tue Feb 5 10:56:58 2019 +0100 >>> >>> Avoid using no_log when we have to pass back values to otopi >>> >>> commit 96974fad1ee6aee
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, Feb 6, 2019 at 10:23 AM Barak Korren wrote: > > > On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi > wrote: > >> >> >> On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg wrote: >> >>> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi >>> wrote: >>> > >>> > >>> > >>> > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg >>> wrote: >>> >> >>> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi < >>> stira...@redhat.com> wrote: >>> >> > >>> >> > >>> >> > >>> >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: >>> >> >> >>> >> >> Hi, >>> >> >> >>> >> >> Please note that ovirt-ansible-hosted-engine-setup has a >>> versioning problem with the package and is causing bootstrap to fail for >>> upgrade suite [1] >>> >> >> >>> >> >> This is effecting all projects, its been reported to the >>> developers and should be fixed as soon as possible. >>> >> >> >>> >> >> you can view CQ status here: >>> >> >> >>> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ >>> >> >> >>> >> >> [1] http://pastebin.test.redhat.com/708086 >>> >> >>> >> It is unfair to refer to an internal pastebin here. It is also not >>> >> very sensible, as it is quite short. >>> >> >>> >> 2019-02-05 11:23:51,390-0500 ERROR >>> >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum >>> >> >>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >>> >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context >>> >> context._executeMethod:142 method exception >>> >> Traceback (most recent call last): >>> >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, >>> >> in _executeMethod >>> >> method['method']() >>> >> File >>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >>> >> line 248, in _packages >>> >> self.processTransaction() >>> >> File >>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >>> >> line 262, in processTransaction >>> >> if self._miniyum.buildTransaction(): >>> >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, >>> >> in buildTransaction >>> >> raise yum.Errors.YumBaseError(msg) >>> >> YumBaseError: >>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >>> >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context >>> >> context._executeMethod:151 Failed to execute stage 'Package >>> >> installation': >>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >>> >> 2019-02-05 11:23:51,413-0500 DEBUG >>> >> otopi.plugins.otopi.debug.debug_failure.debug_failure >>> >> debug_failure._notification:100 tcp connections: >>> >> >>> >> >> >>> >> > >>> >> > The issue is that on github we already have >>> >> > VERSION="1.0.10" >>> >> > as we can see in >>> >> > >>> https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 >>> >> > >>> >> > And this has been bumped before the commit that now is reported as >>> broken. >>> >> > >>> >> > CI instead is still building the package as 1.0.9 ignoring the >>> commit that bumped the version. >>> >> > Honestly I don't know how I can fix it if the version value is >>> already the desired one in the source code. >>> >> >>> >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only >>> >> >>> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >>> >> Not even under "tested": >>> >> >>> https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >>> >> >>> >> Simone, can you doublecheck that its artifacts have been built and >>> >> have been accepted by the change queue? >>> > >>> > >>> > It has been built here once as 1.0.10: >>> > >>> https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ >>> > >>> > then on the next commit, CI started building it again as 1.0.9 >>> although in the source code we have 1.0.10 and so this issue. >>> >>> I don't understand the issue yet (that's not surprising as I do not >>> know what is that "ghpush" job). Which CI job has built the wrong >>> version? can you share its logs? who owns it? >>> >> >> In the git log I see: >> commit b5a6c1db135d81d75f3330160e7ef4a84c97fd60 (HEAD -> master, >> upstream/master, origin/master, origin/HEAD, nolog) >> Author: Simone Tiraboschi >> Date: Tue Feb 5 10:56:58 2019 +0100 >> >> Avoid using no_log when we have to pass back values to otopi >> >> commit 96974fad1ee6aee33f8183e49240f8a2a7a617d4 >> Author: Simone Tiraboschi >> Date: Thu Jan 31 16:39:58 2019 +0100 >> >> use dynamic inclusion to avoid tag inheritance >> >> commit 4a9a23fb8e88acba5af4feb
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi wrote: > > > On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg wrote: > >> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi >> wrote: >> > >> > >> > >> > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg >> wrote: >> >> >> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi >> wrote: >> >> > >> >> > >> >> > >> >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Please note that ovirt-ansible-hosted-engine-setup has a versioning >> problem with the package and is causing bootstrap to fail for upgrade suite >> [1] >> >> >> >> >> >> This is effecting all projects, its been reported to the developers >> and should be fixed as soon as possible. >> >> >> >> >> >> you can view CQ status here: >> >> >> >> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ >> >> >> >> >> >> [1] http://pastebin.test.redhat.com/708086 >> >> >> >> It is unfair to refer to an internal pastebin here. It is also not >> >> very sensible, as it is quite short. >> >> >> >> 2019-02-05 11:23:51,390-0500 ERROR >> >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum >> >> >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context >> >> context._executeMethod:142 method exception >> >> Traceback (most recent call last): >> >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, >> >> in _executeMethod >> >> method['method']() >> >> File >> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> >> line 248, in _packages >> >> self.processTransaction() >> >> File >> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> >> line 262, in processTransaction >> >> if self._miniyum.buildTransaction(): >> >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, >> >> in buildTransaction >> >> raise yum.Errors.YumBaseError(msg) >> >> YumBaseError: >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context >> >> context._executeMethod:151 Failed to execute stage 'Package >> >> installation': >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> >> 2019-02-05 11:23:51,413-0500 DEBUG >> >> otopi.plugins.otopi.debug.debug_failure.debug_failure >> >> debug_failure._notification:100 tcp connections: >> >> >> >> >> >> >> > >> >> > The issue is that on github we already have >> >> > VERSION="1.0.10" >> >> > as we can see in >> >> > >> https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 >> >> > >> >> > And this has been bumped before the commit that now is reported as >> broken. >> >> > >> >> > CI instead is still building the package as 1.0.9 ignoring the >> commit that bumped the version. >> >> > Honestly I don't know how I can fix it if the version value is >> already the desired one in the source code. >> >> >> >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only >> >> >> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> >> Not even under "tested": >> >> >> https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> >> >> >> Simone, can you doublecheck that its artifacts have been built and >> >> have been accepted by the change queue? >> > >> > >> > It has been built here once as 1.0.10: >> > >> https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ >> > >> > then on the next commit, CI started building it again as 1.0.9 although >> in the source code we have 1.0.10 and so this issue. >> >> I don't understand the issue yet (that's not surprising as I do not >> know what is that "ghpush" job). Which CI job has built the wrong >> version? can you share its logs? who owns it? >> > > In the git log I see: > commit b5a6c1db135d81d75f3330160e7ef4a84c97fd60 (HEAD -> master, > upstream/master, origin/master, origin/HEAD, nolog) > Author: Simone Tiraboschi > Date: Tue Feb 5 10:56:58 2019 +0100 > > Avoid using no_log when we have to pass back values to otopi > > commit 96974fad1ee6aee33f8183e49240f8a2a7a617d4 > Author: Simone Tiraboschi > Date: Thu Jan 31 16:39:58 2019 +0100 > > use dynamic inclusion to avoid tag inheritance > > commit 4a9a23fb8e88acba5af4febed43d9e4b02e7a2c5 > Author: Simone Tiraboschi > Date: Thu Jan 31 15:15:04 2019 +0100 > > Force facts gathering on partial executions > > commit 7428b54a5ba8458379b1a27d116f9504bb830e69 > Author: Simone T
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg wrote: > On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi > wrote: > > > > > > > > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg wrote: > >> > >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi > wrote: > >> > > >> > > >> > > >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: > >> >> > >> >> Hi, > >> >> > >> >> Please note that ovirt-ansible-hosted-engine-setup has a versioning > problem with the package and is causing bootstrap to fail for upgrade suite > [1] > >> >> > >> >> This is effecting all projects, its been reported to the developers > and should be fixed as soon as possible. > >> >> > >> >> you can view CQ status here: > >> >> > https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ > >> >> > >> >> [1] http://pastebin.test.redhat.com/708086 > >> > >> It is unfair to refer to an internal pastebin here. It is also not > >> very sensible, as it is quite short. > >> > >> 2019-02-05 11:23:51,390-0500 ERROR > >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum > >> > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context > >> context._executeMethod:142 method exception > >> Traceback (most recent call last): > >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, > >> in _executeMethod > >> method['method']() > >> File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > >> line 248, in _packages > >> self.processTransaction() > >> File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > >> line 262, in processTransaction > >> if self._miniyum.buildTransaction(): > >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, > >> in buildTransaction > >> raise yum.Errors.YumBaseError(msg) > >> YumBaseError: > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context > >> context._executeMethod:151 Failed to execute stage 'Package > >> installation': > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,413-0500 DEBUG > >> otopi.plugins.otopi.debug.debug_failure.debug_failure > >> debug_failure._notification:100 tcp connections: > >> > >> >> > >> > > >> > The issue is that on github we already have > >> > VERSION="1.0.10" > >> > as we can see in > >> > > https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 > >> > > >> > And this has been bumped before the commit that now is reported as > broken. > >> > > >> > CI instead is still building the package as 1.0.9 ignoring the commit > that bumped the version. > >> > Honestly I don't know how I can fix it if the version value is > already the desired one in the source code. > >> > >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only > >> > https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm > >> Not even under "tested": > >> > https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm > >> > >> Simone, can you doublecheck that its artifacts have been built and > >> have been accepted by the change queue? > > > > > > It has been built here once as 1.0.10: > > > https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ > > > > then on the next commit, CI started building it again as 1.0.9 although > in the source code we have 1.0.10 and so this issue. > > I don't understand the issue yet (that's not surprising as I do not > know what is that "ghpush" job). Which CI job has built the wrong > version? can you share its logs? who owns it? > In the git log I see: commit b5a6c1db135d81d75f3330160e7ef4a84c97fd60 (HEAD -> master, upstream/master, origin/master, origin/HEAD, nolog) Author: Simone Tiraboschi Date: Tue Feb 5 10:56:58 2019 +0100 Avoid using no_log when we have to pass back values to otopi commit 96974fad1ee6aee33f8183e49240f8a2a7a617d4 Author: Simone Tiraboschi Date: Thu Jan 31 16:39:58 2019 +0100 use dynamic inclusion to avoid tag inheritance commit 4a9a23fb8e88acba5af4febed43d9e4b02e7a2c5 Author: Simone Tiraboschi Date: Thu Jan 31 15:15:04 2019 +0100 Force facts gathering on partial executions commit 7428b54a5ba8458379b1a27d116f9504bb830e69 Author: Simone Tiraboschi Date: Wed Jan 30 17:01:01 2019 +0100 Use static imports and tags Fixes https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/issues/20 Reuires https://github.com/oVirt/ovirt-ans
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, 6 Feb 2019 at 11:00, Dan Kenigsberg wrote: > On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi > wrote: > > > > > > > > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg wrote: > >> > >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi > wrote: > >> > > >> > > >> > > >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: > >> >> > >> >> Hi, > >> >> > >> >> Please note that ovirt-ansible-hosted-engine-setup has a versioning > problem with the package and is causing bootstrap to fail for upgrade suite > [1] > >> >> > >> >> This is effecting all projects, its been reported to the developers > and should be fixed as soon as possible. > >> >> > >> >> you can view CQ status here: > >> >> > https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ > >> >> > >> >> [1] http://pastebin.test.redhat.com/708086 > >> > >> It is unfair to refer to an internal pastebin here. It is also not > >> very sensible, as it is quite short. > >> > >> 2019-02-05 11:23:51,390-0500 ERROR > >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum > >> > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context > >> context._executeMethod:142 method exception > >> Traceback (most recent call last): > >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, > >> in _executeMethod > >> method['method']() > >> File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > >> line 248, in _packages > >> self.processTransaction() > >> File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > >> line 262, in processTransaction > >> if self._miniyum.buildTransaction(): > >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, > >> in buildTransaction > >> raise yum.Errors.YumBaseError(msg) > >> YumBaseError: > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context > >> context._executeMethod:151 Failed to execute stage 'Package > >> installation': > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > >> 2019-02-05 11:23:51,413-0500 DEBUG > >> otopi.plugins.otopi.debug.debug_failure.debug_failure > >> debug_failure._notification:100 tcp connections: > >> > >> >> > >> > > >> > The issue is that on github we already have > >> > VERSION="1.0.10" > >> > as we can see in > >> > > https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 > >> > > >> > And this has been bumped before the commit that now is reported as > broken. > >> > > >> > CI instead is still building the package as 1.0.9 ignoring the commit > that bumped the version. > >> > Honestly I don't know how I can fix it if the version value is > already the desired one in the source code. > >> > >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only > >> > https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm > >> Not even under "tested": > >> > https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm > >> > >> Simone, can you doublecheck that its artifacts have been built and > >> have been accepted by the change queue? > > > > > > It has been built here once as 1.0.10: > > > https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ > > > > then on the next commit, CI started building it again as 1.0.9 although > in the source code we have 1.0.10 and so this issue. > The next build of this job failed because of infra issue. Are you confusing pre-and post-merge builds? *ghpush job runs post merge on merged code *check-pr job runs on PRs change-queue only looks at builds generated by the ghpush job and unless someone intervened manually, the *ghpush job should always handle commits in merge order. > I don't understand the issue yet (that's not surprising as I do not > know what is that "ghpush" job). Which CI job has built the wrong > version? can you share its logs? who owns it? > > -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/RHWT64HONVMDHNUEDIKRDX2MMFNCOC7N/
[ovirt-devel] Re: Silent errors in storage code on Vdsm startup
Nir Soffer writes: > Even if you port entire vdsm to python 3, sanlock does not ship yet > python 3 bindings, so you cannot have any storage except local storage, > iso domain and export domain. I started working on porting sanlock Python bindings to Python 3 in order to be able to access storage. I have only my private dirty changes at the moment; if they prove to be working at least partially, I can make patches based on them and post them. > Can you check if https://gerrit.ovirt.org/c/97590/ fixes this issue? Yes, Vdsm starts with that patch and I can go on with my Python 3 work. Thank you for explanation and help! Milan ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IJJV6YCS5FREX5ZBMTGLHIVMPP74OM2M/
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi wrote: > > > > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg wrote: >> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi >> wrote: >> > >> > >> > >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: >> >> >> >> Hi, >> >> >> >> Please note that ovirt-ansible-hosted-engine-setup has a versioning >> >> problem with the package and is causing bootstrap to fail for upgrade >> >> suite [1] >> >> >> >> This is effecting all projects, its been reported to the developers and >> >> should be fixed as soon as possible. >> >> >> >> you can view CQ status here: >> >> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ >> >> >> >> [1] http://pastebin.test.redhat.com/708086 >> >> It is unfair to refer to an internal pastebin here. It is also not >> very sensible, as it is quite short. >> >> 2019-02-05 11:23:51,390-0500 ERROR >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context >> context._executeMethod:142 method exception >> Traceback (most recent call last): >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, >> in _executeMethod >> method['method']() >> File "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> line 248, in _packages >> self.processTransaction() >> File "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", >> line 262, in processTransaction >> if self._miniyum.buildTransaction(): >> File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, >> in buildTransaction >> raise yum.Errors.YumBaseError(msg) >> YumBaseError: >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context >> context._executeMethod:151 Failed to execute stage 'Package >> installation': >> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] >> 2019-02-05 11:23:51,413-0500 DEBUG >> otopi.plugins.otopi.debug.debug_failure.debug_failure >> debug_failure._notification:100 tcp connections: >> >> >> >> > >> > The issue is that on github we already have >> > VERSION="1.0.10" >> > as we can see in >> > https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 >> > >> > And this has been bumped before the commit that now is reported as broken. >> > >> > CI instead is still building the package as 1.0.9 ignoring the commit that >> > bumped the version. >> > Honestly I don't know how I can fix it if the version value is already the >> > desired one in the source code. >> >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only >> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> Not even under "tested": >> https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm >> >> Simone, can you doublecheck that its artifacts have been built and >> have been accepted by the change queue? > > > It has been built here once as 1.0.10: > https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ > > then on the next commit, CI started building it again as 1.0.9 although in > the source code we have 1.0.10 and so this issue. I don't understand the issue yet (that's not surprising as I do not know what is that "ghpush" job). Which CI job has built the wrong version? can you share its logs? who owns it? ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/ZG4Y3OSIFICMYRPMLPCCV6LXGDQFZF3B/
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg wrote: > On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi > wrote: > > > > > > > > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: > >> > >> Hi, > >> > >> Please note that ovirt-ansible-hosted-engine-setup has a versioning > problem with the package and is causing bootstrap to fail for upgrade suite > [1] > >> > >> This is effecting all projects, its been reported to the developers and > should be fixed as soon as possible. > >> > >> you can view CQ status here: > >> > https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ > >> > >> [1] http://pastebin.test.redhat.com/708086 > > It is unfair to refer to an internal pastebin here. It is also not > very sensible, as it is quite short. > > 2019-02-05 11:23:51,390-0500 ERROR > otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum > > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > 2019-02-05 11:23:51,390-0500 DEBUG otopi.context > context._executeMethod:142 method exception > Traceback (most recent call last): > File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, > in _executeMethod > method['method']() > File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > line 248, in _packages > self.processTransaction() > File > "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", > line 262, in processTransaction > if self._miniyum.buildTransaction(): > File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, > in buildTransaction > raise yum.Errors.YumBaseError(msg) > YumBaseError: > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > 2019-02-05 11:23:51,391-0500 ERROR otopi.context > context._executeMethod:151 Failed to execute stage 'Package > installation': > [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch > requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] > 2019-02-05 11:23:51,413-0500 DEBUG > otopi.plugins.otopi.debug.debug_failure.debug_failure > debug_failure._notification:100 tcp connections: > > >> > > > > The issue is that on github we already have > > VERSION="1.0.10" > > as we can see in > > > https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 > > > > And this has been bumped before the commit that now is reported as > broken. > > > > CI instead is still building the package as 1.0.9 ignoring the commit > that bumped the version. > > Honestly I don't know how I can fix it if the version value is already > the desired one in the source code. > > I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only > > https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm > Not even under "tested": > > https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm > > Simone, can you doublecheck that its artifacts have been built and > have been accepted by the change queue? > It has been built here once as 1.0.10: https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/ then on the next commit, CI started building it again as 1.0.9 although in the source code we have 1.0.10 and so this issue. ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FFS7BGNMZP7ZHMHLC3YEPHAROOFDJNNN/
[ovirt-devel] Re: imageio proxy and engine dev setup
On Tue, 5 Feb 2019 at 20:58, Nir Soffer wrote: > On Tue, Feb 5, 2019 at 6:46 PM Fedor Gavrilov wrote: > >> Right! >> >> Oh, it just occured to me that imageio prject is two parts and they >> expect me to be in proxy/ directory in the installation docs. >> There is indeed a make-install goal there :) >> >> Tried running it and it seems now setup script recognizes it now. >> > > Right, the instructions should be improved to show all the steps. > > This should work: > > git clone ... > cd ovirt-imageio > make > cd proxy > make install-dev ENGINE_PREFIX=/home/nsoffer/ovirt-engine > > /home/nsoffer/ovirt-engine/bin/engine-setup > (configure it...) > > There are 2 bugs here - 1. the engine will fail to talk with the proxy because the default proxy address is localhost:54323 which will fail ssl verification. This needs to be address in the engine setup plugin 2. The engine will not fail an attempt to upload when it can't actually communicate with the proxy. ImageTransfer needs validation there. To fix it you need to: $ENGINE_PREFIX/bin/engine-config -s ImageProxyAddress=OVIRT-ENGINE-FQDN:54323 export PYTHONPATH=/home/nsoffer/src/ovirt-imageio/common > ./ovirt-imageio-proxy > > Nir > > >> Thanks! >> Fedor Gavrilov >> >> - Исходное сообщение - >> От: "Fedor Gavrilov" >> Кому: "Nir Soffer" >> Копия: "devel" >> Отправленные: Вторник, 5 Февраль 2019 г 17:33:15 >> Тема: [ovirt-devel] Re: imageio proxy and engine dev setup >> >> Hi, >> >> I tried that already unfortunately. Executing make install-dev from >> imageio sources directory complains about no such target. >> Autocomplete for make suggests the following: >> >> [fgavrilo@localhost ovirt-imageio]$ make >> all check clean common daemon distproxy rpm srpm >> >> Wasn't successful with these targets either. >> >> Fedor Gavrilov >> >> - Исходное сообщение - >> От: "Nir Soffer" >> Кому: "Fedor Gavrilov" >> Копия: "devel" , "Daniel Erez" , "Roy >> Golan" >> Отправленные: Вторник, 5 Февраль 2019 г 17:18:42 >> Тема: Re: [ovirt-devel] imageio proxy and engine dev setup >> >> On Tue, Feb 5, 2019 at 5:05 PM Fedor Gavrilov >> wrote: >> >> > Hi, >> > >> > It seems to be rather difficult to have development setup for the engine >> > with imageio proxy. >> > engine-setup script never asks about it, running it again with >> > --reconfigure-optional-components changes nothing and answers file >> contains >> > no mention of imageio (thus, >> > https://bugzilla.redhat.com/show_bug.cgi?id=1446094 does not look to be >> > fixed for dev setups). There is no package to install separately either. >> > >> > Quite confused now. Do you happen to know what am I missing? >> > >> >> Installing with development engine (not installed with rpms) is documented >> here: >> >> >> >> http://ovirt.github.io/ovirt-imageio/installation.html#installation-with-ovirt-engine-developer-environment >> >> >> > >> > Fedor Gavrilov >> > ___ >> > Devel mailing list -- devel@ovirt.org >> > To unsubscribe send an email to devel-le...@ovirt.org >> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> > oVirt Code of Conduct: >> > https://www.ovirt.org/community/about/community-guidelines/ >> > List Archives: >> > >> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JTLEMRZMGMNNLKNCJ45L2VJO5EANY56W/ >> > >> ___ >> Devel mailing list -- devel@ovirt.org >> To unsubscribe send an email to devel-le...@ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/HVEXCKBLSRDRTSLHM2SYCHFQVVQQEBUF/ >> > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IPWTKN6Y2GGF3JBTZXH2RG75E2EDC4DX/
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi wrote: > > > > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: >> >> Hi, >> >> Please note that ovirt-ansible-hosted-engine-setup has a versioning problem >> with the package and is causing bootstrap to fail for upgrade suite [1] >> >> This is effecting all projects, its been reported to the developers and >> should be fixed as soon as possible. >> >> you can view CQ status here: >> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ >> >> [1] http://pastebin.test.redhat.com/708086 It is unfair to refer to an internal pastebin here. It is also not very sensible, as it is quite short. 2019-02-05 11:23:51,390-0500 ERROR otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] 2019-02-05 11:23:51,390-0500 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132, in _executeMethod method['method']() File "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", line 248, in _packages self.processTransaction() File "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py", line 262, in processTransaction if self._miniyum.buildTransaction(): File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920, in buildTransaction raise yum.Errors.YumBaseError(msg) YumBaseError: [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] 2019-02-05 11:23:51,391-0500 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Package installation': [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch requires ovirt-ansible-hosted-engine-setup >= 1.0.10'] 2019-02-05 11:23:51,413-0500 DEBUG otopi.plugins.otopi.debug.debug_failure.debug_failure debug_failure._notification:100 tcp connections: >> > > The issue is that on github we already have > VERSION="1.0.10" > as we can see in > https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 > > And this has been bumped before the commit that now is reported as broken. > > CI instead is still building the package as 1.0.9 ignoring the commit that > bumped the version. > Honestly I don't know how I can fix it if the version value is already the > desired one in the source code. I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm Not even under "tested": https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm Simone, can you doublecheck that its artifacts have been built and have been accepted by the change queue? ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/BTJGPSQLH6HJGTBNMOO32SE5RGVMTPW4/
[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects
On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron wrote: > Hi, > > Please note that ovirt-ansible-hosted-engine-setup has a versioning > problem with the package and is causing bootstrap to fail for upgrade suite > [1] > > This is effecting all projects, its been reported to the developers and > should be fixed as soon as possible. > > you can view CQ status here: > > https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/ > > [1] http://pastebin.test.redhat.com/708086 > > The issue is that on github we already have VERSION="1.0.10" as we can see in https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3 And this has been bumped before the commit that now is reported as broken. CI instead is still building the package as 1.0.9 ignoring the commit that bumped the version. Honestly I don't know how I can fix it if the version value is already the desired one in the source code. > Thanks, > Dafna > > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/BXN4QB54ONYPAA5FTGWWE7PRT5BPI7AF/
