1. 03 Jan, 2020 1 commit
    • fixup! glib: put the expected python in $PATH · 77d9f997
      The OS may not have Python (slapos-node package does not depend
      on any version of Python). Another possible issue was found on Suse:
      
        make[3]: Entering directory '.../parts/glib__compile__/glib-2.56.4/gio'
          GEN      gdbus-daemon-generated.c
        Traceback (most recent call last):
          File "./gdbus-2.0/codegen/gdbus-codegen.in", line 53, in <module>
            from codegen import codegen_main
          File ".../parts/glib__compile__/glib-2.56.4/gio/gdbus-2.0/codegen/codegen_main.py", line 30, in <module>
            from . import parser
          File ".../parts/glib__compile__/glib-2.56.4/gio/gdbus-2.0/codegen/parser.py", line 23, in <module>
            import xml.parsers.expat
        ImportError: No module named xml.parsers.expat
      Julien Muchembled committed
  2. 02 Dec, 2019 1 commit
  3. 29 Nov, 2019 1 commit
  4. 25 Nov, 2019 2 commits
  5. 22 Nov, 2019 2 commits
  6. 19 Nov, 2019 1 commit
  7. 13 Nov, 2019 1 commit
    • slaprunner: parameterize the shared folder · 70a97144
      In test nodes we put the software_root folder out of the webrunner so we
      can keep it for the following tests. Except that the shared folder has
      been introduced by default recently, and it is still inside the webrunner.
      
      Thus, between 2 tests the webrunner is deleted, so the shared parts are too,
      but not the SR folder (which is marked as completed). Then in the successive tests
      the software release fails to build, or the insances fail to isntanciate.
      Nicolas Wavrant committed
  8. 08 Nov, 2019 1 commit
    • resilient: add prefix to a published parameter · d6615b72
      In 95c05120, a published parameter "ssh-url" was added
      to the webrunner, clashing with the existing "ssh-url" parameter used by the resilient
      stack (which is extended by webrunner).
      As the new "ssh-url" is public and read by customers, it doesn't make sense to rename
      it to something more slaprunner-ished, more especially it already existis "ssh-command",
      so if a second parameter was named "runner-ssh-url" it wouldn't make sense to the user...
      
      This change had to be propagated to all the software releases extending the resilient stack.
      
      Finally, I think that stacks should use namespaces to avoid conflicts with the software
      releases extending them. Currently, we are doing the opposite and are using namespaces
      for software release to avoid conflicting with their stack : for exemple, in stack/resilient
      we have a section [sshd-raw-server] and in the software/slaprunner we have [runner-sshd-raw-server].
      This situation will create clashes when one software release extends 2 stacks, as nothing
      guarantees that 2 stacks have no conflicting section name, config file path, ...
      Nicolas Wavrant committed
  9. 30 Oct, 2019 7 commits
  10. 09 Oct, 2019 1 commit
  11. 07 Oct, 2019 1 commit
  12. 04 Oct, 2019 1 commit
    • do not create two wrappers for the same executable if hash change · ed707d3b
      Prevent creating 2 wrapper for the same service if hash changed. Here, one service is exited because port is used by the firt to service to start:
      
          slappart6:runner-sshd-4248650e36a9a26a6481df1baffd9f58-on-watch                RUNNING   pid 27835, uptime 0:03:45
          slappart6:runner-sshd-b3b68f4278ceb84691ec27521ea229eb-on-watch                EXITED    Mar 06 04:52 PM
      
      To achieve that, update slapos.cookbook and use hash-existing-files option of wrapper recipe
      
      hash-existing-files list all the files used for hash that are not
      handled by buildout. For those files, the hash is calculated as soon as
      the __init__ function so that if there is a change in those files,
      buildout will remove the existing wrapper (it will uninstall the
      section) and replace it with the new wrapper.
      
      /reviewed-on nexedi/slapos!525
      Thomas Gambier committed
  13. 09 Sep, 2019 1 commit
  14. 05 Sep, 2019 1 commit
  15. 11 Jul, 2019 1 commit
  16. 24 Jun, 2019 1 commit
  17. 17 Jun, 2019 2 commits
  18. 26 Mar, 2019 1 commit
  19. 11 Mar, 2019 1 commit
  20. 05 Mar, 2019 1 commit
  21. 21 Jan, 2019 1 commit
  22. 10 Jan, 2019 1 commit
  23. 07 Jan, 2019 1 commit
  24. 20 Dec, 2018 1 commit
  25. 07 Dec, 2018 1 commit
  26. 03 Dec, 2018 1 commit
  27. 14 Nov, 2018 2 commits
  28. 13 Nov, 2018 1 commit
  29. 26 Oct, 2018 1 commit
  30. 24 Oct, 2018 1 commit