[release] pagure: 1.1
by Pierre-Yves Chibon
Good Morning Everyone,
I just cut a new release of pagure 1.1.
It is a fairly big update with quite a number of changes but so far things seems
to be running fine.
Here is the changelog:
- Sort the release by commit time rather than name (Clerment Verna)
- Add a link to the markdown syntax we support
- Add the possibility to display custom info when creating a new PR
- Improve the title of the issue page
- Make the ssh_info page more flexible so that we can add new info more easily
- Add the possibility to resend a confirmation email when adding a new email
address
- Encode the email in UTF-8 for domain name supporting it
- Add a button to easily change your avatar in your settings' page (Clement
Verna)
- Expand our markdown processor to support implicit linking to both PR and
issues
- Fix running the unit-tests on F23
- Fix deleting in the UI branches containing a slash ('/') in their name
- Add the possibility to always have a merge commit when merging a PR
- Add the project's avatar to the list in front page when authenticated
- Make the dependency on flask-fas-openid (part of python-fedora) optional
- Prevent our customized markdown to create link on foo.com if it doesn't start
with {f,ht}tp(s) (Clement Verna)
- Bring back the delete ticket button (Ryan Lerch)
- Add the possibility to notify someone when it is mentioned in a comment via
@username
- Fix setting the default value of the web-hook setting and its display in the
settings page
- Add the possibility to have templates for the issues
- Add a button on the doc page to open it in a new tab
- Add the concept of notifications on PR allowing to indicate when a PR is
updated or rebased
- Fix allowing people with non-ascii username to merge PR with a merge commit
- Add the possibility to theme your pagure instance and customized its layout at
will
- Add the possibility to always see inline-comments even if the file was changed
since
- Improve the error message given to the user upon error 500 (Patrick Uiterwijk)
- Stop relying on pygit2 to determine if a file is a binary file or not and
instead use the python library binaryornot
- Store in the DB the identifier of the tree when an inline comment is made to a
PR, this way it will be simpler to figure out a way to add the context of this
comment either by email on in the UI
- Add styling to blockquotes so that we see what is the quote and what is the
answer when replying to someone
- Prevent users from adding again an email pending confirmation
- Fix the preview box for long comment (Ryan Lerch)
- Add the possibility to sort the projects when browsing them (Ryan Lerch)
I would like to highlight some:
- You can now override templates and static files to theme your own pagure
instance
- You can provide templates for issues
- You can customize the Open PR page
- You can notify someone by just using @username
- You can run the unit-tests on F23 :)
I also would like to thanks all the contributors who helped making this release!
Happy hacking,
Pierre
8 years, 1 month
Dropping gitolite and breaking stg
by Pierre-Yves Chibon
Good morning everyone,
For a little while now I have been wondering about dropping gitolite for pagure.
Gitolite has quite a lot of advantages:
- well known
- well documented
- very flexible
But for pagure's use-case it also has some drawbacks:
- perl
- "too powerful"
Let me explain the later point, pagure use-case is currently: either you have
commit or you don't. There is no per-branch ACLs (yet?) and no need for a number
of the fancy features gitolite offers (VREF, aliases...).
Basically it could be replaced with:
- a simple async service queried upon login (ssh login) allowing read/write access,
shell access or denying access
- a git hook for branch ACLs (this would become a pagure plugin I think, like
the other hooks). As said above this isn't there atm, so this could also come
in a later stage anyway.
That's also how gitolite works, a script called upon login allowing access or
not and a git hook for more fine-grain ACLs.
While looking into this I have also been thinking if we would like to drop
gitolite for pkgs.fp.o as well.
We could have the async service directly linked to pkgdb's DB. This means:
- Changes to pkgdb are directly propagated to pkgs.fp.o
- We can rely on the collections information directly retrieved from the DB
- We can use our current set-up (one shell account / packager) and not tweak
gitolite until it behaves as we want (which is only supported by gitolite to
please us).
- No need for the alias warning for namespacing, we can check if a namespace was
specified and use ``rpms`` if not
- May be easier to hack/maintain in the long term (may be not, hard to say in a
way :))
We would still need to have a service to create the git repo and eventually the
branches.
And for pkgs.fp.o we will definitely need a git hook (but there is already one)
to prevent branch from being deleted and do branch-based ACL control.
One question though, looking at our current setup, we allow people to create
their own branch, and not to delete it, right?
I am curious if anyone can create a branch on a package, I'm not seeing
something in the gitolite repo that would prevent me from creating a branch on a
package I don't maintain (assuming I am not provenpackager), but maybe I've
missed it.
So what do you think of this?
Would you be ok with me breaking pkgs.stg.fp.o to do some testing? If so I will
try not to break things in a non-reversible way :).
AFAICS, the only thing I'd need to change is the ~/.ssh/authorized_keys files
for the users and add an pkgdb_async_client RPM or so that would be call upon
login and contain the git hook.
Thoughts? Rotten tomatoes? Soup?
Note that I might still pursue this for pagure, not entirely sure yet though.
Just a thought while writing this, using this approach might actually make it
easier to deploy pagure for pkgs.fp.o since then we could indeed just use pkgdb
as data source and have a fedmsg-based updater to sync ACLs from pkgdb to
pagure.
Thanks for reading it this far :)
Pierre
8 years, 1 month
Plan for tomorrow's Fedora Infrastructure meeting - 2016-02-18
by Kevin Fenzi
The infrastructure team will be having it's weekly meeting tomorrow,
2016-02-18 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.
kevin
--
= 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-02-18)
#meetingname infrastructure
#topic aloha
#chair smooge relrod nirik abadger1999 lmacken dgilmore mdomsch 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 more spring cleaning - kevin
#info mass update/reboot cycle yesterday for glibc and other updates - kevin
#info
= 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)
#topic Spring cleaning progress - kevin
#topic easyfix tickets ideas - kevin
= 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.)
Schedule:
2016-02-18 - ???
2016-02-25 - RFR - patrick
#topic Learn about: ???
= Meeting end stuff =
#topic Open Floor
#endmeeting
8 years, 1 month
February status update for Fedora Infrastructure Apprentices
by Kevin Fenzi
You are getting this email because you are in the 'fi-apprentice' group
in the fedora account system (or are reading this on the
infrastructure list).
Feel free to reply just directly to me, or cc the infrastructure list
for everyone to see and comment on.
https://fedoraproject.org/wiki/Infrastructure_Apprentice
At the first of every month(or so), I am going to be sending out an
email like this one. I would like feedback on how things are going for
you.
I'd like to ask for everyone to send me a quick reply with the
following data or anything related you can think of that might help us
make the apprentice program more useful.
0. Whats your fedora account system login?
1. Have you logged in and used your fi-apprentice membership to look at
our machines/setup in the last month? Do you plan to?
2. Has it helped you decide any area you wish to focus on or contribute
to more?
3. Have you looked at or been able to work on any of the fi-apprentice
'easyfix' tickets?
https://fedorahosted.org/fedora-infrastructure/report/14
4. Do you still wish to be a member of the group? If not (for whatever
reason) could you provide any hints to help others down the road?
5. Is there any help or communication or ideas you have that would help
you do any of the above?
6. What do you find to be the hardest part of getting involved?
Finding things to work on? Getting attention from others to help you?
Finding tickets in your interest area?
7. Have you been able to make any weekly irc meetings? Do you find them
helpful or interesting?
8. Have you logged into our Gobby instance and read/seen/added to our
meeting agenda? https://fedoraproject.org/wiki/Gobby
9. What will you spend leap day on this year? (2016-02-29)
Any other general feedback is also quite welcome, including
improvements to this email, the wiki page, etc.
Any folks I do not hear from in the next week will be removed from the
group. (Note that it's easy to be readded when you have time or
whatever and it's nothing at all personal, we just want to keep the
group up to date with active folks).
Thanks, and looking forward to your feedback!
kevin
8 years, 1 month
ansible 2.0 on batcave01
by Kevin Fenzi
With Toshio porting our callback plugins last night I have gone ahead
and moved batcave01 over to ansible 2.0.
I'm sure we will hit some minor issues, but for the most part I think
we should be good to go.
If you do run into something, please fix it, or report it so we can fix
it up. Playbooks should all run fine as normal, some scripts may still
need porting.
The only other thing related to ansible 2.0 I can think of is that copr
may need to adjust to the new API if it's using that directly, but it
can do that on it's own timeframe.
kevin
8 years, 1 month
a new MirrorManager-related tool for stripping old metadata and
pushing critical updates in a defined time
by Kamil Paral
Hello,
before Christmas QA started discussing changes in the release blocker process for bugs that are not media-related (i.e. don't need to be fixed in the generated .iso/.img files). The conversation is available here:
https://lists.fedoraproject.org/archives/list/test%40lists.fedoraproject....
I took interest in one specific type of such bugs, which are release blockers in one of the existing stable releases (i.e. Branched-1 or Branched-2). These are usually related to the upgrade process. We later decided to mark them with AcceptedPreviousRelease flag in Bugzilla, so I'll call them like this. This email is concerned just with these bugs, i.e. just one type of the non-media-related blockers. (I want to separate the overall topic into several separate discussions, so that it's easier to talk about it and we don't muddy the discussion with too many things at once).
For these AcceptedPreviousRelease blockers, we want to make sure that all of this happens before we announce Branched release:
a) their updates are pushed to Branched-1 or Branched-2 updates repo
b) the contents of those repos are available to all our users, also considering all caches and refresh intervals
Ensuring a) is easy and will be tracked by QA and Bodhi as usual, but for b) we will need help from releng/infra. Since many users upgrade immediately on release day, we really need to make sure the updates are available for everybody by that time, otherwise a large portion of our user base will get affected by those blocker bugs. I have tried to investigate how best to ensure the latest repo contents are available to everyone, and I described it here:
https://lists.fedoraproject.org/archives/list/test%40lists.fedoraproject....
As the easiest way to achieve this, I suggested we create a new MirrorManager-related tool which will strip all old metadata from the repo metalink. Dennis from RelEng agreed he could run such a tool in these circumstances to make sure only latest metadata are distributed. I suppose the tool could work something like this:
1. A blocker update was pushed to f23-updates on 2015-01-07.
2. Releng will run the tool like this:
$ ./mm-strip-old-metadata --release 23 --repo updates --date 2015-01-07
(This is assuming there is only one push per day, if not, maybe we can have --timestamp instead of --date).
3. The tool will go through all metalinks for f23-updates (all primary architectures), and drop each <mm0:alternate> section which has <mm0:timestamp> older than the provided date (let's say midnight UTC).
4. As a result, end-user machines will only connect to repositories which already serve the blocker update (have that or newer repo tree).
And now finally the important question - does infrastructure team thinks this is easily doable, or is there something not accounted for? Is here someone willing to create such a tool? In December, I talked to Adrian Reber and I got the impression he's a MirrorManager developer, so that's the only name I know of, but I don't want to bother anyone directly. Are there more of MM developers? Is anyone willing to help out with this?
Thanks a lot,
Kamil
8 years, 1 month
Spring cleaning
by Kevin Fenzi
I mentioned this in the last meeting, and wanted to bring it up here as
well.
We have made a number of improvements in our ansible vm deployment and
host setup in the last few months. This includes (but is not limited
to):
* guests now get a watchdog device that will reboot them if they go
unresponsive. This would have come in handy a few times in the past
for overloaded machines that we had to notice and power cycle
manually.
* guests are deployed with maxmem and maxvpcus set to 5x what their
current configured allotment is. This means we should be able to hot
add memory and cpus without rebooting machines. This would have come
in handy a few times in the past to avoid downtime.
* Hosts are now using qemu-kvm-rhev, which has some more features over
the base qemu-kvm. This should allow us to live migrate guests that
don't have shared storage. This will sometimes be handy.
* guests ip config is now in ansible, so everything should be the same
on all of them config wise and they should come up with the correct
config on boot. This will save me time having to update resolv.conf's
after reboots or the like. It also (with some caveats) will allow us
to change ip's of guests in ansible and have it make the change for
us.
* I've tweaked our kickstart's and process a bit to bring up virthost
machines easier (passing them the right stuff to use bridges from the
start, etc).
* Since it's been a while since we deployed some machines we may have
added dependencies or broken things so they don't deploy. I would
like to fix these things. Like when reinstalling proxy12 yesterday I
ran into the fact that it needs the hostkey copied to it or httpd
won't start and it needs docs synced before it can be added into
service, we should fix those things in playbook so we don't mess them
up.
So, with all those changes, I would like to look at reinstalling
everything. :)
Some machines should be trivial to do (where we have an 01 and 02, we
can do 01, then 02 with no downtime). Some of them can be just done
when internal users aren't using them (things like rawhide composer
when it's not composing, or backup server not backing up, etc). A few
will require downtime or making a new instance and copying everything
to it and switching over. A few will definitely require downtime (the
database servers).
I've already started a bit with ibiblio hosts (since we have to move
things around there due to new drives anyhow). Probibly we should get
all the easy ones done quickly and then look and see and schedule the
ones that will require downtime or other special needs. Ideally, I
would like to have this all done before the F24 Alpha freeze.
Thoughts? comments? rotten fruits?
kevin
8 years, 2 months