<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>