Re:

[Armand Grillet]

I would be interested.

Le mar. 10 juil. 2018 à 02:46, Harold Dost  a écrit :

> Also interested
>
> 
>
> Harold Dost | @hdost
>
>
>
> On Mon, Jul 9, 2018, 17:50 Gastón Kleiman  wrote:
>
>> Hi all,
>>
>> I'm considering creating an "Operations Working Group".
>>
>> It could focus on making Mesos clusters easier to manage, deploy, and
>> operate.
>>
>> Some possible topics that could be discussed in the working group:
>>
>>- Best practices for operating a Mesos cluster
>>- Packaging
>>- Tools to deploy, upgrade, and operate Mesos clusters (Puppet,
>>Saltstack, Terraform, Mesos CLI, etc.)
>>- Observability through metrics, logging, and debug/information
>>endpoints
>>
>> Please let me know if you think that such a working group would be useful
>> for the community and if you would be interesting in joining its meetings.
>>
>> Thanks!
>>
>> -Gastón
>>
>

-- 
Armand Grillet
Software Engineer, Mesosphere

Re:

[Harold Dost]

Also interested



Harold Dost | @hdost



On Mon, Jul 9, 2018, 17:50 Gastón Kleiman  wrote:

> Hi all,
>
> I'm considering creating an "Operations Working Group".
>
> It could focus on making Mesos clusters easier to manage, deploy, and
> operate.
>
> Some possible topics that could be discussed in the working group:
>
>- Best practices for operating a Mesos cluster
>- Packaging
>- Tools to deploy, upgrade, and operate Mesos clusters (Puppet,
>Saltstack, Terraform, Mesos CLI, etc.)
>- Observability through metrics, logging, and debug/information
>endpoints
>
> Please let me know if you think that such a working group would be useful
> for the community and if you would be interesting in joining its meetings.
>
> Thanks!
>
> -Gastón
>

Operations Working Group proposal

[Gastón Kleiman]

Woops, I just noticed that I sent the email without a subject, I'm adding
one to this mail =).

On Mon, Jul 9, 2018 at 2:49 PM Gastón Kleiman  wrote:

> Hi all,
>
> I'm considering creating an "Operations Working Group".
>
> It could focus on making Mesos clusters easier to manage, deploy, and
> operate.
>
> Some possible topics that could be discussed in the working group:
>
>- Best practices for operating a Mesos cluster
>- Packaging
>- Tools to deploy, upgrade, and operate Mesos clusters (Puppet,
>Saltstack, Terraform, Mesos CLI, etc.)
>- Observability through metrics, logging, and debug/information
>endpoints
>
> Please let me know if you think that such a working group would be useful
> for the community and if you would be interesting in joining its meetings.
>
> Thanks!
>
> -Gastón
>

Re:

[Abel Souza]

I’d be interested.

> On Jul 9, 2018, at 11:49 PM, Gastón Kleiman  wrote:
> 
> Hi all,
> 
> I'm considering creating an "Operations Working Group".
> 
> It could focus on making Mesos clusters easier to manage, deploy, and operate.
> 
> Some possible topics that could be discussed in the working group:
> Best practices for operating a Mesos cluster 
> Packaging
> Tools to deploy, upgrade, and operate Mesos clusters (Puppet, Saltstack, 
> Terraform, Mesos CLI, etc.) 
> Observability through metrics, logging, and debug/information endpoints
> Please let me know if you think that such a working group would be useful for 
> the community and if you would be interesting in joining its meetings.
> 
> Thanks!
> 
> -Gastón

Re:

[Noah Cawley]

Absolutely interested.

On Mon, Jul 9, 2018, 2:50 PM Gastón Kleiman  wrote:

> Hi all,
>
> I'm considering creating an "Operations Working Group".
>
> It could focus on making Mesos clusters easier to manage, deploy, and
> operate.
>
> Some possible topics that could be discussed in the working group:
>
>- Best practices for operating a Mesos cluster
>- Packaging
>- Tools to deploy, upgrade, and operate Mesos clusters (Puppet,
>Saltstack, Terraform, Mesos CLI, etc.)
>- Observability through metrics, logging, and debug/information
>endpoints
>
> Please let me know if you think that such a working group would be useful
> for the community and if you would be interesting in joining its meetings.
>
> Thanks!
>
> -Gastón
>

[no subject]

[Gastón Kleiman]

Hi all,

I'm considering creating an "Operations Working Group".

It could focus on making Mesos clusters easier to manage, deploy, and
operate.

Some possible topics that could be discussed in the working group:

   - Best practices for operating a Mesos cluster
   - Packaging
   - Tools to deploy, upgrade, and operate Mesos clusters (Puppet,
   Saltstack, Terraform, Mesos CLI, etc.)
   - Observability through metrics, logging, and debug/information endpoints

Please let me know if you think that such a working group would be useful
for the community and if you would be interesting in joining its meetings.

Thanks!

-Gastón

Re: [VOTE] Release Apache Mesos 1.3.3 (rc1)

[Michael Park]

I'm considering simply abandoning the 1.3.3 release and bringing the 1.3.x
branch to end of life.
If anyone really wants a 1.3.3, I'm certainly willing to finish the release
portion of this
but I don't have time to dig into the CI issue that Vinod pointed out. If
someone feels compelled
to investigate the issue and wants 1.3.3 released, please speak up.

I'll wait for some time (say, a week) to gauge the interest and take
corresponding action.

Thanks,

MPark

On Thu, May 31, 2018 at 11:55 AM Vinod Kone  wrote:

> -1 (binding).
>
>
> Ran it in ASF CI and found an issue worth investigating. Other 3 issues
> looks to be related to known flaky tests and/or known core dump issue (that
> has been fixed in later versions).
>
> *Revision*: c78e56e4ea217878dd604de638623be166a18db0
>
>- refs/tags/1.3.3-rc1
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl autotools
> [image: Failed]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> --verbose autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
> [image: Success]
> 
> [image: Failed]
> 
> cmake
> [image: Success]
> 
> [image: Failed]
> 
> --verbose autotools
> [image: Failed]
> 
> [image: Success]
> 
> cmake
> [image: Success]
> 
> [image: Success]
> 
>
>
> 1) Segfault in HTTP Test.
> 
>  Looks
> related to MESOS-6799
> 
>  but
> that is suppos

Re: Normalization of metric keys

[Greg Mann]

Good idea; I think percent-encoding sounds great. Unless there are any
objections, I'll go with that approach.

On Fri, Jul 6, 2018 at 5:32 PM, Benjamin Mahler  wrote:

> Do we also want:
>
> 3. Has an unambiguous decoding.
>
> Replacing '/' with '#%$' means I don't know if the user actually supplied
> '#%$' or '/'. But using something like percent-encoding would have property
> 3.
>
> On Fri, Jul 6, 2018 at 10:25 AM, Greg Mann  wrote:
>
>> Thanks for the reply Ben!
>>
>> Yea I suspect the lack of normalization there was not intentional, and it
>> means that you can no longer reliably split on '/' unless you apply some
>> external controls to user input. Yep, this is bad :)
>>
>> One thing we should consider when normalizing metadata embedded in metric
>> keys (like framework name/ID) is that operators will likely want to
>> de-normalize this information in their metrics tooling. For example,
>> ideally something like the 'mesos_exporter' [1] could expose the framework
>> name/ID as tags which could be easily consumed by the cluster's metrics
>> infrastructure.
>>
>> To accommodate de-normalization, any substitutions we perform while
>> normalizing should be:
>>
>>1. Unique - we should substitute a single, unique string for each
>>disallowed character
>>2. Verbose - we should substitute strings which are unlikely to
>>appear in user input. (Examples: '#&#', '*@*', '%!%', etc.)
>>
>>
>> My thought was that since operators can already not simply "split on
>> slash", we might as well avoid normalization to avoid the above
>> difficulties with de-normalization. There are other ways that the metric
>> keys can be processed (e.g., regex), but this requires that the tooling
>> have prior knowledge of the keys it should expect, which is not ideal.
>>
>> However, it also seems reasonable to me to normalize in a way that
>> accommodates de-normalization as noted above.
>>
>> *What would folks think about normalizing by substituting '/' with '#%$'?*
>>
>> Another character that came up as a possible candidate for substitution
>> is the space character, which could very well appear in framework names. I
>> don't think we have a good reason on our side to substitute whitespace, but
>> perhaps its presence in the metric keys would cause issues with external
>> tooling?
>>
>> Greg
>>
>> [1] https://github.com/mesosphere/mesos_exporter
>>
>>
>> On Tue, Jul 3, 2018 at 5:56 PM, Benjamin Mahler 
>> wrote:
>>
>>> I don't think the lack of principal normalization was intentional. Why
>>> spread that further? Don't we also have some normalization today?
>>>
>>> Having slashes show up in components complicates parsing (can no longer
>>> split on '/'), no? For example, if we were to introduce the ability to
>>> query a subset of metrics with a simple matcher (e.g.
>>> /frameworks/*/messages_received), then this would be complicated by the
>>> presence of slashes in the principal or other user supplied strings.
>>>
>>> On Tue, Jul 3, 2018 at 3:17 PM, Greg Mann  wrote:
>>>
 Hi all!
 I'm currently working on adding a suite of new per-framework metrics to
 help schedulers better debug unexpected/unwanted behavior (MESOS-8842
 ). One issue that
 has come up during this work is how we should handle strings like the
 framework name or role name in metric keys, since those strings may contain
 characters like '/' which already have a meaning in our metrics interface.
 I intend to place the framework name and ID in the keys for the new
 per-framework metrics, delimited by a sufficiently-unique separator so that
 operators can decode the name/ID in their metrics tooling. An example
 per-framework metric key:

 master/frameworks/###/tasks/ta
 sk_running


 I recently realized that we actually already allow the '/' character in
 metric keys, since we include the framework principal in these keys:

 frameworks//messages_received
 frameworks//messages_processed

 We don't disallow any characters in the principal, so anything could
 appear in those keys.

 *Since we don't normalize the principal in the above keys, my proposal
 is that we do not normalize the framework name at all when constructing the
 new per-framework metric keys.*


 Let me know what you think!

 Cheers,
 Greg

>>>
>>>
>>
>

Register now for ApacheCon and save $250

[Rich Bowen]

Greetings, Apache software enthusiasts!

(You’re getting this because you’re on one or more dev@ or users@ lists 
for some Apache Software Foundation project.)


ApacheCon North America, in Montreal, is now just 80 days away, and 
early bird prices end in just two weeks - on July 21. Prices will be 
going up from $550 to $800 so register NOW to save $250, at 
http://apachecon.com/acna18


And don’t forget to reserve your hotel room. We have negotiated a 
special rate and the room block closes August 24. 
http://www.apachecon.com/acna18/venue.html


Our schedule includes over 100 talks and we’ll be featuring talks from 
dozens of ASF projects.,  We have inspiring keynotes from some of the 
brilliant members of our community and the wider tech space, including:


 * Myrle Krantz, PMC chair for Apache Fineract, and leader in the open 
source financing space
 * Cliff Schmidt, founder of Literacy Bridge (now Amplio) and creator 
of the Talking Book project

 * Bridget Kromhout, principal cloud developer advocate at Microsoft
 * Euan McLeod, Comcast engineer, and pioneer in streaming video

We’ll also be featuring tracks for Geospatial science, Tomcat, 
Cloudstack, and Big Data, as well as numerous other fields where Apache 
software is leading the way. See the full schedule at 
http://apachecon.com/acna18/schedule.html


As usual we’ll be running our Apache BarCamp, the traditional ApacheCon 
Hackathon, and the Wednesday evening Lighting Talks, too, so you’ll want 
to be there.


Register today at http://apachecon.com/acna18 and we’ll see you in Montreal!

--
Rich Bowen
VP, Conferences, The Apache Software Foundation
h...@apachecon.com
@ApacheCon