Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
cdist
cdist
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 41
    • Issues 41
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 14
    • Merge Requests 14
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • ungleich-public
  • cdistcdist
  • Issues
  • #803

Closed
Open
Opened Feb 22, 2020 by matze@matzeContributor
  • Report abuse
  • New issue
Report abuse New issue

__package_update_index does not update on new installations if --maxage given

By setup new lxc containers, some default manifests are run (which also runs every time a container gets reconfigured). In these manifests, __package_update_index --maxage $((60 * 60 * 24)) and several __package types get called.

These fail because the package index is not up to date (up to this, no __package_update_index got really executed). By debugging this, the currage explorer echos 0 if it does not find the specific file to stat. After creating a brand new lxc container, the specific file do not exist. Therefor, the gencode-remote exists, because the explorer returned a lower value than the maxage parameter.

In the lxc container installation, no package index update was done, so there is no cache file to stat. In such case, the type should rather assume no index update was done and do an update.

I think this can be solved several ways (but don't know the best):

  1. echoing a "max integer" constant which will always be higher than the maxage parameter (does this exist in a shell env?)
  2. thread the value 0 special and make an index update; theoretical, the type could be executed again as fast as the time difference is still 0, which would be a false positive
  3. echoing a special non-numeric case to indicate this problem (also, this could be -1, which is a slightly better solution than 2.); the gencode-remote must then first check if this case happened before comparing both values as integers
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ungleich-public/cdist#803