https://www.hightechemployeelawsuit.com/
Though I think the deadline has passed... you had to register to be part of it.
Update: oh, I take that back, you have until 4/26/2014 it says.
303 karma · joined December 2, 2012
Though I think the deadline has passed... you had to register to be part of it.
Update: oh, I take that back, you have until 4/26/2014 it says.
Also, the impact of the Manhattan Project on Richard Feynman: http://www.youtube.com/watch?v=_ah7f-1M2Sg
"I simply didn't think"
Sensitive data on the magnetic stripe or chip must never be stored. Only the PAN, expiration date, service code, or cardholder name may be stored, and merchants must use technical precautions for safe storage (see back of this fact sheet for a summary)
[1] https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storag...
> The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard
This is just silly... you have to store your configs somewhere, and setting env vars is not OS agnostic.
Assuming you're not using something like Zookeeper, you do want track your config files in your revision control, just separate from the app. Implement an override system so your app loads the env specific settings from a standard override location (e.g. Java /opt/overrides/myapp.properties). If you use env vars or property files doesn't matter as much as being consistent and that you're not creating more complexity to just to make things simple.
You must be new to planet earth. ;-)
Seems like the main issue would be there's only limited case where inventory systems are currently needed, and the existing systems aren't completely broken just yet. But you can imagine at some point, being able to track and manage all of the devices in your home will be a big issue, and there may be an incentive for companies that produce enterprise and consumer goods to not have to develop and maintain duplicate standards. At that point it seems like it would drive some more innovation here.
In the meantime, my preference is to query data in real time form its source (e.g. AWS, VMware), vs. syncing data to a CMDB like database. Unmanaged physical inventory of course still requires a CMDB like database.
Though one of the core technology decisions behind Ansible is that you don't need much to get it running. You can scale things up as needed, such as fireball mode. And you can boot strap that process using Ansible. You don't even need DNS.
Hosts can register back with Ansible on start up, this works today with their AWX product and cloud-init's phone home feature. Also your inventory of hosts can simply be queried from sources, such as AWS's inventory list, so in that case you can't have a host that's unaccounted for.
Ansible keeps the task and orchestration layer simple so you stay focused on the problem you're solving vs. focusing some complexity of the tool itself, like a hierarchical data model.
If you need complex logic, use the programming language of your choice and write a module, it's simple and your code can be as complex as you need.
If you need more complex data structures, then simply have Ansible query it from a real database or other datasource, with as complex a data structure as you need.
But at the layer you're expressing what needs to be done, it should be simple and easy to read.