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,
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
>> 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:
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:
> 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
to autocloud unless we have usecases for long run. Fedora Atomic Host Two
Week releases ends with F29 EOL.
Over the last few months, I was working on integrating Fedora as a
sub-system to plume. This is to migrate from fedimg to plume, and
finally deprecating plume.
The work on plume has been completed and over the next few days, I
prepare for the deployment of plume. I've prepared a spec document for
the same. I plan to move this to Fedora wiki in some time but if
someone wants to do a review can have a look at it and post comments.
Sayan Chowdhury <https://words.yudocaa.in/>
GPG Fingerprint : 0F16 E841 E517 225C 7D13 AB3C B023 9931 9CD0 5C8B
we are now in the infrastructure freeze leading up to the Fedora 30
Final release. This is a final release freeze.
We do this to ensure that our infrastructure is stable and ready to
release the Fedora 30 when it's available.
You can see a list of hosts that do not freeze by checking out the
ansible repo and running the freezelist script:
ansible/scripts/freezelist -i inventory
Any hosts listed as freezes is frozen until 2019-04-30 (or later if
release slips). Frozen hosts should have no changes made to them without
a sign-off on the change from at least 2 sysadmin-main or rel-eng
members, along with (in most cases) a patch of the exact change to be
made to this list.
We have 2 old taiga instances: taiga.fedorainfracloud.org and
Last week I disabled nginx on them so they aren't serving anything.
Next week I would like to retire them both completely.
My understanding is that any active users have moved to the new teams
If there's something you need from them, let me know in the next week
before I retire them.
I noticed today that a backwards incompatible update was pushed to
Fedora 29 stable for libdnf. This breaks Bodhi, which uses
hawkey.Repo which was removed in that version. The update notes did not
mention a backwards incompatible API, and in general backwards
incompatible updates should not be pushed to stable Fedora versions.
This causes problems for Fedora users who may be using your library,
but it also causes issues in this case for the Fedora Infrastructure
team. Please do not push backwards incompatible updates in the
That said, we now need to take some action to solve the problem.
Ideally, we would revert the libdnf in Fedora 29 since that update
should not have happened. I also noticed the Fedora 30 does not have
this version of libdnf (so, Fedora 29 has the backwards incompatible
change, but Fedora 30 does not.) This means that users upgrading from
Fedora 28 to Fedora 31 will experience 3 backwards breaking changes,
instead of just one (which should happen in Fedora 31 only).
Can we revert this change?