About JS framework
by Pierre-Yves Chibon
Good Morning Everyone,
Our infrastructure is mostly a python store, meaning almost all our apps are
written in python and most using wsgi.
However in python we are using a number of framework:
* flask for most
* pyramid for some of the biggest (bodhi, FAS3)
* Django (askbot, Hyperkitty)
* TurboGears2 (fedora-packages)
* aiohttp (python3, async app: mdapi)
While this makes sometime things difficult, these are fairly standard framework
and most of our developers are able to help on all.
However, as I see us starting to look at JS for some of our apps (fedora-hubs,
wartaa...), I wonder if we could start the discussion early about the different
framework and eventually see if we can unify around one.
This would also allow those of us not familiar with any JS framework to look at
the recommended one instead of picking one up semi-randomly.
So has anyone experience with one or more JS framework? Do you have one that
would you recommend? Why?
Thanks for your inputs,
Pierre
1 year, 6 months
The packages app has a short runway
by Randy Barlow
Greetings!
The packages app is running on Fedora 30, and its dependencies are not
available in Fedora 31+ as I understand it.
This means it has about 7 months before we need to do something about
it, or shut it off.
Do we know if it can run on RHEL 7?
3 years, 12 months
Pagure for EL8 (EPEL8)
by Neal Gompa
Hey all,
In the interest of helping to modernize the infrastructure Fedora runs
on, I'm working on introducing Pagure into EPEL8. This will hopefully
allow us to upgrade our Pagure instances to use RHEL 8 instead of RHEL
7, and notably, make the transition (mostly) complete for moving all
Python software Fedora runs to Python 3.
I've done an early build locally to determine what's needed to make
this possible. The following report from DNF indicates the missing
packages that need to be added to EPEL 8 before I can introduce Pagure
into EPEL8:
Problem 1: conflicting requests
- nothing provides python3-jenkins needed by pagure-ci-5.8-1.el8.noarch
Problem 2: conflicting requests
- nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(binaryornot) needed by
pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(celery) needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(flask-wtf) needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(redis) needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(straight.plugin) needed by
pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(wtforms) needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(pygit2) >= 0.26.0 needed by
pagure-5.8-1.el8.noarch
Problem 3: conflicting requests
- nothing provides python3-trololio needed by pagure-ev-5.8-1.el8.noarch
One of the reasons I'd like to have this done sooner rather than later
is so that we can drop Python 2 support from Pagure with version 6.0.
I think it's quite reasonable to say that version 6.0 isn't going to
happen until we can get our Pagure servers running on EL8 using Python
3.
So now, I need some help making this happen. I already own trololio,
and I'm going to make that available in EPEL 8 ASAP. Can anyone help
with some of the other dependencies here?
Thanks in advance,
Neal
--
真実はいつも一つ！/ Always, there's only one truth!
4 years
Infrastructure docs & apps.fp.o
by Timothée Floure
Hi,
I wrote [1] to devel some time ago regarding the deprecation of the apps.fp.o
index and plan to move its content to the main docs. Kevin mentionned that it
could end up in the infrastructure docs and that the whole should be moved to
docs.fp.o at some point. I will take a look at both since I have wanted to play
with the new documentation pipeline for a while. I am not the best guy to
meddle with the infrastructure doc but I might as well do something useful
while playing with antora. Tell me if it's not or if I missed something.
I might have something to show you at Flock if I have troubles sleeping in the
train.
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
See you in Budapest,
--
Timothée
4 years, 2 months
F29 and older instances
by Kevin Fenzi
Greetings everyone.
On 2019-11-26 fedora 29 will go end of life and no longer supported.
We still have a number of things that are f29 (or older for various
reasons). I'd like everyone to look this over and see if you can't move
things to f31 (or at least f30) before the f29 eol.
builders: I am working on this, builders right now are mostly f29, but
should be all moved before the eol date I hope.
openshift apps:
modernpaste: fedora-27. :) But I don't think it was ever moved to
openshift, so we should delete this.
joystick: we should fix this up, I think jdoss was going to take it
over?
the-new-hotness: can we move to f31?
qa-stg01.qa.fedoraproject.org: f24? can we retire?
autocloud*: f27, but should die when f29 goes eol (it's only used to
test atomic-host).
mdadpi: f27, but it moved to openshift, can we clean up the non
openshift instances and files please?
modernpaste: f27. It goes eol soon, so I guess we just wait
notifs-backend: f27. I don't know what to do here. We need a
replacement, which we don't have. I'm afraid that upgrading will blow it
up, but I guess we could try and rollback?
qa-prod01: f27. can we retire?
ci-cc-rdu01: f28. Can we retire soon?
copr-frontend01/02.stg: f28 and I don't think we need them anymore, can
I nuke them?
db-qa03: f28. Can we upgrade please?
osbs: f28, but I think cverna was moving it to newer? any status?
f29's:
aarch64-test01/02 - can be redone as f31 anytime
composer.stg - should be moved to f31
db-koji01.stg - should be moved to f31 and a prod->stg sync
kojipkgs01/02 - I should do these soon to f31, adding to my list.
os-proxy01 - I should do this one, on my list
packages03/04 - No idea here. Can we upgrade?
proxy* - we need to start working on this asap.
relepel01 - do we need this one anymore?
resultsdb/taskotron - can qa folks upgrade these?
old cloud instances:
glittergallery-dev: f23, should be nuked
fedora-bootstrap: f25, should be nuked
waiverdb-dev: f25, still needed?
commops: f27, still needed?
telegram-irc: ? still needed?
copr*stg: f28, can copr folks upgrade?
developer: f28, still needed?
libravatar: f28, should ask them to move to communishift
simple-koji-ci: f29. Can we upgrade to 31? or move it to communishift?
I think thats all of them.
kevin
4 years, 4 months
Re: Deprecating Autocloud
by Sinny Kumari
On Mon, Apr 29, 2019 at 4:47 PM Kamil Paral <kparal(a)redhat.com> wrote:
> On Mon, Apr 29, 2019 at 11:39 AM Sinny Kumari <ksinny(a)gmail.com> wrote:
>
>>
>>
>> On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi <kevin(a)scrye.com> wrote:
>>
>>> Or could we move f29+ all to whatever is replacing it? (taskotron?)
>>>
>>
>> It will be nice but I am not aware of any other system in place which
>> would
>> replace checks performed by autocloud.
>>
>> (CC'ed tflink and kparal)
>> Does taskotron provides capability to perform tests on Fedora cloud
>> Images like booting images and other basic checks?
>>
>
> Theoretically it is possible using nested virt. However, Taskotron is
> going away as well. The replacement is Fedora CI:
> https://docs.fedoraproject.org/en-US/ci/
>
Thanks kamil! yeah, it doesn't make sense to move to Taskotron if it is
going to be deprecated as well.
> I recommend to ask in the CI list:
> https://lists.fedoraproject.org/archives/list/ci%40lists.fedoraproject.org/
>
> It should be possible for them to provide the infrastructure you need.
>
Hmm, I am not very sure if we should spend time investigating and setting
up alternative
to autocloud unless we have usecases for long run. Fedora Atomic Host Two
Week releases ends with F29 EOL.
--
http://sinny.io/
4 years, 4 months
[PATCH] aws-iam-policies: fcos-upload-amis: add ability to DescribeRegions
by Dusty Mabe
Need this since we recently changed to dynamically detect regions
to upload to. See https://github.com/coreos/coreos-assembler/commit/ab3cae5
---
files/aws/iam/policies/fcos-upload-amis.json | 1 +
1 file changed, 1 insertion(+)
diff --git a/files/aws/iam/policies/fcos-upload-amis.json b/files/aws/iam/policies/fcos-upload-amis.json
index 03999c6b0..266074522 100644
--- a/files/aws/iam/policies/fcos-upload-amis.json
+++ b/files/aws/iam/policies/fcos-upload-amis.json
@@ -22,6 +22,7 @@
"ec2:DescribeImageAttribute",
"ec2:DescribeVolumes",
"ec2:CreateSnapshot",
+ "ec2:DescribeRegions",
"ec2:DescribeConversionTasks"
],
"Resource": "*"
--
2.20.1
4 years, 4 months
CPE Weekly: 2019-11-29
by Aoife Moloney
Hi everyone,
Welcome to the CPE team weekly project update mail!
Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers
can give.
For better communication, we will be giving weekly reports to the
CentOS and Fedora communities about the general tasks and work being
done. Also for better communication between our groups we have
created #redhat-cpe on Freenode IRC! Please feel free to catch us
there, a mail has landed on both the CentOS and Fedora devel lists
with context here.
Note:
This document is currently built from individual reports rolled into a
google document which we edit and copy into a final document. We are
aware that this causes problems with some email readers, and are
working on a method to make this less problematic.
High Level Project Updates:
Fedora:
Rawhide Gating:
Bodhi was 5.1 released and is deployed in staging
Robosignatory is broken in staging preventing testing much there
Application Retirements
Elections
Elections being moved to Communishift really soon! Stay tuned!
Fedocal
Still no progress on kanban board last four weeks
https://teams.fedoraproject.org/project/fedora-calendar/kanban
Jlanda is still hitting permission error in communishift
https://pagure.io/fedora-infrastructure/issue/8274
Still working on running local instance
Nuancier
Benson Muite is now working on OIDC authentication
A PR will be created on Github to test if we can see the progress
New PR from sebwoj - Porting to Fedora messaging is under review
Pastebin
Still on track for December 1 modernpaste shutdown
GDPR and privacy centric conversations with respect to application
handovers have resulted in…..more conversations needed - shock :)
CentOS:
The team have been testing projects migration from repospanner to
locally hosted git repositores on git.dev.centos.org and come back
with a migration script/plan to unblock RCM
CentOS Stream
Scoping meetings are still ongoing
Misc
Bugzilla sync script has been resolved
Email inviting to review its change has been sent
New changes to src.fedoraproject.org deployed:
Ability to set the anitya monitoring status directly in the UI
Ability to adopt orphan (and not retired) packages directly in the UI
New changes to Pagure on the horizon:
New API endpoint to enable/disable git hooks
Ability to set dist-git in the default assignee overrides for bugzilla
EPEL 8 modularity
Updates can now be created in bodhi staging!
We are currently testing pushes/composes
We are also testing epel8-playground-modules composes
Aarch64 is now racked and networked
Koji
New koji owner script was debugged
Koji client was updated
Koji was also patched for the --title option fix
Configured migrations from Ansible/Jinja template
https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/1
https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/3
https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/11
https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/14
https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/16
Various Resolved Issues
https://pagure.io/mdapi/pull-request/91
https://github.com/fedora-infra/bodhi/pull/3782
Comments? Suggestions? Feedback? Let Us Know!
Have a great weekend!
Aoife
--
Aoife Moloney
Feature Driver
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
4 years, 4 months
