Open Stack

On Jul 12, 2013, at 6:47 AM, Russell Bryant <rbryant at redhat.com> wrote:

> On 07/12/2013 04:43 AM, Thierry Carrez wrote:
>> Brian Lamar wrote:
>>>> Honestly, I think network injection is evil and I'd rather remove it
>>>> completely. I'm certainly not too interested in trying to add more
>>>> features to it.
>>> 
>>> Can you elaborate on this a little more? Do you not like file injection
>>> or dynamic network allocation?
>> 
>> It's an old discussion... in summary:
>> 
>> Nova inserting stuff pre-booting into the VM it runs = evil, brittle and
>> the source of countless past vulnerabilities
>> 
>> VMs auto-configuring at boot-time using cloud-init based on data
>> provided through generic input channels (config drive, metadata
>> servers...) = good
>> 
>> So this is not about disliking the ability to insert files or specify
>> network parameters for a VM, it's about who is in charge of actually
>> creating files and network configurations. Nova shouldn't have to learn
>> about the specificities of the VM image it runs, nor should it have to
>> mount VM filesystems before booting them. The VM itself should take care
>> of the translation based on standardized input (if it wants to).
> 
> Thank you for the nice summary.  :-)
> 
>>> Can you provide alternative strategies that could be applied to solve
>>> the issue of dynamically brining up interfaces or do you think this is
>>> out of the project scope (controlling the internals of VMs)?
>> 
>> Config-drive should pass that config to the VM, and cloud-init on the VM
>> should pick it up.
> 
> Or you can use the metadata server instead of config-drive.

Speaking of which, the openstack metadata endpoint (and openstack config-drive endpoint) need(s) to gain information about the interfaces attached to the instance. This was discussed during the grizzly summit, but it was never added. That way an agent like cloud-init can be expected to configure the second/third/fourth interfaces correctly.

Vish

> 
> -- 
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev