Re: Our Networking Story

2014-03-10 Thread TJ
On 10/03/14 16:14, Dale Amon wrote:
 On Mon, Mar 10, 2014 at 09:49:02AM +0100, Oliver Grawert wrote:
 network manager stores its system connection info in a text file in .ini
 style format in /etc/NetworkManager/system-connections
 
 Thanks for that pointer... but there is nothing in there about
 eth0, only the WiFi connections past and present.
 
 I was sort of hoping for a control file that would let me
 command network manager Don't use eth0 until I come back and
 allow you to do so again.
 
 And yes, I can see all sorts of issues between it and the 
 interfaces file, but if there are going to be two ways to
 control interfaces, that needs to be sorted eventually.
 
 But I'll settle for a good way to reliably switch eth0
 back and forth between netmanager and the interfaces files.

man networkmanager.conf

Section: [main], no-auto-default=

 Set devices for which NetworkManager shouldn't create default wired 
connection (Auto eth0). NetworkManager creates
  a default wired connection for any wired device that is managed and doesn't 
have a connection configured. List a
  device in this option to inhibit creating the default connection for the 
device.

Section: [ifupdown], managed=

 Controls whether interfaces listed in the 'interfaces' file are managed by 
NetworkManager.

man nmcli

Object: dev, disconnect

 Disconnect a device and prevent the device from automatically activating 
further connections without user/manual intervention.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Robie Basak
On Thu, Mar 06, 2014 at 02:48:52PM -0500, Bryan Quigley wrote:
 We've had a lot of internal Canonical discussions about our networking
 story and before going to a UDS session [1] it was suggested to post to
 ubuntu-devel.
 
 *Network Restart*
 I'd like to start by asking each of you what you think is the correct way
 to restart networking on Ubuntu server?  Feel free to write it down and
 include it in any replies :).

I don't think it's possible to define restart networking in a way that
everybody understands, and in a way that will always work on complex
configurations.

Instead, I think that we need to focus on *why* you need to restart
networking.

Did you change an interface entry in /etc/network/interfaces{,.d}? Then
ifdown before, and ifup after. Or do others disagree?

Something more complicated? Then I guess we need to consider your
specific use cases. What are they, please?

This reminds me of this bug:
https://bugs.launchpad.net/juju-core/+bug/1248283

Daemons can't be expected to continue working if they are (for example)
listening on an interface that disappears. This is why restart
networking is difficult. We could say that they should do so and patch
them all to add handling of a network is down state, or we could
adjust all upstart jobs to automatically stop and start daemons as
required as networking is restarted. But I'm not sure this makes
sense.

 It turns out our documentation has been wrong and the following are not
 correct and more importantly don't work consistently over 10.04/12.04/14.04
 [2]:
 sudo /etc/init.d/networking restart
 sudo restart networking
 
 The correct way I've been told is to use the ifupdown scripts. It's
 important to note that this is different on the desktop due to
 network-manager.
 
 I feel we need to publicly discuss if we really want the ifupdown scripts
 to be the only supported way to manage/restart networking.  We've been
 communicating the opposite for quite some time now..

Thank you for bringing this up. It's certainly important if our
documentation is wrong, or we're short of clarity on the process. I
think we should certainly have a blueprint to assign work items to
ensure that all our understanding and documentation is consistent.
Exactly what would we discuss in a session, though, that we can't do on
a mailing list? Is there any controversy here that we need to resolve?

 Related question:
 Do we not support giving users the ability to restart networking equivalent
 to rebooting the system?  (Upstart is used when booting, not when manually
 doing the ifupdown scripts).

I'd say no, because restarting networking as a general concept isn't
well-defined and unsupported by various components that depend on it
being there. However, I would certainly like to see particular
operations work smoothly without requiring a reboot. Are there specific
cases that do not work well here?

 *More complicated network setups*
 There are many bugs in regards to bonds/vlans/bridging and other more
 complex networking setups.  It appears like it might be a limitation to how
 ifupdown is designed.
 
 We have had cases where the MTU needs to be set using a pre-up or post-up
 option in the interfaces file instead of a plain MTU line.
 Bond interfaces can cause significant pausing in boot/network restart
 The ifupdown script doesn't actually work on bonded interfaces [3]
 
 race condition updating statefile sometimes networking interfaces won't
 come up - was fixed [4]-
 
 We are seeing many more of cases involving complicated networking setups
 and with more OpenStack deployments this is going to become more of the
 norm.

It would be great to see some effort on prioritising these bugs, and
driving them (presumably in Debian also?) as part of a blueprint.

 My understanding is that ifupdown was not designed to handle a parallel
 boot process like Upstart or systemd.  I'm guessing there are a lot more
 bugs lurking due to that, aside from some other issues with the codebase
 [5].

What specific solutions are being proposed here?

Robie


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Robie Basak
On Thu, Mar 06, 2014 at 01:32:17PM -0800, Benjamin Kerensa wrote:
 Why was it  necessary to have discussions internally when they could
 have been open by default?

(wearing both my Canonical and Ubuntu hats)

Are Canonical employees not allowed to speak to each other now? I think
you're being unreasonable. As far as I can tell, Bryan spoke to his
colleagues about specific problems, reached consensus with his
colleagues that these are real problems that affect Ubuntu more
generally, and has brought his problem set and thoughts up for public
discussion on public mailing lists and at UDS. He's done this (as far as
I can tell) before any implementation, or even any thought as to what
any decision Ubuntu makes should be.

Note that I (Canonical Server Team + Ubuntu Server Team) am as new to
this as you are. I'm not aware of any prior internal discussion. The
first I heard of this was when he asked, on a public IRC channel, to
have the blueprint that he'd written approved, and I (remember, I'm
Canonical staff) asked him to email the public list to make sure that
his concerns reach as wide a public audience as possible.

He's done exactly the right thing, and now you're berating him for this?


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Robie Basak
On Thu, Mar 06, 2014 at 11:32:41PM +0100, Stanisław Hodur wrote:
 If talking about the network, I would add:
 
 *Wifi + Ethernet on Desktop*
 The network gets lost if you have both wireless and Ethernet connection.
 The wired network should be the preferred one, as it is usually
 faster. Or else, the recently connected/enabled can become active.
 Anyway, plugging in should not spoil the connection, as it does now
 -- I have to disable wireless network manually to get the eth
 working.

This sounds like a straightforward issue that can be solved in one
component (NetworkManager), and it just needs someone to work with
upstream and get it done.

If I understand you correctly, I have the same issue. To work around, I
have static IP entries defined in NetworkManager, with neither on
automatic. Then I just disconnect one before connecting the other, and
my laptop roams between wifi and wired ethernet seamlessly.


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Robie Basak
On Thu, Mar 06, 2014 at 10:44:07PM -0800, Dale Amon wrote:
 On Thu, Mar 06, 2014 at 11:32:41PM +0100, Stanisław Hodur wrote:
  *Wifi + Ethernet on Desktop*
 
 Which reminds me of another common use of machines that a typical
 GUI user won't think of.
 
 I often configure laptops that for security have wifi, bluetooth
 etc all turned off at BIOS level, and the only ethernet connection
 is not to the internet but to a disconnected network that attaches
 to real, live and quite serious equipment (don't think computer 
 equipment think *equipment*). I really appreciate it when network 
 manager doesn't fight with me over the eth not having any external 
 gateway. I get really annoyed if it does that, but with saucy
 network-manager and I have at least a temporary truce. It lets
 me do what I want with eth1 in interfaces and doesn't try to turn 
 it off. And yes, in a previous version it did do that... I used
 to have to shut it down or even de-install it.

So it works, and you have no problem now?


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Scott Kitterman
On Friday, March 07, 2014 12:57:37 Robie Basak wrote:
 On Thu, Mar 06, 2014 at 01:32:17PM -0800, Benjamin Kerensa wrote:
  Why was it  necessary to have discussions internally when they could
  have been open by default?
 
 (wearing both my Canonical and Ubuntu hats)
 
 Are Canonical employees not allowed to speak to each other now? I think
 you're being unreasonable. As far as I can tell, Bryan spoke to his
 colleagues about specific problems, reached consensus with his
 colleagues that these are real problems that affect Ubuntu more
 generally, and has brought his problem set and thoughts up for public
 discussion on public mailing lists and at UDS. He's done this (as far as
 I can tell) before any implementation, or even any thought as to what
 any decision Ubuntu makes should be.
 
 Note that I (Canonical Server Team + Ubuntu Server Team) am as new to
 this as you are. I'm not aware of any prior internal discussion. The
 first I heard of this was when he asked, on a public IRC channel, to
 have the blueprint that he'd written approved, and I (remember, I'm
 Canonical staff) asked him to email the public list to make sure that
 his concerns reach as wide a public audience as possible.
 
 He's done exactly the right thing, and now you're berating him for this?

That's good to know.

On the subject of not berating though, that was not at all clear from the 
initial message.  It could well have been a synonym for we've worked this out 
internally and now we're going to roll out to the community what we decided.  
It's not like that doesn't happen either.  

Scott K

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Bryan Quigley
On Fri, Mar 7, 2014 at 1:34 AM, Dale Amon a...@vnl.com wrote:
 The only feature I hold near and dear is that I be able
 to ssh into a server in a rack 8000 miles away, fiddle
 with /etc/network/interfaces if needed, and then reliably
 ifdown/ifup one of god knows how many connections (I often
 work with machines that have 8 or even more hardware ethers,
 not to mention ethn:m's.

 Just a begging note to think of the systems guys who are
 making bulk changes using scripts that execute scripts on
 5, 10, a hundred or a thousand server (I know guys who do
 that).

 Lots of us only use a GUI as a place to let us keep 40
 xterm's available...

Could you detail what process you are exactly using to do this
reliably?  Are you using bonds/vlans/bridging?

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Bryan Quigley
On Fri, Mar 7, 2014 at 7:44 AM, Robie Basak robie.ba...@ubuntu.com wrote:
 I don't think it's possible to define restart networking in a way that
 everybody understands, and in a way that will always work on complex
 configurations.

 Instead, I think that we need to focus on *why* you need to restart
 networking.
Example:  A user wants to setup a complicated network setup on many
machines via Puppet.  They don't want to have to know the machines
current state for puppet to be able to take it over and do the right
thing.  (that's a key point of using puppet, btw)


 Did you change an interface entry in /etc/network/interfaces{,.d}? Then
 ifdown before, and ifup after. Or do others disagree?
The order seems to be something like this:
1. bring down all the related things that might be using interfaces
you plan to change (dhcpclient, manually disable the bond, etc)
2. Ifdown the interfaces you want to change
3. Make the change in interfaces
4.  Ifup the interfaces
5.  Maybe you need to bring some daemons back up?

 adjust all upstart jobs to automatically stop and start daemons as
 required as networking is restarted. But I'm not sure this makes
 sense.
That doesn't seems illogical to me.

 Thank you for bringing this up. It's certainly important if our
 documentation is wrong, or we're short of clarity on the process. I
 think we should certainly have a blueprint to assign work items to
 ensure that all our understanding and documentation is consistent.
 Exactly what would we discuss in a session, though, that we can't do on
 a mailing list? Is there any controversy here that we need to resolve?

I, and many others, believe that the ifupdown scripts are not good
enough for the general case problem.   Furthermore,
sudo /etc/init.d/networking restart; seems to Just Work on 10.04
sudo restart networking;  seems to Just Work on 14.04

Why doesn't either of these work on 12.04?   And why can't we
recommend to do sudo restart networking on 14.04?

Basically, why is ifupdown better?

 I'd say no, because restarting networking as a general concept isn't
 well-defined and unsupported by various components that depend on it
 being there. However, I would certainly like to see particular
 operations work smoothly without requiring a reboot. Are there specific
 cases that do not work well here?

At a basic level, customers want to be assured that when they restart
networking settings it will be equivalent to a restart.   Since they
are operated on in different ways via ifupdown vs Upstart (w/ ifupdown
too), it's my understanding that we can not make that guarantee.
Their interfaces file could be incorrect for a parallel boot, but work
fine w/ ifupdown directly or vice versa.

 It would be great to see some effort on prioritising these bugs, and
 driving them (presumably in Debian also?) as part of a blueprint.
That would definitely be part of the proposed session.


 My understanding is that ifupdown was not designed to handle a parallel
 boot process like Upstart or systemd.  I'm guessing there are a lot more
 bugs lurking due to that, aside from some other issues with the codebase
 [5].

 What specific solutions are being proposed here?
A need for more networking QA.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Bryan Quigley
On Fri, Mar 7, 2014 at 11:15 AM, Paul Smith p...@mad-scientist.net wrote:
 I'm not sure this level of detail is needed.

 I've not tried this on Ubuntu, so maybe it already works fine, but
 similar to the OP's request on remote Red Hat systems it is always
 supported to run:

   service network restart

 and know that your ssh session will not be dropped while the network
 restarts (unless you screwed up the network config and it doesn't come
 back up of course).

 This also works:

   service network stop  service network start

 Of course, trying to run stop followed by a start in a different
 command line can't work:

   service network stop
 ... uhm ... oops ... time for a drive!!

 I think the request is that there be a straightforward restart option
 that is ensured to not drop the connection (assuming, again, that the
 start works properly and you haven't changed details of the connection
 you were using).

This my point.  Doesn't that make sense ^.   None of it works on 12.04.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Dale Amon
On Fri, Mar 07, 2014 at 01:02:33PM +, Robie Basak wrote:
 On Thu, Mar 06, 2014 at 10:44:07PM -0800, Dale Amon wrote:
  I often configure laptops that for security have wifi, bluetooth
  etc all turned off at BIOS level, and the only ethernet connection
  is not to the internet but to a disconnected network that attaches
  to real, live and quite serious equipment (don't think computer 
  equipment think *equipment*). I really appreciate it when network 
  manager doesn't fight with me over the eth not having any external 
  gateway. I get really annoyed if it does that, but with saucy
  network-manager and I have at least a temporary truce. It lets
  me do what I want with eth1 in interfaces and doesn't try to turn 
  it off. And yes, in a previous version it did do that... I used
  to have to shut it down or even de-install it.
 
 So it works, and you have no problem now?

This is for the general discussion, an example of mission critical
usage of the networking infrastructure that should be taken into
consideration as people work through their ideas on where
networking control is going.

As to your question, yes, until the next release. I always face
version upgrades with trepidation. I've still not fully recovered 
from the upgrade to saucy on my laptop. The list of things that
broke is getting shorter, but I only get a few hours free each
weekend to even think about it.





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Dale Amon
On Fri, Mar 07, 2014 at 09:39:40AM -0500, Bryan Quigley wrote:
  Lots of us only use a GUI as a place to let us keep 40
  xterm's available...
 
 Could you detail what process you are exactly using to do this
 reliably?  Are you using bonds/vlans/bridging?

On my current job, I am using a laptop that goes out to run
test gear on a remote test stand. I turn off wifi; there is
no wire on eth0 and I use a USB dongle for an eth1. I have
a simple subnet in RFC 1918 space that I bring up with an 
ifup on site. I've found over the years that network manager
tries really hard to bring up an external connection and 
it owns eth0 from boot time, but not the USB that I plug in
later.

As to other configurations, on servers I just remove network
manager and everything to do with it because its too high
a risk. It is hard to nail down specific scenarios because
(up until two years ago) I worked as a gypsy consultant, 
hopping from one customer to another and fixing things. Mostly
though, you set up an interfaces file, work out any of the
funky issues... and then it may not change for years. If
something goes wrong I might have to remotely go in and
reset or tweak something.

Hard to get more specific. It all muddles together over
the years but I have dealt with most things. Not a lot of
bonding, although I did work with a 'big iron' Intel 
modular server with a modular and programmable block
of ethers that gave myself and two other engineers a merry 
chase until we finally beat it into submission... but that
was not a Linux problem per se, although we were running
Linux on the modules.

Just take this as a general plea to keep things simple and
always in ASCII config files so that some poor SOB who
has to fix something in the middle of the night over an 
a possibly intercontinental connection via ssh or IP to RS232
gateway while fiddling with a remote power control unit
to power cycle it... 




-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-07 Thread Soren Hansen
Sorry for sending this to you twice, Bryan, but my first attempt is stuck in
the moderation queue.

2014-03-07 1:18 GMT+05:30 Bryan Quigley bryan.quig...@canonical.com:
 *Network Restart*

 I'd like to start by asking each of you what you think is the correct
 way to restart networking on Ubuntu server?  Feel free to write it
 down and include it in any replies :).

Depends on why you're restarting the network.

If I've just changed an IP address, I'd probably do an ifdown $IFACE;
ifup $IFACE in screen or something. If the changes are more involved
than that, you need to be careful. One scenario I've seen countless
times is this:

1. Install Ubuntu Server on a network with DHCP.
2. Log in afterwards to switch to static IP's.
3. Change /etc/network/interfaces to have the static config.
4. Restart networking (using whichever of the methods you give as
   examples).
5. Verify that their static address is correctly assigned.
6. Come back an hour later and see that it's now using DHCP again.
7. Come to #ubuntu-server and complain.

What most people fail to realise (or consider) is that ifdown reads the
*current* configuration to see what to do. So when you've booted with
DHCP (and thus have a dhcp client running in the background), change
/etc/network/interfaces and run ifdown (directly or by way of
/etc/init.d/networking or whatever), ifdown has no clue that there's a
dhcp client that it needs to worry about. It just deconfigures that
interfaces as it would have any other statically configured interface,
because that's what /etc/network/interfaces says it should do.

When it's ifup'ed again, it gets the right address assigned, but the
dhcp client is still running in the background, waiting to screw up your
network config once the lease is about to expire.

This is a common example, but the same issue applies when you're
adding/removing up/pre-up/down/post-down commands. People usually
remember to make sure that anything you establish during up (or pre-up)
you also tear down in down (or post-down), but if you add or remove
things, you need to remember this caveat when restarting networking.

Depending on how helpful I feel when people ask this on #ubuntu-server,
I either explain this or just tell them to reboot. *shrug*

--
Soren Hansen
Ubuntu Developerhttp://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Our Networking Story

2014-03-06 Thread Bryan Quigley
We've had a lot of internal Canonical discussions about our networking
story and before going to a UDS session [1] it was suggested to post to
ubuntu-devel.

*Network Restart*
I'd like to start by asking each of you what you think is the correct way
to restart networking on Ubuntu server?  Feel free to write it down and
include it in any replies :).

It turns out our documentation has been wrong and the following are not
correct and more importantly don't work consistently over 10.04/12.04/14.04
[2]:
sudo /etc/init.d/networking restart
sudo restart networking

The correct way I've been told is to use the ifupdown scripts. It's
important to note that this is different on the desktop due to
network-manager.

I feel we need to publicly discuss if we really want the ifupdown scripts
to be the only supported way to manage/restart networking.  We've been
communicating the opposite for quite some time now..

Related question:
Do we not support giving users the ability to restart networking equivalent
to rebooting the system?  (Upstart is used when booting, not when manually
doing the ifupdown scripts).


*More complicated network setups*
There are many bugs in regards to bonds/vlans/bridging and other more
complex networking setups.  It appears like it might be a limitation to how
ifupdown is designed.

We have had cases where the MTU needs to be set using a pre-up or post-up
option in the interfaces file instead of a plain MTU line.
Bond interfaces can cause significant pausing in boot/network restart
The ifupdown script doesn't actually work on bonded interfaces [3]

race condition updating statefile sometimes networking interfaces won't
come up - was fixed [4]-

We are seeing many more of cases involving complicated networking setups
and with more OpenStack deployments this is going to become more of the
norm.

My understanding is that ifupdown was not designed to handle a parallel
boot process like Upstart or systemd.  I'm guessing there are a lot more
bugs lurking due to that, aside from some other issues with the codebase
[5].

*Future Releases*
NetworkManager everywhere?  systemd-networkd?

Thanks for discussing,
Bryan


[1]
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1403-networking
[2] If you want to see where those actually work see my document here:
https://docs.google.com/document/d/1OBN3efJ1LmA0-0DzD3K0eUkIuQdscxLQ-QO1yi3bHeM/edit
[3] https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1254120
[4] https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1160490
[5]
http://pureperl.blogspot.com/2013/01/the-debian-ifupdown-package-and.html
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-06 Thread Benjamin Kerensa
Why was it  necessary to have discussions internally when they could
have been open by default?

On Thu, Mar 6, 2014 at 11:48 AM, Bryan Quigley
bryan.quig...@canonical.com wrote:
 We've had a lot of internal Canonical discussions about our networking story
 and before going to a UDS session [1] it was suggested to post to
 ubuntu-devel.

 *Network Restart*
 I'd like to start by asking each of you what you think is the correct way to
 restart networking on Ubuntu server?  Feel free to write it down and include
 it in any replies :).

 It turns out our documentation has been wrong and the following are not
 correct and more importantly don't work consistently over 10.04/12.04/14.04
 [2]:
 sudo /etc/init.d/networking restart
 sudo restart networking

 The correct way I've been told is to use the ifupdown scripts. It's
 important to note that this is different on the desktop due to
 network-manager.

 I feel we need to publicly discuss if we really want the ifupdown scripts to
 be the only supported way to manage/restart networking.  We've been
 communicating the opposite for quite some time now..

 Related question:
 Do we not support giving users the ability to restart networking equivalent
 to rebooting the system?  (Upstart is used when booting, not when manually
 doing the ifupdown scripts).


 *More complicated network setups*
 There are many bugs in regards to bonds/vlans/bridging and other more
 complex networking setups.  It appears like it might be a limitation to how
 ifupdown is designed.

 We have had cases where the MTU needs to be set using a pre-up or post-up
 option in the interfaces file instead of a plain MTU line.
 Bond interfaces can cause significant pausing in boot/network restart
 The ifupdown script doesn't actually work on bonded interfaces [3]

 race condition updating statefile sometimes networking interfaces won't
 come up - was fixed [4]-

 We are seeing many more of cases involving complicated networking setups and
 with more OpenStack deployments this is going to become more of the norm.

 My understanding is that ifupdown was not designed to handle a parallel boot
 process like Upstart or systemd.  I'm guessing there are a lot more bugs
 lurking due to that, aside from some other issues with the codebase [5].

 *Future Releases*
 NetworkManager everywhere?  systemd-networkd?

 Thanks for discussing,
 Bryan


 [1]
 https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1403-networking
 [2] If you want to see where those actually work see my document here:
 https://docs.google.com/document/d/1OBN3efJ1LmA0-0DzD3K0eUkIuQdscxLQ-QO1yi3bHeM/edit
 [3] https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1254120
 [4] https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1160490
 [5]
 http://pureperl.blogspot.com/2013/01/the-debian-ifupdown-package-and.html

 --
 Ubuntu-devel-discuss mailing list
 Ubuntu-devel-discuss@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss




-- 
Benjamin Kerensa
http://benjaminkerensa.com
I am what I am because of who we all are - Ubuntu

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-06 Thread Dimitri John Ledkov
On 6 March 2014 21:32, Benjamin Kerensa bkere...@ubuntu.com wrote:
 Why was it  necessary to have discussions internally when they could
 have been open by default?


Eh... this particular bug is public and well known in both Debian and
Ubuntu for a long time now.
As you can see in that email, he references a few things dating back
more than a year ago, but there is more one can dig through in
launchpad bug reports.

It's just it's making a new round of discussions about it, and he is
bringing this topic up at the upcomming UDS and is advertising the
session in advance =) to gather together relevant people.

Also, please do not top post, on ubuntu mailing list.

Regards,

Dimitri.

ps. Didn't you part Ubuntu Community?!


 On Thu, Mar 6, 2014 at 11:48 AM, Bryan Quigley
 bryan.quig...@canonical.com wrote:
 We've had a lot of internal Canonical discussions about our networking story
 and before going to a UDS session [1] it was suggested to post to
 ubuntu-devel.

 *Network Restart*
 I'd like to start by asking each of you what you think is the correct way to
 restart networking on Ubuntu server?  Feel free to write it down and include
 it in any replies :).

 It turns out our documentation has been wrong and the following are not
 correct and more importantly don't work consistently over 10.04/12.04/14.04
 [2]:
 sudo /etc/init.d/networking restart
 sudo restart networking

 The correct way I've been told is to use the ifupdown scripts. It's
 important to note that this is different on the desktop due to
 network-manager.

 I feel we need to publicly discuss if we really want the ifupdown scripts to
 be the only supported way to manage/restart networking.  We've been
 communicating the opposite for quite some time now..

 Related question:
 Do we not support giving users the ability to restart networking equivalent
 to rebooting the system?  (Upstart is used when booting, not when manually
 doing the ifupdown scripts).


 *More complicated network setups*
 There are many bugs in regards to bonds/vlans/bridging and other more
 complex networking setups.  It appears like it might be a limitation to how
 ifupdown is designed.

 We have had cases where the MTU needs to be set using a pre-up or post-up
 option in the interfaces file instead of a plain MTU line.
 Bond interfaces can cause significant pausing in boot/network restart
 The ifupdown script doesn't actually work on bonded interfaces [3]

 race condition updating statefile sometimes networking interfaces won't
 come up - was fixed [4]-

 We are seeing many more of cases involving complicated networking setups and
 with more OpenStack deployments this is going to become more of the norm.

 My understanding is that ifupdown was not designed to handle a parallel boot
 process like Upstart or systemd.  I'm guessing there are a lot more bugs
 lurking due to that, aside from some other issues with the codebase [5].

 *Future Releases*
 NetworkManager everywhere?  systemd-networkd?

 Thanks for discussing,
 Bryan


 [1]
 https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1403-networking
 [2] If you want to see where those actually work see my document here:
 https://docs.google.com/document/d/1OBN3efJ1LmA0-0DzD3K0eUkIuQdscxLQ-QO1yi3bHeM/edit
 [3] https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1254120
 [4] https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1160490
 [5]
 http://pureperl.blogspot.com/2013/01/the-debian-ifupdown-package-and.html

 --
 Ubuntu-devel-discuss mailing list
 Ubuntu-devel-discuss@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss




 --
 Benjamin Kerensa
 http://benjaminkerensa.com
 I am what I am because of who we all are - Ubuntu

 --
 Ubuntu-devel-discuss mailing list
 Ubuntu-devel-discuss@lists.ubuntu.com
 Modify settings or unsubscribe at: 
 https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Regards,

Dimitri.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-06 Thread Stanisław Hodur

If talking about the network, I would add:

*Wifi + Ethernet on Desktop*
The network gets lost if you have both wireless and Ethernet connection.
The wired network should be the preferred one, as it is usually faster. 
Or else, the recently connected/enabled can become active. Anyway, 
plugging in should not spoil the connection, as it does now -- I have to 
disable wireless network manually to get the eth working.


Best regards
Stanislaus

W dniu 2014-03-06 20:48, Bryan Quigley pisze:
We've had a lot of internal Canonical discussions about our networking 
story and before going to a UDS session [1] it was suggested to post 
to ubuntu-devel.


*Network Restart*
I'd like to start by asking each of you what you think is the correct 
way to restart networking on Ubuntu server? Feel free to write it down 
and include it in any replies :).


It turns out our documentation has been wrong and the following are 
not correct and more importantly don't work consistently over 
10.04/12.04/14.04 [2]:

sudo /etc/init.d/networking restart
sudo restart networking

The correct way I've been told is to use the ifupdown scripts. It's 
important to note that this is different on the desktop due to 
network-manager.


I feel we need to publicly discuss if we really want the ifupdown 
scripts to be the only supported way to manage/restart networking.  
We've been communicating the opposite for quite some time now..


Related question:
Do we not support giving users the ability to restart networking 
equivalent to rebooting the system?  (Upstart is used when booting, 
not when manually doing the ifupdown scripts).



*More complicated network setups*
There are many bugs in regards to bonds/vlans/bridging and other more 
complex networking setups.  It appears like it might be a limitation 
to how ifupdown is designed.


We have had cases where the MTU needs to be set using a pre-up or 
post-up option in the interfaces file instead of a plain MTU line.

Bond interfaces can cause significant pausing in boot/network restart
The ifupdown script doesn't actually work on bonded interfaces [3]

race condition updating statefile sometimes networking interfaces 
won't come up - was fixed [4]-


We are seeing many more of cases involving complicated networking 
setups and with more OpenStack deployments this is going to become 
more of the norm.


My understanding is that ifupdown was not designed to handle a 
parallel boot process like Upstart or systemd.  I'm guessing there are 
a lot more bugs lurking due to that, aside from some other issues with 
the codebase [5].


*Future Releases*
NetworkManager everywhere?  systemd-networkd?

Thanks for discussing,
Bryan


[1] 
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1403-networking
[2] If you want to see where those actually work see my document here: 
https://docs.google.com/document/d/1OBN3efJ1LmA0-0DzD3K0eUkIuQdscxLQ-QO1yi3bHeM/edit

[3] https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1254120
[4] https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1160490
[5] 
http://pureperl.blogspot.com/2013/01/the-debian-ifupdown-package-and.html





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-06 Thread Scott Kitterman
On Thursday, March 06, 2014 14:48:52 Bryan Quigley wrote:
 We've had a lot of internal Canonical discussions about our networking
 story and before going to a UDS session [1] it was suggested to post to
 ubuntu-devel.
 
 *Network Restart*
 I'd like to start by asking each of you what you think is the correct way
 to restart networking on Ubuntu server?  Feel free to write it down and
 include it in any replies :).
 
 It turns out our documentation has been wrong and the following are not
 correct and more importantly don't work consistently over 10.04/12.04/14.04
 [2]:
 sudo /etc/init.d/networking restart
 sudo restart networking
 
 The correct way I've been told is to use the ifupdown scripts. It's
 important to note that this is different on the desktop due to
 network-manager.
 
 I feel we need to publicly discuss if we really want the ifupdown scripts
 to be the only supported way to manage/restart networking.  We've been
 communicating the opposite for quite some time now..
 
 Related question:
 Do we not support giving users the ability to restart networking equivalent
 to rebooting the system?  (Upstart is used when booting, not when manually
 doing the ifupdown scripts).
 
 
 *More complicated network setups*
 There are many bugs in regards to bonds/vlans/bridging and other more
 complex networking setups.  It appears like it might be a limitation to how
 ifupdown is designed.
 
 We have had cases where the MTU needs to be set using a pre-up or post-up
 option in the interfaces file instead of a plain MTU line.
 Bond interfaces can cause significant pausing in boot/network restart
 The ifupdown script doesn't actually work on bonded interfaces [3]
 
 race condition updating statefile sometimes networking interfaces won't
 come up - was fixed [4]-
 
 We are seeing many more of cases involving complicated networking setups
 and with more OpenStack deployments this is going to become more of the
 norm.
 
 My understanding is that ifupdown was not designed to handle a parallel
 boot process like Upstart or systemd.  I'm guessing there are a lot more
 bugs lurking due to that, aside from some other issues with the codebase
 [5].
 
 *Future Releases*
 NetworkManager everywhere?  systemd-networkd?
 
 Thanks for discussing,
 Bryan
 
 
 [1]
 https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1403-networking
 [2] If you want to see where those actually work see my document here:
 https://docs.google.com/document/d/1OBN3efJ1LmA0-0DzD3K0eUkIuQdscxLQ-QO1yi3b
 HeM/edit [3]
 https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1254120 [4]
 https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1160490 [5]
 http://pureperl.blogspot.com/2013/01/the-debian-ifupdown-package-and.html

Whatever the solution is for this, it's a problem that Ubuntu and Debian 
share.  Now that (eventually) we will single up on a common, modern init 
system, I think it's critical to work with the relevant Debian stakeholders on 
a common approach.

Debian also has a stack of bugs around cases that ifupdown doesn't support 
well and there have been discussions about the best way to move forward, but 
they have (so far) foundered of a lack of knowledgeable manpower to do the 
work.  Perhaps working together, Debian and Ubuntu can get it done.

I don't know what the right answer is myself, but based on some of these prior 
discussions and my own experience with NetworkManager on the desktop, I'm 
pretty sure that's not it.

Scott K 

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-06 Thread Dale Amon
The only feature I hold near and dear is that I be able
to ssh into a server in a rack 8000 miles away, fiddle
with /etc/network/interfaces if needed, and then reliably 
ifdown/ifup one of god knows how many connections (I often
work with machines that have 8 or even more hardware ethers,
not to mention ethn:m's.

Just a begging note to think of the systems guys who are
making bulk changes using scripts that execute scripts on
5, 10, a hundred or a thousand server (I know guys who do
that).

Lots of us only use a GUI as a place to let us keep 40
xterm's available...





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Our Networking Story

2014-03-06 Thread Dale Amon
On Thu, Mar 06, 2014 at 11:32:41PM +0100, Stanisław Hodur wrote:
 *Wifi + Ethernet on Desktop*

Which reminds me of another common use of machines that a typical
GUI user won't think of.

I often configure laptops that for security have wifi, bluetooth
etc all turned off at BIOS level, and the only ethernet connection
is not to the internet but to a disconnected network that attaches
to real, live and quite serious equipment (don't think computer 
equipment think *equipment*). I really appreciate it when network 
manager doesn't fight with me over the eth not having any external 
gateway. I get really annoyed if it does that, but with saucy
network-manager and I have at least a temporary truce. It lets
me do what I want with eth1 in interfaces and doesn't try to turn 
it off. And yes, in a previous version it did do that... I used
to have to shut it down or even de-install it.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss