Rudder

The initial promises are located in the rudder-techniques repository.

First of all, we must ensure that the same files in rudder-techniques/initial-promises/nodeInitialPromises/ and rudder-techniques/initial-promises/rootServerInitialPromises/cfengine-community/ are at the same version, the same content:

# tree nodeInitialPromises/
nodeInitialPromises/
├── common
│   └── 1.0
│       ├── cfengine_stdlib.cf
│       ├── core-lib.cf
│       ├── library.cf
│       ├── process_matching.cf
│       ├── site.cf
│       └── update.cf
├── failsafe.cf
├── inventory
│   └── 1.0
│       ├── fetchFusionTools.cf
│       ├── fusionAgent.cf
│       └── virtualMachines.cf
└── promises.cf

4 directories, 11 files

# tree rootServerInitialPromises/cfengine-community/
rootServerInitialPromises/cfengine-community/
├── common
│   └── 1.0
│       ├── cfengine_stdlib.cf
│       ├── cf-served.cf
│       ├── internal_security.cf
│       ├── process_matching.cf
│       ├── rudder_lib.cf
│       ├── site.cf
│       └── update.cf
├── distributePolicy
│   ├── 1.0
│   │   ├── aliveCheck.cf
│   │   ├── apacheCheck.cf
│   │   ├── initCheck.cf
│   │   ├── integrityCheck.cf
│   │   ├── ldapCheck.cf
│   │   ├── logrotateCheck.cf
│   │   ├── postgresCheck.cf
│   │   ├── propagatePromises.cf
│   │   └── rsyslogConf.cf
│   ├── logrotate.conf
│   │   └── rudder
│   └── rsyslog.conf
│       └── rudder.conf
├── failsafe.cf
└── promises.cf

6 directories, 20 files

• initial-promises/nodeInitialPromises/common/1.0/update.cf
• rootServerInitialPromises/cfengine-community/common/1.0/update.cf
• rootServerInitialPromises/cfengine-nova/common/update.cf
• policies/system/common/1.0/update.st

Before all of this, It will be necessary to update all the initial-promises => #2670

Nicolas PERRON wrote:

There is a part about red button in the initial promise promise.cf for root server but not in the node. Given that Red button is an abandoned functionnality, should we keep it ?

Yes, it would be good to preserve this, because we only abandoned it because the UI was unsuitable. The CFEngine side was fine, so let's keep it working if possible.

All commits up to now look good to me.

I have just one concern: the inventory promises are not called on a policy_server, although they now should be.

• inputs instruction can't be subject to CFEngine classes, so I've use an inputs which included all promises needed by server and nodes . Only bundlesquence continue to be subject of CFEngine classes and it's sufficient.

It looks good to me. I do not see any suspicious things in the commits and in the resulting files on the repo. However, special care has to be observer as this is quite a large commit, be careful of side effects.

Jonathan CLARKE wrote:

Jonathan CLARKE wrote:

This is a quite complicated, and I reviewed a lot of it as it happened. It all looks good to me.

Actually, no, commit:d89cc306a3843192f36c77a249c6aa0df9406136 introduced some problems with the bundlesequence in techniques, not in the initial promises. Issues #2742 and #2744 re-introduce 4 of the 6 bundles removed for nodes (non-policy-servers).

The two remaining ones that were removed are "set_red_button" and "clean_red_button". It seems to me that these should be included on nodes just the same as on policy_servers, since they include instructions to add/remove the "stopFile" which is what allows to completely pause CFEngine. Thoughts?

You're right ! The bundle check_red_button_status seems to be useless without set_red_button and clean_red_button. Besides, classes are already define to split between policy server and nodes actions.

Nicolas PERRON wrote:

Jonathan CLARKE wrote:

Jonathan CLARKE wrote:

This is a quite complicated, and I reviewed a lot of it as it happened. It all looks good to me.

Actually, no, commit:d89cc306a3843192f36c77a249c6aa0df9406136 introduced some problems with the bundlesequence in techniques, not in the initial promises. Issues #2742 and #2744 re-introduce 4 of the 6 bundles removed for nodes (non-policy-servers).

The two remaining ones that were removed are "set_red_button" and "clean_red_button". It seems to me that these should be included on nodes just the same as on policy_servers, since they include instructions to add/remove the "stopFile" which is what allows to completely pause CFEngine. Thoughts?

You're right ! The bundle check_red_button_status seems to be useless without set_red_button and clean_red_button. Besides, classes are already define to split between policy server and nodes actions.

OK, cool. Then please open a new bug for this and fix in 2.4.0~beta5. This one can then be closed.

Jonathan CLARKE wrote:

Nicolas PERRON wrote:

Jonathan CLARKE wrote:

Jonathan CLARKE wrote:

This is a quite complicated, and I reviewed a lot of it as it happened. It all looks good to me.

Actually, no, commit:d89cc306a3843192f36c77a249c6aa0df9406136 introduced some problems with the bundlesequence in techniques, not in the initial promises. Issues #2742 and #2744 re-introduce 4 of the 6 bundles removed for nodes (non-policy-servers).

The two remaining ones that were removed are "set_red_button" and "clean_red_button". It seems to me that these should be included on nodes just the same as on policy_servers, since they include instructions to add/remove the "stopFile" which is what allows to completely pause CFEngine. Thoughts?

You're right ! The bundle check_red_button_status seems to be useless without set_red_button and clean_red_button. Besides, classes are already define to split between policy server and nodes actions.

OK, cool. Then please open a new bug for this and fix in 2.4.0~beta5. This one can then be closed.

Done. See #2923