Details
Description
When I first ran marathon it was running as a personal user and registered with mesos-master as such due to putting an empty string in the user field. When I restarted marathon as "nobody", tasks were still being run as the personal user which didn't exist on the slaves. I know marathon was trying to send a FrameworkInfo with nobody listed as the user because I hard coded it in. The tasks wouldn't run as "nobody" until I restarted the mesos-master. Each time I restarted the marathon framework, it reregistered with mesos-master and mesos-master wrote to the logs that it detected a failover because the scheduler went away and then came back.
I understand the scheduler failover, but shouldn't mesos-master respect an updated FrameworkInfo when the scheduler re-registers?
Attachments
Issue Links
- blocks
-
AURORA-687 Aurora should set FrameworkInfo.principal
- Resolved
-
MESOS-1719 Master should persist framework information
- Accepted
- duplicates
-
MESOS-751 Move to online updates of cached FrameworkInfo
- Resolved
-
MESOS-2006 update FrameworkInfo when a framework reregistered
- Resolved
- is duplicated by
-
MESOS-2570 webuiUrl doesn't get updated when a framework re-registers
- Resolved
-
MESOS-1218 Support changing framework failover timeouts
- Resolved
- is related to
-
MESOS-6627 Allow frameworks to modify the role(s) they are subscribed to.
- Resolved
-
MESOS-1828 The Mesos UI should link to framework UIs
- Resolved
- relates to
-
MESOS-2842 Master crashes when framework changes principal on re-registration
- Resolved
-
MESOS-9747 Make behaviour of re-subscription consistent with UPDATE_FRAMEWORK.
- Open
-
MESOS-2841 FrameworkInfo should include a Labels field to support arbitrary, lightweight metadata
- Resolved
-
MESOS-7258 Provide scheduler calls to subscribe to additional roles and unsubscribe from roles.
- Resolved
-
MESOS-8582 Pass FrameworkInfo to agents when applying operations
- Accepted