Lorawan-stack: Réutilisation des EUI des passerelles supprimées
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
- Supprimer une passerelle existante
- Ajoutez-le à l'aide de la CLI ou
- 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 ?
...
adamsondelacruz
Tous les 7 commentaires
htdvisser
le 7 août 2019
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.
htdvisser
le 7 août 2019
Lié à https://github.com/TheThingsNetwork/lorawan-stack/issues/604 (libération des identifiants/EUI)
htdvisser
le 7 août 2019
@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 ?
johanstokking
le 5 janv. 2020
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 .
htdvisser
le 9 janv. 2020
@bafonins pouvez-vous ramasser ça?
johanstokking
le 9 janv. 2020
@adamsondelacruz veuillez rouvrir si https://github.com/TheThingsNetwork/lorawan-stack/pull/1843 ne résout pas le problème.
bafonins
le 13 janv. 2020
Questions connexes
ecities
·
14Commentaires
kschiffer
·
16Commentaires
htdvisser
·
18Commentaires
beitler
·
16Commentaires
adriansmares
·
12Commentaires