Hello.

Den 23 apr 2014 17:10 skrev "Brian Gupta" <[email protected]>:
>
> On Wed, Apr 23, 2014 at 9:16 AM, James Bromberger <[email protected]> wrote:
> > On 23/04/2014 4:42 PM, Anders Ingemann wrote:
> >
> > On 23 April 2014 09:17, Charles Plessy <[email protected]> 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

Reply via email to