This patch (available in email attachment) is to create new ostree
commit when there is no content changes since last commit during
updates compose run. By passing force_new_commit as True, pungi
runs rpm-ostree command with option --force-nocache .
More details are in releng ticket - https://pagure.io/releng/issue/7585
Good Morning Everyone,
So yesterday we held a meeting on #fedora-apps about the future of PDC in Fedora.
We kept notes in etherpad at: http://etherpad.osuosl.org/pdc_fedora
Here is the gist of it:
What do we currently store in PDC:
* modules data - the list of what modules have been built, what rpms are in them,
and which ones are active or not.
* Stream branches, branch ownership, retirement dates (EOL/SLE)
* release/life-circle tracking
* product and product versions (fedpkg gets active Fedora and EPEL releases
from product versions endpont)
* critpath boolean on packages (bodhi uses this)
* metadata from composes (RPMS/images)
* "dependency" data about which rpms depend on which other rpms and which
containers include other rpms. This is not used by anything and can be
de-prioritized, dropped. (It was originally going to be used in Freshmaker.)
* List of all packages: fedora-packages uses this list to know what to index.
It sets up the "for loop" from which fedora-packages pulls data from all our
After some discussion the decision we reached was:
* The "dependency" data in its current form can be dropped. It's something we'll
need in the future but the data structure will most likely need to be
adjusted so let's just drop the existing data and worry about this later.
* The critpath boolean can just be imported into bodhi itself, especially
considering that bodhi is the only tool using this flag.
* The modules data is entirely going to move into MBS
Everything else (ie: composes metadata, release/life-circle tracking,
package/branches information) will need to find a new home.
This new home will be a new django app using the Django Rest Framework (DRF) in
which we will import the PDC apps as needed (potentially adjusting them where
- kellin has agreed to be the project leader for this work but needs a team to
do the actual work.
- pingou has agreed to look for said team
If you have any worries, questions or suggestions or if you want to join the
effort, please let us know :)
Finally some links:
Minutes (text): https://meetbot.fedoraproject.org/fedora-apps/2018-06-11/pdc_and_fedora.2...
Have a nice day,
Sorry it took so long to write this up and send it out, but here's our
proposed plan for authentication moving forward.
Please do feel free to comment or suggest changes/improvements here. Any
mistakes are mine alone. :)
Fedora Project Auth roadmap
The Fedora project created its own authentication/user/group
management system at nearly the beginning of its existance. FAS (Fedora
Account System) (version 1) and then a rewrite (FAS2). At each of these
points other solutions were investigated and found unacceptable for
various reasons. Over the last few years, several additional
applications have been added next to FAS2 to provide additional
functionality: ipisilon has been added as a identity provider, and
FreeIPA has been added for kerberos authentication. FAS2 is still the
authoritative source of authentication data. FAS2 is currently deployed
on RHEL6 servers and won't run on RHEL7.
Also during the last few years, a new FAS re-write has been slowly in
the works. FAS3 is written in a modern framework and has a number of
functionality and interface improvements over FAS2. Additionally it can
run on RHEL7.
Goals and Critera
Maintaining authentication applications is difficult and time
consuming work, and it has always been a goal to try and move to more
industry standard applications as much as possible given our goals and
critera. The last time we looked, Some of those goals/critera include:
* User self service registration
* User self service password reset
* FPCA acceptance requirement
* Basset integration (may not be needed anymore)
* Allow Self Service groups with their own sponsors/admins
* Allow group requirements (other group first, etc)
On discussion with FreeIPA developers and looking at how things are
setup now, we came up with a plan to get what we need, but reduce the
footprint and maintance we need to do. Many of the features we were
hoping to use in FAS3 have now been implemented upstream in
FreeIPA (2fa, fasClient syncing better, etc).
Basically we will:
* A new small wrapper type project is written (Community Account
Information API) or CAIAPI.
This small app provides the Critera listed above, talking at first to
FAS2 on the backend then, later switching to talking to FreeIPA on the
backend and providing a json API to consumers.
* Switch anything we have using the direct FAS api to use CAIAPI instead.
* Move to FreeIPA being the canonical source for authentication data.
This should just be a switch to CAIAPI, and no consumers should even
* FreeIPA still provides kerberos auth.
Note that kerberos will remain limited to use at ipsilon and koji.
* Ipsilon provides identity auth for applications, preferably with OIDC
(still provides others)
* A new small website that uses the CAIAPI json to provide end user
access / management. This thing would be in flask and needs a name still.
Since https://fedoraproject.org/wiki/Infrastructure/fas_freeipa FreeIPA
has matured and our understanding of the work required to make CAIAPI
and a small web consumer has clarified.
* IPA handles all the storing of credentials, replication and such and
we just use it.
* Our maint goes from needing to maintain FAS2 or FAS3 to just CAIAPI
(a much smaller api) and a
very small web application.
* Easier to audit 2 small apps.
* We can try and share the CAIAPI with other open source communities
(Gnome? CentOS? others?)
Open Source Communities already using FreeIPA would be easy to add
* We can stop using fasClient in favor of ipa-client setup (no more
* The heavy security aspects will be handled by upstreams we don't
need to fully maintain
(FreeIPA, sssd, ipsilon, etc).
* We still need to write the CAIAPI/webapp, although Patrick may have
CAIAPI already somewhat implemented.
* It feels very sad to have spent so long on FAS3 and never deploy it,
thats just the way things go. ;(
There will be an outage starting at 2018-07-03 21:00UTC, which will
last approximately 6 hours.
To convert UTC to your local time, take a look at
date -d '2018-07-03 21:00UTC'
Reason for outage:
There have been a set up of updates for EL7 and Fedora requiring
reboots of infrastructure. We will be rebooting the Build and remote
systems outside of PHX2 on this day.
Various web services housed in PHX2 may be up or down during the
outage window. This will affect builds and authentication for short
periods of time.
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
Stephen J Smoogen.
You are kindly invited to the meeting:
Infra Office Hours on 2018-06-26 from 18:00:00 to 19:00:00 UTC
The meeting will be about:
Weekly hour dedicated to answer questions or help people with fixing tickets or implementing features.
On 06/25/2018 12:33 AM, jkonecny(a)redhat.com wrote:
> On Sat, 2018-06-23 at 11:23 -0700, Kevin Fenzi wrote:
>> On 06/22/2018 09:38 AM, Martin Kolman wrote:
>>> Yeah, that looks good:
>>> - lack of backup/mirroring should not be a problem (the results are
>>> more or less
>>> ephemeral anyway & we can easily back them up internally if needed)
>>> - upload speed should not be an issue for the PR test logs & we
>>> plan to publish daily logs
>>> from kickstart test runs, so even if there was a ~hour delay for
>>> uploding the logs it should not
>>> make much difference for once-a-day run.
>>> Using the existing gitanaconda group should be fine as well,
>>> thanks. :)
>>> BTW, how would you recommend to handle the automated log uploads to
>>> this space ?
>>> Is there some interface where we can set a SSH public key, so that
>>> the test runner
>>> can upload the logs there or something similar ?
>> Other groups (cockpit at least) have created a fas user. I'd suggest
>> something with 'bot' in the name like 'anaconda-bot'. Then login and
>> it's ssh key and add it to the group.
> We already have bot user with name: installker
ok. You should be able to use that as long as you add it to the group.