Helper variable for a timestamp:
​DTS = $(shell date +%Y-%m-%dT%H:%M:%S-%Z)

Test for a file:
define test_file
    # tests the file in the <first dependency>
    if ! test -s $@; \
    then echo $(DTS)    [FAIL] - $@ does not exist; \
    else true; fi
endef

etc/sql/INFO_WEEKLY_TOP_SALES_RANK_002_load.sql:
    @$(test_file)

Test for a dependent file:

define test_dependent_file
    # tests the file in the <first dependency>
    if ! test -s $<; \
    then echo $(DTS)    [FAIL] - $< does not exist; \
    else true; fi
endef

SHELL := $(which bash)

SHELL: $(SHELL)
    @$(test_dependent_file)

The ideal host name provides just enough information to help identify the device but not so much information that the name limits the flexibility to accommodate future requirements. It is a [standard industry practice](http://www.ibm.com/developerworks/aix/library/au-name_standards/) to overload the name of a server with many specific physical details. However, as the role of a server or a network device becomes more ephemeral, overloading a hostname with things like physical location, whether it is a virtual or physical device, or even ownership can become a problem in the future.

An industry standard
Here is one suggested standard from IBM.

dtwldora05.ibm.com would represent node 5 of an Oracle database, being used for development, running on linux, in Detroit.
This looks like a pretty good standard but it could be improved. Let’s consider a couple of these situations.

Q: What happens if the server is retired and the application is moved to Google Compute Engine?
A: It’s a new server and therefore would get a new host name.
​
Discussion: This is a correct answer but you need to ask yourself what was the purpose of including the location code? Typically, this is to provide some hint to the physical location of the device. This matters to the operations team but does it matter to the end user? If you shift focus to the actual consumer, specifying city level granularity might be too restrictive. I think Amazon zones are a good example of the level of granularity we need to be considering. Thinking in terms of regional geography is more important than identifying specific locations. Therefore, tracking regional geography may be sufficient. 

Q: What benefit is there in tracking OS Type?
A: It helps the operations team easily identify the operating system and therefore know the skills needed to administer the machine.

Discussion: Again, a good answer if your environment consists of many operating systems. However, if there is a standardization on a particular type of OS (e.g., Linux) this doesn’t add much value. The case could be made that if you switch a server from Windows to Linux, you have a different server and therefore need a new host name. Correct, but does the OS really matter to the end user? I would argue that it may be time to switch to a Host Type designation.
Shifting the focus from OS to Host Type provides a more accurate and flexible reflection of what the device does. For a physical server the following might apply:

p = Bare metal server
v = Virtual host (bare metal + hypervisor)
c = Container host (bare metal + container engine)
g = Guest image (OS image running on a VM or Container)
n = Network device (bare metal + networking software) 

Q: What benefit is there in tracking Application Type?
A: It is important to know the application role of a server for the same reason you need to know the OS. It helps to identify the skills needed to fix any issues.
Discussion: Here I would argue for maintaining the flexibility to change the purpose of the server or the applications running on the server without having to change the host name. The same can be said for production status. It isn’t uncommon for a staging server to be pushed into a production role pre for a development server to be moved into staging. Therefore, I think you could eliminate both the Application Code and Environment from the host name definition.
Remember, this discussion is about the device host name. Application DNS names are a different matter. These additional names for a device are simply aliases and they should be more descriptive, especially if you are implementing DNS based application discovery.

Initial Recommendation

Conclusion
Seven characters leaves a lot of ambiguity! This is by design. Computers are general use tools and should be treated that way. By maintaining the flexibility to repurpose and device for nearly any purpose as needed, you give yourself flexibility to meet changing requirements without having to resort to complicated migration projects. Need to stand up a new server? You only need to know the region it is supporting and its general role. I suppose that as more and more environments migrate to being completely defined by software running on standardized commodity hardware the only necessary information might be the geography and a random unique identifier.

So where does this leave all of other important information about a device? This is best stored and managed in some type of Configuration Management System tied to your Continuous Deployment infrastructure.

Second thoughts
What would the simplest, most flexible, but still useful host name scheme look like?

​Three server migrations to very different platforms but still maintaining the same host name. At the end of the day, you have a computer doing some work. What it looks like, where it is installed, and the specific applications it utilizes don't really matter.

You could simplify even further if you wanted but 5 characters are easy to remember and give plenty of headroom to grow.

Example code
The following code snippet could be used to dynamically create a hostname at the time a system image is being created.

Test Code
$ GEO=$"us" && OLD=$HOSTNAME && SEQ=$(cat /dev/urandom | tr -cd 'a-hj-np-z1-9' | head -c 5) && echo $HOSTNAME " => " $GEO$SEQ
Returns: ubuntu => usyfvds

Implementation
​$ GEO=$"us" && OLD=$HOSTNAME && SEQ=$(cat /dev/urandom | tr -cd 'a-hj-np-z1-9' | head -c 5) && sudo sed -i "s/$OLD/$GEO$SEQ/" /etc/hostname && sudo sed -i "s/$OLD/$GEO$SEQ/g" /etc/hosts && sudo reboot