Quando o NetBox é a fonte da verdade

Um cliente com um NetBox a funcionar não quer um segundo inventário. Quer que os seus bastidores e as suas máquinas apareçam na plataforma a partir da qual opera, e quer continuar a editá-los no sítio que a sua equipa já conhece.

A palavra que costuma vir agarrada a isso é «sincronização», e a palavra é o problema. Sincronizar implica dois sistemas a convergirem para uma verdade. O que existe na realidade é uma pergunta campo a campo que tem de ser respondida de antemão e escrita: para esta coluna, neste objeto, quem decide? Responda uma vez com um encolher de ombros e terá construído um sistema que sobrepõe uma edição local deliberada às três da manhã, ou um sistema que ignora em silêncio uma alteração que o cliente fez há uma hora e julga ter chegado.

Foi assim que respondemos, incluindo os campos em que a resposta é não.

Quatro valores, e não são graus de confiança

Todas as colunas de todos os objetos ligados levam um de quatro valores de titularidade, e eles dizem quatro coisas diferentes sobre quem decide, e não quatro níveis de confiança.

Externo. O outro lado decide. O campo é só de leitura aqui e uma importação sobrepõe-se-lhe sem perguntar. Isso não é uma perda de controlo, é o acordo em que o administrador entrou ao ligar o sistema.

Nosso. Decidimos nós, e uma importação não lhe toca. É este o estado de todos os campos de um objeto que não está ligado de todo, e de todos os campos para os quais o sistema externo não tem equivalente.

Bloqueado manualmente. O outro lado tem de facto um valor, e um administrador sobrepôs-se-lhe deliberadamente aqui, com uma razão. Uma diferença passa então a ser um conflito que é mostrado, nunca uma sobreposição silenciosa. É o único dos quatro que não pode surgir por predefinição: alguém o define.

Derivado. Não decide ninguém. Decorre de outra coisa: de a máquina estar ou não em bastidor, de estar ou não vinculada a um serviço, de estar ou não pronta, da capacidade de um bastidor, da escrituração da própria linha. Estes são estruturalmente não importáveis, e um teste afirma que nunca aparecem em mapeamento nenhum.

Este último merece uma nota. Os campos de escrituração, quem criou uma linha e quando, são derivados e não nossos. Ninguém escolhe esses valores, eles decorrem da ação. Um caminho de importação com autorização para escrever uma data de criação é um caminho de importação que consegue reescrever a história.

A titularidade fica pendurada na ligação e não no objeto. Um objeto sem ligação é inteiramente nosso, o que quer dizer que desligar é uma única eliminação e não uma migração de estado ao longo de todas as colunas.

O registo é por coluna, e a lista de colunas vem do esquema

Todas as colunas dos quatro tipos de objeto suportados, instalações, localizações, bastidores e máquinas, têm uma entrada num registo. Incluindo aquelas que não têm absolutamente nada que ver com o sistema externo.

Essa completude é imposta e não apenas pretendida. Um teste deriva a lista de colunas do esquema da base de dados e exige uma decisão para cada uma. Uma coluna nova acrescentada numa ronda posterior é portanto um teste vermelho em vez de uma lacuna silenciosa, que é a mesma construção que usamos noutros pontos: um teste por caso não consegue, pela sua natureza, encontrar um caso que falta.

Algumas das decisões são a parte interessante.

O orçamento de energia de um bastidor continua nosso. O NetBox modela a energia como alimentações, e não como um único valor de orçamento. Derivar um número a partir de várias alimentações seria uma afirmação de capacidade montada a partir de dados incompletos, que é precisamente aquilo que o desenho da capacidade proíbe. Por isso o campo não é importado, com essa frase registada ao lado dele como razão.

O estado de processo de uma máquina continua nosso. O estado de dispositivo do NetBox mistura ciclo de vida e operação num só campo. Um dispositivo marcado como avariado iria, num mapeamento ingénuo, empurrar uma máquina para um estado de manutenção e tirá-la do conjunto vendável. São dois vocabulários diferentes que por acaso partilham um nome.

A espécie de uma máquina continua nossa. O papel de dispositivo do NetBox é texto livre. Adivinhar mal aí não produz um erro cosmético, muda aquilo que a plataforma deixa fazer com uma máquina.

Cada uma destas fica guardada com uma razão escrita, na mesma estrutura da decisão. Uma regra com uma razão agarrada sobrevive à pessoa seguinte; uma regra sem razão é relaxada por alguém que parte do princípio de que era arbitrária.

Só na primeira vez, porque há autocolantes numa caixa

Dois campos são importados uma vez, na criação, e nunca mais atualizados: o código de uma instalação, localização ou bastidor, e a etiqueta de ativo de uma máquina.

A razão é física. Esses valores estão impressos em etiquetas, e as etiquetas estão numa caixa numa arrecadação. Um slug mudado no NetBox na próxima primavera não pode mandar uma leitura para o sítio errado. Só na primeira vez não é um terceiro valor de titularidade, é uma propriedade da importação: leve-o ao acrescentar e deixe-o em paz a partir daí.

Esses mesmos campos são aquilo por que um objeto não ligado é emparelhado quando a ligação é feita pela primeira vez: o código para os outros três, a etiqueta de ativo para as máquinas. Deliberadamente não o nome, porque um código é estável e único sem distinguir maiúsculas de minúsculas, e um nome não é nem uma coisa nem outra.

A colocação nunca é importada, e não há campo que lá leve

O NetBox conhece, para todos os dispositivos, o seu bastidor, a sua posição e a sua face. Esses três são recusados.

Não ignorados. Recusados, pelo nome, com um código de razão, e mostrados na pré-visualização.

O raciocínio decorre diretamente do desenho da ocupação: o único limite real à ocupação de um bastidor é um índice único parcial sobre a tabela de slots, e esse índice só alguma vez é tocado por uma função. Um caminho de importação que escreva um bastidor e um número de unidade numa máquina é um segundo caminho de escrita que não sabe desse índice, e então um dia uma máquina fica registada em dois bastidores com um sistema externo a confirmar que está correto.

A especificação desta secção diz que uma colocação local ou uma marcação ativa nunca podem ser apagadas por uma importação. Há duas maneiras de tornar isso verdade. Uma é escrever a importação de modo a que deixe as marcações em paz. A outra é tornar impossível que a importação escreva sequer uma marcação, e foi essa que seguimos: não há campo que lá leve.

Impor isso é uma guarda sobre a árvore de sintaxe abstrata e não um caso de teste. Lê o código do módulo de importação e exige que as quatro tabelas protegidas, as marcações, os slots, os vínculos de serviço e as etiquetas, apareçam apenas dentro de um select. Um insert, um update ou um delete sobre qualquer uma delas fica vermelho mesmo que caminho de código nenhum lá chegue, porque a garantia tem de valer para código que ainda não existe. O percorredor falha de forma ruidosa perante uma forma que não reconhece, que é uma lição aprendida da maneira cara numa guarda anterior que saltava em silêncio aquilo que não conseguia interpretar.

As recusas são listadas pelo nome na pré-visualização. A omissão silenciosa é a versão perigosa aqui: alguém liga o seu NetBox, lê «142 máquinas atualizadas» e parte do princípio de que o seu esquema de bastidores veio junto.

Uma eliminação externa é um tombstone

Um objeto ligado que o outro lado deixa de mencionar torna-se um tombstone com uma revisão de impacto, e não uma eliminação.

Isso não é mera cortesia. Uma lista que volta mais curta por causa de um erro de filtro, de uma alteração de permissões ou de uma página obtida a meio esvaziaria de outro modo o inventário de um cliente. O tombstone põe o objeto à frente de uma pessoa, juntamente com aquilo que depende dele: um objeto com uma marcação ativa não pode ser removido de todo e, depois de a marcação ser libertada, o desfecho é um abate e não uma eliminação.

E se se souber que a obtenção veio truncada, não acontece rigorosamente nada. Não é proposto nenhum tombstone para coisa nenhuma. Daquilo que não se viu não se pode concluir que falta. É uma condição de duas linhas e é a diferença entre um conector e um incidente.

O que registaríamos

1. 01Decida a titularidade por coluna e não por objeto, e faça a lista de colunas vir do esquema para que uma coluna nova não possa ser esquecida.
2. 02Guarde a razão com a decisão. Um campo que não é importado precisa de uma frase, ou alguém o importa mais tarde.
3. 03Torne impossível a importação perigosa, em vez de cuidadosa. Nenhum campo lá leva, mais uma guarda que lê o código.
4. 04Nomeie na pré-visualização aquilo que recusa, porque um número de objetos atualizados lê-se como completude.
5. 05Trate a ausência como uma pergunta, nunca como uma eliminação, e trate uma obtenção truncada como informação nenhuma.

Quanto ao nosso próprio estado: isto vive atrás de um sinalizador de lançamento que está desligado por predefinição, com uma definição por organização por cima, pelo que não é coisa que se compre hoje, e nunca correu contra um NetBox real. Aquilo que acima se diz sobre a forma como o NetBox modela a energia, o estado e os papéis vem da sua documentação e da forma da sua interface, e não de uma instância em produção. Tudo o que está acima foi medido contra um duplo de testes que reproduz o comportamento de paginação, o cabeçalho de versão e os objetos aninhados da interface real, fixado na versão da API que o código de produção envia. O duplo oferece genuinamente um bastidor, uma posição e uma face nas suas cargas de dispositivo, e são escritas zero marcações: a recusa é medida e não presumida. A questão relacionada de porque é que um sistema externo a comunicar sucesso não é por si só um resultado está em porque é que um 200 do Proxmox não é um resultado.

Do trabalho de centro de dados na Provibr. A fronteira de ocupação de que esta importação é mantida afastada está descrita em o único limite real à ocupação de um bastidor, e as etiquetas cujos códigos têm de se manter estáveis em uma etiqueta que sobrevive a um novo hostname.