[openstack-dev] [glance] [nova] Image Prefetching – Precaching

[Alberto Geniola]

Hi everyone,


This is my first email to the OS developer forum, so forgive me if I
misplaced the subject tags J.


Straight to the point: for a project we’re involved in, we think that a
pre-fetcher mechanism would be great for a variety of use cases. There was
an attempt with this blueprint:


https://blueprints.launchpad.net/nova/+spec/nova-image-cache-management-2


and a more recent one:


https://blueprints.launchpad.net/python-novaclient/+spec/prefetch-image


although both seems to be dead now.

So I really want to get a feedback from the developer’s community whether
(1) such a feature makes sense in general, and (2) it may be worth the
integration of such a component in the OpenStack code. In fact, although we
can solve our problem by developing an in-house component, it would be
better to have it integrated in OpenStack, including Nova and Horizon, so I
need the feedback from the OS Guru guys J.


What do you think?



-- 
Dott. Alberto Geniola

  albertogeni...@gmail.com
  +39-346-6271105
  https://www.linkedin.com/in/albertogeniola

Web: http://www.hw4u.it
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] [nova] Image Prefetching – Precaching

[Alberto Geniola]

Hi John,

First of all thank you for the tip about tags.

In order to understand what extra API are needed to implement this
mechanism, I think we need to focus on what should be done by this
component.

In my opinion, what we need on NOVA-COMPUTE side would be:
1) List all images prefetched on each nova-compute node
2) Trigger an image prefetch on a particular node
3) Remove an image from the cache

The rest of mechanism, in my opinion, is an Horizon plugin that interacts
with Glance and calls appropriate APIs above.

In order to avoid duplication on the compute nodes, I think that images
might be cached into /var/lib/nova/instances/_base/ , so they are
immediately ready to be used by nova-compute.
Given that, if the user inhibits the image deletion after 1 day of unusage
from the conf file, this mechanism may be very helpful.

In other words by implementing API listed above in nova, alongside
developing a simple horizon plugin, we should be able to provide this
interesting feature.

Do you see any problem with this approach?




On Thu, Aug 20, 2015 at 12:47 PM, John Garbutt j...@johngarbutt.com wrote:

 On 19 August 2015 at 19:30, Alberto Geniola albertogeni...@gmail.com
 wrote:
 
  Hi everyone,
 
 
  This is my first email to the OS developer forum, so forgive me if I
 misplaced the subject tags J.

 Welcome!

 For future posts, I hope this helps make it easier:
 https://wiki.openstack.org/wiki/MailingListEtiquette


  Straight to the point: for a project we’re involved in, we think that a
 pre-fetcher mechanism would be great for a variety of use cases. There was
 an attempt with this blueprint:
 
 
 https://blueprints.launchpad.net/nova/+spec/nova-image-cache-management-2
 
  and a more recent one:
 
  https://blueprints.launchpad.net/python-novaclient/+spec/prefetch-image
 
  although both seems to be dead now.
 
  So I really want to get a feedback from the developer’s community
 whether (1) such a feature makes sense in general, and (2) it may be worth
 the integration of such a component in the OpenStack code. In fact,
 although we can solve our problem by developing an in-house component, it
 would be better to have it integrated in OpenStack, including Nova and
 Horizon, so I need the feedback from the OS Guru guys J.
 
 
  What do you think?

 I think it does make some sense.

 The disagreement in the past is about agreeing what should live inside
 Nova, and what should live outside Nova.

 For me, I am OK having an API to trigger an image prefetch on a
 particular host (although in many cases doing a build on that host has
 the same affect).

 I think the rest of that mechanism should probably live outside of
 Nova and Glance. So the question is what extra API are required to
 create such a tool.

 Thanks,
 johnthetubaguy

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Dott. Alberto Geniola

  albertogeni...@gmail.com
  +39-346-6271105
  https://www.linkedin.com/in/albertogeniola

Web: http://www.hw4u.it
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

[Alberto Geniola]

Hi all,

I'm glad to see much interest in this feature. I will prepare and submit
nova specs by the end of this week.
On Oct 23, 2015 5:47 PM, "Markus Zoeller"  wrote:

> Mathieu Gagné  wrote on 10/22/2015 08:08:07 PM:
> > > Could you maybe add a short explanation what the use case is? IOW,
> > > when and why do I (in whatever role) prefetch images?
> > >
> >
> > This previous OpenStack Summit presentation at Paris is a great example
> > of use case:
> > https://www.openstack.org/summit/openstack-paris-summit-2014/session-
> > videos/presentation/cold-start-booting-of-1000-vms-under-10-minutes
> >
> > --
> > Mathieu
>
> Thanks, that's a great presentation with impressive numbers. I wasn't
> aware that there could be the need to distribute new images such often.
>
> Regards, Markus Zoeller (markus_z)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

[Alberto Geniola]

Hi all,

I'm considering to extend the Nova-Compute API in order to provide
image-prefetching capabilities to OS.

In order to allow image prefetching, I ended up with the need to add three
different APIs on the nova-compute nodes:

  1. Trigger an image prefetching

  2. List prefetched images

  3. Delete a prefetched image



About the point 1 I saw I can re-use the libvirt driver function
_create_image() to trigger the image prefetching. However, this approach
will not store any information about the stored image locally. This leads
to an issue: how do I retrieve a list of already fetched images? A quick
and simple possibility would be having a local file, storing information
about the fetched images. Would it be acceptable? Is there any best
practice in OS community?



Any ideas?


Ty,

Al.

-- 
Dott. Alberto Geniola

  albertogeni...@gmail.com
  +39-346-6271105
  https://www.linkedin.com/in/albertogeniola

Web: http://www.hw4u.it
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

[Alberto Geniola]

Hi Michael,

and thank you for your answer.

Indeed, what I want to do is to add methods to the ImageCache.py module
(listing, adding, deleting). So far, this module only takes care of image
deletion: this represents the "cache" of images. Now, I want to populate
the cache with some images on the hypervisor (as you mention) without
having any instance running it, yet. The method I want like to add should
call the appropriate method from the hypervisor driver (let's say libvirt)
to trigger the image download/creation without starting it (I guess
something like calling _create_image() should do the trick).

Your question is actually good: how will an user be  able to trigger this
image caching mechanism?
My idea is to extend the HTTP Nova Compute API. I would lilke to add a
resource, let's say "CachedImages", to the API tree. In this way,
interacting via CRUD operation we should be able to CALL/CAST rpc api and
interact with the imagecache module.

Is it clearer now? Do you see any problem in this approach?

Regards,

Alberto.




On Thu, Oct 8, 2015 at 11:45 PM, Michael Still <mi...@stillhq.com> wrote:

> I think I'd rephrase your definition of pre-fetched to be honest --
> something more like "images on this hypervisor node without a currently
> running instance". So, your operations would become:
>
>  - trigger an image prefetching
>  - list unused base images (and perhaps when they were last used)
>  - delete an unused image
>
> All of that would need to tie into the image cache management code so that
> its not stomping on your images. In fact, you're probably best of adding
> all of this as tweaks to the image cache manager anyways.
>
> One question though -- who is calling these APIs? Are you adding a central
> service to orchestrate these calls?
>
> Michael
>
>
>
> On Thu, Oct 8, 2015 at 10:50 PM, Alberto Geniola <albertogeni...@gmail.com
> > wrote:
>
>> Hi all,
>>
>> I'm considering to extend the Nova-Compute API in order to provide
>> image-prefetching capabilities to OS.
>>
>> In order to allow image prefetching, I ended up with the need to add
>> three different APIs on the nova-compute nodes:
>>
>>   1. Trigger an image prefetching
>>
>>   2. List prefetched images
>>
>>   3. Delete a prefetched image
>>
>>
>>
>> About the point 1 I saw I can re-use the libvirt driver function
>> _create_image() to trigger the image prefetching. However, this approach
>> will not store any information about the stored image locally. This leads
>> to an issue: how do I retrieve a list of already fetched images? A quick
>> and simple possibility would be having a local file, storing information
>> about the fetched images. Would it be acceptable? Is there any best
>> practice in OS community?
>>
>>
>>
>> Any ideas?
>>
>>
>> Ty,
>>
>> Al.
>>
>> --
>> Dott. Alberto Geniola
>>
>>   albertogeni...@gmail.com
>>   +39-346-6271105
>>   https://www.linkedin.com/in/albertogeniola
>>
>> Web: http://www.hw4u.it
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Rackspace Australia
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dott. Alberto Geniola

  albertogeni...@gmail.com
  +39-346-6271105
  https://www.linkedin.com/in/albertogeniola

Web: http://www.hw4u.it
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev