ereuse/devicehub-django
8
0
Fork 0
Code Issues 5 Pull requests 6 Packages Projects Releases Wiki Activity

upload_legacy_snapshot #40

Merged
pedro merged 4 commits from upload_legacy_snapshot into main 2025-01-23 11:25:19 +00:00
Conversation 6 Commits 4 Files changed 17 +1257 -412
cayop commented 2024-12-19 11:32:35 +00:00
Owner
Copy link

contexto: desde que se hizo merge de dpp, dejaron de subirse bien los legacy snapshots, este PR trata de resolver este problema

related #39

contexto: desde que se hizo merge de dpp, dejaron de subirse bien los legacy snapshots, este PR trata de resolver este problema related https://farga.pangea.org/ereuse/devicehub-django/issues/39
cayop self-assigned this 2024-12-19 11:32:35 +00:00
pedro was assigned by cayop 2024-12-19 11:32:35 +00:00
cayop added 3 commits 2024-12-19 11:32:36 +00:00
pedro commented 2024-12-19 17:15:27 +00:00
Owner
Copy link

te propongo que:

  1. todas las funciones legacy empiecen por legacy_ (he visto get_legacy y set_legacy en algunos casos, pero será más fácil identificarlas todas de esa manera)
  2. cuando hay aportaciones a funciones existentes, encapsularlos en funciones legacy_

esto ayudaría a futuro, separar lo que es inxi vs legacy (incluso por algún refactor futuro quién sabe), o incluso acabar haciendo cleanup de aquí a, ejemplo, 5 años vista

qué te parece?

te propongo que: 1. todas las funciones legacy empiecen por `legacy_` (he visto get_legacy y set_legacy en algunos casos, pero será más fácil identificarlas todas de esa manera) 2. cuando hay aportaciones a funciones existentes, encapsularlos en funciones `legacy_` esto ayudaría a futuro, separar lo que es inxi vs legacy (incluso por algún refactor futuro quién sabe), o incluso acabar haciendo cleanup de aquí a, ejemplo, 5 años vista qué te parece?
cayop force-pushed upload_legacy_snapshot from 13bac41f9f to 51a7c7d119 2024-12-20 16:05:43 +00:00 Compare
cayop commented 2024-12-20 16:11:50 +00:00
Author
Owner
Copy link

He hecho una refactorización brutal de esta rama y es nueva. Viene de main asi que no debería de haber problemas.
Tienes razón con lo de poner legacy_ pero he pensado que es mejor que sea un parse totalmente nuevo si es Legacy. De esta forma no ensuciamos mucho el parse que se tiene que quedar y podremos borrar el legacy en el futuro sin mucho drama. Ahora queda mucho más limpio. Gracias por el consejo. Me ha dado un poco de trabajo pero ha valido la pena.
Her probado lo minimo. Osea:

  • snapshot legacy
  • snapshot no legacy y normal
  • snapshot como credential
  • snapshot dpp
  • snapshot dpp como credential
He hecho una refactorización brutal de esta rama y es nueva. Viene de main asi que no debería de haber problemas. Tienes razón con lo de poner legacy_ pero he pensado que es mejor que sea un parse totalmente nuevo si es Legacy. De esta forma no ensuciamos mucho el parse que se tiene que quedar y podremos borrar el legacy en el futuro sin mucho drama. Ahora queda mucho más limpio. Gracias por el consejo. Me ha dado un poco de trabajo pero ha valido la pena. Her probado lo minimo. Osea: - [x] snapshot legacy - [x] snapshot no legacy y normal - [ ] snapshot como credential - [ ] snapshot dpp - [ ] snapshot dpp como credential
pedro commented 2024-12-20 18:13:22 +00:00
Owner
Copy link

Sí!! Buenísimo, mucho mejor 👏

Desde ahí, te propongo seguir por aquí: subir versión recortada-minimalista [1] de snapshot:

  1. legacy
  2. inxi (no legacy y normal)
  3. inxi como VC (como credencial)

Con eso yo puedo hacer un script de subida de snapshots (CURL POST) que quizá podría ejecutar tanto con DPP y sin; y así, cualquier cambio de parser lo podemos cubrir para validar que no rompe lo que ya funciona; luego se puede acabar integrando en test end to end; vamos viendo. Pero me parece pertinente dejar también esto listo sino ya con este PR muy próximamente.

Y por cierto, estos snapshots también podrían venir por defecto para la demo.

Si quieres lo vemos juntas en una sesión

[1] los snapshots se van fácilmente a los 150-200 KB, la propuesta, es reducir todo aquel texto string que no usa el parser (renombrando string largísima por "etc" o "lorem ipsum" o lo que tú quieras), y toquitear los otros datos para que tampoco se correspondan con ningún equipo real

Sí!! Buenísimo, mucho mejor 👏 Desde ahí, te propongo seguir por aquí: subir versión recortada-minimalista [1] de snapshot: 1. [ ] legacy 2. [ ] inxi (no legacy y normal) 3. [ ] inxi como VC (como credencial) Con eso yo puedo hacer un script de subida de snapshots (CURL POST) que quizá podría ejecutar tanto con DPP y sin; y así, cualquier cambio de parser lo podemos cubrir para validar que no rompe lo que ya funciona; luego se puede acabar integrando en test end to end; vamos viendo. Pero me parece pertinente dejar también esto listo sino ya con este PR muy próximamente. Y por cierto, estos snapshots también podrían venir por defecto para la demo. Si quieres lo vemos juntas en una sesión [1] los snapshots se van fácilmente a los 150-200 KB, la propuesta, es reducir todo aquel texto string que no usa el parser (renombrando string largísima por "etc" o "lorem ipsum" o lo que tú quieras), y toquitear los otros datos para que tampoco se correspondan con ningún equipo real
cayop commented 2024-12-21 00:18:37 +00:00
Author
Owner
Copy link

Tambien pienso que podríamos desacoplar más el tema del parseo. Osea seguir con lo que he hecho hasta ahora pero llendo más alla.
Un punto de entrada Interfaz de programación que interactue con el sistema de forma homogenea y luego modulos de parseo que se acoplan a esta interfaz. Esto nos permitiría habilitar parseos diferentes sin tocar los demás y sin poner en riesgo a los demás. Sería más fácil para terceras personas hacer sus propios modulos de parseo y acoplarlos al sistema. No creo que me costase mucho tiempo hacerlo y vale la pena.
No apruebes por ahora este PR hasta que haga esto.

Tambien pienso que podríamos desacoplar más el tema del parseo. Osea seguir con lo que he hecho hasta ahora pero llendo más alla. Un punto de entrada Interfaz de programación que interactue con el sistema de forma homogenea y luego modulos de parseo que se acoplan a esta interfaz. Esto nos permitiría habilitar parseos diferentes sin tocar los demás y sin poner en riesgo a los demás. Sería más fácil para terceras personas hacer sus propios modulos de parseo y acoplarlos al sistema. No creo que me costase mucho tiempo hacerlo y vale la pena. No apruebes por ahora este PR hasta que haga esto.
cayop added 1 commit 2025-01-11 19:44:52 +00:00
cayop added 1 commit 2025-01-13 16:58:08 +00:00
pedro commented 2025-01-23 09:17:31 +00:00
Owner
Copy link

en reunión con cayo repasamos que tal como está ahora, los parsers funcionan así (por tenerlo en algún sitio documentado), parse: redirige al parse adecuado:

  1. normal_parse: el que está por defecto entran, via workbench-script:
    1.1 no firmado de workbench-script -> example/snapshots/snapshot_workbench-script_non-signed.json
    1.2 no firmado de workbench-script (idhub fallido, genera operator id via token idhub) -> example/snapshots/snapshot_workbench-script_non-signed_idhub-unreachable.json
    1.3 json firmados -> example/snapshots/snapshot_workbench-script_signed.json
  2. old_parse: workbench 11 -> example/snapshots/snapshot-workbench11.json
  3. legacy_parse: workbench_script legacy -> example/snapshots/snapshot_workbench-script_legacy.json

see commit 983971e8c7

en reunión con cayo repasamos que tal como está ahora, los parsers funcionan así (por tenerlo en algún sitio documentado), **parse**: redirige al parse adecuado: 1. normal_parse: el que está por defecto entran, via workbench-script: 1.1 no firmado de workbench-script -> `example/snapshots/snapshot_workbench-script_non-signed.json` 1.2 no firmado de workbench-script (idhub fallido, genera operator id via token idhub) -> `example/snapshots/snapshot_workbench-script_non-signed_idhub-unreachable.json` 1.3 json firmados -> `example/snapshots/snapshot_workbench-script_signed.json` 2. old_parse: workbench 11 -> `example/snapshots/snapshot-workbench11.json` 3. legacy_parse: workbench_script legacy -> `example/snapshots/snapshot_workbench-script_legacy.json` see commit https://farga.pangea.org/ereuse/devicehub-django/commit/983971e8c771b7247edf1b02363f32594188b8c3
pedro added 1 commit 2025-01-23 11:09:26 +00:00 
coauthored with cayo
pedro commented 2025-01-23 11:20:31 +00:00
Owner
Copy link

de esta manera hemos probado con todos los snapshots soportados y funcionan bien, listo para mergear

de esta manera hemos probado con todos los snapshots soportados y funcionan bien, listo para mergear
pedro force-pushed upload_legacy_snapshot from 983971e8c7 to 01db6a3e8e 2025-01-23 11:24:35 +00:00 Compare
pedro merged commit 754820f631 into main 2025-01-23 11:25:19 +00:00
pedro deleted branch upload_legacy_snapshot 2025-01-23 11:25:22 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
cayop
pedro
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: ereuse/devicehub-django#40
No description provided.
Delete branch "upload_legacy_snapshot"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?