Open Stack

On Mon, Apr 26, 2021 at 7:37 PM Marios Andreou <marios at redhat.com> wrote:
>
> Hello folks,
>
> I sent out some stats and links on our PTG meetup with
> http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021999.html
> already, but, as a couple of different people asked me about it, I
> took the time to write a summary for each session today. Of course you
> can find all etherpad links and recordings via
> https://etherpad.opendev.org/p/tripleo-ptg-xena (which seems to be
> down right now but I have backups if it isn't resolved by tomorrow I
> can try sharing that content somewhere else).
>
> Below is a (very) concise summary of the main points in each session
> and I hope that is useful to someone (especially since it took far
> longer than I expected ;)). Please reply here (or ping privately if
> you prefer) for any glaring omissions or obvious issues that should be
> revised (I originally intended to put this in an etherpad for easier
> collaboration but as I wrote above, etherpad.opendev.org seems down
> right now at least for me).

etherpad.opendev.org back now, so I pasted the summaries into
https://etherpad.opendev.org/p/tripleo-ptg-xena-summaries and linked
it via our agenda etherpad,

so, please help me to capture the "glaring omissions or obvious
issues" I have missed in the summary of your or others' sessions?

regards, marios


>
> regards, marios
>
> MON:
>
> * https://etherpad.opendev.org/p/tripleo-ptg-retrospective
>
> Retrospective of the Wallaby cycle - there are some community and team
> level 'headlines' on the main items worked on during this cycle on the
> etherpad.
> Some identified ideas for improvement include targeting another older
> branch for end-of-life likely Queens, improving upstream documentation
> especially removal of stale content, and creating a tag in Launchpad
> for teams so we can more easily identify which squad is currently
> assigned.
>
>  * Topic: Plan/Swift removal  update Presentation link:
> https://drive.google.com/file/d/1igOW4XuAbU55Tat73DwLqO4UGZu8MiNi/view?usp=sharing
>
> An update of the work completed in the W allay cycle to remove the
> Swift service and the deployment plan (which is no longer used as part
> of our deployments) from the undercloud. From wallaby onward by
> default there is no undercloud Swift. There may be a revision of the
> spec https://opendev.org/openstack/tripleo-specs/commit/e83d8aba3a950da83a33c23bcef6ffc38f00002f
> as the original plan didn't explicitly consider removal of the
> deployment plan.
>
> * https://etherpad.opendev.org/p/tripleo-ephemeral-heat
>
> Update  on the ephemeral heat work (i.e. no permanent heat process on
> the undercloud). There has been very strong progress made in this
> cycle and there are still some outstanding patches
> https://review.opendev.org/q/topic:%22ephemeral-heat%22+(status:open)
> to be merged. Goal is to make this the default in Xena deployments and
> backport to Wallaby as optional. Besides the main feature, some
> related planned work includes consolidation of the
> python-tripleoclient  "overcloud deploy" and "tripleo deploy" (eg
> standalone) commands. Note that this work depends on the
> tripleo-network-v2 work (next session below).
>
>
> * https://etherpad.opendev.org/p/tripleo-network-v2
>
> Update on the network ports v2 work (moving network port creation out
> of the heat stack)
> https://opendev.org/openstack/tripleo-specs/src/branch/master/specs/wallaby/triplo-network-data-v2-node-ports.rst
> - again good progress on this during Wallaby but there is still some
> ongoing work there
> https://review.opendev.org/q/topic:%2522network-data-v2%2522+(status:open)
> . The goal for Xena is to make this the default (i.e. no
> node/networking config in deploy-steps-playbook.yaml). One main area
> of work for X in this topic is integration of the baremetal network
> config in the overcloud deployment (i.e. allow a single command).
>
> * https://etherpad.opendev.org/p/tripleo-ceph-xena
>
> Update from the ceph team about the main work items completed in
> Wallaby including the tripleo-ceph-client and tripleo-ceph in place of
> ceph-ansible for RBD (
> https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/tripleo-ceph-client.html
> and https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/tripleo-ceph.html
> ). The main work planned for Xena is to continue trying to achieve
> feature parity with ceph-ansible - including resolving cephadm
> blockers, , Ganesha &
> https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/tripleo-ceph-ganesha.html
> . One major consideration is how to move ceph creation/config outside
> of the heat stack - some parts such as pools, keyrings and haproxy
> config will have to remain as part of the tripleo deployment. Note
> that this work depends on the network ports v2 (previous session
> above).
>
> TUE:
>
> * https://etherpad.opendev.org/p/tripleo-xena-whole-disk-images
>
> A proposal to move to whole disk images instead of the current
> overcloud-full.qcow+overcloud-full.initrd+overcloud-full.vmlinuz.
> There were many compelling arguments made for the proposal including:
> with the overcloud-full.qcow2 partition image, as of centos 8.4 grub2
> no longer supports UEFI boot, there will be much less for
> ironic-python-agent to do during deployment with a single disk image,
> there will be just one file to distribute (vs 3), we will no longer
> need to define and build a separate 'hardened' image (and also remove
> the related CI jobs). One of the main technical issues that needs to
> be addressed first is the grow partition for /var which is where we
> are storing containers and config for deployment.
>
> * https://etherpad.opendev.org/p/tripleo-xena-drop-healthchecks
>
> Proposal to drop the container health check since are using deployment
> resources but aren't providing value. There was no push back against
> this proposal and the details are being discussed in the newly posted
> spec @ https://review.opendev.org/c/openstack/tripleo-specs/+/787535.
>
> * https://etherpad.opendev.org/p/ci-tripleo-repos
>
> Proposal to consolidate the various ways and places that tripleo-ci is
> using to configure the repos in the CI jobs. There is a spec proposed
> @ https://review.opendev.org/c/openstack/tripleo-specs/+/772442 - some
> of the work here is split into sub items which are ongoing
> (tripleo-get-hash there
> https://review.opendev.org/c/openstack/tripleo-ci/+/784392). The main
> outstanding blocking item here is to agree on the common data format
> for the various personas upstream downstream and product that we need
> to support eg https://github.com/mwhahaha/rhos-bootstrap/blob/main/versions/centos.yaml
>  vs https://review.opendev.org/c/openstack/tripleo-repos/+/785593/1/tripleo_repos/conf/master.yaml
>
> * openstack tempest skiplist
> https://docs.google.com/presentation/d/1aCiV35IYNhPV7SRmi4_A9vkIjZ89pwfC4VvL6frFJNE/edit?usp=sharing
>
> Update on the tempest skiplist effort during Wallaby to consolidate
> the skipped Tempest tests in a central location with the ability to
> specify particular jobs and or branches for which specific skips will
> apply.
>
> * https://etherpad.opendev.org/p/tripleo-next
>
> One of the main items discussed here was the 'first principles'
> proposal at https://review.opendev.org/c/openstack/tripleo-specs/+/786980
> - these are meant to guide us when discussing changes to our
> deployment tooling and architecture. The proposal will merge in  Xena
> specs once we've reached consensus on the review. Another topic
> discussed in this session was an update on exploratory work to replace
> "heat & ansible" in our deployment tooling with 'something else' -
> some ongoing work here is at https://github.com/cloudnull/director  &
> https://github.com/mwhahaha/task-core. More info and pointers (also
> discussed Kube/OCP with an operator to deploy tripleo) on the
> etherpad.
>
> WED:
>
> * https://etherpad.opendev.org/p/tripleo-xena-inventory-script
>
> This was a proposal to remove the "tripleo-ansible-inventory script" @
> https://github.com/openstack/tripleo-common/blob/ccd990b58b6583dda3a0e0f34135ae343c833f70/tripleo_common/inventory.py#L744
> and instead generate it from the deployment data (e.g. metalsmith or
> user data from deployed-server deployments). The consensus reached was
> that instead of removing it we should instead use it in a better way,
> for example make sure static inventories are generated and exported to
> known locations (especially for the ephemeral heat case) and re-used.
>
> * https://etherpad.opendev.org/p/vf-ui-output
>
> This was an update from the validations squad about the main items
> worked on during Wallaby (integrated the validation framework into the
> component CI pipelines, enabled the standalone job in upstream
> check/gate and increased adoption especially by the upgrades squad).
> Followed by discussions for planned Xena work, including changes in
> the UI/CLI (eg jq queries can be handled better and various other UI
> improvements more on the etherpad). Some of the other topics raised
> here were to make the validations themselves component aware (run all
> validations related to a given component) and discussion around the
> requirement for a molecule test on all validation additions
> (especially the example of mocking out OpenStack services like
> keystone); the compromise could be to instead use a standalone job for
> such cases.
>
> * https://etherpad.opendev.org/p/Validation-Framework-Next-Generation
>
> In this session the validations squad introduced ideas for the future
> direction of the validation framework. Some of the main proposals are
> to remove the validations repos - validations-common and
> validations-libs out of tripleo governance but still within openstack
> and establishing a new validations project (discussion but no clear
> consensus on this point), to re-merge the two repos into one
> consolidated validations repo and fixup the CLI (see previous session)
> - more items and other considerations on the etherpad.
>
> * https://etherpad.opendev.org/p/tripleo-frr-integration
>
> Update on Wallaby progress from the cross-squad team looking at
> FRR/BGP integration in the tripleo deployment
> (https://opendev.org/openstack/tripleo-specs/src/branch/master/specs/wallaby/triplo-bgp-frrouter.rst).
> Some of the main items discussed for Xena work included how we might
> approximate some part of this feature in upstream CI (high resource
> requirements - downstream CI has 9 nodes) and backport considerations
> (no backport to upstream/train).
>
> * https://etherpad.opendev.org/p/update-upgrade-consolidation
>
> In this session the upgrades squad outlined their proposal for
> consolidation of the minor update and major upgrade workflows -
> without any blockers or objections coming out of the discussion. One
> of the main considerations was around how we can decouple the
> operating system updates/upgrades from the tripleo container upgrade -
> one action item is to de-containerize those containers that are tied
> to the kernel version (ABI) such as libvirt and openvswitch.
>
> THU:
>
> * https://etherpad.opendev.org/p/policy-popup-xena-ptg
>
> In this session the security squad gave an update on progress during
> Wallaby on the Role Based Access Control (RBAC) - many services have
> completed implementation (Keystone, Nova, Ironic  - more on the
> etherpad). Then there was a discussion around potential integration
> points during the tripleo deployment, for example
> https://review.opendev.org/c/openstack/tripleo-heat-templates/+/781571/7/environments/enable-secure-rbac.yaml
> . One of the considerations was around how we can test this in CI
> (possibly the standalone job is a good fit) as well as the use of
> multiple clouds.yaml for project specific operations during the
> deployment (with the root clouds yaml having the system-admin
> profile).
>
> * https://etherpad.opendev.org/p/centos-stream-9-upstream
>
> In this session the CI squad lead a discussion around centos9 stream
> (possibly coming Apr/May) and what we should consider/prepare for with
> respect to upstream CI. Some of the main changes and discussion items
> included NetworkManager and firewalld replacing iptables, ansible
> version (2.11/2.12?/?). Mainly this effort is blocked on the actual
> 9-stream release and getting the relevant nodepool node. Another main
> discussion point here was whether we would support both stream-8 and
> stream-9 on particular branches - consensus here is that wallaby has
> both 8/9 and for X can have only 9 - but this is all dependent on when
> 9 becomes available with respect to when Xena is released.
>
> * https://etherpad.opendev.org/p/os-migrate
>
> This session was an update from the upgrades squad around the
> os-migrate tool ( https://github.com/os-migrate/os-migrate  ) - which
> aims to 'copy' your openstack deployment and in particular the
> end-user workloads (i.e. user data, vms etc, but not the controlplane)
> onto new hardware, as an alternative to the in-place upgrade. More
> information and slides @
> https://docs.google.com/presentation/d/1UYGOI89MBLHLpS89mPp0VK1yvTYtb2BamUL_DmfGLGA/edit?usp=sharing