Produits Entr'ouvert » Hobo

Frédéric Péters a écrit :

Ça retourne dans un attribut "leftover_audience" les endroits où le provisionning a échoué, je me suis demandé si on voulait mettre 'err': 1 au cas où il y a quelque chose dedans, je ne l'ai pas fait.

Tu as une raison pour ça ? Pour ma part je préfère un err:1 au moindre pépin, histoire qu'on ne se retrouve pas avec des conditions bizarres en Django dans les workflows pour gérer les pépins.

Au sujet des pépins potentiels je vois les timeout : faire en sorte que authentic réponde dans un délai maxi de 20 secondes est nécessaire à mon avis. J'imagine bêtement un truc genre :

  ...
  total_timeout = 20  # pourrait venir dans la signature de la fonction, genre total_timeout=120 par défaut en mode de notif classique
  for audience in rest_audience:
      start_time = time.time()
      try:
          requests.put(..., timeout=min(total_timeout, 5))
      except requests.RequestException as e:
          logger.error(u'error provisionning to %s (%s)', audience, e)
      else:
          leftover_audience.remove(audience)
      total_timeout = total_timeout - (time.time() - start_time)
      if total_timeout <= 0:
          logger.error(u'global notify_agents_http timeout'
          break
   ....

Tu as une raison pour ça ?

La même que pour le fallback amqp qui existe pour le provisionning HTTP, parfois un service est down, genre redémarrage, mais oui pour mettre err: 1.

Au sujet des pépins potentiels je vois les timeout : faire en sorte que authentic réponde dans un délai maxi de 20 secondes est nécessaire à mon avis. J'imagine bêtement un truc genre :

S'il y a timeout l'appelant verra bien qu'il y a un soucis à l'appel; je n'ajouterais rien de particulier ici.

Frédéric Péters a écrit :

oui pour mettre err: 1.

Impec.

Au sujet des pépins potentiels je vois les timeout : faire en sorte que authentic réponde dans un délai maxi de 20 secondes est nécessaire à mon avis. J'imagine bêtement un truc genre :

S'il y a timeout l'appelant verra bien qu'il y a un soucis à l'appel; je n'ajouterais rien de particulier ici.

Ça me va, je ne sais pas pourquoi je cherche toujours à me compliquer la vie.

• ajouter ?sync lors d'un POST sur l'API des rôles
• détecter ça dans le provisionning 'sync' in StoreRequestMiddleware.get_request().GET
• activer alors un provisioning synchrone en priorité pour les services combo (si la requête vient de w.c.s. c'est via une action ajouter un rôle, et elle est faite d'abord localement) et ensuite les autres services de façon classique

Là il me semble que ça va demander pas mal de paramétrage dans w.c.s. pour être utilisé alors que l'ajout de sync pourrait être une simple case à cocher dans les actions ajouter/retirer un rôle.

Est-ce qu'il a été identifié un besoin de provisionning synchrone pour autre chose que combo ?

C'est écrit dans la description du ticket le problème immédiat c'est le provisionning des utilisateurs, pas des rôles; il y a un lien vers l'origine dans mon premier commentaire mais c'est en fait assez courant qu'authentic soit contourné. Sur l'option d'ajouter un paramètre inconnu d'authentic sur une de ses API, ça ne m'a pas effleuré l'esprit mais je n'y serais pas allé par peur de venir avec des contraintes extérieures sur ces API (déjà placer cette API sous /api/ j'ai hésité…).

Je sais que l'air du temps est à multiplier les appels de web-service plutôt que les actions de workflow; mais alors dans ce cas précis de lier une objet de w.c.s. à un utilisateur dont w.c.s. vient de demander la création, je ferai comme pour les actions ajouter/retirer rôle, je ferai un minimum de boulot localement dans une action "custom" de création d'utilisateur. Comme on connaît l'uuid et 2/3 attributs on pourrait crééer l'utilisateur immédiatement au retour de l'appel à authentic. Il faudrait revoir le code de provisionning qui n'est pas top sur les création concurrentes.

Je ne vois un intérêt à la complication de ce genre de billard à 3 bandes que quand il y a plus de 2 briques en jeu. Mais je valide le patch de mon coté et je laisse le dernier mot à Thomas.

cf le commentaire derrière le lien qui reprend cette idée et dit pourquoi non : "alternativement dans w.c.s. il y aurait une action native de création d'usager, comme on a l'ajout/retrait de rôle à un usager, (mais on dira que c'est encombrer l'interface d'une action bien rarement utile)".

C'est vrai qu'on est à 3 ou 4 bandes mais j'aime relativement bien l'idée que pour la gestion des utilisateurs, c'est Authentic qui pilote et donc on doit lui dire quoi faire (y compris s'il faut créer un utilisateur dans wcs alors qu'on est dans wcs...). Finalement c'est du billard, c'est quand même mieux que du cross-country (je créé l'utilisateur dans authentic et je récupère l'uuid et je crée un utilisateur localement en lui ajoutant un identifiant saml pour faire croire qu'il vient d'authentic).

Idée de ce soir : pour aider au support et à la compréhension des résultats, je pense que dans le retour du webservice on devrait aussi envoyer l'audience qui a réussi à être jointe, dans une clé "audience". Je sais que ça aidera/rassurera beaucoup de mes collègues.

Ou alors prenons le problème à l'envers, quand on affecte un uuid inconnu à une fiche, w.c.s. pourrait simplement requêter /api/users/<uuid>/ voir si l'utilisateur n'existerait pas et le provisionnerait à la volée. Un appel de WS en moins.