[jira] [Commented] (JCLOUDS-512) Cannot start instance from newly created image in ComputeService

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCLOUDS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106589#comment-15106589 ] 

ASF subversion and git services commented on JCLOUDS-512:
---------------------------------------------------------

Commit 40f31786c59e10f8ea74c2bf4463954361d5f68e in jclouds's branch refs/heads/master from [~nacx]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=40f3178 ]

JCLOUDS-512: Implement the ImageCache

This commit refactors the ImageCacheSupplier to act as a
proper cache. It is used by the ImageExtesion and all operations
on the images are propagated to the cache.

A method has also been added to the TemplateBuilder to let users
force a cache refresh. There have been several requests to provide a way
to disable image caching in the compute abstraction, and this new method
should fix that.


> Cannot start instance from newly created image in ComputeService
> ----------------------------------------------------------------
>
>                 Key: JCLOUDS-512
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-512
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-compute
>    Affects Versions: 1.7.1
>            Reporter: Everett Toews
>            Assignee: Ignasi Barrera
>             Fix For: 2.0.0
>
>
> A user found that after they create an image, they cannot start an instance of that image due to it not being found by the TemplateBuilder. See the example code and log in the following gist.
> https://gist.github.com/everett-toews/5447098
> I suspect the images in the TemplateBuilder are being cached and the new one isn't added to that cache but haven't been able to track down the offending code yet.
> Some notes from IRC for future work:
> in TemplateBuilderImpl images is Memoized
> the supplier is in BaseComputeServiceContextModule.supplyImageCache()
>    protected Optional<SecurityGroupExtension> provideSecurityGroupExtension(Injector i) {
> look at the aws code
> part of it is EC2TemplateBuilderImpl.lazyImageProvider 
> it is backed by a map
> which you could listen for and invalidate the image cache entry
> if the cache interval doesn't work, it is one thing
> to express an invalidation, well there's a couple ways
> dig deep
> and monkey around with internal classes
> or expose a ListOption.invalidate()
> and code'in providers to invalidate the cache when they encounter this flag
> it's not just cache interval, it's PROPERTY_SESSION_INTERVAL. from the name it sounds like if you set it to something low it would invalidate the whole session and reauth, just to invalidate that cache.
> there's no parameter for the cache
> probably what would be most helpful is to expose a property that corresponds to CacheBuilderSpec format
> ex. images.cache-spec=expireAfterWrite=300,refreshInterval=10000
> pass that in as a property
> then people can go to town tuning without special casing everything or conflating things like session interval with cache expiry
> basically, you can see how "template" is wired in
> then re-use that approach for the caches
> the most important one being images
> so you could skip the others for now



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)