Hello.
Den 23 apr 2014 17:10 skrev "Brian Gupta" <brian.gupta@brandorr.com>:
>
> On Wed, Apr 23, 2014 at 9:16 AM, James Bromberger <james@rcpt.to> wrote:
> > On 23/04/2014 4:42 PM, Anders Ingemann wrote:
> >
> > On 23 April 2014 09:17, Charles Plessy <plessy@debian.org> wrote:
> >>
> >> Hello everybody,
> >>
> >> I just received the following bug report on cloud-init.
> >>
> >> Does somebody have experience with secondarly elastic network interfaces ?
> >>
> >> By the way, I have not yet uploaded cloud-init 7.5, since I still have
> >> problems
> >> with the regression tests failign in a minimal environment. Suggestions
> >> are
> >> welcome.
> >>
> >> Have a nice day,
> >
> >
> > In Amazon Linux, additional interfaces (and sub interfaces) is handled by a
> > script in /etc/dhcp/dhclient.d called ec2dhcp.sh. This is under an Apache
> > 2.0 license (http://aws.amazon.com/apache2.0/) - this script is calling
> > functions from /etc/sysconfig/network-scripts/ec2net-functions which is also
> > under an Apache 2.0 license.
> >
> > In essence, these scripts set up additional interfaces and routing tables
> > with metrics and preferences to enable the additional interfaces. Thus far I
> > have not included them in the base Debian AMIs. Time for a community vote:
> > should we adopt these into the Debian AMIs to support the additional
> > interfaces that you may add to your instances, or does this diverge from a
> > base Debian AMI (as per discussions last month)? Are we comfortable with
> > using these verbatim (given the DFSG compatible Apache 2.0 license)?
> >
> > If we get a few people confirm they are happy wit this, then I'll look to
> > include this into bootstrap-vz for the next time we generate new AMIs.
>
> James,
>
> My initial take is that this seems a reasonable approach, if we
> packaged it for sid, and make a backport. However, I would be curious
> to know if (and how) Ubuntu handles this, as coordinating efforts here
> might be useful?
Yes, packning this script so it becomes part of ifupdown ifrastructure would be the proper way. That is how resolveconf solve this by adding configuration directives like dns-servers etc.
I don't think Ubuntu solves this at all, if I understand the bug report correctly.
> The key mitigating difference I think, is:
> a) this is really needed for some VPC cloud use cases
> b) no users who don't need this functionality will be impacted (please confirm)
>
> An alternative approach (if it technically works) would be to still
> package it in backports, but to use cloud-init itself to install the
> package and bring up the interfaces. However, the timing of it might
> not work at all, and even if it does it might be overly complicated?
That would be solved by have cloud-init depend or recommend on this new package. Don't think that is a proper way of solving this.
It should probably be installed early so the contents of /e/n/interfaces can be set up with a proper directive. Like pre-up and post-down running the script or some new directives or a script added to execute to start at the right time.
> Thanks,
> Brian
>
> > James
/Anders J