Dependency handling failing #169

Closed
opened 2021-11-20 15:20:39 +00:00 by ungleich-gitea · 8 comments

Created by: jdguffey

I have a file, /usr/local/keys/pkg.key, referenced by a manifest as such:

__directory /usr/local/keys --owner root --group wheel --mode 755

require="__directory/usr/local/keys" __file /usr/local/keys/pkg.pub --owner root --group wheel
--mode 644 --source $__manifest/global_files/usr/local/keys/pkg.pub

When I execute this manifest, it consistently fails by not creating the __directory/usr/local/keys dependency and so the file has no place to be put.

See the attached file for debug output (cdist config -dvi)

*Created by: jdguffey* I have a file, /usr/local/keys/pkg.key, referenced by a manifest as such: __directory /usr/local/keys --owner root --group wheel --mode 755 require="__directory/usr/local/keys" __file /usr/local/keys/pkg.pub --owner root --group wheel \ --mode 644 --source $__manifest/global_files/usr/local/keys/pkg.pub When I execute this manifest, it consistently fails by not creating the __directory/usr/local/keys dependency and so the file has no place to be put. See the [attached](https://github.com/ungleich/cdist/files/299660/cdist.output.txt) file for debug output (cdist config -dvi)
Author
Owner

Created by: darko-poljak

Merged PR https://github.com/ungleich/cdist/issues/441.
Fixed in new version.

*Created by: darko-poljak* Merged PR https://github.com/ungleich/cdist/issues/441. Fixed in new version.
Author
Owner

Created by: telmich

I think if we encounter an object with a requirement after we found one without requirement the only sane thing is to abort.

If we don't abort we have a confused user (Sorry Jake) and we cannot ensure that the requirement will be fulfilled before it's definition.

It's a nice corner case here and Steven and I used to discuss a lot about dependency resolving before - it's a real fun topic!

*Created by: telmich* I think if we encounter an object _with_ a requirement _after_ we found one _without_ requirement the only sane thing is to abort. If we don't abort we have a confused user (Sorry Jake) and we cannot ensure that the requirement will be fulfilled before it's definition. It's a nice corner case here and Steven and I used to discuss a lot about dependency resolving before - it's a real fun topic!
Author
Owner

Created by: darko-poljak

@jdguffey From the code,
cdist will raise an error if object already exists and CDIST_OVERRIDE is not defined and if already existing object parameters differ from currently defining object.
So in this case, __file/usr/local/keys/pkg.pub without 'require' was registered first.
The second __file/usr/local/keys/pkg.pub (with 'require') was detected as the same object with the same parameters so it is not created. That is why requirement is also not registered.
So cdist creates the first object it encounters and ignores the second with the same id and same parameters regardless 'require' definition.
@telmich Should requirements in this check also be taken into account?

*Created by: darko-poljak* @jdguffey From the code, cdist will raise an error if object already exists and CDIST_OVERRIDE is not defined and if already existing object parameters differ from currently defining object. So in this case, __file/usr/local/keys/pkg.pub without 'require' was registered first. The second __file/usr/local/keys/pkg.pub (with 'require') was detected as the same object with the same parameters so it is not created. That is why requirement is also not registered. So cdist creates the first object it encounters and ignores the second with the same id and same parameters regardless 'require' definition. @telmich Should requirements in this check also be taken into account?
Author
Owner

Created by: jdguffey

Also, I just discovered something after looking through my hierarchical manifests...

The particular subordinate manifest I was sourcing included a __file/usr/local/keys/pkg.pub, without the __directory/usr/local/keys constraint. Apparently the dependency resolver consistently chose to prioritize that one over the entries in the initial manifest.

This is definitely my error. That said, it does raise an interesting issue. If a single type+object_id combination is used twice, should that be treated as an error? If not, should one win out over the other? If so, which one? The one with more constraints? The one defined first? The one defined last?

Paging @telmich for input.

*Created by: jdguffey* Also, I just discovered something after looking through my hierarchical manifests... The particular subordinate manifest I was sourcing included a __file/usr/local/keys/pkg.pub, without the __directory/usr/local/keys constraint. Apparently the dependency resolver consistently chose to prioritize that one over the entries in the initial manifest. This is definitely my error. That said, it does raise an interesting issue. If a single type+object_id combination is used twice, should that be treated as an error? If not, should one win out over the other? If so, which one? The one with more constraints? The one defined first? The one defined last? Paging @telmich for input.
Author
Owner

Created by: jdguffey

It does work.

ls -lrt /usr/local/keys/

total 2
-rw-r--r-- 1 root wheel 800 Jun 7 00:18 pkg.pub

*Created by: jdguffey* It [does](https://github.com/ungleich/cdist/files/301822/cdist.output.txt) work. # ls -lrt /usr/local/keys/ total 2 -rw-r--r-- 1 root wheel 800 Jun 7 00:18 pkg.pub
Author
Owner

Created by: darko-poljak

@jdguffey Hm.. Does this happen for more complex manifest or it happens even for only those two lines:

__directory /usr/local/keys --owner root --group wheel --mode 755

require="__directory/usr/local/keys" __file /usr/local/keys/pkg.pub --owner root --group wheel
--mode 644 --source $__manifest/global_files/usr/local/keys/pkg.pub

*Created by: darko-poljak* @jdguffey Hm.. Does this happen for more complex manifest or it happens even for only those two lines: __directory /usr/local/keys --owner root --group wheel --mode 755 require="__directory/usr/local/keys" __file /usr/local/keys/pkg.pub --owner root --group wheel \ --mode 644 --source $__manifest/global_files/usr/local/keys/pkg.pub
Author
Owner

Created by: jdguffey

@darko-poljak It does. See the attached file.

The issue I'm having is that cdist isn't even attempting to handle the __directory prior to the __file, even though I'm directing it to with require="..."

*Created by: jdguffey* @darko-poljak It does. See the [attached file](https://github.com/ungleich/cdist/files/301403/cdist.output.txt). The issue I'm having is that cdist isn't even attempting to handle the __directory prior to the __file, even though I'm directing it to with require="..."
Author
Owner

Created by: darko-poljak

@jdguffey If you put in the manifest only the line:

__directory /usr/local/keys --owner root --group wheel --mode 755

does it create the directory?

Can you send debug output for that case?

*Created by: darko-poljak* @jdguffey If you put in the manifest only the line: __directory /usr/local/keys --owner root --group wheel --mode 755 does it create the directory? Can you send debug output for that case?
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ungleich-public/cdist#169
No description provided.