Open Stack

On Thu, Apr 22, 2021 at 7:46 PM Donny Davis <donny at fortnebula.com> wrote:

>
> https://grafana.opendev.org/d/BskTteEGk/nodepool-openedge?orgId=1&from=1587349229268&to=1594290731707
>
> 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.
>
> 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.
>

Local nvme means, utilization of worker node storage?


> On Thu, Apr 22, 2021 at 10:06 AM Donny Davis <donny at fortnebula.com> wrote:
>
>> 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.
>>
>> What is the requirement for startup times?
>>
>
End-user supposed to access an application based on his/her choice, and
it's a dedicated VM for the user.
Based on the application end-user selection, VM should be available to the
end-user along with required apps and provided hardware.



>
>> On Mon, Apr 19, 2021 at 9:31 AM Jeremy Stanley <fungi at yuggoth.org> wrote:
>>
>>> On 2021-04-19 16:31:24 +0530 (+0530), open infra wrote:
>>> > On Thu, Mar 25, 2021 at 8:38 PM Jeremy Stanley <fungi at yuggoth.org>
>>> wrote:
>>> [...]
>>> > > The next best thing is basically what Nodepool[*] does: start new
>>> > > virtual machines ahead of time and keep them available in the
>>> > > tenant. This does of course mean you're occupying additional quota
>>> > > for whatever base "ready" capacity you've set for your various
>>> > > images/flavors, and that you need to be able to predict how many of
>>> > > what kinds of virtual machines you're going to need in advance.
>>> > >
>>> > > [*] https://zuul-ci.org/docs/nodepool/
>>> >
>>> > Is it recommended to use nodepool in a production environment?
>>>
>>> I can't begin to guess what you mean by "in a production
>>> environment," but it forms the lifecycle management basis for our
>>> production CI/CD system (as it does for many other Zuul
>>> installations). In the case of the deployment I help run, it's
>>> continuously connected to over a dozen production clouds, both
>>> public and private.
>>>
>>> But anyway, I didn't say "use Nodepool." I suggested you look at
>>> "what Nodepool does" as a model for starting server instances in
>>> advance within the tenants/projects which regularly require instant
>>> access to new virtual machines.
>>> --
>>> Jeremy Stanley
>>>
>>
>>
>> --
>> ~/DonnyD
>> C: 805 814 6800
>> "No mission too difficult. No sacrifice too great. Duty First"
>>
>
>
> --
> ~/DonnyD
> C: 805 814 6800
> "No mission too difficult. No sacrifice too great. Duty First"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210422/cab1e46b/attachment-0001.html>