Didn't you already run it?
(Retrospective) +1 from me
On Feb 25, 2015 5:39 PM, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
> Hi all,
> Justin has asked me if we could increase the maximal size limit for upload of
> kernel tests results (from 10 Kb to 25 Kb).
> He has done it upstream, this commit changes it in prod.
> I would like to apply it and run the corresponding playbook.
> infrastructure mailing list
Hi there, I have nothing set up top properly send patch through email,
but this is just a first draft in order to get review.
As we are moving translations to zanata, websites have to pull
translations from there.
- suppose transifex translation is frozen. Not pulling from there
anymore, we can drop the transifex-client support
- installs zanata-python-client
- don't set up correct API KEY. I don't know how to define this
- sync translations on the previous directory (oh, we might remove the
previous archive. Is there a way with puppet to remove a directory at
first setup ?)
-we need to check it, and edit our Makefiles accordingly (on the
It would be nice to use zanata ASAP.
Please, give me your thoughts. Even If I have to split the patch (to
Also, I have no idea about freeze time.
We currently have MirrorManager2 running on staging. It's apparently not 100%
set-up since we get emails once in a while that one of the crons failed
(iirc among other we need to finish configuring fedmsg).
Other that this, MirrorManager2 is currently in a decent shape I think.
However, we really need to make sure nothing broke in the re-write and we
want to make sure we won't break it in the future.
To try to ensure that last part, I have try to write some tests for the UI but
also for the backend part (all the different scripts).
The pull-request is opened for review:
I have also been trying to capitalize on the knowledge we acquired during the
FAD by starting to write down how mirrormanager works in the documentation:
(pull-request to be opened once the tests branch is merged)
I would appreciate if those that were at the FAD could go through this
branch/changes and adjust as needed.
I have been thinking about asking Matt to do the review so that we can adjust
and improve the documentation.
Before we move MirrorManager2 to prod, here is what I think would be nice to
- Pickle validation
- Figure a way to validate a pickle after its creation and before moving it to
the mirrorlist boxes
- Find out if we can improve our tests some more
(to improve our confidence that we're ready)
- Engage the mirror mailing list and try to get them to react on the coming
The pickle validation might also be an interesting idea to check if there is a
difference between the pickle generated by prod and the one generated in stg.
Finally, at DevConf we have been speaking quite a bit with Dennis around
updates and MirrorManager and here is some of the ideas we spoke about:
- Be able to run the UMDL script on only a part of the tree
(ie: be able to say, we updated f21-updates and we only update this part)
- Crawl the mirrors for only a part of the tree
(This goes together with updating only part of the tree via UMDL)
- Consider if we should/could drop the content of the host_category_dir table
before running the crawler
- Mirror versioning:
- run UMDL, detect changes, increase master mirror's version by 1
- run the crawler, check for the changes, align that mirror's version with the
master mirror one
- be able to see the difference between two versions
- be able to crawl a mirror only for the difference between the version it is
at and the version the master mirror is at
note: we might still want to run a full crawl once in a while (daily?
This list of ideas is more a long term todo list, not something we would want to
have working for pushing MirrorManager2 to prod.
Thoughts? Agreements? Disagreements?
Justin has asked me if we could increase the maximal size limit for upload of
kernel tests results (from 10 Kb to 25 Kb).
He has done it upstream, this commit changes it in prod.
I would like to apply it and run the corresponding playbook.
So, currently our iptables config is generated by a template in
ansible. In that template we add in all the ip's of staging hosts on
the production hosts (to make sure we block them all from talking to
production and possibly causing problems) (except for a small list of
production hosts that allow staging for various reasons).
So, the consequence of this is that when we add a new staging host
(like we did yesterday with ipsilon01.stg) all the production hosts
need to add that ip to their list to block.
So, I'd like to run:
ansible-playbook master -t iptables -l \*.phx2.\*
This will update the iptables config on phx2 hosts and restart
iptables. It will add:
+-A INPUT -s 10.5.126.35 -j REJECT --reject-with icmp-host-prohibited
This will have 2 effects:
1) Will make sure that ipsilon01.stg cannot talk to production and
cause any issue (not that it normally would).
2) My ansible check/diff report will be a ton smaller and I can see if
there's any real changes pending to hosts instead of being lost in the
list of pending iptables changes. ;)
So another freeze break request, +1s appreciated.
This change is the only thing needed to make non-master-repos an option.
Currently, the code always removes master from the requested branches, and crashes if it wasn't there.
I'm just adding a check to only remove it (and announce the package) if it was requested.
Author: Patrick Uiterwijk <puiterwijk(a)redhat.com>
Date: Wed Feb 25 11:34:07 2015 +0000
Only remove master from request if it was requested
Signed-off-by: Patrick Uiterwijk <puiterwijk(a)redhat.com>
diff --git a/roles/distgit/templates/pkgdb_sync_git_branches.py b/roles/distgit/templates/pkgdb_sync_git_branches.py
index c931d26..ced139b 100644
@@ -189,16 +189,17 @@ def branch_package(pkgname, branches):
if not os.path.exists(
os.path.join(GIT_FOLDER, '%s.git' % pkgname)):
- branches.remove('master') # SETUP_PACKAGE creates master
+ if 'master' in branches:
+ branches.remove('master') # SETUP_PACKAGE creates master
# Create all the required branches for the package
# Use the translated branch name until pkgdb falls inline
With kind regards,
I love when I'm the first one to request a freeze break, so here it is :)
Early today we found out that the mechanism restricting access to some packages
(3) to all but the official maintainers (ie: blocks access to provenpackagers)
in pkgdb2 is currently broken.
I've fixed this and Ralph has been kind enough to bare with the code to review
I would like to backport this patch into a new bug-fix release of pkgdb2 that I
would deploy tomorrow if I have enough '+1'.
note #1: Bug-fix release as in I'll add the patch to the RPM and build the RPM
with it, there won't be a new tag in pkgdb or a new release per say.
note #2: this will not go through staging since stg is running the
pre-release of 1.24 that is way ahead of what we have in prod currently.
On the other side, this has been broken for a little time with apparently no
side-effect so we could just wait, but since we know it... :)
Thoughts? +1? -1?
This morning I released a new version of nuancier with a number of changes
desired by the design team.
Here is the changelog:
* Tue Feb 24 2015 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 0.8.0-1
- Update to 0.8.0
- Create a group of reviewers that can approve/deny candidates
- Create a group of users having weighted votes (their votes count double)
- Fix the form to automatically add the red '*' when the field is mandatory
- Redirect the user when os.mkdir fails
- Drop some css instructions breaking the elections tab/pages
- Improve the configuration documentation
- Add URL to come back to the page you're at when login in/out
- Fix the query retrieving the denied candidate
After pushing it to stg and testing it with gnokii, we decided to push it to
prod as well.
I am fairly confident it won't break (too much) but in case I'm wrong, do expect
bug fix releases to come by during the freeze :-] (in advance sorry about that).