An error occurred fetching the project authors.
  1. 15 Oct, 2018 1 commit
  2. 29 Aug, 2018 1 commit
  3. 19 May, 2018 1 commit
  4. 22 Feb, 2018 2 commits
  5. 21 Feb, 2018 1 commit
  6. 13 Feb, 2018 1 commit
  7. 17 Nov, 2017 1 commit
  8. 05 Nov, 2017 1 commit
  9. 30 Oct, 2017 1 commit
  10. 11 Oct, 2017 1 commit
  11. 21 Aug, 2017 1 commit
  12. 19 Jul, 2017 1 commit
  13. 22 Jun, 2017 1 commit
  14. 21 Jun, 2017 1 commit
  15. 20 Apr, 2017 1 commit
    • Rafael Monnerat's avatar
      slapos-master: Follow up recent changes on erp5 stack · c9a3ff91
      Rafael Monnerat authored
        Apply commits:
         stack.erp5: Drop unneeded executable permissions. (fe7ea950)
         stack.logrotate: Fix support for stopped processes.
         stack.erp5: Use an iterator to produce port numbers.
         software/erp5: if wendelin-core-zblk-fmt is not given, then use wendelin.core's default.
         software/erp5 & stack/erp5: Add a new parameter wendelin-core-zblk-fmt.
      c9a3ff91
  16. 26 Oct, 2016 1 commit
    • Kirill Smelkov's avatar
      erp5: jupyter.enable is boolean, not string · 02900123
      Kirill Smelkov authored
      When originally in 0a446263 (ERP5 and Jupyter integrated together) I added
      Jupyter support into ERP5 the parameter for whether to enable/disable it was
      declared as boolean in JSON schema but processed as string in instance code,
      this way preventing usage of real JSON's boolean.
      
      Fix it.
      
      (also fixing up software/slapos-master/ which copied the files for play in 87d13789)
      
      /noticed-by @vpelletier (on nexedi/slapos!43)
      02900123
  17. 18 Feb, 2016 1 commit
  18. 16 Feb, 2016 2 commits
  19. 01 Feb, 2016 1 commit
    • Kirill Smelkov's avatar
      ERP5 and Jupyter integrated together · 0a446263
      Kirill Smelkov authored
      This patch teaches ERP5 software release to automatically instantiate Jupyter
      notebook web UI and tune it to connect to ERP5 by default. When Jupyter is
      enabled, it also installs on-server erp5_data_notebook bt5 (nexedi/erp5!29)
      which handles code execution requested for Jupyter.
      
      For ERP5 - for security and backward compatibility reasons - Jupyter
      instantiation and erp5_data_notebook bt5 install happen only if jupyter is
      explicitly enabled in instance parameters. The default is not to have Jupyter
      out of the box.
      
      On the other hand for Wendelin SR, which inherits from ERP5 SR, the
      default is to have Jupyter out of the box, because Wendelin SR is fresh
      enough without lots of backward compatibility needs, and Jupyter is
      usually very handy for people who use Wendelin.
      
      ~~~~
      
      For integration, we reuse already established in ERP5 infrastructure, to
      request various slave instances, and request Jupyter in a way so it
      automatically tunes and connects to balancer of one of Zope family.
      
      Jupyter code itself is compiled by reusing
      software/ipython_notebook/software.cfg, and Jupyter instance code is
      reused by hooking software/ipython_notebook/instance.cfg.in into ERP5 SR
      properly (the idea to override instance-jupyter not to render into
      default template.cfg is taken from previous work by @tiwariayush).
      
      ~~~~
      
      I tested this patch inside webrunner with create-erp5-site software type and
      various configurations (whether to have or not have jupyter, to which zope
      family to connect it, etc).
      
      I have not tested frontend instantiation fully - because tests were done only
      in webrunner, but I've tried to make sure generated buildout code is valid for
      cases with frontend.
      
      NOTE the code in this patch depends erp5_data_notebook bt5 (nexedi/erp5!29) which just got merged to erp5.git recently (see nexedi/erp5@f662b5a2)
      
      NOTE even when erp5_data_notebook bt5 is installed, on a freshly installed ERP5, it
      is required to "check site consistency" first, so that initial bt5(s) are
      actually installed and erp5 is ready to function.
      
      /cc @vpelletier, @Tyagov, @klaus, @Camata, @tiwariayush, @Kreisel, @jerome, @nexedi
      /proposed-for-review-on nexedi/slapos!43
      0a446263
  20. 01 Dec, 2015 1 commit
  21. 05 Oct, 2015 1 commit
  22. 02 Oct, 2015 1 commit
  23. 24 Aug, 2015 2 commits
    • Vincent Pelletier's avatar
      erp5: Rework postfix integration. · 86295f82
      Vincent Pelletier authored
      Add support for "hosts" aliasing in Zope instances.
      Add support for SASL relayhost with mandatory TLS encryption.
      Add mandatory TSL + SASL authentication, to not be an open relay.
      Wrap postfix commands with proper environment instead of symlink +
      source-able script.
      Add ipv6 listening support (untested).
      Drop non-required main.cf configuration options.
      Make postifx instance optional (requires postmaster address to be
      provided).
      Document and rework smtp-related parameters.
      Expose an userhosts hostname for smtp server.
      Add diversion support (solution to "prod clone sent mails to real customer").
      Use etc/run rather than etc/service, for consistency (if it needs to be
      changed, it must be changed for all software types).
      Hook into syslog and setup local syslog daemon, with logrotate integration.
      Update TODO entries.
      86295f82
    • Marco Mariani's avatar
      48672684
  24. 17 Jul, 2015 1 commit
    • Saurabh's avatar
      Published parameters as simple storage for generated passwords and NEO cluster name · 836309f4
      Saurabh authored
      For performance reasons, the root partition requests subpartitions during
      initialization of sections, whereas such processing should normally be done
      during the update/install phase.
      
      The consequence is that partitions may be requested whereas they depend on
      sections that fail (usually just temporarily, because of missing returned
      parameters in the first runs).
      
      For example, the request of zope partitions depends on the generation of
      passwords:
      
      1. password generated (__init__)
      2. zope partitions requested (__init__)
      3. password saved (install)
      
      As long as a failure happens between 2 and 3, zope parameters are always
      updated with a different password.
      
      In the case of NEO, the instanciation of zope partitions currently succeeds even
      if the list of master nodes is missing (note that there is a minor bug to fix
      here: whenever a NEO storage is not the main one, zope processes may start too
      early, and the user may have to restart zopes manually). The 'inituser_done'
      file is created but zope processes fail to start if NEO is used as main storage,
      and all this happens before the password was saved in the root partition
      ([neo-0-final] failing to install because 'admins' parameter returned yet).
      
      This was never an issue with ZEO because zopes start successfully at the same
      time the 'inituser_done' file is created.
      
      One way to solve this could have been to introduce a dummy dependency between
      [neo-0-final] and any other section generating a password. Quite ugly and we
      also found non-optimal to use a non-backuped file in the root partition to save
      such information, whereas we need anyway to publish them for the user.
      
      Therefore, we introduce a new 'publish-early' recipe for accessing and
      publishing desired parameters before any request of partitions. Of course,
      these must not be dropped by the usual [publish] section, and to avoid having
      to repeating them all manually, we have also added a '-extends' option to the
      'publish' recipe.
      
      We use the same technique to autogenerate and configure cluster name for NEO,
      which helps us in minimizing the number of params one has to pass for
      requesting NEO.
      
      In the 'generate.password' recipe, the 'storage-path' can now be empty, when
      there's no need to save the generated password in a file.
      836309f4
  25. 08 Jul, 2015 1 commit
    • Saurabh's avatar
      Make it possible to instanciate 1 NEO DB inside an ERP5 instance · d35284d8
      Saurabh authored
      Before it was only possible to make an ERP5 cluster connect to a NEO cluster
      that was instanciated separately, by passing "name" and "master_nodes"
      connection parameters in "storage-dict".
      
      For an internal NEO DB, "name" and "master_nodes" is filled automatically
      and you must instead pass a "server" dict, with same parameters as in NEO SR.
      Currently, a NEO cluster name must be given. Later, we hope to generate a good
      name automatically.
      
      All this was implemented by refactoring NEO & ERP5 SR, with common files.
      For the ERP5 SR, the root partition also serves as "root" partition for NEO
      partitions: in other words, there's no second empty partition.
      d35284d8
  26. 25 Jun, 2015 1 commit
  27. 11 Jun, 2015 1 commit
  28. 01 Jun, 2015 1 commit
  29. 22 Apr, 2015 1 commit
    • Vincent Pelletier's avatar
      erp5: Use the same default value for thread amount as Zope's. · b1a6c8e6
      Vincent Pelletier authored
      One thread is just too limited to produce a usable instance (for example,
      a single-zope setup with default thread count fails to run live tests). It
      is also not an advised setting for activity nodes, because of timerserver
      still queuing process_timer calls while CMFActivity is busy processing; the
      result being a (limited) waste of memory, and hammering mysql after long
      processing periods.
      Zope's default value must be duplicated because thread-amount is also used
      to generate haproxy configuration file (so just not providing the value in
      Zope's configuration file is wrong).
      b1a6c8e6
  30. 19 Feb, 2015 1 commit
  31. 18 Feb, 2015 1 commit
  32. 09 Dec, 2014 1 commit
    • Julien Muchembled's avatar
      erp5: review request parameters for SLA & ZODB · a2ba55e0
      Julien Muchembled authored
      All parameters about SLA, i.e. computer-guid & instance-guid, are removed in
      favor of a new "sla-dict" parameter, which is easier to implement and much more
      versatile.
      
      All changes in the request parameters are incompatible. The old ones are
      ignored without warning/error.
      
      For compatibility, the reference of ZEO partition is still "zodb".
      
      Default settings were also fine. Default name of mount-point and FileStorage
      file is reverted to 'root' instead of 'main'.
      a2ba55e0
  33. 18 Nov, 2014 2 commits
    • Julien Muchembled's avatar
      Make ERP5 instantiable with an external NEO storage · a546487f
      Julien Muchembled authored
      In order not to conflict with a future integration of NEO in ERP5:
      - the input schema has a new parameter for external storages.
      - zodb-software-type & zodb is used only for internal storages
        and only ZEO is supported.
      
      NEO logging is also enabled for clients.
      a546487f
    • Julien Muchembled's avatar
      New recipe 'switch-softwaretype' deprecating 'softwaretype' · 7ece1a48
      Julien Muchembled authored
      The inline recipe for ERP5 has been improved and converted into recipe,
      which is reused for NEO.
      
      Templates are instanciated only if they're used, so no need anymore to
      wrap them with:
      
        {% if slap_software_type == software_type -%}
        ...
        {% endif %}
      7ece1a48
  34. 28 Aug, 2014 3 commits