User/occasional-code-contributer here. We¹ve just recently started using the ImageExtension API, via computeServiceContext.getComputeService().getImageExtension(), to create and delete snapshots. Not sure if there is a better or more official way of doing this but if so we¹d love to hear it. Yes it can take some time to complete but has yet to fail for us (we¹re using RedHat OpenStack) though admittedly our workload in this area is quite small.
On 11/5/14, 3:56 PM, "Adrian Cole" <adrian.f.c...@gmail.com> wrote: >Hi, team. > >The following extensions absorb a lot of code and have questionable value. > >http://jclouds.apache.org/reference/javadoc/1.8.x/org/jclouds/compute/exte >nsions/SecurityGroupExtension.html > >http://jclouds.apache.org/reference/javadoc/1.8.x/org/jclouds/compute/exte >nsions/ImageExtension.html > >The image extension launches a complex task to construct and image >given an instance. Back when I recall testing this, it could easily >take 15 minutes, before failing with a massive stack trace. > >The security groups extension is based heavily on the EC2 classic >concept of security groups, which are not related to modern status >quo, where more sophisticated firewall-type rules are present, >complicated by multiple networks. > >Rather than carry the burden and reputation risk of continuing to >review and/or try to make these extensions pass tests, I recommend >calling bankruptcy and starting over. > >I have no idea why @Beta is not on these classes, so we should >deprecate them straight away, and leave the extensions absent from any >labs providers we promote. > >If you know of customer use-cases which depend on these classes, >please make them known, because at least in the case of >ImageExtension, I have serious doubts something implemented in this >way isn't just a timebomb waiting for the caller. > >We should focus more on portability and less on shotgun magic. The >next Image extension should make it easy to represent what an image >api can do, not attempt to perform a multi-step workflow that is >almost guaranteed to fail for a measurable percentage of callers. > >-A
