List view
Currently, partitioning works correctly for files that are large, and static. One can split a file into p partitions and have them traverse a network of pumps, and the partitions will be re-assembled only at the end where final consumers want them to be reassembled. so far, so good. When transferring partitions, the parts get the following suffix: .part.bsz,blktot,brem,bno (see sr_post(7) and sr_postv3(7) for detailed meaning of the fields) the problem with this suffix is that blktot, and brem will change as the file grows. So the resolution for this is for the partition file name suffixes to be something like: .part.bsz,bno and persist the full partition info to disk (xattr.) use cases we have difficulty with right now: log files, backups, genetic code dumps... Approach: 1. build a reproducible test case (start with a small file) announce it in partitions, transfer as partitions, then re-assemble at a second hop. 2. start appending to the file to reproduce the problem. 3. fix it.
No due date•3/8 issues closedOur configuration interface is not actually covered by our tests, but it is a key component of Sarracenia. It has specifications (link here) that would need to be tested as it is the front line of our application. Also we could enhance it, using a parser that already exist instead of parsing everything ourself, hence by decoupling syntax intepretation from semantic interpretation it would make the config api more stable and easier to maintain. A TDD fashion way would be the best way to do that Step 1: List all supported/deprecated/rejected configuration Step 2: Write unit test for the parser, configuration syntax Step 2a: Run the tests, go to Step 2 if it fails Step 3: Write unit test for the interpreter, configuration semantic / post interpretation Step 3a: Run the tests, go to Step 3 if it fails Step 4: Write code that decouple syntax from semantic with the old code Step 4a: Run the tests, go to Step 4 if it fails Step 5: Migrate syntax parser to argparse Step 5a: Run the tests, go to Step 5 if it fails Step 6: Migrate semantic interpretation Step 6a: Run the tests, go to Step 6 if it fails
Overdue by 4 year(s)•Due by September 1, 2020We need to evaluate what is our current test coverage, if we want to improve it. Usually, this is a good measurement of quality and the easiest way to evaluate our current coverage will be to run our test and then calculate: total LOC tested / total LOC of sarra * 100
Overdue by 5 year(s)•Due by November 1, 2019Step 0: full v03 support (message in JSON body rather than AMQP headers), required to work MQTTv3 compatibility. Step 1: ability to send to an MQTT broker (exp_2mqtt.py) Step 2: Would like to see if MQTT clients can consume from a Sarracenia data pump, using the rabbitmq mqtt plugin. Step 3: ?
No due date•4/4 issues closed