mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zameer Manji <zma...@apache.org>
Subject Re: Official RPMs
Date Tue, 22 Sep 2015 18:05:59 GMT
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 <marco@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 <ccaat@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
>>> <mailto:carlos@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 <mailto:radek@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 <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
>>>      >
>>>      >
>>>
>>> --
>>> Zameer Manji
>>>
>>>

Mime
View raw message