Dependency handling failing #169
Labels
No Label
bugfix
cleanup
discussion
documentation
doing
done
feature
improvement
packaging
Stale
testing
TODO
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ungleich-public/cdist#169
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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: darko-poljak
Merged PR https://github.com/ungleich/cdist/issues/441.
Fixed in new version.
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: 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: 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
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: 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: 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: 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?