RE: rotating secrets when authenticating framework

2017-10-20 Thread Devendra Ayalasomayajula
Corrected the subject

From: Devendra Ayalasomayajula
Sent: Friday, October 20, 2017 2:40 PM
To: user@mesos.apache.org
Subject: rotting secrets when authenticating framework

Hi,

The framework I am experimenting with is using MesosSchedulerDriver and I am 
planning to pass Credential. But If the secret is updated how can the 
Credential that's passed to the driver be updated.
How to handle secrets with expiry ?

Thank You
Devendra

This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.



rotting secrets when authenticating framework

2017-10-20 Thread Devendra Ayalasomayajula
Hi,

The framework I am experimenting with is using MesosSchedulerDriver and I am 
planning to pass Credential. But If the secret is updated how can the 
Credential that's passed to the driver be updated.
How to handle secrets with expiry ?

Thank You
Devendra

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


RE: Mesos acceptedResourceRoles slave_public

2017-10-20 Thread Marc Roos
 
Thanks :) But I am runing a test setup of 3 nodes on CentOS7, should 
have written this with first post.

Linux m01 3.10.0-693.2.2.el7.x86_64
mesos-1.4.0-2.0.1.x86_64
marathon-1.4.8-1.0.660.el7.x86_64
containernetworking-cni-0.5.1-1.el7.x86_64
mesosphere-zookeeper-3.4.6-0.1.20141204175332.centos7.x86_64
chronos-2.5.0-0.1.20170816233446.el7.x86_64





-Original Message-
From: Bruce Campbell [mailto:bruce.campb...@microsoft.com] 
Sent: vrijdag 20 oktober 2017 18:41
To: user@mesos.apache.org
Subject: RE: Mesos acceptedResourceRoles slave_public

In acs engine if you define a ports list, the agent will be deployed as 
slave_public.

Example of a public linux agent:

   "agentPoolProfiles": [
  {
"name": "wpub6",
"count": 3,
"vmSize": "Standard_DS2_v2",
"dnsPrefix": "wpub6",
"ports": [
 80,
 443,
 8080,
 3389
  ],
  "customNodeLabels" : {
"foo" : "bar",
"att1" : "value1"
  }
  },

 
},

-Original Message-
From: Marc Roos [mailto:m.r...@f1-outsourcing.eu]
Sent: Friday, October 20, 2017 9:29 AM
To: user 
Subject: Mesos acceptedResourceRoles slave_public

 
I added "acceptedResourceRoles": ["slave_public"] to a json application 
config in marathon. And it complains that the agents/slaves are not 
configured for this. I see some manuals on how to reconfigure via dc/os. 

I just wondered could this be an easy setting like something like this

echo "appc,docker" > /etc/mesos-slave/image_providers







RE: Mesos acceptedResourceRoles slave_public

2017-10-20 Thread Bruce Campbell
In acs engine if you define a ports list, the agent will be deployed as 
slave_public.

Example of a public linux agent:

   "agentPoolProfiles": [
  {
"name": "wpub6",
"count": 3,
"vmSize": "Standard_DS2_v2",
"dnsPrefix": "wpub6",
"ports": [
 80,
 443,
 8080,
 3389
  ],
  "customNodeLabels" : {
"foo" : "bar",
"att1" : "value1"
  }
  },

 
},

-Original Message-
From: Marc Roos [mailto:m.r...@f1-outsourcing.eu] 
Sent: Friday, October 20, 2017 9:29 AM
To: user 
Subject: Mesos acceptedResourceRoles slave_public

 
I added "acceptedResourceRoles": ["slave_public"] to a json application config 
in marathon. And it complains that the agents/slaves are not configured for 
this. I see some manuals on how to reconfigure via dc/os. 
I just wondered could this be an easy setting like something like this

echo "appc,docker" > /etc/mesos-slave/image_providers





Mesos acceptedResourceRoles slave_public

2017-10-20 Thread Marc Roos
 
I added "acceptedResourceRoles": ["slave_public"] to a json application 
config in marathon. And it complains that the agents/slaves are not 
configured for this. I see some manuals on how to reconfigure via dc/os. 
I just wondered could this be an easy setting like something like this

echo "appc,docker" > /etc/mesos-slave/image_providers





Re: Sending TASK_STARTING in the built-in executors

2017-10-20 Thread Benno Evers
As a follow-up, this change now landed and will likely be part of Mesos
1.5.0.

We did our best to verify that we don't accidentally break existing
frameworks, and the only issue we could find was with chronos (where a fix
was since merged into the stable and master branches).

If you discover that some framework you depend on would choke on this, now
would be a good time to update it before upgrading to Mesos 1.5.0 ;)

Best regards,

On Wed, Aug 23, 2017 at 11:38 AM, Benno Evers  wrote:

> Hi all,
>
> when starting a task, an executor can send out the following status
> updates:
>
>   - [optional] TASK_STARTING: Sent by the executor when it received the
> launch command
>   - TASK_RUNNING: Sent by the executor when the task is running
>
> The built-in executors currently don't send out TASK_STARTING updates. I
> think this discards potentially valuable information, because TASK_RUNNING
> informs us about the current status of the task, but not about the status
> change.
>
> For example, if the network connection between scheduler and master is
> interrupted during task start, it has no good way to estimate the tasks
> start time, because the TASK_RUNNING update that it eventually gets might
> be a much later one. Also, for tasks with a long delay between STARTING and
> RUNNING, to an outside observer it will look the same as if the task was
> stuck in STAGING.
>
> There is a small risk that sending an additional update could break
> existing frameworks. We briefly looked through some of the most popular
> open-source frameworks and didn't find any major issues, but of course it's
> impossible to do an exhaustive check.
>
> In particular, a framework will break if
>
>  1. It runs tasks using one of the built-in mesos executors, and
>  2. it doesn't handle the possibility of receiving TASK_STARTING update,
> and
>  3. it reports an error whenever it encounters an unexpected task states
> in an update.
>
>
> If you are aware of any such framework, please speak up so we can consider
> it.
>
>
> Thanks,
> --
> Benno Evers
> Software Engineer, Mesosphere
>



-- 
Benno Evers
Software Engineer, Mesosphere