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
7 months, 1 week
The future of loopabull
by Pierre-Yves Chibon
Good Morning Everyone,
I know this question has already been raised a few times, but I think we should
raise it once more: what do we see as future for loopabull?
It is currently triggered on 4 topics (3 from prod and 1 from stg) to do basically
three actions:
- Flag commit successfully built in koji, in other words it adds these flags
to dist-git:
https://src.fedoraproject.org/rpms/mingw-filesystem/c/717f2a929bd25b62a04...
- Flag when the Fedora CI start testing a PR
- Flag when the Fedora CI finished testing a PR (and thus reports Pass/Fail)
Upstream released yesterday a 0.0.7 release which brings supports for
fedora-messaging (contributed by your servitor).
Looking at the code, it should be python3 compatible, but it doesn't say
specifically in the setup.py and I honestly don't remember if I've tested that
or not.
The package has been orphaned in Fedora for over 10 months and has thus been
retired.
I've had a chat with upstream yesterday and they are still interested in the
project but more as a pet project and their time is just like the rest of us,
limited for pet projects these days.
That being said the code base is really quite small and involves technologies
we're already using in other places (python-pika, celery, rabbitmq, ansible...)
so there isn't really anything new there.
One of its limitation currently is with secrets, how to pass/specify them.
This is something we could circumvent via ansible-vault or so, but it needs a
little investigation.
I basically see three ways forward with this:
- We continue with loopabull and we need to check its python3 support, how to
deal with secrets, if we can get it to run in openshift & so on.
- We look for something else, similar. The requirements being:
- Run a task when seeing a message in our message bus
- Handle secrets
- Scalable up/down
- Runnable in openshift is a bonus
- Preferably in a language we can debug (python++, potentially rust)
- We write something that fits our needs and requirements
Would you know something that fits our requirements and that we could just run?
If not, do you have a preferred way between options #1 and #3?
Thanks for your thoughts,
Pierre
2 years, 11 months
CPE Weekly: 2020-05-31
by Aoife Moloney
---
title: CPE Weekly status email
tags: CPE Weekly, email
---
# CPE Weekly: 2020-05-31
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.
See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/
## General Project Updates
Please check out our updated initiative timetable for briefing in new
projects to our team
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.
Don't forget to view our taiga board to see the projects we are
currently working on, what we have scoped and whats in our backlog
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null
I also currently have weekly IRC office hours on #fedora-meeting-1 @
1300 - 1400 UTC and I will have a bi-weekly office hours on
Centos-meeting @ 1500 - 1600 UTC beginning June 9th also, with Rich
Bowen helping me set it up, thanks Rich :)
There is (usually) no agenda for these meetings and is an open floor,
so please feel free to stop by and chat casually, or about any
projects the CPE team are working on/working on next. The choice of
topic is completely yours :)
### Gitforge
Just a quick note to say this project has not made any more notable
progress. Our team have some very time-intensive projects currently in
flight, so our focus has been and will be on the completion of these
projects over the next few months. We are still using the gitlab
project tracker https://gitlab.com/gitlab-org/gitlab/-/issues/217350
to record issues/technical requirements, and thank you again for your
patience during this slower period of the project, it is very much
appreciated.
## Fedora Updates
### Data Centre Move
* A reduced services offering of Fedora will be in effect from June
8th until July 28th, est.
* This is to complete the final shipment of hardware from Phoenix to
Washington, so please be patient and understanding during this
timeframe as some services will be off and the rest, much slower.
* Kevin Fenzi has sent some details on service validation and a call
to arms to help us meet the June 15th deadline to have the reduced
Fedora operational, please read:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
* Details on what this move may mean for you can be found here
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
### AAA Replacement
* Adding the ability to sign user agreements
* Adding the blog/website attribute for users
* Client library migration to python-freeipa 1.0.0.
### Mbbox
* Project Dashboard here https://github.com/fedora-infra/mbbox/projects/1
* Sprint 3 is done:
* Refactor molecule test suit to share test-cases
* Koji-hub and koji-builder SSL issues solved
* Sprint 4 is in progress
* Kojira CRD
* MBS Backend CRD (MBS doesn’t support fedora messaging)
* Staging environment
## CentOS Updates
### CentOS
* Post OCP4 cluster Installation tasks - storage, TLS cert/ IDP
configs, exploring operators that we can use.
* We have a public accessible ocp4 cluster
(https://console-openshift-console.apps.ocp.ci.centos.org/). We are on
the verge of figuring out subscriptions.
* Documentation: https://centosci.github.io/ocp4-docs/
* Linux 8.2 work is still with QA
### CentOS Stream
* The team are working on adding some 8.2 builds to Stream that failed
or did not make it into Stream for whatever reason.
As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.
Have a great weekend!
Aoife
Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
2 years, 12 months
Please help me receive necessary rights to manage resources in AWS
by Andrei Stepanov
Hello Fedora infra!
I am writing to ask for your guidance regarding how to best secure the rights to manage AWS resources within AWS Fedora Federation.
If you don't mind, could you please help me to understand what the best way to proceed would be?
I would like to request that I be granted the necessary right in order to manage AWS resources in a Fedora account.
So far, I have created an EKS cluster — but unfortunately, I cannot add any compute nodes to it. Also, I can't seem to create other resources, either.
If it would help, I can provide you with an example:
```
User: arn:aws:sts::125523088429:assumed-role/aws-fedora-ci/astepano is not authorized to perform: eks:TagResource on resource: arn:aws:eks:us-east-1:125523088429:cluster/astepano
User: arn:aws:sts::125523088429:assumed-role/aws-fedora-ci/astepano is not authorized to perform: eks:CreateNodegroup on resource: arn:aws:eks:us-east-1:125523088429:cluster/astepano
```
Could you please help me to figure out what the best way to proceed is?
It is very hard to predict which rights are necessary beforehand.
To give you a little bit of context, for example, I have the rights to manage EKS/EC2 -- but as you can see, AWS denies to act on my EKS cluster.
Also, for example, it would be good to create a PVC/network to not collide with testing-farm.
But unfortunately, I do not have the rights to create PVC/network/other resources.
Also, for some fedora-ci projects EKS is not necessary, ECS/Fargate will be enough.
I do not have rights to manage ECS/Fargate resources.
It would help me a lot if you could please suggest a way to fix this problem.
I don't think that opening a new ticket for each denial would be the most efficient or best approach — is there another good way that we could handle this?
I appreciate your insight.
--Andrei
2 years, 12 months
How to deal with dist-git repository of packages never imported
by Mattia Verga
I've started to clean up the list of approved review-tickets which were
never closed when I found https://bugzilla.redhat.com/show_bug.cgi?id=564412
The package bwping was approved and a git repo created, but it always
have been empty. It's currently orphaned both on Fedora and EPEL, but it
was never retired. So, I think this is an anomaly of the auto retirement
script.
Apart from that, I'm wondering what's the best course of action to do
with this package: should I self take and retire it, or it is best to
completely delete the git repo since nothing has never been in it? Is it
possible, and how?
Mattia
3 years
IAD2 datacenter testing/application validation
by Kevin Fenzi
Greetings everyone.
We now have most things deployed in our new datacenter (IAD2).
Accordingly, I would like to get some testing and validation started.
Please see the following document:
https://hackmd.io/op6N_nIaR7aMzw9Ib-sDAQ
Please feel free to ask questions here and add/check off services that
appear to be running as expected. Application owners (people in
sysadmin-whatever groups) should check that they have the expected level
of access as before, that their playbooks run (idempotently!) and the
logs and any interfaces show the application appears to be running fine.
We have this week and next to get everything in good shape for migration
week (20202-06-08) when we will moving everything out of phx2.
Thanks for any help. :)
kevin
3 years
ansible-review is run on pull requests
by Nils Philippsen
Hi everybody,
since a couple of hours, ansible-review is run on changes submitted
through pull requests in our Ansible repository on Pagure.
This means: when someone submits a PR to the ansible repo or pushes
changes into its source branch, a Zuul job is started which, when
finished, reports whether or not ansible-review finds problems in
changed playbooks/roles/... as a detailed comment (linking to test
results) and as a flag in the side bar (see [1] as an example).
Currently this is merely informational, i.e. if the Zuul job hasn't yet
finished or fails, this won't stop reviewers from merging the change
into the repository regardless. On the other hand, because we've set up
ansible-review to just process the changes submitted in the PR, this
takes relatively little time (think about 2 minutes from push to the
report coming in), so it should come in early enough unless you're in a
real rush. ;)
I'd like to thank Pingou, who did the preliminary work and structure
and especially Fabien Boucher who debugged the trouble we initially had
with our deployed version of Zuul[2] and contributed a workaround[3,4].
Ciao,
Nils
[1]: https://pagure.io/fedora-infra/ansible/pull-request/62
[2]: https://pagure.io/fedora-infra/ansible/pull-request/54
[3]: https://pagure.io/fedora-infra/ansible/pull-request/60
[4]: https://pagure.io/fedora-zuul-jobs/pull-request/60
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
3 years
