Support levels and RFR adjustments
by Kevin Fenzi
So, I sent an email a while back about this to get people thinking, but
I didn't get too much feedback from my questions, so this time I am
going to actually outline a proposal for people to look at. ;)
Currently users expect pretty much any public service we have is fully
supported. This means things like updating status when it's down,
working anytime something is down to fix it as quickly as we can.
New applications/services currently all pass through the (somewhat
long) RFR process which we setup to make sure we could support the
service moving forward.
This is great and all, but some services just aren't as sustainable, or
don't really fit into our RFR process very well. Also, our RFR process
makes us pretty slow to bring a new service online properly.
In order to have support levels, we need a way to communicate that to
our users easily and the only/best way I can think of to do that easily
is via domain name. If we try and have a table or something it could
get pretty confusing for people. Tying it to domain names would make it
much easier.
So:
fedoraproject.org - Anything with this domain is something that has
passed though our RFR process and we support fully. This means we
update status, we alert on them anytime they have issues, we work on
them anytime they are down, etc.
fedorainfracloud.org - This comes with a lesser level of support,
simply because our cloud doesn't have any kind of HA setup, so
it will be down when doing maint or when there's problems. Services in
this domain may be down when there is scheduled cloud maint. We
monitor, but don't page off hours, we may work on issues only during
business hours, etc. Services here may not have passed through our RFR
process (perhaps we should have a parallel cloud process)
stg.fedoraproject.org - These can be down anytime and we monitor on
them, but may not work on them off hours, etc.
someother domain that sounds fedora related (fedorarelated.org?
fedoralinks.org? ?) - These are things that are fedora related, but not
fully controlled by fedora infrastructure. Things like the fedora
bootstrap site or the porting python3 in fedora site, or possibly cloud
instances that aren't managed by us. These we don't monitor or have
status on, and direct people to contact the managers directly.
Any other types of sites / domains people can think of?
Any general thoughts on the idea?
kevin
7 years, 5 months
Meeting Agenda Item: Introduction Ganesh Kadam
by Ganesh Kadam
"Hello World!"
1. Your IRC handle : gkadam
2. Skills you have : Basic knowledge about - Linux Administration,Nagios-Core, Python and Bash Scripting
3. Skills you want to learn : System Administration skills,Networking,Configuration Management with Ansible, Programming
4. What you wanna learn, any initial questions you have : I want to learn System Administration skills and also would like to document systems in fedora infra if required. I would like to learn how fedora-infra works internally.What else do i need to contribute in #fedora-infra?
7 years, 6 months
Bugzilla+fedmsg, 2016-03-29
by Ralph Bean
There's a Bugzilla outage scheduled for 00:00 2016-03-29 UTC.
If everything goes to plan, bugzilla should start transmitting
messages about changes to bug tickets shortly after this outage is
complete. We have a mediator service running and ready that should
receive those and rebroadcast them to our fedmsg bus.
Please keep party streamers and confetti on standby.
7 years, 6 months
Plan for tomorrow's Fedora Infrastructure meeting - 2016-03-31
by Kevin Fenzi
The infrastructure team will be having it's weekly meeting tomorrow,
2016-03-31 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-03-31)
#meetingname infrastructure
#topic aloha
#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 Bugzilla messages are now live on our fedmsg bus! - threebean
#info Fedora 24 Alpha was released tuesday (2016-03-29) - everyone
#info New calendar for modularity effort - kevin
#info Feedback in ask now goes in ask questions with meta tag - kevin
#info Lots of small ansible changes pushed out after freeze - kevin
#info db-koji01 still under heavy load for some reason - 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)
#topic badges-backend cron jobs - aikidouke
#info https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
#topic fedmsg from bugzilla brainstorming session - kevin / threebean
#topic
= 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-03-31 - RFR - patrick
#topic Learn about:
= Meeting end stuff =
#topic Open Floor
#endmeeting
7 years, 6 months
Fedora 24 Alpha Freeze now in effect
by Kevin Fenzi
Greetings.
we are now in the infrastructure freeze leading up to the Fedora 24
Alpha release. This is a pre-release freeze.
We do this to ensure that our infrastructure is stable and ready to
release the Fedora 24 Alpha 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-03-22 (or later if
Alpha 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.
Thanks,
kevin
7 years, 6 months
[PATCH] Move varnish, keepalived and infinoted handlers to their role
by Michael Scherer
From: Michael Scherer <misc(a)redhat.com>
---
handlers/restart_services.yml | 9 ---------
roles/infinote/handlers/main.yml | 2 ++
roles/keepalived/handlers/main.yml | 2 ++
3 files changed, 4 insertions(+), 9 deletions(-)
create mode 100644 roles/infinote/handlers/main.yml
create mode 100644 roles/keepalived/handlers/main.yml
diff --git a/handlers/restart_services.yml b/handlers/restart_services.yml
index 940e114..4cfb41e 100644
--- a/handlers/restart_services.yml
+++ b/handlers/restart_services.yml
@@ -167,12 +167,6 @@
- name: restart haproxy
service: name=haproxy state=restarted
-- name: restart varnish
- service: name=varnish state=restarted
-
-- name: restart keepalived
- service: name=keepalived state=restarted
-
- name: restart mariadb
service: name=mariadb state=restarted
@@ -196,9 +190,6 @@
- name: restart autocloud
service: name=autocloud state=restarted
-- name: restart infinoted
- service: name=infinoted state=restarted
-
- name: restart mirrorlist-server
service: name=mirrorlist-server state=restarted
diff --git a/roles/infinote/handlers/main.yml b/roles/infinote/handlers/main.yml
new file mode 100644
index 0000000..55133ec
--- /dev/null
+++ b/roles/infinote/handlers/main.yml
@@ -0,0 +1,2 @@
+- name: restart infinoted
+ service: name=infinoted state=restarted
diff --git a/roles/keepalived/handlers/main.yml b/roles/keepalived/handlers/main.yml
new file mode 100644
index 0000000..3840e64
--- /dev/null
+++ b/roles/keepalived/handlers/main.yml
@@ -0,0 +1,2 @@
+- name: restart keepalived
+ service: name=keepalived state=restarted
--
1.8.3.1
7 years, 6 months
[PATCH] Use a file instead of a command for removing postfix pid
by Michael Scherer
From: Michael Scherer <misc(a)zarb.org>
Avoid a uneeded fork, and avoid repeating the filename
---
playbooks/death_to_postfix.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/playbooks/death_to_postfix.yml b/playbooks/death_to_postfix.yml
index 46a1f33..8e0c2a8 100644
--- a/playbooks/death_to_postfix.yml
+++ b/playbooks/death_to_postfix.yml
@@ -15,7 +15,7 @@
command: pkill -u root master removes=/var/spool/postfix/pid/master.pid
- name: Clean up old pid lock file.
- command: rm /var/spool/postfix/pid/master.pid removes=/var/spool/postfix/pid/master.pid
+ file: name=/var/spool/postfix/pid/master.pid state=absent
- name: Try to start postfix cleanly
service: name=postfix state=started
--
1.8.3.1
7 years, 6 months
[PATCH] Remove old file from some openshift v2 deployment
by Michael Scherer
From: Michael Scherer <misc(a)redhat.com>
Nothing seems to use them in the current repo
---
files/openshift/Gemfile | 50 -------------------
files/openshift/jenkins.repo | 5 --
files/openshift/mcollective-client.cfg | 18 -------
files/openshift/mongo-acct.sh | 7 ---
files/openshift/mongodb.conf | 91 ----------------------------------
files/openshift/openshift-el6.repo | 5 --
files/openshift/qpidd.conf | 3 --
7 files changed, 179 deletions(-)
delete mode 100644 files/openshift/Gemfile
delete mode 100644 files/openshift/jenkins.repo
delete mode 100644 files/openshift/mcollective-client.cfg
delete mode 100644 files/openshift/mongo-acct.sh
delete mode 100644 files/openshift/mongodb.conf
delete mode 100644 files/openshift/openshift-el6.repo
delete mode 100644 files/openshift/qpidd.conf
diff --git a/files/openshift/Gemfile b/files/openshift/Gemfile
deleted file mode 100644
index 1a8a788..0000000
--- a/files/openshift/Gemfile
+++ /dev/null
@@ -1,50 +0,0 @@
-source 'http://rubygems.org'
-
-gem 'rails', '~> 3.0.13'
-gem 'json'
-gem 'parseconfig'
-gem 'mongo'
-gem 'xml-simple'
-gem 'rack'
-gem 'regin'
-gem 'open4'
-gem 'stickshift-common'
-gem 'stickshift-controller'
-gem 'rest-client'
-gem 'systemu'
-
-# Add plugin gems here
-gem 'gearchanger-mcollective-plugin'
-gem 'uplift-bind-plugin'
-gem 'swingshift-mongo-plugin'
-gem 'dnsruby'
-
-# Bundle edge Rails instead:
-# gem 'rails', :git => 'git://github.com/rails/rails.git'
-
-# Use unicorn as the web server
-# gem 'unicorn'
-
-# Deploy with Capistrano
-# gem 'capistrano'
-
-# To use debugger (ruby-debug for Ruby 1.8.7+, ruby-debug19 for Ruby 1.9.2+)
-# gem 'ruby-debug'
-# gem 'ruby-debug19', :require => 'ruby-debug'
-
-# Bundle the extra gems:
-# gem 'bj'
-# gem 'nokogiri'
-# gem 'sqlite3-ruby', :require => 'sqlite3'
-# gem 'aws-s3', :require => 'aws/s3'
-
-# Bundle gems for the local environment. Make sure to
-# put test-only gems in this group so their generators
-# and rake tasks are available in development mode:
-group :development, :test do
- # The require part from http://tinyurl.com/3pf68ho
- gem 'mocha', :require => nil
- gem 'cucumber'
- gem 'rcov'
-end
-
diff --git a/files/openshift/jenkins.repo b/files/openshift/jenkins.repo
deleted file mode 100644
index 5ab0572..0000000
--- a/files/openshift/jenkins.repo
+++ /dev/null
@@ -1,5 +0,0 @@
-[jenkins]
-name=Jenkins
-baseurl=http://pkg.jenkins-ci.org/redhat
-gpgcheck=1
-gpgkey=http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
diff --git a/files/openshift/mcollective-client.cfg b/files/openshift/mcollective-client.cfg
deleted file mode 100644
index 3e8a44f..0000000
--- a/files/openshift/mcollective-client.cfg
+++ /dev/null
@@ -1,18 +0,0 @@
-topicprefix = /topic/
-main_collective = mcollective
-collectives = mcollective
-libdir = /usr/libexec/mcollective
-loglevel = debug
-logfile = /var/log/mcollective-client.log
-
-# Plugins
-securityprovider = psk
-plugin.psk = unset
-connector = qpid
-plugin.qpid.host=127.0.0.1
-plugin.qpid.secure=false
-plugin.qpid.timeout=5
-
-# Facts
-factsource = yaml
-plugin.yaml = /etc/mcollective/facts.yaml
\ No newline at end of file
diff --git a/files/openshift/mongo-acct.sh b/files/openshift/mongo-acct.sh
deleted file mode 100644
index 15e8973..0000000
--- a/files/openshift/mongo-acct.sh
+++ /dev/null
@@ -1,7 +0,0 @@
-#!/bin/bash
-mongo stickshift_broker_dev --eval 'db.addUser("stickshift", "mooo")'
-mongo stickshift_broker_dev --eval 'db.auth_user.update({"_id":"admin"}, {"_id":"admin","user":"admin","password":"2a8462d93a13e51387a5e607cbd1139f"} , true)'
-echo "Acct setup done on `date`" > /etc/mongo-acct-setup
-
-
-
\ No newline at end of file
diff --git a/files/openshift/mongodb.conf b/files/openshift/mongodb.conf
deleted file mode 100644
index b983014..0000000
--- a/files/openshift/mongodb.conf
+++ /dev/null
@@ -1,91 +0,0 @@
-##
-### Basic Defaults
-##
-bind_ip = 127.0.0.1
-port = 27017
-fork = true
-pidfilepath = /var/run/mongodb/mongodb.pid
-logpath = /var/log/mongodb/mongodb.log
-dbpath =/var/lib/mongodb
-journal = true
-
-# Enables periodic logging of CPU utilization and I/O wait
-#cpu = true
-
-# Turn on/off security. Off is currently the default
-#noauth = true
-auth = true
-
-# Verbose logging output.
-#verbose = true
-
-# Inspect all client data for validity on receipt (useful for
-# developing drivers)
-#objcheck = true
-
-# Enable db quota management
-#quota = true
-
-# Set oplogging level where n is
-# 0=off (default)
-# 1=W
-# 2=R
-# 3=both
-# 7=W+some reads
-#oplog = 0
-
-# Diagnostic/debugging option
-#nocursors = true
-
-# Ignore query hints
-#nohints = true
-
-# Disable the HTTP interface (Defaults to port+1000).
-nohttpinterface = true
-
-# Turns off server-side scripting. This will result in greatly limited
-# functionality
-#noscripting = true
-
-# Turns off table scans. Any query that would do a table scan fails.
-#notablescan = true
-
-# Disable data file preallocation.
-#noprealloc = true
-
-# Specify .ns file size for new databases.
-# nssize = <size>
-
-# Accout token for Mongo monitoring server.
-#mms-token = <token>
-
-# Server name for Mongo monitoring server.
-#mms-name = <server-name>
-
-# Ping interval for Mongo monitoring server.
-#mms-interval = <seconds>
-
-# Replication Options
-
-# in replicated mongo databases, specify here whether this is a slave or master
-#slave = true
-#source = master.example.com
-# Slave only: specify a single database to replicate
-#only = master.example.com
-# or
-#master = true
-#source = slave.example.com
-
-# Address of a server to pair with.
-#pairwith = <server:port>
-# Address of arbiter server.
-#arbiter = <server:port>
-# Automatically resync if slave data is stale
-#autoresync
-# Custom size for replication operation log.
-#oplogSize = <MB>
-# Size limit for in-memory storage of op ids.
-#opIdMem = <bytes>
-
-# smallfiles
-smallfiles = true
\ No newline at end of file
diff --git a/files/openshift/openshift-el6.repo b/files/openshift/openshift-el6.repo
deleted file mode 100644
index 87e34a7..0000000
--- a/files/openshift/openshift-el6.repo
+++ /dev/null
@@ -1,5 +0,0 @@
-[openshift]
-name=OpenShift
-baseurl=http://mirror.openshift.com/pub/crankcase/rhel-6/x86_64/
-enabled=1
-gpgcheck=0
diff --git a/files/openshift/qpidd.conf b/files/openshift/qpidd.conf
deleted file mode 100644
index be2e0b8..0000000
--- a/files/openshift/qpidd.conf
+++ /dev/null
@@ -1,3 +0,0 @@
-cluster-mechanism=DIGEST-MD5 ANONYMOUS
-auth=no
-
--
1.8.3.1
7 years, 6 months
ask.fp.o feedback link and emails
by Alick Zhao
Hi all,
As an ask.fp.o moderator, I occasionally received emails from its
feedback link, and I believe other moderators should experience the
same. It seems like the emails are mostly asking questions, especially
on login issues. However, I do not know the answers, and even if I
know, there is no way to reply the questioner since the email came
from nobody(a)fp.o ... In my mind, it is better to change the feedback
link to something that directs the user to mailing list or IRC, so
that it is more likely to be answered. Any idea?
--
Regards,
Alick
7 years, 6 months