DataONE Tasks: Issueshttps://redmine.dataone.org/https://redmine.dataone.org/favicon.ico2018-10-27T16:04:14ZDataONE Tasks
Redmine Infrastructure - Story #8738 (In Progress): HZEventFilter performance decline with increased task...https://redmine.dataone.org/issues/87382018-10-27T16:04:14ZRob Nahfrnahf@epscor.unm.edu
<p>While reindexing, I noticed that creating index tasks was taking about 300ms (when index_task table had about 30k records). Later in the index task generation, that duration increased to about 500 ms on average. (now it's at 600ms).</p>
<p>There are two calls to the database that search for the pid to check its status, and those filters are not against a field that is indexed (pid). Ideally, we should index that field.</p>
<p>At the very least, the 2 queries should be reduced to one query. This could be done without changing the ORM model we're using.</p>
<p>below is the table description in postgres:</p>
<pre>d1-index-queue=# \d index_task
Table "public.index_task"
Column | Type | Collation | Nullable | Default
---------------------+------------------------+-----------+----------+---------
id | bigint | | not null |
datesysmetamodified | bigint | | not null |
deleted | boolean | | not null |
formatid | character varying(255) | | |
nextexecution | bigint | | not null |
objectpath | text | | |
pid | text | | not null |
priority | integer | | not null |
status | character varying(255) | | |
sysmetadata | text | | |
taskmodifieddate | bigint | | not null |
trycount | integer | | not null |
version | integer | | not null |
Indexes:
"index_task_pkey" PRIMARY KEY, btree (id)
d1-index-queue=# \q
</pre> Member Nodes - Story #8727 (In Progress): NCAR Discovery & Assessmenthttps://redmine.dataone.org/issues/87272018-10-04T16:48:23ZAmy Forresteraforres4@utk.edu
<p>Establish contact and build relationship with a potential new member node. Determine if DataONE and the repository are a good fit for one another and if the repository generally meets the requirements of DataONE member nodes. </p>
<p>This story is complete when a determination is made to either proceed with a new deployment, or that joining DataONE is not an option for the repository at this time.</p>
Member Nodes - Story #8535 (In Progress): Neotoma: Story: Discovery & Planninghttps://redmine.dataone.org/issues/85352018-04-09T21:14:39ZAmy Forresteraforres4@utk.edu
<p>Discovery: establish contact and build relationship with a potential new member node. Determine if DataONE and the repository are a good fit for one another and if the repository generally meets the requirements of DataONE member nodes. </p>
<p>Planning: If the repository and DataONE have agreed to proceed with deployment as a member node. Decisions will be made as to how to proceed with development. Node operators will receive training. </p>
<p>This story is complete when a determination is made to either proceed with planning a new deployment, or that joining DataONE is not an option for the repository at this time.</p>
<p><strong>Record initial communication here</strong></p>
Member Nodes - Story #8358 (In Progress): Discovery & Planning (CAFF)https://redmine.dataone.org/issues/83582018-02-12T16:25:06ZAmy Forresteraforres4@utk.edu
<p>Discovery is about establishing contact and building a relationship with a potential new member node. In this phase, it is determined if DataONE and the repository are a good fit for one another and if the repository generally meets the requirements of DataONE member nodes. Broad discussions of deployment options may be reviewed as well.<br>
This story is complete when a determination is made to either proceed with planning a new deployment, or that joining DataONE is not an option for the repository at this time.</p>
Member Nodes - Story #8225 (In Progress): Customize Indexing & View for gmd-pangaeahttps://redmine.dataone.org/issues/82252017-12-06T19:41:28ZMonica Ihliemail@monicaihli.com
<p>An example metadata record: <a href="http://cn-sandbox.test.dataone.org/cn/v2/object/doi:10.1594/PANGAEA.877809_.201711172109">http://cn-sandbox.test.dataone.org/cn/v2/object/doi:10.1594/PANGAEA.877809_.201711172109</a></p>
<p>This record in the search interface on sandbox: <a href="https://search-sandbox.test.dataone.org/#view/doi:10.1594/PANGAEA.877809_.201711172109">https://search-sandbox.test.dataone.org/#view/doi:10.1594/PANGAEA.877809_.201711172109</a></p>
<p>Currently, alternate access point is pulling the link from:<br>
/ns0:MD_Metadata/ns0:distributionInfo[ 1 ]/ns0:MD_Distribution[ 1 ]/ns0:transferOptions[ 1 ]/ns0:MD_DigitalTransferOptions[ 1 ]/ns0:onLine[ 1 ]/ns0:CI_OnlineResource[ 1 ]/ns0:linkage[ 1 ]/ns0:URL[ 1 ]</p>
<p>However, Pangaea wishes users to be directed towards a landing page where they are able to obtain METADATA in multiple formats, found in:<br>
/ns0:MD_Metadata/ns0:dataSetURI[ 1 ]/ns2:CharacterString[ 1 ]</p>
<p>The landing page for this example: <a href="https://doi.pangaea.de/10.1594/PANGAEA.877809">https://doi.pangaea.de/10.1594/PANGAEA.877809</a></p>
Python GMN - Story #8032 (In Progress): GMN v2https://redmine.dataone.org/issues/80322017-03-02T18:25:18ZRoger Dahldahl@unm.edu
<p>GMN v2 related tasks that don't require their own story.</p>
Search UI - Story #7754 (In Progress): Support for XSL transform of various metadata formatshttps://redmine.dataone.org/issues/77542016-04-27T14:43:23ZDave Vieglaisdave.vieglais@gmail.com
<p>Currently the DCX and ISO metadata formats are being rendered in the view service using solr output rather than a transform of the XML metadata. This results in a less than satisfactory rendering.</p>
<p>Goal of this story is to implement XSLT for metadata formats that currently are relying on the solr only rendering.</p>
Infrastructure - Story #7358 (In Progress): ContactSubject on NodeList must be valid D1 ldap entryhttps://redmine.dataone.org/issues/73582015-09-16T19:58:13ZRobert Waltz
<p>Before a CN can be started, LDAP must have an approved entry for Contact Subject.</p>
<p>Contact Subject has been defaulted to CN=Robert P Waltz A904,O=Google,C=US,DC=cilogon,DC=org on all of the CN entries in the node list.</p>
<p>Since Robert P Waltz is a developer and not an organizer or director, then the publicized contact on the CNs should be changed to reflect the organizational hierarchy.</p>
<p>The Contact Subject for the CNs should be the PI of the project, or at least, a Co-PI.</p>
<p>Also, The DN of this subject should be derived from the DataONE CA instead of cilogon.</p>
<p>Updating the existing systems should be trivial. The Ldap Entry for each CN node will be modified, and a new LDAP entry for the new Subject will need to be added.</p>
Python GMN - Story #7219 (In Progress): Upgrade Django version used by GMN, add better support fo...https://redmine.dataone.org/issues/72192015-06-16T14:56:59ZDave Vieglaisdave.vieglais@gmail.comOGC-Slender Node - Story #7151 (In Progress): Generate system metadata for contenthttps://redmine.dataone.org/issues/71512015-06-04T20:24:16ZDave Vieglaisdave.vieglais@gmail.com
<p>For the three types of content (resource, science meta, data), develop a mechanism to provide system metadata.</p>
OGC-Slender Node - Story #7149 (Testing): Implement mechanism to retrieve a list of objects avail...https://redmine.dataone.org/issues/71492015-06-04T20:20:47ZDave Vieglaisdave.vieglais@gmail.com
<p>Using Python, implement a tool that is able to retrieve a list of packages, and the objects that make up each package.</p>
OGC-Slender Node - Story #7146 (In Progress): Determine formatId for content retrievable from NOD...https://redmine.dataone.org/issues/71462015-06-04T20:15:08ZDave Vieglaisdave.vieglais@gmail.com
<p>In order to create system metadata for objects held by NODC, it is necessary to infer the appropriate formatId for each object.</p>
Member Nodes - Story #5833 (In Progress): GBIF: Developinghttps://redmine.dataone.org/issues/58332014-07-17T21:05:32ZRoger Dahldahl@unm.edu
<p>Determine which software stack to use, etc.</p>
Infrastructure - Story #4052 (In Progress): OPeNDAP MN Storyhttps://redmine.dataone.org/issues/40522013-10-06T20:07:50ZBruce Wilsonbwilso27@utk.edu
<p>There are a large number of possible DataONE MN's running Data Access Protocol (DAP) compliant servers, particularly servers based on the OPeNDAP Hyrax and UCAR THREDDS servers. The objective of this work is to develop a MN stack that can be used with at least one of these DAP-compliant software stacks as a low-barrier route to becoming a Tier 1 MN.</p>
Java Client - Story #3666 (In Progress): D1Client.listUpdateHistory() needs to handle changing ac...https://redmine.dataone.org/issues/36662013-03-15T22:51:23ZRob Nahfrnahf@epscor.unm.edu
<p>the current D1Client.listUpdateHistory() method needs to gracefully handle the situation where a NotAuthorized request is returned. the ObsoletesChain client class may need to be refactored to allow for this exception to be held so it can notify the user where appropriate.</p>
<p>Ostensibly, with a NotAuthorized, the user will not have access to either the tail or head of the chain, so can't return the head or tail, depending on how access changes.</p>