openstack team mailing list archive
Mailing list archive
Re: RHEL / CentOS - interfaces.template
Scott Moser <smoser@xxxxxxxxxx>
Joshua Harlow <harlowja@xxxxxxxxxxxxx>
Wed, 15 Feb 2012 13:27:29 -0800
[Openstack] RHEL / CentOS - interfaces.template
Sounds great to me.
Looking forward to that. In the mean-time should there be an attempt at getting something into essex (or not?) that may just be what the grid-dynamics people have done? Thoughts?
On 2/15/12 1:25 PM, "Scott Moser" <smoser@xxxxxxxxxx> wrote:
On Wed, 15 Feb 2012, Joshua Harlow wrote:
> Sure that makes sense (less dependency on guest file-systems).
> Although one of my concerns was that I thought this config drive stuff was only in the openstack api and not in the EC2 one.
> So that limits the market there (especially as openstack really needs
> some love given to the EC2 stuff)?
You could most certainly just attach "network config-drive" by default if
nova is not expecting dhcp to work, then that covers the ec2 api case.
> It seems like cloud-init could work with this netcfg "service" and setup the network, that might be the best approach.
> Its just cloud-init needs to be made less distro-centric. Is there any plans for that? It seems like it could do this (or interact with python-netcf).
I have no objections to cloud-init being less distro-centric. Credit to
Garrett Holmstrom , cloud-init is now in Fedora. Its not finished ,
but, the work is at least known.
I personally would much prefer less interaction with the guest as opposed
to more. I realize people will argue for this having something just *try*
to configure the guest's networking via mount and /etc/ insertion of some
mechanism or another. But the issue with that is it can go wrong,
breaking the image, or losing data (ie, by incompletely updating/overwriting
I'm willing to add a blueprint for openstack F and implement "network
config-drive" basically as I've described in the other post.