We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

Paramètres bulk-delete HubiC


vcasse
08-20-2015, 09:50 AM
Exactement

dynamic-lab
08-19-2015, 06:00 PM
Ok d'accord j'avais déjà remarqué pour les HubiC-DeskBackup et HubiC-Backup_. J'avais pas vu le coup de la metadata Enddate.
Je verifierais ça dans la prochaine release pour marquer en-cours ou incomplète alors.

Ca explique mon problème de container jamais affiché après une erreur de transfert.

vcasse
08-19-2015, 04:50 PM
Salut Mic,

La webapp affiche les backups selon plusieurs regles.

Si leur nom commence par "HubiC-DeskBackup" pour les backups de desktop ou "HubiC-Backup_" pour les backups mobiles.
Pour les backups mobiles, uniquement si le backup indique une date de fin (metadata sur le container "X-Container-Meta-Hubic-Backup-Enddate".

Cordialement,
Vincent

dynamic-lab
08-19-2015, 04:28 PM
Ok merci pour l'info.

Oui j'ai vu que l'historique des versions ou autres des containers de backups n'est pas géré par le paramètre "X-Versions-Location". J'envisage une fonction de sauvegarde périodique du smartphone pour compléter celle existante sur l'appli officielle mais je le ferais surement à partir d'un container spécifique.

A ce propos je suppose que les containers de backup ne sont considéré comme accessible au niveau de l'application web qu'une fois mis dans une base de donnée spécifique à HubiC car j'ai fais 2 sauvegardes de mon téléphone Nexus qui ont échoué à chaque fois sur les 2 dernières vidéos a sauvegardé et en utilisant l'API je vois bien les 2 containers qui contiennent toute la backup sauf les 2 fichiers d'où provient l'erreur.
A l'occaz si vous pouvez voir pour vérifier ce problème de backup qui échoue et qui reste quand même ... enfin je suis pas là pour ça.

Mic

vcasse
08-19-2015, 03:49 PM
Pour les modifications sur default : toutes les applications officielles travaillent sans lien entre elle.
Ainsi, les applications peuvent s'attendre à tous les cas possible (le fichier a été supprimé entre deux, de nouveaux fichiers sont arrivés...).

Donc pas de soucis si tu pousses des fichiers durant une synchronisation : elle ne plantera pas pour ca (et ne supprimera pas tes fichiers).

Attention: les containers de backups sont conçu pour n'être géré QUE par l'application qui la manage. Sur ces containers il peut y avoir des conflits. (Le mieux est de ne permettre que l'affichage ou la suppression globale du container).

Cordialement,
Vincent

dynamic-lab
08-19-2015, 02:20 PM
Merci pour les conseils.

Je compte effectivement d'abord commencer par du bulk-delete ciblé sur quelques fichiers en même temps et parallélisé.
Je suis pour l'instant très méfiant sur les fonctionnalités qui interagisse avec des containers utilisaient par les applications officiels hubic comme default. L'interaction en cas de modification pendant une phase de synchronisation risque d'être épic.

Pour des fonctionnalités géré par un serveur tiers je verrais sur des containers dédiés avec des fonctions particulières et en dehors de l'usage des applications hubic à mon avis.

vcasse
08-19-2015, 12:59 PM
Bonjour Mic,

Attention au serveur tiers: tu ne peux pas remonter les évènements que d'autres applications réalisent sur hubic. Donc tu peux avoir pas mal de cas d'inconsistence..

A mon avis, le mieux est de multiplier les bulk-delete avec chacun un nombre limité de fichiers à supprimer. Tu peux aussi paralléliser par trois ou quatres les requêtes

Cordialement,
Vincent

dynamic-lab
08-19-2015, 09:45 AM
Ok merci pour cette réponse complète. Il n'y a donc pas de soucis et c'est ma vérification à base de fichiers inexistant qui était incorrecte.
Bon donc il ne me reste qu'à tester en générant des vrais erreurs pour pouvoir gérer ces autres cas.

Merci de votre retour sur les requête longue, je pense que je vais restreindre la capacité à quelques fichiers en une seule fois ou une faible quantité de données. Je réfléchi aussi à une solution en passant par un serveur tiers auquel le fichier tar.gz ou tar.bz2 serais envoyé puis transmis à Openstack, la reprise en cas d'erreur ou autre serais plus aisé et la connexion plus stable également.

Merci,

Mic

vcasse
08-19-2015, 09:17 AM
Salut Mic,

Peux tu nous envoyer une partie du fichier @list_file ? Le soucis provient probablement de la dedans.

Aprés vérification sur la doc, et dans le code de Openstack, les fichiers non trouvés ne sont pas classés comme "erreurs". D'ailleurs, c'est assez logique. Supprimé un fichier déjà absent, c'est comme si tu venais de le supprimer

Pour la durée du timeout, non nous n'en avons pas car elle ne dépend pas que de nous. On déconseille les requêtes > 10 minutes. (et plus c'est petit, mieux c'est !) Imagine la problématique pour une personne en déplacement, qui change d'antenne réguliérement... Les requêtes longues vont naturellement tomber en timeout

Cordialement,
Vincent

dynamic-lab
08-14-2015, 12:40 PM
Voici la requête que j'ai utilisé pour supprimer ces fichiers
curl -i -H "X-Auth-Token: $TOKEN" -H "Content-Type: text/plain" -H "Accept: application/json" -X DELETE https://lb9911.hubic.ovh.net/v1/AUTH...X/?bulk-delete --data-binary @list_file.txt

Le XXX remplaçant mon identifiant API, $TOKEN étant un token d'accès valide et le list_file.txt étant un fichier respectant l'encodage des url etc...
Là les fichiers n'étaient pas trouvés car j'ai fais exprès de changer les URLs mais seulement dans le champs errors par contre il n'y avait pas les fichiers non supprimés ce qui devrait être le cas.

Aves-vous un chiffre du temps à partir duquel une requête tombe en timeout ? J'ai fais un test avec 1800-2000 fichiers le tout faisant 150Mo et la requête a pris 15min sans soucis de timeout.

Je comprend bien le problème du timeout c'est pour ça que j'aimerais bien que la requête envoie les fichiers synchronisés et non synchronisés en réponse. La réponse est toujours avec un champ errors vide []. La doc openstack indique que le champ errors devraient intégrés pour chaque fichier la bonne suppression ou non.

D'avance merci,

Mic

vcasse
08-14-2015, 10:59 AM
Bonjour Mic,

Tout d'abord, la limite est de 10000, comme par défault. Après, on conseille d'en faire moi, car sinon, la requête risque d'être trop longue et de tomber en timeout... ce qui fait que tu ne sauras pas quels fichiers sont supprimés et lesquels ne le sont pas.

Ton résulat indique bien qu'il y a eu des fichiers non trouvés 11. De mémoire, il me semble que les fichiers sont affichés dans erreur si une erreur a lieu durant la suppression. La 404 étant remontée avant.

Si ca ne passe toujours pas, peux tu poser ta requête afin de comprendre l'origine du soucis ?

Cordialement,
Vincent

dynamic-lab
08-12-2015, 11:53 PM
Bonjour,

Dans le but d'intégrer la fonctionnalité bulk delete au sein de mon application je souhaiterais savoir combien de fichiers maximum il est possible de supprimer avec une requête bulk-delete avec les paramètres hubiC ?

Est-ce la configuration par défaut ? ( 10 000)

J'ai réalisé plusieurs tests avec curl et la réponse en cas d'échec sur un ou plusieurs fichiers n'inclut pas de détails sur les fichiers concernés comme la doc openstack l'indique. Je me retrouve avec une réponse de ce type :
HTTP/1.1 200 OK
Content-Type: application/json
X-Trans-Id: 5A26A873:C3BD_253B4C64:01BB_55CBCBE7_487685C:5ABA
Date: Wed, 12 Aug 2015 22:42:48 GMT
Transfer-Encoding: chunked
Connection: close
{"Number Not Found": 11, "Response Status": "200 OK", "Errors": [], "Number Deleted": 0, "Response Body": ""}

Est-ce une configuration particulière de votre côté ou une mauvaise requête en curl qui n'intègre pas le détails des fichiers dans le champs "Errors" ?

D'avance merci,

Mic