10:17 p.m.
On 02/27/2012 09:14 PM, David Lutterkort wrote:
On Mon, 2012-02-27 at 18:22 +0200, Itamar Heim wrote:
> On 02/27/2012 05:45 PM, Dan Kenigsberg wrote:
>> On Mon, Feb 27, 2012 at 04:19:02PM +0200, Shahar Havivi wrote:
>>> We encounter a problem with persisting the content to engine database (we
don't
>>> want to save the file the database).
>>>
>>> There are some solution for that:
>>> 1. we do want to persist files to the database (with size limitation).
>>> 2. engine can expect file path (nfs or http) and persist only the file url
>>> 3. we can use this feature in run-once only hence no persistence is needed.
>
> i think size limitation should be ok.
Yes, this only needs to allow for a small amount of data; EC2 limits it
to 16k (though they further limit it to 2k in certain circumstances[1])
Other providers have similar limits. In general, people pass only a few
hundred bytes in in most cases, so a limit of 16k is plenty.
> looking forward to next phase of supporting the cloud based api for
> guests which david mentioned earlier in the thread, vm payload should
> allow passing things like guest keypair files.
> looking at the API[1] david mentioned, i didn't notice files other than
> keypair's, but i may have missed them.
> the rest of the API seems to be based on data that can be retrieved from
> the DB.
> David - any more insight as to when/how files are needed?
A good thing to look at is cloud-init; it's a widely used tool for early
initialization of cloud instances. Yes, by far the most important thing
it does is retrieve the public key from the meta-data server and stuffs
it into $USER/.ssh/authroized_keys (USER is either root or sth like
ec2-user, depending on the image)
> (btw, can you please remind where in the metadata do you pass extra
> information aelous needs?)
For Aeolus, it passes all the information it needs to talk to its config
server and pull down additional things as the user-data. The format is
completely custom, and the cloud platform only needs to make sure that
the data that's passed in through the API shows up in the instance - it
should be completely opaque to the oVirt.
can you give a pointer how/where in the EC2 api this would appear under?
>>>
>>> Thoughts, other ideas?
>>
>> Let's re-ask the question about the (Engine) API: Do we need the payload
>> to be passed on VM definition? Or is it enough to pass it on VM startup?
>
> my view is vm definition, not only startup.
For a cloud, you generally want to launch multiple VM's off the same
image, and therefore need to be able to specify the user data for each
VM. Whether that happens when you define or launch the VM isn't all that
important, though it would be a little friendlier to users to do it at
VM start, since they then do not need to have the user data ready (or
know it) when they define a VM.
well, true for cloud when image start is also creating the instance,
while in ovirt, at least for now, you need to create the VM then launch it.
i agree you need to be able to pass this at VM start, but considering VM
are mostly stateful, i don't see why you wouldn't let user persist this
like the VM is presistent.