Feed All Stories

Yesterday

Ralph Bean <rbean@redhat.com> committed rRSDB39f6bf46f441: A stomp messaging plugin. (authored by Ralph Bean <rbean@redhat.com>).
A stomp messaging plugin.
Fri, May 26, 7:33 PM
kparal moved T953: support wildcards in FMN filters from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Fri, May 26, 4:25 PM · Restricted Project, infrastructure
kparal added a project to T953: support wildcards in FMN filters: Restricted Project.

Pull request here: https://github.com/fedora-infra/fmn/pull/197

Fri, May 26, 4:24 PM · Restricted Project, infrastructure
tflink created T954: allow resultsdb directive to use the root 'task_output' dir as a log link.
Fri, May 26, 4:06 PM · libtaskotron
ralph closed D1191: A stomp messaging plugin..
Fri, May 26, 2:55 PM
tflink added a comment to T878: replace depcheck with rpmdeplint.
In T878#13760, @kparal wrote:

Here's a FMN pull request I intend to send:
https://github.com/kparal/fmn/compare/develop...kparal:rpmdeplint
Not only I renamed depcheck to rpmdeplint, but I also added abicheck as an important task to automatically notify people on failure. We don't get any false negatives reports, it's pretty important, and currently runs just on critical path packages. Abicheck authors have been asking for increased visibility for some time. Does it make sense, do you agree?

Fri, May 26, 2:25 PM · Restricted Project, new-check-ideas
kparal created T953: support wildcards in FMN filters.
Fri, May 26, 2:19 PM · Restricted Project, infrastructure
kparal added a comment to T878: replace depcheck with rpmdeplint.

Here's a FMN pull request I intend to send:
https://github.com/kparal/fmn/compare/develop...kparal:rpmdeplint
Not only I renamed depcheck to rpmdeplint, but I also added abicheck as an important task to automatically notify people on failure. We don't get any false negatives reports, it's pretty important, and currently runs just on critical path packages. Abicheck authors have been asking for increased visibility for some time. Does it make sense, do you agree?

Fri, May 26, 1:05 PM · Restricted Project, new-check-ideas
kparal added a comment to D1191: A stomp messaging plugin..

@tflink added you into taskotron group, please try again

Fri, May 26, 1:04 PM
ralph added a comment to D1191: A stomp messaging plugin..

Thanks! Although, since the move to pagure.io I don't think I have rights to land changes anymore:

Fri, May 26, 12:43 PM
jskladan accepted D1191: A stomp messaging plugin..

Who am I to say what works, and what does not :) I guess you tested it with your usecase, so feel free to merge!

Fri, May 26, 11:09 AM
kparal edited reviewers for D1191: A stomp messaging plugin., added: resultsdb; removed: kparal.
Fri, May 26, 10:47 AM

Thu, May 25

ralph added a comment to D1191: A stomp messaging plugin..

Ping. Any review feedback on this?

Thu, May 25, 3:50 PM

Wed, May 24

mkrizek added a comment to D1196: *WIP* More hacky support, but for containers.

Have you considered using ansible's docker module [1]? Seems like they have it all implemented.

Wed, May 24, 11:37 AM · libtaskotron
GitHub <noreply@github.com> committed rTCLOUD53a994ff1c55: Merge 56076055131d07b8e572ed06a100e2cfe9bdee76 into… (authored by Sumantro Mukherjee <saggy.zone@gmail.com>).
Merge 56076055131d07b8e572ed06a100e2cfe9bdee76 into…
Wed, May 24, 12:30 AM

Tue, May 23

kparal added a comment to T878: replace depcheck with rpmdeplint.

OK. I also removed type=bodhi_update reporting, because we want to get rid of it, and this change is the best chance to push it forward (in the worst case, I'll also prepare a bodhi patch). Now we're waiting for beta freeze to be lifted so that we can push this to production. Also, I'll look at necessary FMN changes and bodhi changes.

Tue, May 23, 12:01 PM · Restricted Project, new-check-ideas
Kamil Páral <kparal@redhat.com> committed rDEPLINTdabe6beb23c8: fix tests (authored by Kamil Páral <kparal@redhat.com>).
fix tests
Tue, May 23, 11:56 AM
kparal claimed T878: replace depcheck with rpmdeplint.
Tue, May 23, 11:47 AM · Restricted Project, new-check-ideas
Kamil Páral <kparal@redhat.com> committed rDEPLINT52d328ff9306: don't squash build results to update results (authored by Kamil Páral <kparal@redhat.com>).
don't squash build results to update results
Tue, May 23, 10:37 AM
jskladan requested changes to D1196: *WIP* More hacky support, but for containers.

Well, I'm not a huge fan of this - since not all the commands support the --format flag. This will most definitely have the same issues as testcloud does, but if the goal is to really have it now...

Tue, May 23, 10:10 AM · libtaskotron
Kamil Páral <kparal@redhat.com> committed rDEPLINTfbcf2aee6aeb: README: --arch is mandatory now (authored by Kamil Páral <kparal@redhat.com>).
README: --arch is mandatory now
Tue, May 23, 10:04 AM
Kamil Páral <kparal@redhat.com> committed rLTRN55d79d57b1ee: yumrepoinfo_directive: fix grammar error (authored by Kamil Páral <kparal@redhat.com>).
yumrepoinfo_directive: fix grammar error
Tue, May 23, 10:01 AM
kparal reopened T835: fedora-phabricator repo is not available for Fedora 25 as "Open".

Our documentation links to https://repos.fedorapeople.org/repos/tflink/phabricator/ . I can change that, but kanarip's packages don't work with our Phab instance:

$ arc list
Exception
[cURL/77] (https://phab.qa.fedoraproject.org/api/user.whoami) <CURLE_SSL_CACERT_BADFILE> The SSL CA Bundles that we tried to use could not be read or are not formatted correctly.
(Run with `--trace` for a full exception trace.)
$ arc list --trace
 ARGV  '/usr/share/arcanist/bin/../scripts/arcanist.php' 'list' '--trace'
 LOAD  Loaded "phutil" from "/usr/share/libphutil/src".
 LOAD  Loaded "arcanist" from "/usr/share/arcanist/src".
Config: Reading user configuration file "/home/kparal/.arcrc"...
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: Reading .arcconfig from "/home/kparal/devel/taskotron/libtaskotron/.arcconfig".
Working Copy: Path "/home/kparal/devel/taskotron/libtaskotron" is part of `git` working copy "/home/kparal/devel/taskotron/libtaskotron".
Working Copy: Project root is at "/home/kparal/devel/taskotron/libtaskotron".
Config: Did not find local configuration at "/home/kparal/devel/taskotron/libtaskotron/.git/arc/config".
>>> [0] <conduit> user.whoami() <bytes = 117>
>>> [1] <http> https://phab.qa.fedoraproject.org/api/user.whoami
<<< [1] <http> 297,727 us
<<< [0] <conduit> 297,936 us
Tue, May 23, 9:40 AM · Restricted Project, infrastructure
mkrizek added a comment to T878: replace depcheck with rpmdeplint.

wfm

Tue, May 23, 9:19 AM · Restricted Project, new-check-ideas
jskladan added a comment to T878: replace depcheck with rpmdeplint.

me likes!

Tue, May 23, 9:10 AM · Restricted Project, new-check-ideas
jskladan accepted D1195: Support for Ansible Tasks.
  • inner runner :(
Tue, May 23, 8:56 AM
kparal added inline comments to D1196: *WIP* More hacky support, but for containers.
Tue, May 23, 8:51 AM · libtaskotron
tflink accepted D1195: Support for Ansible Tasks.

I'm not a huge fan of keeping a playbook in the root of the repo like that but I'm not coming up with any brilliant alternatives at the moment.

Tue, May 23, 4:44 AM

Mon, May 22

tflink closed T796: arcanist does not require php correctly as "Resolved".

This is not valid anymore with either kararip's COPR or the packages up for review.

Mon, May 22, 7:19 PM · Restricted Project, infrastructure
tflink closed T835: fedora-phabricator repo is not available for Fedora 25 as "Resolved".

Until the package reviews go through, use kararip's copr. https://copr.fedorainfracloud.org/coprs/kanarip/phabricator/

Mon, May 22, 7:18 PM · Restricted Project, infrastructure
roshi added inline comments to D1196: *WIP* More hacky support, but for containers.
Mon, May 22, 7:16 PM · libtaskotron
kparal added a comment to T878: replace depcheck with rpmdeplint.

So, here's my most awesome proposal - let's use this for now:

dist.rpmdeplint

Once we also start checking repoclosure with it, we can extend it to

dist.rpmdeplint
dist.rpmdeplint.sat
dist.rpmdeplint.repoclosure

Which means dist.rpmdeplint would be the overall outcome of .sat and .repoclosure.

Mon, May 22, 6:06 PM · Restricted Project, new-check-ideas
merlinm added a comment to T939: Support New Test Invocation Standard.

As an ansible n00b, I'm also trying to work my way through the confusion of how this is going to work, too. I'd be interested in seeing some examples on how to things should be set up in dist-git to have Taskotron automatically kick off the examples described in the ansible-based proposal referenced in the description. I'm sure that will help flesh out a lot of additional questions and details.

Mon, May 22, 3:37 PM · libtaskotron
kparal closed T894: a race condition between downloading i386 and x86_64 packages as "Resolved".

D1178 has been pushed and seems to be working well. This problem has been therefore solved for #task-rpmdeplint. Closing the ticket. The problem is still valid for task-depcheck, now we just need to finish T878 and get rid of depcheck.

Mon, May 22, 2:47 PM · Restricted Project, task-depcheck, Restricted Project
Kamil Páral <kparal@redhat.com> committed rDEPLINT83bd6af25f93: run per-arch (authored by Kamil Páral <kparal@redhat.com>).
run per-arch
Mon, May 22, 2:43 PM
Diffusion closed D1178: run per-arch by committing rDEPLINT83bd6af25f93: run per-arch.
Mon, May 22, 2:43 PM
kparal added a comment to D1178: run per-arch.

This is working well in develop, pushing to master as well.

Mon, May 22, 2:42 PM
kparal added inline comments to D1196: *WIP* More hacky support, but for containers.
Mon, May 22, 2:21 PM · libtaskotron
kparal added a comment to T939: Support New Test Invocation Standard.

I understand the motivation - being able to transfer the task between different test systems without any changes. What I don't understand is how localhost-only ansible execution is related here. When I execute a task through ansible locally, and when I execute it remotely from a different machine, doesn't it look the same to the task itself? Is there a different environment or some behavioral changes that the task needs to adapt to? If the execution looks the same to the task regardless of ansible mode, the end goal is achieved (the task doesn't need to be adjusted when moving between test systems), and the particular ansible execution mode then can be left to the test system to implement as it fits best for it.

Mon, May 22, 1:49 PM · libtaskotron
Kamil Páral <kparal@redhat.com> committed rLTRN20940651b087: README: add libvirt-python dependency (authored by Kamil Páral <kparal@redhat.com>).
README: add libvirt-python dependency
Mon, May 22, 10:59 AM
Diffusion closed D1199: README: add testcloud dependency by committing rLTRN20940651b087: README: add libvirt-python dependency.
Mon, May 22, 10:59 AM
mkrizek updated the diff for D1195: Support for Ansible Tasks.
  • inner runner :(
Mon, May 22, 10:58 AM
kparal edited the content of 20170522-fedoraqadevel.
Mon, May 22, 10:45 AM
mkrizek accepted D1178: run per-arch.
Mon, May 22, 8:25 AM
mkrizek accepted D1199: README: add testcloud dependency.
Mon, May 22, 8:15 AM
jsedlak committed rOPENQATESTS41144066683b: add UEFI for blivet tests (authored by jsedlak).
add UEFI for blivet tests
Mon, May 22, 7:33 AM
jsedlak closed D1201: add UEFI for blivet tests by committing rOPENQATESTS41144066683b: add UEFI for blivet tests.
Mon, May 22, 7:32 AM
jsedlak added a comment to D1201: add UEFI for blivet tests.

Looks fine. Out of interest - do you get a useful warning / error if you try to do an install *without* an ESP? If not, might be worth a bug report...

Mon, May 22, 7:24 AM
tflink created 20170522-fedoraqadevel.
Mon, May 22, 7:11 AM

Fri, May 19

roshi added inline comments to D1196: *WIP* More hacky support, but for containers.
Fri, May 19, 7:15 PM · libtaskotron
adamwill accepted D1201: add UEFI for blivet tests.

Looks fine. Out of interest - do you get a useful warning / error if you try to do an install *without* an ESP? If not, might be worth a bug report...

Fri, May 19, 6:35 PM
kparal added a comment to D1178: run per-arch.

@jskladan @mkrizek: I'd like to push this into develop branch soon, so that I can test how well it works in taskotron-dev. Please review, otherwise I'll do the push early next week. Thanks.

Fri, May 19, 2:17 PM
kparal added inline comments to D1196: *WIP* More hacky support, but for containers.
Fri, May 19, 2:03 PM · libtaskotron
kparal updated the diff for D1199: README: add testcloud dependency.
  • add libvirt-python to readme instead, require fixed testcloud from pypi
Fri, May 19, 1:36 PM
kparal added a comment to D1199: README: add testcloud dependency.

OK, so, testcloud deps were fixed in D1200 and pushed to pypi.

Fri, May 19, 1:34 PM
Kamil Páral <kparal@redhat.com> committed rTCLOUD91a38b00c4c5: Merge branch 'dev' (authored by Kamil Páral <kparal@redhat.com>).
Merge branch 'dev'
Fri, May 19, 1:30 PM
Kamil Páral <kparal@redhat.com> committed rTCLOUDc4d84f620c74: bump version to 0.1.12 (authored by Kamil Páral <kparal@redhat.com>).
bump version to 0.1.12
Fri, May 19, 1:30 PM
Kamil Páral <kparal@redhat.com> committed rTCLOUD86a03fbdcece: setup: specify package deps (authored by Kamil Páral <kparal@redhat.com>).
setup: specify package deps
Fri, May 19, 1:30 PM
Diffusion closed D1200: setup: specify package deps by committing rTCLOUD86a03fbdcece: setup: specify package deps.
Fri, May 19, 1:29 PM
roshi accepted D1200: setup: specify package deps.

Looks good to me.

Fri, May 19, 1:06 PM
jsedlak created D1201: add UEFI for blivet tests.
Fri, May 19, 12:08 PM
jsedlak committed rOPENQATESTS0b5f865c8f0b: add custom btrfs partitioning test for blivet-gui (authored by jsedlak).
add custom btrfs partitioning test for blivet-gui
Fri, May 19, 11:59 AM
jsedlak closed D1194: add custom btrfs partitioning test for blivet-gui by committing rOPENQATESTS0b5f865c8f0b: add custom btrfs partitioning test for blivet-gui.
Fri, May 19, 11:59 AM
kparal created D1200: setup: specify package deps.
Fri, May 19, 11:31 AM
Kamil Páral <kparal@redhat.com> committed rLTRN558968f70c5c: change documentation theme (authored by Kamil Páral <kparal@redhat.com>).
change documentation theme
Fri, May 19, 10:40 AM
Diffusion closed D1198: change documentation theme by committing rLTRN558968f70c5c: change documentation theme.
Fri, May 19, 10:40 AM

Thu, May 18

adamwill accepted D1194: add custom btrfs partitioning test for blivet-gui.

Looks fine, assuming it really does create a btrfs volume with a / subvolume.

Thu, May 18, 7:03 PM
roshi added a comment to D1196: *WIP* More hacky support, but for containers.

Sorry for the spam. Last arc diff went against master I think, since I forgot to base it off the right commit - so it was showing a ton of stuff not included in this review.

Thu, May 18, 2:29 PM · libtaskotron
roshi updated the diff for D1196: *WIP* More hacky support, but for containers.

Updated diff to reflect comments in review.

Thu, May 18, 2:27 PM · libtaskotron
tflink accepted D1198: change documentation theme.

It looks like every other set of docs out there right now but maybe that's not a bad thing.

Thu, May 18, 2:19 PM
roshi updated the diff for D1196: *WIP* More hacky support, but for containers.
  • Updated to reflect review comments.
Thu, May 18, 2:12 PM · libtaskotron
kparal planned changes to D1199: README: add testcloud dependency.

Ah, good catch. The actual problem was with missing libvirt-python. That's a dependency of testcloud, but it clearly doesn't state it on the pypi package. So, we should add the dep to the testcloud package (I'll create a patch). The drawback is that libvirt-python is a bit problematic to install from pypi, it requires to compile some libvirt modules, so it might be actually easier to install it as an rpm anyway. Will look into it.

Thu, May 18, 2:08 PM
mkrizek accepted D1198: change documentation theme.
Thu, May 18, 1:41 PM
mkrizek added a comment to D1199: README: add testcloud dependency.

testcloud is in PyPI, it should be installed through requirements.txt, no?

Thu, May 18, 1:40 PM
kparal created D1199: README: add testcloud dependency.
Thu, May 18, 1:36 PM
lbrabec accepted D1198: change documentation theme.
Thu, May 18, 1:24 PM
jskladan accepted D1198: change documentation theme.

LG™

Thu, May 18, 1:21 PM
kparal updated the diff for D1198: change documentation theme.
  • fix running sphinx-build from virtualenv and use better approach to add stylesheet (the old one fails with newer sphinx)
Thu, May 18, 12:59 PM
kparal updated the test plan for D1198: change documentation theme.
Thu, May 18, 11:28 AM
kparal created D1198: change documentation theme.
Thu, May 18, 10:59 AM

Wed, May 17

roshi added inline comments to D1196: *WIP* More hacky support, but for containers.
Wed, May 17, 2:32 PM · libtaskotron
tflink updated subscribers of T939: Support New Test Invocation Standard.

As alluded to in D1195, there has been a bit of confusion around how all this is going to work. After re-reading the wiki pages and talking with @merlinm a bit, my understanding is:

Wed, May 17, 1:52 PM · libtaskotron
tflink added a task to D1195: Support for Ansible Tasks: T939: Support New Test Invocation Standard.
Wed, May 17, 1:27 PM
tflink added a revision to T939: Support New Test Invocation Standard: D1195: Support for Ansible Tasks.
Wed, May 17, 1:27 PM · libtaskotron
tflink added a comment to D1195: Support for Ansible Tasks.
In D1195#22202, @kparal wrote:
In D1195#22199, @tflink wrote:

I don't think it's worth the effort to keep both formats supported. The remote related code needs to die in a fire. There really are not that many tasks using the current formula that we don't maintain. Let's not keep the code more complex than it has to be. Also, the remote related code needs to die in a fire. My idea was, that until we port the tasks to the new format, we keep running the current production and have the new runner in dev.

I'm of the same mind - we don't have that many tasks using the "old" formulas in the wild that we don't already maintain. I think it'll be far less effort to just do the porting work that it'd be to support both ansible and formulas at the same time.

So, we'll aim for deploying taskotron-ansible onto dev server and also push all tasks converted to ansible format to dev branch, at the exactly same time, correct? If so, how long do we suppose to be in this state, until we update production? Because if we suppose a week or two, that's probably fine. It if should be a month, or two, or three, it's going to be a problem for task developers who use dev branch to test new code (as they rightly should) before pushing to master. (Well, I know of one such person active at the moment, python-versions' maintainer). Of course we can tell them that they need to push directly to production during this phase.

Wed, May 17, 1:26 PM
Kamil Páral <kparal@redhat.com> committed rLTRNff5f27e7c061: check: remove DNF_REPO item type (authored by Kamil Páral <kparal@redhat.com>).
check: remove DNF_REPO item type
Wed, May 17, 12:03 PM
Diffusion closed D1197: check: remove DNF_REPO item type by committing rLTRNff5f27e7c061: check: remove DNF_REPO item type.
Wed, May 17, 12:03 PM
Kamil Páral <kparal@redhat.com> committed rLTRNec8ced66409b: improve documentation (authored by Kamil Páral <kparal@redhat.com>).
improve documentation
Wed, May 17, 12:03 PM
jsedlak updated the diff for D1194: add custom btrfs partitioning test for blivet-gui.
  • correct comment about number of disks in custom btrfs
Wed, May 17, 12:00 PM
mkrizek accepted D1197: check: remove DNF_REPO item type.
Wed, May 17, 11:53 AM
kparal created D1197: check: remove DNF_REPO item type.
Wed, May 17, 11:51 AM
kparal added inline comments to D1195: Support for Ansible Tasks.
Wed, May 17, 11:06 AM
kparal added a comment to D1195: Support for Ansible Tasks.
In D1195#22199, @tflink wrote:

I don't think it's worth the effort to keep both formats supported. The remote related code needs to die in a fire. There really are not that many tasks using the current formula that we don't maintain. Let's not keep the code more complex than it has to be. Also, the remote related code needs to die in a fire. My idea was, that until we port the tasks to the new format, we keep running the current production and have the new runner in dev.

I'm of the same mind - we don't have that many tasks using the "old" formulas in the wild that we don't already maintain. I think it'll be far less effort to just do the porting work that it'd be to support both ansible and formulas at the same time.

Wed, May 17, 10:41 AM
tflink updated subscribers of D1195: Support for Ansible Tasks.
In D1195#22176, @kparal wrote:

Regarding ansible workflow - I'm a bit confused, so please bear with me :-)

Wed, May 17, 5:07 AM
tflink added a comment to D1195: Support for Ansible Tasks.
In D1195#22176, @kparal wrote:

So, first things first - I think there should be almost no deletions in this code. Our old system (formula and minion-based) will have to co-exist with the new system (ansible based) for some time, until we convert all our existing tasks to the new one, and iron out all issues. We need to keep compatibility for some time, this is probably a too big jump to switch everything over at the same time. I'd say keep all the existing code in place, just add new code to make ansible-based workflow work. Once both systems are deployed and working and once we covert all tasks to the new system, then we can drop the old code and refactor all the modules. This approach will also help in having the ansible feature branch much simpler, easier to compare and easier to rebase against develop.

I don't think it's worth the effort to keep both formats supported. The remote related code needs to die in a fire. There really are not that many tasks using the current formula that we don't maintain. Let's not keep the code more complex than it has to be. Also, the remote related code needs to die in a fire. My idea was, that until we port the tasks to the new format, we keep running the current production and have the new runner in dev.

Wed, May 17, 4:59 AM

Tue, May 16

mkrizek updated the diff for D1195: Support for Ansible Tasks.

Address issues in the review. Fix tests and lint errors.

Tue, May 16, 4:00 PM
mkrizek added a comment to D1195: Support for Ansible Tasks.
In D1195#22176, @kparal wrote:

So, first things first - I think there should be almost no deletions in this code. Our old system (formula and minion-based) will have to co-exist with the new system (ansible based) for some time, until we convert all our existing tasks to the new one, and iron out all issues. We need to keep compatibility for some time, this is probably a too big jump to switch everything over at the same time. I'd say keep all the existing code in place, just add new code to make ansible-based workflow work. Once both systems are deployed and working and once we covert all tasks to the new system, then we can drop the old code and refactor all the modules. This approach will also help in having the ansible feature branch much simpler, easier to compare and easier to rebase against develop.

Tue, May 16, 3:58 PM
kparal added inline comments to D1196: *WIP* More hacky support, but for containers.
Tue, May 16, 2:14 PM · libtaskotron
kparal added inline comments to D1195: Support for Ansible Tasks.
Tue, May 16, 1:26 PM
roshi added a comment to D1196: *WIP* More hacky support, but for containers.

We can probably add some logic to manipulate the version of Fedora that goes into the container we run. I'll look into it.

Tue, May 16, 1:02 PM · libtaskotron