Open Stack

Hello,

Thank you all for joining our PTG session !
It was really nice to meet some of the team members in person.

The etherpad for the discussion can be found in the link below, but
I'll share a summary of our discussions in this email. In case you have
any questions/concerns then feel free to let me know.
https://etherpad.opendev.org/p/vancouver-june2023-puppet-openstack


   - Status update
      - We share the status of each person.
      - Unfortunately all of the members attending the discussion have
      limited resources especially for development
      - *Agreement:* we focus on priorities and de-prioritize items which
      does not cause immediate problems/breackages
      - *Agreement: *we ensure we finish the prioritized items in a
      specific release to keep our maintenance simple

      - Puppet 8 support
      - We added unit/lint tests with Puppet 8 for early testing, but
      adding integration tests is currently blocked
      by some ruby dependencies not yet available for Ruby 3.1 which is
      required by Puppet 8.
      - All of the operating system versions do not provide Ruby 3.1 now
      - Puppet 7 EOL is not yet declared
      - *Agreement*: We leave this as non-priority for now and re-work on
      it once Ruby 3.1 is globally available

      - Adaptation to puppetlab-stdlib 9.0.0
      - Some deprecated items were removed. We adapted our modules but are
      still waiting for update
      in the dependent modules
      - validate_legacy was deprecated and causes large warning no*w*
      - Functions from stdlib should be now namespace-d to avoid warnings
      after bump is done
      - *Agreement:* We prioritize replacing validate_legacy by typed
      parameters
      - *Agreement*: We pin stdlib to an older version for now but attempt
      to bump it early

      - Module modernizations
      - Typed parameters
         - Replacing validate_legacy needs to be prioritized now to adapt
         to puppetlab-stdlib 9.0.0
         - Implementing type validations for openstack config options
         require further discussions.
         Handling of os_service_defualt would be the main topic we have to
         sort
         - We prefer consistent implementations for all openstack service
         modules, while we can attempt
         some changes early in a few "independent" modules such as extras,
         vswitch, qdr
         - *Agreement: *We de-prioritize implementing validations for
         config options
         - *Agreement: *We ensure implementations is distributed to all
         modules consistently in a single release

         - Hieradata
         - This is "modern" design pattern, and it's ideal to replace
         legacy params class by it
         - However we don't have urgent requirement to complete this work
         - We have to create the common structure for hieradata files
         maintained in each repositories
         - Some concerns have been raised mainly how we can pick up some
         values once this change is made
         - *Agreement: *We de-prioritize this work for now
         - *Agreement: *We can start with the flat files (pattern 1 in
         https://etherpad.opendev.org/p/puppet-hieradata-structure )
         - *Agreement: *tkajinam will submit a few examples and we review
         how this impact the existing usage
         - *Agreement: *Similarly to typed parameters, we should coordinate
         this work to make the change consistently

         - Making distro/version specific logic selectable by parameters
         - This work is tightly related to the hieradata work
         - *Agreement: *We basically leave this work until the above
         hieradata work is completed, and de-prioritize this.

         - Branch retirements
      - We have multiple branches open now and aim to reduce number of
      branches
      - Red Hat is interested in keeping train open until 2023Q3
      (tentative) and wallaby for some times for donwstream
      - Others do not have requirement to maintain old releases in EM status
      - *Agreement: *We aim to retire train/ussuri/branch after 2023Q3.
      Retiring further branches is subject to future discussions


Thank you,
Takashi Kajinami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230619/6dec2007/attachment.htm>