Apache Mesos is a cluster manager that provides efficient resource isolation and sharing across distributed applications, or frameworks

Overview

Apache Mesos

Apache Mesos is a cluster manager that provides efficient resource isolation and sharing across distributed applications, or frameworks. It can run Hadoop, Jenkins, Spark, Aurora, and other frameworks on a dynamically shared pool of nodes.

Visit us at mesos.apache.org.

Mailing Lists

Documentation

Documentation is available in the docs/ directory. Additionally, a rendered HTML version can be found on the Mesos website's Documentation page.

Installation

Instructions are included on the Getting Started page.

License

Apache Mesos is licensed under the Apache License, Version 2.0.

For additional information, see the LICENSE and NOTICE files.

Comments
  • Fixed a bug where the cgroup task killer leaves the cgroup frozen.

    Fixed a bug where the cgroup task killer leaves the cgroup frozen.

    When its future is discarded, the cgroup task killer would stop immediately. This potentially leaves the cgroup frozen, therefore leaving all processes in uninterruptible state, which is quite bad - for example the tasks would be unkillable and the cgroup couldn't be destroyed. Instead, when discarded, wait a bit to give the task killer a chance to finish cleanly, killing all the tasks and thawing the cgroup.

    I started seeing this after updating my kernel - dozens of tests would fail randomly when trying to destroy cgroups, e.g.:

    [ RUN      ] SlaveRecoveryTest/0.ExecutorDanglingLatestSymlink
    I0517 22:39:10.577574 573547 exec.cpp:164] Version: 1.12.0
    I0517 22:39:10.591667 573550 exec.cpp:237] Executor registered on agent a7c3a499-2968-4eb6-91dd-1020fedc1522-S0
    I0517 22:39:10.594743 573552 executor.cpp:190] Received SUBSCRIBED event
    I0517 22:39:10.595999 573552 executor.cpp:194] Subscribed executor on thinkpad
    I0517 22:39:10.596259 573552 executor.cpp:190] Received LAUNCH event
    I0517 22:39:10.597656 573552 executor.cpp:722] Starting task 39b1539d-9c30-41b0-b643-3ece3e63bea5
    I0517 22:39:10.617466 573552 executor.cpp:740] Forked command at 573554
    ../../src/tests/mesos.cpp:782: Failure
    Failed to wait 15secs for cgroups::destroy(hierarchy, cgroup)
    *** Aborted at 1621287565 (unix time) try "date -d @1621287565" if you are using GNU date ***
    PC: @     0x56129f5437e7 testing::UnitTest::AddTestPartResult()
    *** SIGSEGV (@0x0) received by PID 573473 (TID 0x7fb79b027b00) from PID 0; stack trace: ***
        @     0x7fb79c287140 (unknown)
        @     0x56129f5437e7 testing::UnitTest::AddTestPartResult()
        @     0x56129f5366f3 testing::internal::AssertHelper::operator=()
        @     0x56129e60421b mesos::internal::tests::ContainerizerTest<>::TearDown()
        @     0x56129f5633cb testing::internal::HandleSehExceptionsInMethodIfSupported<>()
        @     0x56129f55d634 testing::internal::HandleExceptionsInMethodIfSupported<>()
        @     0x56129f53d38d testing::Test::Run()
        @     0x56129f53dbb2 testing::TestInfo::Run()
        @     0x56129f53e1f9 testing::TestCase::Run()
        @     0x56129f544ce0 testing::internal::UnitTestImpl::RunAllTests()
        @     0x56129f564349 testing::internal::HandleSehExceptionsInMethodIfSupported<>()
        @     0x56129f55e24a testing::internal::HandleExceptionsInMethodIfSupported<>()
        @     0x56129f543a0a testing::UnitTest::Run()
        @     0x56129e0f6aba RUN_ALL_TESTS()
        @     0x56129e0f6505 main
        @     0x7fb79c0d4d0a __libc_start_main
        @     0x56129d23545a _start
    Erreur de segmentation (core dumped)
    

    Comparing a successful run:

    I0516 23:58:25.918263 466660 cgroups.cpp:2934] Freezing cgroup /sys/fs/cgroup/freezer/mesos_test_8851f242-b14a-4580-88b8-5d3dd552bfde/e2bf97c3-14a1-4b2b-b399-12dbd0f1c99d
    I0516 23:58:25.918447 466657 cgroups.cpp:1323] Successfully froze cgroup /sys/fs/cgroup/freezer/mesos_test_8851f242-b14a-4580-88b8-5d3dd552bfde/e2bf97c3-14a1-4b2b-b399-12dbd0f1c99d after 157952ns
    I0516 23:58:25.918900 466660 cgroups.cpp:2952] Thawing cgroup /sys/fs/cgroup/freezer/mesos_test_8851f242-b14a-4580-88b8-5d3dd552bfde/e2bf97c3-14a1-4b2b-b399-12dbd0f1c99d
    I0516 23:58:25.919064 466656 cgroups.cpp:1352] Successfully thawed cgroup /sys/fs/cgroup/freezer/mesos_test_8851f242-b14a-4580-88b8-5d3dd552bfde/e2bf97c3-14a1-4b2b-b399-12dbd0f1c99d after 134912ns
    

    To an unsuccessful one:

    I0516 23:58:42.638830 466897 linux_launcher.cpp:606] Destroying cgroup '/sys/fs/cgroup/freezer/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558'
    I0516 23:58:42.639083 466898 composing.cpp:343] Finished recovering all containerizers
    I0516 23:58:42.639549 466898 cgroups.cpp:2934] Freezing cgroup /sys/fs/cgroup/freezer/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558
    I0516 23:58:42.714794 466899 cgroups.cpp:2952] Thawing cgroup /sys/fs/cgroup/freezer/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558
    W0516 23:58:42.745649 466903 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:42.746997 466902 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:42.749405 466898 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:42.754009 466900 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:42.762802 466901 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:42.779531 466904 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:42.812022 466897 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:42.877116 466903 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:43.006693 466898 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:43.264366 466899 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:43.777858 466901 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:44.803258 466897 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    W0516 23:58:46.851841 466901 cgroups.cpp:294] Removal of cgroup /sys/fs/cgroup/memory/mesos_test_98d2814b-03ad-4c14-a3f9-832ab688e386/3139257f-4e7a-4828-9af4-75c867846558 failed with EBUSY, will try again
    

    We can see that when the problem occur, it's because the cgroup doesn't freeze quickly. Since the tests quickly destroys the slave/containeriser after the task finished, the cgroups task killer gets interrupted after the cgroup has started to be frozen but before it's been thawed (after killing the tasks) - https://github.com/apache/mesos/blob/master/src/linux/cgroups.cpp#L1445

      void killTasks() {
        // Chain together the steps needed to kill all tasks in the cgroup.
        chain = freeze()                     // Freeze the cgroup.
          .then(defer(self(), &Self::kill))  // Send kill signal.
          .then(defer(self(), &Self::thaw))  // Thaw cgroup to deliver signal.
          .then(defer(self(), &Self::reap)); // Wait until all pids are reaped.
    
        chain.onAny(defer(self(), &Self::finished, lambda::_1));
      }
    

    The problem is that the process sets up a discard callback which immediately terminates the process - https://github.com/apache/mesos/blob/master/src/linux/cgroups.cpp#L1407

      void initialize() override
      {
        // Stop when no one cares.
        promise.future().onDiscard(lambda::bind(
            static_cast<void (*)(const UPID&, bool)>(terminate), self(), true));
    
        killTasks();
      }
    

    Which means that the task killer can be interrupted after it's frozen the cgroup, but before killing the tasks and thawing. Which means that the cgroup stays frozen, tasks are stuck in uninterruptible state, can't be killed and the cgroup can't be destroyed, as can be seen above.

    I'm not adding a specific test because it's causing dozens of tests to fail already.

    I'm not quite sure why this only started happening on recent kernels, but my guess is that for whatever reason freezing seems to sometime take longer than before, which means we're much more likely to interrupt the killer in the middle of its work. In any case it's a long-standing bug which has potentially bad consequences so good to fix.

    @asekretenko @qianzhangxa

    opened by cf-natali 20
  • Add mesos authentication to the mesos cli

    Add mesos authentication to the mesos cli

    The following points I done:

    • Add authentication against mesos manager and agent
    • Add option to skip SSL verification of the mesos-agent
    • Changed the order of "task list" to get back more running states
    opened by andreaspeters 18
  • Process dispatch

    Process dispatch

    Generic Asynchronous Dispatcher

    Motivation

    Since mesos code is based on the actor model and dispatching an interface
    asynchronously is a large part of the code base, generalizing the higher level concept of
    asynchronously dispatching an interface would eliminate the need to manually program the dispatch boilerplate.

    An example usage:
    For a simple interface like:

    class Interface                                                                  
    {                                                                                
      virtual Future<size_t> writeToFile(const char* data) = 0;                      
      virtual ~Interface();                                                          
    };     
    

    Today the developer has to do the following:

    a. Write a wrapper class that implements the same interface to add the
    dispatching boilerplate.
    b. Spend precious time in reviews.
    c. Risk introducing bugs.

    None of the above steps add any value to the executable binary.

    The wrapper class would look like:

    
    // -- hpp file                                                                   
    class InterfaceProcess;                                                          
    
    class InterfaceImpl : public Interface                                           
    {                                                                                
    public:                                                                          
      Try<Owned<InterfaceImpl>> create(const Flags& flags);                          
    
      virtual Future<size_t> writeToFile(const char* data);                          
    
      ~InterfaceImpl();
    private:                                                                         
      Owned<InterfaceProcess> process;                                               
    };                                                                               
    
    // -- cpp file                                                                   
    Try<Owned<InterfaceImpl>> create(const Flags& flags)                             
    {                                                                                
      // Code to create the InterfaceProcess class.                                  
    }                                                                                
    
    Future Future<size_t> InterfaceImpl::writeToFile(const char* data)               
    {                                                                                
      process->dispatch(                                                             
        &InterfaceProcess::writeToFile,                                              
        data);                                                                       
    }                                                                                
    
    InterfaceImpl::InterfaceImpl()                                                   
    {                                                                                
      // Code to spawn the process                                                   
    }                                                                                
    
    InterfaceImpl::~InterfaceImpl()                                                  
    {                                                                                
      // Code to stop the process.                                                   
    }   
    

    At the caller/client site, the code would look like:

    Try<Owned<Interface>> in = InterfaceImpl::create(flags);                         
    Future<size_t> result =                                                          
      in->writeToFile(data);                                                                       
    

    Proposal

    We should use C++'s rich language semnatics to express the intent and avoid
    the boilerplate we write manually.
    The basic intent of the code that leads to all the boilerplate above is:

    a. An interface that provides a set of functionality.
    b. An implementation of the interface.
    c. Ability to dispatch that interface asynchronously using actor.

    C++ has a rich set of generics that can be used to express above.

    Components

    1. ProcessDispatcher
      This component will "dispatch" an interface implementation asychronously using the process framework.
      This component can be expressed as:

      ProcessDispatcher<Interface, InterfaceImplmentation>   
      
    2. DispatchInterface
      Any interface that provides an implementation that can be "dispatched" can be
      expressed using this component.
      This component can be expressed as:

    Dispatchable<Interface>  
    

    Usage:

    1. Simple usage
    Try<Owned<Dispatchable<Interface>>> dispatcher =                                 
      ProcessDispatcher<Interface, InterfaceImpl>::create(flags);                    
    
    Future<size_t> result =                                                          
      dispatcher->dispatch(                                                          
        Interface::writeToFile,                                                      
        data);                                                                       
    
    1. Collecting the interface in a container

      vector<Owned<Dispatchable<Interface>>> dispatchCollection;                       
      
      Try<Owned<Dispatchable<Interface>>> dispatcher1 =                                
      ProcessDispatcher<Interface, InterfaceImpl1>::create(flags);                   
      
      Try<Owned<Dispatchable<Interface>>> dispatcher2 =                                
      ProcessDispatcher<Interface, InterfaceImpl2>::create("test");                  
      
      dispatchCollection.push_back(dispatcher1);                                       
      dispatchCollection.push_back(dispatcher2);    
      
      

    The advantages of using the generic dispatcher:

    • Saves time by avoiding to write all the boilerplate and going through review
      cycles.
    • Less bugs.
    • Focus on real problem and not boilerplate.
    • Less code to represent a primitive.
    opened by conqerAtapple 16
  • [MESOS-6038] Prevent memory leaks

    [MESOS-6038] Prevent memory leaks

    This should prevent any of the promises that are created in the various ZookeeperProcess class methods from leaking memory.

    https://reviews.apache.org/r/51068/

    opened by aaronjwood 14
  • MESOS-10225: Update documentation to systemd's parameter delegate

    MESOS-10225: Update documentation to systemd's parameter delegate

    With these PR I would like to add the systemd parameter "delegate" into the documentation of the mesos-agent. See Issue: https://issues.apache.org/jira/browse/MESOS-10225

    Therefore these PR would not remove our asf.yaml file (https://github.com/apache/mesos-site/pull/2), I also add it into the middleman build process. I know, normally it should be two PR's.

    opened by andreaspeters 13
  • Added option to enable privileged mode for Docker.

    Added option to enable privileged mode for Docker.

    There are a number of options I'd like to pass to Docker, but the most important one right now is --privileged. This specifically addresses that flag, but it would be nice to eventually take some arbitrary arguments. Not sure if there's a plan in place for that.

    opened by kmatzen 13
  • Fixed parsing of ld.so.cache on new glibc.

    Fixed parsing of ld.so.cache on new glibc.

    Since glibc 2.32, ld.so.cache now defaults to the "new" format, instead of the "compat" format which was in use since glibc 2.2 (around 20 years ago). It is now the default on e.g. Debian bullseye, and any recent Linux distribution.

    The code change adds support for the "new" format along with the existing support for the "compat".

    Before:

    root@thinkpad:/home/cf/src/mesos/build# ldconfig -c new
    root@thinkpad:/home/cf/src/mesos/build# ./bin/mesos-tests.sh --gtest_filter=*Ld*
    [...]                                                                                                                                            
    [==========] Running 4 tests from 2 test cases.
    [----------] Global test environment set-up.
    [----------] 1 test from LdcacheTest
    [ RUN      ] LdcacheTest.Parse
    ../../src/tests/ldcache_tests.cpp:43: Failure
    cache: Invalid format
    [  FAILED  ] LdcacheTest.Parse (0 ms)
    [----------] 1 test from LdcacheTest (0 ms total)
    
    [----------] 3 tests from Ldd
    [ RUN      ] Ldd.BinSh
    ../../src/tests/ldd_tests.cpp:43: Failure
    cache: Invalid format
    [  FAILED  ] Ldd.BinSh (0 ms)
    [ RUN      ] Ldd.EmptyCache
    [       OK ] Ldd.EmptyCache (1 ms)
    [ RUN      ] Ldd.MissingFile
    ../../src/tests/ldd_tests.cpp:77: Failure
    cache: Invalid format
    [  FAILED  ] Ldd.MissingFile (0 ms)
    [----------] 3 tests from Ldd (1 ms total)
    
    [----------] Global test environment tear-down
    [==========] 4 tests from 2 test cases ran. (8 ms total)
    [  PASSED  ] 1 test.
    [  FAILED  ] 3 tests, listed below:
    [  FAILED  ] LdcacheTest.Parse
    [  FAILED  ] Ldd.BinSh
    [  FAILED  ] Ldd.MissingFile
    
     3 FAILED TESTS
    

    After:

    root@thinkpad:/home/cf/src/mesos/build# ldconfig -c new
    root@thinkpad:/home/cf/src/mesos/build# ./bin/mesos-tests.sh --gtest_filter=*Ld*
    [...]                                                                                                                                                                                                                                                                  
    [==========] Running 4 tests from 2 test cases.
    [----------] Global test environment set-up.
    [----------] 1 test from LdcacheTest
    [ RUN      ] LdcacheTest.Parse
    [       OK ] LdcacheTest.Parse (529 ms)
    [----------] 1 test from LdcacheTest (529 ms total)
    
    [----------] 3 tests from Ldd
    [ RUN      ] Ldd.BinSh
    [       OK ] Ldd.BinSh (3 ms)
    [ RUN      ] Ldd.EmptyCache
    [       OK ] Ldd.EmptyCache (0 ms)
    [ RUN      ] Ldd.MissingFile
    [       OK ] Ldd.MissingFile (0 ms)
    [----------] 3 tests from Ldd (3 ms total)
    
    [----------] Global test environment tear-down
    [==========] 4 tests from 2 test cases ran. (541 ms total)
    [  PASSED  ] 4 tests.
    

    Closes #10220.

    @asekretenko @andreaspeters

    opened by cf-natali 11
  • Add alg RS256 support for JWT generator and validator.

    Add alg RS256 support for JWT generator and validator.

    Currently, the JWT library only support creating and validating HS256 tokens. I implemented the creation and validation of RS256 tokens.

    The interface is accepting a shared pointer of RSA as input for RSA keys to be as generic as possible but I also provide helper functions to convert PEM representation of keys into RSA keys so that it is easy to read the PEM on disk. I will probably implement the JWK representation of keys in a coming review.

    opened by clems4ever 11
  • mesoscon eu - hackatron exercise - CI using travis

    mesoscon eu - hackatron exercise - CI using travis

    Hi,

    reusing some of the work my colleague @danigiri did (mesos-build-helper) , i've adapted (and incorporated into the project) some scripts that, inside a container:

    • resolves the compilation dependencies

    • compiles

    • and execute the tests

      So TravisCI can execute this on branches and when triggering PRs against the project (currently is active, but does nothing out of adding red flags)...

    Pending to do:

    • actual error checking (probably we want to break the build if make test fails)

    • remove some references to mesos_version (current scripts pick the latest checked out version)

      That's it for now... let me know if it makes sense to complete the work (you probably are covering CI in a different way), but having this integrated in github may be good for contributors. Example of job that travis executed: https://travis-ci.org/dcaba/mesos/builds/157089050

    opened by dcaba 11
  • Add framework plugin

    Add framework plugin

    As I mentioned, I add a framework plugin to mesos-cli and some new features for the already existing task plugin.

    The features are:

    • show all framework
    • inspect frameworks and tasks
    • disable the limitation of tasks in the task list
    opened by andreaspeters 10
  • Documented EOF in ATTACH_CONTAINER_INPUT

    Documented EOF in ATTACH_CONTAINER_INPUT

    This documents how to indicate when EOF is reached on STDIN.

    See https://github.com/dcos/dcos-core-cli/blob/009999e1d8f4eddca5d961152f32669e02ed81d5/python/lib/dcos/dcos/mesos.py#L1657-L1658

    opened by bamarni 9
  • Bump nokogiri from 1.13.6 to 1.13.9 in /site

    Bump nokogiri from 1.13.6 to 1.13.9 in /site

    Bumps nokogiri from 1.13.6 to 1.13.9.

    Release notes

    Sourced from nokogiri's releases.

    1.13.9 / 2022-10-18

    Security

    Dependencies

    • [CRuby] Vendored libxml2 is updated to v2.10.3 from v2.9.14.
    • [CRuby] Vendored libxslt is updated to v1.1.37 from v1.1.35.
    • [CRuby] Vendored zlib is updated from 1.2.12 to 1.2.13. (See LICENSE-DEPENDENCIES.md for details on which packages redistribute this library.)

    Fixed

    • [CRuby] Nokogiri::XML::Namespace objects, when compacted, update their internal struct's reference to the Ruby object wrapper. Previously, with GC compaction enabled, a segmentation fault was possible after compaction was triggered. [#2658] (Thanks, @​eightbitraptor and @​peterzhu2118!)
    • [CRuby] Document#remove_namespaces! now defers freeing the underlying xmlNs struct until the Document is GCed. Previously, maintaining a reference to a Namespace object that was removed in this way could lead to a segfault. [#2658]

    sha256 checksums:

    9b69829561d30c4461ea803baeaf3460e8b145cff7a26ce397119577a4083a02  nokogiri-1.13.9-aarch64-linux.gem
    e76ebb4b7b2e02c72b2d1541289f8b0679fb5984867cf199d89b8ef485764956  nokogiri-1.13.9-arm64-darwin.gem
    15bae7d08bddeaa898d8e3f558723300137c26a2dc2632a1f89c8574c4467165  nokogiri-1.13.9-java.gem
    f6a1dbc7229184357f3129503530af73cc59ceba4932c700a458a561edbe04b9  nokogiri-1.13.9-x64-mingw-ucrt.gem
    36d935d799baa4dc488024f71881ff0bc8b172cecdfc54781169c40ec02cbdb3  nokogiri-1.13.9-x64-mingw32.gem
    ebaf82aa9a11b8fafb67873d19ee48efb565040f04c898cdce8ca0cd53ff1a12  nokogiri-1.13.9-x86-linux.gem
    11789a2a11b28bc028ee111f23311461104d8c4468d5b901ab7536b282504154  nokogiri-1.13.9-x86-mingw32.gem
    01830e1646803ff91c0fe94bc768ff40082c6de8cfa563dafd01b3f7d5f9d795  nokogiri-1.13.9-x86_64-darwin.gem
    8e93b8adec22958013799c8690d81c2cdf8a90b6f6e8150ab22e11895844d781  nokogiri-1.13.9-x86_64-linux.gem
    96f37c1baf0234d3ae54c2c89aef7220d4a8a1b03d2675ff7723565b0a095531  nokogiri-1.13.9.gem
    

    1.13.8 / 2022-07-23

    Deprecated

    • XML::Reader#attribute_nodes is deprecated due to incompatibility between libxml2's xmlReader memory semantics and Ruby's garbage collector. Although this method continues to exist for backwards compatibility, it is unsafe to call and may segfault. This method will be removed in a future version of Nokogiri, and callers should use #attribute_hash instead. [#2598]

    Improvements

    • XML::Reader#attribute_hash is a new method to safely retrieve the attributes of a node from XML::Reader. [#2598, #2599]

    Fixed

    ... (truncated)

    Changelog

    Sourced from nokogiri's changelog.

    1.13.9 / 2022-10-18

    Security

    Dependencies

    • [CRuby] Vendored libxml2 is updated to v2.10.3 from v2.9.14.
    • [CRuby] Vendored libxslt is updated to v1.1.37 from v1.1.35.
    • [CRuby] Vendored zlib is updated from 1.2.12 to 1.2.13. (See LICENSE-DEPENDENCIES.md for details on which packages redistribute this library.)

    Fixed

    • [CRuby] Nokogiri::XML::Namespace objects, when compacted, update their internal struct's reference to the Ruby object wrapper. Previously, with GC compaction enabled, a segmentation fault was possible after compaction was triggered. [#2658] (Thanks, @​eightbitraptor and @​peterzhu2118!)
    • [CRuby] Document#remove_namespaces! now defers freeing the underlying xmlNs struct until the Document is GCed. Previously, maintaining a reference to a Namespace object that was removed in this way could lead to a segfault. [#2658]

    1.13.8 / 2022-07-23

    Deprecated

    • XML::Reader#attribute_nodes is deprecated due to incompatibility between libxml2's xmlReader memory semantics and Ruby's garbage collector. Although this method continues to exist for backwards compatibility, it is unsafe to call and may segfault. This method will be removed in a future version of Nokogiri, and callers should use #attribute_hash instead. [#2598]

    Improvements

    • XML::Reader#attribute_hash is a new method to safely retrieve the attributes of a node from XML::Reader. [#2598, #2599]

    Fixed

    • [CRuby] Calling XML::Reader#attributes is now safe to call. In Nokogiri <= 1.13.7 this method may segfault. [#2598, #2599]

    1.13.7 / 2022-07-12

    Fixed

    XML::Node objects, when compacted, update their internal struct's reference to the Ruby object wrapper. Previously, with GC compaction enabled, a segmentation fault was possible after compaction was triggered. [#2578] (Thanks, @​eightbitraptor!)

    Commits
    • 897759c version bump to v1.13.9
    • aeb1ac3 doc: update CHANGELOG
    • c663e49 Merge pull request #2671 from sparklemotion/flavorjones-update-zlib-1.2.13_v1...
    • 212e07d ext: hack to cross-compile zlib v1.2.13 on darwin
    • 76dbc8c dep: update zlib to v1.2.13
    • 24e3a9c doc: update CHANGELOG
    • 4db3b4d Merge pull request #2668 from sparklemotion/flavorjones-namespace-scopes-comp...
    • 73d73d6 fix: Document#remove_namespaces! use-after-free bug
    • 5f58b34 fix: namespace nodes behave properly when compacted
    • b08a858 test: repro namespace_scopes compaction issue
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies ruby 
    opened by dependabot[bot] 0
  • FIX: mesos rpm add command and change mesos_isolation.

    FIX: mesos rpm add command and change mesos_isolation.

    This PR will fix two failures.

    1. During the building of the docker base image, it could not find the rpm file of mesos.
    2. The mesos-agent didn't start. I had to change the mesos_isolation definition.

    With these two changes, mesos-mini is working again.

    opened by andreaspeters 0
  • Ensure that long CNI labels are short enough

    Ensure that long CNI labels are short enough

    Apparently this is an implicit limitation on the maximum length of network labels, enforced by the k8s apimachinery library that various CNI plugins use for their API abstraction.

    The maximum allowed length is 63 characters. Therefore, in order for us to be able to maximize the amount of information preserved, I am proposing the following solution for long labels:

    MD5(<label>)[0:7] + "~" + <label>[sizeof(<label>)-53:]
    

    For example:

    /teams/backend-services/database-service/deployments/development/tag-1.12-dev
    

    Becomes:

    df1d656~database-service/deployments/development/tag-1.12-dev
    
    opened by wavesoft 0
  • MESOS-9499 extended URI syntax to support any Zookeeper authentication schemes

    MESOS-9499 extended URI syntax to support any Zookeeper authentication schemes

    Zookeeper URL now optionally can have syntax: zk://zk_auth_scheme!zk_auth_data@host:port/path

    If there is no "!" in URL it works as before with digest auth scheme.

    For example, I use it with our Zk auth plugin like this: zk://simple!login:[email protected]:2181/mesos Here "simple" is an authentication scheme name.

    opened by dlazarus 3
Owner
The Apache Software Foundation
The Apache Software Foundation
Netflix, Inc. 23.1k Jan 5, 2023
Zuul is a gateway service that provides dynamic routing, monitoring, resiliency, security, and more.

Zuul Zuul is an L7 application gateway that provides capabilities for dynamic routing, monitoring, resiliency, security, and more. Please view the wik

Netflix, Inc. 12.4k Jan 3, 2023
Distributed Stream and Batch Processing

What is Jet Jet is an open-source, in-memory, distributed batch and stream processing engine. You can use it to process large volumes of real-time eve

hazelcast 1k Dec 31, 2022
A reactive Java framework for building fault-tolerant distributed systems

Atomix Website | Javadoc | Slack | Google Group A reactive Java framework for building fault-tolerant distributed systems Please see the website for f

Atomix 2.3k Dec 29, 2022
APM, (Application Performance Management) tool for large-scale distributed systems.

Visit our official web site for more information and Latest updates on Pinpoint. Latest Release (2020/01/21) We're happy to announce the release of Pi

null 12.5k Dec 29, 2022
Orbit - Virtual actor framework for building distributed systems

Full Documentation See the documentation website for full documentation, examples and other information. Orbit 1 Looking for Orbit 1? Visit the orbit1

Orbit 1.7k Dec 28, 2022
Vert.x is a tool-kit for building reactive applications on the JVM

Vert.x Core This is the repository for Vert.x core. Vert.x core contains fairly low-level functionality, including support for HTTP, TCP, file system

Eclipse Vert.x 13.3k Jan 8, 2023
Apache Geode

Contents Overview How to Get Apache Geode Main Concepts and Components Location of Directions for Building from Source Geode in 5 minutes Application

The Apache Software Foundation 2.2k Dec 30, 2022
Apache ZooKeeper

Apache ZooKeeper For the latest information about Apache ZooKeeper, please visit our website at: https://zookeeper.apache.org and our wiki, at: https:

The Apache Software Foundation 11k Jan 6, 2023
Mirror of Apache Storm

Master Branch: Storm is a distributed realtime computation system. Similar to how Hadoop provides a set of general primitives for doing batch processi

The Apache Software Foundation 6.4k Dec 26, 2022
BitTorrent library and client with DHT, magnet links, encryption and more

Bt A full-featured BitTorrent implementation in Java 8 peer exchange | magnet links | DHT | encryption | LSD | private trackers | extended protocol |

Andrei Tomashpolskiy 2.1k Jan 2, 2023
Fault tolerance and resilience patterns for the JVM

Failsafe Failsafe is a lightweight, zero-dependency library for handling failures in Java 8+, with a concise API for handling everyday use cases and t

Jonathan Halterman 3.9k Dec 29, 2022
Fibers, Channels and Actors for the JVM

Quasar Fibers, Channels and Actors for the JVM Getting started Add the following Maven/Gradle dependencies: Feature Artifact Core (required) co.parall

Parallel Universe 4.5k Dec 25, 2022
Resilience4j is a fault tolerance library designed for Java8 and functional programming

Fault tolerance library designed for functional programming Table of Contents 1. Introduction 2. Documentation 3. Overview 4. Resilience patterns 5. S

Resilience4j 8.5k Jan 2, 2023
a blockchain network simulator aimed at researching consensus algorithms for performance and security

Just Another Blockchain Simulator JABS - Just Another Blockchain Simulator. JABS is a blockchain network simulator aimed at researching consensus algo

null 49 Jan 1, 2023
Simple and lightweight sip server to create voice robots, based on vert.x

Overview Lightweight SIP application built on vert.x. It's intended to be used as addon for full-featured PBX to implement programmable voice scenario

Ivoice Technology 7 May 15, 2022
Cluster manager for Apache Doris

Apache Doris (incubating) Manager The repository contains Manager for Apache Doris (incubating) License Apache License, Version 2.0 Report issues or s

The Apache Software Foundation 96 Jan 4, 2023