On 2016-07-28 11:25:20 -0400 (-0400), Sam Hartman wrote: [...] > I tried this last summer and couldn't get network configuration to work > without their agent. > I considered networking a key feature:-) > > Have any idea what I might have been doing wrong? [...]
For a while the only viable option was to check the assigned network information reported for the created instance and then manually update your configuration files by logging in through their virtual console, though that was not convenient. You could also do tricks like triggering an instance rebuild after adjusting a userdata script to embed the desired network config queried separately from the API but that was even more fiddly. (For years I've held that they should have just used DHCP like most other providers but apparently their network implementation is too special to be able to support that easily.) More recently they've started providing network assignment details in structured data on the configdrive (in a format standardized within OpenStack), so you can have a custom initscript/systemd unit consume that or use a tool like glean (I don't see it packaged yet in Debian though, nor any ITP/RFP). Also cloud-init just merged support for this method in recent months, but there was a significant fix for it that landed in trunk two weeks ago so that will probably become a much more viable option once they make their next release. But anyway, as my earlier E-mail stated, their custom "nova-agent" daemon does at least appear to be Apache licensed so presumably suitable for main (or maybe contrib depending on your/ftpmasters' take on the software-depends-on-outside-services issue). My only real beefs with it are that it's not developed within the OpenStack community (rather it's a workaround for Rackspace's nonstandard/divergent network implementation so furthers their image as being a separate special snowflake in an ecosystem that's supposed to be striving for cross-provider standardization), and in the past I've seen them use it to do things like helpfully "correct" my resolver configuration to the point where I ended up flagging /etc/resolv.conf immutable to prevent a recurrence. -- Jeremy Stanley
