Lorawan-stack: Réutilisation des EUI des passerelles supprimées

Créé le 7 août 2019  ·  7Commentaires  ·  Source: TheThingsNetwork/lorawan-stack

Résumé

Lorsque vous supprimez une passerelle, puis en ajoutez une nouvelle avec le même EUI, si cela échoue car il se plaint que la passerelle existe déjà.

Étapes à suivre pour reproduire

  1. Supprimer une passerelle existante
  2. Ajoutez-le à l'aide de la CLI ou
  3. Ajoutez-le à l'aide de l'API

Que voyez-vous maintenant ?

{
    "code": 6,
    "message": "error:pkg/identityserver/store:already_exists (entity already exists)",
    "details": [
        {
            "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
            "namespace": "pkg/identityserver/store",
            "name": "already_exists",
            "message_format": "entity already exists",
            "attributes": {
                "field": "gateway_eui",
                "value": "'3135313749005303'"
            },
            "correlation_id": "c0dc6bb73d714702bd8d0be57e83f369"
        }
    ]
}

Que veux-tu voir à la place ?


Créer avec succès la nouvelle passerelle

Environnement

amazon linux utilisant TTN CLI et Postman utilisant API Call

Comment proposez-vous de mettre cela en œuvre ?

Lorsque l'utilisateur essaie d'insérer une passerelle supprimée, mettez à jour l'indicateur supprimé sur false

Pouvez-vous le faire vous-même et soumettre une demande d'extraction ?

...

identity server in progress

Tous les 7 commentaires

J'ai un peu mis à jour ce problème pour avoir une portée légèrement différente de # 1121, que nous pouvons faire plus sur la restauration des entités supprimées en général (au lieu des seules applications).

Dans le numéro actuel, concentrons-nous davantage sur l'ajout de nouvelles passerelles avec le même EUI qu'une passerelle supprimée.

Lié à https://github.com/TheThingsNetwork/lorawan-stack/issues/604 (libération des identifiants/EUI)

@htdvisser même avoir https://github.com/TheThingsNetwork/lorawan-stack/issues/1703 (maintenant dans Next Up) ne couvre pas entièrement le cas d'utilisation courant de pouvoir créer une passerelle avec un EUI qui a déjà été utilisé . Faire une boucle dans un administrateur pour purger une entité n'est pas une expérience utilisateur agréable, et purger une entité est plus destructeur que de simplement libérer l'EUI.

Afaik, nous n'avons pas de problèmes de sécurité avec la libération de l'EUI lors de la suppression de la passerelle. C'est déjà facultatif. Cela rendrait, évidemment, la récupération partielle, c'est-à-dire que l'EUI a disparu, mais je pense que c'est acceptable et correspond également à la façon dont les EUI de l'appareil sont libérés immédiatement lors de la suppression.

Pouvons-nous résoudre ce problème en publiant simplement l'EUI lors de la suppression de la passerelle ? Si non, pourquoi pas ?

Oui, nous pourrions mettre à jour le champ Gateway EUI à nil/NULL lors de la suppression. Cela devrait être aussi simple que d'ajouter un

// AfterDelete releases the EUI of a Gateway after it is deleted.
func (gtw *Gateway) AfterDelete(db *gorm.DB) error {
    return db.Unscoped().Model(gtw).UpdateColumn("gateway_eui", nil).Error
}

en pkg/identityserver/store/hooks.go .

@bafonins pouvez-vous ramasser ça?

@adamsondelacruz veuillez rouvrir si https://github.com/TheThingsNetwork/lorawan-stack/pull/1843 ne résout pas le problème.

Cette page vous a été utile?
0 / 5 - 0 notes