| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2015-10-21 | Rewrote Propellor.Property.ControlHeir one more time, renaming it to ↵ | Joey Hess | |
| Propellor.Property.Conductor. Wow, really.. So, this gets back to having properties that are added to hosts to say what they conduct. I think that conducts webservers `before` conducts dnsserver is an important thing to be able to express. Untested except for eyeballing the resulting Host data. | |||
| 2015-10-20 | refactor | Joey Hess | |
| 2015-10-20 | simplify privdata propigation to spin from controller | Joey Hess | |
| 2015-10-20 | reword | Joey Hess | |
| 2015-10-20 | build warnings | Joey Hess | |
| 2015-10-20 | The Propellor.Property.Spin added in the last release is replaced with a ↵ | Joey Hess | |
| very different Propellor.Property.ControlHeir. Rethought it because it turned out that propigating the PrivData rendered the loop detection pointless, because when there was a loop, each host included the other's PrivData, which in turn lead to a loop. And, it was not possible to break that loop. So, changed from adding properties to hosts to a top-down hierarchy that makes changes as needed when applied to the hosts. Which makes it easy to detect and break loops. Aka: The Ur Quan know what they're up to. | |||
