MySQL GRANT oddities

The problem

Just yesterday after setting up a mysql slave I tried to switch the backups of the master to the slave, trying to reduce the load on the master. While trying the following command:

mysql> GRANT ALL ON *.* TO 'backupuser'@'localhost';

I got the following error:

 Access denied for user 'root'@'localhost' (using password: NO)

hmmm, quite curious since I was logged into the mysql server as root. After some googling on the subject I found a weird little problem with the tables between versions.

This error above only happened because I had upgraded the mysql server from a 5.0 to a 5.5 server. I had thought there wasn't much to this, I also changed the location of the data directory to be a new partition to handle the amount of data that I had.

The crux of the issue was that during the upgrade I moved the data directory contents as well. Meaning that the old tables were in place with the new server.

The Solution

What I didn't realize was that I needed to upgrade the mysql tables from the old version to the new. So with the following command:

shell> mysql_upgrade

I got the above error again. 

 Access denied for user 'root'@'localhost' (using password: NO)

Damn! But not to worry, with the above command is able to take  a username and password:

shell> mysql_upgrade -u root -p

Nice one I'm now in and it gives me a bunch of errors. Damn! Error code 13? Hold on that's a permissions error. I wonder if running it as the mysql user that has ownership of the data file tables will work:

shell> sudo su - mysql
shell> mysql_upgrade -u root -p

Nice, worked a charm this time.

I can now go back to my little grant that I was trying to do in the first place:

mysql> GRANT ALL ON *.* TO 'backupuser'@'localhost';

And I'm able to complete it. Nice one.

Implementing Kanban

Frustrations


A general frustration of mine of using an agile type board to track the work the team I am currently working in was that we had very little insight into what types of work that we completed. I had worked in a development team a while back and was very impressed about how good it can work for a team on a specific project. About a year and a half ago I moved into the DevOps type role, still a software developer by title but more concerned about the build and release side of things. The board that we implemented for this was the following:

A couple of things to note about this board. 

• There's no rhyme or reason for the colors that are used
• The backlog is huge and rarely moves as things get put directly into next
• All the backlog items are "planned" work things that we need to get to at some point but very rarely get the time for

Along with the changing role there were a great deal of work type baggage. For instance we might have to change build scripts, promote code, build the latest release candidate, fix a problem with an environment. The main change was that a good portion of this work was not planned, all very ad hoc. People coming up to our desk and saying "I need a build" or "the MQ server is down", stuff like that.


The problem with the above board is that none of this ad hoc work is visualized. This meant that the planned work sat in the backlog for a very very long time and the in progress stories were there for a long time too. Things would also come straight into next without be prioritized in the backlog either. So all in all, although being very busy, it felt like we were doing nothing cause the board wasn't moving.


Trying something different


I was then lucky enough to get on a conference about Lean. A couple of speakers at it specifically talked about Kanban for DevOps. This is a growing subject and I was very interested in how they applied lean/kanban to there teams work. It talked alot about visualizing the types of work that are completed by the team, showing the dependencies on other teams and how to make changes to the current way of things.


From this then we created a new board, after the first couple of days it looked something like this:

The things to note are:

• There are three main swim lanes one for each type of work that we think we do, incidents (yellow), change requests (blue) and planned work (green) with a waiting for or impediment (pink) for problems
• We have a lot less in our backlog
• Blockers and waiting for are visualised

The new swim lanes go a long way to showing the actual types of work that are coming across our desk. As you can see the different colors show that a good proportion of the work is actually incidents. These are not typically large jobs however they do involve a context switch which is time consuming in it's own right.


The difference it makes


There are a couple of differences we say this could make to the team.

• Allows people coming up to the desk to see what work is currently going on and how there task would fit into the current work load
• Shows the flow across the board, meaning that it actually looks like we're doing something - this is more personal for me as I was able to feel better about the work getting done
• Data - it might not be apparent from the picture but we track how long something is sitting in the board with a start date and how long it is in progress with a dot for every day

Next Steps


Next steps will be what to do with the data that is being captured from the board. We are planning to clear the board every week and capture the data that we can get and then make some improvements. Cause that's the end game really, is to make some genuine improvements into the way that we work. This will mean that the "done" column will also be cleared down and the board will look fresh for the new week coming.


I'm still undecided whether or not there is enough data there to be useful to us, and what we're marking down is going to tell us anything. But what we record will possible change by having a look at what is useful to us with the data that we currently have.


Anyway, I might post something in a month or two about this to see if the same holds true, if we've made any improvements or just clean scrapped the board for something else.