Open Stack

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.

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.

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.

Regards,

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

-- 
-- 

Orange Logo

*Pierre Crégut*
IMT/OLN/WTC/IEE/NAVI
tél. +33 (0)2 96 07 19 76
pierre.cregut at orange.com <mailto:pierre.cregut at orange.com>


_________________________________________________________________________________________________________________________

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.