- add workarounds for Systemv / Upstart
Details
- Reviewers
jeschkies kensipe jenkins ichernetsky - Commits
- rMARATHON1e503b95adfc: Upgrade sbt-native packager; add package tests
rMARATHON614b5c877cae: Upgrade sbt-native packager; add package tests
rMARATHON8f06255e2e1d: Upgrade sbt-native packager; add package tests
rMARATHONca62a99e8375: Upgrade sbt-native packager; add package tests
rMARATHON920aed97e69b: Upgrade sbt-native packager; add package tests
rMARATHON259423d9c976: Upgrade sbt-native packager; add package tests - JIRA Issues
- JIRA MARATHON-7732 Debian SystemV package doesn't log
JIRA MARATHON-7733 Upstart package ignores /etc/default/marathon configuration
JIRA MARATHON-2445 Create integration test to install marathon debian snapshot package and start marathon
run them
Diff Detail
- Repository
- rMARATHON marathon
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
This is awesome work! Thanks. I have a few questions to understand the code better. Why are the Mesos Docker images required? When is make called in tests/package?
build.sbt | ||
---|---|---|
211–212 | Is this done for each loader? | |
project/NativePackagerSettings/systemv/start-debian-template | ||
2 | Where was this before. Is this new? | |
tests/package/test.sc | ||
2 | Wow! How about adding this to our pipeline? | |
tests/package/ubuntu-upstart/Dockerfile | ||
4 | Should this be hard coded? |
Some comments! I have a readme to answer when is make run, etc.
build.sbt | ||
---|---|---|
211–212 | Yeah, it is, via the "packageAll" macro. | |
project/NativePackagerSettings/systemv/start-debian-template | ||
2 | It's new, there is actually a bug with the sbt-native-packager Debian template for SystemV in which we did not get any logs. I was planning on submitting an issue to sbt-native-packager and putting a comment here but did not have time. | |
tests/package/test.sc | ||
2 | Yeah, we can do this! The tests will take a while to run due to needing to build all of the marathon environments, so I don't think we want them to run on every build. Perhaps just running before releasing packages? | |
tests/package/ubuntu-upstart/Dockerfile | ||
4 | Docker is kind of finicky; we could have the makefile copy a file over mesos version |
@jeschkies to answer your question, I build a mesos image because the tests actually start an agent-less mesos-master and checks to asserts that Marathon will register with it. In order for this test to pass, a number of things must work:
- the system loader / init script / etc must be able to launch Marathon properly
- the environment variables must be properly loaded and interpreted from /etc/default/marathon (we convert, for example, MARATHON_ZK=... to --zk=...)
- Marathon dependencies must be properly installed and working
It isn't exhaustive, of course, but it does provide at least a basic sanity check.
Error message:
Stage Compile and Test failed.
(๑′°︿°๑)
Error message:
Stage Package Docker Image, Debian and RedHat Packages failed.
(๑′°︿°๑)
Error message:
Stage Package Docker Image, Debian and RedHat Packages failed.
(๑′°︿°๑)
You can create a DC/OS with your patched Marathon by creating a new pull
request with the following changes in buildinfo.json:
\\ ٩( ᐛ )و //
You can create a DC/OS with your patched Marathon by creating a new pull
request with the following changes in buildinfo.json:
\\ ٩( ᐛ )و //
Error message:
Stage Compile and Test failed.
(๑′°︿°๑)
Error message:
Stage Compile and Test failed.
(๑′°︿°๑)
You can create a DC/OS with your patched Marathon by creating a new pull
request with the following changes in buildinfo.json:
\\ ٩( ᐛ )و //
tests/package/.gitignore | ||
---|---|---|
2 | A new line? :) |
tests/package/test.sc | ||
---|---|---|
2 | Yep. Sound good to me. We have to tackle the release scripts anyways. |
Is this done for each loader?