Now that we've concluded our migration to git, we also made some changes to our branch naming scheme.

In the Mercurial age, we had two main branches:

• development: the active development branch, used by developers to derive their feature branches from and which was used as the target branch for pull requests.
• default: the branch that nightly release builds and official releases were built from. This branch was updated by merging development into default by Jenkins jobs that performed a wide range of automatic tests against the development branch. Only if these tests had passed, an automatic merge to the default was performed.

During the conversion from Mercurial to git, the default branch was automatically renamed to master, which is the canonical name for the "main" repository branch in git. For most open source projects, the master branch resembles the current line of development, similar to how we used the development branch in Mercurial.

Read more…

If you want to create or modify a oA blog post, then this short introduction will show you how to do this without the need to read howto's about Nikola. You will be able to setup a virtual environment within seconds to avoid polluting your Python installation and your Git repository on your development system.

Read more…

From the very beginning, the openATTIC source code repository was managed using the Mercurial distributed source control management tool.

Our code is hosted on BitBucket which provides for a tight integration with our public Jira issue tracker.

Unfortunately, Mercurial is somewhat less flexible than git when it comes to using branches to separate ongoing development work (which is a workflow encouraged by using Jira/BitBucket) - there is a tight relationship between branch names across repositories and it's impossible to delete branches once they have been created or merged. Sure, we could have probably used Mercurial bookmarks for this, but they are not well supported by the Jira and BitBucket workflows we are using (and are more designed to be used locally, not across multiple repositories).

In addition to that, we have a growing developer/contributor base that simply is more familiar with git than Mercurial nowadays. Switching to git could potentially help us attracting a bigger number of developers.

These were the main reasons for our decision to convert. Thankfully, with the help of the fast-export utility, the actual conversion was straightforward and painless. It automatically renamed the former default branch to master, to be conforming to established git practices. We will revisit the branch naming conventions in a following step.

There was some cleanup work involved afterwards, to remove all the obsolete branches that were created by Mercurial when merging pull requests.

Additionally, all pending pull requests from the previous Mercurial repo had to be re-created, but that provided us with a good opportunity to clean up the commit history before submitting them. Going forward, we intend to also make use of the more advanced features of git like rebasing or squashing change sets, to have a cleaner revision history with less noise.

We're now in the process of updating our documentation and build scripts to support this change, but this should not take us too long to resolve.

A few days ago, I stumbled over an article on Opensource.com about "How to make release notes count".

The article is worth a read - it contains a number of useful suggestions on how to structure the documentation that summarizes the changes that have taken place in a software project's latest release.

Which was excellent timing, as we just merged a major overhaul of our own project's CHANGELOG file (see OP-1911 for details).

We adapted our CHANGELOG based on suggestions made by the Keep a Changelog project, with the exception of using reStructuredText for markup instead of Markdown.

To describe their impact on the project, changes are now grouped as follows:

• Added for new features.
• Changed for changes in existing functionality.
• Deprecated for once-stable features removed in upcoming releases.
• Removed for deprecated features removed in this release.
• Fixed for any bug fixes.
• Security to invite users to upgrade in case of vulnerabilities.

This will hopefully make it easier for our users to get an impression on the changes to expect when updating to a newer version.

How do you like the new structure? Please let us know. Thanks!

We've observed that the update of Nagios from version 4.0.8 to 4.2.4 in EPEL7 is causing some issues for both new openATTIC installations and updates of existing installations on Red Hat Enterprise Linux and derivatives like CentOS.

In this post, we will summarize the issues that affect openATTIC and how to resolve them.

Read more…

This weekend (March 11-12), the Chemnitzer Linuxtage take place again, and it's our great pleasure to attend and represent our project there, this time as a proud member of the growing openSUSE ecosystem.

We'll be showcasing the latest development version of openATTIC, including the latest Ceph management features and a preview of the DRBD mirroring functionality.

In addition to myself, you will be able to meet and talk the following members of the openATTIC team: Kai Wagner (one of the project founders), Volker Theile (maintainer of the OpenMediaVault project and also well-known as one of the early contributors to the FreeNAS project) and Stephan Müller (one of our WebUI developers).

We look forward to the event and good conversations with the general Linux and OSS community. If you are attending CLT, please stop by and say hello!

I could be very annoying to use Thunderbird with multiple folders. Everytime you'll create a new subfolder you have to change the properties and click the checkbox to download all emails to this folder without the need to click on this specific folder every time.

I found a global option which made my life much easier. Just use the config editor (about:config) and change the following entry:

mail.server.default.check_all_folders_for_new -> true

That's it.

For your information, I'll be talking about Ceph and storage management with openATTIC on Wednesday, March 22th at 12:00 EST (19:00 UTC) at the Vault 2017.

Vault brings together the leading developers and users in file systems and storage in the Linux kernel and related projects to forge a path to continued innovation and education.

This presentation will give an overview and update about what has happend in the last year of the development of openATTIC, what has changed since the project has been acquired by SUSE and where we are heading to. A general introduction to openATTIC as well as an outline about new features and impovements to openATTIC with regard to the traditional storage using NFS, CIFS, Samba, iSCSI or FC and distributed storage management and monitoring using Ceph.

Come to my talk and register now to save 20% off your pass with code VLTSP20 - Register

I look forward to see you there!

Now with Ubuntu 16.04 LTS "Xenial" being available since quite some time, we intend to slowly drop Ubuntu 14.04 "Trusty" as a supported platform.

This will allow us to reduce the amount of testing required on our end and also makes it possible to remove support for some "legacy" technologies like SysV init (all other supported distributions are based on systemd now), which will help to simplify the code base.

If you still use openATTIC on Ubuntu Trusty, please consider upgrading your operating system to Ubuntu's latest LTS support in the near future.

If you have any troubles with upgrading openATTIC just contact us.

How to setup a ceph cluster with DeepSea on top of SUSE Leap VMs.

1. Install three VMs and configure "/etc/hosts" -> easiest way to do is to add all nodes in "/etc/hosts" on all VMs. Make sure FQDN are set, too

2. Install "salt-master" on one VM "zypper in salt-master". Enable the service: "systemctl enable salt-master"

3. Install "salt-minion" on ALL VMs "zypper in salt-minion". Enable the service: "systemctl enable salt-minion"

4. Configure "/etc/salt/minion" on all systems to point to the right master and restart minions "systemctl restart salt-minion"

5. Accept keys on the salt-master "salt-key -A -y"

6. Install the build tools on the salt-master VM "zypper in git make"

7. Clone the DeepSea repo "git clone https://github.com/SUSE/DeepSea.git" on the salt-master VM

8. Inside the DeepSea folder run "make install"

9. On the salt master run "systemctl restart salt-master"

10. Run "chown -R salt /srv/pillar/*"

11. Run "salt-run state.orch ceph.stage.0" or "salt-run state.orch ceph.stage.prep"

12. Run "salt-run state.orch ceph.stage.1" or "salt-run state.orch ceph.stage.discovery"

13. Create "/srv/pillar/ceph/proposals/policy.cfg" and run "chown salt:salt /srv/pillar/ceph/proposals/policy.cfg". Example:

    # Cluster assignment
    cluster-ceph/cluster/*.sls
    # Hardware Profile
    profile-*-1/cluster/*.sls
    profile-*-1/stack/default/ceph/minions/*yml
    # Common configuration
    config/stack/default/global.yml
    config/stack/default/ceph/cluster.yml
    # Role assignment
    role-master/cluster/*.sls
    role-mon/cluster/*.sls
    role-mon/stack/default/ceph/minions/*.yml
    

14. Run "salt-run state.orch ceph.stage.2" or "salt-run state.orch ceph.stage.configure"

15. Run "DEV_ENV=true salt-run state.orch ceph.stage.3" or "DEV_ENV=true salt-run state.orch ceph.stage.deploy" -> "DEV_ENV is only needed if you have <=3 VMs"

16. You should change the pg(p)_num to get rid of the "to few pgs per osd" error "ceph osd pool set rbd pg_num 120" and "ceph osd pool set rbd pgp_num 120"

You now should have an up and running cluster.

Now you could add the openATTIC OBS (openSUSE Build Service) repo and install openATTIC and the openattic-deployment package

17. Add the needed Repo from OBS "zypper ar http://download.opensuse.org/repositories/filesystems:/openATTIC/openSUSE_Leap_42.2/filesystems:openATTIC.repo"
18. Install openATTIC "zypper in openattic openattic-module-ceph-deployment" -> you have to break dependencies because deepsea isn't shipped with leap by default
19. Run "chmod 655 /etc/ceph/ceph.*"
20. Run "openattic install"

You're done :)

Update 2017-04-07

• Fixed some typos and added some more steps to do.