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,
As a designer, when I jump into doing a UI review, or hacking on the
templates / CSS of a new project, one of the most painful steps for me is
getting my dev environment set up.
Most of our webapps do have very good documentation on getting a dev
environment set up, but invariably this takes a good chunk of time and
fiddling for me (being someone that is not super-familiar with setting up
and running the back-ends of webapps). This is especially relevant if what
i am trying to fix is just a simple template change, and TBH manually
tweaking postgres config files is not really my idea of a good time. :)
Long story short, i am asking for comments and thoughts on how to make
setting up a dev environment simpler and easier (and perhaps even
standardized between all our apps).
I recently started playing with Vagrant, and made this vagrant setup for
bootstrapping a bodhi dev envirionment using Vagrant on top of
vagrant-libvirt, and it works pretty well for me -- i can just use one
command to spin up a new clean instance of a bodhi dev environment, with
the DB configured and populated and ready to go. Note that i chose libvirt
with Vagrant here, primarily because i am not well versed in Docker, but
Docker on Vagrant is possible too.
 - https://gist.github.com/ryanlerch/577eb8cd9d8ff66023cb2f98dc78bfe5
we are now in the infrastructure freeze leading up to the Fedora 24
Beta release. This is a pre-release freeze.
We do this to ensure that our infrastructure is stable and ready to
release the Fedora 24 Beta 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:
git clone https://infrastructure.fedoraproject.org/infra/ansible.git
scripts/freezelist -i inventory
Any hosts listed as freezes is frozen until 2016-05-03. (or later if
Beta 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.
My name is Justin, IRC / FAS username jflory7. Some of you might have
seen me around other parts of Fedora. I am looking at becoming more
involved with the Infrastructure team.
Over the summer, I am planning on contributing to the Ansible playbooks
as part of Google Summer of Code. My primary objectives are to (1) merge
the Community Blog and Fedora Magazine into a shared core, and (2)
automate the deployment with Ansible, one of the very few things in
Fedora that is not powered by Ansible yet. Patrick (puiterwijk) is
mentoring me for my proposal.
The full details of my project proposal can be found on the wiki.
In terms of my current experience, I am a Networking & Systems
Administration student at the Rochester Institute of Technology. I have
about three years experience administrating CentOS/RHEL machines that I
have used for personal work. I am familiar with Java and am in the
process of picking up Python.
More information about me can also be found on my wiki page.
I'm planning on making it to the meeting today and have already added
some info to the Gobby meeting agenda pad. Looking forward to getting
more involved with the Infrastructure team!
Justin W. Flory
Basset's rabbit-mq is very chatty in logs, so I would like to apply the
following and run the logserver playbook:
diff --git a/roles/epylog/files/merged/weed_local.cf
b/roles/epylog/files/merged/weed_local.cf index db8ed07..7720ad5 100644
@@ -213,6 +213,7 @@ python2.*: mail from:.*
restorecond: Reset file context /etc/aliases.*
restorecond: Reset file context /var/db/shadow.db.*
With the netapp maint last night, we may be able to finally take
advantage of nfsv4 mounts. I'd like to take backup01 (when it's not
doing any backups, ie, before 22UTC when they start) and do some
testing to see if I can get it working.
If I can, great. If not, I can reboot and set it back to nfsv3 before
the backups start.
The infrastructure team will be having it's weekly meeting tomorrow,
2016-04-28 at 18:00 UTC in #fedora-meeting on the freenode network.
We have a gobby document
(see: https://fedoraproject.org/wiki/Gobby )
fedora-infrastructure-meeting-next is the document.
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.
If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.
= Introduction =
This shared document is for the next fedora infrastructure meeting.
We will use it over the week before the meeting to gather status and info and
discussion items and so forth, then use it in the irc meeting to transfer
information to the meetbot logs.
= Meeting start stuff =
#startmeeting Infrastructure (2016-04-28)
#chair smooge relrod nirik abadger1999 lmacken dgilmore threebean pingou puiterwijk pbrobinson
#topic New folks introductions / Apprentice feedback
= Status / information / Trivia / Announcements =
(We put things here we want others on the team to know, but don't need to discuss)
(Please use #info <the thing> - your name)
#topic announcements and information
#info codecs.fedoraproject.org all setup, just needs SOP and repo files updates - kevin/dennis
#info updated blacklist of lists to not send fedmsg for - kevin
#info blockerbugs01.stg proxy setup fixed up - kevin
#info helped clean up some hosts netmasks after networking changes - kevin
#info netapp storage outage/update wed night - kevin
= Things we should discuss =
We use this section to bring up discussion topics. Things we want to talk about
as a group and come up with some consensus or decision or just brainstorm a
problem or issue. If there are none of these we skip this section.
(Use #topic your discussion topic - your username)
= Learn about some application or setup in infrastructure =
(This section, each week we get 1 person to talk about an application or setup
that we have. Just going over what it is, how to contribute, ideas for improvement,
etc. Whoever would like to do this, just add the info in this section. In the
event we don't find someone to teach about something, we skip this section
and just move on to open floor.)
unknown. Sign up now?
#topic Learn about:
= Meeting end stuff =
#topic Open Floor
Good Morning everyone,
Ralph and I have tried to move our team to a pull-request based development
practice. The idea is that every piece of code of every application that is
released should go through a pull-request/code review. That means application
that are being dev, do not necessarily need to go through this process.
The code review can be as simple as checking that there is nothing standing out
in the code while reading it, asking for a comment in the code if there is
something a little hard to understand. It can also be as complex as pulling the
changes locally and run them to see if they behave as expected.
Most often I have done the former though :)
Code review does not mean you are formally acknowledging that there are no bugs
in this piece of code. More that you have been through it, understand it and
that it seems to make sense to you.
The person who wrote the code is expected to have tested it, the reviewer is
more tasked to check if the code make sense, if there are optimization that
could be done and using this process, we can improve the understanding of our
apps in the team, meaning that if there is a fire to pull out, the code will
look more familiar to more people.
All this to say that, everyone can do code review, I've missed more than my
share of typos and small bugs in reviews, but I've also found some small issues,
asked for some clarifications and so on.
Code review is also a good place to fight technical debt. Quite often we can do
something that works and the reviewer points out that this is not the best way,
which motivate us on fixing things (that's at least my experience).
Asking for code-review isn't necessarily nice, it gives the feeling you're
asking someone to do work for you.
So Ralph and I put in place a few tools allowing to find the opened
pull-requests so that people wanted to do some can check them, once or twice a
day or more, see if there is anything new and act on it without the need for the
developer to ask.
So pull-requests can be found:
* on #fedora-apps, either by the github or fedmsg bots
* on http://ambre.pingoured.fr/fedora-infra/ for all the opened PRs on
* available on irc using the .pulls command, for example:
.pulls pagure <- the PR of the project tagged as 'pagure' on pagure.io or
part of a 'pagure' group on github
.pulls fedora-infra <- the PR of all the projects tagged 'fedora-infra' on
pagure or part of the fedora-infra group on github
I personally pinned the URL in the second bullet point above in my firefox and
check it a few times a day.
If people are interested, I could see about adding support for pagure in there
and other platforms if we want/need.
I hope this will motivate everyone to regularly check for new pull-requests and
take a few minutes to go through them and see if they can spot problems.