Open Stack

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 <valentin.matton at orange.com> 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.matton at orange.com" <valentin.matton at orange.com><valentin.matton at orange.com> <valentin.matton at 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-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170710/b8281eb2/attachment.html>