Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* dwilcox joins07:29
* github-ff joins07:43
[fcrepo4] claussni closed pull request #1272: Improve mediatype validation on ingest (master...fcrepo-2520) https://git.io/vb3d6
* github-ff leaves
* dwilcox leaves08:39
* dhlamb joins08:44
* bseeger joins08:49
* dwilcox joins08:59
* peichman joins09:12
* yamil joins09:19
* bryjbrown__ joins09:37
* bryjbrown_ joins09:56
* bryjbrown__ leaves09:59
* peichman1 joins10:02
* apb18 joins10:03
* peichman leaves10:04
* benpennell joins10:11
* westgard joins10:26
* whikloj joins10:43
<westgard>awoods: ping10:44
awoods: I will not be able to be at the fedora tech meeting today.10:45
I will catch up my starmaster duties another time!
<awoods>westgard: thanks for the heads-up
<westgard>I have completed some of the tests for the current RC and will continue to test on the new RC over the coming days
I will be at the instructors meeting10:46
<awoods>westgard++10:47
* benc__ joins10:59
* escowles joins
<bseeger>https://wiki.duraspace.org/display/FF/2018-01-25+-+Fedora+Tech+Meeting11:01
* dbernstein joins
* bryjbrown_ leaves11:02
* bryjbrown_ joins
* escowles is here
<benpennell>so many bens
<bseeger>hi bens!11:03
<benc__>hey everyone
<dbernstein>https://wiki.duraspace.org/display/FF/2018-01-25+-+Fedora+Tech+Meeting
* whikloj is here11:05
always later
<awoods>benc__: http://mail.asis.org/pipermail/pasig-discuss/2017-December/000666.html11:06
http://mail.asis.org/pipermail/pasig-discuss/2018-January/000704.html
<benc__>thanks
<benpennell>the first "ben" is benpennell rather than ben armintor, fyi
* kefo joins11:07
<benpennell>also i think kevin ford needs to mute microphone
<awoods>kefo: did you bring some background humming?
https://github.com/fcrepo4/fcrepo4/commit/cab6f05305e26cf7b0aa818e6683dda422c6984d11:13
* ylchen joins
<escowles>fwiw, we're running 4.7.4 with postgres and it's definitely using postgres
<kefo>Yeah, I would be surprised if this were a problem in 4.7.4. Surely it would have been noticed by now....11:16
<bseeger>we could put that out to the community - who uses windows?11:20
<whikloj>bseeger++
<apb18>bseeger: I do use Windows, but I'm on another call and didn't hear the question that propmpted "who uses windows"
<bseeger>apb18 - discussion of this issue: https://jira.duraspace.org/browse/FCREPO-2665?src=confmacro11:21
<apb18>oh, that one.11:22
I think there was an earlier issue in JIRA about it as well, which may be closed now11:23
<bseeger>apb18 - I think the question is how much should we actually support windows (or at least windows 10)
I agree - it shouldn't be a blocker and I don't think it even needs to go into 4.7.511:24
<apb18>to me, its only use is "verifying correctness, since it is a weird platform for which some assumptions don't apply"
<peichman1>whikloj++
<apb18>also, it's very picky about closing open files.
* apb18 is on the call now11:25
<bseeger>apb18 - we are talking about a RC-3 to fix an error about fedora not using postgres when configured for it.11:26
<apb18>huh
<whikloj>Once we have a ticket I'd love to try and verify the issue
<apb18>interesting
<kefo>Also not using mysql
<ylchen>what's the decision of FCREPO-2666?11:29
<whikloj>ylchen: not make it a blocker
<ylchen>ok
<whikloj>ylchen: just try to resolve it when there is time and someone to do the work11:30
<peichman1>I will have my scheduling availability by COB tomorrow11:31
* apb18 had forgotten to update it, and added a (4) to the pairtree/apple tree page this morning11:32
https://wiki.duraspace.org/display/FF/Design+-+Identifier+Generation11:33
<bseeger>but maybe it's a non-issue11:38
<escowles>i think it's an issue — using the pairtree structure to segment the repository to workaround the limits helped @peichman1 be able to reindex, for example
<peichman1>escowles++11:39
what would happen if we elevated the pairtree nodes to full container status?11:40
I guess we would lose the ldp:contains relationship between the logical parent and its children11:41
<escowles>yes, you would always have to navigate the pairtree structure to find the children11:42
<apb18>escowles: yes, (4) is specifically intended to remove the ability to use pairtrees for partitioning membership from the client side.
It's a modeshape-ism that would be difficult to implement and maintain outside of fcrepo-upon-modeshape11:43
<escowles>i think i would prefer the opposite: go with (3), allow people to configure pairtrees if they want to do that, but stop hiding them if they exist
<apb18>I'm strongly -1 to that idea.11:44
(the idea of them having a representation that enumerates their chilfren)11:46
<benpennell>has anyone observed if there are any gains aside from time to first byte for using n-triples vs turtle?11:50
<peichman1>apb18++11:54
<dbernstein>sorry folks - I just got dropped.11:55
I’m back here.11:56
<apb18>Flat identifiers as the default, keep pairtree URI minter, and implement (4) - 404s for pairtrees, absent a partitioning spec
escowles++ yes, effort better spent removing need for workarounds. but I'm uncomfortable carrying them forward11:57
<escowles>apb18: i'm also not happy about carrying them forward, but i fear that any changes will seem just as awkward a couple of years from now (and in the meantime will make it hard for some folks to migrate)12:00
<awoods>benc__: there have been some talks with the folks at Oxford regarding a Fedora impl on top of an OCFL backend.12:01
<ylchen>Minutes done, please feel free to updat
* ylchen leaves
<benc__>awoods: thanks. I'll look into the OCFL calls you linked to, and try to follow the developments.12:02
<awoods>benc__: there is also discussion of a sidecar capability in any Fedora impl to either based on messages, or on-demand, export OCFL-structured representations on disk.12:03
benc__: do you have a particular model or interest in mind?
<benc__>we have a large enough repo (~28T) that it seems like data migrations are a hassle that we'd like to avoid. Seems like if we have a standard for how data is stored on disk, we may be able to avoid data migrations, even if/when software is updated.12:04
<awoods>benc__: that is a common concern... and one that will increase over time.12:05
<benc__>so common agreement on how to store content on the filesystems, and then software that works with that content, could be nice for our situation.
<awoods>benc__: "filesystem as an API"12:06
<benc__>update/change software, but don't change all the data.
yup
<awoods>benc__: You will want to review the first OCFL meeting recording. There was a fair amount of discussion along those lines.
benc__: Did you get the links above?
<benc__>ok, great.
yup
<escowles>benc__: yep, i think that's a nice improvement on the current external-content approach — storing files outside the repo, but use a standard layout to make that work better
<benc__>escowles: if there were a standard filesystem layout that prevented many data migrations, would you still want to go with external content?12:08
<escowles>if my repository could use it natively, i guess not — but i don't know if fedora will do that12:09
<awoods>benc__/escowles: it is worth noting that the OCFL effort is separate from Fedora. From the Fedora (specification) perspective, there is good reason not to tie implementations to specific file layouts...
benc__/escowles: but various Fedora implementations can approach this differently.
<apb18>escowles: The problem is that pairtrees "as exposed for the purpose of partitioning" not really sustainable. Maybe the compromise is to have 404s by default, and setting (or add-on) to enable the old behaviour, noting that it's deprecated or unsupported12:10
I still stand by the notion that if it *is* truly an important thing to do irrespective of implementation, workarounds, etc.. then it ought to be a spec.12:11
<benc__>awoods: I might put more value on designing a standard for the data layout that all the software conforms to, than on standardizing the application api for the software.12:12
<awoods>apb18: I think it is a workaround
<apb18>escowles, In other words, enabling the "pairtree" ID generator is distinct from ".. and expose their content"
awoods: So do I.
<escowles>awoods: apb18: a workaround for sure, but a common one with analogues in filesystem pairtrees12:13
<awoods>benc__: there are different levels of abstraction and different concerns. Application API and persistence specification speak to different audiences.
<apb18>escowles: Yeah, but the filesystem analogy already can be implemented in user-space - just create the intermediate containers yourself. Then they are first-order LDP constructs12:14
<escowles>imho, we should go with the simplest identifier generation option (#3), and make it easier for people to configure the behavior they want (whether that's the current behavior, or appletrees, or something else)12:15
i hope that we could revisit the work that acoburn and barmintor did to simplify the identifier translation and use caching etc. to improve performance, now that versioning doesn't complicate that as much12:16
<apb18>escowles: Identifier generation is fine, and ought to be simple. I just think it's the special behaviours that happen with pairtree nodes and LDP membership that is problematic.12:17
i.e. it should be a separate config option, next to a red, blinking "THERE BE DRAGONS" sign.
<escowles>i would be +1 to adding a "THERE BE DRAGONS" sign on the pairtree behavior as it stands now12:18
<apb18>That's a happy compromise :)
<escowles>indeed — i really don't like the current behavior — i just feel like the alternatives are not dramatically better, and know that any change will inconvenience someone12:19
<apb18>Yeah. If people have to take positive action (a config option) to retain the old behaviour, that at least brings it into their mindspace that there is a problem in search of a solution.12:22
<whikloj>kefo: I just setup 4.7.5-RC-2 against MySQL and I do see more items included in the MODESHAPE_REPOSITORY table for each I add through the HTML UI. Not that I totally understand it, but how would I tell if it was using the file-simple storage?12:35
* benpennell leaves12:36
* benpennell joins12:40
<apb18>whikloj: (I'm missing the context for the conversation, but..) I've noticed that there is a base number of nodes always present (a few hundred, maybe), and that each repository resource corresponds to multiple rows in the Modeshape table. Maybe 2 or so?12:48
It's opaque to me what is going on, but I see "a lot more" rows in the modeshape table than there are repository resources.12:49
<whikloj>apb18: kefo found that testing RC-1 stuff was going into MySQL and Postgres but testing RC-2 it was not and he believed it was defaulting to the file-simple repository config.12:50
apb18: and yes an empty repo has 265 rows of data in the MODESHAPE_REPOSITORY table;
<apb18>whikloj: I *think* there is some setting that allows content to be inlined in the database, rather than persisted in the file store?12:51
on paper, it's size that matters.. but I've seen things persisted in the file store that violate that threshold, so I really don't know what Modeshape is doing12:52
<whikloj>apb18: I don't know, I noticed that the wiki config page still has information on configuring the ISPN database using JNDI. Which I believe is no longer used.
<apb18>It's a bit of a black box to me12:53
<whikloj>agreed
<apb18>but anyway, the ISPN stuff is definitely obsolete
<awoods>whikloj: there is ISPN documentation floating around?12:54
<whikloj>awoods: https://wiki.duraspace.org/display/FEDORA4x/Configuring+JDBC+Object+Store
JNDI Configuration is for ISPN
unless it can be used for the fcrepo DB, but I tried and couldn't figure it out12:55
<awoods>whikloj: the use of "ispn" on that page is effectively a variable name... which should be changed.
<whikloj>awoods: right but to use that context file you have to edit the infinispan.xml. Where is that?12:56
<awoods>whikloj: gone
<whikloj>awoods: ok, I thought maybe I just missed it
<awoods>whikloj: it would be helpful to walk through those instructions and make them correct. Thanks for surfacing it.
* benpennell leaves12:57
<whikloj>awoods: I don't see that the resource can be used to replace the system properties. So there is definitely something to be done in the repository.json...I'm just not sure what
<awoods>whikloj: which "resource" are you referring to?12:58
<whikloj>awoods: The one we define in the fcrepo.xml context file
* benpennell joins13:00
* dwilcox leaves13:02
* westgard leaves13:07
* dwilcox joins13:25
* benc__ leaves13:26
* bryjbrown_ leaves14:08
* bryjbrown joins
* dwilcox leaves15:14
* dwilcox joins15:32
* bseeger leaves16:28
<kefo>For those interested: https://jira.duraspace.org/browse/FCREPO-266716:37
* bryjbrown leaves16:49
* benpennell leaves17:15
* yamil leaves17:40
* peichman1 leaves17:43
* dhlamb leaves18:02
* whikloj leaves
<kefo>dbernstein: I *thought* I saw the problem in 475-rc1, too, yesterday with mysql but I could not reproduce it today.18:21
dbernstein: Today, I was very methodical. I cleaned up completely between attempts.18:22
<dbernstein>oh - that could be it. Possibly the existence of the fcrepo4-home directory might have thrown me off.18:23
<kefo>dbernstein: Did you clear out your fcrepo_data directory *before* running 4.7.5-rc1 after encountering the issue with rc2? If yes, OK. If not, do you see the problem with rc1 *after* clearing fcrepo_data?
* apb18 leaves
<dbernstein>right - I’ll try clearing the data directory before runnning it.18:24
* escowles_ joins18:30
* escowles leaves18:32
* benpennell joins18:35
* benpennell leaves19:12
* kefo leaves19:24
* escowles_ leaves19:37
* apb18 joins20:26
* dwilcox leaves20:40
* apb18 leaves22:37
* awoods leaves23:24
* benpennell joins23:39
* benpennell leaves23:54
* dbernstein leaves00:05