Image caching code has landed

8 views
Skip to first unread message

Miquel Torres

unread,
Nov 8, 2010, 1:52:38 PM11/8/10
to Overmind development
Hi all,

I finally had some time to start Milestone 2 development.

Before the two big items of M2, job queue and UI, there was some
pending work on images, locations and sizes for nodes. They now have
each their own model and the different image, location and size
options are saved for each provider instead of being fetched on each
call to the new node form.

The form is now much faster to load as a result, and the tooltips show
the respective info.

There remains work to be done, because EC2 has nearly 6000 images,
which is a pain to browse in a select box and slow to load (even from
the DB). Grig and I have discussed implementing "favorite" images for
providers which offer a big number of images. You will for example be
able to introduce an ami id and that will be added to your image list
when launching a new node. That prevents from having an enormous and
unusable image list.

If anyone has a better idea interface-wise please share it with us!

Enjoy!
Miquel

lusis

unread,
Nov 8, 2010, 2:39:31 PM11/8/10
to Overmind development
It might help to not only do favorite images but classify them in some
way. You can at least restrict the images to Linux only for now. I
think Amazon added filtering to the EC2 API recently. Not sure if that
affected AMIs or not.

Worst case, recently used first, then favorites then nested select box
based on first letter or something? I just did a quick count and there
are only 718 Linux AMIs.

Miquel Torres

unread,
Nov 9, 2010, 3:17:40 AM11/9/10
to overmi...@googlegroups.com
That is not a bad suggestion, but there are two problems with it.
First, I'd rather not introduce provider-dependent hacks. Also, I
don't want to restrict which images you can use. Don't get me wrong, I
don't plan to actively work to support Windows, but I wouldn't
restrict to Linux from the get go.

What I had in mind is more or less what you say. Only, any image used
once will be automatically added to your favorites list, which makes a
recently used list redundant. And the "image browser" wouldn't need to
be shown per default. Besides being slow (look how long it takes for
the image browser of the AWS Maganement console to load!), it can't be
easier to manually look for an image than to just enter the ami id?

An thing about real work at a real organization. The 98% use case will
be to select an image from a list of 2 or 3 anyway, not loose time
browsing through hundreds of images.


2010/11/8 lusis <lusi...@gmail.com>:

Miquel Torres

unread,
Nov 10, 2010, 10:00:25 AM11/10/10
to overmi...@googlegroups.com
There is a first implementation of the favorite images in master.

All is done in-place, in the new node form. The form now loads
instantly, as it only pulls favorite images from the DB. There is a
link below the image list, which calls an in-line form that allows to
add another image to the favorites list, choosing from the complete
image set of the provider or entering an image id (ami for EC2). The
image list, even though it is indeed huge for EC2, is now
alphabetically ordered, so it is not so difficult to find something on
the few occasions when you will need to browse.

I think it works quite nicely, specially when you keep in mind the
normal use case: choose from the few images you use in daily work.

I left out removing images from the list. I will look again at that
part when I implement a real UI.

What do you think of this implementation?

Miquel


2010/11/9 Miquel Torres <tob...@googlemail.com>:

Miquel Torres

unread,
Dec 9, 2010, 6:59:25 AM12/9/10
to overmi...@googlegroups.com
Hi all,

just wanted to say that I have refined the image handling quite a bit.
You can now mark and unmark images as favorite and your last used
image is remembered and pre-selected by the new node form.

Also, sizes now show their price, both in the node form and in the
node tooltip (overview). Bear in mind thought that clouds do not
always provide pricing info through their APIs, and libcloud has
hardcoded prices as of version 0.4 (probably from November). They have
plans to put up an online prices database so that libcloud users can
get up-to-date pricing without having to release a new libcloud
version, but for the mean time this will do.

It still is nice to be able to see a ballpark figure for each instance
size. What I need to think about now is how to display some kind of
disclaimer about prices...

If anyone has a look at the new Overmind master version please give
some feedback here (DB must be rebuilt)!

Cheers

PS: These changes and small refactorings and polish in other areas
have kept me busy, but now all is clear for the next step: the job
queue!


2010/11/10 Miquel Torres <tob...@googlemail.com>:

Reply all
Reply to author
Forward
0 new messages