service networking provided more than once

  • Open
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Mathieu Othacehe
Severity
important

Debbugs page

M
M
Mathieu Othacehe wrote on 15 Dec 2021 05:04
(address . bug-guix@gnu.org)
87czlyj9y7.fsf@gnu.org
Hello,

When using this service:

Toggle snippet (22 lines)
(service static-networking-service-type
(list (static-networking
(addresses
(list
;; Connection to the DMZ for public access
;; This is a 10G port.
(network-address
(device "eno2")
(value "141.80.181.40/24"))))
(routes
(list (network-route
(destination "default")
(gateway "141.80.181.1")))))
(static-networking
(addresses
(list
;; Connection to build nodes
(network-address
(device "eno1")
(value "141.80.167.131/26")))))))

I have the following error message:

Toggle snippet (3 lines)
service networking provided more that once

I guess it boils down to tweak the "provision" field accordingly, but it
should be automated or documented properly.

Thanks,

Mathieu
L
L
Ludovic Courtès wrote on 15 Dec 2021 05:24
control message for bug #52511
(address . control@debbugs.gnu.org)
87ilvqvw4p.fsf@gnu.org
severity 52511 important
quit
L
L
Ludovic Courtès wrote on 15 Dec 2021 05:28
Re: bug#52511: service networking provided more than once
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 52511@debbugs.gnu.org)
87ee6evvy3.fsf@gnu.org
Hi!

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (31 lines)
> When using this service:
>
> (service static-networking-service-type
> (list (static-networking
> (addresses
> (list
> ;; Connection to the DMZ for public access
> ;; This is a 10G port.
> (network-address
> (device "eno2")
> (value "141.80.181.40/24"))))
> (routes
> (list (network-route
> (destination "default")
> (gateway "141.80.181.1")))))
> (static-networking
> (addresses
> (list
> ;; Connection to build nodes
> (network-address
> (device "eno1")
> (value "141.80.167.131/26")))))))
>
>
> I have the following error message:
>
> service networking provided more that once
>
> I guess it boils down to tweak the "provision" field accordingly, but it
> should be automated or documented properly.

In this particular case, you could/should have a single
‘static-networking’ with multiple addresses:

(static-networking
(addresses
(list (network-address …)
(network-address …)))
(routes …))

I’m not sure if there are other situations where this limitation is
problematic.

WDYT?

Thanks,
Ludo’.
M
M
Mathieu Othacehe wrote on 15 Dec 2021 05:50
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 52511@debbugs.gnu.org)
875yrqj7tg.fsf@gnu.org
Hey,

Toggle quote (9 lines)
> In this particular case, you could/should have a single
> ‘static-networking’ with multiple addresses:
>
> (static-networking
> (addresses
> (list (network-address …)
> (network-address …)))
> (routes …))

Oh, I see. There's still something problematic:

Toggle snippet (12 lines)
;; Connection to the DMZ for public access
;; This is a 10G port.
(static-networking-service "eno2"
"141.80.181.40"
#:netmask "255.255.255.0"
#:gateway "141.80.181.1")
;; Connection to build nodes
(static-networking-service "eno1"
"141.80.167.131"
#:netmask "255.255.255.192")

The above configuration used to create two distinct shepherd services:
networking-eno1 and networking-eno2.

We now have the aforementioned error because those two interfaces are
now provisioning 'networking, breaking compatibility.

Browsing the code, I also found:

Toggle snippet (10 lines)
(service static-networking-service-type
(list %loopback-static-networking

;; QEMU user-mode networking. To get "eth0", you need
;; QEMU to emulate a device for which Mach has an
;; in-kernel driver, for instance with:
;; --device rtl8139,netdev=net0 --netdev user,id=net0
%qemu-static-networking))

which made me think that creating a distinct static-networking record
per interface was the way to go.

Thanks,

Mathieu
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 52511@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 52511
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch