<div dir="ltr"><div class="gmail_default" style="font-family:monospace"><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">Hello everyone,</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">Here are a few highlights on the TripleO Ceph integration status and the plans for the next cycle.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><b><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br>1. Deployed ceph as a separate step</span></b></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">TripleO
now provides a different stage (with a new cli set of commands) to
bootstrap the Ceph cluster before reaching the overcloud deployment
phase.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">This
is the new default approach since Wallaby, and the short term plan is
to work on the upstream CI consolidation to make sure we run this stage
on<br> the existing TripleO standalone scenarios, extending the coverage
to both phases (before the overcloud deployment, when the Ceph cluster
is created,<br> and during the overcloud deployment, when the cluster is finalized according to the enabled services).</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">It's
worth mentioning that great progress in this direction has been made,
and the collaboration with the tripleo-ci is one of the key points here,
as<br> they're helping on the automation aspect to test upstream pending bits with daily jobs.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">The
next step will be working together on the automation of the promotion
mechanism, which is supposed to make this process less error-prone.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><b><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br>2. Decouple Ceph Upgrades</span></b></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">Nautilus
to Pacific is still managed
by ceph-ansible but the stage of upgrading the cluster has been moved before the overcloud upgrade, resulting in</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">a different maintenance window.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">Once
the cluster is moved to Pacific, cephadm is enabled, and from this
moment onwards, the upgrade process, as well as minor updates, will be
managed<br> by cephadm and can be seen as a day2 operation.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">The
operator can now perform these kinds of tasks without any interaction
with TripleO, which is still used to pull the new containers (unless
another<br> registry reachable from the overcloud is used), but the scope has been limited.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><b><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">3. Ganesha transitioning to Ceph orchestrator and Ingress migration</span></b></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">This
has been the main topic for this first ptg session: the feature it's
tracked by two already approved upstream specs and the goal is to
support a<br> Ganesha service managed by cephadm instead of a tripleo-managed one.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">The TripleO conversation impacted many areas:</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><b>a.</b>
the networkv2 flow has been improved and it's now possible to reserve
more than 1 VIP per network, but it applies only to the ceph services;</span><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><b>b.</b>
a new TripleO resource, the CephIngress daemon, has been added, and
it's a key component (provided by Ceph) that is supposed to provide HA
for the<br> ceph-nfs managed daemon</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><b>c.</b> The tripleo cli is extended and the ceph-nfs daemon can be deployed during the bootstrap of the ceph cluster</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><b>d.</b>
This feature depends on the manila driver development [1], which
represents an effort to implement a driver that can interact with the
Ceph orch cli<br> (and the layer it provides for nfs) instead of using dbus.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"> Further information about this conversation can be found here [1].</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">Part
of this conversation (and really good input here actually) was about
the migration plan for already existing environments where operators
would like<br> to move from a TripleO managed Ganesha to a highly available ceph-nfs managed by cephadm.</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">The outcome here is:</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><b>1.</b>
It's possible to move to the cephadm managed ingress daemon during the
upgrade under certain constraints, but we should provide tools to
finalize the<br> migration because there's an impact not only on the
server-side (and the manila service itself) but also on the clients
where the shares are mounted;</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><b>2.</b>
We might want to have options to keep the PCS managed VIP for Ganesha
and avoid forcing people to migrate, and this flow should be consistent
at tripleo<br> heat templates level;</span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br>For those who are interested, here's the etherpad [2] and the recording of the session [3].<br></span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br><br></span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">Thanks,<br></span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">Francesco<br></span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">[1] <a href="https://etherpad.opendev.org/p/zorilla-ptg-manila-planning" target="_blank">https://etherpad.opendev.org/p/zorilla-ptg-manila-planning</a></span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">[2] <a href="https://etherpad.opendev.org/p/tripleo-zed-ceph" target="_blank">https://etherpad.opendev.org/p/tripleo-zed-ceph</a></span></p><p style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(14,16,26);background:transparent none repeat scroll 0% 0%;margin-top:0pt;margin-bottom:0pt">[3] <a href="https://slagle.fedorapeople.org/tripleo-zed-ptg/tripleo-zed-ptg-ceph.mp4" target="_blank">https://slagle.fedorapeople.org/tripleo-zed-ptg/tripleo-zed-ptg-ceph.mp4</a></span></p></div><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><font face="monospace">Francesco Pantano<br>
GPG KEY: F41BD75C</font><br></font></span></div></div></div></div></div></div></div>