[GitHub] incubator-predictionio pull request #273: PIO-20 Merge ActionML fork

[pferrel]

Github user pferrel commented on a diff in the pull request:


https://github.com/apache/incubator-predictionio/pull/273#discussion_r74712711
  
--- Diff: bin/install.sh ---
@@ -102,9 +103,8 @@ if [[ "$OS" = "Linux" && $(cat /proc/1/cgroup) == 
*cpu:/docker/* ]]; then
   # Java Install
   echo -e "\033[1;36mStarting Java install...\033[0m"
 
-  sudo add-apt-repository -y ppa:openjdk-r/ppa
   sudo apt-get update
-  sudo apt-get install openjdk-8-jdk libgfortran3 -y
+  sudo apt-get install openjdk-7-jdk libgfortran3 -y
--- End diff --

Yes, but it's not in this merge. We had all of the SF 0.9.6 running on j7, 
I'll fix this to say j8 for now


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-predictionio pull request #273: PIO-20 Merge ActionML fork

[pferrel]

Github user pferrel commented on a diff in the pull request:


https://github.com/apache/incubator-predictionio/pull/273#discussion_r74712571
  
--- Diff: RELEASE.md ---
@@ -1,26 +1,58 @@
-##Release Notes and News
+#Release Notes and News
 
 **Note:** For upgrade instructions please refer to [this 
page](http://predictionio.incubator.apache.org/resources/upgrade/).
 
-###v0.9.6
+## Version History
 
-November, 2015 | [Release 
Notes](https://github.com/apache/incubator-predictionio/blob/master/RELEASE.md) 
have been moved to Github and you are reading them. For a detailed list of 
commits check [this 
page](https://github.com/apache/incubator-predictionio/commits/master)
+### 0.10.0
+
+Aug ??, 2016
+
+ - Make SSL optional
+ - Merge ActionML fork
+ - First Apache PredictionIO (incubating) release
+
+### 0.9.7-aml (ActionML fork)
+
+Aug 5, 2016
+
+ - changed version id so artifacts don't conflict with naming in the 
Salesforce sponsored project.
+ - bug fix in memory use during moving window event trim and compaction  
EventStore data.
+ - update 
[install.sh](https://github.com/actionml/PredictionIO/blob/master/bin/install.sh)
 script for single line installs with options that support various combinations 
required by some templates.
+ 
+### v0.9.6
+
+April 11, 2015 
+
+For a detailed list of commits check [this 
page](https://github.com/apache/incubator-predictionio/commits/master)
 
 - Upgrade components for install/runtime to Hbase 1, Spark 1.5.2 PIO still 
runs on older HBase and Spark back to 1.3.1, upgrading install of Elaticsearch 
to 1.5.2 since pio run well on it but also runs on older versions.
 - Support for maintaining a moving window of events by discarding old 
events from the EventStore
 - Support for doing a deploy without creating a Spark Context
 
+### v0.9.6 (ActionML fork)
+
+March 26, 2016
+
+- Upgrade components for install/runtime to Hbase 1.X, Spark 1.5.2 PIO 
still runs on older HBase and Spark back to 1.3.1, upgrading install of 
Elasticsearch to 1.5.2 since pio run well on it but also runs on older versions.
+- Support for maintaining a moving window of events by discarding old 
events from the EventStore
+- Support for doing a deploy without creating a Spark Context
+
 ###v0.9.5 
 
-October 14th, 2015 | [Release 
Notes](https://github.com/apache/incubator-predictionio/blob/master/RELEASE.md) 
have been moved to Github and you are reading them. For a detailed list of 
commits check [this 
page](https://github.com/apache/incubator-predictionio/commits/v0.9.5)
+October 14th, 2015 
+
+[Release 
Notes](https://github.com/apache/incubator-predictionio/blob/master/RELEASE.md) 
have been moved to Github and you are reading them. For a detailed list of 
commits check [this 
page](https://github.com/apache/incubator-predictionio/commits/v0.9.5)
 
 - Support batches of events sent to the EventServer as json arrays
 - Support creating an Elasticsearch StorageClient created for an 
Elasticsearch cluster from variables in pio-env.sh
 - Fixed some errors installing PredictionIO through install.sh when SBT 
was not correctly downloaded
 
 ###v0.9.4
 
-July 16th, 2015 | [Release 
Notes](https://predictionio.atlassian.net/jira/secure/ReleaseNote.jspa?projectId=1=13700)
+July 16th, 2015
+
+[Release 
Notes](https://predictionio.atlassian.net/jira/secure/ReleaseNote.jspa?projectId=1=13700)
--- End diff --

sure, but this was in develop when I got it, all I changed was the 
formatting. In the name of expediency I'll leave it for another push if that's 
ok.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (PIO-21) Checks in Travis build not the same as local build

[Pat Ferrel (JIRA)]

[ 
https://issues.apache.org/jira/browse/PIO-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420548#comment-15420548
 ] 

Pat Ferrel commented on PIO-21:
---

I think it is my local problem, can't run the integration test due to no way to 
download a prerequisite. The integration test should run the same style and 
unit tests as are in Travis.

Closing as resolved

> Checks in Travis build not the same as local build
> --
>
> Key: PIO-21
> URL: https://issues.apache.org/jira/browse/PIO-21
> Project: PredictionIO
>  Issue Type: Bug
>Affects Versions: 0.10.0
>Reporter: Pat Ferrel
>
> When Travis runs it's style checks against PRs it is more strict that the 
> local build. They should be the same.
> Having a fully tested PR ready to commit only to see it fail in travis is not 
> a very productive way to work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PIO-21) Checks in Travis build not the same as local build

[Pat Ferrel (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PIO-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pat Ferrel resolved PIO-21.
---
Resolution: Invalid

> Checks in Travis build not the same as local build
> --
>
> Key: PIO-21
> URL: https://issues.apache.org/jira/browse/PIO-21
> Project: PredictionIO
>  Issue Type: Bug
>Affects Versions: 0.10.0
>Reporter: Pat Ferrel
>
> When Travis runs it's style checks against PRs it is more strict that the 
> local build. They should be the same.
> Having a fully tested PR ready to commit only to see it fail in travis is not 
> a very productive way to work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PIO-20) Merge ActionML fork

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PIO-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420544#comment-15420544
 ] 

ASF GitHub Bot commented on PIO-20:
---

Github user pferrel commented on a diff in the pull request:


https://github.com/apache/incubator-predictionio/pull/273#discussion_r74712711
  
--- Diff: bin/install.sh ---
@@ -102,9 +103,8 @@ if [[ "$OS" = "Linux" && $(cat /proc/1/cgroup) == 
*cpu:/docker/* ]]; then
   # Java Install
   echo -e "\033[1;36mStarting Java install...\033[0m"
 
-  sudo add-apt-repository -y ppa:openjdk-r/ppa
   sudo apt-get update
-  sudo apt-get install openjdk-8-jdk libgfortran3 -y
+  sudo apt-get install openjdk-7-jdk libgfortran3 -y
--- End diff --

Yes, but it's not in this merge. We had all of the SF 0.9.6 running on j7, 
I'll fix this to say j8 for now


> Merge ActionML fork
> ---
>
> Key: PIO-20
> URL: https://issues.apache.org/jira/browse/PIO-20
> Project: PredictionIO
>  Issue Type: Bug
>Reporter: Pat Ferrel
>Assignee: Pat Ferrel
>
> Merge ActionML's changes since forking pio 0.9.5. This includes 2 releases 
> and the biggest feature is the SelfCleaningDatasource, which optionally trims 
> old events and compact dups and property change events. 
> Adds an optional eventWindow param to engine.json datasource params



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PIO-20) Merge ActionML fork

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PIO-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420542#comment-15420542
 ] 

ASF GitHub Bot commented on PIO-20:
---

Github user pferrel commented on a diff in the pull request:


https://github.com/apache/incubator-predictionio/pull/273#discussion_r74712571
  
--- Diff: RELEASE.md ---
@@ -1,26 +1,58 @@
-##Release Notes and News
+#Release Notes and News
 
 **Note:** For upgrade instructions please refer to [this 
page](http://predictionio.incubator.apache.org/resources/upgrade/).
 
-###v0.9.6
+## Version History
 
-November, 2015 | [Release 
Notes](https://github.com/apache/incubator-predictionio/blob/master/RELEASE.md) 
have been moved to Github and you are reading them. For a detailed list of 
commits check [this 
page](https://github.com/apache/incubator-predictionio/commits/master)
+### 0.10.0
+
+Aug ??, 2016
+
+ - Make SSL optional
+ - Merge ActionML fork
+ - First Apache PredictionIO (incubating) release
+
+### 0.9.7-aml (ActionML fork)
+
+Aug 5, 2016
+
+ - changed version id so artifacts don't conflict with naming in the 
Salesforce sponsored project.
+ - bug fix in memory use during moving window event trim and compaction  
EventStore data.
+ - update 
[install.sh](https://github.com/actionml/PredictionIO/blob/master/bin/install.sh)
 script for single line installs with options that support various combinations 
required by some templates.
+ 
+### v0.9.6
+
+April 11, 2015 
+
+For a detailed list of commits check [this 
page](https://github.com/apache/incubator-predictionio/commits/master)
 
 - Upgrade components for install/runtime to Hbase 1, Spark 1.5.2 PIO still 
runs on older HBase and Spark back to 1.3.1, upgrading install of Elaticsearch 
to 1.5.2 since pio run well on it but also runs on older versions.
 - Support for maintaining a moving window of events by discarding old 
events from the EventStore
 - Support for doing a deploy without creating a Spark Context
 
+### v0.9.6 (ActionML fork)
+
+March 26, 2016
+
+- Upgrade components for install/runtime to Hbase 1.X, Spark 1.5.2 PIO 
still runs on older HBase and Spark back to 1.3.1, upgrading install of 
Elasticsearch to 1.5.2 since pio run well on it but also runs on older versions.
+- Support for maintaining a moving window of events by discarding old 
events from the EventStore
+- Support for doing a deploy without creating a Spark Context
+
 ###v0.9.5 
 
-October 14th, 2015 | [Release 
Notes](https://github.com/apache/incubator-predictionio/blob/master/RELEASE.md) 
have been moved to Github and you are reading them. For a detailed list of 
commits check [this 
page](https://github.com/apache/incubator-predictionio/commits/v0.9.5)
+October 14th, 2015 
+
+[Release 
Notes](https://github.com/apache/incubator-predictionio/blob/master/RELEASE.md) 
have been moved to Github and you are reading them. For a detailed list of 
commits check [this 
page](https://github.com/apache/incubator-predictionio/commits/v0.9.5)
 
 - Support batches of events sent to the EventServer as json arrays
 - Support creating an Elasticsearch StorageClient created for an 
Elasticsearch cluster from variables in pio-env.sh
 - Fixed some errors installing PredictionIO through install.sh when SBT 
was not correctly downloaded
 
 ###v0.9.4
 
-July 16th, 2015 | [Release 
Notes](https://predictionio.atlassian.net/jira/secure/ReleaseNote.jspa?projectId=1=13700)
+July 16th, 2015
+
+[Release 
Notes](https://predictionio.atlassian.net/jira/secure/ReleaseNote.jspa?projectId=1=13700)
--- End diff --

sure, but this was in develop when I got it, all I changed was the 
formatting. In the name of expediency I'll leave it for another push if that's 
ok.


> Merge ActionML fork
> ---
>
> Key: PIO-20
> URL: https://issues.apache.org/jira/browse/PIO-20
> Project: PredictionIO
>  Issue Type: Bug
>Reporter: Pat Ferrel
>Assignee: Pat Ferrel
>
> Merge ActionML's changes since forking pio 0.9.5. This includes 2 releases 
> and the biggest feature is the SelfCleaningDatasource, which optionally trims 
> old events and compact dups and property change events. 
> Adds an optional eventWindow param to engine.json datasource params



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 0.10.0 release

[Pat Ferrel]

When I say infrastructure I am by no means talking about the  Apache Infra 
*people* who are asked to do an awful lot of work and they do it well. They are 
asked to create and maintain the equivalent of Github, Gmail, Google Forums, 
and other tools. It might be time for Apache to re-think this but it is a bit 
off subject for this thread so I’ll save it for infrastructure@. Unfortunately 
we can’t wait for something to come out of that discussion to decide what we do 
for our first Apache release.

If we remove the question of how much work it is to create a new Apache git 
repo what would we do? PIO (Tappingstone), Salesforce, and ActionML chose a 
template per repo and users who make simple mods follow this model for the 
reasons I listed below. Let’s not forget we’ll be talking about this again when 
we get to SDKs, maybe containers, and microservice refactoring as well. All of 
which seem natural to think of as separate repos. 

Let’s start the discussion with what is easier for maintainers and users? What 
fits current best practice better? What method fits the practical needs for 
releasing code best? What method scales and fits future needs better? What 
method will encourage 3rd party extensions like templates and sdks? What is 
easiest to document or automate?

If we decide to have a monolithic repo, let's do it because it’s the best thing 
for the project. What do others think?


On Aug 14, 2016, at 11:02 AM, Andrew Purtell  wrote:

Interesting idea to try separate repos for landing to-be-donated templates. On 
GitHub repositories are cheap and, though not necessarily at this moment at 
Apache, easy to provision. If you think separate repo and lifecycle is the best 
way to manage templates then we PPMC plus mentors should make that happen here. 

I would think if the project comes to have a set of core templates used for 
such things as integration testing and good out of the box experience, these 
will in fact be coupled with changes to framework and having both in the same 
repo would seem like a fine idea. Just a thought. Not sure how useful it is, 
FWIW

Anyway, rather than rant at infrastructure (or suppress one (smile)) I'd 
encourage you to engage in a proactive manner. Everything self service we have 
at the foundation today has stemmed from a pain point and constructive 
proposal. So if you'd like to have a repo per template and anticipate frequent 
repo provisioning requests to be a problem, start a discussion about self 
service repo provisioning (or whatever you think will work) on infrastructure@. 
Podlings are meant to stretch and grow the foundation as much as assimilate IP 
and governance practice. 

> On Aug 14, 2016, at 8:30 AM, Pat Ferrel  wrote:
> 
> Important things unresolved for release:
> 
> 1) What to do with Apache templates—my suggestion is separate repos for the 3 
> reasons below.
> 2) We need a Gallery page listing at least a couple converted tested 
> templates—couldn’t find this in the site but maybe I missed it. The UR is now 
> converted and tested as are the examples.
> 3) AML fork healed, should be pushed this afternoon.
> 4) the rest of the release magic
> 
> PIO is rather moot without templates but if they are on a separate release 
> schedule like the doc site (which also needs work) we could release without 1 
> & 2. I’d favor that rather than releasing with templates in a templates/ 
> directory.
> 
> Anything else? How are people feeling about release?
> 
> 
> On Aug 12, 2016, at 10:18 AM, Pat Ferrel  wrote:
> 
> Independent of Apache I’d suggest each template have their own git repo as 
> they do now. Is this practically possible in ASF (another example of my 
> infrastructure rant but leave that for now). The semantics of this make 
> sense. The requirements for all apache or non-apache templates seem to be:
> 
> 1) They need to be allowed to have separate release cycles. 
> 2) There should be only one way to install templates apache or non-apache
> 3) This method should support tags and branches, and separate PRs
> 
> Practically speaking for independent ones (the Universal Recommender will 
> remain independent until the issues above are resolved) the templates *will* 
> be a separate repo and `git pull` *will* be the method of download. To me 
> this implies the Apache ones should use the same pattern. 
> 
> The separate issue of rules for inclusion in Apache should include a test 
> requirement IMO. But inclusion in the Gallery seems a looser attachment to 
> the project—just one persons opinion
> 
> 
> On Aug 11, 2016, at 3:42 PM, Chan Lee  > wrote:
> 
> I've begun working on migrating official PredictionIO templates into the main 
> apache repository, and there are a few points I'd like to bring to attention.
> 
> 1) Template code will be merged under templates/ directory, and all commit 
> history and authorship will 

Re: 0.10.0 release

[Andrew Purtell]

Interesting idea to try separate repos for landing to-be-donated templates. On 
GitHub repositories are cheap and, though not necessarily at this moment at 
Apache, easy to provision. If you think separate repo and lifecycle is the best 
way to manage templates then we PPMC plus mentors should make that happen here. 

I would think if the project comes to have a set of core templates used for 
such things as integration testing and good out of the box experience, these 
will in fact be coupled with changes to framework and having both in the same 
repo would seem like a fine idea. Just a thought. Not sure how useful it is, 
FWIW

Anyway, rather than rant at infrastructure (or suppress one (smile)) I'd 
encourage you to engage in a proactive manner. Everything self service we have 
at the foundation today has stemmed from a pain point and constructive 
proposal. So if you'd like to have a repo per template and anticipate frequent 
repo provisioning requests to be a problem, start a discussion about self 
service repo provisioning (or whatever you think will work) on infrastructure@. 
Podlings are meant to stretch and grow the foundation as much as assimilate IP 
and governance practice. 

> On Aug 14, 2016, at 8:30 AM, Pat Ferrel  wrote:
> 
> Important things unresolved for release:
> 
> 1) What to do with Apache templates—my suggestion is separate repos for the 3 
> reasons below.
> 2) We need a Gallery page listing at least a couple converted tested 
> templates—couldn’t find this in the site but maybe I missed it. The UR is now 
> converted and tested as are the examples.
> 3) AML fork healed, should be pushed this afternoon.
> 4) the rest of the release magic
> 
> PIO is rather moot without templates but if they are on a separate release 
> schedule like the doc site (which also needs work) we could release without 1 
> & 2. I’d favor that rather than releasing with templates in a templates/ 
> directory.
> 
> Anything else? How are people feeling about release?
> 
> 
> On Aug 12, 2016, at 10:18 AM, Pat Ferrel  wrote:
> 
> Independent of Apache I’d suggest each template have their own git repo as 
> they do now. Is this practically possible in ASF (another example of my 
> infrastructure rant but leave that for now). The semantics of this make 
> sense. The requirements for all apache or non-apache templates seem to be:
> 
> 1) They need to be allowed to have separate release cycles. 
> 2) There should be only one way to install templates apache or non-apache
> 3) This method should support tags and branches, and separate PRs
> 
> Practically speaking for independent ones (the Universal Recommender will 
> remain independent until the issues above are resolved) the templates *will* 
> be a separate repo and `git pull` *will* be the method of download. To me 
> this implies the Apache ones should use the same pattern. 
> 
> The separate issue of rules for inclusion in Apache should include a test 
> requirement IMO. But inclusion in the Gallery seems a looser attachment to 
> the project—just one persons opinion
> 
> 
> On Aug 11, 2016, at 3:42 PM, Chan Lee  > wrote:
> 
> I've begun working on migrating official PredictionIO templates into the main 
> apache repository, and there are a few points I'd like to bring to attention.
> 
> 1) Template code will be merged under templates/ directory, and all commit 
> history and authorship will be preserved.
> 
> 2) Organization namespace will change in the template code from 
> "io.prediction" to "org.apache.predictionio". 
> 
> 3) In order to download an engine template, users could (1) git clone the 
> entire repo and copy the files in templates/, or (2) use 
> something like svn to download only the necessary subdirectory. I'd like to 
> ask what everyone thinks should be the recommended approach. The 
> documentation should be updated accordingly (instead of `pio template get`).
> 
> 4) I'd like to ask if there are any ActionML/outside templates that should be 
> included or updated. For instance, 
> template-scala-parallel-universal-recommendation in PredictionIO repo seems 
> outdate compared to one in actionml repo. 
> 
> 
> Thanks,
> Chan
> 
> 
> 
> On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński  > wrote:
> I think that this is a very good idea. Obviously it would require
> configuring more concurrent builds to finish in reasonable time, what
> should not be a problem. Besides, it would make the official templates be
> consistent with every next release of PredictionIO and what is very
> important - it would provide many different tests for the repository.
> Having working templates of different types could give us more material to
> test not only the reliability of PredictionIO, but also its performance
> with every change. It would require adding different types of tests and
> tools to gather runtime 

0.10.0 release

[Pat Ferrel]

Important things unresolved for release:

1) What to do with Apache templates—my suggestion is separate repos for the 3 
reasons below.
2) We need a Gallery page listing at least a couple converted tested 
templates—couldn’t find this in the site but maybe I missed it. The UR is now 
converted and tested as are the examples.
3) AML fork healed, should be pushed this afternoon.
4) the rest of the release magic

PIO is rather moot without templates but if they are on a separate release 
schedule like the doc site (which also needs work) we could release without 1 & 
2. I’d favor that rather than releasing with templates in a templates/ 
directory.

Anything else? How are people feeling about release?


On Aug 12, 2016, at 10:18 AM, Pat Ferrel  wrote:

Independent of Apache I’d suggest each template have their own git repo as they 
do now. Is this practically possible in ASF (another example of my 
infrastructure rant but leave that for now). The semantics of this make sense. 
The requirements for all apache or non-apache templates seem to be:

1) They need to be allowed to have separate release cycles. 
2) There should be only one way to install templates apache or non-apache
3) This method should support tags and branches, and separate PRs

Practically speaking for independent ones (the Universal Recommender will 
remain independent until the issues above are resolved) the templates *will* be 
a separate repo and `git pull` *will* be the method of download. To me this 
implies the Apache ones should use the same pattern. 

The separate issue of rules for inclusion in Apache should include a test 
requirement IMO. But inclusion in the Gallery seems a looser attachment to the 
project—just one persons opinion


On Aug 11, 2016, at 3:42 PM, Chan Lee > wrote:

I've begun working on migrating official PredictionIO templates into the main 
apache repository, and there are a few points I'd like to bring to attention.

1) Template code will be merged under templates/ directory, and all commit 
history and authorship will be preserved.

2) Organization namespace will change in the template code from "io.prediction" 
to "org.apache.predictionio". 

3) In order to download an engine template, users could (1) git clone the 
entire repo and copy the files in templates/, or (2) use 
something like svn to download only the necessary subdirectory. I'd like to ask 
what everyone thinks should be the recommended approach. The documentation 
should be updated accordingly (instead of `pio template get`).

4) I'd like to ask if there are any ActionML/outside templates that should be 
included or updated. For instance, 
template-scala-parallel-universal-recommendation in PredictionIO repo seems 
outdate compared to one in actionml repo. 


Thanks,
Chan



On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński > wrote:
I think that this is a very good idea. Obviously it would require
configuring more concurrent builds to finish in reasonable time, what
should not be a problem. Besides, it would make the official templates be
consistent with every next release of PredictionIO and what is very
important - it would provide many different tests for the repository.
Having working templates of different types could give us more material to
test not only the reliability of PredictionIO, but also its performance
with every change. It would require adding different types of tests and
tools to gather runtime statistics, but this is something I would like to
take a look at in the future.

niedz., 7.08.2016 o 10:21 użytkownik Donald Szeto >
napisał:

> We can also make these templates part of the integration test that Chan and
> Marcin just submitted (
> https://github.com/apache/incubator-predictionio/pull/267 
> ). That way we
> can
> make commitment to included templates be part of every committer's effort.
> Just my 2c.
>
> On Sun, Aug 7, 2016 at 9:47 AM, Pat Ferrel  > wrote:
>
> > If this sound ok, I propose the process be:
> > 1) inclusion in the gallery is a PR to the yaml gallery file. This is
> > reviewable by all but takes only one committer to approve and merge.
> > 2) submission for inclusion in the project can be a PR to the new
> > templates directory as Simon suggests. But this may require a more formal
> > vote, and come with some commitment for support and possibly
> consideration
> > of the author for committer status.
> >
> > Someone who knows Apache rules better than me may know the type of vote
> to
> > have for #2, maybe this is only informal review and single committer
> > acceptance too as long as the committer is willing to support the
> template.
> >
> > As far as the Salesforce templates marked official, I’d hope that most
> > would be 

Re: PIO-20 problems

[Pat Ferrel]

The first set of requirement fail to install at python’s unittest. That sort-of 
stops me dead. Don’t have a lot of dedicated time right now to debug so I let 
Travis do the tests and they are passing now and all comments are resolved. I 
left the keystore in so we ca address in a separate Jira. This PR will be 
pushed this afternoon, at which time the fork will completely “healed”.


On Aug 13, 2016, at 1:41 PM, Donald Szeto  wrote:

Hey Pat, how are you running integration tests? All requirements are already 
inside the Docker image and should not need to be installed manually. Are you 
trying to rebuild the image from scratch? Is there somewhere in the integration 
test documentation that can be improved?

On Sat, Aug 13, 2016 at 12:31 PM, Alex Merritt > wrote:
Resolved, passing in Travis now.


On Fri, Aug 12, 2016 at 3:04 PM, Pat Ferrel > wrote:
Alex, can you look at these unit test failures on the PR, they seem to be in 
JDBCPEvents

https://travis-ci.org/apache/incubator-predictionio/builds/151905196 



On Aug 12, 2016, at 1:18 PM, Pat Ferrel > wrote:

Can't install unittest with pip or pip3 even though the rest of the 
prerequisites work. Simply refuses to find it. Pip3 search unittest give this:

WebTestRunner (0.2)- Web-based interface for selectively 
executing client-side Python UnitTests
unittest (0.0) -
nosetests-json-extended (0.1.0)- Create json logging output for 
pythonnosetests unittest framework

no description and 0.0 seems odd. Pip3 install unittest gives:

Collecting unittest
 Could not find a version that satisfies the requirement unittest (from 
versions: )
No matching distribution found for unittest

Tried forcing the version to 0.0 but again no luck

Ideas? In the meantime waiting for Travis to do it—sigh


On Aug 11, 2016, at 2:31 PM, Pat Ferrel > wrote:

With the keystore my template-based integration test passes and I’ve put the 
keystore back in. The diffs on PRs on Github seem completely wonky right now. 
Git diff is trustworthy at least.

Will try the python tests now too.

Thanks guys, working smoothly now.


On Aug 11, 2016, at 11:53 AM, Donald Szeto > wrote:

Hi all,

I went ahead and pulled Pat's branch, performed a clean build, and repeated
the quick start guide of the Scala parallel recommendation template. I
could produce the same problem, and root caused it to a missing
conf/keystore.jks file.

I think with SSL now optional, we should not be distributing a KeyStore
file. We can either quick fix it now by putting this file back, or modify
SSLConfiguration to not look for this file when SSL support is off.

Regards,
Donald

On Thu, Aug 11, 2016 at 8:03 AM, Chan Lee > wrote:

> I want to clarify some points:
>
> 2) Deploying templates do not require SSL. If you execute
> ./make-distribution.sh using the current develop branch (provided you
> change the namespace in the template from io.prediction to
> org.apache.predictionio), you can deploy without SSL on localhost. The
> travis tests also do not use SSL and pass as can be seen in
> https://travis-ci.org/Ziemin/incubator-predictionio 
> .
>
> 3) You can run the tests locally the same way it is run on travis
> ('python3 ${PIO_DIR}/tests/pio_tests/tests.py'). It is documented in the
> README in the same directory, but maybe this was not clear enough. If you
> have any additional questions or run into issues executing the tests,
> please let me know.
>
> Thanks,
> Chan
>
> On Thu, Aug 11, 2016 at 6:07 AM, Pat Ferrel  > wrote:
>
>> I’m always disinclined to commit code that has not been tested. However
>> many things in the current state of the develop branch seem broken or at
>> least too big to address in a single commit.
>>
>> 1) Style test fail in Travis that are not runnable or at least have not
>> been documented for local build. I have fixed these.
>> 2) SSL seems to still be required for deploying an engine, PIO-1 may not
>> have addressed this. Has anyone tried to build and test a template yet
>> without SSL? Unless someone can state otherwise I’m inclined to ignore this
>> failure for now since it is out of scope for this commit.
>> 3) the test framework has been integrated into Travis but again no
>> documented way to run it locally and some of the travis errors seem
>> spurious. I am also not inclined to wait for this to be fixed unless
>> someone can point out real problems it is discovering and send instructions
>> for how to run it locally.
>>
>>