[jira] [Assigned] (MESOS-2493) google glog link is incorrect
[ https://issues.apache.org/jira/browse/MESOS-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-2493: --- Assignee: haosdent > google glog link is incorrect > - > > Key: MESOS-2493 > URL: https://issues.apache.org/jira/browse/MESOS-2493 > Project: Mesos > Issue Type: Bug > Components: documentation >Reporter: haosdent >Assignee: haosdent >Priority: Minor > > In this page: > http://mesos.apache.org/documentation/latest/logging-and-debugging/. The link > of "Google Logging library" is incorrect. > "http://mesos.apache.org/documentation/latest/http://code.google.com/p/google-glog"; > ==> "http://code.google.com/p/google-glog"; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2493) google glog link is incorrect
[ https://issues.apache.org/jira/browse/MESOS-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621797#comment-14621797 ] haosdent commented on MESOS-2493: - Seems it is because of http://code.google.com/p/google-glog/ not exists so the generate tool failed to convert this. > google glog link is incorrect > - > > Key: MESOS-2493 > URL: https://issues.apache.org/jira/browse/MESOS-2493 > Project: Mesos > Issue Type: Bug > Components: documentation >Reporter: haosdent >Priority: Minor > > In this page: > http://mesos.apache.org/documentation/latest/logging-and-debugging/. The link > of "Google Logging library" is incorrect. > "http://mesos.apache.org/documentation/latest/http://code.google.com/p/google-glog"; > ==> "http://code.google.com/p/google-glog"; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2257) Set Mesos specific content type with version for HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621610#comment-14621610
]
haosdent commented on MESOS-2257:
-
Add X-Mesos-Media-Type to response header like Github Api would be better?
> Set Mesos specific content type with version for HTTP endpoints
> ---
>
> Key: MESOS-2257
> URL: https://issues.apache.org/jira/browse/MESOS-2257
> Project: Mesos
> Issue Type: Improvement
>Reporter: Sunil Shah
>Priority: Minor
> Labels: mesosphere
>
> As a consumer of the Mesos HTTP API, it is necessary for us to determine the
> current version of Mesos so that we can parse the JSON documents returned
> correctly (since they change from version to version).
> Currently we're doing this by fetching state.json, parsing it and pulling out
> the version field. A more idiomatic way to do this would be to filter on the
> content-type in the header itself.
> To give a more concrete example, currently the JSON documents returned by the
> HTTP API return the following headers:
> {code}
> HTTP/1.1 200 OK
> Date: Fri, 23 Jan 2015 21:31:37 GMT
> Content-Length: 9352
> Content-Type: application/json
> {code}
> Something like the following (e.g. for master/state.json) would be easy to
> switch upon:
> {code}
> HTTP/1.1 200 OK
> Date: Fri, 23 Jan 2015 21:31:37 GMT
> Content-Length: 9352
> Content-Type: application/vnd.mesos.master.state.v0.20.1+json; charset=utf-8
> {code}
> The vnd prefix is typically used for vendor specific file types (see:
> http://en.wikipedia.org/wiki/Internet_media_type#Prefix_vnd). Charset=utf-8
> is required for JSON documents and is currently being omitted.
> This content-type would change for each document type, for example:
> {code}
> application/vnd.mesos.master.state.v0.20.1+json; charset=utf-8
> application/vnd.mesos.master.stats.v0.20.1+json; charset=utf-8
> application/vnd.mesos.slave.state.v0.20.1+json; charset=utf-8
> application/vnd.mesos.slave.stats.v0.20.1+json; charset=utf-8
> {code}
> Alternatively, the version could be appended as an extra field:
> {code}
> application/vnd.mesos.master.state+json; charset=utf-8; version=v0.20.1
> application/vnd.mesos.master.stats+json; charset=utf-8; version=v0.20.1
> application/vnd.mesos.slave.state+json; charset=utf-8; version=v0.20.1
> application/vnd.mesos.slave.stats+json; charset=utf-8; version=v0.20.1
> {code}
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3024) HTTP endpoint authN is enabled merely by specifying --credentials
[ https://issues.apache.org/jira/browse/MESOS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621487#comment-14621487 ] Till Toenshoff commented on MESOS-3024: --- +1 for undesired coupling of master provided credentials with authentication activation. Let's keep in mind that e.g. ticket based authentication mechanisms do not require credentials. +1 for getting rid of the authentication requirement activation via the "authenticate" and "authenticate_slaves" flags and instead using the ACLs. > HTTP endpoint authN is enabled merely by specifying --credentials > - > > Key: MESOS-3024 > URL: https://issues.apache.org/jira/browse/MESOS-3024 > Project: Mesos > Issue Type: Bug > Components: master, security >Reporter: Adam B > Labels: authentication, http, mesosphere > > If I set `--credentials` on the master, framework and slave authentication > are allowed, but not required. On the other hand, http authentication is now > required for authenticated endpoints (currently only `/shutdown`). That means > that I cannot enable framework or slave authentication without also enabling > http endpoint authentication. This is undesirable. > Framework and slave authentication have separate flags (`--authenticate` and > `--authenticate_slaves`) to require authentication for each. It would be > great if there was also such a flag for framework authentication. Or maybe we > get rid of these flags altogether and rely on ACLs to determine which > unauthenticated principals are even allowed to authenticate for each > endpoint/action. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2910) Add an Event message handler to scheduler driver
[ https://issues.apache.org/jira/browse/MESOS-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-2910: --- Sprint: Twitter Mesos Q2 Sprint 6, Twitter Mesos Q3 Sprint 1 (was: Twitter Mesos Q2 Sprint 6) > Add an Event message handler to scheduler driver > > > Key: MESOS-2910 > URL: https://issues.apache.org/jira/browse/MESOS-2910 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Benjamin Mahler > > Adding this handler lets master send Event messages to the driver. > See MESOS-2909 for additional context. > This ticket only tracks the installation of the handler and maybe handling of > a single event for testing. Additional events handling will be captured in a > different ticket(s). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-898) Introduce CMake as an alternative build system.
[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621456#comment-14621456 ] Vinod Kone commented on MESOS-898: -- Any updates on this [~hausdorff]? > Introduce CMake as an alternative build system. > --- > > Key: MESOS-898 > URL: https://issues.apache.org/jira/browse/MESOS-898 > Project: Mesos > Issue Type: Epic > Components: build >Reporter: Timothy St. Clair >Assignee: Alex Clemmer > Labels: build > > This is a rather substantial undertaking, so I would want upstream > debate+buy-in prior to full commitment. The basic premise is: upstream > rebundles several of its dependencies in part to tightly control its stack. > This is not out of the norm, but in order to be picked up by distribution > channels it needs to built against system dependencies, and rebundling is > strictly forbidden. Given that the mesos primary target platform are > data-center distributions such as RHEL/CENTOS/SL it makes sense to still have > bundling support for those who do not have dependencies in their channels > "yet". This is where cmake can be win with it's uber macros > (http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:ExternalProject). > I do not know of any equivalent in the autotools world, other then to brew > your own solution. I've done this type of work in the past, and completely > transformed condor and would leverage a lot of the work that was done there. > I currently have a tracking branch where I've started this work, but before I > go off into the woods, it makes sense to have a debate in public. > The primary benefits are: > 1. Enable downstream channels to easily distro without carrying a large patch > sets. > 2. Still support existing "non-proper" distribution methods. > 3. Harden / future proof dependent interfaces. > Side Benefits: > Audit current build mechanics. > - Presently the language specific binding are not installed. (.py & .jar) > - make -jX currently fails > - optionally look in arm support. > Costs: > 1. Time > 2. Potential temporary destabilization > 3. Infrastructure around build+test may need to change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1841) Mesos components should expose their version on an endpoint.
[
https://issues.apache.org/jira/browse/MESOS-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-1841:
---
Description:
The libraries (used by scheduler and executor) should expose their version on
an endpoint.
{noformat:title=stats exposed by the scheduler driver}
# netstat -dnatp | grep LISTEN | grep java
tcp0 0 0.0.0.0:48747 0.0.0.0:*
LISTEN 1699/java
tcp0 0 :::8081 :::*
LISTEN 1699/java
# curl -s http://localhost:48747/metrics/snapshot | python2.7 -m json.tool
{
"scheduler/event_queue_messages": 0,
"system/cpus_total": 24,
"system/load_15min": 0.18,
"system/load_1min": 0.29,
"system/load_5min": 0.2,
"system/mem_free_bytes": 7850483712,
"system/mem_total_bytes": 33534873600
}
{noformat}
Likewise, for the master and slave, a lightweight endpoint is desired, see
MESOS-2644 as well.
was:
The libraries (used by scheduler and executor) should expose their version on
an endpoint.
{noformat:title=stats exposed by the scheduler driver}
# netstat -dnatp | grep LISTEN | grep java
tcp0 0 0.0.0.0:48747 0.0.0.0:*
LISTEN 1699/java
tcp0 0 :::8081 :::*
LISTEN 1699/java
# curl -s http://localhost:48747/metrics/snapshot | python2.7 -m json.tool
{
"scheduler/event_queue_messages": 0,
"system/cpus_total": 24,
"system/load_15min": 0.18,
"system/load_1min": 0.29,
"system/load_5min": 0.2,
"system/mem_free_bytes": 7850483712,
"system/mem_total_bytes": 33534873600
}
{noformat}
Summary: Mesos components should expose their version on an endpoint.
(was: drivers should expose their version on an endpoint)
> Mesos components should expose their version on an endpoint.
>
>
> Key: MESOS-1841
> URL: https://issues.apache.org/jira/browse/MESOS-1841
> Project: Mesos
> Issue Type: Improvement
>Reporter: David Robinson
>Priority: Minor
> Labels: twitter
>
> The libraries (used by scheduler and executor) should expose their version on
> an endpoint.
> {noformat:title=stats exposed by the scheduler driver}
> # netstat -dnatp | grep LISTEN | grep java
> tcp0 0 0.0.0.0:48747 0.0.0.0:*
> LISTEN 1699/java
> tcp0 0 :::8081 :::*
> LISTEN 1699/java
> # curl -s http://localhost:48747/metrics/snapshot | python2.7 -m json.tool
> {
> "scheduler/event_queue_messages": 0,
> "system/cpus_total": 24,
> "system/load_15min": 0.18,
> "system/load_1min": 0.29,
> "system/load_5min": 0.2,
> "system/mem_free_bytes": 7850483712,
> "system/mem_total_bytes": 33534873600
> }
> {noformat}
> Likewise, for the master and slave, a lightweight endpoint is desired, see
> MESOS-2644 as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1841) drivers should expose their version on an endpoint
[
https://issues.apache.org/jira/browse/MESOS-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621447#comment-14621447
]
Benjamin Mahler commented on MESOS-1841:
Linking in duplicate ticket.
> drivers should expose their version on an endpoint
> --
>
> Key: MESOS-1841
> URL: https://issues.apache.org/jira/browse/MESOS-1841
> Project: Mesos
> Issue Type: Improvement
>Reporter: David Robinson
>Priority: Minor
> Labels: twitter
>
> The libraries (used by scheduler and executor) should expose their version on
> an endpoint.
> {noformat:title=stats exposed by the scheduler driver}
> # netstat -dnatp | grep LISTEN | grep java
> tcp0 0 0.0.0.0:48747 0.0.0.0:*
> LISTEN 1699/java
> tcp0 0 :::8081 :::*
> LISTEN 1699/java
> # curl -s http://localhost:48747/metrics/snapshot | python2.7 -m json.tool
> {
> "scheduler/event_queue_messages": 0,
> "system/cpus_total": 24,
> "system/load_15min": 0.18,
> "system/load_1min": 0.29,
> "system/load_5min": 0.2,
> "system/mem_free_bytes": 7850483712,
> "system/mem_total_bytes": 33534873600
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1841) drivers should expose their version on an endpoint
[
https://issues.apache.org/jira/browse/MESOS-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-1841:
---
Labels: twitter (was: )
We can't to it inside metrics, but can definitely add another endpoint.
> drivers should expose their version on an endpoint
> --
>
> Key: MESOS-1841
> URL: https://issues.apache.org/jira/browse/MESOS-1841
> Project: Mesos
> Issue Type: Improvement
>Reporter: David Robinson
>Priority: Minor
> Labels: twitter
>
> The libraries (used by scheduler and executor) should expose their version on
> an endpoint.
> {noformat:title=stats exposed by the scheduler driver}
> # netstat -dnatp | grep LISTEN | grep java
> tcp0 0 0.0.0.0:48747 0.0.0.0:*
> LISTEN 1699/java
> tcp0 0 :::8081 :::*
> LISTEN 1699/java
> # curl -s http://localhost:48747/metrics/snapshot | python2.7 -m json.tool
> {
> "scheduler/event_queue_messages": 0,
> "system/cpus_total": 24,
> "system/load_15min": 0.18,
> "system/load_1min": 0.29,
> "system/load_5min": 0.2,
> "system/mem_free_bytes": 7850483712,
> "system/mem_total_bytes": 33534873600
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2644) AS a framework developer I WANT to check and depend on a Mesos (master) version
[
https://issues.apache.org/jira/browse/MESOS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-2644:
---
Labels: mesosphere twitter (was: mesosphere)
Adding the twitter label as we're interested in having a lightweight /version
endpoint as an alternative to state.json, and also to expose version for any
particular mesos component (slave, master, scheduler driver, executor driver).
> AS a framework developer I WANT to check and depend on a Mesos (master)
> version
> ---
>
> Key: MESOS-2644
> URL: https://issues.apache.org/jira/browse/MESOS-2644
> Project: Mesos
> Issue Type: Story
> Components: framework
>Affects Versions: 0.22.0
>Reporter: Aaron Bell
> Labels: mesosphere, twitter
>
> Example: I'm developing a framework that makes use of persistent volumes,
> MESOS-1554. At startup I want my scheduler to verify the Mesos master's
> version and abort if it's less than e.g. {{0.23.0}}, which I know is the
> minimum version for that feature.
> I've looked at MESOS-753 and MESOS-986 and they don't seem to address this
> cleanly.
> Version may be available in {{state.json}}, but this is an unboundedly large
> value to parse. It would seem sensible to have an HTTP endpoint {{/version}}
> or similar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2834) Support different perf output formats
[ https://issues.apache.org/jira/browse/MESOS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621430#comment-14621430 ] Paul Brett commented on MESOS-2834: --- Updated to address reviewer issues and reposted at: https://reviews.apache.org/r/36378/ https://reviews.apache.org/r/36380/ > Support different perf output formats > - > > Key: MESOS-2834 > URL: https://issues.apache.org/jira/browse/MESOS-2834 > Project: Mesos > Issue Type: Improvement > Components: isolation >Reporter: Ian Downes >Assignee: Paul Brett > Labels: twitter > > The output format of perf changes in 3.14 (inserting an additional field) and > in again in 4.1 (appending additional) fields. See kernel commits: > 410136f5dd96b6013fe6d1011b523b1c247e1ccb > d73515c03c6a2706e088094ff6095a3abefd398b > Update the perf::parse() function to understand all these formats. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3020) Expose major, minor and patch components from stout Version
[
https://issues.apache.org/jira/browse/MESOS-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621395#comment-14621395
]
Benjamin Mahler commented on MESOS-3020:
Don't forget to include the commit for posterity:
{noformat}
commit 3c7933dfe8ff73c4b80a8f2086d0529d69f3051f
Author: Paul Brett
Date: Thu Jul 9 15:07:59 2015 -0700
Exposed major, minor and patch components in stout Version.
Note: The names major and minor are not available when compiling
with GCC because it pulls in the sysmacros.h header implicitly
which define these for makedev.
Review: https://reviews.apache.org/r/36336
{noformat}
> Expose major, minor and patch components from stout Version
> -
>
> Key: MESOS-3020
> URL: https://issues.apache.org/jira/browse/MESOS-3020
> Project: Mesos
> Issue Type: Improvement
>Reporter: Paul Brett
>Assignee: Paul Brett
> Labels: twitter
> Fix For: 0.24.0
>
>
> Stout version class does not expose version components, preventing
> computations manipulation of version information. Solution is to make major,
> minor and patch public.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-708) Static files missing "Last-Modified" HTTP headers
[ https://issues.apache.org/jira/browse/MESOS-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621394#comment-14621394 ] Till Toenshoff commented on MESOS-708: -- See MESOS-3026 for some serious problems of these patches. > Static files missing "Last-Modified" HTTP headers > - > > Key: MESOS-708 > URL: https://issues.apache.org/jira/browse/MESOS-708 > Project: Mesos > Issue Type: Improvement > Components: libprocess, webui >Affects Versions: 0.13.0 >Reporter: Ross Allen >Assignee: Alexander Rojas > Labels: mesosphere > > Static assets served by the Mesos master don't return "Last-Modified" HTTP > headers. That means clients receive a 200 status code and re-download assets > on every page request even if the assets haven't changed. Because Angular JS > does most of the work, the downloading happens only when you navigate to > Mesos master in your browser or use the browser's refresh. > Example header for "mesos.css": > HTTP/1.1 200 OK > Date: Thu, 26 Sep 2013 17:18:52 GMT > Content-Length: 1670 > Content-Type: text/css > Clients sometimes use the "Date" header for the same effect as > "Last-Modified", but the date is always the time of the response from the > server, i.e. it changes on every request and makes the assets look new every > time. > The "Last-Modified" header should be added and should be the last modified > time of the file. On subsequent requests for the same files, the master > should return 304 responses with no content rather than 200 with the full > files. It could save clients a lot of download time since Mesos assets are > rather heavyweight. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3026) ProcessTest.Cache fails and hangs
[
https://issues.apache.org/jira/browse/MESOS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621389#comment-14621389
]
Till Toenshoff commented on MESOS-3026:
---
commit dab0977d2c9649fd9a7235c82cfa5d944ca32214
Author: Till Toenshoff
Date: Fri Jul 10 00:13:06 2015 +0200
Reverted commit for HTTP caching of static assets.
This reverts commit d0300e1a47d1ba5d6714957fc258ab125fd53ed1.
We identified several issues in this implementation and the most important
one is described by MESOS-3026.
> ProcessTest.Cache fails and hangs
> -
>
> Key: MESOS-3026
> URL: https://issues.apache.org/jira/browse/MESOS-3026
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: ubuntu 15.04/ ubuntu 14.04.2
> clang-3.6 / gcc 4.8.2
>Reporter: Joris Van Remoortere
>Assignee: Alexander Rojas
>Priority: Blocker
> Labels: libprocess, tests
>
> {code}
> [ RUN ] ProcessTest.Cache
> ../../../3rdparty/libprocess/src/tests/process_tests.cpp:1726: Failure
> Value of: response.get().status
> Actual: "200 OK"
> Expected: "304 Not Modified"
> [ FAILED ] ProcessTest.Cache (1 ms)
> {code}
> The tests then finish running, but the gtest framework fails to terminate and
> uses 100% CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2257) Set Mesos specific content type with version for HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621382#comment-14621382
]
Ben Whitehead commented on MESOS-2257:
--
This is for things that aren't frameworks.
For example if I've got a tools that hits one of the http endpoints
(/stats.json for example) it'd be nice to have the version of mesos in the HTTP
headers, rather than having to query state.json and extract the property.
> Set Mesos specific content type with version for HTTP endpoints
> ---
>
> Key: MESOS-2257
> URL: https://issues.apache.org/jira/browse/MESOS-2257
> Project: Mesos
> Issue Type: Improvement
>Reporter: Sunil Shah
>Priority: Minor
> Labels: mesosphere
>
> As a consumer of the Mesos HTTP API, it is necessary for us to determine the
> current version of Mesos so that we can parse the JSON documents returned
> correctly (since they change from version to version).
> Currently we're doing this by fetching state.json, parsing it and pulling out
> the version field. A more idiomatic way to do this would be to filter on the
> content-type in the header itself.
> To give a more concrete example, currently the JSON documents returned by the
> HTTP API return the following headers:
> {code}
> HTTP/1.1 200 OK
> Date: Fri, 23 Jan 2015 21:31:37 GMT
> Content-Length: 9352
> Content-Type: application/json
> {code}
> Something like the following (e.g. for master/state.json) would be easy to
> switch upon:
> {code}
> HTTP/1.1 200 OK
> Date: Fri, 23 Jan 2015 21:31:37 GMT
> Content-Length: 9352
> Content-Type: application/vnd.mesos.master.state.v0.20.1+json; charset=utf-8
> {code}
> The vnd prefix is typically used for vendor specific file types (see:
> http://en.wikipedia.org/wiki/Internet_media_type#Prefix_vnd). Charset=utf-8
> is required for JSON documents and is currently being omitted.
> This content-type would change for each document type, for example:
> {code}
> application/vnd.mesos.master.state.v0.20.1+json; charset=utf-8
> application/vnd.mesos.master.stats.v0.20.1+json; charset=utf-8
> application/vnd.mesos.slave.state.v0.20.1+json; charset=utf-8
> application/vnd.mesos.slave.stats.v0.20.1+json; charset=utf-8
> {code}
> Alternatively, the version could be appended as an extra field:
> {code}
> application/vnd.mesos.master.state+json; charset=utf-8; version=v0.20.1
> application/vnd.mesos.master.stats+json; charset=utf-8; version=v0.20.1
> application/vnd.mesos.slave.state+json; charset=utf-8; version=v0.20.1
> application/vnd.mesos.slave.stats+json; charset=utf-8; version=v0.20.1
> {code}
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3026) ProcessTest.Cache fails and hangs
[
https://issues.apache.org/jira/browse/MESOS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621375#comment-14621375
]
Joris Van Remoortere edited comment on MESOS-3026 at 7/9/15 10:13 PM:
--
The offending code is being reverted as even if we fix the time-zone
difference, some of these functions depend on global state. Assigning back to
Alex for now.
was (Author: jvanremoortere):
The offending code is being reverted. Assigning back to Alex for now.
> ProcessTest.Cache fails and hangs
> -
>
> Key: MESOS-3026
> URL: https://issues.apache.org/jira/browse/MESOS-3026
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: ubuntu 15.04/ ubuntu 14.04.2
> clang-3.6 / gcc 4.8.2
>Reporter: Joris Van Remoortere
>Assignee: Alexander Rojas
>Priority: Blocker
> Labels: libprocess, tests
>
> {code}
> [ RUN ] ProcessTest.Cache
> ../../../3rdparty/libprocess/src/tests/process_tests.cpp:1726: Failure
> Value of: response.get().status
> Actual: "200 OK"
> Expected: "304 Not Modified"
> [ FAILED ] ProcessTest.Cache (1 ms)
> {code}
> The tests then finish running, but the gtest framework fails to terminate and
> uses 100% CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3026) ProcessTest.Cache fails and hangs
[
https://issues.apache.org/jira/browse/MESOS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Van Remoortere updated MESOS-3026:
Assignee: Alexander Rojas (was: Joris Van Remoortere)
> ProcessTest.Cache fails and hangs
> -
>
> Key: MESOS-3026
> URL: https://issues.apache.org/jira/browse/MESOS-3026
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: ubuntu 15.04/ ubuntu 14.04.2
> clang-3.6 / gcc 4.8.2
>Reporter: Joris Van Remoortere
>Assignee: Alexander Rojas
>Priority: Blocker
> Labels: libprocess, tests
>
> {code}
> [ RUN ] ProcessTest.Cache
> ../../../3rdparty/libprocess/src/tests/process_tests.cpp:1726: Failure
> Value of: response.get().status
> Actual: "200 OK"
> Expected: "304 Not Modified"
> [ FAILED ] ProcessTest.Cache (1 ms)
> {code}
> The tests then finish running, but the gtest framework fails to terminate and
> uses 100% CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3026) ProcessTest.Cache fails and hangs
[
https://issues.apache.org/jira/browse/MESOS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621375#comment-14621375
]
Joris Van Remoortere commented on MESOS-3026:
-
The offending code is being reverted. Assigning back to Alex for now.
> ProcessTest.Cache fails and hangs
> -
>
> Key: MESOS-3026
> URL: https://issues.apache.org/jira/browse/MESOS-3026
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: ubuntu 15.04/ ubuntu 14.04.2
> clang-3.6 / gcc 4.8.2
>Reporter: Joris Van Remoortere
>Assignee: Joris Van Remoortere
>Priority: Blocker
> Labels: libprocess, tests
>
> {code}
> [ RUN ] ProcessTest.Cache
> ../../../3rdparty/libprocess/src/tests/process_tests.cpp:1726: Failure
> Value of: response.get().status
> Actual: "200 OK"
> Expected: "304 Not Modified"
> [ FAILED ] ProcessTest.Cache (1 ms)
> {code}
> The tests then finish running, but the gtest framework fails to terminate and
> uses 100% CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2061) Add InverseOffer protobuf message.
[
https://issues.apache.org/jira/browse/MESOS-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Hindman updated MESOS-2061:
Shepherd: Benjamin Hindman
> Add InverseOffer protobuf message.
> --
>
> Key: MESOS-2061
> URL: https://issues.apache.org/jira/browse/MESOS-2061
> Project: Mesos
> Issue Type: Task
>Reporter: Benjamin Mahler
>Assignee: Joseph Wu
> Labels: mesosphere, twitter
>
> InverseOffer was defined as part of the maintenance work in MESOS-1474,
> design doc here:
> https://docs.google.com/document/d/16k0lVwpSGVOyxPSyXKmGC-gbNmRlisNEe4p-fAUSojk/edit?usp=sharing
> {code}
> // A request to "deallocate" or "return" any resources already
> // being consumed by the framework.
> message InverseOffer {
> required OfferID id = 1;
> required FrameworkID framework_id = 2;
> repeated Resource resources = 3;
>
> // The slave ID if the resources need to be released on a particular slave.
> optional SlaveID slave_id = 4;
>
> // The executor and task IDs if the resources need to be released on
> specific
> // executors and/or tasks.
> optional ExecutorID executor_id = 6;
> repeated TaskID task_ids = 6;
>
> // The resources specified in this offer will become unavailable
> // at the specified start time and for the specified duration. Any
> // tasks running using these resources might get killed when
> // these resources become unavailable.
> required Unavailability unavailability = 7;
> }
> {code}
> This ticket is to capture the addition of the InverseOffer protobuf to
> mesos.proto, the necessary API changes for Event/Call and the language
> bindings will be tracked separately.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2257) Set Mesos specific content type with version for HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621313#comment-14621313
]
Adam B commented on MESOS-2257:
---
As of Mesos 0.23, MESOS-2957, whenever a framework registers, it gets back a
MasterInfo (containing the version) inside the FrameworkRe[re]gistered message.
Assuming the framework is currently registered with the (leading) master, why
would you need this endpoint? For CLI tools, perhaps?
> Set Mesos specific content type with version for HTTP endpoints
> ---
>
> Key: MESOS-2257
> URL: https://issues.apache.org/jira/browse/MESOS-2257
> Project: Mesos
> Issue Type: Improvement
>Reporter: Sunil Shah
>Priority: Minor
> Labels: mesosphere
>
> As a consumer of the Mesos HTTP API, it is necessary for us to determine the
> current version of Mesos so that we can parse the JSON documents returned
> correctly (since they change from version to version).
> Currently we're doing this by fetching state.json, parsing it and pulling out
> the version field. A more idiomatic way to do this would be to filter on the
> content-type in the header itself.
> To give a more concrete example, currently the JSON documents returned by the
> HTTP API return the following headers:
> {code}
> HTTP/1.1 200 OK
> Date: Fri, 23 Jan 2015 21:31:37 GMT
> Content-Length: 9352
> Content-Type: application/json
> {code}
> Something like the following (e.g. for master/state.json) would be easy to
> switch upon:
> {code}
> HTTP/1.1 200 OK
> Date: Fri, 23 Jan 2015 21:31:37 GMT
> Content-Length: 9352
> Content-Type: application/vnd.mesos.master.state.v0.20.1+json; charset=utf-8
> {code}
> The vnd prefix is typically used for vendor specific file types (see:
> http://en.wikipedia.org/wiki/Internet_media_type#Prefix_vnd). Charset=utf-8
> is required for JSON documents and is currently being omitted.
> This content-type would change for each document type, for example:
> {code}
> application/vnd.mesos.master.state.v0.20.1+json; charset=utf-8
> application/vnd.mesos.master.stats.v0.20.1+json; charset=utf-8
> application/vnd.mesos.slave.state.v0.20.1+json; charset=utf-8
> application/vnd.mesos.slave.stats.v0.20.1+json; charset=utf-8
> {code}
> Alternatively, the version could be appended as an extra field:
> {code}
> application/vnd.mesos.master.state+json; charset=utf-8; version=v0.20.1
> application/vnd.mesos.master.stats+json; charset=utf-8; version=v0.20.1
> application/vnd.mesos.slave.state+json; charset=utf-8; version=v0.20.1
> application/vnd.mesos.slave.stats+json; charset=utf-8; version=v0.20.1
> {code}
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2902) Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME
[
https://issues.apache.org/jira/browse/MESOS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621226#comment-14621226
]
Cody Maloney commented on MESOS-2902:
-
[~bmahler] Mesos is much more particular and peculiar in it's DNS / Hostname /
IP requirements than a lot of datacenter software. nginx, httpd, etc. don't
actually use the machine's hostname, they purely use whatever a request comes
in as. They also don't publish anywhere saying "This is me come find me" based
on the DNS address of the local machine. They get a request in, they inspect
what IP address / port that request came in on, and in the case of nginx /
apache possibly what the {{Host}} HTTP header is and deal with it from there.
In the case of Mesos for the Masters for instance if a master and framework
disagree on the master IP, you just end up with lost packets with no logging
currently. The HTTP API should help in this area, but we need to ship Mesos
today / can't wait for that to come.
We only use cloud-init in some environments. And it only has coreos public /
private IPv4. There are environments we install using the myriad of other host
install / setup tools (chef, salt, fleet, ...). There are a lot of ways we ship
this stuff to clients.
Adding one simple flag doesn't considerably add to the Mesos maintenance
burden, and solves our use case at the moment. If adding a flag is unpalatable,
it could be added as a mesos 'hook' module which does exactly the same thing,
just makes the IP lookup pluggable. That would make it so someone could write a
mesos module which does NetworkManager if they wished (Although there will
still be a problem of Mesos slave can't handle when it's IP address changes)
This isn't teaching mesos configuration management at all. It is trying to get
it out of the policy of trying to self-configure itself badly for a lot of our
customer environments, leading to lots of headaches for various customers we
are trying to ship Mesos as a component of DCOS to.
The maintenance burden for this is no more than the `--ip` flag that Mesos has
currently which is the exact same as setting LIBPROCESS_IP. It does not
significantly effect organizations which do not need the flag / wish to use it
I believe, and if they don't give it, it will not change the behavior of their
setups.
> Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME
>
>
> Key: MESOS-2902
> URL: https://issues.apache.org/jira/browse/MESOS-2902
> Project: Mesos
> Issue Type: Improvement
> Components: master, modules, slave
>Reporter: Cody Maloney
>Assignee: Marco Massenzio
>Priority: Critical
> Labels: mesosphere
>
> Currently Mesos tries to guess the IP, HOSTNAME by doing a reverse DNS
> lookup. This doesn't work on a lot of clouds as we want things like public
> IPs (which aren't the default DNS), there aren't FQDN names (Azure), or the
> correct way to figure it out is to call some cloud-specific endpoint.
> If Mesos / Libprocess could load a mesos-module (Or run a script) which is
> provided per-cloud, we can figure out perfectly the IP / Hostname for the
> given environment. It also means we can ship one identical set of files to
> all hosts in a given provider which doesn't happen to have the DNS scheme +
> hostnames that libprocess/Mesos expects. Currently we have to generate
> host-specific config files which Mesos uses to guess.
> The host-specific files break / fall apart if machines change IP / hostname
> without being reinstalled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3026) ProcessTest.Cache fails and hangs
[
https://issues.apache.org/jira/browse/MESOS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Van Remoortere updated MESOS-3026:
Shepherd: Till Toenshoff
Assignee: Joris Van Remoortere (was: Alexander Rojas)
> ProcessTest.Cache fails and hangs
> -
>
> Key: MESOS-3026
> URL: https://issues.apache.org/jira/browse/MESOS-3026
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: ubuntu 15.04/ ubuntu 14.04.2
> clang-3.6 / gcc 4.8.2
>Reporter: Joris Van Remoortere
>Assignee: Joris Van Remoortere
>Priority: Blocker
> Labels: libprocess, tests
>
> {code}
> [ RUN ] ProcessTest.Cache
> ../../../3rdparty/libprocess/src/tests/process_tests.cpp:1726: Failure
> Value of: response.get().status
> Actual: "200 OK"
> Expected: "304 Not Modified"
> [ FAILED ] ProcessTest.Cache (1 ms)
> {code}
> The tests then finish running, but the gtest framework fails to terminate and
> uses 100% CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3027) Compiler warning in stout subcommand tests
Paul Brett created MESOS-3027: - Summary: Compiler warning in stout subcommand tests Key: MESOS-3027 URL: https://issues.apache.org/jira/browse/MESOS-3027 Project: Mesos Issue Type: Bug Components: stout Environment: clang 3.7 ubuntu 15.04 Reporter: Paul Brett Priority: Minor ../../../../3rdparty/libprocess/3rdparty/stout/tests/subcommand_tests.cpp:146:3: warning: 'delete' applied to a pointer that was allocated with 'new[]'; did you mean 'delete[]'? [-Wmismatched-new-delete] delete argv; ^ [] ../../../../3rdparty/libprocess/3rdparty/stout/tests/subcommand_tests.cpp:119:17: note: allocated with 'new[]' here char** argv = new char*[argc]; ^ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3026) ProcessTest.Cache fails and hangs
[
https://issues.apache.org/jira/browse/MESOS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-3026:
---
Priority: Blocker (was: Major)
> ProcessTest.Cache fails and hangs
> -
>
> Key: MESOS-3026
> URL: https://issues.apache.org/jira/browse/MESOS-3026
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: ubuntu 15.04/ ubuntu 14.04.2
> clang-3.6 / gcc 4.8.2
>Reporter: Joris Van Remoortere
>Assignee: Alexander Rojas
>Priority: Blocker
> Labels: libprocess, tests
>
> {code}
> [ RUN ] ProcessTest.Cache
> ../../../3rdparty/libprocess/src/tests/process_tests.cpp:1726: Failure
> Value of: response.get().status
> Actual: "200 OK"
> Expected: "304 Not Modified"
> [ FAILED ] ProcessTest.Cache (1 ms)
> {code}
> The tests then finish running, but the gtest framework fails to terminate and
> uses 100% CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2902) Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME
[
https://issues.apache.org/jira/browse/MESOS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621126#comment-14621126
]
David Robinson commented on MESOS-2902:
---
{quote}
I can't drop it in a systemd unit file which runs a command before mesos and
pass the data without making a temp file which is an odd way to do the config
generation.
{quote}
[~cmaloney], couldn't you use something like cloud-init to create the file for
EnvironmentFile=... ? eg:
{code}
EnvironmentFile=/etc/mesos/config.env
ExecStart=/usr/bin/mesos-slave... ${some_env_var_from_EnvironmentFile}...
{code}
If not cloud-init then perhaps a service that runs before mesos and populates
EnvironmentFile?
{quote}
The host-specific files break / fall apart if machines change IP / hostname
without being reinstalled.
{quote}
{quote}
It is structurally in-feasible to change the mesos-master systemd unit per
cluster to include the 'Set the IP by running this script' only in cases where
we want to do that. There may also cases where Mesos exits and we restart it,
and it would refuse to start because it has a different IP (mesos slave might
checkpoint it, although I'd have to double check).
{quote}
Can you hook into whatever mechanism changes the IP/hostname and have it also
update EnvironmentFile? I'm fairly certain that dhclient and NetworkManager
could be hooked into to solve this, they both provide the ability to run a
script when an IP changes.
TBH I'm not convinced an --ip-detection flag is needed in mesos. Configuration
management shouldn't be Mesos's concern.
> Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME
>
>
> Key: MESOS-2902
> URL: https://issues.apache.org/jira/browse/MESOS-2902
> Project: Mesos
> Issue Type: Improvement
> Components: master, modules, slave
>Reporter: Cody Maloney
>Assignee: Marco Massenzio
>Priority: Critical
> Labels: mesosphere
>
> Currently Mesos tries to guess the IP, HOSTNAME by doing a reverse DNS
> lookup. This doesn't work on a lot of clouds as we want things like public
> IPs (which aren't the default DNS), there aren't FQDN names (Azure), or the
> correct way to figure it out is to call some cloud-specific endpoint.
> If Mesos / Libprocess could load a mesos-module (Or run a script) which is
> provided per-cloud, we can figure out perfectly the IP / Hostname for the
> given environment. It also means we can ship one identical set of files to
> all hosts in a given provider which doesn't happen to have the DNS scheme +
> hostnames that libprocess/Mesos expects. Currently we have to generate
> host-specific config files which Mesos uses to guess.
> The host-specific files break / fall apart if machines change IP / hostname
> without being reinstalled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3026) ProcessTest.Cache fails and hangs
[
https://issues.apache.org/jira/browse/MESOS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621123#comment-14621123
]
Paul Brett commented on MESOS-3026:
---
I see the same hang on g++ 4.8, ubuntu 14.04.
> ProcessTest.Cache fails and hangs
> -
>
> Key: MESOS-3026
> URL: https://issues.apache.org/jira/browse/MESOS-3026
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: ubuntu 15.04/ ubuntu 14.04.2
> clang-3.6 / gcc 4.8.2
>Reporter: Joris Van Remoortere
>Assignee: Alexander Rojas
> Labels: libprocess, tests
>
> {code}
> [ RUN ] ProcessTest.Cache
> ../../../3rdparty/libprocess/src/tests/process_tests.cpp:1726: Failure
> Value of: response.get().status
> Actual: "200 OK"
> Expected: "304 Not Modified"
> [ FAILED ] ProcessTest.Cache (1 ms)
> {code}
> The tests then finish running, but the gtest framework fails to terminate and
> uses 100% CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3026) ProcessTest.Cache fails and hangs
[
https://issues.apache.org/jira/browse/MESOS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabel Jimenez updated MESOS-3026:
--
Environment:
ubuntu 15.04/ ubuntu 14.04.2
clang-3.6 / gcc 4.8.2
was:
ubuntu 15.04
clang-3.6
> ProcessTest.Cache fails and hangs
> -
>
> Key: MESOS-3026
> URL: https://issues.apache.org/jira/browse/MESOS-3026
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: ubuntu 15.04/ ubuntu 14.04.2
> clang-3.6 / gcc 4.8.2
>Reporter: Joris Van Remoortere
>Assignee: Alexander Rojas
> Labels: libprocess, tests
>
> {code}
> [ RUN ] ProcessTest.Cache
> ../../../3rdparty/libprocess/src/tests/process_tests.cpp:1726: Failure
> Value of: response.get().status
> Actual: "200 OK"
> Expected: "304 Not Modified"
> [ FAILED ] ProcessTest.Cache (1 ms)
> {code}
> The tests then finish running, but the gtest framework fails to terminate and
> uses 100% CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3026) ProcessTest.Cache fails and hangs
Joris Van Remoortere created MESOS-3026:
---
Summary: ProcessTest.Cache fails and hangs
Key: MESOS-3026
URL: https://issues.apache.org/jira/browse/MESOS-3026
Project: Mesos
Issue Type: Bug
Components: libprocess
Environment: ubuntu 15.04
clang-3.6
Reporter: Joris Van Remoortere
Assignee: Alexander Rojas
{code}
[ RUN ] ProcessTest.Cache
../../../3rdparty/libprocess/src/tests/process_tests.cpp:1726: Failure
Value of: response.get().status
Actual: "200 OK"
Expected: "304 Not Modified"
[ FAILED ] ProcessTest.Cache (1 ms)
{code}
The tests then finish running, but the gtest framework fails to terminate and
uses 100% CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2902) Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME
[ https://issues.apache.org/jira/browse/MESOS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621029#comment-14621029 ] Benjamin Mahler commented on MESOS-2902: [~cmaloney], Hm.. I would imagine that operators are faced with this issue for all other sever software. Have you looked at how folks configure IP addresses for other server software under systemd? AFAICT, other projects (e.g. nginx, apache, etc) aren't pushing this kind of scripted IP functionality into the system, seems to require proper configuration from the outside instead, so would be great to understand how this is dealt for other projects. > Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME > > > Key: MESOS-2902 > URL: https://issues.apache.org/jira/browse/MESOS-2902 > Project: Mesos > Issue Type: Improvement > Components: master, modules, slave >Reporter: Cody Maloney >Assignee: Marco Massenzio >Priority: Critical > Labels: mesosphere > > Currently Mesos tries to guess the IP, HOSTNAME by doing a reverse DNS > lookup. This doesn't work on a lot of clouds as we want things like public > IPs (which aren't the default DNS), there aren't FQDN names (Azure), or the > correct way to figure it out is to call some cloud-specific endpoint. > If Mesos / Libprocess could load a mesos-module (Or run a script) which is > provided per-cloud, we can figure out perfectly the IP / Hostname for the > given environment. It also means we can ship one identical set of files to > all hosts in a given provider which doesn't happen to have the DNS scheme + > hostnames that libprocess/Mesos expects. Currently we have to generate > host-specific config files which Mesos uses to guess. > The host-specific files break / fall apart if machines change IP / hostname > without being reinstalled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3025) 0.22.x scheduler driver drops 0.23.x reconciliation status updates due to missing StatusUpdate.uuid.
Benjamin Mahler created MESOS-3025: -- Summary: 0.22.x scheduler driver drops 0.23.x reconciliation status updates due to missing StatusUpdate.uuid. Key: MESOS-3025 URL: https://issues.apache.org/jira/browse/MESOS-3025 Project: Mesos Issue Type: Bug Reporter: Benjamin Mahler Assignee: Benjamin Mahler Priority: Blocker In the process of fixing MESOS-2940, we accidentally introduced a non-backwards compatible change: --> StatusUpdate.uuid was required in 0.22.x and was always set. --> StatusUpdate.uuid is optional in 0.23.x and the master is not setting it for master-generated updates. In 0.22.x, the scheduler driver ignores the 'uuid' for master/driver generated updates already. I'd suggest the following fix: # In 0.23.x, rather than not setting StatusUpdate.uuid, set it to an empty string. # In 0.23.x, ensure the scheduler driver also ignores empty StatusUpdate.uuids. # In 0.24.x, stop setting StatusUpdate.uuid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1648) mesos-slave and mesos-master should have a --pidfile option
[
https://issues.apache.org/jira/browse/MESOS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14591966#comment-14591966
]
Greg Mann edited comment on MESOS-1648 at 7/9/15 4:09 PM:
--
Excellent, thanks for the suggestions Ben. I removed the duplicate and updated
descriptions.
was (Author: greggomann):
Excellent, thanks for the suggestions Ben. Splitting up the patches sounds
good, I'll create issues for the locking/removal and post links here.
> mesos-slave and mesos-master should have a --pidfile option
> ---
>
> Key: MESOS-1648
> URL: https://issues.apache.org/jira/browse/MESOS-1648
> Project: Mesos
> Issue Type: Improvement
> Components: master, slave
>Reporter: Tobias Weingartner
>Assignee: Greg Mann
> Labels: newbie, twitter
>
> Add a {{--pidfile}} option to the common logging flags. Right now we use a
> number of wrapper scripts to try and keep up a
> {{/var/run/mesos/mesos-slave.pid}} in order to be able to monitor the
> process. It would be nice if this extra (somewhat fragile) wrapper was not
> necessary.
> Following implementation of this command line option, consider adding
> automatic removal of the file, as well as locking the file as a secondary
> signal that there is a live mesos-slave to new slaves attempting to start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1999) mesos slave should handle a PID file
[ https://issues.apache.org/jira/browse/MESOS-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Mann updated MESOS-1999: - Description: Duplicate - see MESOS-1648 At the current time, we use extra tooling around the mesos-slave to create and manage a pid file for the slave (and master). This tooling is brittle at best, and it would be very nice if the mesos-slave could create, remove, and manage a pid file on its own. In particular, it could use flock(2) to lock the file while it is running, giving an extra signal to any other slaves starting up that there is a live mesos-slave currently running (along with kill(2) with signal 0 to probe). was: At the current time, we use extra tooling around the mesos-slave to create and manage a pid file for the slave (and master). This tooling is brittle at best, and it would be very nice if the mesos-slave could create, remove, and manage a pid file on its own. In particular, it could use flock(2) to lock the file while it is running, giving an extra signal to any other slaves starting up that there is a live mesos-slave currently running (along with kill(2) with signal 0 to probe). > mesos slave should handle a PID file > > > Key: MESOS-1999 > URL: https://issues.apache.org/jira/browse/MESOS-1999 > Project: Mesos > Issue Type: Bug > Components: slave >Reporter: Tobias Weingartner > > Duplicate - see MESOS-1648 > At the current time, we use extra tooling around the mesos-slave to create > and manage a pid file for the slave (and master). This tooling is brittle at > best, and it would be very nice if the mesos-slave could create, remove, and > manage a pid file on its own. > In particular, it could use flock(2) to lock the file while it is running, > giving an extra signal to any other slaves starting up that there is a live > mesos-slave currently running (along with kill(2) with signal 0 to probe). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1194) protobuf-JSON rendering doesnt validate
[
https://issues.apache.org/jira/browse/MESOS-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620755#comment-14620755
]
Till Toenshoff commented on MESOS-1194:
---
[~Akanksha08] could you have a look at that review-request, I added a comment
that needs to get resolved.
> protobuf-JSON rendering doesnt validate
> ---
>
> Key: MESOS-1194
> URL: https://issues.apache.org/jira/browse/MESOS-1194
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Affects Versions: 0.19.0
>Reporter: Till Toenshoff
>Assignee: Akanksha Agrawal
>Priority: Minor
> Labels: json, newbie, protobuf, stout
>
> When using JSON::Protobuf(Message&), the supplied protobuf is not checked for
> being properly initialized, hence e.g. required fields could be missing.
> It would be desirable to have a feedback mechanism in place for this
> constructor - maybe this would do:
> {noformat}
> if (!message.IsInitialized()) {
> std::cerr << "Protobuf not initialized: " <<
> message.InitializationErrorString() << std::endl;
> abort();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1648) mesos-slave and mesos-master should have a --pidfile option
[
https://issues.apache.org/jira/browse/MESOS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann updated MESOS-1648:
-
Description:
Add a {{--pidfile}} option to the common logging flags. Right now we use a
number of wrapper scripts to try and keep up a
{{/var/run/mesos/mesos-slave.pid}} in order to be able to monitor the process.
It would be nice if this extra (somewhat fragile) wrapper was not necessary.
Following implementation of this command line option, consider adding automatic
removal of the file, as well as locking the file as a secondary signal that
there is a live mesos-slave to new slaves attempting to start.
was:
Add a {{--pidfile}} option to the common logging flags. Right now we use a
number of wrapper scripts to try and keep up a
{{/var/run/mesos/mesos-slave.pid}} in order to be able to monitor the process.
It would be nice if this extra (somewhat fragile) wrapper was not necessary.
Following implementation of this command line option, consider locking the
pidfile as a secondary signal that there is a live mesos-slave to new slaves
attempting to start.
> mesos-slave and mesos-master should have a --pidfile option
> ---
>
> Key: MESOS-1648
> URL: https://issues.apache.org/jira/browse/MESOS-1648
> Project: Mesos
> Issue Type: Improvement
> Components: master, slave
>Reporter: Tobias Weingartner
>Assignee: Greg Mann
> Labels: newbie, twitter
>
> Add a {{--pidfile}} option to the common logging flags. Right now we use a
> number of wrapper scripts to try and keep up a
> {{/var/run/mesos/mesos-slave.pid}} in order to be able to monitor the
> process. It would be nice if this extra (somewhat fragile) wrapper was not
> necessary.
> Following implementation of this command line option, consider adding
> automatic removal of the file, as well as locking the file as a secondary
> signal that there is a live mesos-slave to new slaves attempting to start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1648) mesos-slave and mesos-master should have a --pidfile option
[
https://issues.apache.org/jira/browse/MESOS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann updated MESOS-1648:
-
Description:
Add a {{--pidfile}} option to the common logging flags. Right now we use a
number of wrapper scripts to try and keep up a
{{/var/run/mesos/mesos-slave.pid}} in order to be able to monitor the process.
It would be nice if this extra (somewhat fragile) wrapper was not necessary.
Following implementation of this command line option, consider locking the
pidfile as a secondary signal that there is a live mesos-slave to new slaves
attempting to start.
was:Right now we use a number of wrapper scripts to try and keep up a
{{/var/run/mesos/mesos-slave.pid}} in order to be able to monitor the process.
It would be nice if this extra (somewhat fragile) wrapper was not necessary.
Having a {{--pidfile}} option would eliminate some of this pain.
> mesos-slave and mesos-master should have a --pidfile option
> ---
>
> Key: MESOS-1648
> URL: https://issues.apache.org/jira/browse/MESOS-1648
> Project: Mesos
> Issue Type: Improvement
> Components: master, slave
>Reporter: Tobias Weingartner
>Assignee: Greg Mann
> Labels: newbie, twitter
>
> Add a {{--pidfile}} option to the common logging flags. Right now we use a
> number of wrapper scripts to try and keep up a
> {{/var/run/mesos/mesos-slave.pid}} in order to be able to monitor the
> process. It would be nice if this extra (somewhat fragile) wrapper was not
> necessary.
> Following implementation of this command line option, consider locking the
> pidfile as a secondary signal that there is a live mesos-slave to new slaves
> attempting to start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-708) Static files missing "Last-Modified" HTTP headers
[
https://issues.apache.org/jira/browse/MESOS-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14320300#comment-14320300
]
Till Toenshoff edited comment on MESOS-708 at 7/9/15 1:27 PM:
--
https://reviews.apache.org/r/34703/ - Adds manipulator style objects for the
serialization of {{Time}} object instances.
https://reviews.apache.org/r/30032/ - Adds support for HTTP cache
({{Last-Modifief}} and {{If-Modified-Since}} headers.
was (Author: arojas):
https://reviews.apache.org/r/34392/ - Adds {{Path::mtime()}} by wrapping
{{os::stat::mtime()}}.
https://reviews.apache.org/r/34703/ - Adds manipulator style objects for the
serialization of {{Time}} object instances.
https://reviews.apache.org/r/30032/ - Adds support for HTTP cache
({{Last-Modifief}} and {{If-Modified-Since}} headers.
> Static files missing "Last-Modified" HTTP headers
> -
>
> Key: MESOS-708
> URL: https://issues.apache.org/jira/browse/MESOS-708
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess, webui
>Affects Versions: 0.13.0
>Reporter: Ross Allen
>Assignee: Alexander Rojas
> Labels: mesosphere
>
> Static assets served by the Mesos master don't return "Last-Modified" HTTP
> headers. That means clients receive a 200 status code and re-download assets
> on every page request even if the assets haven't changed. Because Angular JS
> does most of the work, the downloading happens only when you navigate to
> Mesos master in your browser or use the browser's refresh.
> Example header for "mesos.css":
> HTTP/1.1 200 OK
> Date: Thu, 26 Sep 2013 17:18:52 GMT
> Content-Length: 1670
> Content-Type: text/css
> Clients sometimes use the "Date" header for the same effect as
> "Last-Modified", but the date is always the time of the response from the
> server, i.e. it changes on every request and makes the assets look new every
> time.
> The "Last-Modified" header should be added and should be the last modified
> time of the file. On subsequent requests for the same files, the master
> should return 304 responses with no content rather than 200 with the full
> files. It could save clients a lot of download time since Mesos assets are
> rather heavyweight.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2948) Generalize authorizer interface in order to allow for arbitrary Subjects, Actions and Objects
[
https://issues.apache.org/jira/browse/MESOS-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620154#comment-14620154
]
Adam B commented on MESOS-2948:
---
For some history, see comments in MESOS-911 and
https://reviews.apache.org/r/18730/
> Generalize authorizer interface in order to allow for arbitrary Subjects,
> Actions and Objects
> -
>
> Key: MESOS-2948
> URL: https://issues.apache.org/jira/browse/MESOS-2948
> Project: Mesos
> Issue Type: Epic
> Components: master, security
>Reporter: Alexander Rojas
> Labels: acl, mesosphere, security
>
> The current
> [{{mesos::Authorizer}}|https://github.com/apache/mesos/blob/40b596402521be25b93b9ef4edd8f5c727c9d20e/src/authorizer/authorizer.hpp]
> API has one method for each of the _actions_ supported (Register Framework,
> Launch Task and Shutdown Framework), and each of these _actions_ themselves
> define the _objects_ on which they operate.
> Currently, in case a new action needs to be authorized it is necessary to
> modify the {{mesos::Authorizer}} interface and all its implementations
> (currently only {{mesos::LocalAuthorizer}}), and add a new nested message to
> the {{ACL}} message in {{mesos.proto}}.
> An update to the API should allow for new _actions_ and _objects_ to be added
> without the need to change the {{mesos::Authorizer}} interface while
> encapsulating implementation details on how the authorization process is
> performed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2830) Add an endpoint to slaves to allow launching system administration tasks
[
https://issues.apache.org/jira/browse/MESOS-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620112#comment-14620112
]
Marco Massenzio commented on MESOS-2830:
Ok - I have a working prototype, needs some engineering work, but I now have a
basic understanding of how this would work for the Slave.
I'll progress the design doc and present it for discussion; probably tomorrow
(well, today).
Uses a {{POST /execute}} of a JSON-encoded {{CommandInfo}} and will return the
{{JSON}}-encoded output of the command (or something along those lines).
> Add an endpoint to slaves to allow launching system administration tasks
>
>
> Key: MESOS-2830
> URL: https://issues.apache.org/jira/browse/MESOS-2830
> Project: Mesos
> Issue Type: Wish
> Components: slave
>Reporter: Cody Maloney
>Assignee: Marco Massenzio
>Priority: Minor
> Labels: mesosphere
>
> As a System Administrator often times I need to run a organization-mandated
> task on every machine in the cluster. Ideally I could do this within the
> framework of mesos resources if it is a "cleanup" or auditing task, but
> sometimes I just have to run something, and run it now, regardless if a
> machine has un-accounted resources (Ex: Adding/removing a user).
> Currently to do this I have to completely bypass Mesos and SSH to the box.
> Ideally I could tell a mesos slave (With proper authentication) to run a
> container with the limited special permissions needed to get the task done.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
