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

Understand science pipeline cadence for DP0.1 users

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Up to now, both science pipelines and science platform code has been under rapid development and the userbase has wanted to take advantage of new features and stability improvements. So Nublado weeklies are built on top of science weeklies. Since DP0.1 is essentially a "as-is" release of the science platform I had assumed that we would follow a similar protocol of defaulting to a recommended weekly build, only with a "slower-moving" recommended.
      In a discussion on Slack https://lsstc.slack.com/archives/C9YRAS4HM/p1621010253184400?thread_ts=1620238563.142200&cid=C9YRAS4HM
      it emerged that at least one person assumed that we would follow the stack club model, which only runs on official science pipelines releases, updating only when the next science pipelines release is out. With the build/release process available for DP0.1 (which is not the final ops-era process but is what we have) this would mean not releasing to the users any usability improvements in JupyterLab (user aids, rewording a confusing menu etc) until a new science pipelines release is out. This seems sub-optimal to me.
      The one thing I can safely say: there is no compatibility guarantee offered for the preview era. If you log onto the RSP once, and then log back on 6 months later, you are not guaranteed to find things exactly as you left them with an identical environment. The effort to maintain stability across even a year or two will not be available till Construction is complete.

      This ticket is to resolve what is needed.

        Attachments

          Issue Links

            Activity

            Hide
            frossie Frossie Economou added a comment -

            Talked to Yusra AlSayyad. Since there is a v23 pipelines release planned for the summer (around PCW) as the "Gen3" release, we could leverage the current process, recommend v22 (assuming it is out by DP0.1 date) and then there will be no JL fixes deployed until v23 (around 1.5 months later). That doesn't seem too long to go.

            Show
            frossie Frossie Economou added a comment - Talked to Yusra AlSayyad . Since there is a v23 pipelines release planned for the summer (around PCW) as the "Gen3" release, we could leverage the current process, recommend v22 (assuming it is out by DP0.1 date) and then there will be no JL fixes deployed until v23 (around 1.5 months later). That doesn't seem too long to go.
            Hide
            frossie Frossie Economou added a comment -

            Gregory Dubois-Felsmann is working on a requirement setting out the general backward compatibility guarantee for nublado to inform further work in this area.

            Show
            frossie Frossie Economou added a comment - Gregory Dubois-Felsmann is working on a requirement setting out the general backward compatibility guarantee for nublado to inform further work in this area.
            Hide
            tjenness Tim Jenness added a comment -

            Locking people into formal releases is fine so long as this doesn't result in a sudden burden of us having to backport many many fixes on to those release branches. v22 will be over two months old by DP0.1 start and it won't be possible with reasonable effort to back port many of the more recent developments. Gen3 middleware is still changing rapidly.

            Show
            tjenness Tim Jenness added a comment - Locking people into formal releases is fine so long as this doesn't result in a sudden burden of us having to backport many many fixes on to those release branches. v22 will be over two months old by DP0.1 start and it won't be possible with reasonable effort to back port many of the more recent developments. Gen3 middleware is still changing rapidly.
            Hide
            krughoff Simon Krughoff added a comment - - edited

            [EDIT] I missed Tim's edit when putting mine together. This proposal is to avoid what Tim is worried about with having to backport lots of things to old releases. This provides some formality and accountability without the rigidity of being beholden to only use formal releases.

            My preference for how to promote recommended is to have a formal process of approval by pipelines and CET for updating recommended, but not necessarily require that a recommended be an official release. I think we probably can start with v22 as the recommended, but I'd like to have a little more flexibility than requiring the next recommended by another official release. My starting proposal is the recommended on the IDF can be bumped to any image (preferably a weekly or better) using the following process:

            1. A DM ticket is made with at least me (as the POC for the notebook-demo repository), Frossie, Leanne, Yusra and Gregory as watchers including the requested stack version to bump the recommended tag to.
            2. This triggers the functionality testing process of the various notebook repositories we distribute to the RSP automatically. This is the process being formalized in DM-30241. The point of contact for each repository needing testing will comment on the triggering ticket indicating go/no go for bumping the recommended. I am the point of contact for the notebook-demo repository if we continue to distribute that repository in some form.
            3. Once all responsible parties have responded with a "go" status, formal sign off on moving recommended will commence by moving the ticket to "In Review" with Leanne, Gregory, Yusra and Frossie as reviewers
            4. Removing their name from the reviewer list and adding a comment indicating sign off is the signal that each reviewer is willing to promote the version in question to recommended.
            5. The final reviewer should mark the ticket "Reviewed" and indicate that they are willing to promote.
            6. At this point the functional activities of tagging the image and any other necessary actions can begin and the ticket will be moved to "Done" when the those actions have all been taken and it's been shown that the recommended on the IDF does, indeed, reflect the intended version.

            Show
            krughoff Simon Krughoff added a comment - - edited [EDIT] I missed Tim's edit when putting mine together. This proposal is to avoid what Tim is worried about with having to backport lots of things to old releases. This provides some formality and accountability without the rigidity of being beholden to only use formal releases. My preference for how to promote recommended is to have a formal process of approval by pipelines and CET for updating recommended, but not necessarily require that a recommended be an official release. I think we probably can start with v22 as the recommended, but I'd like to have a little more flexibility than requiring the next recommended by another official release. My starting proposal is the recommended on the IDF can be bumped to any image (preferably a weekly or better) using the following process: 1. A DM ticket is made with at least me (as the POC for the notebook-demo repository), Frossie, Leanne, Yusra and Gregory as watchers including the requested stack version to bump the recommended tag to. 2. This triggers the functionality testing process of the various notebook repositories we distribute to the RSP automatically. This is the process being formalized in DM-30241 . The point of contact for each repository needing testing will comment on the triggering ticket indicating go/no go for bumping the recommended. I am the point of contact for the notebook-demo repository if we continue to distribute that repository in some form. 3. Once all responsible parties have responded with a "go" status, formal sign off on moving recommended will commence by moving the ticket to "In Review" with Leanne, Gregory, Yusra and Frossie as reviewers 4. Removing their name from the reviewer list and adding a comment indicating sign off is the signal that each reviewer is willing to promote the version in question to recommended. 5. The final reviewer should mark the ticket "Reviewed" and indicate that they are willing to promote. 6. At this point the functional activities of tagging the image and any other necessary actions can begin and the ticket will be moved to "Done" when the those actions have all been taken and it's been shown that the recommended on the IDF does, indeed, reflect the intended version.
            Hide
            kadrlica Alex Drlica-Wagner added a comment -

            We discussed this within the CET team with Leanne Guy and Melissa Graham, and I think we largely agree on the points raised by Simon. To enumerate these:

            1. The CET is not recommending that the default release be the last major release for long periods of time (i.e. 6 months). We do think that a slightly slower-moving default (i.e., once a month) based on a weekly version would probably be about the right cadence. We are under the impression that the first default version for DP0 will be major release v22.
            2. The CET has started to develop a set of small tutorial notebooks that will be put under CI and should be verified to build on any new default release.
            3. There are a set of larger and more complex notebooks contributed by the community that the CET does not support (one example is the Stack Club, and we expect more DP0 delegate contributions in the months to come). These will not be put under CI, and may break with the monthly default update cadence. In order to attempt to allow these to be run by users, we would like to ask that the most recent major release remain available to the user when selecting a container, but not be selected as the default. We are not requesting that this major release be supported at any greater level than is currently occurring on the RSP at NCSA.
            4. We agree with the multi-checkoff process that Simon proposed for bumping a new release.

            Show
            kadrlica Alex Drlica-Wagner added a comment - We discussed this within the CET team with Leanne Guy and  Melissa Graham , and I think we largely agree on the points raised by Simon. To enumerate these: 1. The CET is not recommending that the default release be the last major release for long periods of time (i.e. 6 months). We do think that a slightly slower-moving default (i.e., once a month) based on a weekly version would probably be about the right cadence. We are under the impression that the first default version for DP0 will be major release v22. 2. The CET has started to develop a set of small tutorial notebooks that will be put under CI and should be verified to build on any new default release. 3. There are a set of larger and more complex notebooks contributed by the community that the CET does not support (one example is the Stack Club, and we expect more DP0 delegate contributions in the months to come). These will not be put under CI, and may break with the monthly default update cadence. In order to attempt to allow these to be run by users, we would like to ask that the most recent major release remain available to the user when selecting a container, but not be selected as the default. We are not requesting that this major release be supported at any greater level than is currently occurring on the RSP at NCSA. 4. We agree with the multi-checkoff process that Simon proposed for bumping a new release.
            Hide
            mgraham Melissa Graham added a comment -

            As a follow up (though maybe a little off-topic for this ticket) a question I think for Simon Krughoff and Frossie Economou – right now the CET is using https://github.com/rubin-dp0/tutorial-notebooks to assemble and develop the set of notebooks which would be put under CI. That same set would be what we want all RSP users to have in their default notebooks/tutorials folder, too. Is that repo OK to live in the rubin-dp0 org or should it live elsewhere, like in the lsst or lsst-dm orgs? 

            Show
            mgraham Melissa Graham added a comment - As a follow up (though maybe a little off-topic for this ticket) a question I think for Simon Krughoff  and Frossie Economou  – right now the CET is using https://github.com/rubin-dp0/tutorial-notebooks  to assemble and develop the set of notebooks which would be put under CI. That same set would be what we want all RSP users to have in their default notebooks/tutorials folder, too. Is that repo OK to live in the rubin-dp0 org or should it live elsewhere, like in the lsst or lsst-dm orgs? 
            Hide
            frossie Frossie Economou added a comment -

            Melissa Graham it doesn't matter where it is, as long as it's public - whatever works for you. Can you open a separate ticket on me to actually deploy it in the containers?

            Show
            frossie Frossie Economou added a comment - Melissa Graham  it doesn't matter where it is, as long as it's public - whatever works for you. Can you open a separate ticket on me to actually deploy it in the containers?
            Hide
            frossie Frossie Economou added a comment -

            Following Simon and Alex's meeting of minds, I consider this ticket resolved. Thanks all.  Simon Krughoff you might want to think what the right place is to document the process you outlined, I'm blanking. 

            Show
            frossie Frossie Economou added a comment - Following Simon and Alex's meeting of minds, I consider this ticket resolved. Thanks all.  Simon Krughoff you might want to think what the right place is to document the process you outlined, I'm blanking. 

              People

              Assignee:
              frossie Frossie Economou
              Reporter:
              frossie Frossie Economou
              Reviewers:
              Leanne Guy
              Watchers:
              Alex Drlica-Wagner, Colin Slater, Frossie Economou, Gregory Dubois-Felsmann, Ian Sullivan, Leanne Guy, Melissa Graham, Simon Krughoff, Tim Jenness, Yusra AlSayyad
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  CI Builds

                  No builds found.