1. 27 Dec, 2019 1 commit
  2. 15 Nov, 2019 4 commits
  3. 14 Nov, 2019 1 commit
  4. 13 Nov, 2019 1 commit
  5. 12 Nov, 2019 1 commit
  6. 08 Nov, 2019 1 commit
  7. 30 Oct, 2019 1 commit
  8. 28 Oct, 2019 2 commits
  9. 26 Oct, 2019 1 commit
  10. 07 Oct, 2019 1 commit
    • Jérome Perrin's avatar
      grid: new shared_part_list config file option · 5cbd70bc
      Jérome Perrin authored
      This new option for slapos.cfg allow to define a list of paths to use
      for shared parts feature of `slapos.recipe.cmmi`.
      This will be injected in the buildout profile used to install software,
      as `${buildout:shared-part-list}` which is the option `slapos.recipe.cmmi`
      use since 0.11.
      
      Note that the option changed in `slapos.recipe.cmmi` because this was
      incompatible. In 0.10, the option was named `${buildout:shared-parts}` and
      it was supposed to be a single path. `slapos.recipe.cmmi` 0.10 was trying
      to create this path. If we continued using this `${buildout:shared-parts}`
      option and changed to passe a newline-separated list of paths, then
      `slapos.recipe.cmmi` would just create one directory with \n in the name
      and will probably fail, which would make all software from 1.0.73 to 1.0.121
      not installable on next `slapos.core`, so we used another buildout option
      to prevent this problem.
      
      Because generally, profiles using slapos.recipe.cmmi 0.10 were not
      "safely" shared, we don't even provide compatibility with old option.
      
      /reviewed-on !46
      5cbd70bc
  11. 25 Sep, 2019 1 commit
  12. 06 Aug, 2019 1 commit
  13. 01 Aug, 2019 1 commit
  14. 31 Jul, 2019 1 commit
  15. 25 Jun, 2019 1 commit
  16. 03 May, 2019 1 commit
  17. 06 Mar, 2019 2 commits
  18. 04 Mar, 2019 1 commit
  19. 15 Feb, 2019 1 commit
  20. 08 Feb, 2019 1 commit
  21. 06 Feb, 2019 2 commits
  22. 05 Feb, 2019 2 commits
    • Alain Takoudjou's avatar
      1213a413
    • Alain Takoudjou's avatar
      grid.promise: add support for promise without test or anomaly · 1dba7a89
      Alain Takoudjou authored
      Support for promise test-less or anomaly-less allow to disable either the test phase or the anomaly phase.
      
      by default, test and anomaly are enabled. Test will run when buildout is processing the computer partition, and anomaly when the partition is processed.
      
      Call `self.setTestLess()` in __init__.py of the promise will disable Test and set `__is_tested = False`. Call `self.setAnomalyLess()` will rather disable Anomaly and set `__is_anomaly_detected = False`.
      
      If the promise is test less, then slapgrid will not run the promise while processing the partition which mean that the promise will not report error, only Anomaly will be checked. Samething, if promise is anomaly less, only test will run when slapgrid is processing the partition.
      1dba7a89
  23. 28 Dec, 2018 3 commits
  24. 14 Dec, 2018 1 commit
  25. 26 Nov, 2018 1 commit
  26. 28 Sep, 2018 1 commit
    • Bryton Lacquement's avatar
      slapgrid-sr: do not rebootstrap unnecessarily · 7f279836
      Bryton Lacquement authored
      Currently, bootstrapBuildout is called unconditionally, and since
      Software Releases use slapos.reboostrap, we end up with the
      following behaviour in the best case:
      
          Processing software releases...
          Installing software release /srv/slapgrid/slappart9/srv/testnode/aai/software.cfg...
          Generated script '/srv/slapgrid/slappart9/srv/testnode/aai/soft/08f8010370c519147fe23fed3170be9e/bin/buildout'.
          slapos.rebootstrap: Make sure that the section 'python2.7' won't be reinstalled after rebootstrap.
          Unused options for buildout: 'allowed-eggs-from-site-packages' 'exec-sitecustomize' 'include-site-packages' 'unzip'.
          Updating xz-utils.
          Updating patch.
          ...
          Updating gcc.
          Updating python2.7.
          Stripping binaries ...
          Done.
          slapos.rebootstrap:
          ************ REBOOTSTRAP: IMPORTANT NOTICE ************
          bin/buildout is being reinstalled right now, as new python:
            /srv/slapgrid/slappart9/srv/testnode/aai/soft/08f8010370c519147fe23fed3170be9e/parts/python2.7/bin/python2.7
          is available, and buildout is using another python:
            /opt/slapgrid/b9f9e0967ab8491759399f306d65239a/parts/python2.7/bin/python2.7
          Buildout will be restarted automatically to have this change applied.
          ************ REBOOTSTRAP: IMPORTANT NOTICE ************
      
          Unused options for buildout: 'allowed-eggs-from-site-packages' 'exec-sitecustomize' 'include-site-packages' 'unzip'.
          Updating xz-utils.
          Updating patch.
          ...
          Updating gcc.
          Updating python2.7.
          Updating autoconf.
          ...
      
      Which means that bin/buildout always runs twice: updating parts is usually fast
      but loading extends and checking that binaries are stripped can take a while.
      
      The idea of this commit is minimize the amount of work when bin/buildout
      already exists, in particular if it is already changed by slapos.reboostrap
      to use the built Python. We also hope this will avoid complete rebuilds when
      building a different version of Python:
      
          Installing software release /srv/slapgrid/slappart1/srv/testnode/bsu/software.cfg...
          Generated script '/srv/slapgrid/slappart1/srv/testnode/bsu/soft/90adf14823b5e2bc7dd89ccfbd9388df/bin/buildout'.
          slapos.rebootstrap: Make sure that the section 'python3.5' won't be reinstalled after rebootstrap.
          Uninstalling python3.5.
          Uninstalling file.
          Uninstalling file-msooxml.
          Uninstalling gettext.
          Uninstalling lunzip.
          Uninstalling libxml2.
          Uninstalling sqlite3.
          Uninstalling openssl.
          Uninstalling ca-certificates.
          Uninstalling perl.
          Uninstalling gdbm.
          Uninstalling bzip2.
          Uninstalling libffi.
          Uninstalling libexpat.
          Uninstalling readline.
          Uninstalling ncurses.
          Uninstalling zlib.
          Uninstalling patch.
          Uninstalling xz-utils.
          Unused options for buildout: 'allowed-eggs-from-site-packages' 'exec-sitecustomize' 'include-site-packages' 'unzip'.
          Installing xz-utils.
          ...
          Stripping binaries ...
          Done.
          slapos.rebootstrap:
          ************ REBOOTSTRAP: IMPORTANT NOTICE ************
          bin/buildout is being reinstalled right now, as new python:
            /srv/slapgrid/slappart1/srv/testnode/bsu/soft/90adf14823b5e2bc7dd89ccfbd9388df/parts/python3.5/bin/python3.5
          is available, and buildout is using another python:
            /opt/slapgrid/b9f9e0967ab8491759399f306d65239a/parts/python2.7/bin/python2.7
          Buildout will be restarted automatically to have this change applied.
          ************ REBOOTSTRAP: IMPORTANT NOTICE ************
      
          Uninstalling template.
          ...
          Uninstalling m4.
          Unused options for buildout: 'allowed-eggs-from-site-packages' 'exec-sitecustomize' 'include-site-packages' 'unzip'.
          Updating xz-utils.
          ...
          Updating python3.5.
          Installing m4.
          ...
      
      About the implementation, we could merely add a `if not os.path.exists(...):`.
      I fear cases where a previous run may have left bin/buildout in a non-working
      state, so I suggest the use of a marker to force bootstrap if a previous run
      failed whereas the existing bin/buildout was reused.
      
      /reviewed-on !54
      7f279836
  27. 24 Aug, 2018 2 commits
  28. 21 Aug, 2018 1 commit
  29. 20 Jul, 2018 1 commit
    • Rafael Monnerat's avatar
      API Change: Remove available/building API from Computer Partition · 9fdaa54d
      Rafael Monnerat authored
        The API that notify availability and building from Computer Partition is unecessary and it's
        implementation overuse resources and cause flaky effect on the state of the Computer Partition.
      
        At the Software Release, the states can be available/building/error, and this state tens to be
        immutable once the software release is finished (it will be available, where building and error are
        transitory states).
      
        At Computer Partition, we intent to have started/stopped/destroyed instances, where available and
        building were transitory, but they have no practical function as a second report would come quickly
        after. So we may consider that started is actually same as available, in this case, it is a duplicated
        meaning, as you cannot be available w/o been started/stopped.
      
        computer_partition.building were never used, as the master knew that a partition is been processed,
        so this API were never used.
      
        Report transitory states are prevent us to determinate the actuall state, considering that the latest
        actuall state is more relevant (started/stopped/destroyed).
      9fdaa54d
  30. 05 Jul, 2018 1 commit