You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Zameer Manji <zm...@apache.org> on 2015/09/19 02:01:02 UTC
Official RPMs
Hey,
Does the Apache Mesos project provide OS packages for installation? I
haven't been able to find any for the 0.24 release and I think having them
would make installing Mesos a lot easier.
--
Zameer Manji
Re: Official RPMs
Posted by Artem Harutyunyan <ar...@mesosphere.io>.
We use https://github.com/mesosphere/mesos-deb-packaging in conjunction
with some internal tooling (that Marco mentioned) to distribute package
building. So you should be able to find all the actual package building
code in that repo. Please let us know if you have questions.
Cheers,
Artem.
On Saturday, September 26, 2015, CCAAT <cc...@tampabay.rr.com> wrote:
> On 09/25/2015 07:36 PM, Marco Massenzio wrote:
>
>> Yes, the plan is definitely to make the tooling available to the
>> project: there is nothing "secret" about it - at the moment,
>> unfortunately, it relies on a bit of internal infrastructure and, well,
>> yesss, it's a bit too crafty to be ready for "external consumption"....
>> but we're working on it!
>>
>
> Hello Marco,
>
> I' packaging up for gentoo linux. Just the itemized list of
> what/where/when you setup config files and such would be a keen help to my
> efforts. I can substitute in gentoo-centric tools, if you can provide a
> brief description on what your infra/tools are doing.
> A skeletal spec, if you like.
>
>
> James
>
>
>
>
>
>> /Marco Massenzio/
>> /Distributed Systems Engineer
>> http://codetrips.com/
>>
>> On Fri, Sep 25, 2015 at 11:33 AM, Zameer Manji <zmanji@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Could mesosphere donate their tooling for packaging mesos to the
>> project? This way any project member or contributor can build
>> packages and it can be apart of the release process.
>>
>> On Fri, Sep 25, 2015 at 10:53 AM, Artem Harutyunyan
>> <artem@mesosphere.io <ma...@mesosphere.io>> wrote:
>>
>> The repositories have been updated yesterday, and the downloads
>> page
>> was updated today. Mesos 0.24 packages are now available at
>> https://mesosphere.com/downloads/. Thank you very much for your
>> patience!
>>
>> Cheers,
>> Artem.
>>
>> On Tue, Sep 22, 2015 at 11:02 AM, Marco Massenzio
>> <marco@mesosphere.io <ma...@mesosphere.io>> wrote:
>> > Hi guys,
>> >
>> > just wanted to let you all know that we (Mesosphere) fully
>> intend to
>> > continue supporting distributing binary packages for the
>> current set of
>> > supported OSes (namely, Ubuntu / Debian / RedHat / CentOS as
>> listed in [0]).
>> >
>> > Sorry that 0.24 slipped through the cracks, the person who
>> actually takes
>> > care of that and knows the magic incantations has been
>> unwell, and a number
>> > of other competing priorities got in the way - we will
>> eventually be
>> > automating the process, so that downloadable binary packages
>> are created out
>> > of each release/RC build (and, possibly, even more often)
>> without pesky
>> > humans getting in the way :) but this may take some time.
>> > We're building the 0.24 ones as we speak, so please bear with
>> us while this
>> > gets done.
>> >
>> > Any questions / suggestions, we'd love to hear those too!
>> >
>> > [0] https://mesosphere.com/downloads/
>> >
>> > Marco Massenzio
>> > Distributed Systems Engineer
>> > http://codetrips.com
>> >
>> > On Tue, Sep 22, 2015 at 10:54 AM, CCAAT
>> <ccaat@tampabay.rr.com <ma...@tampabay.rr.com>> wrote:
>> >>
>> >> On 09/21/2015 03:01 PM, Vinod Kone wrote:
>> >>>
>> >>> +Jake Farrell
>> >>>
>> >>> The mesos project doesn't publish platform dependent
>> artifacts. We
>> >>> currently only publish platform independent artifacts like
>> JAR (to
>> >>> apache maven) and interface EGG (to PyPI).
>> >>>
>> >>> Recently we made the decision
>> >>>
>> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html
>> >
>> for
>> >>> the project to not officially support different language
>> (java, python)
>> >>> framework libraries going forward (likely after 1.0). The
>> project will
>> >>> only support C++ libraries which will live in the repo and
>> link to other
>> >>> language libraries from our website.
>> >>>
>> >>> The main reason was that the PMC lacks the expertise to
>> support various
>> >>> language bindings and hence we wanted to remove the support
>> burden.
>> >>>
>> >>> Option #1) It looks like we could do a similar thing with
>> RPMs/DEBs,
>> >>> i.e., link to 3rd party artifacts from the project website.
>> Similar to
>> >>> the client library authors, we could hold package maintainers
>> >>> accountable by providing guidelines.
>> >>>
>> >>> Option #2) Since the project officially supports certain
>> platforms
>> >>> (Ubuntu, CentOS, OSX) and continuously tests this via CI,
>> we could've
>> >>> the CI continuously build and upload the packages. Not sure
>> what's ASF
>> >>> stance on this is. I filed a ticket
>> >>> <https://issues.apache.org/jira/browse/INFRA-10385> a while
>> ago with
>> >>> INFRA regarding something similar, but never received any
>> response.
>> >>>
>> >>> Personally, with the direction the project is headed
>> towards, I prefer
>> >>> #1.
>> >>
>> >>
>> >> +1 (Option #1)
>> >>
>> >> This 'Option #1' approach will require the core dev team to
>> clearly convey
>> >> what is needed for any OS supported, not the chosen OSes for
>> support. Right
>> >> now, I'm having to parse many documents to figure out how to
>> extend the
>> >> gentoo ebuild for mesos. And where to cut off what I do in
>> the ebuilds and
>> >> what to put into the configuration documents for gentoo.
>> Naturally the
>> >> minimial is only what should be in the the gentoo ebuild;
>> with other items,
>> >> such as HDFS as a compiler option. Once I get the btrfs/ceph
>> work
>> >> stabilized, there will be a compile time option for
>> btrfs/ceph with the
>> >> gentoo ebuild. Other distros that are not going that
>> >> way should have other Distributed File System options 'baked
>> into' their
>> >> installation on that OS.
>> >>
>> >>
>> >>
>> >> 'Option #1' sets the stage for many OSes to be supported and
>> the core dev
>> >> team only has to support a single document to clarify what
>> any distro needs
>> >> to robustly support mesos for their user community. This
>> will facilitate a
>> >> wider variety of experimentation, at the companion repos
>> too. This Option
>> >> #1 approach will further accelerate adoption of Mesos on a
>> very wide variety
>> >> of platforms and architectures, imho. It sets the stage for
>> valid benchmark
>> >> performance comparison between distros; something that the
>> gentoo community
>> >> will no doubt win....
>> >>
>> >> ;-)
>> >>
>> >> James
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez
>> <carlos@apache.org <ma...@apache.org>
>> >>> <mailto:carlos@apache.org <ma...@apache.org>>>
>> wrote:
>> >>>
>> >>> I'm using the same repo with some changes to build SSL
>> enabled
>> >>> packages
>> >>>
>> >>>
>> >>>
>>
>> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>> >>>
>> >>>
>> >>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski
>> >>> <radek@gruchalski.com <ma...@gruchalski.com>
>> <mailto:radek@gruchalski.com <ma...@gruchalski.com>>>
>> wrote:
>> >>> > Should be rather easy to package it with this little
>> tool from
>> >>> Mesosphere:
>> >>> > https://github.com/mesosphere/mesos-deb-packaging.
>> I’ve done it
>> >>> myself for
>> >>> > ubuntu 12.04 and 14.04.
>> >>> > The only thing that needs to be changed are the
>> dependencies, for
>> >>> ubuntu
>> >>> > this was:
>> >>> >
>> >>> > diff --git a/build_mesos b/build_mesos
>> >>> > index 81561bc..f756ef0 100755
>> >>> > --- a/build_mesos
>> >>> > +++ b/build_mesos
>> >>> > @@ -313,9 +313,10 @@ function deb_ {
>> >>> > --deb-recommends zookeeperd
>> >>> > --deb-recommends zookeeper-bin
>> >>> > -d 'java-runtime-headless'
>> >>> > - -d libcurl3
>> >>> > - -d libsvn1
>> >>> > - -d libsasl2-modules
>> >>> > + -d libcurl4-nss-dev
>> >>> > + -d libsasl2-dev
>> >>> > + -d libapr1-dev
>> >>> > + -d libsvn-dev
>> >>> >
>> >>> > It does look like the tool can build RPMs.
>> >>> >
>> >>> > Kind regards,
>> >>> > Radek Gruchalski
>> >>> > radek@gruchalski.com <ma...@gruchalski.com>
>> <mailto:radek@gruchalski.com <ma...@gruchalski.com>>
>> >>> > de.linkedin.com/in/radgruchalski/
>> <http://de.linkedin.com/in/radgruchalski/>
>> >>> <http://de.linkedin.com/in/radgruchalski/>
>> >>> >
>> >>> > Confidentiality:
>> >>> > This communication is intended for the above-named
>> person and may
>> >>> be
>> >>> > confidential and/or legally privileged.
>> >>> > If it has come to you in error you must take no
>> action based on
>> >>> it, nor must
>> >>> > you copy or show it to anyone; please delete/destroy
>> and inform
>> >>> the sender
>> >>> > immediately.
>> >>> >
>> >>> > On Saturday, 19 September 2015 at 04:09, craig w
>> wrote:
>> >>> >
>> >>> > Mesosphere provides packages, you can find more
>> information here:
>> >>> > https://mesosphere.com/downloads/
>> >>> >
>> >>> > As of right now, they don't seem to have a 0.24.0
>> package.
>> >>> >
>> >>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks
>> >>> <brian@brianthicks.com <ma...@brianthicks.com>
>> <mailto:brian@brianthicks.com <ma...@brianthicks.com>>>
>> wrote:
>> >>> >
>> >>> > We've got some experimental packages at
>> >>> bintray.com/asteris/mantl-rpm
>> <http://bintray.com/asteris/mantl-rpm>
>> <http://bintray.com/asteris/mantl-rpm>,
>> >>> > source is at github.com/asteris-llc/mesos-packaging
>> <http://github.com/asteris-llc/mesos-packaging>
>> >>> <http://github.com/asteris-llc/mesos-packaging>. They
>> can really use
>> >>> > some testing if you wanted to give them a try.
>> Configuration is a
>> >>> bit
>> >>> > different than the Mesosphere packages, see the repo
>> for details.
>> >>> >
>> >>> > On Sep 18, 2015 7:01 PM, "Zameer Manji"
>> <zmanji@apache.org <ma...@apache.org>
>> >>> <mailto:zmanji@apache.org <ma...@apache.org>>>
>> wrote:
>> >>> >
>> >>> > Hey,
>> >>> >
>> >>> > Does the Apache Mesos project provide OS packages for
>> >>> installation? I
>> >>> > haven't been able to find any for the 0.24 release
>> and I think
>> >>> having them
>> >>> > would make installing Mesos a lot easier.
>> >>> >
>> >>> > --
>> >>> > Zameer Manji
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> >
>> >>> > https://github.com/mindscratch
>> >>> > https://www.google.com/+CraigWickesser
>> >>> > https://twitter.com/mind_scratch
>> >>> > https://twitter.com/craig_links
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>
>> >
>>
>> --
>> Zameer Manji
>>
>>
>>
>
Re: Official RPMs
Posted by CCAAT <cc...@tampabay.rr.com>.
On 09/25/2015 07:36 PM, Marco Massenzio wrote:
> Yes, the plan is definitely to make the tooling available to the
> project: there is nothing "secret" about it - at the moment,
> unfortunately, it relies on a bit of internal infrastructure and, well,
> yesss, it's a bit too crafty to be ready for "external consumption"....
> but we're working on it!
Hello Marco,
I' packaging up for gentoo linux. Just the itemized list of
what/where/when you setup config files and such would be a keen help to
my efforts. I can substitute in gentoo-centric tools, if you can provide
a brief description on what your infra/tools are doing.
A skeletal spec, if you like.
James
>
> /Marco Massenzio/
> /Distributed Systems Engineer
> http://codetrips.com/
>
> On Fri, Sep 25, 2015 at 11:33 AM, Zameer Manji <zmanji@apache.org
> <ma...@apache.org>> wrote:
>
> Could mesosphere donate their tooling for packaging mesos to the
> project? This way any project member or contributor can build
> packages and it can be apart of the release process.
>
> On Fri, Sep 25, 2015 at 10:53 AM, Artem Harutyunyan
> <artem@mesosphere.io <ma...@mesosphere.io>> wrote:
>
> The repositories have been updated yesterday, and the downloads page
> was updated today. Mesos 0.24 packages are now available at
> https://mesosphere.com/downloads/. Thank you very much for your
> patience!
>
> Cheers,
> Artem.
>
> On Tue, Sep 22, 2015 at 11:02 AM, Marco Massenzio
> <marco@mesosphere.io <ma...@mesosphere.io>> wrote:
> > Hi guys,
> >
> > just wanted to let you all know that we (Mesosphere) fully
> intend to
> > continue supporting distributing binary packages for the
> current set of
> > supported OSes (namely, Ubuntu / Debian / RedHat / CentOS as
> listed in [0]).
> >
> > Sorry that 0.24 slipped through the cracks, the person who
> actually takes
> > care of that and knows the magic incantations has been
> unwell, and a number
> > of other competing priorities got in the way - we will
> eventually be
> > automating the process, so that downloadable binary packages
> are created out
> > of each release/RC build (and, possibly, even more often)
> without pesky
> > humans getting in the way :) but this may take some time.
> > We're building the 0.24 ones as we speak, so please bear with
> us while this
> > gets done.
> >
> > Any questions / suggestions, we'd love to hear those too!
> >
> > [0] https://mesosphere.com/downloads/
> >
> > Marco Massenzio
> > Distributed Systems Engineer
> > http://codetrips.com
> >
> > On Tue, Sep 22, 2015 at 10:54 AM, CCAAT
> <ccaat@tampabay.rr.com <ma...@tampabay.rr.com>> wrote:
> >>
> >> On 09/21/2015 03:01 PM, Vinod Kone wrote:
> >>>
> >>> +Jake Farrell
> >>>
> >>> The mesos project doesn't publish platform dependent
> artifacts. We
> >>> currently only publish platform independent artifacts like
> JAR (to
> >>> apache maven) and interface EGG (to PyPI).
> >>>
> >>> Recently we made the decision
> >>>
> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html>
> for
> >>> the project to not officially support different language
> (java, python)
> >>> framework libraries going forward (likely after 1.0). The
> project will
> >>> only support C++ libraries which will live in the repo and
> link to other
> >>> language libraries from our website.
> >>>
> >>> The main reason was that the PMC lacks the expertise to
> support various
> >>> language bindings and hence we wanted to remove the support
> burden.
> >>>
> >>> Option #1) It looks like we could do a similar thing with
> RPMs/DEBs,
> >>> i.e., link to 3rd party artifacts from the project website.
> Similar to
> >>> the client library authors, we could hold package maintainers
> >>> accountable by providing guidelines.
> >>>
> >>> Option #2) Since the project officially supports certain
> platforms
> >>> (Ubuntu, CentOS, OSX) and continuously tests this via CI,
> we could've
> >>> the CI continuously build and upload the packages. Not sure
> what's ASF
> >>> stance on this is. I filed a ticket
> >>> <https://issues.apache.org/jira/browse/INFRA-10385> a while
> ago with
> >>> INFRA regarding something similar, but never received any
> response.
> >>>
> >>> Personally, with the direction the project is headed
> towards, I prefer
> >>> #1.
> >>
> >>
> >> +1 (Option #1)
> >>
> >> This 'Option #1' approach will require the core dev team to
> clearly convey
> >> what is needed for any OS supported, not the chosen OSes for
> support. Right
> >> now, I'm having to parse many documents to figure out how to
> extend the
> >> gentoo ebuild for mesos. And where to cut off what I do in
> the ebuilds and
> >> what to put into the configuration documents for gentoo.
> Naturally the
> >> minimial is only what should be in the the gentoo ebuild;
> with other items,
> >> such as HDFS as a compiler option. Once I get the btrfs/ceph
> work
> >> stabilized, there will be a compile time option for
> btrfs/ceph with the
> >> gentoo ebuild. Other distros that are not going that
> >> way should have other Distributed File System options 'baked
> into' their
> >> installation on that OS.
> >>
> >>
> >>
> >> 'Option #1' sets the stage for many OSes to be supported and
> the core dev
> >> team only has to support a single document to clarify what
> any distro needs
> >> to robustly support mesos for their user community. This
> will facilitate a
> >> wider variety of experimentation, at the companion repos
> too. This Option
> >> #1 approach will further accelerate adoption of Mesos on a
> very wide variety
> >> of platforms and architectures, imho. It sets the stage for
> valid benchmark
> >> performance comparison between distros; something that the
> gentoo community
> >> will no doubt win....
> >>
> >> ;-)
> >>
> >> James
> >>
> >>
> >>
> >>
> >>>
> >>> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez
> <carlos@apache.org <ma...@apache.org>
> >>> <mailto:carlos@apache.org <ma...@apache.org>>> wrote:
> >>>
> >>> I'm using the same repo with some changes to build SSL
> enabled
> >>> packages
> >>>
> >>>
> >>>
> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
> >>>
> >>>
> >>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski
> >>> <radek@gruchalski.com <ma...@gruchalski.com>
> <mailto:radek@gruchalski.com <ma...@gruchalski.com>>> wrote:
> >>> > Should be rather easy to package it with this little
> tool from
> >>> Mesosphere:
> >>> > https://github.com/mesosphere/mesos-deb-packaging.
> I’ve done it
> >>> myself for
> >>> > ubuntu 12.04 and 14.04.
> >>> > The only thing that needs to be changed are the
> dependencies, for
> >>> ubuntu
> >>> > this was:
> >>> >
> >>> > diff --git a/build_mesos b/build_mesos
> >>> > index 81561bc..f756ef0 100755
> >>> > --- a/build_mesos
> >>> > +++ b/build_mesos
> >>> > @@ -313,9 +313,10 @@ function deb_ {
> >>> > --deb-recommends zookeeperd
> >>> > --deb-recommends zookeeper-bin
> >>> > -d 'java-runtime-headless'
> >>> > - -d libcurl3
> >>> > - -d libsvn1
> >>> > - -d libsasl2-modules
> >>> > + -d libcurl4-nss-dev
> >>> > + -d libsasl2-dev
> >>> > + -d libapr1-dev
> >>> > + -d libsvn-dev
> >>> >
> >>> > It does look like the tool can build RPMs.
> >>> >
> >>> > Kind regards,
> >>> > Radek Gruchalski
> >>> > radek@gruchalski.com <ma...@gruchalski.com>
> <mailto:radek@gruchalski.com <ma...@gruchalski.com>>
> >>> > de.linkedin.com/in/radgruchalski/
> <http://de.linkedin.com/in/radgruchalski/>
> >>> <http://de.linkedin.com/in/radgruchalski/>
> >>> >
> >>> > Confidentiality:
> >>> > This communication is intended for the above-named
> person and may
> >>> be
> >>> > confidential and/or legally privileged.
> >>> > If it has come to you in error you must take no
> action based on
> >>> it, nor must
> >>> > you copy or show it to anyone; please delete/destroy
> and inform
> >>> the sender
> >>> > immediately.
> >>> >
> >>> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
> >>> >
> >>> > Mesosphere provides packages, you can find more
> information here:
> >>> > https://mesosphere.com/downloads/
> >>> >
> >>> > As of right now, they don't seem to have a 0.24.0
> package.
> >>> >
> >>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks
> >>> <brian@brianthicks.com <ma...@brianthicks.com>
> <mailto:brian@brianthicks.com <ma...@brianthicks.com>>>
> wrote:
> >>> >
> >>> > We've got some experimental packages at
> >>> bintray.com/asteris/mantl-rpm
> <http://bintray.com/asteris/mantl-rpm>
> <http://bintray.com/asteris/mantl-rpm>,
> >>> > source is at github.com/asteris-llc/mesos-packaging
> <http://github.com/asteris-llc/mesos-packaging>
> >>> <http://github.com/asteris-llc/mesos-packaging>. They
> can really use
> >>> > some testing if you wanted to give them a try.
> Configuration is a
> >>> bit
> >>> > different than the Mesosphere packages, see the repo
> for details.
> >>> >
> >>> > On Sep 18, 2015 7:01 PM, "Zameer Manji"
> <zmanji@apache.org <ma...@apache.org>
> >>> <mailto:zmanji@apache.org <ma...@apache.org>>>
> wrote:
> >>> >
> >>> > Hey,
> >>> >
> >>> > Does the Apache Mesos project provide OS packages for
> >>> installation? I
> >>> > haven't been able to find any for the 0.24 release
> and I think
> >>> having them
> >>> > would make installing Mesos a lot easier.
> >>> >
> >>> > --
> >>> > Zameer Manji
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> >
> >>> > https://github.com/mindscratch
> >>> > https://www.google.com/+CraigWickesser
> >>> > https://twitter.com/mind_scratch
> >>> > https://twitter.com/craig_links
> >>> >
> >>> >
> >>>
> >>>
> >>
> >
>
> --
> Zameer Manji
>
>
Re: Official RPMs
Posted by Marco Massenzio <ma...@mesosphere.io>.
Yes, the plan is definitely to make the tooling available to the project:
there is nothing "secret" about it - at the moment, unfortunately, it
relies on a bit of internal infrastructure and, well, yesss, it's a bit too
crafty to be ready for "external consumption".... but we're working on it!
*Marco Massenzio*
*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*
On Fri, Sep 25, 2015 at 11:33 AM, Zameer Manji <zm...@apache.org> wrote:
> Could mesosphere donate their tooling for packaging mesos to the project?
> This way any project member or contributor can build packages and it can be
> apart of the release process.
>
> On Fri, Sep 25, 2015 at 10:53 AM, Artem Harutyunyan <ar...@mesosphere.io>
> wrote:
>
>> The repositories have been updated yesterday, and the downloads page
>> was updated today. Mesos 0.24 packages are now available at
>> https://mesosphere.com/downloads/. Thank you very much for your
>> patience!
>>
>> Cheers,
>> Artem.
>>
>> On Tue, Sep 22, 2015 at 11:02 AM, Marco Massenzio <ma...@mesosphere.io>
>> wrote:
>> > Hi guys,
>> >
>> > just wanted to let you all know that we (Mesosphere) fully intend to
>> > continue supporting distributing binary packages for the current set of
>> > supported OSes (namely, Ubuntu / Debian / RedHat / CentOS as listed in
>> [0]).
>> >
>> > Sorry that 0.24 slipped through the cracks, the person who actually
>> takes
>> > care of that and knows the magic incantations has been unwell, and a
>> number
>> > of other competing priorities got in the way - we will eventually be
>> > automating the process, so that downloadable binary packages are
>> created out
>> > of each release/RC build (and, possibly, even more often) without pesky
>> > humans getting in the way :) but this may take some time.
>> > We're building the 0.24 ones as we speak, so please bear with us while
>> this
>> > gets done.
>> >
>> > Any questions / suggestions, we'd love to hear those too!
>> >
>> > [0] https://mesosphere.com/downloads/
>> >
>> > Marco Massenzio
>> > Distributed Systems Engineer
>> > http://codetrips.com
>> >
>> > On Tue, Sep 22, 2015 at 10:54 AM, CCAAT <cc...@tampabay.rr.com> wrote:
>> >>
>> >> On 09/21/2015 03:01 PM, Vinod Kone wrote:
>> >>>
>> >>> +Jake Farrell
>> >>>
>> >>> The mesos project doesn't publish platform dependent artifacts. We
>> >>> currently only publish platform independent artifacts like JAR (to
>> >>> apache maven) and interface EGG (to PyPI).
>> >>>
>> >>> Recently we made the decision
>> >>> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html>
>> for
>> >>> the project to not officially support different language (java,
>> python)
>> >>> framework libraries going forward (likely after 1.0). The project will
>> >>> only support C++ libraries which will live in the repo and link to
>> other
>> >>> language libraries from our website.
>> >>>
>> >>> The main reason was that the PMC lacks the expertise to support
>> various
>> >>> language bindings and hence we wanted to remove the support burden.
>> >>>
>> >>> Option #1) It looks like we could do a similar thing with RPMs/DEBs,
>> >>> i.e., link to 3rd party artifacts from the project website. Similar to
>> >>> the client library authors, we could hold package maintainers
>> >>> accountable by providing guidelines.
>> >>>
>> >>> Option #2) Since the project officially supports certain platforms
>> >>> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've
>> >>> the CI continuously build and upload the packages. Not sure what's ASF
>> >>> stance on this is. I filed a ticket
>> >>> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with
>> >>> INFRA regarding something similar, but never received any response.
>> >>>
>> >>> Personally, with the direction the project is headed towards, I prefer
>> >>> #1.
>> >>
>> >>
>> >> +1 (Option #1)
>> >>
>> >> This 'Option #1' approach will require the core dev team to clearly
>> convey
>> >> what is needed for any OS supported, not the chosen OSes for support.
>> Right
>> >> now, I'm having to parse many documents to figure out how to extend the
>> >> gentoo ebuild for mesos. And where to cut off what I do in the ebuilds
>> and
>> >> what to put into the configuration documents for gentoo. Naturally the
>> >> minimial is only what should be in the the gentoo ebuild; with other
>> items,
>> >> such as HDFS as a compiler option. Once I get the btrfs/ceph work
>> >> stabilized, there will be a compile time option for btrfs/ceph with the
>> >> gentoo ebuild. Other distros that are not going that
>> >> way should have other Distributed File System options 'baked into'
>> their
>> >> installation on that OS.
>> >>
>> >>
>> >>
>> >> 'Option #1' sets the stage for many OSes to be supported and the core
>> dev
>> >> team only has to support a single document to clarify what any distro
>> needs
>> >> to robustly support mesos for their user community. This will
>> facilitate a
>> >> wider variety of experimentation, at the companion repos too. This
>> Option
>> >> #1 approach will further accelerate adoption of Mesos on a very wide
>> variety
>> >> of platforms and architectures, imho. It sets the stage for valid
>> benchmark
>> >> performance comparison between distros; something that the gentoo
>> community
>> >> will no doubt win....
>> >>
>> >> ;-)
>> >>
>> >> James
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <carlos@apache.org
>> >>> <ma...@apache.org>> wrote:
>> >>>
>> >>> I'm using the same repo with some changes to build SSL enabled
>> >>> packages
>> >>>
>> >>>
>> >>>
>> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>> >>>
>> >>>
>> >>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski
>> >>> <radek@gruchalski.com <ma...@gruchalski.com>> wrote:
>> >>> > Should be rather easy to package it with this little tool from
>> >>> Mesosphere:
>> >>> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done
>> it
>> >>> myself for
>> >>> > ubuntu 12.04 and 14.04.
>> >>> > The only thing that needs to be changed are the dependencies,
>> for
>> >>> ubuntu
>> >>> > this was:
>> >>> >
>> >>> > diff --git a/build_mesos b/build_mesos
>> >>> > index 81561bc..f756ef0 100755
>> >>> > --- a/build_mesos
>> >>> > +++ b/build_mesos
>> >>> > @@ -313,9 +313,10 @@ function deb_ {
>> >>> > --deb-recommends zookeeperd
>> >>> > --deb-recommends zookeeper-bin
>> >>> > -d 'java-runtime-headless'
>> >>> > - -d libcurl3
>> >>> > - -d libsvn1
>> >>> > - -d libsasl2-modules
>> >>> > + -d libcurl4-nss-dev
>> >>> > + -d libsasl2-dev
>> >>> > + -d libapr1-dev
>> >>> > + -d libsvn-dev
>> >>> >
>> >>> > It does look like the tool can build RPMs.
>> >>> >
>> >>> > Kind regards,
>> >>> > Radek Gruchalski
>> >>> > radek@gruchalski.com <ma...@gruchalski.com>
>> >>> > de.linkedin.com/in/radgruchalski/
>> >>> <http://de.linkedin.com/in/radgruchalski/>
>> >>> >
>> >>> > Confidentiality:
>> >>> > This communication is intended for the above-named person and
>> may
>> >>> be
>> >>> > confidential and/or legally privileged.
>> >>> > If it has come to you in error you must take no action based on
>> >>> it, nor must
>> >>> > you copy or show it to anyone; please delete/destroy and inform
>> >>> the sender
>> >>> > immediately.
>> >>> >
>> >>> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
>> >>> >
>> >>> > Mesosphere provides packages, you can find more information
>> here:
>> >>> > https://mesosphere.com/downloads/
>> >>> >
>> >>> > As of right now, they don't seem to have a 0.24.0 package.
>> >>> >
>> >>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks
>> >>> <brian@brianthicks.com <ma...@brianthicks.com>> wrote:
>> >>> >
>> >>> > We've got some experimental packages at
>> >>> bintray.com/asteris/mantl-rpm <
>> http://bintray.com/asteris/mantl-rpm>,
>> >>> > source is at github.com/asteris-llc/mesos-packaging
>> >>> <http://github.com/asteris-llc/mesos-packaging>. They can really
>> use
>> >>> > some testing if you wanted to give them a try. Configuration
>> is a
>> >>> bit
>> >>> > different than the Mesosphere packages, see the repo for
>> details.
>> >>> >
>> >>> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zmanji@apache.org
>> >>> <ma...@apache.org>> wrote:
>> >>> >
>> >>> > Hey,
>> >>> >
>> >>> > Does the Apache Mesos project provide OS packages for
>> >>> installation? I
>> >>> > haven't been able to find any for the 0.24 release and I think
>> >>> having them
>> >>> > would make installing Mesos a lot easier.
>> >>> >
>> >>> > --
>> >>> > Zameer Manji
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> >
>> >>> > https://github.com/mindscratch
>> >>> > https://www.google.com/+CraigWickesser
>> >>> > https://twitter.com/mind_scratch
>> >>> > https://twitter.com/craig_links
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>
>> >
>>
>> --
>> Zameer Manji
>>
>>
Re: Official RPMs
Posted by haosdent <ha...@gmail.com>.
Maybe this one https://github.com/mesosphere/mesos-deb-packaging? Need
mesosphere guys help confirm. :-)
On Sat, Sep 26, 2015 at 2:33 AM, Zameer Manji <zm...@apache.org> wrote:
> Could mesosphere donate their tooling for packaging mesos to the project?
> This way any project member or contributor can build packages and it can be
> apart of the release process.
>
> On Fri, Sep 25, 2015 at 10:53 AM, Artem Harutyunyan <ar...@mesosphere.io>
> wrote:
>
>> The repositories have been updated yesterday, and the downloads page
>> was updated today. Mesos 0.24 packages are now available at
>> https://mesosphere.com/downloads/. Thank you very much for your
>> patience!
>>
>> Cheers,
>> Artem.
>>
>> On Tue, Sep 22, 2015 at 11:02 AM, Marco Massenzio <ma...@mesosphere.io>
>> wrote:
>> > Hi guys,
>> >
>> > just wanted to let you all know that we (Mesosphere) fully intend to
>> > continue supporting distributing binary packages for the current set of
>> > supported OSes (namely, Ubuntu / Debian / RedHat / CentOS as listed in
>> [0]).
>> >
>> > Sorry that 0.24 slipped through the cracks, the person who actually
>> takes
>> > care of that and knows the magic incantations has been unwell, and a
>> number
>> > of other competing priorities got in the way - we will eventually be
>> > automating the process, so that downloadable binary packages are
>> created out
>> > of each release/RC build (and, possibly, even more often) without pesky
>> > humans getting in the way :) but this may take some time.
>> > We're building the 0.24 ones as we speak, so please bear with us while
>> this
>> > gets done.
>> >
>> > Any questions / suggestions, we'd love to hear those too!
>> >
>> > [0] https://mesosphere.com/downloads/
>> >
>> > Marco Massenzio
>> > Distributed Systems Engineer
>> > http://codetrips.com
>> >
>> > On Tue, Sep 22, 2015 at 10:54 AM, CCAAT <cc...@tampabay.rr.com> wrote:
>> >>
>> >> On 09/21/2015 03:01 PM, Vinod Kone wrote:
>> >>>
>> >>> +Jake Farrell
>> >>>
>> >>> The mesos project doesn't publish platform dependent artifacts. We
>> >>> currently only publish platform independent artifacts like JAR (to
>> >>> apache maven) and interface EGG (to PyPI).
>> >>>
>> >>> Recently we made the decision
>> >>> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html>
>> for
>> >>> the project to not officially support different language (java,
>> python)
>> >>> framework libraries going forward (likely after 1.0). The project will
>> >>> only support C++ libraries which will live in the repo and link to
>> other
>> >>> language libraries from our website.
>> >>>
>> >>> The main reason was that the PMC lacks the expertise to support
>> various
>> >>> language bindings and hence we wanted to remove the support burden.
>> >>>
>> >>> Option #1) It looks like we could do a similar thing with RPMs/DEBs,
>> >>> i.e., link to 3rd party artifacts from the project website. Similar to
>> >>> the client library authors, we could hold package maintainers
>> >>> accountable by providing guidelines.
>> >>>
>> >>> Option #2) Since the project officially supports certain platforms
>> >>> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've
>> >>> the CI continuously build and upload the packages. Not sure what's ASF
>> >>> stance on this is. I filed a ticket
>> >>> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with
>> >>> INFRA regarding something similar, but never received any response.
>> >>>
>> >>> Personally, with the direction the project is headed towards, I prefer
>> >>> #1.
>> >>
>> >>
>> >> +1 (Option #1)
>> >>
>> >> This 'Option #1' approach will require the core dev team to clearly
>> convey
>> >> what is needed for any OS supported, not the chosen OSes for support.
>> Right
>> >> now, I'm having to parse many documents to figure out how to extend the
>> >> gentoo ebuild for mesos. And where to cut off what I do in the ebuilds
>> and
>> >> what to put into the configuration documents for gentoo. Naturally the
>> >> minimial is only what should be in the the gentoo ebuild; with other
>> items,
>> >> such as HDFS as a compiler option. Once I get the btrfs/ceph work
>> >> stabilized, there will be a compile time option for btrfs/ceph with the
>> >> gentoo ebuild. Other distros that are not going that
>> >> way should have other Distributed File System options 'baked into'
>> their
>> >> installation on that OS.
>> >>
>> >>
>> >>
>> >> 'Option #1' sets the stage for many OSes to be supported and the core
>> dev
>> >> team only has to support a single document to clarify what any distro
>> needs
>> >> to robustly support mesos for their user community. This will
>> facilitate a
>> >> wider variety of experimentation, at the companion repos too. This
>> Option
>> >> #1 approach will further accelerate adoption of Mesos on a very wide
>> variety
>> >> of platforms and architectures, imho. It sets the stage for valid
>> benchmark
>> >> performance comparison between distros; something that the gentoo
>> community
>> >> will no doubt win....
>> >>
>> >> ;-)
>> >>
>> >> James
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <carlos@apache.org
>> >>> <ma...@apache.org>> wrote:
>> >>>
>> >>> I'm using the same repo with some changes to build SSL enabled
>> >>> packages
>> >>>
>> >>>
>> >>>
>> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>> >>>
>> >>>
>> >>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski
>> >>> <radek@gruchalski.com <ma...@gruchalski.com>> wrote:
>> >>> > Should be rather easy to package it with this little tool from
>> >>> Mesosphere:
>> >>> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done
>> it
>> >>> myself for
>> >>> > ubuntu 12.04 and 14.04.
>> >>> > The only thing that needs to be changed are the dependencies,
>> for
>> >>> ubuntu
>> >>> > this was:
>> >>> >
>> >>> > diff --git a/build_mesos b/build_mesos
>> >>> > index 81561bc..f756ef0 100755
>> >>> > --- a/build_mesos
>> >>> > +++ b/build_mesos
>> >>> > @@ -313,9 +313,10 @@ function deb_ {
>> >>> > --deb-recommends zookeeperd
>> >>> > --deb-recommends zookeeper-bin
>> >>> > -d 'java-runtime-headless'
>> >>> > - -d libcurl3
>> >>> > - -d libsvn1
>> >>> > - -d libsasl2-modules
>> >>> > + -d libcurl4-nss-dev
>> >>> > + -d libsasl2-dev
>> >>> > + -d libapr1-dev
>> >>> > + -d libsvn-dev
>> >>> >
>> >>> > It does look like the tool can build RPMs.
>> >>> >
>> >>> > Kind regards,
>> >>> > Radek Gruchalski
>> >>> > radek@gruchalski.com <ma...@gruchalski.com>
>> >>> > de.linkedin.com/in/radgruchalski/
>> >>> <http://de.linkedin.com/in/radgruchalski/>
>> >>> >
>> >>> > Confidentiality:
>> >>> > This communication is intended for the above-named person and
>> may
>> >>> be
>> >>> > confidential and/or legally privileged.
>> >>> > If it has come to you in error you must take no action based on
>> >>> it, nor must
>> >>> > you copy or show it to anyone; please delete/destroy and inform
>> >>> the sender
>> >>> > immediately.
>> >>> >
>> >>> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
>> >>> >
>> >>> > Mesosphere provides packages, you can find more information
>> here:
>> >>> > https://mesosphere.com/downloads/
>> >>> >
>> >>> > As of right now, they don't seem to have a 0.24.0 package.
>> >>> >
>> >>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks
>> >>> <brian@brianthicks.com <ma...@brianthicks.com>> wrote:
>> >>> >
>> >>> > We've got some experimental packages at
>> >>> bintray.com/asteris/mantl-rpm <
>> http://bintray.com/asteris/mantl-rpm>,
>> >>> > source is at github.com/asteris-llc/mesos-packaging
>> >>> <http://github.com/asteris-llc/mesos-packaging>. They can really
>> use
>> >>> > some testing if you wanted to give them a try. Configuration
>> is a
>> >>> bit
>> >>> > different than the Mesosphere packages, see the repo for
>> details.
>> >>> >
>> >>> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zmanji@apache.org
>> >>> <ma...@apache.org>> wrote:
>> >>> >
>> >>> > Hey,
>> >>> >
>> >>> > Does the Apache Mesos project provide OS packages for
>> >>> installation? I
>> >>> > haven't been able to find any for the 0.24 release and I think
>> >>> having them
>> >>> > would make installing Mesos a lot easier.
>> >>> >
>> >>> > --
>> >>> > Zameer Manji
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> >
>> >>> > https://github.com/mindscratch
>> >>> > https://www.google.com/+CraigWickesser
>> >>> > https://twitter.com/mind_scratch
>> >>> > https://twitter.com/craig_links
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>
>> >
>>
>> --
>> Zameer Manji
>>
>>
--
Best Regards,
Haosdent Huang
Re: Official RPMs
Posted by Zameer Manji <zm...@apache.org>.
Could mesosphere donate their tooling for packaging mesos to the project?
This way any project member or contributor can build packages and it can be
apart of the release process.
On Fri, Sep 25, 2015 at 10:53 AM, Artem Harutyunyan <ar...@mesosphere.io>
wrote:
> The repositories have been updated yesterday, and the downloads page
> was updated today. Mesos 0.24 packages are now available at
> https://mesosphere.com/downloads/. Thank you very much for your
> patience!
>
> Cheers,
> Artem.
>
> On Tue, Sep 22, 2015 at 11:02 AM, Marco Massenzio <ma...@mesosphere.io>
> wrote:
> > Hi guys,
> >
> > just wanted to let you all know that we (Mesosphere) fully intend to
> > continue supporting distributing binary packages for the current set of
> > supported OSes (namely, Ubuntu / Debian / RedHat / CentOS as listed in
> [0]).
> >
> > Sorry that 0.24 slipped through the cracks, the person who actually takes
> > care of that and knows the magic incantations has been unwell, and a
> number
> > of other competing priorities got in the way - we will eventually be
> > automating the process, so that downloadable binary packages are created
> out
> > of each release/RC build (and, possibly, even more often) without pesky
> > humans getting in the way :) but this may take some time.
> > We're building the 0.24 ones as we speak, so please bear with us while
> this
> > gets done.
> >
> > Any questions / suggestions, we'd love to hear those too!
> >
> > [0] https://mesosphere.com/downloads/
> >
> > Marco Massenzio
> > Distributed Systems Engineer
> > http://codetrips.com
> >
> > On Tue, Sep 22, 2015 at 10:54 AM, CCAAT <cc...@tampabay.rr.com> wrote:
> >>
> >> On 09/21/2015 03:01 PM, Vinod Kone wrote:
> >>>
> >>> +Jake Farrell
> >>>
> >>> The mesos project doesn't publish platform dependent artifacts. We
> >>> currently only publish platform independent artifacts like JAR (to
> >>> apache maven) and interface EGG (to PyPI).
> >>>
> >>> Recently we made the decision
> >>> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html> for
> >>> the project to not officially support different language (java, python)
> >>> framework libraries going forward (likely after 1.0). The project will
> >>> only support C++ libraries which will live in the repo and link to
> other
> >>> language libraries from our website.
> >>>
> >>> The main reason was that the PMC lacks the expertise to support various
> >>> language bindings and hence we wanted to remove the support burden.
> >>>
> >>> Option #1) It looks like we could do a similar thing with RPMs/DEBs,
> >>> i.e., link to 3rd party artifacts from the project website. Similar to
> >>> the client library authors, we could hold package maintainers
> >>> accountable by providing guidelines.
> >>>
> >>> Option #2) Since the project officially supports certain platforms
> >>> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've
> >>> the CI continuously build and upload the packages. Not sure what's ASF
> >>> stance on this is. I filed a ticket
> >>> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with
> >>> INFRA regarding something similar, but never received any response.
> >>>
> >>> Personally, with the direction the project is headed towards, I prefer
> >>> #1.
> >>
> >>
> >> +1 (Option #1)
> >>
> >> This 'Option #1' approach will require the core dev team to clearly
> convey
> >> what is needed for any OS supported, not the chosen OSes for support.
> Right
> >> now, I'm having to parse many documents to figure out how to extend the
> >> gentoo ebuild for mesos. And where to cut off what I do in the ebuilds
> and
> >> what to put into the configuration documents for gentoo. Naturally the
> >> minimial is only what should be in the the gentoo ebuild; with other
> items,
> >> such as HDFS as a compiler option. Once I get the btrfs/ceph work
> >> stabilized, there will be a compile time option for btrfs/ceph with the
> >> gentoo ebuild. Other distros that are not going that
> >> way should have other Distributed File System options 'baked into' their
> >> installation on that OS.
> >>
> >>
> >>
> >> 'Option #1' sets the stage for many OSes to be supported and the core
> dev
> >> team only has to support a single document to clarify what any distro
> needs
> >> to robustly support mesos for their user community. This will
> facilitate a
> >> wider variety of experimentation, at the companion repos too. This
> Option
> >> #1 approach will further accelerate adoption of Mesos on a very wide
> variety
> >> of platforms and architectures, imho. It sets the stage for valid
> benchmark
> >> performance comparison between distros; something that the gentoo
> community
> >> will no doubt win....
> >>
> >> ;-)
> >>
> >> James
> >>
> >>
> >>
> >>
> >>>
> >>> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <carlos@apache.org
> >>> <ma...@apache.org>> wrote:
> >>>
> >>> I'm using the same repo with some changes to build SSL enabled
> >>> packages
> >>>
> >>>
> >>>
> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
> >>>
> >>>
> >>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski
> >>> <radek@gruchalski.com <ma...@gruchalski.com>> wrote:
> >>> > Should be rather easy to package it with this little tool from
> >>> Mesosphere:
> >>> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done it
> >>> myself for
> >>> > ubuntu 12.04 and 14.04.
> >>> > The only thing that needs to be changed are the dependencies,
> for
> >>> ubuntu
> >>> > this was:
> >>> >
> >>> > diff --git a/build_mesos b/build_mesos
> >>> > index 81561bc..f756ef0 100755
> >>> > --- a/build_mesos
> >>> > +++ b/build_mesos
> >>> > @@ -313,9 +313,10 @@ function deb_ {
> >>> > --deb-recommends zookeeperd
> >>> > --deb-recommends zookeeper-bin
> >>> > -d 'java-runtime-headless'
> >>> > - -d libcurl3
> >>> > - -d libsvn1
> >>> > - -d libsasl2-modules
> >>> > + -d libcurl4-nss-dev
> >>> > + -d libsasl2-dev
> >>> > + -d libapr1-dev
> >>> > + -d libsvn-dev
> >>> >
> >>> > It does look like the tool can build RPMs.
> >>> >
> >>> > Kind regards,
> >>> > Radek Gruchalski
> >>> > radek@gruchalski.com <ma...@gruchalski.com>
> >>> > de.linkedin.com/in/radgruchalski/
> >>> <http://de.linkedin.com/in/radgruchalski/>
> >>> >
> >>> > Confidentiality:
> >>> > This communication is intended for the above-named person and
> may
> >>> be
> >>> > confidential and/or legally privileged.
> >>> > If it has come to you in error you must take no action based on
> >>> it, nor must
> >>> > you copy or show it to anyone; please delete/destroy and inform
> >>> the sender
> >>> > immediately.
> >>> >
> >>> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
> >>> >
> >>> > Mesosphere provides packages, you can find more information
> here:
> >>> > https://mesosphere.com/downloads/
> >>> >
> >>> > As of right now, they don't seem to have a 0.24.0 package.
> >>> >
> >>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks
> >>> <brian@brianthicks.com <ma...@brianthicks.com>> wrote:
> >>> >
> >>> > We've got some experimental packages at
> >>> bintray.com/asteris/mantl-rpm <
> http://bintray.com/asteris/mantl-rpm>,
> >>> > source is at github.com/asteris-llc/mesos-packaging
> >>> <http://github.com/asteris-llc/mesos-packaging>. They can really
> use
> >>> > some testing if you wanted to give them a try. Configuration is
> a
> >>> bit
> >>> > different than the Mesosphere packages, see the repo for
> details.
> >>> >
> >>> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zmanji@apache.org
> >>> <ma...@apache.org>> wrote:
> >>> >
> >>> > Hey,
> >>> >
> >>> > Does the Apache Mesos project provide OS packages for
> >>> installation? I
> >>> > haven't been able to find any for the 0.24 release and I think
> >>> having them
> >>> > would make installing Mesos a lot easier.
> >>> >
> >>> > --
> >>> > Zameer Manji
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> >
> >>> > https://github.com/mindscratch
> >>> > https://www.google.com/+CraigWickesser
> >>> > https://twitter.com/mind_scratch
> >>> > https://twitter.com/craig_links
> >>> >
> >>> >
> >>>
> >>>
> >>
> >
>
> --
> Zameer Manji
>
>
Re: Official RPMs
Posted by Artem Harutyunyan <ar...@mesosphere.io>.
The repositories have been updated yesterday, and the downloads page
was updated today. Mesos 0.24 packages are now available at
https://mesosphere.com/downloads/. Thank you very much for your
patience!
Cheers,
Artem.
On Tue, Sep 22, 2015 at 11:02 AM, Marco Massenzio <ma...@mesosphere.io> wrote:
> Hi guys,
>
> just wanted to let you all know that we (Mesosphere) fully intend to
> continue supporting distributing binary packages for the current set of
> supported OSes (namely, Ubuntu / Debian / RedHat / CentOS as listed in [0]).
>
> Sorry that 0.24 slipped through the cracks, the person who actually takes
> care of that and knows the magic incantations has been unwell, and a number
> of other competing priorities got in the way - we will eventually be
> automating the process, so that downloadable binary packages are created out
> of each release/RC build (and, possibly, even more often) without pesky
> humans getting in the way :) but this may take some time.
> We're building the 0.24 ones as we speak, so please bear with us while this
> gets done.
>
> Any questions / suggestions, we'd love to hear those too!
>
> [0] https://mesosphere.com/downloads/
>
> Marco Massenzio
> Distributed Systems Engineer
> http://codetrips.com
>
> On Tue, Sep 22, 2015 at 10:54 AM, CCAAT <cc...@tampabay.rr.com> wrote:
>>
>> On 09/21/2015 03:01 PM, Vinod Kone wrote:
>>>
>>> +Jake Farrell
>>>
>>> The mesos project doesn't publish platform dependent artifacts. We
>>> currently only publish platform independent artifacts like JAR (to
>>> apache maven) and interface EGG (to PyPI).
>>>
>>> Recently we made the decision
>>> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html> for
>>> the project to not officially support different language (java, python)
>>> framework libraries going forward (likely after 1.0). The project will
>>> only support C++ libraries which will live in the repo and link to other
>>> language libraries from our website.
>>>
>>> The main reason was that the PMC lacks the expertise to support various
>>> language bindings and hence we wanted to remove the support burden.
>>>
>>> Option #1) It looks like we could do a similar thing with RPMs/DEBs,
>>> i.e., link to 3rd party artifacts from the project website. Similar to
>>> the client library authors, we could hold package maintainers
>>> accountable by providing guidelines.
>>>
>>> Option #2) Since the project officially supports certain platforms
>>> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've
>>> the CI continuously build and upload the packages. Not sure what's ASF
>>> stance on this is. I filed a ticket
>>> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with
>>> INFRA regarding something similar, but never received any response.
>>>
>>> Personally, with the direction the project is headed towards, I prefer
>>> #1.
>>
>>
>> +1 (Option #1)
>>
>> This 'Option #1' approach will require the core dev team to clearly convey
>> what is needed for any OS supported, not the chosen OSes for support. Right
>> now, I'm having to parse many documents to figure out how to extend the
>> gentoo ebuild for mesos. And where to cut off what I do in the ebuilds and
>> what to put into the configuration documents for gentoo. Naturally the
>> minimial is only what should be in the the gentoo ebuild; with other items,
>> such as HDFS as a compiler option. Once I get the btrfs/ceph work
>> stabilized, there will be a compile time option for btrfs/ceph with the
>> gentoo ebuild. Other distros that are not going that
>> way should have other Distributed File System options 'baked into' their
>> installation on that OS.
>>
>>
>>
>> 'Option #1' sets the stage for many OSes to be supported and the core dev
>> team only has to support a single document to clarify what any distro needs
>> to robustly support mesos for their user community. This will facilitate a
>> wider variety of experimentation, at the companion repos too. This Option
>> #1 approach will further accelerate adoption of Mesos on a very wide variety
>> of platforms and architectures, imho. It sets the stage for valid benchmark
>> performance comparison between distros; something that the gentoo community
>> will no doubt win....
>>
>> ;-)
>>
>> James
>>
>>
>>
>>
>>>
>>> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <carlos@apache.org
>>> <ma...@apache.org>> wrote:
>>>
>>> I'm using the same repo with some changes to build SSL enabled
>>> packages
>>>
>>>
>>> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>>>
>>>
>>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski
>>> <radek@gruchalski.com <ma...@gruchalski.com>> wrote:
>>> > Should be rather easy to package it with this little tool from
>>> Mesosphere:
>>> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done it
>>> myself for
>>> > ubuntu 12.04 and 14.04.
>>> > The only thing that needs to be changed are the dependencies, for
>>> ubuntu
>>> > this was:
>>> >
>>> > diff --git a/build_mesos b/build_mesos
>>> > index 81561bc..f756ef0 100755
>>> > --- a/build_mesos
>>> > +++ b/build_mesos
>>> > @@ -313,9 +313,10 @@ function deb_ {
>>> > --deb-recommends zookeeperd
>>> > --deb-recommends zookeeper-bin
>>> > -d 'java-runtime-headless'
>>> > - -d libcurl3
>>> > - -d libsvn1
>>> > - -d libsasl2-modules
>>> > + -d libcurl4-nss-dev
>>> > + -d libsasl2-dev
>>> > + -d libapr1-dev
>>> > + -d libsvn-dev
>>> >
>>> > It does look like the tool can build RPMs.
>>> >
>>> > Kind regards,
>>> > Radek Gruchalski
>>> > radek@gruchalski.com <ma...@gruchalski.com>
>>> > de.linkedin.com/in/radgruchalski/
>>> <http://de.linkedin.com/in/radgruchalski/>
>>> >
>>> > Confidentiality:
>>> > This communication is intended for the above-named person and may
>>> be
>>> > confidential and/or legally privileged.
>>> > If it has come to you in error you must take no action based on
>>> it, nor must
>>> > you copy or show it to anyone; please delete/destroy and inform
>>> the sender
>>> > immediately.
>>> >
>>> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
>>> >
>>> > Mesosphere provides packages, you can find more information here:
>>> > https://mesosphere.com/downloads/
>>> >
>>> > As of right now, they don't seem to have a 0.24.0 package.
>>> >
>>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks
>>> <brian@brianthicks.com <ma...@brianthicks.com>> wrote:
>>> >
>>> > We've got some experimental packages at
>>> bintray.com/asteris/mantl-rpm <http://bintray.com/asteris/mantl-rpm>,
>>> > source is at github.com/asteris-llc/mesos-packaging
>>> <http://github.com/asteris-llc/mesos-packaging>. They can really use
>>> > some testing if you wanted to give them a try. Configuration is a
>>> bit
>>> > different than the Mesosphere packages, see the repo for details.
>>> >
>>> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zmanji@apache.org
>>> <ma...@apache.org>> wrote:
>>> >
>>> > Hey,
>>> >
>>> > Does the Apache Mesos project provide OS packages for
>>> installation? I
>>> > haven't been able to find any for the 0.24 release and I think
>>> having them
>>> > would make installing Mesos a lot easier.
>>> >
>>> > --
>>> > Zameer Manji
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > https://github.com/mindscratch
>>> > https://www.google.com/+CraigWickesser
>>> > https://twitter.com/mind_scratch
>>> > https://twitter.com/craig_links
>>> >
>>> >
>>>
>>>
>>
>
Re: Official RPMs
Posted by Zameer Manji <zm...@apache.org>.
Instead of relying on a private company's closed source tooling and private
infrastructure to produce packages, why can't the automation and hosting be
done by Apache? The Aurora project has a packaging repo which has the
tooling to build packages and uses the Apache CI infrastructure to produce
the packages.
I don't like the idea of relying on a private company (Mesosphere) to get a
usable Mesos installation.
On Tue, Sep 22, 2015 at 11:02 AM, Marco Massenzio <ma...@mesosphere.io>
wrote:
> Hi guys,
>
> just wanted to let you all know that we (Mesosphere) fully intend to
> continue supporting distributing binary packages for the current set of
> supported OSes (namely, Ubuntu / Debian / RedHat / CentOS as listed in [0]).
>
> Sorry that 0.24 slipped through the cracks, the person who actually takes
> care of that and knows the magic incantations has been unwell, and a number
> of other competing priorities got in the way - we will eventually be
> automating the process, so that downloadable binary packages are created
> out of each release/RC build (and, possibly, even more often) without pesky
> humans getting in the way :) but this may take some time.
> We're building the 0.24 ones as we speak, so please bear with us while
> this gets done.
>
> Any questions / suggestions, we'd love to hear those too!
>
> [0] https://mesosphere.com/downloads/
>
> *Marco Massenzio*
>
> *Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*
>
> On Tue, Sep 22, 2015 at 10:54 AM, CCAAT <cc...@tampabay.rr.com> wrote:
>
>> On 09/21/2015 03:01 PM, Vinod Kone wrote:
>>
>>> +Jake Farrell
>>>
>>> The mesos project doesn't publish platform dependent artifacts. We
>>> currently only publish platform independent artifacts like JAR (to
>>> apache maven) and interface EGG (to PyPI).
>>>
>>> Recently we made the decision
>>> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html> for
>>> the project to not officially support different language (java, python)
>>> framework libraries going forward (likely after 1.0). The project will
>>> only support C++ libraries which will live in the repo and link to other
>>> language libraries from our website.
>>>
>>> The main reason was that the PMC lacks the expertise to support various
>>> language bindings and hence we wanted to remove the support burden.
>>>
>>> Option #1) It looks like we could do a similar thing with RPMs/DEBs,
>>> i.e., link to 3rd party artifacts from the project website. Similar to
>>> the client library authors, we could hold package maintainers
>>> accountable by providing guidelines.
>>>
>>> Option #2) Since the project officially supports certain platforms
>>> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've
>>> the CI continuously build and upload the packages. Not sure what's ASF
>>> stance on this is. I filed a ticket
>>> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with
>>> INFRA regarding something similar, but never received any response.
>>>
>>> Personally, with the direction the project is headed towards, I prefer
>>> #1.
>>>
>>
>> +1 (Option #1)
>>
>> This 'Option #1' approach will require the core dev team to clearly
>> convey what is needed for any OS supported, not the chosen OSes for
>> support. Right now, I'm having to parse many documents to figure out how to
>> extend the gentoo ebuild for mesos. And where to cut off what I do in the
>> ebuilds and what to put into the configuration documents for gentoo.
>> Naturally the minimial is only what should be in the the gentoo ebuild;
>> with other items, such as HDFS as a compiler option. Once I get the
>> btrfs/ceph work stabilized, there will be a compile time option for
>> btrfs/ceph with the gentoo ebuild. Other distros that are not going that
>> way should have other Distributed File System options 'baked into' their
>> installation on that OS.
>>
>>
>>
>> 'Option #1' sets the stage for many OSes to be supported and the core dev
>> team only has to support a single document to clarify what any distro
>> needs to robustly support mesos for their user community. This will
>> facilitate a wider variety of experimentation, at the companion repos too.
>> This Option #1 approach will further accelerate adoption of Mesos on a
>> very wide variety of platforms and architectures, imho. It sets the stage
>> for valid benchmark performance comparison between distros; something that
>> the gentoo community will no doubt win....
>>
>> ;-)
>>
>> James
>>
>>
>>
>>
>>
>>> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <carlos@apache.org
>>> <ma...@apache.org>> wrote:
>>>
>>> I'm using the same repo with some changes to build SSL enabled
>>> packages
>>>
>>>
>>> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>>>
>>>
>>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski
>>> <radek@gruchalski.com <ma...@gruchalski.com>> wrote:
>>> > Should be rather easy to package it with this little tool from
>>> Mesosphere:
>>> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done it
>>> myself for
>>> > ubuntu 12.04 and 14.04.
>>> > The only thing that needs to be changed are the dependencies, for
>>> ubuntu
>>> > this was:
>>> >
>>> > diff --git a/build_mesos b/build_mesos
>>> > index 81561bc..f756ef0 100755
>>> > --- a/build_mesos
>>> > +++ b/build_mesos
>>> > @@ -313,9 +313,10 @@ function deb_ {
>>> > --deb-recommends zookeeperd
>>> > --deb-recommends zookeeper-bin
>>> > -d 'java-runtime-headless'
>>> > - -d libcurl3
>>> > - -d libsvn1
>>> > - -d libsasl2-modules
>>> > + -d libcurl4-nss-dev
>>> > + -d libsasl2-dev
>>> > + -d libapr1-dev
>>> > + -d libsvn-dev
>>> >
>>> > It does look like the tool can build RPMs.
>>> >
>>> > Kind regards,
>>> > Radek Gruchalski
>>> > radek@gruchalski.com <ma...@gruchalski.com>
>>> > de.linkedin.com/in/radgruchalski/
>>> <http://de.linkedin.com/in/radgruchalski/>
>>> >
>>> > Confidentiality:
>>> > This communication is intended for the above-named person and may
>>> be
>>> > confidential and/or legally privileged.
>>> > If it has come to you in error you must take no action based on
>>> it, nor must
>>> > you copy or show it to anyone; please delete/destroy and inform
>>> the sender
>>> > immediately.
>>> >
>>> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
>>> >
>>> > Mesosphere provides packages, you can find more information here:
>>> > https://mesosphere.com/downloads/
>>> >
>>> > As of right now, they don't seem to have a 0.24.0 package.
>>> >
>>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks
>>> <brian@brianthicks.com <ma...@brianthicks.com>> wrote:
>>> >
>>> > We've got some experimental packages at
>>> bintray.com/asteris/mantl-rpm <http://bintray.com/asteris/mantl-rpm
>>> >,
>>> > source is at github.com/asteris-llc/mesos-packaging
>>> <http://github.com/asteris-llc/mesos-packaging>. They can really use
>>> > some testing if you wanted to give them a try. Configuration is a
>>> bit
>>> > different than the Mesosphere packages, see the repo for details.
>>> >
>>> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zmanji@apache.org
>>> <ma...@apache.org>> wrote:
>>> >
>>> > Hey,
>>> >
>>> > Does the Apache Mesos project provide OS packages for
>>> installation? I
>>> > haven't been able to find any for the 0.24 release and I think
>>> having them
>>> > would make installing Mesos a lot easier.
>>> >
>>> > --
>>> > Zameer Manji
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > https://github.com/mindscratch
>>> > https://www.google.com/+CraigWickesser
>>> > https://twitter.com/mind_scratch
>>> > https://twitter.com/craig_links
>>> >
>>> >
>>>
>>> --
>>> Zameer Manji
>>>
>>>
Re: Official RPMs
Posted by Marco Massenzio <ma...@mesosphere.io>.
Hi guys,
just wanted to let you all know that we (Mesosphere) fully intend to
continue supporting distributing binary packages for the current set of
supported OSes (namely, Ubuntu / Debian / RedHat / CentOS as listed in [0]).
Sorry that 0.24 slipped through the cracks, the person who actually takes
care of that and knows the magic incantations has been unwell, and a number
of other competing priorities got in the way - we will eventually be
automating the process, so that downloadable binary packages are created
out of each release/RC build (and, possibly, even more often) without pesky
humans getting in the way :) but this may take some time.
We're building the 0.24 ones as we speak, so please bear with us while this
gets done.
Any questions / suggestions, we'd love to hear those too!
[0] https://mesosphere.com/downloads/
*Marco Massenzio*
*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*
On Tue, Sep 22, 2015 at 10:54 AM, CCAAT <cc...@tampabay.rr.com> wrote:
> On 09/21/2015 03:01 PM, Vinod Kone wrote:
>
>> +Jake Farrell
>>
>> The mesos project doesn't publish platform dependent artifacts. We
>> currently only publish platform independent artifacts like JAR (to
>> apache maven) and interface EGG (to PyPI).
>>
>> Recently we made the decision
>> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html> for
>> the project to not officially support different language (java, python)
>> framework libraries going forward (likely after 1.0). The project will
>> only support C++ libraries which will live in the repo and link to other
>> language libraries from our website.
>>
>> The main reason was that the PMC lacks the expertise to support various
>> language bindings and hence we wanted to remove the support burden.
>>
>> Option #1) It looks like we could do a similar thing with RPMs/DEBs,
>> i.e., link to 3rd party artifacts from the project website. Similar to
>> the client library authors, we could hold package maintainers
>> accountable by providing guidelines.
>>
>> Option #2) Since the project officially supports certain platforms
>> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've
>> the CI continuously build and upload the packages. Not sure what's ASF
>> stance on this is. I filed a ticket
>> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with
>> INFRA regarding something similar, but never received any response.
>>
>> Personally, with the direction the project is headed towards, I prefer #1.
>>
>
> +1 (Option #1)
>
> This 'Option #1' approach will require the core dev team to clearly convey
> what is needed for any OS supported, not the chosen OSes for support. Right
> now, I'm having to parse many documents to figure out how to extend the
> gentoo ebuild for mesos. And where to cut off what I do in the ebuilds and
> what to put into the configuration documents for gentoo. Naturally the
> minimial is only what should be in the the gentoo ebuild; with other items,
> such as HDFS as a compiler option. Once I get the btrfs/ceph work
> stabilized, there will be a compile time option for btrfs/ceph with the
> gentoo ebuild. Other distros that are not going that
> way should have other Distributed File System options 'baked into' their
> installation on that OS.
>
>
>
> 'Option #1' sets the stage for many OSes to be supported and the core dev
> team only has to support a single document to clarify what any distro
> needs to robustly support mesos for their user community. This will
> facilitate a wider variety of experimentation, at the companion repos too.
> This Option #1 approach will further accelerate adoption of Mesos on a
> very wide variety of platforms and architectures, imho. It sets the stage
> for valid benchmark performance comparison between distros; something that
> the gentoo community will no doubt win....
>
> ;-)
>
> James
>
>
>
>
>
>> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <carlos@apache.org
>> <ma...@apache.org>> wrote:
>>
>> I'm using the same repo with some changes to build SSL enabled
>> packages
>>
>>
>> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>>
>>
>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski
>> <radek@gruchalski.com <ma...@gruchalski.com>> wrote:
>> > Should be rather easy to package it with this little tool from
>> Mesosphere:
>> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done it
>> myself for
>> > ubuntu 12.04 and 14.04.
>> > The only thing that needs to be changed are the dependencies, for
>> ubuntu
>> > this was:
>> >
>> > diff --git a/build_mesos b/build_mesos
>> > index 81561bc..f756ef0 100755
>> > --- a/build_mesos
>> > +++ b/build_mesos
>> > @@ -313,9 +313,10 @@ function deb_ {
>> > --deb-recommends zookeeperd
>> > --deb-recommends zookeeper-bin
>> > -d 'java-runtime-headless'
>> > - -d libcurl3
>> > - -d libsvn1
>> > - -d libsasl2-modules
>> > + -d libcurl4-nss-dev
>> > + -d libsasl2-dev
>> > + -d libapr1-dev
>> > + -d libsvn-dev
>> >
>> > It does look like the tool can build RPMs.
>> >
>> > Kind regards,
>> > Radek Gruchalski
>> > radek@gruchalski.com <ma...@gruchalski.com>
>> > de.linkedin.com/in/radgruchalski/
>> <http://de.linkedin.com/in/radgruchalski/>
>> >
>> > Confidentiality:
>> > This communication is intended for the above-named person and may
>> be
>> > confidential and/or legally privileged.
>> > If it has come to you in error you must take no action based on
>> it, nor must
>> > you copy or show it to anyone; please delete/destroy and inform
>> the sender
>> > immediately.
>> >
>> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
>> >
>> > Mesosphere provides packages, you can find more information here:
>> > https://mesosphere.com/downloads/
>> >
>> > As of right now, they don't seem to have a 0.24.0 package.
>> >
>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks
>> <brian@brianthicks.com <ma...@brianthicks.com>> wrote:
>> >
>> > We've got some experimental packages at
>> bintray.com/asteris/mantl-rpm <http://bintray.com/asteris/mantl-rpm>,
>> > source is at github.com/asteris-llc/mesos-packaging
>> <http://github.com/asteris-llc/mesos-packaging>. They can really use
>> > some testing if you wanted to give them a try. Configuration is a
>> bit
>> > different than the Mesosphere packages, see the repo for details.
>> >
>> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zmanji@apache.org
>> <ma...@apache.org>> wrote:
>> >
>> > Hey,
>> >
>> > Does the Apache Mesos project provide OS packages for
>> installation? I
>> > haven't been able to find any for the 0.24 release and I think
>> having them
>> > would make installing Mesos a lot easier.
>> >
>> > --
>> > Zameer Manji
>> >
>> >
>> >
>> >
>> > --
>> >
>> > https://github.com/mindscratch
>> > https://www.google.com/+CraigWickesser
>> > https://twitter.com/mind_scratch
>> > https://twitter.com/craig_links
>> >
>> >
>>
>>
>>
>
Re: Official RPMs
Posted by CCAAT <cc...@tampabay.rr.com>.
On 09/21/2015 03:01 PM, Vinod Kone wrote:
> +Jake Farrell
>
> The mesos project doesn't publish platform dependent artifacts. We
> currently only publish platform independent artifacts like JAR (to
> apache maven) and interface EGG (to PyPI).
>
> Recently we made the decision
> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html> for
> the project to not officially support different language (java, python)
> framework libraries going forward (likely after 1.0). The project will
> only support C++ libraries which will live in the repo and link to other
> language libraries from our website.
>
> The main reason was that the PMC lacks the expertise to support various
> language bindings and hence we wanted to remove the support burden.
>
> Option #1) It looks like we could do a similar thing with RPMs/DEBs,
> i.e., link to 3rd party artifacts from the project website. Similar to
> the client library authors, we could hold package maintainers
> accountable by providing guidelines.
>
> Option #2) Since the project officially supports certain platforms
> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've
> the CI continuously build and upload the packages. Not sure what's ASF
> stance on this is. I filed a ticket
> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with
> INFRA regarding something similar, but never received any response.
>
> Personally, with the direction the project is headed towards, I prefer #1.
+1 (Option #1)
This 'Option #1' approach will require the core dev team to clearly
convey what is needed for any OS supported, not the chosen OSes for
support. Right now, I'm having to parse many documents to figure out how
to extend the gentoo ebuild for mesos. And where to cut off what I do in
the ebuilds and what to put into the configuration documents for gentoo.
Naturally the minimial is only what should be in the the gentoo ebuild;
with other items, such as HDFS as a compiler option. Once I get the
btrfs/ceph work stabilized, there will be a compile time option for
btrfs/ceph with the gentoo ebuild. Other distros that are not going that
way should have other Distributed File System options 'baked into' their
installation on that OS.
'Option #1' sets the stage for many OSes to be supported and the core
dev team only has to support a single document to clarify what any
distro needs to robustly support mesos for their user community. This
will facilitate a wider variety of experimentation, at the companion
repos too. This Option #1 approach will further accelerate adoption of
Mesos on a very wide variety of platforms and architectures, imho. It
sets the stage for valid benchmark performance comparison between
distros; something that the gentoo community will no doubt win....
;-)
James
>
> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <carlos@apache.org
> <ma...@apache.org>> wrote:
>
> I'm using the same repo with some changes to build SSL enabled packages
>
> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>
>
> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski
> <radek@gruchalski.com <ma...@gruchalski.com>> wrote:
> > Should be rather easy to package it with this little tool from
> Mesosphere:
> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done it
> myself for
> > ubuntu 12.04 and 14.04.
> > The only thing that needs to be changed are the dependencies, for
> ubuntu
> > this was:
> >
> > diff --git a/build_mesos b/build_mesos
> > index 81561bc..f756ef0 100755
> > --- a/build_mesos
> > +++ b/build_mesos
> > @@ -313,9 +313,10 @@ function deb_ {
> > --deb-recommends zookeeperd
> > --deb-recommends zookeeper-bin
> > -d 'java-runtime-headless'
> > - -d libcurl3
> > - -d libsvn1
> > - -d libsasl2-modules
> > + -d libcurl4-nss-dev
> > + -d libsasl2-dev
> > + -d libapr1-dev
> > + -d libsvn-dev
> >
> > It does look like the tool can build RPMs.
> >
> > Kind regards,
> > Radek Gruchalski
> > radek@gruchalski.com <ma...@gruchalski.com>
> > de.linkedin.com/in/radgruchalski/
> <http://de.linkedin.com/in/radgruchalski/>
> >
> > Confidentiality:
> > This communication is intended for the above-named person and may be
> > confidential and/or legally privileged.
> > If it has come to you in error you must take no action based on
> it, nor must
> > you copy or show it to anyone; please delete/destroy and inform
> the sender
> > immediately.
> >
> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
> >
> > Mesosphere provides packages, you can find more information here:
> > https://mesosphere.com/downloads/
> >
> > As of right now, they don't seem to have a 0.24.0 package.
> >
> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks
> <brian@brianthicks.com <ma...@brianthicks.com>> wrote:
> >
> > We've got some experimental packages at
> bintray.com/asteris/mantl-rpm <http://bintray.com/asteris/mantl-rpm>,
> > source is at github.com/asteris-llc/mesos-packaging
> <http://github.com/asteris-llc/mesos-packaging>. They can really use
> > some testing if you wanted to give them a try. Configuration is a bit
> > different than the Mesosphere packages, see the repo for details.
> >
> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zmanji@apache.org
> <ma...@apache.org>> wrote:
> >
> > Hey,
> >
> > Does the Apache Mesos project provide OS packages for installation? I
> > haven't been able to find any for the 0.24 release and I think
> having them
> > would make installing Mesos a lot easier.
> >
> > --
> > Zameer Manji
> >
> >
> >
> >
> > --
> >
> > https://github.com/mindscratch
> > https://www.google.com/+CraigWickesser
> > https://twitter.com/mind_scratch
> > https://twitter.com/craig_links
> >
> >
>
>
Re: Official RPMs
Posted by Zameer Manji <zm...@apache.org>.
I think option 2 is a really good way forward for the project. If the
project could provide packages for the tested platforms it will reduce the
amount of work required to setup Mesos.
On Tue, Sep 22, 2015 at 6:04 AM, Jake Farrell <jf...@apache.org> wrote:
> Not an easy project decision for sure, #2 adds some more work for the
> project and #1 can leave a bad impression of the project when a 3rd party
> does not keep its implementation current or maintained. Personally I tend
> to favor #2 as it keeps everything with the project and makes it easier for
> the end user.
>
> As for the CI, it can not produce official binary distributions as those
> require a vote. You can run the packaging as part of your testing, process
> but these resulting artifacts must be marked as snapshots and can not be
> uploaded for distribution.
>
> For official rpm/deb packages infra leverages bintray to do the actual
> hosting of the packages. I am currently working on scripting the process
> for publishing the package artifacts for Aurora to bintray. I also have
> native deb packaging for Mesos in my github fork available at [1]. If
> either of these are something that are of interest I'm happy to contribute
> them back to Mesos as patches and help maintain them moving forward.
>
> -Jake
>
> [1]: https://github.com/jfarrell/mesos/tree/debian-packaging
>
>
>
>
>
> On Mon, Sep 21, 2015 at 4:01 PM, Vinod Kone <vi...@apache.org> wrote:
>
>> +Jake Farrell
>>
>> The mesos project doesn't publish platform dependent artifacts. We
>> currently only publish platform independent artifacts like JAR (to apache
>> maven) and interface EGG (to PyPI).
>>
>> Recently we made the decision
>> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html> for
>> the project to not officially support different language (java, python)
>> framework libraries going forward (likely after 1.0). The project will only
>> support C++ libraries which will live in the repo and link to other
>> language libraries from our website.
>>
>> The main reason was that the PMC lacks the expertise to support various
>> language bindings and hence we wanted to remove the support burden.
>>
>> Option #1) It looks like we could do a similar thing with RPMs/DEBs,
>> i.e., link to 3rd party artifacts from the project website. Similar to the
>> client library authors, we could hold package maintainers accountable by
>> providing guidelines.
>>
>> Option #2) Since the project officially supports certain platforms
>> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've the
>> CI continuously build and upload the packages. Not sure what's ASF stance
>> on this is. I filed a ticket
>> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with
>> INFRA regarding something similar, but never received any response.
>>
>> Personally, with the direction the project is headed towards, I prefer #1.
>>
>> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <ca...@apache.org>
>> wrote:
>>
>>> I'm using the same repo with some changes to build SSL enabled packages
>>>
>>>
>>> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>>>
>>>
>>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski <ra...@gruchalski.com>
>>> wrote:
>>> > Should be rather easy to package it with this little tool from
>>> Mesosphere:
>>> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done it
>>> myself for
>>> > ubuntu 12.04 and 14.04.
>>> > The only thing that needs to be changed are the dependencies, for
>>> ubuntu
>>> > this was:
>>> >
>>> > diff --git a/build_mesos b/build_mesos
>>> > index 81561bc..f756ef0 100755
>>> > --- a/build_mesos
>>> > +++ b/build_mesos
>>> > @@ -313,9 +313,10 @@ function deb_ {
>>> > --deb-recommends zookeeperd
>>> > --deb-recommends zookeeper-bin
>>> > -d 'java-runtime-headless'
>>> > - -d libcurl3
>>> > - -d libsvn1
>>> > - -d libsasl2-modules
>>> > + -d libcurl4-nss-dev
>>> > + -d libsasl2-dev
>>> > + -d libapr1-dev
>>> > + -d libsvn-dev
>>> >
>>> > It does look like the tool can build RPMs.
>>> >
>>> > Kind regards,
>>> > Radek Gruchalski
>>> > radek@gruchalski.com
>>> > de.linkedin.com/in/radgruchalski/
>>> >
>>> > Confidentiality:
>>> > This communication is intended for the above-named person and may be
>>> > confidential and/or legally privileged.
>>> > If it has come to you in error you must take no action based on it,
>>> nor must
>>> > you copy or show it to anyone; please delete/destroy and inform the
>>> sender
>>> > immediately.
>>> >
>>> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
>>> >
>>> > Mesosphere provides packages, you can find more information here:
>>> > https://mesosphere.com/downloads/
>>> >
>>> > As of right now, they don't seem to have a 0.24.0 package.
>>> >
>>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks <br...@brianthicks.com>
>>> wrote:
>>> >
>>> > We've got some experimental packages at bintray.com/asteris/mantl-rpm,
>>> > source is at github.com/asteris-llc/mesos-packaging. They can really
>>> use
>>> > some testing if you wanted to give them a try. Configuration is a bit
>>> > different than the Mesosphere packages, see the repo for details.
>>> >
>>> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zm...@apache.org> wrote:
>>> >
>>> > Hey,
>>> >
>>> > Does the Apache Mesos project provide OS packages for installation? I
>>> > haven't been able to find any for the 0.24 release and I think having
>>> them
>>> > would make installing Mesos a lot easier.
>>> >
>>> > --
>>> > Zameer Manji
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > https://github.com/mindscratch
>>> > https://www.google.com/+CraigWickesser
>>> > https://twitter.com/mind_scratch
>>> > https://twitter.com/craig_links
>>> >
>>> >
>>>
>>> --
>>> Zameer Manji
>>>
>>>
Re: Official RPMs
Posted by Jake Farrell <jf...@apache.org>.
Not an easy project decision for sure, #2 adds some more work for the
project and #1 can leave a bad impression of the project when a 3rd party
does not keep its implementation current or maintained. Personally I tend
to favor #2 as it keeps everything with the project and makes it easier for
the end user.
As for the CI, it can not produce official binary distributions as those
require a vote. You can run the packaging as part of your testing, process
but these resulting artifacts must be marked as snapshots and can not be
uploaded for distribution.
For official rpm/deb packages infra leverages bintray to do the actual
hosting of the packages. I am currently working on scripting the process
for publishing the package artifacts for Aurora to bintray. I also have
native deb packaging for Mesos in my github fork available at [1]. If
either of these are something that are of interest I'm happy to contribute
them back to Mesos as patches and help maintain them moving forward.
-Jake
[1]: https://github.com/jfarrell/mesos/tree/debian-packaging
On Mon, Sep 21, 2015 at 4:01 PM, Vinod Kone <vi...@apache.org> wrote:
> +Jake Farrell
>
> The mesos project doesn't publish platform dependent artifacts. We
> currently only publish platform independent artifacts like JAR (to apache
> maven) and interface EGG (to PyPI).
>
> Recently we made the decision
> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html> for
> the project to not officially support different language (java, python)
> framework libraries going forward (likely after 1.0). The project will only
> support C++ libraries which will live in the repo and link to other
> language libraries from our website.
>
> The main reason was that the PMC lacks the expertise to support various
> language bindings and hence we wanted to remove the support burden.
>
> Option #1) It looks like we could do a similar thing with RPMs/DEBs, i.e.,
> link to 3rd party artifacts from the project website. Similar to the client
> library authors, we could hold package maintainers accountable by providing
> guidelines.
>
> Option #2) Since the project officially supports certain platforms
> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've the
> CI continuously build and upload the packages. Not sure what's ASF stance
> on this is. I filed a ticket
> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with
> INFRA regarding something similar, but never received any response.
>
> Personally, with the direction the project is headed towards, I prefer #1.
>
> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <ca...@apache.org> wrote:
>
>> I'm using the same repo with some changes to build SSL enabled packages
>>
>>
>> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>>
>>
>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski <ra...@gruchalski.com>
>> wrote:
>> > Should be rather easy to package it with this little tool from
>> Mesosphere:
>> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done it myself
>> for
>> > ubuntu 12.04 and 14.04.
>> > The only thing that needs to be changed are the dependencies, for ubuntu
>> > this was:
>> >
>> > diff --git a/build_mesos b/build_mesos
>> > index 81561bc..f756ef0 100755
>> > --- a/build_mesos
>> > +++ b/build_mesos
>> > @@ -313,9 +313,10 @@ function deb_ {
>> > --deb-recommends zookeeperd
>> > --deb-recommends zookeeper-bin
>> > -d 'java-runtime-headless'
>> > - -d libcurl3
>> > - -d libsvn1
>> > - -d libsasl2-modules
>> > + -d libcurl4-nss-dev
>> > + -d libsasl2-dev
>> > + -d libapr1-dev
>> > + -d libsvn-dev
>> >
>> > It does look like the tool can build RPMs.
>> >
>> > Kind regards,
>> > Radek Gruchalski
>> > radek@gruchalski.com
>> > de.linkedin.com/in/radgruchalski/
>> >
>> > Confidentiality:
>> > This communication is intended for the above-named person and may be
>> > confidential and/or legally privileged.
>> > If it has come to you in error you must take no action based on it, nor
>> must
>> > you copy or show it to anyone; please delete/destroy and inform the
>> sender
>> > immediately.
>> >
>> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
>> >
>> > Mesosphere provides packages, you can find more information here:
>> > https://mesosphere.com/downloads/
>> >
>> > As of right now, they don't seem to have a 0.24.0 package.
>> >
>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks <br...@brianthicks.com>
>> wrote:
>> >
>> > We've got some experimental packages at bintray.com/asteris/mantl-rpm,
>> > source is at github.com/asteris-llc/mesos-packaging. They can really
>> use
>> > some testing if you wanted to give them a try. Configuration is a bit
>> > different than the Mesosphere packages, see the repo for details.
>> >
>> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zm...@apache.org> wrote:
>> >
>> > Hey,
>> >
>> > Does the Apache Mesos project provide OS packages for installation? I
>> > haven't been able to find any for the 0.24 release and I think having
>> them
>> > would make installing Mesos a lot easier.
>> >
>> > --
>> > Zameer Manji
>> >
>> >
>> >
>> >
>> > --
>> >
>> > https://github.com/mindscratch
>> > https://www.google.com/+CraigWickesser
>> > https://twitter.com/mind_scratch
>> > https://twitter.com/craig_links
>> >
>> >
>>
>
>
Re: Official RPMs
Posted by Vinod Kone <vi...@apache.org>.
+Jake Farrell
The mesos project doesn't publish platform dependent artifacts. We
currently only publish platform independent artifacts like JAR (to apache
maven) and interface EGG (to PyPI).
Recently we made the decision
<http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html> for the
project to not officially support different language (java, python)
framework libraries going forward (likely after 1.0). The project will only
support C++ libraries which will live in the repo and link to other
language libraries from our website.
The main reason was that the PMC lacks the expertise to support various
language bindings and hence we wanted to remove the support burden.
Option #1) It looks like we could do a similar thing with RPMs/DEBs, i.e.,
link to 3rd party artifacts from the project website. Similar to the client
library authors, we could hold package maintainers accountable by providing
guidelines.
Option #2) Since the project officially supports certain platforms (Ubuntu,
CentOS, OSX) and continuously tests this via CI, we could've the CI
continuously build and upload the packages. Not sure what's ASF stance on
this is. I filed a ticket
<https://issues.apache.org/jira/browse/INFRA-10385> a while ago with INFRA
regarding something similar, but never received any response.
Personally, with the direction the project is headed towards, I prefer #1.
On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <ca...@apache.org> wrote:
> I'm using the same repo with some changes to build SSL enabled packages
>
>
> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
>
>
> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski <ra...@gruchalski.com>
> wrote:
> > Should be rather easy to package it with this little tool from
> Mesosphere:
> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done it myself
> for
> > ubuntu 12.04 and 14.04.
> > The only thing that needs to be changed are the dependencies, for ubuntu
> > this was:
> >
> > diff --git a/build_mesos b/build_mesos
> > index 81561bc..f756ef0 100755
> > --- a/build_mesos
> > +++ b/build_mesos
> > @@ -313,9 +313,10 @@ function deb_ {
> > --deb-recommends zookeeperd
> > --deb-recommends zookeeper-bin
> > -d 'java-runtime-headless'
> > - -d libcurl3
> > - -d libsvn1
> > - -d libsasl2-modules
> > + -d libcurl4-nss-dev
> > + -d libsasl2-dev
> > + -d libapr1-dev
> > + -d libsvn-dev
> >
> > It does look like the tool can build RPMs.
> >
> > Kind regards,
> > Radek Gruchalski
> > radek@gruchalski.com
> > de.linkedin.com/in/radgruchalski/
> >
> > Confidentiality:
> > This communication is intended for the above-named person and may be
> > confidential and/or legally privileged.
> > If it has come to you in error you must take no action based on it, nor
> must
> > you copy or show it to anyone; please delete/destroy and inform the
> sender
> > immediately.
> >
> > On Saturday, 19 September 2015 at 04:09, craig w wrote:
> >
> > Mesosphere provides packages, you can find more information here:
> > https://mesosphere.com/downloads/
> >
> > As of right now, they don't seem to have a 0.24.0 package.
> >
> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks <br...@brianthicks.com>
> wrote:
> >
> > We've got some experimental packages at bintray.com/asteris/mantl-rpm,
> > source is at github.com/asteris-llc/mesos-packaging. They can really use
> > some testing if you wanted to give them a try. Configuration is a bit
> > different than the Mesosphere packages, see the repo for details.
> >
> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zm...@apache.org> wrote:
> >
> > Hey,
> >
> > Does the Apache Mesos project provide OS packages for installation? I
> > haven't been able to find any for the 0.24 release and I think having
> them
> > would make installing Mesos a lot easier.
> >
> > --
> > Zameer Manji
> >
> >
> >
> >
> > --
> >
> > https://github.com/mindscratch
> > https://www.google.com/+CraigWickesser
> > https://twitter.com/mind_scratch
> > https://twitter.com/craig_links
> >
> >
>
Re: Official RPMs
Posted by Carlos Sanchez <ca...@apache.org>.
I'm using the same repo with some changes to build SSL enabled packages
https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl
On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski <ra...@gruchalski.com> wrote:
> Should be rather easy to package it with this little tool from Mesosphere:
> https://github.com/mesosphere/mesos-deb-packaging. I’ve done it myself for
> ubuntu 12.04 and 14.04.
> The only thing that needs to be changed are the dependencies, for ubuntu
> this was:
>
> diff --git a/build_mesos b/build_mesos
> index 81561bc..f756ef0 100755
> --- a/build_mesos
> +++ b/build_mesos
> @@ -313,9 +313,10 @@ function deb_ {
> --deb-recommends zookeeperd
> --deb-recommends zookeeper-bin
> -d 'java-runtime-headless'
> - -d libcurl3
> - -d libsvn1
> - -d libsasl2-modules
> + -d libcurl4-nss-dev
> + -d libsasl2-dev
> + -d libapr1-dev
> + -d libsvn-dev
>
> It does look like the tool can build RPMs.
>
> Kind regards,
> Radek Gruchalski
>
radek@gruchalski.com
> de.linkedin.com/in/radgruchalski/
>
> Confidentiality:
> This communication is intended for the above-named person and may be
> confidential and/or legally privileged.
> If it has come to you in error you must take no action based on it, nor must
> you copy or show it to anyone; please delete/destroy and inform the sender
> immediately.
>
> On Saturday, 19 September 2015 at 04:09, craig w wrote:
>
> Mesosphere provides packages, you can find more information here:
> https://mesosphere.com/downloads/
>
> As of right now, they don't seem to have a 0.24.0 package.
>
> On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks <br...@brianthicks.com> wrote:
>
> We've got some experimental packages at bintray.com/asteris/mantl-rpm,
> source is at github.com/asteris-llc/mesos-packaging. They can really use
> some testing if you wanted to give them a try. Configuration is a bit
> different than the Mesosphere packages, see the repo for details.
>
> On Sep 18, 2015 7:01 PM, "Zameer Manji" <zm...@apache.org> wrote:
>
> Hey,
>
> Does the Apache Mesos project provide OS packages for installation? I
> haven't been able to find any for the 0.24 release and I think having them
> would make installing Mesos a lot easier.
>
> --
> Zameer Manji
>
>
>
>
> --
>
> https://github.com/mindscratch
> https://www.google.com/+CraigWickesser
> https://twitter.com/mind_scratch
> https://twitter.com/craig_links
>
>
Re: Official RPMs
Posted by Rad Gruchalski <ra...@gruchalski.com>.
Should be rather easy to package it with this little tool from Mesosphere: https://github.com/mesosphere/mesos-deb-packaging. I’ve done it myself for ubuntu 12.04 and 14.04.
The only thing that needs to be changed are the dependencies, for ubuntu this was:
diff --git a/build_mesos b/build_mesos
index 81561bc..f756ef0 100755
--- a/build_mesos
+++ b/build_mesos
@@ -313,9 +313,10 @@ function deb_ {
--deb-recommends zookeeperd
--deb-recommends zookeeper-bin
-d 'java-runtime-headless'
- -d libcurl3
- -d libsvn1
- -d libsasl2-modules
+ -d libcurl4-nss-dev
+ -d libsasl2-dev
+ -d libapr1-dev
+ -d libsvn-dev
It does look like the tool can build RPMs.
Kind regards,
Radek Gruchalski
radek@gruchalski.com (mailto:radek@gruchalski.com)
(mailto:radek@gruchalski.com)
de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/)
Confidentiality:
This communication is intended for the above-named person and may be confidential and/or legally privileged.
If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately.
On Saturday, 19 September 2015 at 04:09, craig w wrote:
> Mesosphere provides packages, you can find more information here: https://mesosphere.com/downloads/
>
> As of right now, they don't seem to have a 0.24.0 package.
>
> On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks <brian@brianthicks.com (mailto:brian@brianthicks.com)> wrote:
> > We've got some experimental packages at bintray.com/asteris/mantl-rpm (http://bintray.com/asteris/mantl-rpm), source is at github.com/asteris-llc/mesos-packaging (http://github.com/asteris-llc/mesos-packaging). They can really use some testing if you wanted to give them a try. Configuration is a bit different than the Mesosphere packages, see the repo for details.
> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zmanji@apache.org (mailto:zmanji@apache.org)> wrote:
> > > Hey,
> > >
> > > Does the Apache Mesos project provide OS packages for installation? I haven't been able to find any for the 0.24 release and I think having them would make installing Mesos a lot easier.
> > >
> > > --
> > > Zameer Manji
>
>
>
> --
> https://github.com/mindscratch
> https://www.google.com/+CraigWickesser
> https://twitter.com/mind_scratch
> https://twitter.com/craig_links
Re: Official RPMs
Posted by craig w <co...@gmail.com>.
Mesosphere provides packages, you can find more information here:
https://mesosphere.com/downloads/
As of right now, they don't seem to have a 0.24.0 package.
On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks <br...@brianthicks.com> wrote:
> We've got some experimental packages at bintray.com/asteris/mantl-rpm,
> source is at github.com/asteris-llc/mesos-packaging. They can really use
> some testing if you wanted to give them a try. Configuration is a bit
> different than the Mesosphere packages, see the repo for details.
> On Sep 18, 2015 7:01 PM, "Zameer Manji" <zm...@apache.org> wrote:
>
>> Hey,
>>
>> Does the Apache Mesos project provide OS packages for installation? I
>> haven't been able to find any for the 0.24 release and I think having them
>> would make installing Mesos a lot easier.
>>
>> --
>> Zameer Manji
>>
>
--
https://github.com/mindscratch
https://www.google.com/+CraigWickesser
https://twitter.com/mind_scratch
https://twitter.com/craig_links
Re: Official RPMs
Posted by Brian Hicks <br...@brianthicks.com>.
We've got some experimental packages at bintray.com/asteris/mantl-rpm,
source is at github.com/asteris-llc/mesos-packaging. They can really use
some testing if you wanted to give them a try. Configuration is a bit
different than the Mesosphere packages, see the repo for details.
On Sep 18, 2015 7:01 PM, "Zameer Manji" <zm...@apache.org> wrote:
> Hey,
>
> Does the Apache Mesos project provide OS packages for installation? I
> haven't been able to find any for the 0.24 release and I think having them
> would make installing Mesos a lot easier.
>
> --
> Zameer Manji
>