Re: [openstack-dev] [Openstack] Improve inject network configuration
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). 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. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Improve inject network configuration
On 12 July 2013 20:43, Thierry Carrez thie...@openstack.org 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). 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 the instance should just auto-adjust. Chris Jones wrote some code for that for tripleo, but we can't use it until we can disable file injection... and I can't find where we stashed it. Chris? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Improve inject network configuration
On 07/12/2013 01:10 AM, Brian Lamar wrote: Russell Bryant wrote: On 07/11/2013 08:53 PM, Jae Sang Lee wrote: Hi, stackers. When creating vm using multi nics, User should power up the second interface on the instance manually for use second IP. http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html I intend to fix interfaces.template file, so It can be possible power up other interface during booting time automatically. I registered blueprint for this a month ago.(https://blueprints.launchpad.net/nova/+spec/better-network-injection) But not yet approved. If you have permission to approve who read this mail, please approve my blueprint. 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? File injection in general. 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)? -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Improve inject network configuration
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. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack] Improve inject network configuration
Hi, stackers. When creating vm using multi nics, User should power up the second interface on the instance manually for use second IP. http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html I intend to fix interfaces.template file, so It can be possible power up other interface during booting time automatically. I registered blueprint for this a month ago.( https://blueprints.launchpad.net/nova/+spec/better-network-injection) But not yet approved. If you have permission to approve who read this mail, please approve my blueprint. Thanks. Jay Lee ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Improve inject network configuration
Russell Bryant wrote: On 07/11/2013 08:53 PM, Jae Sang Lee wrote: Hi, stackers. When creating vm using multi nics, User should power up the second interface on the instance manually for use second IP. http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html I intend to fix interfaces.template file, so It can be possible power up other interface during booting time automatically. I registered blueprint for this a month ago.(https://blueprints.launchpad.net/nova/+spec/better-network-injection) But not yet approved. If you have permission to approve who read this mail, please approve my blueprint. 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? 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)? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
