Hi Marc The slave_public is a DC/OS construct and has no inherent significance in Mesos/Marathon. My guess is that you launched Marathon with default configuration where --mesos_role flag defaults to None ( ref https://mesosphere.github.io/marathon/docs/command-line-flags.html) . Hence Marathon does not recognize the role slave_public and hence might be complaining.
Instead of explaining how to configure marathon/mesos to use a slave_public role I must first ask *What problem are you trying to actually solve?* If the answer to that question is that you want to launch certain apps on certain nodes in the cluster instead of others due to some reason then do explore the possibility of using attributes/constraints (ref: https://mesosphere.github.io/marathon/docs/constraints.html). Let me know if you have questions configuring attributes on mesos and then using constraints on Marathon. But if you are already familiar with constraints and you consciously made a choice of not using them and using roles for a particular reason then you would have to do a couple of things to make it work : 1) Make resource reservation for the desired role in Mesos so that Marathon can be offered the resources with that role 2) Configure Marathon to use that particular resource role If you have not done either of these steps it would not work. Expanding on these two points in above detail : *1) Making resource reservation in Mesos* I would once again stress that make sure you cannot solve this problem with attributes because I’m of the opinion that there is value to not having to statically partition your cluster resources unless there is no better way out. If you are sold on the idea on using static resource reservations then you can configure resources on your agent node using the --resources flag (ref: http://mesos.apache.org/documentation/latest/reservation/) and carve out resources for the desired role (Ref http://mesos.apache.org/documentation/latest/roles/). I purposely did not use the term slave_publicfor role because you can name it to whatever you desire. Also note that --roles flag for Mesos master is deprecated no longer required to be specified. Lets assume you used custom_role as a the role. *2) Configuring Marathon to use the custom role* Please note that even though Mesos now supports a single framework accepting offers from mutiple roles ( https://issues.apache.org/jira/browse/MESOS-1763), Marathon has not caught upto this (https://jira.mesosphere.com/browse/MARATHON-2775) yet. So as of today Marathon can only get offers for one customer role and unreserved (*) resources. - Configuring --mesos_role flag Unless you specify --mesos_role custom_role Marathon is only going to accept offers from * resources. If you specify --mesos_role custom_role apps launched on Marathon would be able to accept offers from both * as well as custom_role. - Configuring --default_accepted_resource_roles flag Another important flag to be aware of here is --default_accepted_resource_roles. This flag dictates the deafult for "acceptedResourceRoles" attribute as a comma-separated list of strings. Any app definition which does not specify this attribute explicitly uses this value for launching new tasks. So you can use the correct mix of --mesos_role and --default_accepted_resource_roles to get desired behaviour. e.g. : —mesos_role —default_accepted_resource_roles acceptedResourceRoles resources used <unspecified> <unspecified> <unspecified> * custom_role <unspecified> <unspecified> * or custom_role custom_role *,custom_role <unspecified> * or custom_role custom_role * custom_role custom_role You can extrapolate the examples from the table above to come up with all possibilities and use the one that fits your needs. Let me know if you have followup questions. Cheers Harpreet On Fri, Oct 20, 2017 at 2:00 PM, Marc Roos <[email protected]> wrote: > 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:[email protected]] > Sent: vrijdag 20 oktober 2017 18:41 > To: [email protected] > 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:[email protected]] > Sent: Friday, October 20, 2017 9:29 AM > To: user <[email protected]> > 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 > > > > > >
