all:
  children:
    zuul_unreachable:
      hosts: {}
  hosts:
    debian-bookworm:
      ansible_connection: ssh
      ansible_host: 2a13:1a81:8000:3124:f816:3eff:feb5:edd4
      ansible_port: 22
      ansible_python_interpreter: auto
      ansible_user: zuul
      nodepool:
        az: nova
        cloud: regiocloud-a-ci
        external_id: 016612d6-1afb-42ac-add8-06e1adb8012d
        host_id: 4667d18e0398acd2fb730ad41ba32e35789c4ac8cd4c0875d25b316b
        interface_ip: 2a13:1a81:8000:3124:f816:3eff:feb5:edd4
        label: debian-bookworm
        node_properties: {}
        private_ipv4: 10.128.0.99
        private_ipv6: null
        provider: regiocloud-a
        public_ipv4: 81.163.192.59
        public_ipv6: 2a13:1a81:8000:3124:f816:3eff:feb5:edd4
        region: null
        slot: null
  vars:
    zuul:
      _inheritance_path:
      - '<Job base explicit: None implied: {MatchAny:{ImpliedBranchMatcher:main}}
        source: osism/zuul-config/zuul.d/jobs.yaml@main#2>'
      - '<Job mypy explicit: None implied: {MatchAny:{ImpliedBranchMatcher:main}}
        source: osism/zuul-jobs/.zuul.yaml@main#42>'
      - '<Job mypy explicit: None implied: None source: osism/python-osism/.zuul.yaml@main#138>'
      ansible_version: '9'
      attempts: 1
      branch: main
      build: a8dbd2816c114ccdb7ee41e6ec4926ce
      build_refs:
      - branch: main
        change: '2297'
        change_message: "sonic: document and test config generator ownership model\n\n##
          Motivation\n\nPRs #2279 and #2290 both ran into the same unresolved question:
          when `generate_sonic_config()` regenerates a SONiC config, which sections
          does it own outright, and which can an operator customize directly in `config_db.json`?\n\nIn
          #2279, a reviewer noted the assumption implied by unconditional assignment
          to `ROUTE_REDISTRIBUTE` but left the question open. In #2290, new tests
          used empty scaffolds, so they neither confirmed nor denied base-config preservation
          \u2014 and the same question arises on closer inspection of that PR. This
          PR tries to break the pattern.\n\n## What this PR does\n\n**Docstring**
          (`generate_sonic_config`): states the ownership model as the code largely
          implements it \u2014 generated sections (BGP_GLOBALS, VLAN, VLAN_INTERFACE,
          ROUTE_REDISTRIBUTE, VXLAN_TUNNEL, VXLAN_TUNNEL_MAP, etc.) are fully owned
          by the generator; entries in those sections are unconditionally overwritten
          on each regen, and pre-existing values from `config_db.json` are not preserved.\n\n**Illustrative
          tests** (`test_config_generator_ownership.py`): five passing tests showing
          what \"owned\" means in practice \u2014 pre-existing operator fields in
          `BGP_GLOBALS[vrf_name]`, `VLAN[Vlan{vni}]`, `ROUTE_REDISTRIBUTE[key]`, and
          `VLAN[VlanX]` are silently dropped on regen.\n\n**Violation test** (`test_config_generator_orchestrator.py`):
          one failing test that exposes an inconsistency in the current implementation
          \u2014 `BGP_GLOBALS[\"default\"]` is handled differently from the rest.
          The orchestrator updates it with key-level writes rather than replacing
          the entry, so pre-existing fields survive regen. The test is intentionally
          left failing to flag this for discussion.\n\n## What this PR is not\n\nThis
          is not a proposal to enforce a specific policy, and it does not fix the
          `BGP_GLOBALS[\"default\"]` inconsistency. The goal is to make the implicit
          rule visible and invite a decision:\n\n- Is the ownership model as stated
          correct? If not, what should it say?\n- For `BGP_GLOBALS[\"default\"]` specifically:
          should the orchestrator be fixed to replace the entry on regen (which would
          make the failing test pass), or should the rule be refined to treat the
          default VRF as a merge-only exception?\n\nSettling this once would avoid
          relitigating it in every PR that touches the config generator."
        change_url: https://github.com/osism/python-osism/pull/2297
        commit_id: f4c34e05dca2805d9338cc74d1dbbf4672a157ed
        patchset: f4c34e05dca2805d9338cc74d1dbbf4672a157ed
        project:
          canonical_hostname: github.com
          canonical_name: github.com/osism/python-osism
          name: osism/python-osism
          short_name: python-osism
        src_dir: src/github.com/osism/python-osism
        topic: null
      buildset: 0375027e9c69440e9c61db697655a636
      buildset_refs:
      - branch: main
        change: '2297'
        change_message: "sonic: document and test config generator ownership model\n\n##
          Motivation\n\nPRs #2279 and #2290 both ran into the same unresolved question:
          when `generate_sonic_config()` regenerates a SONiC config, which sections
          does it own outright, and which can an operator customize directly in `config_db.json`?\n\nIn
          #2279, a reviewer noted the assumption implied by unconditional assignment
          to `ROUTE_REDISTRIBUTE` but left the question open. In #2290, new tests
          used empty scaffolds, so they neither confirmed nor denied base-config preservation
          \u2014 and the same question arises on closer inspection of that PR. This
          PR tries to break the pattern.\n\n## What this PR does\n\n**Docstring**
          (`generate_sonic_config`): states the ownership model as the code largely
          implements it \u2014 generated sections (BGP_GLOBALS, VLAN, VLAN_INTERFACE,
          ROUTE_REDISTRIBUTE, VXLAN_TUNNEL, VXLAN_TUNNEL_MAP, etc.) are fully owned
          by the generator; entries in those sections are unconditionally overwritten
          on each regen, and pre-existing values from `config_db.json` are not preserved.\n\n**Illustrative
          tests** (`test_config_generator_ownership.py`): five passing tests showing
          what \"owned\" means in practice \u2014 pre-existing operator fields in
          `BGP_GLOBALS[vrf_name]`, `VLAN[Vlan{vni}]`, `ROUTE_REDISTRIBUTE[key]`, and
          `VLAN[VlanX]` are silently dropped on regen.\n\n**Violation test** (`test_config_generator_orchestrator.py`):
          one failing test that exposes an inconsistency in the current implementation
          \u2014 `BGP_GLOBALS[\"default\"]` is handled differently from the rest.
          The orchestrator updates it with key-level writes rather than replacing
          the entry, so pre-existing fields survive regen. The test is intentionally
          left failing to flag this for discussion.\n\n## What this PR is not\n\nThis
          is not a proposal to enforce a specific policy, and it does not fix the
          `BGP_GLOBALS[\"default\"]` inconsistency. The goal is to make the implicit
          rule visible and invite a decision:\n\n- Is the ownership model as stated
          correct? If not, what should it say?\n- For `BGP_GLOBALS[\"default\"]` specifically:
          should the orchestrator be fixed to replace the entry on regen (which would
          make the failing test pass), or should the rule be refined to treat the
          default VRF as a merge-only exception?\n\nSettling this once would avoid
          relitigating it in every PR that touches the config generator."
        change_url: https://github.com/osism/python-osism/pull/2297
        commit_id: f4c34e05dca2805d9338cc74d1dbbf4672a157ed
        patchset: f4c34e05dca2805d9338cc74d1dbbf4672a157ed
        project:
          canonical_hostname: github.com
          canonical_name: github.com/osism/python-osism
          name: osism/python-osism
          short_name: python-osism
        src_dir: src/github.com/osism/python-osism
        topic: null
      change: '2297'
      change_message: "sonic: document and test config generator ownership model\n\n##
        Motivation\n\nPRs #2279 and #2290 both ran into the same unresolved question:
        when `generate_sonic_config()` regenerates a SONiC config, which sections
        does it own outright, and which can an operator customize directly in `config_db.json`?\n\nIn
        #2279, a reviewer noted the assumption implied by unconditional assignment
        to `ROUTE_REDISTRIBUTE` but left the question open. In #2290, new tests used
        empty scaffolds, so they neither confirmed nor denied base-config preservation
        \u2014 and the same question arises on closer inspection of that PR. This
        PR tries to break the pattern.\n\n## What this PR does\n\n**Docstring** (`generate_sonic_config`):
        states the ownership model as the code largely implements it \u2014 generated
        sections (BGP_GLOBALS, VLAN, VLAN_INTERFACE, ROUTE_REDISTRIBUTE, VXLAN_TUNNEL,
        VXLAN_TUNNEL_MAP, etc.) are fully owned by the generator; entries in those
        sections are unconditionally overwritten on each regen, and pre-existing values
        from `config_db.json` are not preserved.\n\n**Illustrative tests** (`test_config_generator_ownership.py`):
        five passing tests showing what \"owned\" means in practice \u2014 pre-existing
        operator fields in `BGP_GLOBALS[vrf_name]`, `VLAN[Vlan{vni}]`, `ROUTE_REDISTRIBUTE[key]`,
        and `VLAN[VlanX]` are silently dropped on regen.\n\n**Violation test** (`test_config_generator_orchestrator.py`):
        one failing test that exposes an inconsistency in the current implementation
        \u2014 `BGP_GLOBALS[\"default\"]` is handled differently from the rest. The
        orchestrator updates it with key-level writes rather than replacing the entry,
        so pre-existing fields survive regen. The test is intentionally left failing
        to flag this for discussion.\n\n## What this PR is not\n\nThis is not a proposal
        to enforce a specific policy, and it does not fix the `BGP_GLOBALS[\"default\"]`
        inconsistency. The goal is to make the implicit rule visible and invite a
        decision:\n\n- Is the ownership model as stated correct? If not, what should
        it say?\n- For `BGP_GLOBALS[\"default\"]` specifically: should the orchestrator
        be fixed to replace the entry on regen (which would make the failing test
        pass), or should the rule be refined to treat the default VRF as a merge-only
        exception?\n\nSettling this once would avoid relitigating it in every PR that
        touches the config generator."
      change_url: https://github.com/osism/python-osism/pull/2297
      child_jobs: []
      commit_id: f4c34e05dca2805d9338cc74d1dbbf4672a157ed
      event_id: d8fa49e0-5a6e-11f1-9d39-dd3019c59e41
      executor:
        hostname: 521e9411259a
        inventory_file: /var/lib/zuul/builds/a8dbd2816c114ccdb7ee41e6ec4926ce/ansible/inventory.yaml
        log_root: /var/lib/zuul/builds/a8dbd2816c114ccdb7ee41e6ec4926ce/work/logs
        result_data_file: /var/lib/zuul/builds/a8dbd2816c114ccdb7ee41e6ec4926ce/work/results.json
        src_root: /var/lib/zuul/builds/a8dbd2816c114ccdb7ee41e6ec4926ce/work/src
        work_root: /var/lib/zuul/builds/a8dbd2816c114ccdb7ee41e6ec4926ce/work
      include_vars: []
      items:
      - branch: main
        change: '2297'
        change_message: "sonic: document and test config generator ownership model\n\n##
          Motivation\n\nPRs #2279 and #2290 both ran into the same unresolved question:
          when `generate_sonic_config()` regenerates a SONiC config, which sections
          does it own outright, and which can an operator customize directly in `config_db.json`?\n\nIn
          #2279, a reviewer noted the assumption implied by unconditional assignment
          to `ROUTE_REDISTRIBUTE` but left the question open. In #2290, new tests
          used empty scaffolds, so they neither confirmed nor denied base-config preservation
          \u2014 and the same question arises on closer inspection of that PR. This
          PR tries to break the pattern.\n\n## What this PR does\n\n**Docstring**
          (`generate_sonic_config`): states the ownership model as the code largely
          implements it \u2014 generated sections (BGP_GLOBALS, VLAN, VLAN_INTERFACE,
          ROUTE_REDISTRIBUTE, VXLAN_TUNNEL, VXLAN_TUNNEL_MAP, etc.) are fully owned
          by the generator; entries in those sections are unconditionally overwritten
          on each regen, and pre-existing values from `config_db.json` are not preserved.\n\n**Illustrative
          tests** (`test_config_generator_ownership.py`): five passing tests showing
          what \"owned\" means in practice \u2014 pre-existing operator fields in
          `BGP_GLOBALS[vrf_name]`, `VLAN[Vlan{vni}]`, `ROUTE_REDISTRIBUTE[key]`, and
          `VLAN[VlanX]` are silently dropped on regen.\n\n**Violation test** (`test_config_generator_orchestrator.py`):
          one failing test that exposes an inconsistency in the current implementation
          \u2014 `BGP_GLOBALS[\"default\"]` is handled differently from the rest.
          The orchestrator updates it with key-level writes rather than replacing
          the entry, so pre-existing fields survive regen. The test is intentionally
          left failing to flag this for discussion.\n\n## What this PR is not\n\nThis
          is not a proposal to enforce a specific policy, and it does not fix the
          `BGP_GLOBALS[\"default\"]` inconsistency. The goal is to make the implicit
          rule visible and invite a decision:\n\n- Is the ownership model as stated
          correct? If not, what should it say?\n- For `BGP_GLOBALS[\"default\"]` specifically:
          should the orchestrator be fixed to replace the entry on regen (which would
          make the failing test pass), or should the rule be refined to treat the
          default VRF as a merge-only exception?\n\nSettling this once would avoid
          relitigating it in every PR that touches the config generator."
        change_url: https://github.com/osism/python-osism/pull/2297
        commit_id: f4c34e05dca2805d9338cc74d1dbbf4672a157ed
        patchset: f4c34e05dca2805d9338cc74d1dbbf4672a157ed
        project:
          canonical_hostname: github.com
          canonical_name: github.com/osism/python-osism
          name: osism/python-osism
          short_name: python-osism
          src_dir: src/github.com/osism/python-osism
        topic: null
      job: mypy
      jobtags: []
      max_attempts: 3
      message: c29uaWM6IGRvY3VtZW50IGFuZCB0ZXN0IGNvbmZpZyBnZW5lcmF0b3Igb3duZXJzaGlwIG1vZGVsCgojIyBNb3RpdmF0aW9uCgpQUnMgIzIyNzkgYW5kICMyMjkwIGJvdGggcmFuIGludG8gdGhlIHNhbWUgdW5yZXNvbHZlZCBxdWVzdGlvbjogd2hlbiBgZ2VuZXJhdGVfc29uaWNfY29uZmlnKClgIHJlZ2VuZXJhdGVzIGEgU09OaUMgY29uZmlnLCB3aGljaCBzZWN0aW9ucyBkb2VzIGl0IG93biBvdXRyaWdodCwgYW5kIHdoaWNoIGNhbiBhbiBvcGVyYXRvciBjdXN0b21pemUgZGlyZWN0bHkgaW4gYGNvbmZpZ19kYi5qc29uYD8KCkluICMyMjc5LCBhIHJldmlld2VyIG5vdGVkIHRoZSBhc3N1bXB0aW9uIGltcGxpZWQgYnkgdW5jb25kaXRpb25hbCBhc3NpZ25tZW50IHRvIGBST1VURV9SRURJU1RSSUJVVEVgIGJ1dCBsZWZ0IHRoZSBxdWVzdGlvbiBvcGVuLiBJbiAjMjI5MCwgbmV3IHRlc3RzIHVzZWQgZW1wdHkgc2NhZmZvbGRzLCBzbyB0aGV5IG5laXRoZXIgY29uZmlybWVkIG5vciBkZW5pZWQgYmFzZS1jb25maWcgcHJlc2VydmF0aW9uIOKAlCBhbmQgdGhlIHNhbWUgcXVlc3Rpb24gYXJpc2VzIG9uIGNsb3NlciBpbnNwZWN0aW9uIG9mIHRoYXQgUFIuIFRoaXMgUFIgdHJpZXMgdG8gYnJlYWsgdGhlIHBhdHRlcm4uCgojIyBXaGF0IHRoaXMgUFIgZG9lcwoKKipEb2NzdHJpbmcqKiAoYGdlbmVyYXRlX3NvbmljX2NvbmZpZ2ApOiBzdGF0ZXMgdGhlIG93bmVyc2hpcCBtb2RlbCBhcyB0aGUgY29kZSBsYXJnZWx5IGltcGxlbWVudHMgaXQg4oCUIGdlbmVyYXRlZCBzZWN0aW9ucyAoQkdQX0dMT0JBTFMsIFZMQU4sIFZMQU5fSU5URVJGQUNFLCBST1VURV9SRURJU1RSSUJVVEUsIFZYTEFOX1RVTk5FTCwgVlhMQU5fVFVOTkVMX01BUCwgZXRjLikgYXJlIGZ1bGx5IG93bmVkIGJ5IHRoZSBnZW5lcmF0b3I7IGVudHJpZXMgaW4gdGhvc2Ugc2VjdGlvbnMgYXJlIHVuY29uZGl0aW9uYWxseSBvdmVyd3JpdHRlbiBvbiBlYWNoIHJlZ2VuLCBhbmQgcHJlLWV4aXN0aW5nIHZhbHVlcyBmcm9tIGBjb25maWdfZGIuanNvbmAgYXJlIG5vdCBwcmVzZXJ2ZWQuCgoqKklsbHVzdHJhdGl2ZSB0ZXN0cyoqIChgdGVzdF9jb25maWdfZ2VuZXJhdG9yX293bmVyc2hpcC5weWApOiBmaXZlIHBhc3NpbmcgdGVzdHMgc2hvd2luZyB3aGF0ICJvd25lZCIgbWVhbnMgaW4gcHJhY3RpY2Ug4oCUIHByZS1leGlzdGluZyBvcGVyYXRvciBmaWVsZHMgaW4gYEJHUF9HTE9CQUxTW3ZyZl9uYW1lXWAsIGBWTEFOW1ZsYW57dm5pfV1gLCBgUk9VVEVfUkVESVNUUklCVVRFW2tleV1gLCBhbmQgYFZMQU5bVmxhblhdYCBhcmUgc2lsZW50bHkgZHJvcHBlZCBvbiByZWdlbi4KCioqVmlvbGF0aW9uIHRlc3QqKiAoYHRlc3RfY29uZmlnX2dlbmVyYXRvcl9vcmNoZXN0cmF0b3IucHlgKTogb25lIGZhaWxpbmcgdGVzdCB0aGF0IGV4cG9zZXMgYW4gaW5jb25zaXN0ZW5jeSBpbiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiDigJQgYEJHUF9HTE9CQUxTWyJkZWZhdWx0Il1gIGlzIGhhbmRsZWQgZGlmZmVyZW50bHkgZnJvbSB0aGUgcmVzdC4gVGhlIG9yY2hlc3RyYXRvciB1cGRhdGVzIGl0IHdpdGgga2V5LWxldmVsIHdyaXRlcyByYXRoZXIgdGhhbiByZXBsYWNpbmcgdGhlIGVudHJ5LCBzbyBwcmUtZXhpc3RpbmcgZmllbGRzIHN1cnZpdmUgcmVnZW4uIFRoZSB0ZXN0IGlzIGludGVudGlvbmFsbHkgbGVmdCBmYWlsaW5nIHRvIGZsYWcgdGhpcyBmb3IgZGlzY3Vzc2lvbi4KCiMjIFdoYXQgdGhpcyBQUiBpcyBub3QKClRoaXMgaXMgbm90IGEgcHJvcG9zYWwgdG8gZW5mb3JjZSBhIHNwZWNpZmljIHBvbGljeSwgYW5kIGl0IGRvZXMgbm90IGZpeCB0aGUgYEJHUF9HTE9CQUxTWyJkZWZhdWx0Il1gIGluY29uc2lzdGVuY3kuIFRoZSBnb2FsIGlzIHRvIG1ha2UgdGhlIGltcGxpY2l0IHJ1bGUgdmlzaWJsZSBhbmQgaW52aXRlIGEgZGVjaXNpb246CgotIElzIHRoZSBvd25lcnNoaXAgbW9kZWwgYXMgc3RhdGVkIGNvcnJlY3Q/IElmIG5vdCwgd2hhdCBzaG91bGQgaXQgc2F5PwotIEZvciBgQkdQX0dMT0JBTFNbImRlZmF1bHQiXWAgc3BlY2lmaWNhbGx5OiBzaG91bGQgdGhlIG9yY2hlc3RyYXRvciBiZSBmaXhlZCB0byByZXBsYWNlIHRoZSBlbnRyeSBvbiByZWdlbiAod2hpY2ggd291bGQgbWFrZSB0aGUgZmFpbGluZyB0ZXN0IHBhc3MpLCBvciBzaG91bGQgdGhlIHJ1bGUgYmUgcmVmaW5lZCB0byB0cmVhdCB0aGUgZGVmYXVsdCBWUkYgYXMgYSBtZXJnZS1vbmx5IGV4Y2VwdGlvbj8KClNldHRsaW5nIHRoaXMgb25jZSB3b3VsZCBhdm9pZCByZWxpdGlnYXRpbmcgaXQgaW4gZXZlcnkgUFIgdGhhdCB0b3VjaGVzIHRoZSBjb25maWcgZ2VuZXJhdG9yLg==
      patchset: f4c34e05dca2805d9338cc74d1dbbf4672a157ed
      pipeline: check
      playbook_context:
        playbook_projects:
          trusted/project_0/github.com/osism/zuul-config:
            canonical_name: github.com/osism/zuul-config
            checkout: main
            commit: 019f0261a526db7d8989ff1abefc2299a8c0ffbc
          trusted/project_1/github.com/osism/openinfra-zuul-jobs:
            canonical_name: github.com/osism/openinfra-zuul-jobs
            checkout: master
            commit: 038dd8b856c62af4433c8477c5cb3d0480847059
          trusted/project_2/github.com/osism/zuul-jobs:
            canonical_name: github.com/osism/zuul-jobs
            checkout: main
            commit: 0c74c57cedff2b36bb37ca68a5338d1c49991496
          untrusted/project_0/github.com/osism/zuul-jobs:
            canonical_name: github.com/osism/zuul-jobs
            checkout: main
            commit: 0c74c57cedff2b36bb37ca68a5338d1c49991496
          untrusted/project_1/github.com/osism/zuul-config:
            canonical_name: github.com/osism/zuul-config
            checkout: main
            commit: 019f0261a526db7d8989ff1abefc2299a8c0ffbc
          untrusted/project_2/github.com/osism/openinfra-zuul-jobs:
            canonical_name: github.com/osism/openinfra-zuul-jobs
            checkout: master
            commit: 038dd8b856c62af4433c8477c5cb3d0480847059
        playbooks:
        - path: untrusted/project_0/github.com/osism/zuul-jobs/playbooks/mypy/run.yaml
          roles:
          - checkout: main
            checkout_description: zuul branch
            link_name: ansible/playbook_0/role_0/zuul-config
            link_target: untrusted/project_1/github.com/osism/zuul-config
            role_path: ansible/playbook_0/role_0/zuul-config/roles
          - checkout: master
            checkout_description: project default branch
            link_name: ansible/playbook_0/role_1/openinfra-zuul-jobs
            link_target: untrusted/project_2/github.com/osism/openinfra-zuul-jobs
            role_path: ansible/playbook_0/role_1/openinfra-zuul-jobs/roles
          - checkout: main
            checkout_description: playbook branch
            link_name: ansible/playbook_0/role_2/zuul-jobs
            link_target: untrusted/project_0/github.com/osism/zuul-jobs
            role_path: ansible/playbook_0/role_2/zuul-jobs/roles
      post_review: false
      post_timeout: null
      pre_timeout: null
      project:
        canonical_hostname: github.com
        canonical_name: github.com/osism/python-osism
        name: osism/python-osism
        short_name: python-osism
        src_dir: src/github.com/osism/python-osism
      projects:
        github.com/osism/python-osism:
          canonical_hostname: github.com
          canonical_name: github.com/osism/python-osism
          checkout: main
          checkout_description: zuul branch
          commit: 0def76945f422c2b6216ca06cba72b1d2a85740b
          name: osism/python-osism
          required: false
          short_name: python-osism
          src_dir: src/github.com/osism/python-osism
      ref: refs/pull/2297/head
      resources: {}
      tenant: osism
      timeout: 1800
      topic: null
      voting: true
