Re: Welcome Chun-Hung Hsiao as Mesos Committer and PMC Member
Congrats Chun! 🎉 On Mon, Mar 12, 2018 at 2:50 PM, Benjamin Mahler wrote: > Welcome Chun! It's been great discussing things with you so far and thanks > for the all the hard work! > > On Sat, Mar 10, 2018 at 9:14 PM, Jie Yu wrote: > > > Hi, > > > > I am happy to announce that the PMC has voted Chun-Hung Hsiao as a new > > committer and member of PMC for the Apache Mesos project. Please join me > > to congratulate him! > > > > Chun has been an active contributor for the past year. His main > > contributions to the project include: > > * Designed and implemented gRPC client support to libprocess (MESOS-7749) > > * Designed and implemented Storage Local Resource Provider (MESOS-7235, > > MESOS-8374) > > * Implemented part of the CSI support (MESOS-7235, MESOS-8374) > > > > Chun is friendly and humble, but also intelligent, insightful, and > > opinionated. I am confident that he will be a great addition to our > > committer pool. Thanks Chun for all your contributions to the project so > > far! > > > > His committer checklist can be found here: > > https://docs.google.com/document/d/1FjroAvjGa5NdP29zM7- > > 2eg6tLPAzQRMUmCorytdEI_U/edit?usp=sharing > > > > - Jie > > > -- Judith Malnick Community Manager 310-709-1517
Re: API Review: Resize (persistent) volume support
>From the perspective of resource allocation, GROW takes two resources and merge them into one, while SHRINK takes one resource and split it into two. So, having two separated calls could make it explicit to the framework about what the resources being consumed are. Jie also mentioned in the comment https://reviews.apache.org/r/66049/#comment279663 that specifying two resources instead of one in GROW would make the validation clear. I don't think allowing the operation to be applied more than once is a good idea, and thus I'm thinking about the following validation: 1. The master checks that its resources contain the consumed resource(s). 2. The master forwards the operation to the agent. 3. The agent checks that its resources contain the consumed resource(s). 4. The agent applies the operation to update its resources, and returns a resource conversion. 5. The master receives the resource conversion and applies it to update its resources. On Sun, Mar 18, 2018 at 8:16 PM, James Peach wrote: > > > > On Mar 16, 2018, at 11:12 AM, Zhitao Li wrote: > > > > Hi everyone, > > > > Chun, Greg, Gastón and I are working on supporting resizing of persistent > > volume[1]. See [2] for the design doc in length. > > > > The proposed new offer operation and corresponding operator API are in > > following two patches: > > > > https://reviews.apache.org/r/66049/ > > https://reviews.apache.org/r/66052 > > > > Our intention is to eventually support resizing of not only persistent > > volumes, but also CSI volumes[3] introduced after Mesos 1.5 in the same > set > > of API, so we are declaring the API as experimental in its first release > > version. > > > > We also want to make sure the API is reasonable to use to framework > authors > > and operators. > > Why do you have separate GROW/SHRINK operations? Could a RESIZE operation > with a target size work? > > In all of these cases, is it possible for the operation to be applied more > than once? Clearly, replaying a SHRINK would be bad. Applying RESIZE > operations out of order would also be bad, but not in the same way. > > What is the response to this request? > > > Considering the above, both APIs need to include the original volume as > > resource. Some alternatives on extra fields: > > 1) size difference in Resource format: this may not be applicable in CSI > > volume; > > 2) size difference in Scalar value: this can be applicable in both CSI > and > > persistent volume case, since there is always a quantitive difference. We > > can add extra CSI only fields once the spec is defined; > > 3) target volume in `Resource` format: this may not be possible for any > CSI > > volume because the implementation could change certain metadata, so we > did > > not take this approach. > > > > Therefore, we are taking option 2) in current patches. > > > > Please let me know what you think. Thanks. > > > > [1] https://issues.apache.org/jira/browse/MESOS-4965 > > [2] https://docs.google.com/document/d/1Z16okNG8mlf2eA6NyW_PUmBfNFs_ > > 6EOaPzPtwYNVQUQ/edit# > > [3] https://github.com/apache/mesos/blob/master/docs/csi.md > > > > -- > > Cheers, > > > > Zhitao Li > >
[GitHub] mesos issue #266: Tasks docs
Github user kohend commented on the issue: https://github.com/apache/mesos/pull/266 Is it relevant to add it to the documentation in the source instead, so that the difference will have better visibility (and people won't have to go through versions to see when it's added)? ---
Re: Introducing `support/mesos-build.sh`
Dockerfile for ARM with CMake support https://reviews.apache.org/r/66138/ pon., 12 lut 2018 o 15:41 użytkownik Tomek Janiszewski napisał: > How can I use it for our ARM CI? > > JOBS=16 OS=arm64v8/ubuntu:16.04 ./support/mesos-build.sh > + set -e > + set -o pipefail > + : arm64v8/ubuntu:16.04 > + : autotools > + : gcc > + : '--verbose --disable-libtool-wrappers' > + : 'GLOG_v=1 MESOS_VERBOSE=1' > + : 16 > ++ git rev-parse --show-toplevel > + MESOS_DIR=/home/janisz/mesos > ++ git diff-index --quiet HEAD -- > + docker run --rm -v /home/janisz/mesos:/SRC:Z -e BUILDTOOL=autotools -e > COMPILER=gcc -e 'CONFIGURATION=--verbose --disable-libtool-wrappers' -e > 'ENVIRONMENT=GLOG_v=1 MESOS_VERBOSE=1' -e JOBS=16 > mesos/mesos-build:arm64v8/ubuntu-16.04 > docker: invalid reference format. > See 'docker run --help'. > > > czw., 8 lut 2018 o 07:38 użytkownik Michael Park > napisał: > >> The first run looks good! >> https://builds.apache.org/job/Mesos-Buildbot/4890/ >> >> [image: Screen Shot 2018-02-07 at 10.30.51 PM.png] >> On Wed, Feb 7, 2018 at 8:39 PM Michael Park wrote: >> >> > Yep, Just landed! Waiting for >> https://builds.apache.org/job/Mesos-Buildbot to >> > pick it up. >> > >> > On Wed, Feb 7, 2018 at 8:27 PM Vinod Kone wrote: >> > >> >> Yay, thanks MPark! Has the change landed already? >> >> >> >> On Wed, Feb 7, 2018 at 8:23 PM, Michael Park wrote: >> >> >> >> > Many of you probably know that we currently have >> >> `support/docker-build.sh` >> >> > to power our CI for our various configurations. One of the problems >> for >> >> us >> >> > has been that we create a `Dockerfile` ad-hoc and invoke `docker >> build` >> >> > with it. This is very inefficient and also leads to flaky issues >> around >> >> > `apt-get install`. >> >> > >> >> > I've introduced `support/mesos-build.sh` which operates off of docker >> >> > images hosted on Dockerhub instead, and should aid in bringing us >> faster >> >> > and more stable CI results! >> >> > >> >> > As a bonus, we now also test Clang on the CentOS 7! >> >> > >> >> > Thanks, >> >> > >> >> > MPark >> >> > >> >> >> > >> >
