1. 09 Jan, 2017 2 commits
  2. 30 Dec, 2016 2 commits
  3. 24 Nov, 2016 2 commits
  4. 15 Nov, 2016 1 commit
  5. 26 Oct, 2016 2 commits
  6. 12 Oct, 2016 1 commit
  7. 10 Oct, 2016 1 commit
  8. 27 Sep, 2016 1 commit
  9. 19 Sep, 2016 2 commits
  10. 15 Sep, 2016 1 commit
  11. 24 Jun, 2016 1 commit
  12. 23 Jun, 2016 8 commits
  13. 30 May, 2016 1 commit
  14. 23 May, 2016 2 commits
  15. 15 Apr, 2016 2 commits
  16. 27 Nov, 2015 2 commits
  17. 25 Nov, 2015 1 commit
  18. 27 Oct, 2015 2 commits
  19. 26 Oct, 2015 2 commits
  20. 17 Aug, 2015 1 commit
  21. 24 Jul, 2015 2 commits
  22. 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
      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.