[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of the Cloud Images BoF at DC16



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


Reply to: