Re: Should "read-only" HTTP endpoints allow other request methods than "GET"?

[Kevin Klues]

There was some discussion of this between mpark and I in relation to
the v1 operator API.  The idea was to have a base class for endpoints
that implement GET/POST/DELETE/PUT/etc... functions that return an
error by default. You can then override the specific subset of them
that that each endpoint supports.

On Tue, May 10, 2016 at 6:42 AM, Vinod Kone  wrote:
> +1 to only allow GET for read only
>
> @vinodkone
>
>> On May 10, 2016, at 6:37 AM, Jan Schlicht  wrote:
>>
>> Hi guys,
>>
>> while working on HTTP endpoint authorization for Mesos, I found some
>> interesting behavior: It's the responsibility of the HTTP endpoint handlers
>> to validate the HTTP request method they've been called with. Many
>> "read-only" endpoints (e.g. "/flags", "/state") don't do this at the
>> moment. This means that it's possible to send, for example, an HTTP "POST"
>> to the "/state" endpoint and get the same results as if it would have been
>> an HTTP "GET".
>> While this is currently not a problem, it will complicate things when we
>> want to authorize endpoint access. The authorization should take the HTTP
>> request method into account to distinguish between "user wants read access
>> to the endpoint" and "user wants write access to the endpoint". This makes
>> it ambitious on how to handle these "read-only" endpoints that also accept
>> a "POST" request.
>> The solution to that problem would be to add HTTP request method validation
>> to every endpoint, i.e. the read-only endpoints would reject any request
>> method that isn't "GET". I've created MESOS-5346 for that.
>> Because that would change the existing behavior, that allows to e.g. "POST"
>> to a "read-only" endpoint, I'd like to know if anybody relies on that
>> behavior, or if there are any other objections on changing it.
>>
>> Cheers,
>> Jan



-- 
~Kevin

Re: Should "read-only" HTTP endpoints allow other request methods than "GET"?

[Vinod Kone]

+1 to only allow GET for read only

@vinodkone

> On May 10, 2016, at 6:37 AM, Jan Schlicht  wrote:
> 
> Hi guys,
> 
> while working on HTTP endpoint authorization for Mesos, I found some
> interesting behavior: It's the responsibility of the HTTP endpoint handlers
> to validate the HTTP request method they've been called with. Many
> "read-only" endpoints (e.g. "/flags", "/state") don't do this at the
> moment. This means that it's possible to send, for example, an HTTP "POST"
> to the "/state" endpoint and get the same results as if it would have been
> an HTTP "GET".
> While this is currently not a problem, it will complicate things when we
> want to authorize endpoint access. The authorization should take the HTTP
> request method into account to distinguish between "user wants read access
> to the endpoint" and "user wants write access to the endpoint". This makes
> it ambitious on how to handle these "read-only" endpoints that also accept
> a "POST" request.
> The solution to that problem would be to add HTTP request method validation
> to every endpoint, i.e. the read-only endpoints would reject any request
> method that isn't "GET". I've created MESOS-5346 for that.
> Because that would change the existing behavior, that allows to e.g. "POST"
> to a "read-only" endpoint, I'd like to know if anybody relies on that
> behavior, or if there are any other objections on changing it.
> 
> Cheers,
> Jan

Should "read-only" HTTP endpoints allow other request methods than "GET"?

[Jan Schlicht]

Hi guys,

while working on HTTP endpoint authorization for Mesos, I found some
interesting behavior: It's the responsibility of the HTTP endpoint handlers
to validate the HTTP request method they've been called with. Many
"read-only" endpoints (e.g. "/flags", "/state") don't do this at the
moment. This means that it's possible to send, for example, an HTTP "POST"
to the "/state" endpoint and get the same results as if it would have been
an HTTP "GET".
While this is currently not a problem, it will complicate things when we
want to authorize endpoint access. The authorization should take the HTTP
request method into account to distinguish between "user wants read access
to the endpoint" and "user wants write access to the endpoint". This makes
it ambitious on how to handle these "read-only" endpoints that also accept
a "POST" request.
The solution to that problem would be to add HTTP request method validation
to every endpoint, i.e. the read-only endpoints would reject any request
method that isn't "GET". I've created MESOS-5346 for that.
Because that would change the existing behavior, that allows to e.g. "POST"
to a "read-only" endpoint, I'd like to know if anybody relies on that
behavior, or if there are any other objections on changing it.

Cheers,
Jan

Re: mesos git commit: Replaced CHECK with CHECK_READY.

[Neil Conway]

Hi Ben,

Thanks for raising this!

My thinking for grouping the changes together in a single review is
basically what AlexR said: I agree with doing "one thing per patch",
but I felt like a header cleanup was sufficiently close to CHECK
cleanup that they could be grouped together. If there's consensus that
folks would rather see such changes separated, I'm happy to do that in
the future.

Re: the  change, my mistake -- although I confess I
didn't realize we have a strict "no dependence on transitive includes"
policy. Is that documented anywhere?

Anyway, RRs here:

https://reviews.apache.org/r/47112 avoids depending on transitively
included headers
https://reviews.apache.org/r/47113 replaces "using namespace process;"
with more fine-grained "using" statements
https://reviews.apache.org/r/47114 fixes angle bracket style.

Thanks,
Neil

On Sun, May 8, 2016 at 10:28 AM, Alex R  wrote:
> I agree that "atomic patches" (those that do one thing per patch) are a good
> thing because they simplify navigating history, do blame and bisect. But how
> to define that "one thing"? Some people would say, that a new feature is one
> thing, and if introducing a feature requires some refactoring, it should be
> done in the same patch, so that motivation for the refactoring is clear. On
> the other hand there will be folks who would say that putting all
> loosely-coupled changes like refactoring, tests, protobuf update,
> implementation into the same patch makes it hardly reviewable and
> complicates finding problems via blame / bisect.
>
> Let's take a step back and think, why we need to read commit history in the
> first place. Based on my experience, I see several cases:
>   * Searching which patch introduced a bug, a regression, or some peculiar
> behaviour.
>   * Learning how a feature was implemented and why.
>
> That's why it is important to separate functional changes from cleanups.
>
> However, do we still want to separate different sorts of cleanups as well or
> squash them together to avoid the churn? If I search for a bug and see a
> style fix patch, I simply skip. I'd rather prefer to have one single patch
> for all style fixes than a tiny patch for each type of cleanup.
>
> Regarding r/46827/, you are right that doing audit of include and using
> sections was not the primary intention, but I considered it fine to include
> those changes since they were not making the code "worse" (modulo removing
>  which was a mistake).
>
> On 8 May 2016 at 02:38, Benjamin Mahler  wrote:
>>
>> Hm.. any reason that unrelated headers were touched and the using
>> statement was removed in this patch?
>>
>> My concern with mixing unrelated changes within a single patch is that
>> patches become less precise. If one reads the patch there is additional
>> overhead in understanding what is related to the goal of the change and what
>> is not. I know it's a small example here but I see value in being
>> disciplined about this regardless of patch size.
>>
>> The other concern is that the reviewer of this patch has to review these
>> two additional changes:
>>   1. How does the header audit look? Anything else need added or removed?
>>   2. How does the 'using' audit look? Anything else need added or removed?
>>
>> (1) and (2) could be done together in a single patch. As in turns out, the
>> header audit looks like it has a few issues, but I'm guessing the reviewer
>> glossed over it because the point of this change was CHECK_READY :)
>>   - was removed but CHECK_NONE and CHECK_SOME are used
>>   - is not present but LOG is used
>>   - is absent but Nothing is used
>>   - is absent but process::Process / process::wait /
>> process::terminate are used.
>>
>> Then for the 'using' audit, we now avoid pulling in all of the process::
>> namespace in favor of finer-grained using statements.
>>
>> On Mon, May 2, 2016 at 4:08 AM,  wrote:
>>>
>>> Repository: mesos
>>> Updated Branches:
>>>   refs/heads/master 78f6101cc -> 4f9040db6
>>>
>>>
>>> Replaced CHECK with CHECK_READY.
>>>
>>> Also removes some unused header includes.
>>>
>>> Review: https://reviews.apache.org/r/46827/
>>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/4f9040db
>>> Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/4f9040db
>>> Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/4f9040db
>>>
>>> Branch: refs/heads/master
>>> Commit: 4f9040db62294f370f94aaba675f05b1ccf7a310
>>> Parents: 78f6101
>>> Author: Neil Conway 
>>> Authored: Mon May 2 13:05:56 2016 +0200
>>> Committer: Alexander Rukletsov 
>>> Committed: Mon May 2 13:05:56 2016 +0200
>>>
>>> --
>>>  src/zookeeper/contender.cpp | 7 ++-
>>>  1 file changed, 2 insertions(+), 5 deletions(-)
>>> 

[Unified Container] [Unit Test] Pay attention to your test case when using "alpine" docker image with INTERNET filter

[Guangya Liu]

Hi,

We got two JIRA tickets for same issue about test failure on CentOS 7:
1) https://issues.apache.org/jira/browse/MESOS-5351
2) https://issues.apache.org/jira/browse/MESOS-4810

The issue for those two JIRA tickets are the test case will be failed on
CentOS 7, the root cause is that on some linux distribution, '/bin' is not
under $PATH when some shell is used. Since the container image 'alpine'
itself does not specify environment variables, $PATH will be inherit from
the agent. As a result, when we exec, the exec cannot find 'sh' because
it's under /bin in alpine, but '/bin' is not under $PATH.

I see that we are continually adding test cases for unified container with
INTERNET CURL option, so just sending this out as a reminder to avoid such
issue in your test case.

To avoid such issue, please refer to
https://github.com/apache/mesos/blob/master/src/tests/containerizer/provisioner_docker_tests.cpp#L435-L443
as a reference: *Use a non-shell command because 'sh' might not be in the
PATH.*

Thanks,

Guangya

Re: Does Mesos have official dailybuild packages?

[tommy xiao]

https://github.com/mesosphere/mesos-deb-packaging is awesome project.

2016-05-10 13:37 GMT+08:00 Shuai Lin :

> This repo may be helpful if you want to build deb pkgs yourself:
> https://github.com/mesosphere/mesos-deb-packaging
>
> On Tue, May 10, 2016 at 1:17 PM, zhiwei  wrote:
>
> > Hi all,
> >
> > When a user want to use Mesos from master branch, how should he do?
> Compile
> > from source code?
> >
> > Is there an official script to build Mesos package?
> >
> >
> > Thanks,
> > Zhiwei
> >
>



-- 
Deshi Xiao
Twitter: xds2000
E-mail: xiaods(AT)gmail.com

Re: Atomicity of multiple OfferOperations

[Adam Bordelon]

See also https://issues.apache.org/jira/browse/MESOS-3746

On Wed, May 4, 2016 at 6:13 PM, Benjamin Mahler  wrote:

> It's not done atomically. Yes it's possible that only RESERVE succeeded and
> CREATE was dropped due to a failure in the master or agent.
>
> On Wed, May 4, 2016 at 5:50 PM, Zhitao Li  wrote:
>
> > Hi,
> >
> > Can someone confirm whether whether a sequence of RESERVE, CREATE and
> > LAUNCH operations are perform atomic or not? For example, if master is
> > restarted in the middle, is it possible that RESERVE succeeded, but
> CREATE
> > for persistent volume failed?
> >
> > Thanks.
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>

Looking for Shepherd for MESOS-2201

[Tomek Janiszewski]

Hi

Can anyone help shepherd MESOS-2201 – Fixed replica log restore tests.
This issue is first step to upgrade leveldb.

https://issues.apache.org/jira/browse/MESOS-2201
https://reviews.apache.org/r/47161/

Thanks
Tomek