Resize disks in a Centos 7 Install

Posted on by
8

The default layout for disks in a Centos deployment may make sense for the average use case, but not for using the machine as a Tripleo all-in-one development box. I have 500 GB of Disk space, and the default installer puts 400GB into /home and 50 GB into /. However, since most of the work here is going to be done in virtual machines, the majority of the /home space is wasted, and I found I have filled up the 50 GB partition on / on a regular basis. So, I want to remove /home and put all the space under /.

Continue reading →

Rippowam

Posted on by
Reply

Ossipee started off as OS-IPA. As it morphed into a tool for building development clusters,I realized it was more useful to split the building of the cluster from the Install and configuration of the application on that cluster. To install IPA and OpenStack, and integrate them together, we now use an ansible-playbook called Rippowam.

Continue reading →

Getting Started with Tripleo

Posted on by
Reply

OpenStack is big. I’ve been focused on my little corner of it, Keystone, for a long time. Now, it is time for me to help out with some of the more downstream aspects of configuring RDO deployments. In order to do so, I need to do an RDO deployment. Until recently, this has meant Packstack. However, Packstack really is not meant for production deployments. RDO manager is the right tool for that. So, I am gearing up on RDO manager. The upstream of RDO Manager is TripleO.
Continue reading →

Translating Between RDO/RHOS and Upstream OpenStack releases

Posted on by
3

There is a straight forward mapping between the version numbers used for Red Hat Enterprise Linux OpenStack Platform release numbers, and the upstream and RDO releases of OpenStack. I can never keep them straight. So, I write code.

UPDATE1: missed Juno before…this is why we code review
UPDATE2: had RDO using the version numbers, but it in sync with upstream.

#!/usr/bin/python
 
upstream = ['Austin', 'Bexar', 'Cactus', 'Diablo', 'Essex', 'Folsom',
            'Grizzly', 'Havana', 'Icehouse', 'Juno', 'Kilo', 'Liberty',
            'Mitaka', 'Newton', 'Ocata', 'Pike', 'Queens', 'Rocky',
            'Stein', 'Train', 'Ussuri', 'V','W','X','Y','Z']
 
for v in range(0, len(upstream) - 3):
    print "RHOS Version %s = upstream %s" % (v, upstream[v + 3])

RHOS Version 0 = upstream Diablo
RHOS Version 1 = upstream Essex
RHOS Version 2 = upstream Folsom
RHOS Version 3 = upstream Grizzly
RHOS Version 4 = upstream Havana
RHOS Version 5 = upstream Icehouse
RHOS Version 6 = upstream Juno
RHOS Version 7 = upstream Kilo
RHOS Version 8 = upstream Liberty
RHOS Version 9 = upstream Mitaka
RHOS Version 10 = upstream Newton
RHOS Version 11 = upstream Ocata
RHOS Version 12 = upstream Pike
RHOS Version 13 = upstream Queens
RHOS Version 14 = upstream Rocky
RHOS Version 15 = upstream Stein
RHOS Version 16 = upstream Train
RHOS Version 17 = upstream Ussuri
RHOS Version 18 = upstream V
RHOS Version 19 = upstream W
RHOS Version 20 = upstream X
RHOS Version 21 = upstream Y
RHOS Version 22 = upstream Z

UPDATE: I’ve edited the list.

Leadership in Software Development Part 3

Posted on by
Reply

Principle #7 Keep Your Team Informed

Communication is the key to any operation. In the Army, they taught that an Infantry Soldier needs to do three things in order to succeed: Shoot, move, and communicate. Well, there should be very little gun fire in open source development, so shooting is less essential. Movement to, since most things happen via network. But communication is paramount. Tell people what you are going to do. A great decision left not communicated is no decision. In the absence of information, people will make assumptions. It is easier to correct mistakes early, and to identify them requires review and correction.

Continue reading →

Leadership in Software Development Part 2

Posted on by
Reply

Principle #6 Know Your Personnel and Look Out for Their Well Being

In an Open Source software project, who are “your people?” Your people are your community. Whether they are a fellow developer from your own company, the guy that pops in once every couple of months to make a typo fix, or someone that just reports bugs, they are all the people that lead to the success (or lack thereof) of your project.

Continue reading →