Description
The 3rd party Jira package, including the python Jira API, will be useful for automatically creating/updating Jira DRP (or other production tickets) from within the operations production environment. For instance, this allows a data production campaign to be defined ahead of execting the campaign, and allows the status of the steps of the campaign to be updated as part of the 'bps submit' process.
For DP0.2, the operators, specially installed Jira on their submit machine node to gain access to the functionality (available as part of the prodstat module).
While the ops-campaign-tooling is currently in flux, and will change, it is likely that at some level it will be convienent to update Jira tickets automatically as part of campaign execution, so it will be useful to have Jira as a product that can be 'setup' along with the operations stack.
We also note that currently Jira requires a passwd login, which is handled with a .netrc file for each operator. Eventually this will transition to a token or other authentication mechanism, at which time the version of the Jira interface will need to be updated.
Attachments
Activity
Brian Yanny what is the lifetime of your prodstat tooling that is using Jira? Eric Charles are you intending to use Jira at all for your replacement?
The prodstat tool which uses Jira is a 'transition' product which documents the DP0.2 production computing resources used. We expect it will become static when the current revision is done and reviewed (PREOPS-1041). In this sense we don't need Jira for prodstat to be integrated into the overall lsst_distrib stack. We expect some features of prodstat may be carried over into the next production campaign tools now under development. Specifically, it may be useful to have ``bps submit step1-group4.yaml`` insert information into a Jira issue ticket automatically, and it may be useful for whatever database is used to track campaign information to be able to create/update Jira tickets which point to or read from that database. To make these issues automatic, it would be useful to have the python Jira interface available as part of the lsst_distrib stack, or at least 'set-up-able'. It may also be useful to be able to automatically connect requests to perform certain processing campaigns (described by a Jira ticket) with the database that tracks these campaigns, but I don't think the details have been decided.
Brian Yanny
added a comment - The prodstat tool which uses Jira is a 'transition' product which documents the DP0.2 production computing resources used. We expect it will become static when the current revision is done and reviewed (PREOPS-1041). In this sense we don't need Jira for prodstat to be integrated into the overall lsst_distrib stack. We expect some features of prodstat may be carried over into the next production campaign tools now under development. Specifically, it may be useful to have ``bps submit step1-group4.yaml`` insert information into a Jira issue ticket automatically, and it may be useful for whatever database is used to track campaign information to be able to create/update Jira tickets which point to or read from that database. To make these issues automatic, it would be useful to have the python Jira interface available as part of the lsst_distrib stack, or at least 'set-up-able'. It may also be useful to be able to automatically connect requests to perform certain processing campaigns (described by a Jira ticket) with the database that tracks these campaigns, but I don't think the details have been decided.
No plans to use jira.
It sounds like there is not a general need for Jira to be added to the env given the lifetime of prodstat and no other users stating a need for it. The DM-CCB have decided they do not want to adopt this RFC.
This is ~60 kbytes but also pulls in requests-oauthlib (~20 kbytes) and requests-toolbelt (~40 kbytes). So size is not an issue.
It sounds like this could possibly go into the proposed rubin-env-developer (assuming those are the people who might use campaign management), rather than rubin-env-extras (which is not typically installed anywhere). Or it could go into rubin-env-extras, and we could install it in the USDF shared stack. In either case, it should probably not go into the RSP containers.
I'm not sure why a version update is needed to go to tokens. No particular version seems to be being requested here, and given the dependency on oauthlib, I'd imagine that tokens are already capable of being handled. We would normally not pin the jira package version anyway.