Re: Compute event at Twitter HQ - 03/31

[Micheal Benedict Arul]

We won't be streaming live but are working to get the talks recorded.

On Wed, Mar 16, 2016 at 9:45 AM, haosdent  wrote:

> Would it have youtube live link?
>
> On Thu, Mar 17, 2016 at 12:38 AM, Ian Downes  wrote:
>
> > Hello everyone,
> >
> > I'd like to call attention to an event the Compute group at Twitter is
> > holding at the end of the month where there will be a few
> > Aurora/Mesos-related talks:
> >
> > 1. David Robinson, one of our SREs, will talk about how our small team
> > of SREs manages what is possibly the largest Mesos cluster in
> > existence.
> > 2. David McLaughlin, Aurora committer/PMC member, will talk about
> > Workflows, an internal tool we've built to orchestrate deployments
> > across Aurora clusters.
> > 3. David Hagar, Engineering Manager at TellApart, will talk about
> > running Aurora/Mesos in AWS.
> >
> > On top of that there will be lots of other great talks about how we
> > run the entirety of our compute infrastructure.
> >
> > The event is on the evening of March 31st at Twitter HQ in San
> > Francisco. I hope to see many of you there!
> >
> > https://www.eventbrite.com/e/compute-tickets-22811196904
> >
> > Thanks,
> >
> > Ian
> >
> > Note: This is nearly a straight copy of an email that Joshua sent out
> > to the Aurora mailing lists.
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Recent changes to MesosTest helpers

[Joseph Wu]

Hello Devs & Contributors,

We recently committed a refactor of the MesosTest suite and underlying
"Cluster" abstraction.  This affects almost every existing test and future
test, so here's a summary of what has changed and what you should be aware
of:

   - The purpose of the refactor is to make the entire test suite more
   resilient to flaky tests.  Before, every test that used the "
   MesosTest::StartMaster" and "MesosTest::StartSlave" helpers also needed
   to have "Shutdown()" at the end of the test.  If the test failed an
   assertion or expectation, it would exit before "Shutdown()" and would
   very likely segfault, or hit a "__cxa_pure_virtual__" and exit with a
   cryptic stack trace.
   - The signatures of "MesosTest::StartMaster" and "MesosTest::StartSlave"
   have changed.  Both test helpers now return a "
   Try" Instead of a "Try>".
   To way to access the "PID" was changed from ".get()" to ".get()->pid".
   - "Shutdown()" has been removed from MesosTest.  It is no longer
   necessary.
   - The MasterDetector has been exposed at the top-level for all slaves.
   This slave dependency was originally populated by the "Cluster" abstraction
   (which held both Masters and Slaves).  In most cases, it will be sufficient
   to create the detector like:

   Owned detector = master->createDetector();
   - If you need to restart the master in the middle of a test, just reset
   the underlying "Owned" pointer.  i.e:

   master->reset();
   master = StartMaster();

   Note: We can't assign master before resetting the pointer.  This is a
   limitation related to supporting multiple masters in tests, which is
   currently not possible.
   - If you need to restart the slave in the middle of a test, there are
   several ways:
  - To clean up any containers associated with that slave:
  slave = StartSlave(...);

  Or:
  slave.reset();
  slave = StartSlave(...);
  - To stop a slave without container cleanup (equivalent to the
  original "MesosTest::Stop()"), use:
  slave->terminate();

  Or:
  slave->shutdown();

  These two methods emulate turning off the slave, but have slightly
  different semantics.  "Terminate" generally emulates a crash.  "Shutdown"
  emulates a graceful exit.

If you have any further questions, feel free to ask.  There are still quite
a few improvements to make, but those will likely be less disruptive.

~Joseph

Re: Contributor request

[Artem Harutyunyan]

Hi Tomek,

Sorry for the delay. Just tried to add you but couldn't find you. Which
email did you use (jani...@gmail.com does appear to be in the list of
registered users).

Artem.

On Fri, Mar 11, 2016 at 6:48 AM, Tomek Janiszewski 
wrote:

> Please add me as contributor in the Mesos JIRA project. My Apache JIRA's
> username: janisz
>
> Thanks!
>

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Kevin Klues]

On Tue, Mar 15, 2016 at 6:10 PM, Gilbert Song  wrote:
> @Kevin, thanks for writing it down in detail. It sounds good that a more
> concrete
> schema is designed to generally solve similar auth problem.
>
> Just have two potential issues inlined below:
>
> On Tue, Mar 15, 2016 at 5:39 PM, Kevin Klues  wrote:
>>
>> Yeah, option 2.
>>
>> I was trying to expand on Avinash's suggestion and make it a bit more
>> concrete in terms of what was being proposed. Needing to reload the
>> agent just to update the list of credentials it accepts seems
>> undesirable though.
>>
>> Maybe we could have a way to start the agent with a default config (by
>> iterating on the schema from my previous email), but allow newly
>> launched frameworks to somehow update the config on the fly through a
>
>
> Will it be too expensive to update all agents every time a new framework
> joins (handling consensus problem as well)?

Not sure, I haven't though about it in depth.  What I was picturing
though was something exactly like what you describe for how the docker
containerizer currently solves this problem, except instead of using
docker/config.json directly, use a new credentials.json file which
follows a schema similar to what I proposed above.

>>
>> file in their sandbox that follows the same schema.
>
>
> Does that mean the file in sandbox should be exposed to each other?
>
>>
>> On Tue, Mar 15, 2016 at 5:25 PM, Jie Yu  wrote:
>> > Kevin, are you suggesting option 2 and having a config file like the
>> > above?
>> >
>> > I think another downside of a per-agent config is that it's hard to
>> > maintain this. What if a new framework joins and has a new credential
>> > for
>> > the docker images. Do we need to restart the agent to reload the config?
>> >
>> > - Jie
>> >
>> > On Tue, Mar 15, 2016 at 1:25 PM, Kevin Klues  wrote:
>> >
>> >> Can we be a bit more concrete here and try to build up a schema for
>> >> this.
>> >> Maybe something like:
>> >>
>> >> {
>> >>   [
>> >> {
>> >>   "service" : "docker",
>> >>   "registries" :
>> >>   [
>> >> "uri" : "",
>> >> "default_credentials" :
>> >> {
>> >>   "type" : "",
>> >>   "credential" :
>> >>   {
>> >>   // Custom based on type...
>> >>   }
>> >> },
>> >> "image_credentials" :
>> >> [
>> >>   {
>> >> "image_name" : "",
>> >> "type" : "",
>> >> "credential" :
>> >> {
>> >>   // Custom based on type...
>> >> },
>> >>   },
>> >>   ...
>> >> ],
>> >> ...
>> >>   ]
>> >>   ...
>> >> },
>> >> ...
>> >>   ]
>> >> }
>> >>
>> >>
>> >> On Tue, Mar 15, 2016 at 12:57 PM, Jie Yu  wrote:
>> >> >>
>> >> >> Yeah I was thinking having the JSON as a dictionary with keys being
>> >> >> the
>> >> >> registry URI (appc/docker) and the values being credentials (which
>> >> >> will
>> >> be
>> >> >> a dictionary as well I guess).
>> >> >
>> >> >
>> >> > Using registry URI as the key is problematic. Think about the public
>> >> docker
>> >> > hub. Different frameworks might want to use different credentials to
>> >> access
>> >> > their docker images.
>> >> >
>> >> > - Jie
>> >> >
>> >> > On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan <
>> >> avin...@mesosphere.io
>> >> >
>> >> > wrote:
>> >> >
>> >> >> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone 
>> >> wrote:
>> >> >>
>> >> >> > moved core@ to *bcc*
>> >> >> >
>> >> >> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
>> >> >> avin...@mesosphere.io
>> >> >> > > wrote:
>> >> >> >
>> >> >> >> Why not follow option 2, but instead of passing the agent
>> >> credentials,
>> >> >> >> pass a location to the flag where credentials for the registry
>> >> >> >> can be
>> >> >> found
>> >> >> >> (in JSON)? The frameworks can set credentials (maybe registry
>> >> >> >> name or
>> >> >> URL
>> >> >> >> to the registry), and the credentials can be learnt from the JSON
>> >> >> config.
>> >> >> >>
>> >> >> >
>> >> >> > What if we need credentials for multiple-registries? Have a JSON
>> >> >> > with
>> >> one
>> >> >> > credential per registry I guess? But if possible, I would love to
>> >> solve
>> >> >> > this more generally as possible; as Gilbert mentioned, this is not
>> >> >> > a
>> >> >> > problem just for Docker images but any URIs that need AuthN.
>> >> >> >
>> >> >> Yeah I was thinking having the JSON as a dictionary with keys being
>> >> >> the
>> >> >> registry URI (appc/docker) and the values being credentials (which
>> >> >> will
>> >> be
>> >> >> a dictionary as well I guess).
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Avinash Sridharan, Mesosphere
>> >> >> +1 (323) 702 5245
>> >> >>
>> >>
>> >>
>> >>
>> >> --
>> >> ~Kevin
>> >>
>>
>>
>>
>> --
>> ~Kevin
>
>



-- 
~Kevin

Upgrade to clang-format-3.8

[Yong Tang]

Hi All


This email is to announce that the default configuration and the recommended 
version of the clang-format is being upgraded to 3.8 (from 3.5) in mesos.


In clang-format-3.8, the newly introduced option "AlignAfterOpenBracket: 
AlwaysBreak" closes the largest gap between ClangFormat and the style guide in 
mesos. It avoids  "jaggedness" in function calls and is worth migrating for.


Along with the changes in clang-format configuration (support/clang-format), 
the documentation (docs/clang-format.md) is also going to be updated to reflect 
changes in version and the recommended installation process.


More details about this upgrade could be found in MESOS-4906 
(https://issues.apache.org/jira/browse/MESOS-4906). By the way, thanks Michael 
for the help on this issue.


Thanks


Yong


  

Re: Backport r/44230 to 0.27 branch

[Cong Wang]

On Tue, Mar 15, 2016 at 5:17 PM, Jie Yu  wrote:
> commit 5278e5cc50544ed7af28b15a1acd2b2e96a15a47
> Author: Jojy Varghese 
> Date:   Tue Mar 15 17:12:01 2016 -0700
>
> Added support for FTS_SLNONE in rmdir.
>
> Review: https://reviews.apache.org/r/44874/
>
> commit 5c4b348c8090ce61804b7701e3b0705ced975a7e
> Author: Jojy Varghese 
> Date:   Tue Mar 15 17:11:54 2016 -0700
>
> Added test for rmdir with device file.
>
> Existing tests did not cover the case of removing directories with
> special files like device files.
>
> Review: https://reviews.apache.org/r/44873/
>

Will they be backported as well?

Re: [RESULT][VOTE] Release Apache Mesos 0.28.0 (rc2)

[Jake Farrell]

I've been maintaining a deb/rpm set for Mesos and for Aurora and Thrift we
have been using the infra supported Bintray to make it available to the
community via http://www.apache.org/dist/${project}/${os}

If there is interest I'd be happy to put some time into bringing my patches
into reviews and helping setup jenkins tests, etc.

-Jake






On Thu, Mar 17, 2016 at 1:41 PM, Vinod Kone  wrote:

> The project itself doesn't officially release rpms/debs, but the community
> members do.  For example, Mesosphere is planning to release rpms/debs
> shortly.
>
> On Thu, Mar 17, 2016 at 10:38 AM, craig w  wrote:
>
> > Great news. Do the rpm's get automatically built and released or will
> they
> > come later this week?
> >
> > On Thu, Mar 17, 2016 at 1:28 PM, Vinod Kone 
> wrote:
> >
> >> Hi all,
> >>
> >>
> >> The vote for Mesos 0.28.0 (rc2) has passed with the
> >>
> >> following votes.
> >>
> >>
> >> +1 (Binding)
> >>
> >> --
> >>
> >> Vinod Kone
> >>
> >> Michael Park
> >>
> >> Kapil Arya
> >>
> >>
> >> +1 (Non-binding)
> >>
> >> --
> >>
> >> Greg Mann
> >>
> >> Daniel Osborne
> >>
> >> Jorg Schad
> >>
> >> Zhitao Li
> >>
> >>
> >> There were no 0 or -1 votes.
> >>
> >>
> >> Please find the release at:
> >>
> >> https://dist.apache.org/repos/dist/release/mesos/0.28.0
> >>
> >>
> >> It is recommended to use a mirror to download the release:
> >>
> >> http://www.apache.org/dyn/closer.cgi
> >>
> >>
> >> The CHANGELOG for the release is available at:
> >>
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.0
> >>
> >>
> >> The mesos-0.28.0.jar has been released to:
> >>
> >> https://repository.apache.org
> >>
> >>
> >> The website (http://mesos.apache.org) will be updated shortly to
> reflect
> >> this release.
> >>
> >>
> >> Thanks,
> >>
> >
> >
> >
> > --
> >
> > https://github.com/mindscratch
> > https://www.google.com/+CraigWickesser
> > https://twitter.com/mind_scratch
> > https://twitter.com/craig_links
> >
> >
>

Re: Looking for a shepherd for MESOS-4878

[Shuai Lin]

Ping.


On Thu, Mar 10, 2016 at 3:55 PM, Shuai Lin  wrote:

> The bug is: if a framework launches a task with mesos containerizer and a
> docker image, and the slave failed to fetch the image for any reason, the
> task state would be stuck in STAGING forever.
>
> https://issues.apache.org/jira/browse/MESOS-4878
>
> @jieyu can you shepherd it? Thanks!
>

Re: Backport r/44230 to 0.27 branch

[Cong Wang]

On Wed, Mar 16, 2016 at 12:18 PM, Jie Yu  wrote:
>>
>> like many other review requests are burned or take
>
> 6+ months to merge
>
>
> Have you reached out to any shepherd for that ticket/review?
>

This is exactly where it doesn't work.

You, as qualified as a committer, need to do _your_ work, you have
to prioritize all the review requests you get, take care of all of them.
Why? Because you have them all, you should know which of them
are more important than others therefore should be reviewed earlier
than later. You can't wait for others to tell you, because you are a
committer.

Priorities are based on _your_ understanding of the code, rather than
who you know better or who pings you more than others.

You have 20+ committers, you should be able to handle all of these
review requests, but apparently some of them are not working at all
so some of them are overloaded. This is a problem you need to fix,
rather than being ping'ed.

Vote on #MesosCon proposals, deadline Friday March 25

[Kiersten Gaffney]

Please take a few minutes the next few days and review what members of the
community have submitted!

Voting forms close Friday, March 25, 2016, 11:55 PST

A total of 154 proposals were submitted in time for #MesosCon review, up
significantly from 63 submitted for last year’s conference. Similar to last
year, the MesosCon program committee is opening these proposals up for
community review/feedback to better-inform our decisions about what should
be included in the program.

In order to make it easier to review a subset of the proposals, we’ve
segmented them based upon two loose themes: Developer and Users.

Developers: http://bit.ly/1RpZPvj

Talks on how frameworks can be used, developed, and integrate with Mesos.

Users: http://bit.ly/1Mspaxp

A combination of talks that are use cases (how company x uses Mesos), and
operations-focused (how we deploy x, use Docker, etc).

The forms above also include an opportunity to indicate which sessions you
didn't see proposed but would like to attend.

Thanks in advance for your participation!

Kiersten, Dave, and David (Program Committee)

Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)

[Kevin Klues]

I respectfully disagree.

The whole purpose of tags is to mark permanent things like releases,
whereas branches are designed as temporary lines of development that
come and go (and grow and shrink) dynamically all the time.

On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu  wrote:
> I like the idea of using branches to manage releases.
>
> We can use that to manage point releases and backports as well.
>
> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in that
> branch. Once the RC is accepted, the head of that branch will become the
> release.
>
> Then, we immediate fork that branch and create 0.29.1 branch.
>
> When a new bug fix is committed on the trunk, the committer will decide
> whether it'll affect the old releases (a bounded number, we can decide that
> later). If it does, the committer of that patch should also cherry-pick
> that patch to the point releases (e.g., 0.29.1 in this case). We can do a
> timely based point releases.
>
> - Jie
>
> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang  wrote:
>
>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu  wrote:
>> > Cong Wang,
>> >
>> > The tags are sync'd.  See: https://github.com/apache/mesos/releases
>> >
>> > You might not have done: git pull --tags
>>
>>
>> Yeah, I figured it out by myself too. This is why I hate tags personally,
>> branches are better since they are fetched without additional parameters.
>>
>> Any reason why Mesos maintainers picked tags over branches to manage
>> releases? Just curious...
>>



-- 
~Kevin

Re: Unzip should work in non interactive mode

[Tomek Janiszewski]

Patch is ready https://reviews.apache.org/r/45057/diff/1/

pt., 18.03.2016 o 16:43 użytkownik Jie Yu  napisał:

> I can shepherd it. Do you have a patch ready?
>
> - Jie
>
> On Fri, Mar 18, 2016 at 3:13 AM, Tomek Janiszewski 
> wrote:
>
> > Hi
> >
> > Consider situation when deployed zip file is malformed and contains
> > duplicated files .
> > When fetcher downloads malformed zip file, that contains duplicated files
> > (e.g., dist zips generated by gradle) and try to uncompress it,
> deployment
> > hang in staged phase because unzip prompt if file should be replaced.
> unzip
> > should overwrite this file or break with error. I created issue for this
> > MESOS-4885
> > It looks like easy fix, anyone want to shepherd it?
> >
> > Best
> > Tomek
> >
>

Re: Backport r/44230 to 0.27 branch

[Jie Yu]

Zhitao, that's a fair point. Can you add an agenda item to the next
community sync to discuss this? Thanks!

- Jie

On Wed, Mar 16, 2016 at 12:16 PM, Zhitao Li  wrote:

> Maybe we can try to draft a formal guideline about when/how something
> should be back ported, and making sure interested parties in the community
> have chance to get their voices heard?
>
> I'm also interested in knowing how much work it generates when they cut
> with back port releases, and how the community could help.
>
> On Wed, Mar 16, 2016 at 12:11 PM, Cong Wang 
> wrote:
>
> > On Wed, Mar 16, 2016 at 11:58 AM, Jie Yu  wrote:
> > >
> > > Currently, it's based on request. We definitely need to improve this
> > part.
> >
> >
> > It simply doesn't work, like many other review requests are burned or
> take
> > 6+ months to merge. I am sure you need to improve that too, but after
> > watching Mesos community for months, I don't see any improvement yet.
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: [VOTE] Release Apache Mesos 0.28.0 (rc2)

[Michael Park]

+1 (binding)

Internal CI results with the corresponding JIRA tickets for the failed
tests:

CentOS 6 (non-SSL):
CentOS 6 (SSL):
  - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
(MESOS-4047 )

CentOS 7 (non-SSL):
  - ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand
(MESOS-4810)

CentOS 7 (SSL):
  - LinuxFilesystemIsolatorTest.ROOT_MultipleContainers (Fixed in master)
(MESOS-4912 )
  - ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand
(MESOS-4810 )

Debian 8 (non-SSL):
  - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
(MESOS-4047 )

Debian 8 (SSL):
  - NsTest.ROOT_setns
(MESOS-3000 )
  - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
(MESOS-4047 )

Ubuntu 12 (non-SSL):
  - HealthCheckTest.ROOT_DOCKER_DockerHealthStatusChange
Failed with MESOS-2017


Ubuntu 12 (SSL): Success!
Ubuntu 14 (non-SSL): Success!
Ubuntu 14 (SSL): Success!
Ubuntu 15 (non-SSL): Success!
Ubuntu 15 (SSL): Success!

On 11 March 2016 at 15:46, Vinod Kone  wrote:

> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 0.28.0.
>
>
> 0.28.0 includes the following:
>
>
> 
>
> Release Notes - Mesos - Version 0.28.0
>
> 
>
> This release contains the following new features:
>
>   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
> subsystem in
>
> Linux. The cgroups/net_cls isolator allows operators to provide network
>
> performance isolation and network segmentation for containers within a
> Mesos
>
> cluster. To enable the cgroups/net_cls isolator, append
> `cgroups/net_cls` to
>
> the `--isolation` flag when starting the slave. Please refer to
>
> docs/mesos-containerizer.md for more details.
>
>
>   * [MESOS-4687] - The implementation of scalar resource values (e.g., "2.5
>
> CPUs") has changed. Mesos now reliably supports resources with up to
> three
>
> decimal digits of precision (e.g., "2.501 CPUs"); resources with more
> than
>
> three decimal digits of precision will be rounded. Internally, resource
> math
>
> is now done using a fixed-point format that supports three decimal
> digits of
>
> precision, and then converted to/from floating point for input and
> output,
>
> respectively. Frameworks that do their own resource math and manipulate
>
> fractional resources may observe differences in roundoff error and
> numerical
>
> precision.
>
>
>   * [MESOS-4479] - Reserved resources can now optionally include "labels".
>
> Labels are a set of key-value pairs that can be used to associate
> metadata
>
> with a reserved resource. For example, frameworks can use this feature
> to
>
> distinguish between two reservations for the same role at the same
> agent
>
> that are intended for different purposes.
>
>
>   * [MESOS-2840] - **Experimental** support for container images in Mesos
>
> containerizer (a.k.a. Unified Containerizer). This allows frameworks to
>
> launch Docker/Appc containers using Mesos containerizer without relying
> on
>
> docker daemon (engine) or rkt. The isolation of the containers is done
> using
>
> isolators. Please refer to docs/container-image.md for currently
> supported
>
> features and limitations.
>
>
>   * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API. This
>
> allows executors to send HTTP requests to the /api/v1/executor agent
>
> endpoint without the need for an executor driver. Please refer to
>
> docs/executor-http-api.md for more details.
>
>
>   * [MESOS-4370] Added support for service discovery of Docker containers
> that
>
> use Docker Remote API v1.21.
>
>
> Additional API Changes:
>
>   * [MESOS-4066] - Agent should not return partial state when a request is
> made to /state endpoint during recovery.
>
>   * [MESOS-4547] - Introduce TASK_KILLING state.
>
>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> Scheduler API.
>
>   * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
> ACLs to `roles`.
>
>   * [MESOS-3583] - Add stream IDs for HTTP schedulers.
>
>   * [MESOS-4427] - Ensure ip_address in state.json (from NetworkInfo) is
> valid
>
>
> The CHANGELOG for the release is available at:
>
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.0-rc2
>
>
> 
>
>
> The candidate for Mesos 0.28.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0

Re: shepherd for MESOS-4735, and proposal

[Vinod Kone]

I'll be happy to shepherd.

On Wed, Mar 16, 2016 at 10:58 AM, Michael Browning 
wrote:

> Bump. This should be a pretty small change, any takers?
>
> On Mon, Mar 14, 2016 at 6:39 PM, Shuai Lin  wrote:
> > +1 for the new `filename` field for the URI. It would also be useful for
> > implementing base64:// or data:// scheme uri fetcher, so that the
> scheduler
> > can pass arbitary file blobs to the task directly without resorting to a
> > custom executor. (https://issues.apache.org/jira/browse/MESOS-4524)
> >
> > On Tue, Mar 15, 2016 at 8:18 AM, Michael Browning <
> invitapri...@gmail.com>
> > wrote:
> >
> >> Hi all,
> >>
> >> Looking for a shepherd for this task:
> >>
> >> https://issues.apache.org/jira/browse/MESOS-4735
> >>
> >> As Zhitao mentioned in the ticket, the frequently-encountered
> >> inability to extract archives from webhdfs-fetched files due to the
> >> inclusion of things like query params in the resulting filename is
> >> kind of a blocker for us, and there seems to be interest from others
> >> too, q.v.:
> >>
> >> https://issues.apache.org/jira/browse/MESOS-4779
> >>
> >> My proposed fix is basically that proposed by Erik in the ticket: add
> >> an optional string `filename` field to the CommandInfo.URI protobuf --
> >> when omitted, the old behavior will be retained, but when specified
> >> the file will be saved to the sandbox with that filename. Any feedback
> >> would be appreciated.
> >>
> >> Thanks,
> >> Michael
> >>
>

Re: Upgrade to clang-format-3.8

[Michael Park]

Hi James,

Someone would need to propose to auto-format everything with clang-format
and convince the community
that while clang-format will never be perfect, it generates a systematic,
sane and just as readable codebase.
If we can reach consensus on that, we could add it as a commit hook and no
one will worry about formatting.

I dreamed of the world described above, but at least at the time
clang-format was still learning about some
of the C++11 constructs (especially around lambdas), so it seemed a bit too
far fetched.

My goal with clang-format currently is for people to have it integrated in
their editors to help them get 80, 90%
of the way there with single key-stroke, then follow-up with necessary
minor edits. We've been converging from
both sides to get that percentage higher (new features in clang-format +
modifying our style), and we'll continue
to make such efforts where it makes sense.

MPark

On 18 March 2016 at 12:45, James Peach  wrote:

>
> > On Mar 17, 2016, at 10:41 AM, Yong Tang 
> wrote:
> >
> > Hi All
> >
> >
> > This email is to announce that the default configuration and the
> recommended version of the clang-format is being upgraded to 3.8 (from 3.5)
> in mesos.
> >
> >
> > In clang-format-3.8, the newly introduced option "AlignAfterOpenBracket:
> AlwaysBreak" closes the largest gap between ClangFormat and the style guide
> in mesos. It avoids  "jaggedness" in function calls and is worth migrating
> for.
> >
> >
> > Along with the changes in clang-format configuration
> (support/clang-format), the documentation (docs/clang-format.md) is also
> going to be updated to reflect changes in version and the recommended
> installation process.
> >
> >
> > More details about this upgrade could be found in MESOS-4906 (
> https://issues.apache.org/jira/browse/MESOS-4906). By the way, thanks
> Michael for the help on this issue.
>
> This sounds really promising. Is the plan to auto-format everything with
> clang-format?

Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)

[Erik Weathers]

BTW, if the tag is created against a commit that *doesn't* become
"unreachable" from HEAD [1], then `git pull` is sufficient to also pull
down the tags.

The only time I've needed to do `git fetch --tags` is when the tagged
commit SHA gets merged away.  So presumably the process being followed by
the core committers / releasers is resulting in these "unreachable" tags.
Not sure if that is preventable though.

- Erik

[1] http://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/

>From the git manual (“git help fetch”): [1]

-t, –tags Most of the tags are fetched automatically as branch heads are
downloaded, but tags that do not point at objects reachable from the branch
heads that are being tracked will not be fetched by this mechanism. This
flag lets all tags and their associated objects be downloaded. The default
behavior for a remote may be specified with the remote..tagopt
setting. See git-config(1).



On Fri, Mar 18, 2016 at 6:22 PM, Michael Browning 
wrote:

> I agree with Kevin -- tags are immutable, so they're naturally suited
> for labeling releases, which ought to be immutable too.
>
> On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues  wrote:
> > I respectfully disagree.
> >
> > The whole purpose of tags is to mark permanent things like releases,
> > whereas branches are designed as temporary lines of development that
> > come and go (and grow and shrink) dynamically all the time.
> >
> > On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu  wrote:
> >> I like the idea of using branches to manage releases.
> >>
> >> We can use that to manage point releases and backports as well.
> >>
> >> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in
> that
> >> branch. Once the RC is accepted, the head of that branch will become the
> >> release.
> >>
> >> Then, we immediate fork that branch and create 0.29.1 branch.
> >>
> >> When a new bug fix is committed on the trunk, the committer will decide
> >> whether it'll affect the old releases (a bounded number, we can decide
> that
> >> later). If it does, the committer of that patch should also cherry-pick
> >> that patch to the point releases (e.g., 0.29.1 in this case). We can do
> a
> >> timely based point releases.
> >>
> >> - Jie
> >>
> >> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang 
> wrote:
> >>
> >>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu 
> wrote:
> >>> > Cong Wang,
> >>> >
> >>> > The tags are sync'd.  See: https://github.com/apache/mesos/releases
> >>> >
> >>> > You might not have done: git pull --tags
> >>>
> >>>
> >>> Yeah, I figured it out by myself too. This is why I hate tags
> personally,
> >>> branches are better since they are fetched without additional
> parameters.
> >>>
> >>> Any reason why Mesos maintainers picked tags over branches to manage
> >>> releases? Just curious...
> >>>
> >
> >
> >
> > --
> > ~Kevin
>

Re: Upgrade to clang-format-3.8

[Cong Wang]

On Fri, Mar 18, 2016 at 10:19 AM, Yong Tang
 wrote:
> Hi James
>
> My understanding is that there are two epic associated. One is the 
> clang-format integration that formatting whitespaces, multiple lines, etc. 
> Another is the clang-tidy integration that helps handle class/function naming 
> conventions etc..

This is needed sooner than later. I once opened
https://issues.apache.org/jira/browse/MESOS-3523
when people keep wasting time on whitespaces, new lines etc.
on review board.

It needs to be integrated with git hooks too like cpplint,
so people don't need to worry/argue/review coding styles.

It is not that coding styles are not important, quite oppositely,
it is too important that we can't rely on humans to review them. :)

I can't wait for this.

Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)

[Klaus Ma]

@team, are we going to provide LTS version? If so, we definitely need a
branch to back merge issues; if not, we release a new version monthly (??),
we'd suggest user to upgrade to next release.


Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
Platform OpenSource Technology, STG, IBM GCG
+86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me

On Sat, Mar 19, 2016 at 7:59 AM, Kevin Klues  wrote:

> I respectfully disagree.
>
> The whole purpose of tags is to mark permanent things like releases,
> whereas branches are designed as temporary lines of development that
> come and go (and grow and shrink) dynamically all the time.
>
> On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu  wrote:
> > I like the idea of using branches to manage releases.
> >
> > We can use that to manage point releases and backports as well.
> >
> > Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in
> that
> > branch. Once the RC is accepted, the head of that branch will become the
> > release.
> >
> > Then, we immediate fork that branch and create 0.29.1 branch.
> >
> > When a new bug fix is committed on the trunk, the committer will decide
> > whether it'll affect the old releases (a bounded number, we can decide
> that
> > later). If it does, the committer of that patch should also cherry-pick
> > that patch to the point releases (e.g., 0.29.1 in this case). We can do a
> > timely based point releases.
> >
> > - Jie
> >
> > On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang 
> wrote:
> >
> >> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu 
> wrote:
> >> > Cong Wang,
> >> >
> >> > The tags are sync'd.  See: https://github.com/apache/mesos/releases
> >> >
> >> > You might not have done: git pull --tags
> >>
> >>
> >> Yeah, I figured it out by myself too. This is why I hate tags
> personally,
> >> branches are better since they are fetched without additional
> parameters.
> >>
> >> Any reason why Mesos maintainers picked tags over branches to manage
> >> releases? Just curious...
> >>
>
>
>
> --
> ~Kevin
>