[lago-devel] [ovirt-devel] Lago and vm templates

[Marc Young]

Ive made progress on using pure cloud-init on the centos glance images to
get the vagrant pre-requisites included and usable but so far thats
introduced two issues that still make template exporting within Lago
desirable:


   1. Time and network resources to download packages as well as CPU/memory
   bloating from repeated installations of the same packages
   2. Unable to test network configuration of vagrant, which is a large
   part of vagrant to leave untested
      1. By that i mean dhcp/static/multiple network interfaces via blocks
      such as [1] and [2]

In the mean time I'm contemplating using the vagrant/ruby sdk to make
`vagrant package` export as an oVirt template which would let me call that
in the middle of an ovirt-system-tests suite, if I'm not mistaken?

[1]

  config.vm.network :private_network,
    :ovirt__network_name => 'ovirtmgmt' #DHCP

[2]

  config.vm.network :private_network,
    :ovirt__ip => '192.168.2.198', :ovirt__network_name => 'ovirtmgmt',
:ovirt__gateway => '192.168.2.125', :ovirt__netmask => '255.255.0.0',
:ovirt__dns_servers => '192.168.2.1', :ovirt__dns_search => 'test.local'




On Thu, Aug 24, 2017 at 9:32 AM, Yaniv Kaul <ykaul at redhat.com> wrote:

>
>
> On Thu, Aug 24, 2017 at 4:53 PM, Marc Young <3vilpenguin at gmail.com> wrote:
>
>> Per cloud-init, I think that's doable. I added support for cloud-init so
>> Ill see if that can get me going on an easy  path.
>>
>
> Regretfully there's something wrong with the cloud-init on the CirrOS
> image we download, so it doesn't work well.
> Two alternatives I can think of:
> 1. Download a different image - CentOS and Fedora both work well, for
> example. The downside is that it's a bit slow.
> 2. Upload an image using the upload API. This has the advantage that it's
> (1) quicker and (2) will add an additional test to ovirt-system-tests,
> which is always a good idea. There's already an example available (
> https://github.com/oVirt/ovirt-engine-sdk/blob/master/
> sdk/examples/upload_disk.py) .
> Downside: will take a bit of space on the git repo, if the image will be
> on o-s-t git repo.
>
>
>
>>
>> Per uploading: I'm not sure. This might be pretty complex. Vagrant has a
>> concept of boxes (for non local files its usually just a zip folder with a
>> metadata manifest) [1] and uploading to their cloud platform atlas [2] but
>> that kind of gets outside the realm of Vagrant and more into the niche that
>> Packer[3] fits.
>>
>
> Packer support for oVirt is waiting for the Go SDK and for someone to
> implement it.
> Y.
>
>
>> There has been some work on packer with qemu[4] but not oVirt so possibly
>> thats a good place for another project to fit (ovirt packer provider)
>>
>> [1] https://github.com/myoung34/vagrant-ovirt4/tree/master/example_box
>> [2] https://www.vagrantup.com/docs/boxes.html
>> [3] https://www.packer.io/
>> [4] https://www.packer.io/docs/builders/qemu.html
>>
>> On Thu, Aug 24, 2017 at 8:17 AM, Barak Korren <bkorren at redhat.com> wrote:
>>
>>> On 24 August 2017 at 15:35, Marc Young <3vilpenguin at gmail.com> wrote:
>>> >
>>> > Vagrant requires coming up from a template (and a modified one at that
>>> [1].
>>>
>>> I was wondering about this approach. Could things be changed so that a
>>> vanilla image (Like the ones hosted on oVirt Glance) and a cloud-init
>>> script would be sufficient?
>>>
>>> It would be even better if Vargant could upload the images from
>>> libvirt boxes directly into oVirt.
>>>
>>> --
>>> Barak Korren
>>> RHV DevOps team , RHCE, RHCi
>>> Red Hat EMEA
>>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/lago-devel/attachments/20170905/4307ad01/attachment.html>