> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/Makefile, line 15
> > <https://reviews.apache.org/r/33778/diff/3/?file=952806#file952806line15>
> >
> >     My hunch is we should grab this from either the requirements.txt or the 
> > java dep, vs. specifying it here
> 
> Zameer Manji wrote:
>     +1. We don't need more places to specify the mesos version.

Switched to a method which obtains this via parsing requirements.txt.


> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/Makefile, line 17
> > <https://reviews.apache.org/r/33778/diff/3/?file=952806#file952806line17>
> >
> >     If someone grabs this from the downloads page (aka, downloads a 
> > tarballed Release) then this won't be in a git repo. Not sure if we're 
> > worried about it for the people that get confused and try to build a 
> > "nightly" Release, but just wanted to bring it up in case this was a 
> > concern for others.

Switched to a method which does not require usage of git.


> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/Makefile, line 18
> > <https://reviews.apache.org/r/33778/diff/3/?file=952806#file952806line18>
> >
> >     Aha, but this will definitely cause issues if not in a git repo, which 
> > we don't want. If not git, just ../.. ?

Switched to a method which does not require usage of git.


> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/aurora.init.sh, line 6
> > <https://reviews.apache.org/r/33778/diff/3/?file=952807#file952807line6>
> >
> >     s/task/service

Fixed.


> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/aurora.init.sh, line 7
> > <https://reviews.apache.org/r/33778/diff/3/?file=952807#file952807line7>
> >
> >     s/services/tasks

Fixed.


> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/aurora.init.sh, line 89
> > <https://reviews.apache.org/r/33778/diff/3/?file=952807#file952807line89>
> >
> >     sweet!

Thanks!


> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/aurora.spec, line 111
> > <https://reviews.apache.org/r/33778/diff/3/?file=952810#file952810line111>
> >
> >     maybe s/executes/runs and monitors ? (just to avoid the double execut*)

I dig; fixed.


> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/aurora.spec, line 184
> > <https://reviews.apache.org/r/33778/diff/3/?file=952810#file952810line184>
> >
> >     There's also a Thermos CLI tool at 
> > `src/main/apache/thermos/cli/bin:thermos`

This is awesome; it's now included in the current RPM.


> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/aurora.spec, line 117
> > <https://reviews.apache.org/r/33778/diff/3/?file=952810#file952810line117>
> >
> >     Since docker support is still beta, perhaps put this behind a flag and 
> > only install if desired?

I originally thought that we'd go this route, but I ultimately opted to include 
Docker as a hard requirement for the following reasons:

1. Docker is present within the current EPEL repos for EL (already required to 
install Thermos as libmesos requires cyrus-sasl) and is a dependency of the 
upstream Fedora RPMs
2. Docker support is currently enabled within the Vagrant automation
3. Docker is popular amongst the potential OSS users of Aurora

As such, I think that including Docker as a hard requirement for Thermos could 
help drive the open source adoption of Aurora as well as being lightweight, as 
packaging for it already exists across all our supported platforms.


> On May 11, 2015, 2:53 a.m., Joe Smith wrote:
> > packaging/rpm/aurora.spec, line 152
> > <https://reviews.apache.org/r/33778/diff/3/?file=952810#file952810line152>
> >
> >     I looked around for a gradle RPM but couldn't find it, so I'll +1 this

I feel similarly about this situation; alas, official Gradle RPMs won't land 
upstream until F22:

https://fedoraproject.org/wiki/Changes/Gradle


- Steve


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


On May 8, 2015, 5:08 a.m., Steve Salevan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33778/
> -----------------------------------------------------------
> 
> (Updated May 8, 2015, 5:08 a.m.)
> 
> 
> Review request for Aurora, Jake Farrell, Kevin Sweeney, and Bill Farner.
> 
> 
> Bugs: AURORA-1116
>     https://issues.apache.org/jira/browse/AURORA-1116
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> This review board adds support for building Red Hat-flavored packages for the 
> Aurora scheduler alongside its client and Thermos-related binaries:
> 
> aurora - Aurora Scheduler
> aurora-client - Aurora client and admin tool
> aurora-thermos - Thermos executor, runner, and observer
> aurora-debuginfo - Debugging symbols for Python/libmesos integration
> 
> If you'd like to give it a whirl, the following Make targets will spin up new 
> RPMs:
> 
> make (nightly_srpm|nightly_rpm) - builds an RPM or SRPM with timestamped 
> versioning, suitable for producing nightly updates
> make (release_srpm|release_rpm) - builds without timestamped versioning
> 
> Let me know what you think, and thanks!
> 
> 
> Diffs
> -----
> 
>   packaging/rpm/Makefile PRE-CREATION 
>   packaging/rpm/aurora.init.sh PRE-CREATION 
>   packaging/rpm/aurora.logrotate PRE-CREATION 
>   packaging/rpm/aurora.service PRE-CREATION 
>   packaging/rpm/aurora.spec PRE-CREATION 
>   packaging/rpm/aurora.startup.sh PRE-CREATION 
>   packaging/rpm/aurora.sysconfig PRE-CREATION 
>   packaging/rpm/clusters.json PRE-CREATION 
>   packaging/rpm/thermos-observer.init.sh PRE-CREATION 
>   packaging/rpm/thermos-observer.logrotate PRE-CREATION 
>   packaging/rpm/thermos-observer.service PRE-CREATION 
>   packaging/rpm/thermos-observer.startup.sh PRE-CREATION 
>   packaging/rpm/thermos-observer.sysconfig PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/33778/diff/
> 
> 
> Testing
> -------
> 
> Successfully executed builds on EL 6/7 and F19/20, tested deployment on EL6 
> and F19
> 
> 
> Thanks,
> 
> Steve Salevan
> 
>

Reply via email to