Hi all, I noticed that Fedocal was on the upcoming orphaned packages
list on a recent email to the devel-announce mailing list. I was curious
if this would have an impact on Fedocal in Fedora Infra currently since
I hadn't heard anything about it prior.
I wasn't sure what this meant for Fedocal, so I was hoping to get some
clarification if it's relevant for end-users or not.
-------- Forwarded Message --------
Subject: Orphaned packages need you
Date: Mon, 24 Jun 2019 18:57:23 +0200
From: Miro Hrončok <mhroncok(a)redhat.com>
Reply-To: Development discussions related to Fedora
Organization: Red Hat
To: Development discussions related to Fedora
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
Note: If you received this mail directly you (co)maintain one of the
packages or a package that depends on one. Please adopt the affected
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.
This e-mail was shortened, see the full report at:
Packages retired today:
clpbar compat-openssl10-pkcs11-helper rubygem-commander rubygem-paranoia
Request package ownership via: https://pagure.io/releng/issues
fedocal infra-sig, orphan 3
The following packages require above mentioned packages:
Too longs, see https://churchyard.fedorapeople.org/orphans-2019-06-24.txt
Grep the content for your username and follow the dependencies.
infra-sig: fedocal, python-fmn-lib
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
The sources of this script can be found at:
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
An item that came out of our meetings last week was to try and
standardize style and checks on our ansible repo. This has a number of
goals, including making things more readable for newcomers as well as
reducing the number of errors we commit and have to correct.
Toward that end, we decided to start using 'ansible-review' on our
playbooks/roles/commits. ansible-review is packaged in fedora and comes
with a set of default rules which is easy to expand or reduce. We
decided to start with the standard rules and asjudt from there.
I setup: https://pagure.io/cpe/ansible-review-templates
(which currently doesn't have anything in it) as a central place to hold
any rules when/if we change from the default.
We don't yet have ansible-review as a hook, but we hope to add it soon.
It would only reject on errors, not warnings (of which we have a lot).
Once we get ansible setup to handle PR's we can add it in there as a CI
step. In the mean time you can run it over any changes you are about to
make easily enough (just cat whatever things into 'ansible-review').
Additionally, we came up with a few other items:
* Use 'yml' instead of 'yaml'
* do add '.j2' to the end of templates
* in general let readablity trump grepability, ie:
- name: This is some play
module: name=thing arg=thing2 anotherlongerarg=thing arg4=anodheranth
- name: This is some play
- name: thing
- arg: thing2
I have added a "STYLEGUIDE" text file to the root on the ansible repo
with this infrmation also.
If you can think of other things we should standardize on, please do
follow up on this thread or file a ticket and we can discuss.
On Mon, 2019-06-10 at 09:24 +0900, Tristan Cacqueray wrote:
> On Mon, Jun 10, 2019 at 01:24 Igor Gnatenko wrote:
> > Hello,
> > I have been trying to write some script which would listen on
> > generation of new repository / successful build is tagged in Koji and
> > do some actions locally. Or basically whenever someone pushes commits,
> > I want to fetch repo locally.
> > I was reading https://fedora-messaging.readthedocs.io/en/latest/consuming.html,
> > but it is not very clear to me where I can find list of topics and
> > what data messages will contain...
As well as the doc, there is a sample consumer:
and a couple of sample config files:
that you will probably find useful.
> Hi Igor,
> you can find the list of topics and their associated schema here:
Treat this with caution, because it is...sometimes a lie. It is in fact
auto-generated from the test cases for the
which is where the metadata providers that produce things like the
human-readable summaries you get from FMN live.
If you maintain a thing that publishes fedmsgs, you are *supposed to*
also maintain a provider in fedmsg_meta that can interpret all the
fedmsgs your thing publishes, and a test suite for that provider which
includes tests for every topic your provider publishes on and useful
docstrings for each test. That doc page is then actually built more or
less just by gluing all the test docstrings together.
However, there is no enforcement of any of this. Which means that it
quite often isn't really all in sync. I think there may still be some
fedmsg publishers which don't have a metadata provider or tests at all.
There are definitely some where a provider and tests exist, but the
fedmsg publisher's behaviour has changed a lot since they were written
and no-one has updated the provider or the tests, so the doc no longer
actually lists the topics on which messages are now being published.
I don't really use this list any more because of issues like that...
> And you can also find samples on this website:
...this is much more useful, because it is just a log of all the
*actual* fedmsgs that have ever been published. It can be a bit
unwieldy to work with, but it's not too bad. You can see all Koji
messages from the last two days here:
You can tweak the 'delta' arg (given in seconds), or use 'start' and
'end' (given as Unix timestamps) instead, to get messages from
Note, datagrepper consumes and publishes *fedmsgs*, not fedora-
messaging messages (at least at present). We are currently in the
middle of trying to move things over from fedmsg (the old 0MQ-based
system) to fedora-messaging (the new AMQP-based system). To aid this,
there are bridges in place in both directions: messages published to
fedora-mesaging are re-published as fedmsgs, and messages published as
fedmsgs are re-published to fedora-messaging. Even for messages that
are actually natively published to fedora-messaging, what you see on
datagrepper is the result of the AMQP->0MQ bridge: it's not the actual
original message, but the re-published fedmsg. AFAIK there is no
publicly available 'datagrepper-for-fedora-messaging' ATM, though, so
you can't really look at an archive of the actual messages as they're
seen on the new system.
There is one very important wrinkle you should bear in mind thanks to
this: the message format.
If you're writing an AMQP consumer in Python, what you'll ultimately
get for your consumer to process is a `message` object which is an
instance of a fedora_messaging.api.Message() (or a subclass of it - a
message schema class). This will have a `body` attribute which should
be a dict of the message 'body' - the main meat of the message. If the
message was natively published as a fedora-messaging AMQP message, that
is indeed what it will be. However, if it was published as a fedmsg,
what you get as `message.body` is actually the *entire* fedmsg dict -
the whole dict as you see it when you view a message on datagrepper,
with a bunch of headers and a 'msg' dict with the real body in it, e.g.
To get to what is effectively the 'body' of a fedmsg, you need to take
message.body['msg']. This wrinkle is currently under discussion at
I came across this while converting fedmsg consumers to fedora-
messaging, and I wrote a little helper to deal with it:
Whenever you want the body of a message you just run it through that
and it should give you the 'true' body. That also means you won't have
to worry if the bridge gets changed to fix the bug, that function will
still give the correct result.
If you want to look at some real-world fedora-messaging consumers, that
file contains three consumers for scheduling openQA jobs and reporting
their results. Also see the reference config files (the '.toml' files)
and the README, at top level of the fedora-messaging branch:
You can also look at Bodhi, which has also been converted to fedora-
the config file for Bodhi is in infra ansible:
Oh, one more wrinkle I had fun with: if you want to use the 'public'
credentials for the brokers, be aware that the amqp_url setting and
[tls] block settings in the sample config files are correct, but the
necessary certificate and key files for the staging broker are not
included in the `fedora-messaging` package at present. If you look in
/etc/fedora-messaging after installing it you'll see only the files for
the production broker are there. If you want to listen to the staging
broker, you have to grab the files from a git checkout (they're in the
'configs' dir) and copy them to /etc/fedora-messaging .
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
Over the last couple days I've been sorta-kinda helping Adam move OpenQA
to AMQP and he has, through no fault of his own, had a rough time of it.
The problems boil down to permissions issues and a lack of visibility
into the broker. I'd like to propose two changes so that folks can help
themselves rather than blindly guessing and hoping I am around (there is
a bus around every corner and lottery tickets in every shop).
Firstly, I propose we allow authenticated users to create objects in the
/pubsub (private) vhost using the AMQP client. These users already can
create objects, but they have to do it through Ansible roles rather than
through the AMQP object. Since the AMQP client configuration is checked
into Ansible, though, it's rather redundant to make them declare the
queue separately. When they don't declare it properly, they can't tell
and so it's actually quite a pain point. This is an easy change, we just
change all the accounts to have configure permissions
Secondly, I propose we offer a read-only monitoring account to the web
interface RabbitMQ provides. One great thing about switching from ZeroMQ
to AMQP is that the broker gives us tons of tools to make monitoring and
debugging easier. Allowing users to easily see the objects in the broker
(queues, bindings, exchanges, connections) means they can solve their
own deployment problems rather than pinging me.
I think if we make an account with no AMQP permissions and the
"monitoring" permission, folks should be able to see everything and
not be able to do anything destructive. Then it's just a question of how
to share the credentials (or just make the account name guest with the
username guest?) and how to expose the management UI port (just require
people to sshuttle?).