Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-26227

lsstsw is slow on centos7/centos8 for conda transactions

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: conda, jenkins, lsstsw
    • Labels:
      None
    • Team:
      Architecture
    • Urgent?:
      No

      Description

      Whenever bin/deploy is ran, it will attempt to reinstall a conda environment even if that exact conda environment is already deployed. On jenkins workers for linux, this is really slow because the transactions are very slow over networked file systems due to the large amount of small files.

       

      Some kind of fast path could probably be created - particularly when we are using lock files. Simply verifying an existing environment has the same conda list --explicit output that the environment we are asking to install should be enough to bypass the extra step.

        Attachments

          Activity

          Hide
          gcomoretto Gabriele Comoretto [X] (Inactive) added a comment -

          From my understanding, especially in Jenkins, nothing is going to change the environment. 

          Therefore, we could just check if the environment exists, and avoid re-deploying in case it is.

          Or we could add a flag to force: do not redeploy if it exists, so we keep the current behavior as default.

          Show
          gcomoretto Gabriele Comoretto [X] (Inactive) added a comment - From my understanding, especially in Jenkins, nothing is going to change the environment.  Therefore, we could just check if the environment exists, and avoid re-deploying in case it is. Or we could add a flag to force: do not redeploy if it exists, so we keep the current behavior as default.
          Hide
          ktl Kian-Tat Lim added a comment -

          As long as the env is specified by git hash, I agree that looking at the contents is overkill. In other cases, checking the contents doesn't seem too expensive and is a bit safer.

          Show
          ktl Kian-Tat Lim added a comment - As long as the env is specified by git hash, I agree that looking at the contents is overkill. In other cases, checking the contents doesn't seem too expensive and is a bit safer.
          Hide
          gcomoretto Gabriele Comoretto [X] (Inactive) added a comment -

          Considering that an environment reference may be a tag instead of a hash and that tags may change (this is a different problem in my opinion), it may make sense to check also that the content of the environment hasn't changed.

          Show
          gcomoretto Gabriele Comoretto [X] (Inactive) added a comment - Considering that an environment reference may be a tag instead of a hash and that tags may change (this is a different problem in my opinion), it may make sense to check also that the content of the environment hasn't changed.

            People

            Assignee:
            gcomoretto Gabriele Comoretto [X] (Inactive)
            Reporter:
            bvan Brian Van Klaveren
            Reviewers:
            Brian Van Klaveren
            Watchers:
            Brian Van Klaveren, Gabriele Comoretto [X] (Inactive), Kian-Tat Lim
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Jenkins

                No builds found.