OSIRIS JSON para Cisco

A Cisco nao e um unico alvo de producer. Ela e varias superficies de infraestrutura diferentes que precisam convergir em um unico modelo portavel.

E exatamente por isso que Cisco e uma direcao importante para OSIRIS JSON. Um producer para Cisco APIC, Cisco NX-OS e Cisco IOS nao deve achatar esses mundos na mesma exportacao bruta. Ele deve traduzir cada um deles para uma linguagem de topologia compartilhada, preservando ao mesmo tempo os detalhes especificos do vendor que ainda importam adiante.

Tres superficies Cisco, um objetivo de intercambio

O desafio do producer e diferente em cada caso.

Cisco APIC expoe uma visao de fabric orientada por controlador e politicas
Cisco NX-OS expoe inventario e relacionamentos de switching de datacenter centrados no dispositivo
Cisco IOS expoe o estado classico de routing, acesso e redes de campus

Esses nao sao modelos-fonte intercambiaveis, mas ainda assim podem alimentar a mesma estrutura de documento OSIRIS. Esse e o ponto do padrao: normalizar infraestrutura heterogenea sem fingir que as fontes eram identicas.

APIC nao deve ser forcado a uma exportacao generica de switch

Cisco APIC e o exemplo mais claro de por que OSIRIS precisa tanto de campos core quanto de namespaces de vendor.

Um producer apoiado por APIC nao esta apenas descobrindo dispositivos isolados. Ele esta lidando com construcoes no nivel de fabric, limites de politica e relacionamentos mediados por controlador. Em termos de OSIRIS, isso significa que um producer ainda pode emitir recursos, grupos e conexoes portaveis para o grafo de que consumers genericos precisam, preservando ao mesmo tempo a semantica especifica de ACI dentro do espaco de extensoes Cisco.

A especificacao ja deixa espaco para essa direcao por meio de extensoes Cisco com namespace e tipos especificos de vendor como osiris.cisco.aci.fabric. Esse e o lugar certo para o significado nativo de ACI que nao deve ser forcado para dentro do schema core.

NX-OS tem forte aderencia a topologia core

Cisco NX-OS e um alvo de producer muito natural para OSIRIS porque a infraestrutura subjacente ja se mapeia de forma limpa ao modelo padrao.

Fabrics Nexus normalmente giram em torno de recursos de switch, interfaces, uplinks, peerings, VLANs, contexto de routing e relacionamentos fisicos ou logicos explicitos. Esses sao exatamente os tipos de estrutura que OSIRIS foi criado para transportar. Um bom producer de NX-OS deve ser capaz de emitir:

recursos network.switch para dispositivos Nexus
IDs deterministicas e atribuicao estavel de provider usando cisco
conexoes explicitas para links, peerings e caminhos de attachment
grupos para limites de fabric, site, rack, pod ou ambiente
propriedades portaveis para modelo, IP de gerenciamento, versao e contexto em nivel de interface

Se um producer Cisco nao consegue expressar claramente um switch fabric em OSIRIS, o problema nao esta no dominio. Esta no producer.

IOS importa porque a borda de rede ainda importa

Cisco IOS pode parecer menos na moda do que fabrics orientados por controlador, mas ele continua essencial para a historia de producers do OSIRIS.

Roteadores, dispositivos de filial, equipamentos da camada de acesso e bordas de rede legadas, mas criticas, sao exatamente o tipo de sistema que tende a ficar fora de pipelines de topologia refinados. O OSIRIS tambem precisa lidar com esses ambientes.

O padrao ja tem mapeamentos diretos para infraestrutura comum no estilo IOS, como network.router, network.switch, network.vlan e os relacionamentos em torno deles. Isso faz do IOS um exemplo forte do principio de producer que mais importa na pratica: primeiro normalizar a forma portavel e, depois, preservar o contexto nativo do vendor quando necessario.

Detalhe especifico de Cisco sem perder interoperabilidade

Em APIC, NX-OS e IOS, a regra do producer permanece a mesma: manter a topologia core portavel e manter a semantica de Cisco em namespaces.

Isso significa:

usar tipos padrao de recurso e conexao do OSIRIS quando eles ja expressarem o conceito
manter estavel a atribuicao de provider com a nomenclatura canonica de Cisco
armazenar atributos intrinsecos e amplamente uteis em properties
armazenar estruturas nativas de Cisco em extensions, usando namespaces como osiris.cisco
preservar semantica mais profunda e especifica de ACI sob padroes dedicados de extensao Cisco ou de tipo vendor, em vez de deixa-la vazar para o modelo core

E aqui que OSIRIS e mais forte do que exportacoes ad hoc. Um consumer que nao saiba nada sobre Cisco ainda deve conseguir construir o grafo. Um consumer com conhecimento de Cisco pode entao aprofundar sem quebrar a portabilidade para todo o resto.

O contrato do producer continua valendo

Um producer Cisco continua sujeito as mesmas regras de producer do OSIRIS que qualquer outra fonte:

ele e somente leitura e nao deve modificar infraestrutura
ele nao deve adivinhar valores desconhecidos
ele deve produzir saida deterministica para a mesma entrada de origem
ele deve remover segredos e falhar de forma segura quando dados sensiveis forem detectados
ele deve validar pela CLI canonica do OSIRIS, em vez de distribuir seu proprio validador concorrente

Essa disciplina importa ainda mais para Cisco porque o panorama das fontes e amplo. Sem um contrato rigoroso de producer, exporters de APIC, NX-OS e IOS se desviariam para tres interpretacoes incompativeis do mesmo padrao.

Por que Cisco e uma familia de producers significativa para OSIRIS

Cisco cobre fabrics orientados por controlador, switching de datacenter, routing, campus e cenarios de borda industrial. Isso a torna um teste de estresse util para o modelo de producers do OSIRIS.

Se o padrao consegue representar abstracoes de APIC, fabrics NX-OS e bordas de rede IOS dentro de uma abordagem unica e coerente de intercambio, entao ele esta provando algo importante: OSIRIS nao serve apenas para um unico estilo de infraestrutura. Ele e realmente capaz de abranger os ambientes mistos que operadores precisam documentar e validar no mundo real.

Ler a documentacao relacionada

Todos os nomes de produtos e empresas sao marcas comerciais™ ou marcas registradas® de seus respectivos titulares. O uso deles nao implica qualquer afiliacao nem endosso por parte desses titulares.

OSIRIS JSON para Cisco APIC, NX-OS e IOS