[release] pagure: 0.1.33
Good morning everyone, I just cut a new pagure release: 0.1.33 Here is the changelog: * Fri Nov 20 2015 Pierre-Yves Chibon - 0.1.33-1 - Update to 0.1.33 - Prevent project with a name starting with a non-alphanumerical character (Farhaanbukhsh) - Ensure we appropriately set the private flag when creating an issue - Add an activity graph on the user profile using datagrepper - Sometime the identified we get is a Tag, not a commit (fixes traceback received by email) - Order the PR from the most recent to the oldest - Fix the patch view of a PR when we cannot find one of the commit (fixes traceback received by email) - Allow user that are not admin to create a remote pull-request - Fix closing the EV server by calling the appropriate variable - Fix generating the diff of remote pull-request Among the cool features, Ralph added an activity graph on the user page based on datagrepper: https://pagure.io/user/ralph (at the bottom) Most of the other changes are bug fixes :) Thanks to all the contributors and happy hacking! Pierre pgpNGwuyt6SdH.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: [PATCH] koji directory cleanup: shorten the time we keep things
On Mon, 26 Oct 2015 10:39:07 +0100 Mikolaj Izdebski wrote: > On 10/26/2015 10:13 AM, Vít Ondruch wrote: > > Dne 23.10.2015 v 23:18 den...@ausil.us napsal(a): > >> keep koschei builds for 1 day > > > > This is really short period. If the build fails Friday evening, it > > is already long time lost Monday morning when I would like to check > > what went wrong > > Definitely agreed. So short Koschei log life time very negatively > affects Koschei users. Logs should be kept much longer than one day > (at least 1 week IMHO). > > Note that Koschei users care mostly just about logs. You can remove > RPMs as soon as you want, or even not store them at all, which I > proposed this as a Koji enhancement long time ago: > > https://fedorahosted.org/koji/ticket/284 > > AFAIK this is a problem with lack of i-nodes on NetApp. Has anyone > considered increasing available i-node instead of this patch? Yes, and we not have 2x as many inodes. So, we could revert part of this if we want (possibly after freeze)? kevin pgpMXFSqYCrtt.pgp Description: OpenPGP digital signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Technical Debt Fighters, Assemble!
On Thu, Nov 19, 2015 at 02:14:50PM -0500, Ralph Bean wrote: > At Flock, we talked about scheduling some kind of regular > technical-debt-fighting week to happen every so often - some period of > time where we don't do any new features (and even try to de-prioritize > interrupt-driven stuff) and focus on shoring up, cleaning up, > tightening the bolts, etc[1]. > > Here are some things broadly to think about: > > - Add unit tests where there are none. Increase "code coverage". > - Write docs (and make diagrams!) where there are none. > - Reduce code duplication, and increase code re-use where appropriate. > - Break up ultra long methods, classes, and files into more > understandable chunks. > - Remove half-implemented features! > - Remove dead code!! > - Add comments where there are none, and correct inaccurate comments. > - Deal with the existential questions facing the code that none of us > wants to touch. > - Increase happiness and general zest for life. > > Time-wise, how about we try and schedule a week to try this on the > first week back from the holiday break -- a New Year, a New > Infrastructure(!) That would be January 4-8th[2]. > > Here's a question I have. It seems like we could approach this in two > different ways: > > - We could select one or two projects we want to prioritize, and try > to do *all* of the best-practices things to them. > - We could select one or two of the best-practices things, and try to > do them to *all* of our projects. I love the idea, one thought I had was: do we want to have all personnel on-board of the same project or do we want to make smaller team and split the projects among them? Say: 3 people on bodhi, 2 on pkgdb, 2 on badges and so on. Regarding the two ways I see pros and cons to either: - doing few best-practices on more projects might be more rewarding and faster, you know what you are targeting and by the end of the first or second day you're already faster to find and correct what you are looking for. - doing most best-practices on fewer projects might be better to gain a better insight on how the project works and is designed, and might results in more contributors in the long term (since more people know the code). So the first one might be more efficient, the second give a deeper insight on the project, on the other side the first approach should give a better overview of all the projects to more people. Maybe we should try one approach for the first and try the other for the next week :) Pierre pgptn_LABVgz6.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Meeting Agenda Item: Introduction Ladislav Novak
On Fri, Nov 20, 2015 at 08:04:13AM +0100, Ladislav Novák wrote: > Name: Ladislav Novák > TImezone: UTC/GMT + 1 hour / Czech Republic > IRC: ladisone > > > I can offer this skills: > System administrations > Webservers(Apache, Nginx) > VPN(Ipsec, OpenVPN) > DataBase(MySQL, PostgreSQL, Redis, MariDB, MariaDB-Gallera) > Mailserver(Postfix, Dovecot, Sieve, Webmail, Amavis, Postgrey, DKIM, > SPF, Postmulti, ) > Virtualization(KVM, OpenVZ, VirtualBox, Docker, VMWare) > DNS(Bind, PowerDNS, DNSmasq) > Cluster(cman, rgmanager, pacemaker, corosync, clvm) > Sotrage(DRBD, CEPHS, NFS, ISCSI) > FreeBSD Jails > Firewall(Iptables, Packet Filter) > Monitoring(Zabbix, Nagios) > Programing Language(Bash, Python, Ruby) > LoadBalancing(Haproxy) > Orchestration(SaltStack, Ansible, Puppet) > Kubernetes > Basic Openstack Welcome! There is no meeting 26 November due to the US holiday. Please stop by #fedora-admin or #fedora-noc to say hello and/or request to join the infrastructure apprentice group (it's where we all start). You can read up on our applications and SOP at infrastructure.fedoraproject.org/infra/docs. A good first read is our SSH access SOP. We use ansible for configuration management. If you are not familiar with ansible, please also take some time to read the docs at http://ansible.docs.com Regards, Zach #aikidouke ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Meeting Agenda Item: Introduction Ales Petrovicky
On Wed, 18 Nov 2015 22:43:45 +0100 Aleš Petrovický wrote: > Hello Fedora Admins, > my name is Ales Petrovicky and Iam from Czech Republic. Iam working as > System administrator for group of hoding companies. My favourite > distributions are Redhat Enterprise Linux and its derivates. Iam using > Fedora at my notebook and desktop computer. My passion is high > availability, load balancing, clusters, security, performance tunning > and learning about new technologies and software. > > I would like to help community with my experiences in system > administration to make Fedora systems running as best as posible with > minimal or none outage. Also improve my admin skills, learn something > new, improve my language skills, meet new people and share knowledge > and problems with them. > > What skills I can offer? > I will try to describe shortly: DNS, web servers (especialy Nginx and > Apache), Load balancers (like Haproxy, Keepalived+LVS,...), > virtualization (OpenVZ, Libvirt, Qemu,...) with high availability, > RHCS (rgmanager and pacemaker), Kubernetes, Docker, Storage systems > like NetApp, Ceph, databases (Mysql/MariDB, Galera Cluster, percona > tools, Firebird), monitoring (Zabbix, Nagios), orchestration > (Saltstack, now Iam reading about Ansible), VPN servers (OpenVPN, > IPSec), Filesystems, snapshots and partitioning, Firewalling > (Iptables, Firewalld, BSD Packet Filter), OpenBSD as router/firewall, > DRBD, basic OpenStack skills, bash scripting and also some programing > skills, especialy PHP, basic knowledge about Java and Python > programming, ...uff maybe something else, but I cant remember about > it now :) > > My new IRC nick is: aldapetr > > Iam looking forward to join Fedora community! Welcome! I already talked with you on IRC and added you to the apprentice group, so this is just a welcome. ;) kevin pgpbVPmagaeJN.pgp Description: OpenPGP digital signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: buildvmhost csi vars patch
Applied. Thanks. kevin pgpv566mSUM8E.pgp Description: OpenPGP digital signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: List of Infrastructure hosts with no CSI vars
Unfortunately, there's some line wrapping issues going on that makes it so git doesn't want to apply. ;( Can you resend as an attachment? kevin pgpx4WwTBgWvN.pgp Description: OpenPGP digital signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: CSI group_vars patch for beaker
Applied, thanks. kevin pgpyPMnrW9jFI.pgp Description: OpenPGP digital signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: added csi vars for buildvm
Applied, thanks. kevin pgpT7JHA83EzH.pgp Description: OpenPGP digital signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: csi vars patch for buildvm-stg
Applied. Thanks. kevin pgp1SF4N7Pjkp.pgp Description: OpenPGP digital signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: List of Infrastructure hosts with no CSI vars
Did my attachment not arrive OK? Trying again. Should I assume the csi vars were OK like that then? Happy to carry on doing more. Great exercise to get to know how the infrastructure is set up Juan On Fri, 2015-11-20 at 11:08 -0700, Kevin Fenzi wrote: > Unfortunately, there's some line wrapping issues going on that makes > it > so git doesn't want to apply. ;( > > Can you resend as an attachment? > > kevincommit 4598da9a56a231d1b65eedfdd867ef5c261b7277 Author: Juan Jimenez-Anca Date: Wed Nov 18 21:58:48 2015 + csi vars for bastion, copr-back, cpr-back-stg, copr-front, copr-front-stg diff --git a/inventory/group_vars/bastion b/inventory/group_vars/bastion index 87a0e33..40733b4 100644 --- a/inventory/group_vars/bastion +++ b/inventory/group_vars/bastion @@ -1,5 +1,5 @@ --- -# Define resources for this group of hosts here. +# Define resources for this group of hosts here. lvm_size: 2 mem_size: 8192 num_cpus: 4 @@ -37,3 +37,16 @@ fas_aliases: true # nrpe_procs_warn: 1100 nrpe_procs_crit: 1200 + +# These variables are pushed into /etc/system_identification by the base role. +# Groups and individual hosts should override them with specific info. +# See http://infrastructure.fedoraproject.org/csi/security-policy/ + +csi_security_category: High +csi_primary_contact: sysadmin-main ad...@fedoraproject.org +csi_purpose: SSH proxy to access infrastructure not exposed to the web +csi_relationship: + * Provides ssh access to all phx2/vpn connected servers. + * Bastion is the hub for all infrastructure's VPN connections. + * All incoming SMTP from phx2 and VPN, as well as outgoing SMTP, pass or are filtered here. + * Bastion does not accept any mail outside phx2/vpn. diff --git a/inventory/group_vars/copr-back b/inventory/group_vars/copr-back index 6d598e4..c2a279f 100644 --- a/inventory/group_vars/copr-back +++ b/inventory/group_vars/copr-back @@ -20,3 +20,14 @@ do_sign: "true" spawn_in_advance: "true" frontend_base_url: "https://copr-fe.cloud.fedoraproject.org"; + +# These variables are pushed into /etc/system_identification by the base role. +# Groups and individual hosts should override them with specific info. +# See http://infrastructure.fedoraproject.org/csi/security-policy/ + +csi_security_category: High +csi_primary_contact: msuchy (mirek, vgologuz) | IRC: #fedora-admin, #fedora-buildsys +csi_purpose: Provide the backend for copr (3rd party packages) +csi_relationship: + * Backend: Management of copr cloud infrastructure (OpenStack). + * Small frontend with copr's public stats diff --git a/inventory/group_vars/copr-back-stg b/inventory/group_vars/copr-back-stg index 7c0fb6a..42ac9fa 100644 --- a/inventory/group_vars/copr-back-stg +++ b/inventory/group_vars/copr-back-stg @@ -18,3 +18,12 @@ do_sign: "true" spawn_in_advance: "false" frontend_base_url: "http://copr-fe-dev.cloud.fedoraproject.org"; + +# These variables are pushed into /etc/system_identification by the base role. +# Groups and individual hosts should override them with specific info. +# See http://infrastructure.fedoraproject.org/csi/security-policy/ + +csi_security_category: Moderate +csi_primary_contact: msuchy (mirek, vgologuz) | IRC: #fedora-admin, #fedora-buildsys +csi_purpose: Provide the testing environment of copr's backend +csi_relationship: This host is the testing environment for the cloud infrastructure of copr's backend diff --git a/inventory/group_vars/copr-front b/inventory/group_vars/copr-front index 7dcfcd7..628ab78 100644 --- a/inventory/group_vars/copr-front +++ b/inventory/group_vars/copr-front @@ -1,3 +1,14 @@ --- copr_hostname: "copr-fe.cloud.fedoraproject.org" copr_frontend_public_hostname: "copr.fedoraproject.org" + +# These variables are pushed into /etc/system_identification by the base role. +# Groups and individual hosts should override them with specific info. +# See http://infrastructure.fedoraproject.org/csi/security-policy/ + +csi_security_category: Moderate +csi_primary_contact: msuchy (mirek, vgologuz) | IRC: #fedora-admin, #fedora-buildsys +csi_purpose: Provide a publicly accessible frontend for 3rd party packages (copr) +csi_relationship: + * This host provides the frontend part of copr only. + * It's the point of contact between end users and the copr build system (backend, package singer) diff --git a/inventory/group_vars/copr-front-stg b/inventory/group_vars/copr-front-stg index 835a21a..e12e6e2 100644 --- a/inventory/group_vars/copr-front-stg +++ b/inventory/group_vars/copr-front-stg @@ -1,2 +1,7 @@ --- copr_frontend_public_hostname: "copr-fe-dev.cloud.fedoraproject.org" + +csi_security_category: Low +csi_primary_contact: msuchy (mirek, vgologuz) | IRC: #fedora-admin, #fedora-buildsys +csi_purpose: Provide the testing environment of copr's frontend +csi_relationship: This host is the testing environment for copr's web interface ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedorapr
Re: List of Infrastructure hosts with no CSI vars
On Fri, 20 Nov 2015 19:16:46 + Juan Jimenez-Anca wrote: > Did my attachment not arrive OK? Trying again. > Should I assume the csi vars were OK like that then? Happy to carry on > doing more. Great exercise to get to know how the infrastructure is > set up That worked. Something in the previous send wasn't happy with whitespace. ;) kevin -- > Juan > On Fri, 2015-11-20 at 11:08 -0700, Kevin Fenzi wrote: > > Unfortunately, there's some line wrapping issues going on that makes > > it > > so git doesn't want to apply. ;( > > > > Can you resend as an attachment? > > > > kevin pgpLSjLqlwcx7.pgp Description: OpenPGP digital signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Some notes on CSI variables
Just some quick notes on CSI variables as may people are submitting them. ;) They can't contain : in them as thats used as a variable seperator. If you want to do multiple lines, thats ok, but you have to do: variablename: | one two three (the | is important there, it tells jinja that there's mutiple lines there). Also, you can't use * in the multiline ones, use - instead as a bullet). Thanks, kevin pgpvhDTOuBvL_.pgp Description: OpenPGP digital signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Some notes on CSI variables
Noted. In triplicate. :) On Fri, 2015-11-20 at 13:42 -0700, Kevin Fenzi wrote: > Just some quick notes on CSI variables as may people are submitting > them. ;) > > They can't contain : in them as thats used as a variable seperator. > > If you want to do multiple lines, thats ok, but you have to do: > > variablename: | > one > two > three > > (the | is important there, it tells jinja that there's mutiple lines > there). > > Also, you can't use * in the multiline ones, use - instead as a > bullet). > > Thanks, > > kevin > ___ > infrastructure mailing list > infrastructure@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedor > aproject.org ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: group_vars csi patch for virthost_ updated
Updated in light of Kevin's oh so timely gentle nudge. ;) Preserved copy attached. Nasty whitspace... Odin, Destroyer of Ice Giants. --- virthost.orig 2015-11-19 13:18:42.781783307 -0500 +++ virthost 2015-11-20 16:38:13.350610366 -0500 @@ -1,5 +1,5 @@ - -scsi initiator for netapp iscsi volume +--- +# iscsi initiator for netapp iscsi volume netapp_nfs01_iscsi_name: iqn.1992- 08.com.netapp:sn.1573980325:vf.f88732f4-106e-11e2-bc86-00a098162 a28 # iscsi portal for netapp iscsi volume netapp_nfs01_iscsi_portal: 10.5.88.36 @@ -8,3 +8,15 @@ nrpe_procs_warn: 900 nrpe_procs_crit: 1000 + +# These variables are pushed into /etc/system_identification by the base role. +# Groups and individual hosts should override them with specific info. +# See http://infrastructure.fedoraproject.org/csi/security-policy/ + +csi_security_category: High +csi_primary_contact: Fedora Admins - ad...@fedoraproject.org +csi_purpose: Host guest virtual machines. +csi_relationship: | + - Guests on this host will be inaccessible if the host is down. + - This host will be required by any application with a virtual machine running on it, therefore , if this host is down those applications will be impacted. "virthost.patch" [readonly] 26L, 1071C On Thu, 2015-11-19 at 13:28 -0500, David Shier wrote: > Below and attached is a patch to add group vars for csi compliance > for virthost. As I did not find much in the way of documentation, and > cannot currently log on to any of the virthost servers I have left > them pretty general. > > - virthost.orig 2015-11-19 13:18:42.781783307 -0500 > +++ virthost 2015-11-19 13:18:18.305474418 -0500 > @@ -1,5 +1,5 @@ > - > -scsi initiator for netapp iscsi volume > +--- > +# iscsi initiator for netapp iscsi volume > netapp_nfs01_iscsi_name: iqn.1992- > 08.com.netapp:sn.1573980325:vf.f88732f4-106e-1 > 1e2-bc86-00a098162a28 > # iscsi portal for netapp iscsi volume > netapp_nfs01_iscsi_portal: 10.5.88.36 > @@ -8,3 +8,15 @@ > nrpe_procs_warn: 900 > nrpe_procs_crit: 1000 > > + > +# These variables are pushed into /etc/system_identification by the > base role. > +# Groups and individual hosts should override them with specific > info. > +# See http://infrastructure.fedoraproject.org/csi/security-policy/ > + > +csi_security_category: High > +csi_primary_contact: Fedora Admins - ad...@fedoraproject.org > +csi_purpose: Host guest virtual machines. > +csi_relationship: | > + * Guests on this host will be inaccessible if the host is down. > + * This host will be required by any application with a virtual > machine running on it, therefore, if this host is down those > applications will be impacted. > + > > > --- > Dave Shier > --- virthost.orig 2015-11-19 13:18:42.781783307 -0500 +++ virthost 2015-11-20 16:38:13.350610366 -0500 @@ -1,5 +1,5 @@ - -scsi initiator for netapp iscsi volume +--- +# iscsi initiator for netapp iscsi volume netapp_nfs01_iscsi_name: iqn.1992-08.com.netapp:sn.1573980325:vf.f88732f4-106e-11e2-bc86-00a098162a28 # iscsi portal for netapp iscsi volume netapp_nfs01_iscsi_portal: 10.5.88.36 @@ -8,3 +8,15 @@ nrpe_procs_warn: 900 nrpe_procs_crit: 1000 + +# These variables are pushed into /etc/system_identification by the base role. +# Groups and individual hosts should override them with specific info. +# See http://infrastructure.fedoraproject.org/csi/security-policy/ + +csi_security_category: High +csi_primary_contact: Fedora Admins - ad...@fedoraproject.org +csi_purpose: Host guest virtual machines. +csi_relationship: | + - Guests on this host will be inaccessible if the host is down. + - This host will be required by any application with a virtual machine running on it, therefore, if this host is down those applications will be impacted. + ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
