> On Dec. 1, 2017, 12:24 p.m., Benjamin Bannier wrote: > > include/mesos/allocator/allocator.hpp > > Lines 211-212 (patched) > > <https://reviews.apache.org/r/64010/diff/4/?file=1903878#file1903878line211> > > > > This doesn't look what was in the original design where a framework > > could receive an update for agent updates and remove offer filters itself > > (we already independently plan to extend the scheduler interfaces to allow > > reviving a single agent for offer operation feedback). > > > > I feel having a master remove unexpired offer filters by itself > > violates responsibilities. It would seem much more straight-forward to > > reason about lifecycles would the framework which created the filter also > > be the sole on responsible for cleaning it up before expiry. The originally > > designed agent update channel to the framework would permit this, and I > > hope this is what we still plan to implement. > > > > This makes me wonder whether we should we mark this parameter as > > transitional if we cannot get rid of it completely now. We are working on a > > public interface here so this is not ideal either.
We don't have an agent update message yet. That's a bigger project that needs to be done. For now, instead of changing the interface, we will remove the filters inside the allocator itself on attribute changes only. - Vinod ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/64010/#review192478 ----------------------------------------------------------- On Dec. 1, 2017, 6:31 p.m., Benno Evers wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/64010/ > ----------------------------------------------------------- > > (Updated Dec. 1, 2017, 6:31 p.m.) > > > Review request for mesos and Vinod Kone. > > > Repository: mesos > > > Description > ------- > > The current `SlaveInfo` of a slave is now passed as an additional > parameter to `updateSlave()`, to account for the possibility of > it changing during an agent restart. > > While the existing HierarchicalDRFAllocator only cares about the domain > and hostname fields, the full SlaveInfo is passed since custom > allocators might base their scheduling decisions on other fields, for > example attributes. > > Additionally, this also provides callers with an option to reset > existing offer filters for a given slave id when the update is > applied. > > > Diffs > ----- > > include/mesos/allocator/allocator.hpp > acb9e4f6a843e64c915c43c218d8a533ca63333b > src/master/allocator/mesos/allocator.hpp > 48254b6e0974bdc16ffda04d3d271538048d3206 > src/master/allocator/mesos/hierarchical.hpp > 3c87dc797cf70f3aa48b1ed9f86d673d4ea2fe76 > src/master/allocator/mesos/hierarchical.cpp > ab2abf868f9252154d934243521622c5cb107182 > src/tests/allocator.hpp fc5d9efc8dab3bd971fa8938e3f82e8291c4ab9d > src/tests/hierarchical_allocator_tests.cpp > 0309074bab180be122c9b0074981e6f69c97feee > > > Diff: https://reviews.apache.org/r/64010/diff/5/ > > > Testing > ------- > > > Thanks, > > Benno Evers > >
