<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.<br>
<br>
The difference of roles already exist between an orchestrator such
as Heat and Congress. You could use Heat in such a way templates
only describe correct configurations according to your policies
and test your templates to ensure they do follow your rules but
you will still use Congress as the place to describe the policy
and a way to check compliance.<br>
<br>
Because we have thousands of options with requirements that are
not all functionals and coming from different sources (project,
vendors, security team, global and local design, ops knowledge) we
should try to find ways to make knowledge explicit, declarative
and composable rather than bury it in imperative procedures. The
bet is that formalized rules will be much easier to capitalize on
than informal documentation. May be in the future, a lot of rules
could be supplied directly by OpenStack projects when options are
defined as a companion to the informal help descriptions. <br>
</p>
Regards,<br>
<br>
Pierre Crégut<br>
<br>
<div class="moz-cite-prefix">On 07/04/2017 05:17 PM, Clint Byrum
wrote:<br>
</div>
<blockquote type="cite" cite="mid:1499180783-sup-5043@fewbar.com">
<pre wrap="">Excerpts from valentin.matton's message of 2017-07-04 15:29:25 +0200:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title></title>
-- <br>
<div class="moz-signature">
<p style="font-family: Arial, Helvetica, sans-serif; margin-top:
10pt; margin-bottom: 10pt; font-size: 10pt; color:#000000;"><img
alt="Orange Logo"
src="cid:part1.0B51CD28.6F54DF49@orange.com" width="58"
height="58"></p>
<p style="font-family: Arial, Helvetica, sans-serif; margin-top:
0pt; margin-bottom: 0pt; font-size: 10pt; color:#000000;"> <b>Pierre
Crégut</b><br>
IMT/OLN/WTC/IEE/NAVI<br>
tél. +33 (0)2 96 07 19 76<br>
<a href="mailto:pierre.cregut@orange.com" style="font-family:
Arial, Helvetica, sans-serif; font-size: 10pt;
color:#FF6600">pierre.cregut@orange.com</a></p>
</div>
</div>
<PRE>_________________________________________________________________________________________________________________________
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.
</PRE></body>
</html>