<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title type="text">Markus's Brain Swap Space</title>
  <id>http://www.markusz.io/posts/atom.xml</id>
  <updated>2022-01-16T00:00:00Z</updated>
  <link href="http://www.markusz.io/" />
  <link href="http://www.markusz.io/posts/atom.xml" rel="self" />
  <generator uri="http://ablog.readthedocs.org" version="0.8.4">ABlog</generator>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Command Hooks with the zsh Shell</title>
    <id>http://www.markusz.io/posts/2022/01/16/zsh-command-hooks/</id>
    <updated>2022-01-16T00:00:00Z</updated>
    <published>2022-01-16T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2022/01/16/zsh-command-hooks/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;This post shows a small example how command hooks of the &lt;em&gt;zsh&lt;/em&gt; shell can be used to print
timestamps before and after a command execution. This can be helpful in postmortems of
operations when it can be important to know exactly when you&amp;#8217;ve seen a specific output or how
long a command took.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Elastic Stack (formerly ELK) - Kibana (part 1)</title>
    <id>http://www.markusz.io/posts/2018/05/25/elastic-stack-elk-kibana-part1/</id>
    <updated>2018-05-25T00:00:00Z</updated>
    <published>2018-05-25T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/05/25/elastic-stack-elk-kibana-part1/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;&lt;em&gt;Kibana&lt;/em&gt; is the web UI to visualize data in the data store called &lt;em&gt;Elasticsearch&lt;/em&gt;.
It&amp;#8217;s the user facing component in the &lt;em&gt;Elastic Stack&lt;/em&gt;, formerly called
ELK stack. This post is based on previous posts which show the basics
of &lt;em&gt;Logstash&lt;/em&gt; and &lt;em&gt;Elasticsearch&lt;/em&gt; and will talk about a few ways how &lt;em&gt;Kibana&lt;/em&gt; can help you
make sense out of your logs.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">The 2018 KubeCon and CloudNativeCon in Copenhagen, Denmark</title>
    <id>http://www.markusz.io/posts/2018/05/11/cncf-kubecon-2018-CPH/</id>
    <updated>2018-05-11T00:00:00Z</updated>
    <published>2018-05-11T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/05/11/cncf-kubecon-2018-CPH/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;This post is my recap of the &lt;em&gt;KubeCon and CloudNativeCon&lt;/em&gt; conference which
took place in &lt;em&gt;Copenhagen (Denmark)&lt;/em&gt; from May 1-4, 2018. I&amp;#8217;ll go
briefly through the sessions I attended and the notes I took.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Ubuntu with Debian Sid APT repository</title>
    <id>http://www.markusz.io/posts/2018/04/27/ubuntu-debian-repo-pinning/</id>
    <updated>2018-04-27T00:00:00Z</updated>
    <published>2018-04-27T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/04/27/ubuntu-debian-repo-pinning/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;Ubuntu is great in my opinion, and of the reasons for it is its use of
recent versions for the packages in their APT repositories. But what if
you need a package in an even more recent version and cannot wait for the
next release? The Debian Sid release, the unstable development version, has
those newer packages and they can be used in an Ubuntu with the help of
APT package pinning and this post shows the things you need to know for that.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Learning Go (part 1) - Conway's Game of Life</title>
    <id>http://www.markusz.io/posts/2018/04/13/go-part1-game-of-life/</id>
    <updated>2018-04-13T00:00:00Z</updated>
    <published>2018-04-13T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/04/13/go-part1-game-of-life/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;The &lt;em&gt;Go&lt;/em&gt; programming language is currently fashionable, and it&amp;#8217;s been four
years since the last time I started to learn a new programming language
(&lt;em&gt;Python&lt;/em&gt;), so I decided to start a series about my learning attempts.
As I also want to know more about &lt;em&gt;Kubernetes&lt;/em&gt;, my goal is to
learn enough &lt;em&gt;Go&lt;/em&gt; in the next few months to read the &lt;em&gt;Kubernetes&lt;/em&gt; code base
comfortably. As a starting point for this multi-part series, I&amp;#8217;ve chosen
&lt;em&gt;Conway&amp;#8217;s Game of Life&lt;/em&gt; &lt;a class=&quot;footnote-reference&quot; href=&quot;#cgol&quot; id=&quot;id1&quot;&gt;[1]&lt;/a&gt;, because its rules are simple but more
complex than a typical &lt;em&gt;hello world&lt;/em&gt; example.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Quick Tip: Ansible target hosts with wildcard</title>
    <id>http://www.markusz.io/posts/2018/03/30/ansible-hosts-wildcard/</id>
    <updated>2018-03-30T00:00:00Z</updated>
    <published>2018-03-30T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/03/30/ansible-hosts-wildcard/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;This is a short quick tip about &lt;em&gt;Ansible&lt;/em&gt;. TL;DR: it&amp;#8217;s possible to use a
wildcard in the target hosts specifier. This became useful to me when I
dynamically created the inventory based on &lt;em&gt;Ansible&lt;/em&gt; facts.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">HTML5 slides with Reveal.js, Markdown and Docker</title>
    <id>http://www.markusz.io/posts/2018/03/16/revealjs-docker-markdown-slides/</id>
    <updated>2018-03-19T00:00:00Z</updated>
    <published>2018-03-16T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/03/16/revealjs-docker-markdown-slides/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;Presentation slides. They can be a great tool for communicating ideas
to others. I was looking for a way to create slide decks where I can
specify the content as plain text and have it separate to the rendering.
I&amp;#8217;m sure this is somehow possible with &lt;em&gt;PowerPoint&lt;/em&gt; or &lt;em&gt;OpenOffice&lt;/em&gt;,
but I didn&amp;#8217;t bother to look for it. This post shows how I specify the
content in a &lt;em&gt;Markdown&lt;/em&gt; file and let it render by &lt;em&gt;Reveal.js&lt;/em&gt; which
I packed into a &lt;em&gt;Docker&lt;/em&gt; image.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Elastic Stack (formerly ELK) - Logstash (Part 2)</title>
    <id>http://www.markusz.io/posts/2018/03/02/elastic-stack-elk-logstash-part2/</id>
    <updated>2018-03-02T00:00:00Z</updated>
    <published>2018-03-02T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/03/02/elastic-stack-elk-logstash-part2/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;This is a follow-up to the previous post
&lt;a class=&quot;reference internal&quot; href=&quot;2018/02/16/elastic-stack-elk-logstash-part1/#elastic-stack-elk-logstash-part1&quot;&gt;&lt;span class=&quot;std std-ref&quot;&gt;Elastic Stack (formerly ELK) - Logstash (Part 1)&lt;/span&gt;&lt;/a&gt;.
We continue were we left of the last time, and dive right into it.
No intro, no explanation of concepts or terms, only configuration of
&lt;em&gt;Logstash&lt;/em&gt; pipelines.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Elastic Stack (formerly ELK) - Logstash (Part 1)</title>
    <id>http://www.markusz.io/posts/2018/02/16/elastic-stack-elk-logstash-part1/</id>
    <updated>2018-02-16T00:00:00Z</updated>
    <published>2018-02-16T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/02/16/elastic-stack-elk-logstash-part1/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;In this post I&amp;#8217;ll talk about the &lt;em&gt;Logstash&lt;/em&gt; service, which is part of the
&lt;em&gt;Elastic Stack&lt;/em&gt;, formerly known as &lt;em&gt;ELK&lt;/em&gt; stack. The purpose of &lt;em&gt;Logstash&lt;/em&gt; is to
ingest (logging) data, do some transformation or filtering on it,
and output it into a data store like &lt;em&gt;Elasticsearch&lt;/em&gt;. For details about &lt;em&gt;Elasticsearch&lt;/em&gt;, you
can get more information in my previous post
&lt;a class=&quot;reference internal&quot; href=&quot;2018/01/05/elastic-stack-elk-elasticsearch/#elastic-stack-elk-elasticsearch&quot;&gt;&lt;span class=&quot;std std-ref&quot;&gt;Elastic Stack (formerly ELK) - Elasticsearch&lt;/span&gt;&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Project documentation with reStructuredText and Sphinx</title>
    <id>http://www.markusz.io/posts/2018/02/02/project-docs-rst-markup-sphinx/</id>
    <updated>2018-02-02T00:00:00Z</updated>
    <published>2018-02-02T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/02/02/project-docs-rst-markup-sphinx/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;When it comes to documenting your project, especially the non-code parts,
you might face a plethora of opinions what the &amp;#8220;correct approach&amp;#8221; might be.
Some love &lt;em&gt;Word&lt;/em&gt; documents, some favor &lt;em&gt;PowerPoint&lt;/em&gt; slides and some like
documents written in a markup language. I&amp;#8217;m one of the latter. This post
will show my favorite, &lt;em&gt;reStructuredText&lt;/em&gt; with &lt;em&gt;Sphinx&lt;/em&gt;. It will list the capabilities I
usually need when documenting, and how to do it with the features of &lt;em&gt;Sphinx&lt;/em&gt;
and &lt;em&gt;reStructuredText&lt;/em&gt;.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Quick Tip: Ansible commands as non-root user with environment variables</title>
    <id>http://www.markusz.io/posts/2018/01/19/ansible-env-var-non-root/</id>
    <updated>2018-01-19T00:00:00Z</updated>
    <published>2018-01-19T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/01/19/ansible-env-var-non-root/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;This is a short quick tip. When executing &lt;em&gt;Ansible&lt;/em&gt; playbooks, you might
need to execute a task as another user than the one you established the
connection with. This post shows an example how to do it and deal with
the environment variables.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Elastic Stack (formerly ELK) - Elasticsearch</title>
    <id>http://www.markusz.io/posts/2018/01/05/elastic-stack-elk-elasticsearch/</id>
    <updated>2018-01-05T00:00:00Z</updated>
    <published>2018-01-05T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2018/01/05/elastic-stack-elk-elasticsearch/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;When something goes wrong in an environment, the people trying to fix it
mostly start by looking at the log files persisted on the local filesystem
of the server. This gets more cumbersome the more server and services
participate. Highly distributed applications, developed and deployed as
microservices in a cloud environment exacerbate this too. A centralized
logging server helps to ease the pain. In this post I&amp;#8217;ll talk about the
popular &lt;em&gt;Elasticsearch&lt;/em&gt; service, which is part of the &lt;em&gt;Elastic Stack&lt;/em&gt;, formerly known
as &lt;em&gt;ELK&lt;/em&gt; stack.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Release Notes with reno</title>
    <id>http://www.markusz.io/posts/2017/12/22/release-notes-with-reno/</id>
    <updated>2017-12-22T00:00:00Z</updated>
    <published>2017-12-22T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2017/12/22/release-notes-with-reno/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;&lt;em&gt;&amp;#8220;What features merged since the last release?&amp;#8221;&lt;/em&gt; &amp;#8211;
&lt;em&gt;&amp;#8220;Did we introduce something which might break a deployment?&amp;#8221;&lt;/em&gt; &amp;#8211;
&lt;em&gt;&amp;#8220;Let me grep through the commit history to check what happened.&amp;#8221;&lt;/em&gt;
Remember sentences like these when you&amp;#8217;re about to release? If you
like this fire-fighting mode, ignore this post. If you want to have a
more relaxed release, this post will show you how to use a tool called
&lt;em&gt;reno&lt;/em&gt; to manage your release notes.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Recommendation: The Five Dysfunctions of a Team</title>
    <id>http://www.markusz.io/posts/2017/12/08/book-5-team-dysfunctions/</id>
    <updated>2017-12-08T00:00:00Z</updated>
    <published>2017-12-08T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2017/12/08/book-5-team-dysfunctions/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;Did you ever wonder why you&amp;#8217;re (again) in a meeting without a clear result?
Do you feel like the topics got already discussed in a previous meeting?
How often did your hear the sentence &lt;cite&gt;&amp;#8220;Someone should work on that.&amp;#8221;&lt;/cite&gt;?
Let&amp;#8217;s be honest, our work family is sometimes a little dysfunctional.
Join me in my personal reflection of the book
&lt;cite&gt;The Five Dysfunctions of a Team: A Leadership Fable&lt;/cite&gt; from 2002 by
&lt;em&gt;Patrick Lencioni&lt;/em&gt;, which helps to understand what&amp;#8217;s happening.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Ansible Playbook Refactoring into Roles</title>
    <id>http://www.markusz.io/posts/2017/11/24/ansible-playbook-roles/</id>
    <updated>2017-11-24T00:00:00Z</updated>
    <published>2017-11-24T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2017/11/24/ansible-playbook-roles/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;In a previous post (&lt;a class=&quot;reference internal&quot; href=&quot;2017/10/27/monitoring-prometheus/#monitoring-prometheus&quot;&gt;&lt;span class=&quot;std std-ref&quot;&gt;Monitoring with Prometheus&lt;/span&gt;&lt;/a&gt;), we created one playbook
which contained all the logic. This post will show how to do a refactoring of
a playbook into smaller, reusable &lt;em&gt;Ansible Roles&lt;/em&gt;. This allows us to hide
complexity and to provide defined interfaces. It also increases the
ability to work in parallel on different parts of your
&lt;em&gt;Infrastructure as Code (IaC)&lt;/em&gt; project. I won&amp;#8217;t explore how you publish
your roles to &lt;em&gt;Ansible Galaxy&lt;/em&gt; but merely show a basic recipe how you
move &lt;em&gt;Playbook&lt;/em&gt; logic step by step into project specific roles.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">The 2017 Open Source Summit Europe in Praque</title>
    <id>http://www.markusz.io/posts/2017/11/10/osse-prague-2017/</id>
    <updated>2017-11-10T00:00:00Z</updated>
    <published>2017-11-10T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2017/11/10/osse-prague-2017/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;This post is my recap of the &lt;em&gt;Open Source Summit Europe&lt;/em&gt; conference which
took place in &lt;em&gt;Praque (Czech Republic)&lt;/em&gt; from October 23-26, 2017. I&amp;#8217;ll go
briefly through the sessions I attended and the notes I took.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Monitoring with Prometheus</title>
    <id>http://www.markusz.io/posts/2017/10/27/monitoring-prometheus/</id>
    <updated>2017-10-27T00:00:00Z</updated>
    <published>2017-10-27T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2017/10/27/monitoring-prometheus/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;One of the common causes for service degradation or interruption is still
the failure or exhaustion of your basic infrastructure resources.
This post gives you an intro how you can monitor your basic resources
with &lt;em&gt;Prometheus&lt;/em&gt;. It shows the setup with &lt;em&gt;Ansible&lt;/em&gt; and the data visualization
with &lt;em&gt;Grafana&lt;/em&gt;. The post does &lt;strong&gt;not&lt;/strong&gt; show all the capabilities of &lt;em&gt;Prometheus&lt;/em&gt;.
In fact, I&amp;#8217;m showing you only the simplest configuration. The benefit
of this post is, that it takes you from start to finish and gives you
a playground you can easily recreate when things go wrong, thanks to
&lt;em&gt;Vagrant&lt;/em&gt; and &lt;em&gt;VirtualBox&lt;/em&gt;. Beware, as this is a non-trivial (non-hello-world)
example, this post is really long.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Recommendation: The Phoenix Project</title>
    <id>http://www.markusz.io/posts/2017/10/13/book-phoenix-project/</id>
    <updated>2017-10-13T00:00:00Z</updated>
    <published>2017-10-13T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2017/10/13/book-phoenix-project/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;This is my take on the book
&lt;cite&gt;The Phoenix Project: A  Novel about IT, DevOps, and Helping Your Business Win&lt;/cite&gt;
from 2014 by &lt;em&gt;Gene Kim&lt;/em&gt;; &lt;em&gt;Kevin Behr&lt;/em&gt;; &lt;em&gt;George Spafford&lt;/em&gt;. It&amp;#8217;s more of a personal
reflection why I like the book &amp;#8211; and why I think you should read it too &amp;#8211;
and less of a review.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Basics about Logrotate</title>
    <id>http://www.markusz.io/posts/2017/09/29/logrotate/</id>
    <updated>2017-09-29T00:00:00Z</updated>
    <published>2017-09-29T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2017/09/29/logrotate/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;Ever lost a host because one of the services on that host used all
available disk space with its logs? &lt;em&gt;logrotate&lt;/em&gt; is a common tool
which truncates your logs to make sure this won&amp;#8217;t happen anymore.
This post is a short &lt;em&gt;how-to&lt;/em&gt;.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">OpenStack Nova Scheduling based on CPU architecture</title>
    <id>http://www.markusz.io/posts/2017/08/25/openstack-cpu-arch-scheduling/</id>
    <updated>2017-08-25T00:00:00Z</updated>
    <published>2017-08-25T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2017/08/25/openstack-cpu-arch-scheduling/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;If you have an OpenStack cloud with compute nodes with different CPU
architectures, then this post will give you the needed information about
how to tag your guest images, which enables the Nova scheduler to find
a target with the correct CPU architecture.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">Setup Grafana + Graphite + Statsd</title>
    <id>http://www.markusz.io/posts/2016/03/06/grafana-graphite-statsd/</id>
    <updated>2016-03-06T00:00:00Z</updated>
    <published>2016-03-06T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2016/03/06/grafana-graphite-statsd/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;If you ever played around with time series data and wanted to visualize them
with graphs in a nice way you probably have heard about &lt;em&gt;Grafana&lt;/em&gt;. This
post provides a step-by-step instruction on how to build a &lt;em&gt;Grafana&lt;/em&gt;-playground
in about 15 minutes. The setup will be build of &lt;em&gt;statsd&lt;/em&gt; to collect metrics,
&lt;em&gt;graphite&lt;/em&gt; to store those metrics, and &lt;em&gt;Grafana&lt;/em&gt; to visualize those metrics.
We will also create and push custom metrics and create templated graphs based
on them. This post won&amp;#8217;t provide any in-depth details about &lt;em&gt;statsd&lt;/em&gt;,
&lt;em&gt;graphite&lt;/em&gt; and &lt;em&gt;Grafana&lt;/em&gt; itself.&lt;/p&gt;
</content>
  </entry>
  <entry xml:base="http://www.markusz.io/posts/atom.xml">
    <title type="text">OpenStack's Bug Management</title>
    <id>http://www.markusz.io/posts/2015/12/01/openstack-bugs/</id>
    <updated>2015-12-01T00:00:00Z</updated>
    <published>2015-12-01T00:00:00Z</published>
    <link href="http://www.markusz.io/posts/2015/12/01/openstack-bugs/" />
    <author>
      <name>Markus Zoeller</name>
    </author>
    <content type="html">&lt;p&gt;This post intends to give you enough background to play an active part in
working with bugs in &lt;em&gt;OpenStack&lt;/em&gt;. This includes an understanding of the
basic life cycle a bug goes through and in which state you can contribute
in which way. It also clarifies some possible misunderstandings and gives a
few best practices. In general, the bugs of a project (like &lt;em&gt;Nova&lt;/em&gt;, &lt;em&gt;Cinder&lt;/em&gt;,
&lt;em&gt;Neutron&lt;/em&gt; and others) can be found in our issue tracker &lt;em&gt;Launchpad&lt;/em&gt;. The
lists of bugs are available at &lt;code class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;https://bugs.launchpad.net/&amp;lt;projectname&amp;gt;&lt;/span&gt;&lt;/code&gt; for
example &lt;code class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;https://bugs.launchpad.net/nova&lt;/span&gt;&lt;/code&gt; for the &lt;em&gt;Nova&lt;/em&gt; project.&lt;/p&gt;
</content>
  </entry>
</feed>
