Imagefactory HVM support for EC2

John Hover jhover at bnl.gov
Fri May 1 18:57:05 UTC 2015


Hi,

We exchanged email awhile ago about HVM instance type support from 
Imagefactory.

We now have working PV to HVM converter scripts 
(ec2-pv2hvm,img-conv-pv2hvm.sh ). The ec2-pv2hvm script is run from 
outside EC2, and it uses the img-conv-pv2hvm.sh script on the utility VM 
to do the conversion.

By looking at what the scripts do, I think you can pretty easily 
determine what you'd need to add to the EC2 plugin to provide an HVM 
image type.

http://svn.usatlas.bnl.gov/svn/griddev/provisioning-toolkit/misc/

Let us know what you think.

Cheers,

--john


On 01/15/2015 12:46 PM, John Hover wrote:
> On 01/15/2015 09:26 AM, Ian McLeod wrote:
>> On 01/14/2015 03:30 PM, John Hover wrote:
>>> Hi,
>>>
>>> We're heavy users of Imagefactory for building VMs to run scientific
>>> data processing on EC2 and on several private Openstack clusters.
>>>
>>> Four questions:
>>>
>>> Do you know if/when Imagefactory will begin supporting builds of
>>> HVM-compatible images on EC2? The newer instance types no longer support
>>> the PV images currently created. This is important to us because we
>>> often run 20000-50000 cores at a time, and getting that kind of capacity
>>> requires using multiple instance types.
>>
>> I'd be happy to work this through.  My impression is that it should
>> actually be a bit easier to do HVM, since we won't have to worry about
>> creating pvgrub compatible configuration files.
>>
>> Can you give me just a bit more detail about how you are using the
>> existing EC2 support?  Are you generating S3 or EBS backed images (or
>> both)?  Are you using the REST API or the CLI.
>
> Sure. We are building batch execution nodes that run in EC2 which, when
> run, connect back to our home system to run scientific analysis jobs
> (analyzing data from the Large Hadron Collider at CERN in Switzerland).
> The nodes are basic CentOS with various middleware and applications
> added in. They are EBS instances, using the defaults for the EC2 plugin
> in Imagefactory (version 1.1.6 currently, built from github checkout).
>
> All this is done in the context of the OSG (Open Science Grid), the US
> grid computing infrastructure (http://www.opensciencegrid.org/). In
> fact, OSG is considering using Imagefactory in *their* Koji build system
> as well--both for in-house test images and for public EC2 images (that
> other scientists can use).
>
>>
>> If you can give me a concrete example of the input to an actual build,
>> stripped of anything you don't wish to share externally, that would be
>> ideal.
>
> Sure, I have a custom build wrapper tool, that calls imagefactory after
> creating the tdl from several templates and input files.
>
> Here are the command lines it calls, just parsing the UUID after each
> step. See attached (and slightly sanitized tdl).
>
> imagefactory --debug base_image
> work/centos65-x86_64-bare-cloudconfig-condor-stable-osg-atlas.tdl
>
> imagefactory --debug target_image --id
> caf61ccc-53ba-4cf0-80dc-d85499277b9d ec2
>
> imagefactory --debug provider_image --id
> 8bc57601-0be3-404a-8442-c977e3b51faa ec2 @us-east-1
> /root/etc/ec2_credentials.xml
>
> At the end we've got a PV AMI ready to run.
>
>>
>>> I see no traffic at all on imagefactory-devel. Is this because the real
>>> discussions are happening elsewhere, or is it really not a very active
>>> project?
>>>
>>> Is Redhat intending to continue Imagefactory as its image authoring
>>> framework? I built a lot of infrastructure around Boxgrinder, only to
>>> have it deprecated. I hope we're not facing the same situation with
>>> Imagefactory.
>>>
>>> We have several simple patches that have made things easier for us and
>>> might be useful to others. Do you take pull requests via github, or some
>>> other mechanism?
>>
>> PRs on github are most welcome.
>
> OK. At this point my main change is to add more useful information to
> the AMI name field on EC2--things like build date and template name,
> such that when you sort the field in the AWS console you can easily see
> the most recent image. AWS doesn't include a 'build date' field at all
> for AMIs!
>
>> Imagefactory is now being actively used in a number of contexts and I
>> have every intention of continuing to develop and maintain it.
>
> That's great news.
>
>>
>> Two quick examples:
>>
>> It's the backing tool that creates most of the images in Fedora's koji
>> instance:
>>
>> http://koji.fedoraproject.org/koji/tasks?state=all&view=tree&method=image&order=-id
>>
>>
>> It's incorporated into the "toolbox" code used to generate disk images
>> for project Atomic:
>>
>> https://github.com/projectatomic/rpm-ostree-toolbox
>>
>> I apologize for the lack of mailing list traffic or other announcements
>> of progress.  I'm regularly reminded that communication and community
>> development are important and will try to do more :-).
>
> No worries. Same here.
>
> --john
>
>>
>> -Ian
>>
>>
>>>
>>> Thanks,
>>>
>>> --john
>>>
>>>
>>>   --
>>> John Hover
>>> Group Leader | Grid Group/Experiment Services
>>> RHIC/ATLAS Computing Facility | Brookhaven National Laboratory
>>> jhover at bnl.gov | 631-344-5828 | http://www.racf.bnl.gov/Members/jhover
>>>
>>
>
>
>
>
> _______________________________________________
> imagefactory-devel mailing list
> imagefactory-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/imagefactory-devel
>


-- 
John Hover
Group Leader | Grid Group/Experiment Services
RHIC/ATLAS Computing Facility | Brookhaven National Laboratory
jhover at bnl.gov | 631-344-5828 | http://www.racf.bnl.gov/Members/jhover

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3517 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.fedorahosted.org/pipermail/imagefactory-devel/attachments/20150501/067d14e4/attachment.p7s>


More information about the imagefactory-devel mailing list