Re: [openstack-dev] [congress] Using congress to improve the consistency of configuration files.

[Tim Hinrichs]

Hi Valentin,

Sounds like an interesting use case.  Typically we've focused on
information available through APIs.  In this case the information would be
pulled off the disks of the machines running each service.

Here's the info for our weekly meeting.  If you can make that, it's a good
place to start.

http://eavesdrop.openstack.org/#Congress_Team_Meeting

Tim



On Mon, Jul 10, 2017 at 4:31 AM  wrote:

> Hi Eric,
>
> Here is the blueprint :
>
> https://blueprints.launchpad.net/congress/+spec/configuration-files-validation
>
> As Pierre Crégut presented it in his reply to Clint, the use of Congress
> we suggested and config management systems complement one another.
>
> Essentially, the latter reproduce delimited and *likely* valid
> configurations.
> But there is little formal validation and you'd rely on tests as soon as
> you
> have to make a change. Tests should be used in validation but are not
> best-suited to cover many constraints.
>
> By means of Congress, we could aggregate a lot of informal requirements
> and rules to define what a valid state is, in a more manageable way.
> We think that a declarative approach to the validation of configuration
> files would be very fitting.
>
> We'd also like to discuss the prototype and how to improve its design with
> the Congress team.
>
> V. Matton.
>
> Le 07/07/2017 à 01:16, Eric K a écrit :
>
> Hi Valentin,
>
> Very cool to hear about your use case and vision! It definitely sounds
> like the kind of use case Congress is well-equipped to solve using a
> flexible, declarative rule language.
>
> I'd love to explore the use case further (and where it fits along side
> config management systems as Clint mentioned). I'm especially curious to
> learn more about the prototype and see how I can be of help from Congress
> team.
>
> I did not see the blueprint link in the original message; missed paste
> perhaps?
>
> -Eric Kao (ekcs)
>
>
>
> On 7/4/17, 6:29 AM, "valentin.mat...@orange.com" 
>  
>  wrote:
>
>
> 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.
>
> Congress is such a safety net but it ensures policies on live resources
> deployed in the cloud, not on how the cloud is configured but we think
> that it could be extended
> to perform such verification with the adequate datasource.
> So we propose a new datasource that will query each node to fetch its
> configuration files as long as they follow oslo.config requirements and
> structure.
> As a first step we propose to use agents deployed on the different nodes
> explicitly configured with the list of configuration files that push
> those files to the central
> congress service. Later on, oslo.config could be modified to provide a
> hook used to push config files directly from running services.
>
> The new datasource displays not only the option values, the file, host
> where they are defined but also the associated metadata so that generic
> rules can be defined.
> It is then possible to define rules:
> - that constrain the value of options between different nodes
> - that constrain the values between different services or different
> service plugins.
> - it is even possible to use the knowledge of those configuration
> options to check policies on live resources (for example when there is a
> limitation or a bug in a given
> driver).
>
> We have a working prototype and the corresponding specification along
> those principles that we would like to share. An initial blueprint has
> been submitted here:
> Please feel free to react
>
> V. Matton
>
> __
> ___
>
> 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 

Re: [openstack-dev] [congress] Using congress to improve the consistency of configuration files.

[valentin.matton]

  
  
Hi Eric,
  
  Here is the blueprint : 
https://blueprints.launchpad.net/congress/+spec/configuration-files-validation
  
  As Pierre Crégut presented it in his reply to Clint, the use of
  Congress 
  we suggested and config management systems complement one another.
 Essentially, the latter reproduce delimited and likely
  valid configurations. 
  But there is little formal validation and you'd rely on tests as
  soon as you
  have to make a change. Tests should be used in validation but are
  not 
  best-suited to cover many constraints.

 By means of Congress, we could aggregate a lot of informal
  requirements 
  and rules to define what a valid state is, in a more manageable
  way. 
  We think that a declarative approach to the validation of
  configuration 
  files would be very fitting.
  
  We'd also like to discuss the prototype and how to improve its
  design with the Congress team.
  
  V. Matton.

Le 07/07/2017 à 01:16, Eric K a écrit :


  Hi Valentin,

Very cool to hear about your use case and vision! It definitely sounds
like the kind of use case Congress is well-equipped to solve using a
flexible, declarative rule language.

I'd love to explore the use case further (and where it fits along side
config management systems as Clint mentioned). I'm especially curious to
learn more about the prototype and see how I can be of help from Congress
team.

I did not see the blueprint link in the original message; missed paste
perhaps?

-Eric Kao (ekcs)



On 7/4/17, 6:29 AM, "valentin.mat...@orange.com"
 wrote:


  
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.

Congress is such a safety net but it ensures policies on live resources
deployed in the cloud, not on how the cloud is configured but we think
that it could be extended
to perform such verification with the adequate datasource.
So we propose a new datasource that will query each node to fetch its
configuration files as long as they follow oslo.config requirements and
structure.
As a first step we propose to use agents deployed on the different nodes
explicitly configured with the list of configuration files that push
those files to the central
congress service. Later on, oslo.config could be modified to provide a
hook used to push config files directly from running services.

The new datasource displays not only the option values, the file, host
where they are defined but also the associated metadata so that generic
rules can be defined.
It is then possible to define rules:
- that constrain the value of options between different nodes
- that constrain the values between different services or different
service plugins.
- it is even possible to use the knowledge of those configuration
options to check policies on live resources (for example when there is a
limitation or a bug in a given
driver).

We have a working prototype and the corresponding specification along
those principles that we would like to share. An initial blueprint has
been submitted here:
Please feel free to react

V. Matton

__
___

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

  
  


__
OpenStack Development Mailing List 

Re: [openstack-dev] [congress] Using congress to improve the consistency of configuration files.

[Eric K]

Hi Valentin,

Very cool to hear about your use case and vision! It definitely sounds
like the kind of use case Congress is well-equipped to solve using a
flexible, declarative rule language.

I'd love to explore the use case further (and where it fits along side
config management systems as Clint mentioned). I'm especially curious to
learn more about the prototype and see how I can be of help from Congress
team.

I did not see the blueprint link in the original message; missed paste
perhaps?

-Eric Kao (ekcs)



On 7/4/17, 6:29 AM, "valentin.mat...@orange.com"
 wrote:

>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.
>
>Congress is such a safety net but it ensures policies on live resources
>deployed in the cloud, not on how the cloud is configured but we think
>that it could be extended
>to perform such verification with the adequate datasource.
>So we propose a new datasource that will query each node to fetch its
>configuration files as long as they follow oslo.config requirements and
>structure.
>As a first step we propose to use agents deployed on the different nodes
>explicitly configured with the list of configuration files that push
>those files to the central
>congress service. Later on, oslo.config could be modified to provide a
>hook used to push config files directly from running services.
>
>The new datasource displays not only the option values, the file, host
>where they are defined but also the associated metadata so that generic
>rules can be defined.
>It is then possible to define rules:
>- that constrain the value of options between different nodes
>- that constrain the values between different services or different
>service plugins.
>- it is even possible to use the knowledge of those configuration
>options to check policies on live resources (for example when there is a
>limitation or a bug in a given
>driver).
>
>We have a working prototype and the corresponding specification along
>those principles that we would like to share. An initial blueprint has
>been submitted here:
>Please feel free to react
>
>V. Matton
>
>__
>___
>
>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



__
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

Re: [openstack-dev] [congress] Using congress to improve the consistency of configuration files.

[pierre.cregut]

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


__
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

Re: [openstack-dev] [congress] Using congress to improve the consistency of configuration files. (OpenStack-dev Digest, Vol 63, Issue 5)

[pierre.cregut]

  
  
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.







-- 
  
  
  -- 
  

 Pierre
Crégut
  IMT/OLN/WTC/IEE/NAVI
  tél. +33 (0)2 96 07 19 76
  pierre.cre...@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.


__
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

Re: [openstack-dev] [congress] Using congress to improve the consistency of configuration files.

[Clint Byrum]

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.

__
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

[openstack-dev] [congress] Using congress to improve the consistency of configuration files.

[valentin.matton]

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.


Congress is such a safety net but it ensures policies on live resources 
deployed in the cloud, not on how the cloud is configured but we think 
that it could be extended

to perform such verification with the adequate datasource.
So we propose a new datasource that will query each node to fetch its 
configuration files as long as they follow oslo.config requirements and 
structure.
As a first step we propose to use agents deployed on the different nodes 
explicitly configured with the list of configuration files that push 
those files to the central
congress service. Later on, oslo.config could be modified to provide a 
hook used to push config files directly from running services.


The new datasource displays not only the option values, the file, host 
where they are defined but also the associated metadata so that generic 
rules can be defined.

It is then possible to define rules:
- that constrain the value of options between different nodes
- that constrain the values between different services or different 
service plugins.
- it is even possible to use the knowledge of those configuration 
options to check policies on live resources (for example when there is a 
limitation or a bug in a given

driver).

We have a working prototype and the corresponding specification along 
those principles that we would like to share. An initial blueprint has 
been submitted here:

Please feel free to react

V. Matton

_

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