Skip to main content
Moderne OnlyThis recipe is proprietary to Moderne and runs on the Moderne platform or CLI — it isn’t part of the open-source catalog. Available with a Moderne subscription.Contact Sales

Find Das Schiff resources that have to move to Sylva

Recipe IDio.moderne.kubernetes.sylva.migrate.dasschiff.FindDasSchiffMigrationWork
Artifactorg.openrewrite.recipe:rewrite-kubernetes

Inventory every Das Schiff resource the Sylva intent group replaces and report, per kind, whether it moves automatically or what has to be decided first. All eight legacy kinds are marked, the three the operator generates included, so a kind that goes unmentioned is one this catalogue does not know about. A repository partway through the move also reports where the intent resources it already holds no longer say what the legacy ones do. Reports only; nothing is rewritten.

Composite recipeOpenRewritekubernetestelekomModerne Proprietary License
Try in PlatformTry this recipe in the Moderne platform. Not a user yet? You’ll get a no-setup demo environment, with nothing to install or configure.

Definition​

Recipes7

Examples​

yaml
Before
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: VRFRouteConfiguration
metadata:
  name: mirror-test-vrf
spec:
  vrf: mirror
  vni: 2002099
  routeTarget: "65188:2099"
  seq: 20
  import: []
  export: []
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: Layer2NetworkConfiguration
metadata:
  name: vlan590
spec:
  id: 590
  mtu: 1500
  vni: 4000090
  vrf: mirror
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: MirrorTarget
metadata:
  name: collector-prod
spec:
  type: l3gre
  destinationIP: 10.250.90.100
  destinationVrf: mirror
  sourceLoopback: lo.mir
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: MirrorSelector
metadata:
  name: example-mirror
spec:
  direction: ingress
  mirrorTarget:
    kind: MirrorTarget
    name: collector-prod
  mirrorSource:
    kind: Layer2NetworkConfiguration
    name: vlan590
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: BGPPeering
metadata:
  name: peering
spec:
  peeringVlan:
    name: vlan590
  remoteASN: 65100
  import: []
  export:
    - action: permit
      cidr: 10.102.0.0/24
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: NodeNetworkConfig
metadata:
  name: worker-1
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: NodeNetplanConfig
metadata:
  name: worker-1
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: NetworkConfigRevision
metadata:
  name: 4f2a1c9de0
After
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by VRF, Destination, Inbound and Outbound)~~>~~(becomes `VRF` and `Destination`)~~>kind: VRFRouteConfiguration
metadata:
  name: mirror-test-vrf
spec:
  vrf: mirror
  vni: 2002099
  routeTarget: "65188:2099"
  seq: 20
  import: []
  export: []
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by Network and Layer2Attachment)~~>~~(becomes `Network` and `Layer2Attachment`)~~>kind: Layer2NetworkConfiguration
metadata:
  name: vlan590
spec:
  id: 590
  mtu: 1500
  vni: 4000090
  vrf: mirror
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by Collector)~~>~~(sources the tunnel from loopback `lo.mir`, which `VRFRouteConfiguration` `mirror-test-vrf` declares no `spec.loopbacks` entry for, and `spec.mirrorVRF.loopback.subnet` has nowhere else to come from)~~>kind: MirrorTarget
metadata:
  name: collector-prod
spec:
  type: l3gre
  destinationIP: 10.250.90.100
  destinationVrf: mirror
  sourceLoopback: lo.mir
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by TrafficMirror)~~>~~(sends to `MirrorTarget` collector-prod, which stays on the legacy group, so the `Collector` this would name does not exist)~~>kind: MirrorSelector
metadata:
  name: example-mirror
spec:
  direction: ingress
  mirrorTarget:
    kind: MirrorTarget
    name: collector-prod
  mirrorSource:
    kind: Layer2NetworkConfiguration
    name: vlan590
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by BGPPeering in the Sylva group, which shares the name and four fields; the rest of the spec is references the legacy one does not carry, and no export filter survives, so this one moves by hand)~~>~~(peers on `vlan590`, and this manifest holds no intent `Layer2Attachment` of that name for `spec.ref.attachmentRef` to point at. `MigrateLowLevelNetworkConfigToIntent` names the attachment it generates after the `Layer2NetworkConfiguration` it replaces, so run it first)~~>kind: BGPPeering
metadata:
  name: peering
spec:
  peeringVlan:
    name: vlan590
  remoteASN: 65100
  import: []
  export:
    - action: permit
      cidr: 10.102.0.0/24
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(generated by the operator, not authored)~~>kind: NodeNetworkConfig
metadata:
  name: worker-1
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(generated by the operator, not authored)~~>kind: NodeNetplanConfig
metadata:
  name: worker-1
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(generated by the operator, not authored)~~>kind: NetworkConfigRevision
metadata:
  name: 4f2a1c9de0
yaml
Before
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: VRFRouteConfiguration
metadata:
  name: mirror-test-vrf
spec:
  vrf: mirror
  vni: 2002099
  routeTarget: "65188:2099"
  seq: 20
  import: []
  export: []
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: Layer2NetworkConfiguration
metadata:
  name: vlan590
spec:
  id: 590
  mtu: 1500
  vni: 4000090
  vrf: mirror
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: MirrorTarget
metadata:
  name: collector-prod
spec:
  type: l3gre
  destinationIP: 10.250.90.100
  destinationVrf: mirror
  sourceLoopback: lo.mir
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: MirrorSelector
metadata:
  name: example-mirror
spec:
  direction: ingress
  mirrorTarget:
    kind: MirrorTarget
    name: collector-prod
  mirrorSource:
    kind: Layer2NetworkConfiguration
    name: vlan590
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: BGPPeering
metadata:
  name: peering
spec:
  peeringVlan:
    name: vlan590
  remoteASN: 65100
  import: []
  export:
    - action: permit
      cidr: 10.102.0.0/24
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: NodeNetworkConfig
metadata:
  name: worker-1
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: NodeNetplanConfig
metadata:
  name: worker-1
---
apiVersion: network.t-caas.telekom.com/v1alpha1
kind: NetworkConfigRevision
metadata:
  name: 4f2a1c9de0
After
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by VRF, Destination, Inbound and Outbound)~~>~~(becomes `VRF` and `Destination`)~~>kind: VRFRouteConfiguration
metadata:
  name: mirror-test-vrf
spec:
  vrf: mirror
  vni: 2002099
  routeTarget: "65188:2099"
  seq: 20
  import: []
  export: []
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by Network and Layer2Attachment)~~>~~(becomes `Network` and `Layer2Attachment`)~~>kind: Layer2NetworkConfiguration
metadata:
  name: vlan590
spec:
  id: 590
  mtu: 1500
  vni: 4000090
  vrf: mirror
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by Collector)~~>~~(sources the tunnel from loopback `lo.mir`, which `VRFRouteConfiguration` `mirror-test-vrf` declares no `spec.loopbacks` entry for, and `spec.mirrorVRF.loopback.subnet` has nowhere else to come from)~~>kind: MirrorTarget
metadata:
  name: collector-prod
spec:
  type: l3gre
  destinationIP: 10.250.90.100
  destinationVrf: mirror
  sourceLoopback: lo.mir
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by TrafficMirror)~~>~~(sends to `MirrorTarget` collector-prod, which stays on the legacy group, so the `Collector` this would name does not exist)~~>kind: MirrorSelector
metadata:
  name: example-mirror
spec:
  direction: ingress
  mirrorTarget:
    kind: MirrorTarget
    name: collector-prod
  mirrorSource:
    kind: Layer2NetworkConfiguration
    name: vlan590
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(replaced by BGPPeering in the Sylva group, which shares the name and four fields; the rest of the spec is references the legacy one does not carry, and no export filter survives, so this one moves by hand)~~>~~(peers on `vlan590`, and this manifest holds no intent `Layer2Attachment` of that name for `spec.ref.attachmentRef` to point at. `MigrateLowLevelNetworkConfigToIntent` names the attachment it generates after the `Layer2NetworkConfiguration` it replaces, so run it first)~~>kind: BGPPeering
metadata:
  name: peering
spec:
  peeringVlan:
    name: vlan590
  remoteASN: 65100
  import: []
  export:
    - action: permit
      cidr: 10.102.0.0/24
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(generated by the operator, not authored)~~>kind: NodeNetworkConfig
metadata:
  name: worker-1
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(generated by the operator, not authored)~~>kind: NodeNetplanConfig
metadata:
  name: worker-1
---
apiVersion: network.t-caas.telekom.com/v1alpha1
~~(generated by the operator, not authored)~~>kind: NetworkConfigRevision
metadata:
  name: 4f2a1c9de0

Usage​

Run this recipe

This recipe has no required configuration options. Users of Moderne can run it via the Moderne CLI.

You will need to have configured the Moderne CLI on your machine before you can run the following command.

shell
mod run . --recipe FindDasSchiffMigrationWork

If the recipe is not available locally, then you can install it using:

RELEASE resolves to the newest release and LATEST to the newest build of any kind, including snapshots. Either one lets mod config recipes upgrade pull in later versions without editing this command; a pinned version stays where you put it.

mod config recipes jar install org.openrewrite.recipe:rewrite-kubernetes:RELEASE

Data tables​

Low level network configurations
io.moderne.kubernetes.sylva.migrate.dasschiff.table.LowLevelNetworkConfigs

Deutsche Telekom network.t-caas.telekom.com resources that the network-connector.sylvaproject.org intent group replaces, and whether each one can be moved mechanically.

ColumnDescription
Source pathThe path to the manifest.
KindThe legacy kind.
NameThe metadata.name of the legacy resource.
VRFThe VRF the resource declares or attaches to, empty when it names none.
Migrationautomatic when io.moderne.kubernetes.sylva.MigrateLowLevelNetworkConfigToIntent rewrites this resource, manual otherwise.
Intent kindsThe intent resources it becomes, empty when it has to be moved by hand.
DetailWhy the resource cannot be moved mechanically, empty when it can.
Manual follow-upLegacy fields with no intent field to hold them, which the operator derives or assigns instead. Empty when the move loses nothing.
Traffic mirror configurations
io.moderne.kubernetes.sylva.migrate.dasschiff.table.MirrorConfigs

Deutsche Telekom MirrorTarget and MirrorSelector resources that the network-connector.sylvaproject.org Collector and TrafficMirror replace, and whether each one can be moved mechanically.

ColumnDescription
Source pathThe path to the manifest.
KindThe legacy kind.
NameThe metadata.name of the legacy resource.
ReferenceThe VRF a MirrorTarget tunnels through, or the MirrorTarget a MirrorSelector sends to. Empty when it names none.
Migrationautomatic when io.moderne.kubernetes.sylva.migrate.dasschiff.MigrateMirrorConfigToIntent rewrites this resource, manual otherwise.
Intent kindsThe intent resource it becomes, empty when it has to be moved by hand.
DetailWhy the resource cannot be moved mechanically, empty when it can.
Manual follow-upWhat still has to be done by hand once the resource has moved, which is mostly the resources it names that the intent group has not generated yet. Empty when the move leaves nothing behind.
BGP peerings
io.moderne.kubernetes.sylva.migrate.dasschiff.table.BgpPeerings

Deutsche Telekom network.t-caas.telekom.com BGPPeering resources, and what each one needs decided before it can be written against the network-connector.sylvaproject.org BGPPeering that shares its name.

ColumnDescription
Source pathThe path to the manifest.
NameThe metadata.name of the legacy resource.
ModeThe intent spec.mode this peering maps onto: listenRange when it sets spec.peeringVlan, loopbackPeer when it sets spec.loopbackPeer, empty when neither is readable.
BlockerWhat has to be decided before this peering can be written against the intent group. Checks run narrowest first, so a peering reported against spec.export is one whose every other field and reference already resolves.
Intent drift
io.moderne.kubernetes.sylva.migrate.dasschiff.table.IntentDrift

Where the network-connector.sylvaproject.org resources in a repository do not say what the network.t-caas.telekom.com resources beside them said.

ColumnDescription
Source pathThe path to the manifest holding the legacy resource.
KindThe legacy kind the comparison is anchored on.
NameThe metadata.name of the legacy resource.
Intent resourceThe intent resource compared against, as kind name. Empty when none was found.
FieldThe legacy field compared, empty when the finding is about the resource as a whole.
Legacy valueWhat the legacy resource says. Empty when only the intent side says anything.
Intent valueWhat the intent resources say. Empty when they say nothing.
Verdictdiffers when both groups express the field and disagree, dropped when the intent group has nowhere to put the legacy value, unverifiable when the intent group leaves it to the operator, unpaired when no counterpart was found, and ambiguous when more than one counterpart was.
DetailWhat the difference does to the network.
Exported ranges
io.moderne.kubernetes.sylva.migrate.dasschiff.table.ExportRanges

Every spec.export range of a Deutsche Telekom VRFRouteConfiguration, and whether it is classified as the load balancer pool or the egress NAT pool the network-connector.sylvaproject.org intent group needs it to be.

ColumnDescription
Source pathThe path to the manifest.
NameThe metadata.name of the VRFRouteConfiguration exporting the range.
VRFThe VRF the range is exported into.
CIDRThe exported range.
Classification keyThe key that classifies this range, to be supplied as <key>=<role>:<networkRef>. Empty when no classification would help.
Statusgenerated when an Inbound or Outbound was produced, unclassified when the range needs a role, not expressible when no intent resource can hold it, and templated when the resource renders through a Helm expression.
RoleThe supplied role: inbound-bgp, inbound-l2 or outbound. Empty when unclassified.
NetworkThe Network the supplied classification allocates from. Empty when unclassified.
GeneratedThe intent resource this range landed in, empty when none was generated.
DetailWhat has to be decided, why the range cannot move, or what generating it adds beyond the export the legacy resource performed.
Das Schiff network operator ConfigMaps
io.moderne.kubernetes.sylva.migrate.dasschiff.table.NetworkOperatorConfigMaps

One row per data key of every ConfigMap that configures Deutsche Telekom's das-schiff-network-operator, describing where it lives and what shape it is in. A ConfigMap that declares no keys still gets a row, so that the inventory is of ConfigMaps and not only of keys.

ColumnDescription
Source pathThe path to the manifest.
NamespaceThe metadata.namespace, empty when the manifest leaves it to the applying context, as a Kustomize overlay or a Helm release does.
NameThe metadata.name of the ConfigMap. A Kustomize namePrefix is not applied here, so the name in the cluster may carry a prefix this one does not.
KeyOne key of data, or of binaryData. Empty when the ConfigMap declares neither.
StyleHow the value is written: block for a literal block scalar (|), folded (>), plain, single quoted, double quoted, or binary for a binaryData key. A mapping or sequence is malformed, because every ConfigMap value is a string.
SizeCharacters in the value, block scalars dedented, so that the number is the size of the embedded document rather than of its indentation. For binaryData, the length of the base64 text.
Matched byWhich signals identified this as a network operator ConfigMap: name, label for app.kubernetes.io/name: network-operator, data key for a base-config.yaml key. Listed so that a row can be judged rather than trusted.
Templatedyes when the document contains a Helm expression, in which case the keys and sizes here are those of the template and not of what the cluster receives.
Source files that had results
org.openrewrite.table.SourcesFileResults

Source files that were modified by the recipe run.

ColumnDescription
Source path before the runThe source path of the file before the run. null when a source file was created during the run.
Source path after the runA recipe may modify the source path. This is the path after the run. null when a source file was deleted during the run.
Parent of the recipe that made changesIn a hierarchical recipe, the parent of the recipe that made a change. Empty if this is the root of a hierarchy or if the recipe is not hierarchical at all.
Recipe that made changesThe specific recipe that made a change.
Estimated time savingAn estimated effort that a developer to fix manually instead of using this recipe, in unit of seconds.
CycleThe recipe cycle in which the change was made.
Source files that had search results
org.openrewrite.table.SearchResults

Search results that were found during the recipe run.

ColumnDescription
Source path of search result before the runThe source path of the file with the search result markers present.
Source path of search result after run the runA recipe may modify the source path. This is the path after the run. null when a source file was deleted during the run.
ResultThe trimmed printed tree of the LST element that the marker is attached to.
DescriptionThe content of the description of the marker.
Recipe that added the search markerThe specific recipe that added the Search marker.
Source files that errored on a recipe
org.openrewrite.table.SourcesFileErrors

The details of all errors produced by a recipe run.

ColumnDescription
Source pathThe file that failed to parse.
Recipe that made changesThe specific recipe that made a change.
Stack traceThe stack trace of the failure.
Recipe performance
org.openrewrite.table.RecipeRunStats

Statistics used in analyzing the performance of recipes.

ColumnDescription
The recipeThe recipe whose stats are being measured both individually and cumulatively.
Source file countThe number of source files the recipe ran over.
Source file changed countThe number of source files which were changed in the recipe run. Includes files created, deleted, and edited.
Cumulative scanning time (ns)The total time spent across the scanning phase of this recipe.
Max scanning time (ns)The max time scanning any one source file.
Cumulative edit time (ns)The total time spent across the editing phase of this recipe.
Max edit time (ns)The max time editing any one source file.