Modify ↓
Ticket #1096 (accepted defect)
bcfg2-info mappings broken for Package entries
Reported by: | solj | Owned by: | solj |
---|---|---|---|
Priority: | major | Milestone: | Bcfg2 1.3.5 Release (Bugfix) |
Component: | bcfg2-server | Version: | 1.0 |
Keywords: | Cc: |
Description (last modified by solj) (diff)
On a machine with Packages properly configured and working...
> mappings Package Plugin | Type | Name ========================= >
Attachments
Change History
comment:1 Changed 11 years ago by solj
- Owner changed from desai to solj
- Status changed from new to accepted
- Description modified (diff)
comment:2 Changed 11 years ago by solj
- Milestone changed from Bcfg2 1.2.2 Release (Bugfix) to Bcfg2 1.2.3 Release (Bugfix)
Moving to 1.2.3
comment:3 Changed 11 years ago by solj
- Milestone changed from Bcfg2 1.2.3 Release (Bugfix) to Bcfg2 1.3.0 Release
Moving to 1.3
comment:4 Changed 11 years ago by https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc
I'm not sure this is reasonable (or maybe even possible) due to the way mappings is implemented. It looks through each generator for its inventory as recorded in plugin.Entries. For plugins like Packages that don't store their entries in Entries (but rather use HandlesEntry/HandleEntry? to do the "slow" lookup) this kind of inventory just isn't kept.
So we have a few options:
- Keep mappings as-is and acknowledge that more "dynamic" plugins simply aren't going to work;
- Do an inventory of entries in Bundler and iterate over those rather than over the generators, and acknowledge that entries in templated bundles simply aren't going to work;
- Some kind of hairy hybrid of those two approaches (which would likely mean doing both and taking a union of the results).
Note: See
TracTickets for help on using
tickets.