<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 22, 2021 at 7:46 PM Donny Davis <<a href="mailto:donny@fortnebula.com">donny@fortnebula.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><a href="https://grafana.opendev.org/d/BskTteEGk/nodepool-openedge?orgId=1&from=1587349229268&to=1594290731707" target="_blank">https://grafana.opendev.org/d/BskTteEGk/nodepool-openedge?orgId=1&from=1587349229268&to=1594290731707</a><br><div><br></div><div>I know nodepool keeps a number of instances up and available for use, but on FN it was usually tapped to the max so I am not sure this logic applies. </div><div><br></div><div>Anyways in my performance testing and tuning of Openstack to get it moving as fast as possible, my determination was local NVME storage fit the rapid fire use case the best.  Next best was on shared NVME storage via ISCSI using cinder caching. </div></div></blockquote><div><br></div><div>Local nvme means, utilization of worker node storage? <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 22, 2021 at 10:06 AM Donny Davis <<a href="mailto:donny@fortnebula.com" target="_blank">donny@fortnebula.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">FWIW I had some excellent startup times in Fort Nebula due to using local storage backed by nvme drives. Once the cloud image is copied to the hypervisor, startup's of the vms were usually measured in seconds. Not sure if that fits the requirements, but sub 30 second startups were the norm. This time was including the actual connection from nodepool to the instance. So I imagine the local start time was even faster. <br><br>What is the requirement for startup times? </div></blockquote></div></blockquote><div><br></div><div>End-user supposed to access an application based on his/her choice, and it's a dedicated VM for the user.</div><div>Based on the application end-user selection, VM should be available to the end-user along with required apps and provided hardware.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 19, 2021 at 9:31 AM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2021-04-19 16:31:24 +0530 (+0530), open infra wrote:<br>
> On Thu, Mar 25, 2021 at 8:38 PM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> wrote:<br>
[...]<br>
> > The next best thing is basically what Nodepool[*] does: start new<br>
> > virtual machines ahead of time and keep them available in the<br>
> > tenant. This does of course mean you're occupying additional quota<br>
> > for whatever base "ready" capacity you've set for your various<br>
> > images/flavors, and that you need to be able to predict how many of<br>
> > what kinds of virtual machines you're going to need in advance.<br>
> ><br>
> > [*] <a href="https://zuul-ci.org/docs/nodepool/" rel="noreferrer" target="_blank">https://zuul-ci.org/docs/nodepool/</a><br>
> <br>
> Is it recommended to use nodepool in a production environment?<br>
<br>
I can't begin to guess what you mean by "in a production<br>
environment," but it forms the lifecycle management basis for our<br>
production CI/CD system (as it does for many other Zuul<br>
installations). In the case of the deployment I help run, it's<br>
continuously connected to over a dozen production clouds, both<br>
public and private.<br>
<br>
But anyway, I didn't say "use Nodepool." I suggested you look at<br>
"what Nodepool does" as a model for starting server instances in<br>
advance within the tenants/projects which regularly require instant<br>
access to new virtual machines.<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>~/DonnyD</div><div>C: 805 814 6800</div><div>"No mission too difficult. No sacrifice too great. Duty First"</div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>~/DonnyD</div><div>C: 805 814 6800</div><div>"No mission too difficult. No sacrifice too great. Duty First"</div></div></div>
</blockquote></div></div>