This is the classical divide between workflows and business rule
engines and we think that both are useful. While the first are
invaluable to make a system reach a correct state, the second
describe in a more declarative way what a correct state is and can
also be used as a global model of the set of correct
configurations. A workflow engine will bring you to a reproducible
state but this state is correct only because some rules have been
verified beforehand. Workflows are also often designed in silos.
When you need to combine playbooks, interactions may lead to
unexpected problems. Testing is necessary but if you can capture
invariants (types) you will spend less time and get better
confidence on your deployments. Pierre Crégut On 07/04/2017 05:17 PM, Clint Byrum
wrote:
Excerpts from valentin.matton's message of 2017-07-04 15:29:25 +0200:We would like to use congress to check the consistency of the configuration files used by the various Openstack services on different nodes.Although installers do a great job for ensuring that the initial definition of those files are correct, it may be necessary to tweak those files on running instances or to use templates that are out of the bounds of the pre-configured use-cases. Then the administrator must modify the configuration without any safety net.While I'm sure this does still happen, you'd have to be living under a rock to think that this is the state of the art. I'm certain _most_ OpenStack installs are using automated configuration management to assert their config file content. And if they're practicing safe deploys, they also have integration tests to make sure those modifications work properly. Now, if Congress does in fact want to compete with Puppet / Chef / Ansible / Salt / etc., I suppose that's Congress's choice. But just to be clear: very few operators are doing what you suggest as the reason to make Congress do this. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev