propagate source routing rules to container machines (LXD, KVM) as of MAAS 2.6
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| juju |
High
|
Joseph Phillips |
Bug Description
As of MAAS 2.6 MAAS will provide source routing configuration to machines to make them send data out the same interface the traffic was received on.
Specifically, for responses it will work for TCP sockets bound to a specific address or 0.0.0.0 and for UDP sockets bound to specific addresses (not 0.0.0.0).
https:/
https:/
Example netplan (routing-policy is only added for interfaces that have an address with a subnet that has a default gateway defined in MAAS):
https:/
This information needs to be propagated to LXD containers and KVMs created by Juju machine agents if they are associated with relevant spaces.
Changed in juju: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → 2.7-beta1 |
Changed in juju: | |
milestone: | 2.7-beta1 → 2.7-rc1 |
Changed in juju: | |
milestone: | 2.7-rc1 → 2.7.1 |
Changed in juju: | |
milestone: | 2.7.1 → 2.7.2 |
tags: | added: sts |
José Pekkarinen (koalinux) wrote : | #1 |
Changed in juju: | |
assignee: | nobody → Joseph Phillips (manadart) |
John A Meinel (jameinel) wrote : | #2 |
This feels like a potentially dangerous feature request being hidden as a field-critical bugfix. I have some concern that rushing it into a 2.7.2 release is as likely to bite us because someone else didn't realize it would affect them and when they upgrade something will break.
There are things like tracking the "next table route id". And if a given deployment has been adding routes directly, then we will be interacting with their rules. (I guess hopefully they wouldn't add source routing in MAAS if they were setting source routing directly)
There are also questions of things like "what platforms support this". I'd be much more comfortable with "this is high priority, and needs to preempt some of our existing roadmap" than "push out a critical fix as fast as possible".
John A Meinel (jameinel) wrote : | #3 |
Also if we are dealing with Series support, what happens if the container we are deploying has a different series than the host machine. (bionic container on xenial machine, or xenial container on bionic machine.)
I think they are all answerable, but critical bugfix to get out before the weekend is going to have a hard time being aware of, much less answering them all.
Richard Harding (rharding) wrote : | #4 |
Just to clarify, in the side email around this the main question was "if this isn't going to work in Juju right now what would be a workaround?". So the goal is to investigate what the new feature in MAAS is, how it works, is it as trivial as adding to things we already proxy into containers on a MAAS environment, and if not, what would be a suitable workaround path until we can plot out a proper update.
If it is a small update to existing information set into containers let's see if we can get it into the upcoming 2.7.2, but if not, let's help with workaround steps until we can get it in.
Joseph Phillips (manadart) wrote : | #5 |
It looks like we are going to need to do the following.
- Expand the network.
- Update gomaasapi to get this data from MAAS.
- Store the data when we run the instance poller.
- Pass the device information to the container manager after bridge policy runs.
- Include the InterfaceInfo routing information when we render Netplan in the container.
Richard Harding (rharding) wrote : | #6 |
Given the updates required and the validation we'd need to do this isn't going to be able to be a quick fix for the 2.7.2 release that's upcoming. Our expectation is it'll take several PRs and QA of that to make sure we've got a solid fix.
In light of that, to help work around the issue I wanted to see if there's a way to leverage a cloud-init script that would run on containers (that are bionic+) to help seed the routing information. There was also talk of a possible charm solution as a subordinate or the like. I think we need to explore these while the work in Juju goes forward.
Changed in juju: | |
milestone: | 2.7.2 → 2.8-beta1 |
Felipe Reyes (freyes) wrote : Re: [Bug 1829150] Re: propagate source routing rules to container machines (LXD, KVM) as of MAAS 2.6 | #7 |
On Thu, 2020-01-30 at 16:11 +0000, Richard Harding wrote:
> Given the updates required and the validation we'd need to do this
> isn't
> going to be able to be a quick fix for the 2.7.2 release that's
> upcoming. Our expectation is it'll take several PRs and QA of that to
> make sure we've got a solid fix.
>
> In light of that, to help work around the issue I wanted to see if
> there's a way to leverage a cloud-init script that would run on
> containers (that are bionic+) to help seed the routing information.
> There was also talk of a possible charm solution as a subordinate or
> the
> like.
Some clouds use this charm as a workaround.
https:/
Changed in juju: | |
milestone: | 2.8-beta1 → 2.8.1 |
Tim Penhey (thumper) wrote : | #8 |
Taking field-critical off as this is a feature request.
Changed in juju: | |
milestone: | 2.8.1 → 2.8-next |
Subscribed field critical.