<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:-webkit-standard;
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-AU" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Hi Tobias,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">I saw your message, interesting method to get around the transient mdev issue.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Have you looked into implementing cyborg as a method to alleviate this? We are currently assessing it for a different project using nvidia A40’s.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Would be keen to swap war stories and see if we can make a better solution than the current vGPU mdev support going on.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black">Kind Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black">Karl.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black">You can book a 30-minute meeting with me by clicking
</span><span style="font-size:11.0pt;font-family:-webkit-standard"><a href="https://calendly.com/karl_rwts/30min"><span style="color:#0563C1">this link.</span></a><span style="color:black"><o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black">--<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:-webkit-standard;color:black">Karl Kloppenborg, Systems Engineering</span></b><span style="font-size:11.0pt;font-family:-webkit-standard;color:black"> <i>(BCompSc, CNCF-[KCNA, CKA, CKAD], LFCE,
CompTIA Linux+ XK0-004)</i><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black">Real World Technology Solutions - IT People you can trust<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black">Voice | Data | IT Procurement | Managed IT<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black"><a href="http://rwts.com.au" target="_blank"><span style="color:#000064">rwts.com.au</span></a> | 1300 798 718<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black"><img border="0" width="600" height="63" style="width:6.25in;height:.6562in" id="Picture_x0020_1" src="cid:image001.jpg@01D92AB9.16FDD2F0" alt="uc%3fexport=download&id=1M0bR7j1-rXl-e7k5f1Rhwot6K_vfuAvn&revid=0B4fBbZ0cwq-1WFdQSExlR28rOEtUanJjOGcvQnJjMFhEMlEwPQ"><o:p></o:p></span></p>
<p class="MsoNormal"><i><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Real World is a DellEMC Gold Partner</span></i><span style="font-size:11.0pt;font-family:-webkit-standard;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:-webkit-standard;color:black">This document should be read only by those persons to whom it is addressed and its content is not intended for use by any other persons. If you have received this message
in error, please notify us immediately. Please also destroy and delete the message from your computer. Any unauthorised form of reproduction of this message is strictly prohibited. We are not liable for the proper and complete transmission of the information
contained in this communication, nor for any delay in its receipt. Please consider the environment before printing this e-mail.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">openstack-discuss-request@lists.openstack.org <openstack-discuss-request@lists.openstack.org><br>
<b>Date: </b>Tuesday, 17 January 2023 at 9:06 pm<br>
<b>To: </b>openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org><br>
<b>Subject: </b>openstack-discuss Digest, Vol 51, Issue 51<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Send openstack-discuss mailing list submissions to<br>
openstack-discuss@lists.openstack.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss">
https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss</a><br>
<br>
or, via email, send a message with subject or body 'help' to<br>
openstack-discuss-request@lists.openstack.org<br>
<br>
You can reach the person managing the list at<br>
openstack-discuss-owner@lists.openstack.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of openstack-discuss digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Enable fstrim automatically on cinder thin lvm<br>
provisioning (Rajat Dhasmana)<br>
2. Re: Experience with VGPUs (Tobias Urdin)<br>
3. Re: [designate] Proposal to deprecate the agent framework and<br>
agent based backends (Thomas Goirand)<br>
4. Re: Experience with VGPUs (Sylvain Bauza)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 17 Jan 2023 10:11:27 +0530<br>
From: Rajat Dhasmana <rdhasman@redhat.com><br>
To: A Monster <amonster369@gmail.com><br>
Cc: openstack-discuss <openstack-discuss@lists.openstack.org><br>
Subject: Re: Enable fstrim automatically on cinder thin lvm<br>
provisioning<br>
Message-ID:<br>
<CAARK8KQ3rM9KSQ9vFP+CAVPL_xAksxfXvFuvZj8gd7FeFT6LTw@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
We've a config option 'report_discard_supported'[1] which can be added to<br>
cinder.conf that will enable trim/unmap support.<br>
<br>
Also I would like to suggest not creating new openstack-discuss threads for<br>
the same issue and reuse the first one created.<br>
As I can see these are the 3 threads for the same issue[2][3][4].<br>
<br>
[1]<br>
<a href="https://docs.openstack.org/cinder/latest/configuration/block-storage/config-options.html">https://docs.openstack.org/cinder/latest/configuration/block-storage/config-options.html</a><br>
[2]<br>
<a href="https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031789.html">https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031789.html</a><br>
[3]<br>
<a href="https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031797.html">https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031797.html</a><br>
[4]<br>
<a href="https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031805.html">https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031805.html</a><br>
<br>
Thanks<br>
Rajat Dhasmana<br>
<br>
On Tue, Jan 17, 2023 at 8:57 AM A Monster <amonster369@gmail.com> wrote:<br>
<br>
> I deployed openstack using kolla ansible, and used LVM as storage backend<br>
> for my cinder service, however I noticed that the lvm thin pool size keeps<br>
> increasing even though the space used by instances volumes is the same, and<br>
> after a bit of investigating I found out that I had to enable fstrim<br>
> because the data deleted inside the logical volumes was still allocated<br>
> from the thin pool perspective and I had to do fstrim on those volumes,<br>
><br>
> how can I enable this automatically in openstack?<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230117/805f4aba/attachment-0001.htm">https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230117/805f4aba/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 17 Jan 2023 08:54:03 +0000<br>
From: Tobias Urdin <tobias.urdin@binero.com><br>
To: openstack-discuss <openstack-discuss@lists.openstack.org><br>
Subject: Re: Experience with VGPUs<br>
Message-ID: <220CE3FB-C139-492E-ADD1-BC1ECBEAE65E@binero.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello,<br>
<br>
We are using vGPUs with Nova on OpenStack Xena release and we?ve had a fairly good experience integration<br>
NVIDIA A10 GPUs into our cloud.<br>
<br>
As we see it there is some painpoints that just goes with mantaining the GPU feature.<br>
<br>
- There is a very tight coupling of the NVIDIA driver in the guest (instance) and on the compute node that needs to<br>
be managed.<br>
<br>
- Doing maintainance need more planning i.e powering off instances, NVIDIA driver on compute node needs to be<br>
rebuilt on hypervisor if kernel is upgraded unless you?ve implemented DKMS for that.<br>
<br>
- Because we?ve different flavor of GPU (we split the A10 cards into different flavors for maximum utilization of<br>
other compute resources) we added custom traits in the Placement service to handle that, handling that with<br>
a script since doing anything manually related to GPUs you will get confused quickly. [1]<br>
<br>
- Since Nova does not handle recreation of mdevs (or use the new libvirt autostart feature for mdevs) we have<br>
a systemd unit that executes before the nova-compute service that walks all the libvirt domains and does lookups<br>
in Placement to recreate the mdevs before nova-compute start. [2] [3] [4]<br>
<br>
Best regards<br>
Tobias<br>
<br>
DISCLAIMER: Below is provided without any warranty of actually working for you or your setup and does<br>
very specific things that we need and is only provided to give you some insight and help. Use at your own risk.<br>
<br>
[1] <a href="https://paste.opendev.org/show/b6FdfwDHnyJXR0G3XarE/">https://paste.opendev.org/show/b6FdfwDHnyJXR0G3XarE/</a><br>
[2] <a href="https://paste.opendev.org/show/bGtO6aIE519uysvytWv0/">https://paste.opendev.org/show/bGtO6aIE519uysvytWv0/</a><br>
[3] <a href="https://paste.opendev.org/show/bftOEIPxlpLptkosxlL6/">https://paste.opendev.org/show/bftOEIPxlpLptkosxlL6/</a><br>
[4] <a href="https://paste.opendev.org/show/bOYBV6lhRON4ntQKYPkb/">https://paste.opendev.org/show/bOYBV6lhRON4ntQKYPkb/</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230117/daed7e1e/attachment-0001.htm">https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230117/daed7e1e/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 17 Jan 2023 10:11:44 +0100<br>
From: Thomas Goirand <zigo@debian.org><br>
To: openstack-discuss <OpenStack-discuss@lists.openstack.org><br>
Subject: Re: [designate] Proposal to deprecate the agent framework and<br>
agent based backends<br>
Message-ID: <46a43b97-063d-ed46-6dc1-94f7e0d12e5e@debian.org><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
On 1/17/23 01:52, Michael Johnson wrote:<br>
> TLDR: The Designate team would like to deprecate the backend agent<br>
> framework and the agent based backends due to lack of development and<br>
> design issues with the current implementation. The following backends<br>
> would be deprecated: Bind9 (Agent), Denominator, Microsoft DNS<br>
> (Agent), Djbdns (Agent), Gdnsd (Agent), and Knot2 (Agent).<br>
<br>
Hi Michael,<br>
<br>
Thanks for this.<br>
<br>
Now, if we're going to get rid of the code soonish, can we just get rid <br>
of the unit tests, rather than attempting to monkey-patch dnspython? <br>
That feels safer, no? With Eventlet, I have the experience that monkey <br>
patching is dangerous and often leads to disaster.<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 17 Jan 2023 11:04:59 +0100<br>
From: Sylvain Bauza <sbauza@redhat.com><br>
To: Tobias Urdin <tobias.urdin@binero.com><br>
Cc: openstack-discuss <openstack-discuss@lists.openstack.org><br>
Subject: Re: Experience with VGPUs<br>
Message-ID:<br>
<CALOCmukWP2qwfh7D8sUotSbhrpqok739s8KcvHmiXEZWT3JSfQ@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Le mar. 17 janv. 2023 ? 10:00, Tobias Urdin <tobias.urdin@binero.com> a<br>
?crit :<br>
<br>
> Hello,<br>
><br>
> We are using vGPUs with Nova on OpenStack Xena release and we?ve had a<br>
> fairly good experience integration<br>
> NVIDIA A10 GPUs into our cloud.<br>
><br>
><br>
Great to hear, thanks for your feedback, much appreciated Tobias.<br>
<br>
<br>
> As we see it there is some painpoints that just goes with mantaining the<br>
> GPU feature.<br>
><br>
> - There is a very tight coupling of the NVIDIA driver in the guest<br>
> (instance) and on the compute node that needs to<br>
> be managed.<br>
><br>
><br>
As nvidia provides proprietary drivers, there isn't much we can move on<br>
upstream, even for CI testing.<br>
Many participants in this thread explained this as a common concern and I<br>
understand their pain, but yeah you need third-party tooling for managing<br>
both the driver installation and the licensing servers.<br>
<br>
<br>
> - Doing maintainance need more planning i.e powering off instances, NVIDIA<br>
> driver on compute node needs to be<br>
> rebuilt on hypervisor if kernel is upgraded unless you?ve implemented<br>
> DKMS for that.<br>
><br>
><br>
Ditto, unfortunately I wish the driver could be less kernel-dependent but I<br>
don't see a foreseenable future for this.<br>
<br>
<br>
<br>
> - Because we?ve different flavor of GPU (we split the A10 cards into<br>
> different flavors for maximum utilization of<br>
> other compute resources) we added custom traits in the Placement service<br>
> to handle that, handling that with<br>
> a script since doing anything manually related to GPUs you will get<br>
> confused quickly. [1]<br>
><br>
<br>
True, that's why you can also use generic mdevs which will create different<br>
resource classes (but ssssht) or use the placement.yaml file to manage your<br>
inventories.<br>
<a href="https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/generic-mdevs.html">https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/generic-mdevs.html</a><br>
<br>
<br>
> - Since Nova does not handle recreation of mdevs (or use the new libvirt<br>
> autostart feature for mdevs) we have<br>
> a systemd unit that executes before the nova-compute service that walks<br>
> all the libvirt domains and does lookups<br>
> in Placement to recreate the mdevs before nova-compute start. [2] [3] [4]<br>
><br>
><br>
This is a known issue and we agreed on the last PTG for a direction.<br>
Patches on review.<br>
<a href="https://review.opendev.org/c/openstack/nova/+/864418">https://review.opendev.org/c/openstack/nova/+/864418</a><br>
<br>
Thanks,<br>
-Sylvain<br>
<br>
<br>
> Best regards<br>
> Tobias<br>
><br>
> DISCLAIMER: Below is provided without any warranty of actually working for<br>
> you or your setup and does<br>
> very specific things that we need and is only provided to give you some<br>
> insight and help. Use at your own risk.<br>
><br>
> [1] <a href="https://paste.opendev.org/show/b6FdfwDHnyJXR0G3XarE/">https://paste.opendev.org/show/b6FdfwDHnyJXR0G3XarE/</a><br>
> [2] <a href="https://paste.opendev.org/show/bGtO6aIE519uysvytWv0/">https://paste.opendev.org/show/bGtO6aIE519uysvytWv0/</a><br>
> [3] <a href="https://paste.opendev.org/show/bftOEIPxlpLptkosxlL6/">https://paste.opendev.org/show/bftOEIPxlpLptkosxlL6/</a><br>
> [4] <a href="https://paste.opendev.org/show/bOYBV6lhRON4ntQKYPkb/">https://paste.opendev.org/show/bOYBV6lhRON4ntQKYPkb/</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230117/7b9455f2/attachment.htm">https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230117/7b9455f2/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
openstack-discuss mailing list<br>
openstack-discuss@lists.openstack.org<br>
<br>
<br>
------------------------------<br>
<br>
End of openstack-discuss Digest, Vol 51, Issue 51<br>
*************************************************<o:p></o:p></span></p>
</div>
</div>
</body>
</html>