1. 27 Mar, 2024 5 commits
    • Romain Courteaud's avatar
      slapos_cloud: add virtual master concept · a22f28a8
      Romain Courteaud authored
      Drop the allocation scope open/subscription/public logic.
      
      Instead, use Project as Virtual Master, and force
      all slapos_cloud object to be linked to one Project:
      * every Compute Node is linked to a Project
      * any Project's Instance can be allocated on a Project's Compute Node
      
      Allocation is managed by configuring an Allocation Supply document,
      which defined on which Compute Node a Software Product can be allocated.
      
      User are not allowed anymore to change the release/type/shared state of their Instance Tree.
      
      Managing Compute Node is done on the virtual master level, and so,
      there is no need to define any Compute Node administrator.
      
      A Software Product is a variated resource with 2 axes: software release url and softare type.
      
      Slave Instance are now allocated on Instance Node, which is created
      from the Software Instance which will control the configuration.
      Slave Instance allocation is also controlled by an Allocation Supply,
      which allow separating the Software Instance and Slave Instances versions.
      
      There could be any number of virtual master in the system.
      Every virtual master defines its own Software Products.
      Because of this, it is not possible to change a document's virtual master
      after its creation.
      
      Instance request can be propagated on another virtual master, by
      allocating them on a Remote Node document, which will generate
      a new Instance Tree request on another virtual master.
      
      Also in this commit:
      * trigger alarms as soon as possible with interaction workflow
        which allows to reduce some alarms frequency
      * drop never used Organisation logic
      * drop person.requestSite
      * drop audit_validation_workflow
      * drop ComputePartition_getCustomAllocationParameterDict
        This is a hack incompatible with virtual master standalone logic.
      * drop cloud contract
      * do not sort security base category when generating local roles
        Otherwise, it is not possible to ensure source_section/function and destination/function generate the same local role
      * stop using hardcoded currency/organisation/trade condition/business process
      * drop templates usages
      * add One Time Virtual Master Access Token portal type
        Needed for compatibility with the compute node deploy script
      a22f28a8
    • Romain Courteaud's avatar
      slapos_category: · 6f11cc66
      Romain Courteaud authored
      * add new business application categories
      * export edger category
      * automated ledger is not only for accounting
      * drop allocation_scope/open categories
        All compute nodes are public now
      * add use/trade/deposit category
      * do not use the same title for 2 categories
      * Add trade condition type categories.
        This will be used to automatically select a Trade Condition in slapos_accounting
      * add invoicing taxable vat categories
      6f11cc66
    • Romain Courteaud's avatar
    • Romain Courteaud's avatar
    • Romain Courteaud's avatar
      slapos_mysql_innodb_catalog: drop not needed related keyes · b930e1ef
      Romain Courteaud authored
      * drop default_or_child_aggregate_reference
      * drop default_or_child_aggregate_uid catalog key
      * drop follow_up_default_or_child_aggregate_uid
      * drop causality_subscription_request_related_uid related key
      b930e1ef
  2. 26 Mar, 2024 5 commits
  3. 25 Mar, 2024 1 commit
    • Rafael Monnerat's avatar
      slapos_cloud: Split edit in 2 · acff4533
      Rafael Monnerat authored
        This is required due interacton workflow call on _setAlloctionScope.
      
        We could change the capacity_scope to close (so allocation worklfow order dont matter, but
        it would change the expected behaviour if we drop the interaction workflow, so it is more
        reasonable keep the existing behaviour unchanged.
      acff4533
  4. 23 Mar, 2024 1 commit
  5. 22 Mar, 2024 6 commits
  6. 19 Mar, 2024 8 commits
  7. 15 Mar, 2024 2 commits
  8. 14 Mar, 2024 3 commits
  9. 13 Mar, 2024 1 commit
  10. 08 Mar, 2024 5 commits
  11. 06 Mar, 2024 1 commit
  12. 01 Mar, 2024 2 commits