JIRA, Religion, Technical, Technology

HOWTO: Develop Software Agilely

Link: https://dannyman.toldme.com/2015/03/06/howto-program-agile/

There seems to be some backlash going on against the religion of “Agile Software Development” and it is best summarized by PragDave, reminding us that the “Agile Manifesto” first places “Individuals and interactions over processes and tools” — there are now a lot of Agile Processes and Tools which you can buy in to . . .

He then summarizes how to work agilely:

What to do:

Find out where you are
Take a small step towards your goal
Adjust your understanding based on what you learned

How to do it:

When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

Sounds like sensible advice. I think I’ll print that out and tape it on my display to help me keep focused.

Feedback Welcome


“Father Finger” Banjo Tab

Link: https://dannyman.toldme.com/2015/03/11/father-finger-banjo-tab/

Tommy can not get enough of this song, so I picked this out on the banjo. My first attempt at building my own tab:

 G B D D G B D D    E G D   E G D     G D D   G D D     A A B G  A A B G

As a total total total newbie, the wife helped me pick the notes out on the piano. I then shifted them left 3: C –> G, E –> B, because that is what was sounding right on the banjo. And I had picked out my own notes chart using the “Fine Chromatic Tuner” app:

0  1  2  3  4  5  6   (fingers on frets..)
D  D# E  F  F# G
B  C  C# D  D#
G  G# A  A# B  C  C#
D  D# E  F  F# G  G#
G  -----------------

The revelation was when I “discovered” (I’m sure I have been told but it hadn’t been relevant at the time) that the fifth “G” string matches first string, fifth fret. Before that I was picking 2, then 5 on the D string.

With any luck I can pick around on this and mush it into some roll somehow. It would be nice if the second bit mapped to a chord . . .

Good times!

Feedback Welcome


“Father Finger” Banjo Tab v2

Link: https://dannyman.toldme.com/2015/03/23/father-finger-banjo-tab-v2/

  G B D D G B D D    E G D   E G D      G B D   G B D      A   A   B   G

I have been thinking about whether and where there are “drone notes” to work a roll around. I started with cleaning up the timing. (My knowledge of this song consists mainly of YouTube videos from India.) The bars go:

father finger x2
where are you? x2
here i am! x2
how do you do? x1

Each note here corresponds to a syllable, with quarter-note spacing on the last phrase. At least at the speed I play at this time, there is no roll to be added.

I did make two changes:
1) The fourth and eighth Ds in the first phrase moved from fifth string to fourth. Now the middle finger needs to be ready on that third fret a bit earlier, but we get out of plucking the fifth string twice in a row.
2) To avoid double-plucking in the third phrase, I went from G D D to G B D. They sound equally good to me, and to get G D D you can just keep your finger on the third fret.

Feedback Welcome


Nagios: Delay WARNING Notifications

Link: https://dannyman.toldme.com/2015/03/23/nagios-delay-warning-notifications/

I have a Nagios check to monitor the power being drawn through our PDUs. While setting all this up, I had to figure out alert threshholds. The convention for disk capacity is warn at 80%, critical at 90%. I also had this gem to work with:

National Electric Code requires that the continuous current drawn from a branch circuit not exceed 80% of the circuit’s maximum rating. “Continuous current” is any load sustained continuously for at least 3 hours.

(Thanks to mike Pennington, via http://serverfault.com/a/413307/72839)

So, I went with 80% warning, 90% critical.

Lately I have been getting a lot of warning notifications about circuits exceeding 80%. Ah, but the NEC says that is only a problem if they are at 80% for more than three hours. So, I dig through Nagios documentation and split my check out into two services:

define service{ # PDU load at 90% of circuit rating
    use                     generic-service
    hostgroup_name          pdus
    service_description     Power Load Critical
    notification_options    c,u,r
    check_command           check_sentry
    contact_groups          admins

define service{ # PDU sustained load at 80% of circuit rating for 3 hours
    use                       generic-service
    hostgroup_name            pdus
    service_description       Power Load High
    notification_options      w,r
    first_notification_delay  180
    check_command             check_sentry
    contact_groups            admins

The first part limits regular notifications to critical alerts. In the second case, the first_notification_delay should cover the “don’t bug me unless it has been happening for three hours” caveat and I set that service to only notify on warnings and recovery.

Feedback Welcome


Balancing 3-Phase Power

Link: https://dannyman.toldme.com/2015/03/27/balancing-3-phase-power/

I have some racks in a data center that were designed to use 3-phase PDUs. This allows for greater density, since a 3-phase circuit delivers more watts. The way three-phase works is that the PDU breaks the circuit into three branches, and each branch is split across two of the legs. Something like:

Branch A: leg X->Y
Branch B: leg Y->Z
Branch C: leg Z->X

The load needs to be balanced as evenly as possible across the three branches. When the PDU tells me the power draw on Branch A is say, 3A, I am really sure if that is because of equipment on Branch A or … Branch C? This only becomes a problem when one branch reports chronic overloading and I want to balance the loads.

I chatted with a friend who has a PhD in this stuff. He said that if my servers don’t all have similar characteristics, then the math says I want to randomly distribute the load. That is hard to do on an existing rack.

I came up with an alternative approach. Most of my servers fall into clusters of similar hardware and what I would call a “load profile.” I had a rack powered by two unbalanced 3-phase circuits. I counted through the rack’s server inventory and classified each host into a series of cohorts based on their hardware and load profile. Two three-phase circuits gives me six branches to work with, so I divided the total by six to come up with a “branch quota.” Something like:

<= 2 hadoop node, hardware type A
<= 2 hadoop node, hardware type B
   1 spark node, hardware type A
   1 spark node, hardware type C
   1 misc node, hardware type C

I then sat down with a pad and paper, one circuit on either side of the sheet, and wrote down what servers I had, and where the circuit was relative to quota. So, one circuit might have started off as:

Circuit A, Branch XY:

hadoopA: RM 1
hadoopB: ADD 2
sparkA:  --
sparkC:  ADD 1
misc:    --

I then moved servers around, updating each branch circuit with pencil and eraser as I went, like a diligent Dungeon Master. (And also, very important: the PDU receptacle configuration.)

The end result:



I started moving servers around Thu 15:00, and was done about 16:30, which is also when the hadoop cluster went idle. It kicked back up again at 17:00, and started spinning down around midnight.

What is important is to keep sustained load on the branches under the straight green line, which represents 80% of circuit capacity. You can see that on the left, especially the second circuit had two branches running “hot” and after the re-balancing the branch loads fly closer together, and top off at the green line.

Feedback Welcome

Arrr! . . . Avast!
Site Archive