Samza Mesos

[Sriram Ramachandrasekaran]

Folks,

We've been using Samza in Production from beginning of this year. It's been
quite stable for our needs, although, we don't use it heavily yet. One of
the things we would like to know is, where is Samza Mesos integration in
the roadmap? I know, SAMZA-375
 is specifically towards
that, but, is there something stopping the community from integration into
mainline?

I ask this because, we run our Samza jobs on YARN right now and we use
Mesos infra for other workloads. I really don't want to manage 2 infra
components which are supposed to do exactly the same thing. We've built
enough tooling around Mesos infra, so, wouldn't want to move away from it
too.

The options we're evaluating are:
1. Move to KStreams and get away from YARN
2. Explore Samza-Mesos integration so that, we can reduce "explicit"
dependency on Kafka.


Some clarity on this would really help us.
Sriram

-- 
It's just about how deep your longing is!

Re: Review Request 47835: SAMZA-914: Initial draft for Java programming APIs on operators supporting DAGs

[Jake Maes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/47835/#review147209
---



Mostly minor feedback like naming issues so far. 
I hopped around a bit, but my thorough review will pick up at WindowOutput 
(which I'm currently trying to understand why it's in the API)


build.gradle (line 349)


It would be nice to NOT have an avro dependency or constrain it to a 
testCompile.



samza-operator/src/main/java/org/apache/samza/operators/api/MessageStream.java 
(line 52)


Naming:
When I read "*System*MessageStream", my first interpretation is that it 
represents a stream of system messages. e.g. for coordination, the common case 
for broadcast streams.

After browsing the code, I think a better name for this is "SourceStream" 
or "InputStream"

Also, it doesn't seem to be adding much value. The private fields have no 
accessors. Is this placeholding for something more significant later?



samza-operator/src/main/java/org/apache/samza/operators/api/MessageStream.java 
(line 80)


Minor: 
I saw K2 and M2 and found myself asking "where are K1 and M1, and do I need 
them?" I see now that the goal was to avoid "hiding" K and M from 
MessageStream, but are there any better options?

I first thought OK and OM for output key and output message, but then it 
seems like each operator is getting ready to meditate. :-)

Maybe?
OperatorBase
T=type

Same for each of the Operators



samza-operator/src/main/java/org/apache/samza/operators/api/MessageStream.java 
(line 84)


Naming:
output D Stream. "D" stands for data?
Is it needed?



samza-operator/src/main/java/org/apache/samza/operators/api/MessageStream.java 
(line 147)


I think it would be useful to call out why SinkFunction is the only one 
that needs a MessageCollector and TaskCoordinator. 

I believe the reason for TaskCoordinator is because Sink is terminal, so 
that is the only place you need to commit(). I'm not sure about the 
MessageCollector though. It seems like it should be consistent with 
StreamOperator. Either both should have collectors or neither... unless I'm 
missing something.



samza-operator/src/main/java/org/apache/samza/operators/api/MessageStream.java 
(line 152)


It's odd that the Java Function class is used for the 1 parameter case but 
we define a completely independent interface for the multi-parameter case. 

Maybe there should be a new @FunctionalInterface for this case.

http://stackoverflow.com/questions/27872387/can-a-java-lambda-have-more-than-1-parameter



samza-operator/src/main/java/org/apache/samza/operators/api/MessageStream.java 
(line 385)


Should this have generics so users can have specific types at the very 
beginning or is that not possible until at least one user-defined op has 
processed and declared the types?



samza-operator/src/main/java/org/apache/samza/operators/api/Scan.java (line 28)


Naming:
Maybe it's just me and maybe I'm not seeing the big picture of use cases, 
but I still don't find this class name intuitive. Scan is a verb that makes 
some sense if the input is a table but I've never heard someone describe a 
"scan" of a stream. Further, to me, scan is a "read" operation and it would be 
unintuitive for it to have side effects like extracting keys and timestamps.   

Also, it seems like this will only be used at the entry points of the DAG. 
If so, it should be the antithesis of "sink" so I'd call it "source"
Source.createWithExtractors(te, ke)
Source.createWithKeyExtractor(ke)
Source.createWithTimestampExtractor(te)

Alternatively, if this could be used in the middle of the DAG, it could be 
MessageStream.createWithExtractors(te, ke)
MessageStream.createWithKeyExtractor(ke)
MessageStream.createWithTimestampExtractor(te)

Neither of the above are verbs so here are some other options:
Preprocess
Normalize
Decorate
Annotate
Extract
Enrich (or any of its synonyms)

I know they may be less concise, but they all feel clearer to me. Normalize 
and Enrich are my current favorites.



samza-sql-core/src/main/java/org/apache/samza/sql/data/avro/AvroData.java 
(lines 51 - 63)


I know this isn't part of the current patch but this smells funky. All the 
@Overrides are Unsupported..., and then 

Re: Review Request 51252: SAMZA-1004: Fix some logging and javadoc issues for AsyncStreamTask

[Navina Ramesh]

> On Aug. 30, 2016, 10:37 p.m., Prateek Maheshwari wrote:
> > samza-api/src/main/java/org/apache/samza/task/AsyncStreamTask.java, line 36
> > 
> >
> > s/serialized/serial?

+1


- Navina


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51252/#review147373
---


On Aug. 30, 2016, 10:01 p.m., Xinyu Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51252/
> ---
> 
> (Updated Aug. 30, 2016, 10:01 p.m.)
> 
> 
> Review request for samza, Navina Ramesh and Yi Pan (Data Infrastructure).
> 
> 
> Repository: samza
> 
> 
> Description
> ---
> 
> SAMZA-1004: Fix some logging and javadoc issues for AsyncStreamTask
> 
> 
> Diffs
> -
> 
>   samza-api/src/main/java/org/apache/samza/task/AsyncStreamTask.java 
> 684ba0b77fca1c1c5fd8d740597d3b7fcdc0f5cb 
>   samza-core/src/main/scala/org/apache/samza/container/SamzaContainer.scala 
> f786fc08c8f7eced4f4084dc8326b28b6422 
> 
> Diff: https://reviews.apache.org/r/51252/diff/
> 
> 
> Testing
> ---
> 
> gradlew clean build.
> 
> 
> Thanks,
> 
> Xinyu Liu
> 
>

Re: Review Request 50174: SAMZA-977: User doc for samza multithreading

[Navina Ramesh]

> On Aug. 25, 2016, 12:31 a.m., Navina Ramesh wrote:
> > Not that I intend to give you more work. However, adding an example of 
> > AsyncStreamTask to samza's hello-world will give a quick idea to the user 
> > on when to use it and how to use it. This can be augmented in a tutorial 
> > page, similar to the one Jake provided for samza-rest api. Thanks!

Any updates here, xinyu ?


- Navina


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50174/#review146739
---


On Aug. 30, 2016, 12:49 a.m., Xinyu Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50174/
> ---
> 
> (Updated Aug. 30, 2016, 12:49 a.m.)
> 
> 
> Review request for samza, Chris Pettitt, Navina Ramesh, and Yi Pan (Data 
> Infrastructure).
> 
> 
> Repository: samza
> 
> 
> Description
> ---
> 
> Update samza web docs with new multithreading api, core and configs.
> 
> 
> Diffs
> -
> 
>   docs/learn/documentation/versioned/api/overview.md 
> 6712344e84e19883b857e00549db2acb101c7e0e 
>   docs/learn/documentation/versioned/container/event-loop.md 
> 116238312df7071747cbbc14bc9c46f558755195 
>   docs/learn/documentation/versioned/jobs/configuration-table.html 
> 54c52981c3055b398ee60af50eeaf2592ed0e64f 
> 
> Diff: https://reviews.apache.org/r/50174/diff/
> 
> 
> Testing
> ---
> 
> Test the web pages locally.
> 
> 
> Thanks,
> 
> Xinyu Liu
> 
>

Re: Review Request 50174: SAMZA-977: User doc for samza multithreading

[Navina Ramesh]

> On Aug. 25, 2016, 12:30 a.m., Navina Ramesh wrote:
> > docs/learn/documentation/versioned/jobs/configuration-table.html, line 360
> > 
> >
> > Isn't there a performance impact if we use AsyncStreamTask by default? 
> > Esp. on jobs that don't need any async processing. 
> > Why is the default value false? 
> > 
> > If users upgrade to the new version and automatically start using 
> > multithreaded execution, will they see any performance impact?
> 
> Xinyu Liu wrote:
> The default of new AsyncRunLoop is still running in a single thread, and 
> the performance is on par with the previous RUnLoop. So the users shouldn't 
> see any perf difference.

Ok. I think the performance results are pretty important. Can you add a link to 
the performance test results pdf - 
https://issues.apache.org/jira/secure/attachment/12812335/perf-test-results.pdf,
 probably appropriate in the event-loop.md where you mention the guarantees 
that Samza provides.


- Navina


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50174/#review146554
---


On Aug. 30, 2016, 12:49 a.m., Xinyu Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50174/
> ---
> 
> (Updated Aug. 30, 2016, 12:49 a.m.)
> 
> 
> Review request for samza, Chris Pettitt, Navina Ramesh, and Yi Pan (Data 
> Infrastructure).
> 
> 
> Repository: samza
> 
> 
> Description
> ---
> 
> Update samza web docs with new multithreading api, core and configs.
> 
> 
> Diffs
> -
> 
>   docs/learn/documentation/versioned/api/overview.md 
> 6712344e84e19883b857e00549db2acb101c7e0e 
>   docs/learn/documentation/versioned/container/event-loop.md 
> 116238312df7071747cbbc14bc9c46f558755195 
>   docs/learn/documentation/versioned/jobs/configuration-table.html 
> 54c52981c3055b398ee60af50eeaf2592ed0e64f 
> 
> Diff: https://reviews.apache.org/r/50174/diff/
> 
> 
> Testing
> ---
> 
> Test the web pages locally.
> 
> 
> Thanks,
> 
> Xinyu Liu
> 
>

Re: Review Request 50174: SAMZA-977: User doc for samza multithreading

[Navina Ramesh]

> On Aug. 25, 2016, 12:30 a.m., Navina Ramesh wrote:
> > docs/learn/documentation/versioned/container/event-loop.md, line 49
> > 
> >
> > Does anything change with respect to adding "task.subtask.class" in the 
> > process() method of AsyncStreamTask? Please check if this does not change 
> > the expected behavior in SAMZA-437. We use that at LinkedIn for 
> > restliWrapper (I think).
> 
> Xinyu Liu wrote:
> This is actually not implemented in open source, only in LinkedIn.

Ah.. looks like we added and then, removed it. The JIRA still explains the 
pattern that the developer can use. Cool!


- Navina


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50174/#review146554
---


On Aug. 30, 2016, 12:49 a.m., Xinyu Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50174/
> ---
> 
> (Updated Aug. 30, 2016, 12:49 a.m.)
> 
> 
> Review request for samza, Chris Pettitt, Navina Ramesh, and Yi Pan (Data 
> Infrastructure).
> 
> 
> Repository: samza
> 
> 
> Description
> ---
> 
> Update samza web docs with new multithreading api, core and configs.
> 
> 
> Diffs
> -
> 
>   docs/learn/documentation/versioned/api/overview.md 
> 6712344e84e19883b857e00549db2acb101c7e0e 
>   docs/learn/documentation/versioned/container/event-loop.md 
> 116238312df7071747cbbc14bc9c46f558755195 
>   docs/learn/documentation/versioned/jobs/configuration-table.html 
> 54c52981c3055b398ee60af50eeaf2592ed0e64f 
> 
> Diff: https://reviews.apache.org/r/50174/diff/
> 
> 
> Testing
> ---
> 
> Test the web pages locally.
> 
> 
> Thanks,
> 
> Xinyu Liu
> 
>

Re: Review Request 50174: SAMZA-977: User doc for samza multithreading

[Navina Ramesh]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50174/#review147388
---




docs/learn/documentation/versioned/api/overview.md (line 49)


// fire callback after process complete 
>> Is the user expected to invoke the callback here or is it samza that 
invokes the callback ? Not clear from the example. If the user has to invoke 
the callback, you can write the code snippet. 

In your previous diff, you had this line - "To complete the process, you 
need to call callback.complete() or callback.failure(). Samza will continue to 
process next message or shut down the job based on the callback status." . Is 
that still valid?



docs/learn/documentation/versioned/container/event-loop.md (line 28)


"any state change from one operation will be fully visible to others"?  -> 
does this mean tasks share state (which in my opinion can be anything from 
shared variables to KV stores). What state change is made fully visible here? 
I think it is sufficient to say that these operatios within a task 
partition are mutually exclusive. You can probably remove the state change part.



docs/learn/documentation/versioned/container/event-loop.md (line 45)


Thanks for adding the semantics section. Really clarifies things!



docs/learn/documentation/versioned/container/event-loop.md (line 52)


"This allows multiple outstanding messages to be processed per task at a 
time" -> I think it should be "This allows multiple outstanding messages to be 
processed parallely by the task".



docs/learn/documentation/versioned/container/event-loop.md (line 56)


It feels like we are introducing new terms here "serialized mode". I think 
it is sufficient to simply state, if task.max.concurrency = 1, then each 
message process completion ...

Also "it is required to coordinate any shared state" can be re-phrased to 
"user should synchronize access to any shared/global variables in the Task."



docs/learn/documentation/versioned/jobs/configuration-table.html (line 357)


Is it too late to comment on the config key pattern? Traditionally, we 
don't have any strict conventions for config names listed anywhere. Since we 
use period as a delimiter to distinguish configs belonging to a namespace, I 
think we should try to avoid using the same in the actual config part. 
For example, job.container.single.thread.mode can be 
job.container.single-thread-mode.
Same for job.container.thread.pool.size, task.callback.timeout.ms and 
task.max.concurrency


- Navina Ramesh


On Aug. 30, 2016, 12:49 a.m., Xinyu Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50174/
> ---
> 
> (Updated Aug. 30, 2016, 12:49 a.m.)
> 
> 
> Review request for samza, Chris Pettitt, Navina Ramesh, and Yi Pan (Data 
> Infrastructure).
> 
> 
> Repository: samza
> 
> 
> Description
> ---
> 
> Update samza web docs with new multithreading api, core and configs.
> 
> 
> Diffs
> -
> 
>   docs/learn/documentation/versioned/api/overview.md 
> 6712344e84e19883b857e00549db2acb101c7e0e 
>   docs/learn/documentation/versioned/container/event-loop.md 
> 116238312df7071747cbbc14bc9c46f558755195 
>   docs/learn/documentation/versioned/jobs/configuration-table.html 
> 54c52981c3055b398ee60af50eeaf2592ed0e64f 
> 
> Diff: https://reviews.apache.org/r/50174/diff/
> 
> 
> Testing
> ---
> 
> Test the web pages locally.
> 
> 
> Thanks,
> 
> Xinyu Liu
> 
>

Re: Review Request 50174: SAMZA-977: User doc for samza multithreading

[Navina Ramesh]

> On Aug. 25, 2016, 12:30 a.m., Navina Ramesh wrote:
> > docs/learn/documentation/versioned/container/event-loop.md, line 24
> > 
> >
> > There is no sharing of task state in Samza. Each task guarantee 
> > isolation from the others. What exactly are you referring to here? Unless I 
> > have misunderstood the semantics provided by processing in multiple threads
> 
> Xinyu Liu wrote:
> The shared state refers to global in-memory states, like singletons and 
> static vars.

Yeah. I kind of figured that's what you meant. But "state" is an very 
overloaded term. It will be great if you can modify the "sharing task state" to 
include examples. For example, sharing task state (via global in-memory states, 
singletons, static vars etc)


- Navina


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50174/#review146554
---


On Aug. 30, 2016, 12:49 a.m., Xinyu Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50174/
> ---
> 
> (Updated Aug. 30, 2016, 12:49 a.m.)
> 
> 
> Review request for samza, Chris Pettitt, Navina Ramesh, and Yi Pan (Data 
> Infrastructure).
> 
> 
> Repository: samza
> 
> 
> Description
> ---
> 
> Update samza web docs with new multithreading api, core and configs.
> 
> 
> Diffs
> -
> 
>   docs/learn/documentation/versioned/api/overview.md 
> 6712344e84e19883b857e00549db2acb101c7e0e 
>   docs/learn/documentation/versioned/container/event-loop.md 
> 116238312df7071747cbbc14bc9c46f558755195 
>   docs/learn/documentation/versioned/jobs/configuration-table.html 
> 54c52981c3055b398ee60af50eeaf2592ed0e64f 
> 
> Diff: https://reviews.apache.org/r/50174/diff/
> 
> 
> Testing
> ---
> 
> Test the web pages locally.
> 
> 
> Thanks,
> 
> Xinyu Liu
> 
>

Re: [DISCUSS] End of Stream Feature in Samza

[Julian Hyde]

> On Aug 30, 2016, at 4:44 PM, Xinyu Liu  wrote:
> 
> It's very exciting that Samza is adding support of bounded input streams.

+1!

Re: [DISCUSS] End of Stream Feature in Samza

[xinyu liu]

It's very exciting that Samza is adding support of bounded input streams.
Nice write-up of different scenarios and options. Look forward to having
this feature work with the upcoming HDFS consumer!

Thanks,
Xinyu

On Tue, Aug 30, 2016 at 12:09 PM, Jagadish Venkatraman <
jagadish1...@gmail.com> wrote:

> Currently, Samza works with streaming input sources like Kafka topics. This
> proposal will build an idea of 'end-of-stream' into Samza to support data
> sources that are bounded - like HDFS files, snapshots on disk etc.
>
> Proposal:
>
> https://issues.apache.org/jira/secure/attachment/12825119/
> ProposalforEndofStreaminSamza.pdf
>
> This is tracked in SAMZA-974.
>
> --
> Jagadish V,
> Graduate Student,
> Department of Computer Science,
> Stanford University
>

Re: Review Request 51252: SAMZA-1004: Fix some logging and javadoc issues for AsyncStreamTask

[Prateek Maheshwari]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51252/#review147373
---




samza-api/src/main/java/org/apache/samza/task/AsyncStreamTask.java (line 25)


multithreaded.

Maybe use asynchronous instead of multithreaded here? Multi-threaded seems 
like an implementation detail.



samza-api/src/main/java/org/apache/samza/task/AsyncStreamTask.java (line 36)


s/serialized/serial?


- Prateek Maheshwari


On Aug. 30, 2016, 3:01 p.m., Xinyu Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51252/
> ---
> 
> (Updated Aug. 30, 2016, 3:01 p.m.)
> 
> 
> Review request for samza, Navina Ramesh and Yi Pan (Data Infrastructure).
> 
> 
> Repository: samza
> 
> 
> Description
> ---
> 
> SAMZA-1004: Fix some logging and javadoc issues for AsyncStreamTask
> 
> 
> Diffs
> -
> 
>   samza-api/src/main/java/org/apache/samza/task/AsyncStreamTask.java 
> 684ba0b77fca1c1c5fd8d740597d3b7fcdc0f5cb 
>   samza-core/src/main/scala/org/apache/samza/container/SamzaContainer.scala 
> f786fc08c8f7eced4f4084dc8326b28b6422 
> 
> Diff: https://reviews.apache.org/r/51252/diff/
> 
> 
> Testing
> ---
> 
> gradlew clean build.
> 
> 
> Thanks,
> 
> Xinyu Liu
> 
>

Re: Review Request 51252: SAMZA-1004: Fix some logging and javadoc issues for AsyncStreamTask

[Xinyu Liu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51252/
---

(Updated Aug. 30, 2016, 10:01 p.m.)


Review request for samza, Navina Ramesh and Yi Pan (Data Infrastructure).


Repository: samza


Description
---

SAMZA-1004: Fix some logging and javadoc issues for AsyncStreamTask


Diffs (updated)
-

  samza-api/src/main/java/org/apache/samza/task/AsyncStreamTask.java 
684ba0b77fca1c1c5fd8d740597d3b7fcdc0f5cb 
  samza-core/src/main/scala/org/apache/samza/container/SamzaContainer.scala 
f786fc08c8f7eced4f4084dc8326b28b6422 

Diff: https://reviews.apache.org/r/51252/diff/


Testing
---

gradlew clean build.


Thanks,

Xinyu Liu

[DISCUSS] End of Stream Feature in Samza

[Jagadish Venkatraman]

Currently, Samza works with streaming input sources like Kafka topics. This
proposal will build an idea of 'end-of-stream' into Samza to support data
sources that are bounded - like HDFS files, snapshots on disk etc.

Proposal:

https://issues.apache.org/jira/secure/attachment/12825119/ProposalforEndofStreaminSamza.pdf

This is tracked in SAMZA-974.

-- 
Jagadish V,
Graduate Student,
Department of Computer Science,
Stanford University

ApacheCon Seville CFP closes September 9th

[Rich Bowen]

It's traditional. We wait for the last minute to get our talk proposals
in for conferences.

Well, the last minute has arrived. The CFP for ApacheCon Seville closes
on September 9th, which is less than 2 weeks away. It's time to get your
talks in, so that we can make this the best ApacheCon yet.

It's also time to discuss with your developer and user community whether
there's a track of talks that you might want to propose, so that you
have more complete coverage of your project than a talk or two.

For Apache Big Data, the relevant URLs are:
Event details:
http://events.linuxfoundation.org/events/apache-big-data-europe
CFP:
http://events.linuxfoundation.org/events/apache-big-data-europe/program/cfp

For ApacheCon Europe, the relevant URLs are:
Event details: http://events.linuxfoundation.org/events/apachecon-europe
CFP: http://events.linuxfoundation.org/events/apachecon-europe/program/cfp

This year, we'll be reviewing papers "blind" - that is, looking at the
abstracts without knowing who the speaker is. This has been shown to
eliminate the "me and my buddies" nature of many tech conferences,
producing more diversity, and more new speakers. So make sure your
abstracts clearly explain what you'll be talking about.

For further updated about ApacheCon, follow us on Twitter, @ApacheCon,
or drop by our IRC channel, #apachecon on the Freenode IRC network.

-- 
Rich Bowen
WWW: http://apachecon.com/
Twitter: @ApacheCon

Review Request 51516: SAMZA-702: Document the significance of all the different metrics emitted by Samza out of the box

[Branislav Cogic]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51516/
---

Review request for samza.


Bugs: SAMZA-702
https://issues.apache.org/jira/browse/SAMZA-702


Repository: samza


Description
---

All the metrics documented in a metrics-table.

Few counters and timer removed because they are not used:
"send-calls" counter and "chooser-update-ns" timer from SamzaContainerMetrics
"batch-resets" counter from BootstrapingChooserMetrics


Diffs
-

  docs/_layouts/default.html 7beb734ddeaecb7a6369f7d2a5d4e0c67655269c 
  docs/learn/documentation/versioned/container/metrics-table.html PRE-CREATION 
  docs/learn/documentation/versioned/container/metrics.md 
b053b792097400536ea385cb3db720f6f71da017 
  
samza-core/src/main/scala/org/apache/samza/container/SamzaContainerMetrics.scala
 1e7515e8e8eb5ff2f769bea3184ce49308bada9a 
  
samza-core/src/main/scala/org/apache/samza/system/chooser/BootstrappingChooser.scala
 1cd8e0637e2192460a9e9fe078c735444be8eb97 

Diff: https://reviews.apache.org/r/51516/diff/


Testing
---

Site ran locally using local-site-test.sh


Thanks,

Branislav Cogic