 ¡Hola a todos! ¡Bienvenidos a OpenShift and View! Hoy estamos de nuevo en María Baratso, es Scott McCarty, y tenemos un invitado especial a Carlos Eduardo Arango Gutiérrez. Carlos, ¿te lo dejará esta audiencia? Es tan difícil cambiarse al español. Estaba pensando en saludar en inglés. Sí, mi nombre es Eduardo Arango, llevo ya casi un año trabajando para Red Hat, desarrollando para OpenShift, vivo en Cali, Colombia, hablo español de forma nativa, y es para mí muy emocionante y un gran honor hablar en español de lo que yo hago. Va a ser muy difícil, pero lo voy a intentarlo con todo el amor, porque en verdad quiero traer todo ese conocimiento para la región. Qué bueno, Carlos, nos encanta tenerte aquí, ya vas a ver que con Scott, la presentación anterior también fue un poco de medio Spanish, pero yo creo que somos bastante flexibles, y me encanta tenerte aquí. Y Scott, nos saludas y dejo una breve introducción de ti. Yo soy de Ohio, yo soy un gringo, pero ya, yo hablo de español y me encanta hacer esto con ustedes. Yo soy muy emocionado también. Qué bien, bueno, Carlos, empecemos y vamos al próximo slide. Hoy vamos a hablar de OpenShift Builds. Y yo quería darles, primero un poquito, ubicarnos donde estamos. Generalmente yo hablo más sobre la parte de plataformas, así que hoy en la parte de AppyDev, voy a dejárselo más a Scott, pero quería comentarles un poco sobre nuestro roadmap, todas las features que tenemos que vienen ahora en OpenShift 4.6, 4.7, 4.8, que pueden ver que OpenShift Builds es una de esas features que nosotros sacamos y esperamos tener está en Technology Preview, STP Technology Preview, y lo que esperamos es que clientes de la comunidad que sea lo use, nos den feedback, nos cuenten qué les parece, cómo la usan, para luego poder graduarlas a General Availability o GA. Entonces esta es una de esas features que ya están en el producto, ya funciona, ya la pueden utilizar y quizás estamos esperando un poco más de feedback para saber qué tuarcas tenemos que apretar. La siguiente slide, como les contaba, está en la parte en el espacio de Application and Development, no necesariamente en la parte de la plataforma como tal, o sea es una de las cosas de OpenShift que va más allá de Kubernetes solamente, y son Container Images que crean utilizando el código base directamente en herramientas de Kubernetes. ¿Nos cuentas un poco más de Pipeline? Quizás debo decir un poquito de la historia, un poquito. En OpenShift 3 tuvimos como dos estrategías de construir imágenes de contenedores, más o menos, tuvimos una estrategía de Docker y también de Source to Image, y la diferencia es que si usted tiene un Dockerfile, es mejor solo usar la estrategía de Docker, pero si solo quieres apuntarlo como por ejemplo al URL de GitHub y solo tienes tu código ahí, tú puedes ponerlo ahí y se baja el código y se construye todo, incluyendo la imagen de contenedor y entonces más o menos lo que vamos a tener en el futuro y lo que vamos a tener en OpenShift 4.6, 4.7, 4.8, más o menos, vamos a tener lo mismo funcionalidad, pero la tecnología abajo va a ser diferente, va a ser construido con Tecton y también vamos a tener más flexibilidad de construir con tus propios herramientas por ejemplo, si usted quiere usar Builda, está bien, si usted quiere usar Source to Image, está bien, pero también si quieres usar otra cosa, vamos a permitir eso y no exactamente apoyarlo, pero facilitarlo para usarlo más o menos, tener más flexibilidad para reenir con los clientes en donde están más o menos. Libertad para los desarrolladores para que sigan desarrollando en herramientas que ya conocen, que ya son partes del enterprise o de la compañía o del ambiente en el que ya están familiarizados, qué bueno. Scott, yo te puedo preguntar en qué número 4.6, 4.7, 4.8 está el Preview para hacer Builds sobre CNB Container Native Virtualization, porque a veces recibo mucho la pregunta, la gente le da miedo construir contenedores sobre su propio cluster y a veces construyen un cluster, solo va a construir imágenes, si la gente puede construir contenedores en un ambiente virtualizado con CNB, eso sería muy cool. De verdad, no sé si tenemos un punto en el roadmap, más o menos, pero que estamos, para mí estamos, en mi grupo estamos investigando dos cosas, para construir imágenes en rootless más o menos, estamos construyendo unas partes en cryo para, para facilitar eso y también pensamos que podemos mejorar la seguridad de eso, bastante que está muy bien para la mayoría de la gente, pero vamos a ver, también estamos investigando hacerlo en virtual machines, más o menos, en máquinas virtuales, pero todavía no sé, es posible que Steve está trabajando con eso en CNB, pero no sé exactamente de su lugar, pero de nosotros, para nosotros estamos investigando más o menos el 80 porcentaje, creamos que podemos hacerlo solo con cryo, más o menos, pero nativo en, como un proceso pero rootless más o menos, y adelante vamos a ver, quizás también con CNB en un envío más seguro, más o menos. Sí, dale. Y bueno, de nuevo, y creo que ya esto lo mencionamos, pero quería comentarles que esto es más, o sea, separado de la parte de Kubernetes como tal, corriendo en la OpenShift Container Platform, pero sobre Kubernetes, así que dejamos entonces el siguiente slide, y un poco de lo que estábamos hablando, verdad, puede correr en physical virtual, la nueva virtual privada, o la nueva publicada, así que, ya, vamos a lo que vinimos, así. Oh, no me deja. Ahora, ¿ven mi terminal? Bien? Sí. Ok, entonces yo acá estoy listo con un pequeño proyecto que yo tengo, que yo lo llamo Archdomy, y es básicamente para construir imágenes y que me diga información sobre la CPU en la cual se construyó ese contenedor. Tiene un enfoque demasiado, pues, a lo que me enfoco yo al trabajo, que es performance, es hacer que OpenShift sea más rápido y más veloz y mejor todos los días, y parte de la que yo me enfoco mucho es la arquitectura sobre la cual está corriendo OpenShift. Entonces, este es un proyectico de juguete muy interesante, está en GitHub, al final les doy en link, y aquí en deployments, yo tengo guardado toda la configuración para manejar este proyecto por medio de OpenShift Builds. Y, pues, lo que voy a mostrar en este demo es que también yo lo puedo hacer, puedo hacer como algo de GitOps, que, y esto es Builds, versión 1, no versión 2, o sea que próximamente será mejor porque estará sobre Tecton, pero si yo miro aquí, este es como se configura un Build de forma Jammer, lo podríamos mirar también en la plataforma, pues, digamos, de forma gráfica, como se ve aquí, con Clicks, pero este para mí es una herramienta y porque me gusta tanto y buen amorado de ella es, para mí es una herramienta para los desarrolladores, es una herramienta que tiene todo su peso y su poder desde la terminal, porque es para nosotros los desarrolladores, y esto es básicamente como se ve un Build config, o sea, como se configura los Builds, pero antes de hablar de los Builds, hay algo que a veces yo veo que todos hablan de Builds y no se usa es los Image Streams. OpenShift me permite tener, entre comillas, un repositorio personal interno de OpenShift, que es un, como su palabra lo dice, un stream, o sea, un flujo de lo que yo estoy construyendo y lo empuja hacia un determinado deployment. Entonces, yo puedo tener un deployment en el cual yo mire hacia un Image Stream y cada que yo actualice un contenedor en este Image Stream, OpenShift va a hacer todo esto automáticamente por mí de una forma que ya veremos puede ser hasta Github. Él va a decir, hay un nuevo contenedor en el Image Stream del deployment X que está corriendo, necesitamos actualizar esa imagen y OpenShift lo hará automáticamente para mí. Entonces, cuando yo quiero declarar un Build Config, lo más importante siempre es declarar un Image Stream al cual yo voy a apuntar mi Build Config y en el cual voy a guardar mis imágenes, ¿cierto? Entonces, aquí lo que estamos viendo es que yo estoy construyendo el Build Config de Eduardo, una preguntita, ¿puedes hacer fuente más, un poco más grande? Claro, debo salirme, ahí. Ay, perfecto. Ay, buenísimo. Sí, es a veces la costumbre de los ojos. Somos viejos aquí. No, bueno, como es pequeño, no fui la que pedí eso. Lo siento, yo soy viejo. Entonces, a ver, iluminemos lo que quiero mostrar. Primero, esto. Voy a apuntar mi Build Config a, como decía Scott, a un link de Github, convirtiendo mi Build, mi OpenShift Build en como podríamos decirlo como un old school, como al antigua, un Github al antigua y es que yo le estoy diciendo a OpenShift, por favor mire a este repositorio de Github y construyame el contenedor que está en la carpeta UPS, la carpeta Build de mi repositorio de Github, ahí tengo almacenado mi Dockerfile y construyamelo con una estrategia Docker y el contexto es este, como sabemos, construyendo un contenedor. A veces yo puedo cambiar el contexto porque internamente en el Dockerfile el paso copy, sobre todo es el más importante, cuando yo voy a hacer un copy, si no pongo la ruta total o la ruta parcial y el contexto está cambiado, pues puedo tener errores. Entonces, el Build Config me permite hacer eso también. Entonces, el source es Gith y algo muy importante aquí es configurar esto, que la verdad no sé cómo esconderlo, entonces lo dejé hecho antes de empezar esto, porque aquí hay que manejar secretos, yo puedo, aunque esto lo voy a ahorrar ahora después de esto, yo puedo tener secretos, entonces yo declaro los secretos para Github y esto debe ser secretos en code 64, base 64 y con esto yo voy a Github y configuró el webhub para este repositorio, cierto, y de esa forma me asegura que nadie pueda apuntar a piece a mi OpenShift y empezará a disparar builds por mí, yo puedo controlar esto y dado que es un secreto, yo lo puedo manejar dinámicamente. Otra cosa que quiero mostrar acá es esto, el Image Stream. Entonces, yo aquí estoy apuntando cada que esta imagen se construya la almacena en el Image Stream, también yo puedo decir que la output sea a un repositorio Quay o un repositorio con que sea OCI comparivo, o sea que respete las APIs OCI, OpenShift es capaz de apuntar y almacenar mi contenedor en este repositorio, pero aquí lo estoy almacenando de forma interna y no tengo que, digamos, desplegar todo un operador Quay o hacer todo un deployment de propio Quay en mi OpenShift, que es como algunas personas lo hacen, que sabiendo que OpenShift igual maneja un registro interno, acentó un despliegue personalizado de Quay, lo cual es pesado, yo puedo utilizar las estanzas propias de OpenShift para almacenar mis contenedores y ese es el Image Stream tag. Acá básicamente pues esto sí es buenas prácticas, le pongo algunas anotaciones, algunos labels a mi contenedor antes de desplegar. Por último, este es el contenedor, esto es básicamente de desplegar un pod, algo muy cool es, este llameo fue generado por Podman, no lo hice yo, yo desplegué este contenedor en mi máquina y luego le pedí a Podman que me diga el llame, es otro de los features para desarrolladores que me gusta mucho. En un tiempo intenté también hacer que todo este builds lo hiciera a Podman con Scott, lo intentamos, pero OpenShift builds a B2 va a ser mucho mejor que mi idea, entonces estoy contento con eso. Y ahora básicamente otra buenas prácticas es enumerar las cosas, pues cuando yo hago esto OpenShift crea los recursos en orden. Ahora si vengo acá, en builds puedo ver que hace unos segundos se disparó un build por los builds que está ocurriendo y el está aquí construyendo. Puedes ver el log, si, también puedes ver. Sí, por los logs es como es la compilación de un programita en go, los logs de construcción no son muy largos, es básicamente esto, pero como nos puede mostrar aquí el va a GitHub y clona el repositorio, como yo les dije le estaba apuntando Busca el Dockerfile y lo construye, entonces aquí ya empezó. Manajar los cambios y cambiar los cambios del código con GitHub también, ¿verdad? Sí, con el webhook, entonces si vengo acá, mis repositorios, ya tengo el webhook configurado, se me perdió el Archdom y settings acá en webhooks. Acá pueden ver que está configurado el webhook y este va a informarle a OpenShift por medio de esta API que se genera OpenShift, cada que hay exista un cambio en el código. ¿Cómo puedo ver eso? Lo puedo ver aquí. Entonces veo que tengo unos build configs, yo le pido a OpenShift en la terminal que me diga, que me describa todo mi build config y él me arroja esta información, webhook, GitHub. Con esto, yo luego copio esto, lo llevo a GitHub, obviamente aquí me protege el secreto, simplemente dice aquí va un secreto, pero no lo pone, y yo llevo esta información a GitHub y con esto creo el webhook, obviamente reemplazando la palabra secret por el secreto propiamente dado. Una forma más fácil a los que les gusta dar click es venir acá a mi build en la plataforma y bajo acá y donde dice webhooks, GitHub, si yo doy click aquí, él me lo almacena en el cache de copy and paste y aquí lo puedo ver. Y acá podemos ver que él reemplazó la palabra secreto por el nombre del secreto, pero como yo tengo el secreto protegido con base 64, igual que no pasa nada. Ahora, algo que me gusta que hable es esto, que aquí yo no uso una imagen de afuera, yo le puedo decir a OpenShift que quiero crear un nuevo deployment desde un image stream y vengo acá y podemos ver que ya está mi image stream creado aquí, aún lo está construyendo el que ya había construido y la recomendación es siempre guardarlo como latex de forma tal que lo único que haga es reemplazar ese latex que exista un cambio, entonces si yo voy cambio algo en mi repositorio de GitHub, OpenShift se dar cuenta va a disparar un build y una vez ese build termine, él va a construir un contenedor, lo almacena del image stream y él va a actualizar el deployment. A mí me encanta la automación de build context porque puedes construir como cadenas de builds si tú quieres con los streams de imágenes o image streams. No sé, es la palabra en español trigger. Disparar. Sí es disparar, básicamente. Es lo mismo que shoot, pero sí. Y acá podemos ver, hice el deployment de esa imagen totalmente desde la consola, no usando un yaml de pod y entonces podemos ver que él se está alimentando de un builds. Si ven, o sea, aquí en la misma plataforma me dice, este deployment se alimenta de un build y venimos acá y podemos ver que corre y es addomiserver.retrieves.bas.info y básicamente yo le tengo. Me dice que este contenedor fue construido sobre un nodo en que tiene intelción y la importancia de por qué hice este juguetito llamado Ars Domi es porque ahora que OpenShift está siendo tan atractivo para workflows de inteligencia artificial, AI, ML, marching learning, empezamos a tener clusters OpenShift híbridos en los cuales yo puedo tener tres nodos con intelción, luego otros tres nodos con AMV, ahora que AMV está de moda y otros tres nodos con NVIDIA con alguna configuración rara. Entonces usando builds yo puedo además, si volvemos acá usando builds yo puedo usar el node selector usando ese node selector y aquí lo tengo como null pero si yo cambio el node selector yo puedo decirle a OpenShift construyame este contenedor pero para el nodo de arquitectura tipo tal o el nodo de arquitectura NVIDIA o el nodo de arquitectura AMD lo cual es muy poderoso y ya lo estamos probando con nuestras plataformas de OpenShift de OpenDataApp y es construir el mismo contenedor pero para cada nodo que yo pueda llegar a tener en mi cluster, entonces si yo tengo un cluster con diferentes arquitecturas utilizando builds y el node selector dentro de mi build yo puedo construir el mismo contenedor para diferentes arquitecturas y esto tiene la ventaja como todos sabemos de que código compilado siempre será mejor y pues cuando estamos hablando de inteligencia artificial siempre queremos como ese extra juguito de performance de cada cosa. Y puedes comparar mejor en las diferentes arquitecturas porque sabes que ya el código fue es el mismo solamente que está utilizado para cada arquitectura necesito una nueva frase. Y ahí les dejo mi juguetito porque la verdad es muy bueno para el que quiera desplegarlo si se despliega como un demon set entonces cada nodo que tengas va a tener esta API que es slash CPU o slash version la verdad lo dejé abierto y te dice cada nodo toda la configuración que tiene a nivel arquitectural y si esto te interesa si estás haciendo workflows de inteligencia artificial o cosas así es muy importante poder saber la arquitectura cada nodo y pues este juguetito hace eso. Ahora soy yo que te va a pedir que lo hagas más grande. Ah porque si es que es un intel. Si es el mil. Si es el mil. Si es lo que ya. Esto es build once deploy everywhere. Lo construyes una vez y lo lo creas pero de verdad lo lo build en diferentes arquitecturas. Y yo básicamente todos los días por eso quería hablar de esto. Para lo que estamos haciendo de open chief inteligencia artificial esto requiere tocar cosas que no vienen por defecto en Linux o en real y es los drivers de envidia por decir así a veces cierto y para poder compilarlos por cada nodo usamos builds. Entonces yo uso build solos días para compilar drivers de envidia compilar drivers de hardware especializado como tarjetas de redes especializadas y hardware especializado que se está construyendo todos los días para machine learning inteligencia artificial para poder hacer estas compilaciones. Yo quiero compilar el código sobre el kernel en el que voy a estar corriendo. Entonces open chief builds me permite eso porque voy a estar compilando el código sobre el kernel del nodo y me permite manejar las builds de una forma muy dinámica. Entonces yo uso builds todos los días como parte de mi trabajo desarrollador y es un fissure que la verdad me encanta mucho y quiero ya jugar con el builds 2.0. Que bueno Carlos tu comentabas que tu trabajas en la parte también de performance como mides el performance de de pues quizás debes explicar lo que haces. Si un poquito más comparando como que como mides el performance de cada aplicación en diferente arquitectura y como porque me parece que utilizando builds también hay otro montón de cosas que puedes hacer para para seguir haciendo esa comparación. Te tiene un primer deployment que sería tu baseline y luego pues sigues haciendo otros en diferentes arquitecturas corriendo digamos los mismos tipos de tests si si vienen al caso y y luego comparando pero me interesa saber cuáles son esos esos indicadores que estás midiendo para saber el performance. Estamos por liberar un blog post para hablar de exactamente ese tema y es que construí un contenedor que realiza tareas matemáticas muy sencillas y lo ejecuté en diferentes tipos de nodo AWS que es una de las plataformas más usadas y se puede ver como la misma tarea matemática que por lo general cuando se están haciendo estas comparaciones se usan sumas de vectores. Yo empiezo a hacer sumas de vectores y la misma suma de vectores el mismo uno más uno pero si lo corro sobre un Intel C1 Platinum y otro Intel C1 que no es Platinum y luego voy lo corro sobre un nodo que es AMD empezamos a ver que es la misma suma de vectores pero en una es un segundo más rápida un segundo más lenta entonces actualmente estoy trabajando en esas comparaciones y podemos ver que la misma tarea matemática que a veces pensamos que debería tener el mismo performance cambia dependiendo del nodo y como digo ya hablando inteligencia artificial machine learning matemáticamente hablando es básicamente suma de vectores estadística regresiones lineales estamos hablando de operaciones vectoriales todo el tiempo entonces si yo corro la misma operación vectorial en diferentes arquitecturas puedo encontrar que en una arquitectura es más rápida que en otra si uso el mismo contenedor luego en este mismo blog post que estamos preparando vamos a ver cómo si yo compilo de nuevo mi código para el nuevo tipo de nodo vuelvo y gano el mismo performance que puedo tener en otra arquitectura entonces por eso para mí es muy importante OpenSheet builds porque me permite estar de forma desatendida construyendo el mismo código para todas las arquitecturas en las que yo trabajo de forma diaria entonces no me tengo que preocupar por estar construyendo un contenedor una y otra vez yo le dejo esa tarea OpenSheet builds y si estamos encontrando un impacto en el performance que las personas pueden los desarrolladores puedan encontrar ya en producción al construir el un contenedor cada vez que lo van a usar porque una crítica que yo hago mucho y algo que da muy OpenSheet a veces voy a encontrar Scott un poquito y es potman es es una gran herramienta a movilidad mi casa está llena de stickers de perritos por todo el lado pero estas prácticas que aprendimos hace dos o tres años de construir que nos decían de hecho el marketing y todo construye el contenedor en tu laptop correlo en producción me parece que eso ya debería romperse y todos deberíamos adoptar estrategias como OpenSheet builds y es no construyas tu contenedor en tu laptop déjale eso a OpenSheet y haz que OpenSheet construya tu contenedor donde él va a correr porque lo mismo nuestros laptops nuestros computadores de nuestra casita nos no utilizan los los mismos chips que utiliza Amazon que utiliza Google que utiliza Azure y empezamos a ver estas diferencias en performance que son muy grandes y me gustó mucho que en kubeconf y Google que acaba de pasar en uno de los keynotes se habló de la responsabilidad social ecológica que tenemos los usuarios de kubernetes y es cuántos clusters de kubernetes están ahí en producción que podrían hacerlo mejor podrían estar corriendo mejor podrían estar teniendo la misma carga de producción utilizando menos energía eléctrica y esto lo podemos lograr con este tipo de herramientas como builds porque si yo construyó un contenedor en mi laptop lo mando a OpenSheet no OpenSheet como tal pero el linux kernel va a tener que utilizar un poquito más de electricidad para correr ese mismo contenedor por temas de performance de la misma operación vectorial todo lo que vengo hablando versus si yo le entrego toda la tarea OpenSheet entonces si si queremos ser responsables ambientalmente esto no me encantó esa ese keynote de de kubeconf me encantó porque yo nunca nunca esperé encontrar en en kubeconf una conferencia totalmente sobre contenedores tecnología cloud encontrar a alguien hablando de de la electricidad que estamos desperdiciando porque hay muchos closures de kubernetes no sólo de OpenSheet que la verdad es como como decimos en español a las patadas pero como yo construyó kubernetes y le tiro todos los contenedores que se me ocurran y hago que kubernetes los corran entonces OpenSheet nos da estas herramientas a los desarrolladores para yo simplemente apuntarle a un repositorio de git y preocuparme por comid como se dice comid me imagino que hay una historia y también con v i con con rel con el kernel de rel porque corre muy bien juntos y entonces puede usar menos poder por ejemplo yo debo explorar eso es interesante este ese ese no sé camino de pensamiento más o menos la verdad todo fue desde la keynote de kubeconf me encantó que hablarán de ese tema y yo que vengo explorando los los builds para mejorar el performance de tareas y sobre todo el workflows de inteligencia artificial y workflows de de temas que son de performance y estamos ayudando mucho a las personas utilizando OpenSheet builds me siento escéptico que los usuarios van a poder construir en sus laptops pero no sé es interesante de definitivamente no lo niego pero creo que no sé tenemos que explorar lo más pero me siento como los servidores dependiendo la mayoría están tentado ahí corriendo haciendo nada y eso es el problema que tenemos como miles de clustres y están solo corriendo corriendo usando electricidad y me imagino que hay mucho mucho waste y OpenSheet builds algo que que como desarrollador y entusiasta veo que va a ganar que por eso quería mostrarlo y es estamos a meses de tener laptops a rm y esto va a ser muy interesante porque si mi empresa si yo soy un usuario OpenSheet y mi cluster OpenSheet está en amazon x86 pero la empresa me da un laptop a rm ya no puedo construir mi contenedor en mi laptop y empujarlo mi cluster entonces me parece que esta disparidad que vamos a tener laptops a rm va a disparar muchísimo el uso de de OpenSheet builds porque ahora sí necesitamos construir el contenedor donde está el cluster y no en los laptops a rm si yo creo eso también creo eso también con power como con poder con esa arquitectura no no vamos a tener laptops de poder es imposible más o menos entonces vamos a construir de verdad tenemos clientes que están haciendo eso hoy hoy en día por ejemplo que quieren poder power con con con intel juntos en un cluster y ellos están construyendo en el cluster y quieren esa esa capability están haciéndolo con con no selectors como como tú dices pero pero tienen que construir su propio como metodológico de hacerlo más o menos no no probé no probé no no sé cómo decir eso we don't provide no probé probemos algo que funciona fácilmente hoy más o menos y bueno también también podría ser el tipo de usuarios así tú no no estás todo el tiempo construyendo no pero lo que habla carlos esto de digamos tratar de hacerlo trabajar más inteligente y menos menos fuertes lo que es más difícil y dejar el trabajo pesado OpenSheet también porque cuando empezamos a hablar de inteligencia artificial e compilar un contenedor de tensorflow o algo así eso puede tomar minutos hasta ahora o sea dependiendo del poder de tu laptop si no quiero hacer eso en mi laptop no porque no puedo tener un vídeo y no funciona yo veo que está jodido cuando estoy trabajando y hay sólo con con rsync más o menos o con construyendo un contenedor que jode todo entonces si yo no quiero estar compilando tensorflow en mi laptop cada media hora cada hora yo le dejo esa tarea a OpenSheet yo compito lo mando a github y esto hace que OpenSheet construye el contenedor por mí y si yo pues no lo no no lo hice aquí porque la verdad no encontré que modificarle a mi repositorio de git pero si yo disparo tres cambios en cinco minutos a mi repositorio de git OpenSheet lo que va a hacer es crear tres builds para cada comid diferente entonces yo puedo estar probando diferentes versiones de mi de mi contenedor con tensorflow y simplemente relajarme mientras OpenSheet los construye por mí y luego tienes todos estos cambios en un log que después puedes ir a ver qué fue lo que hiciste en ese momento no que si le haces esto todo manual en tu laptop pues ya yo necesito acceso a un cluster como carlos y yo no yo no tengo esa de conexión como tú tú tienes lo bueno bueno si esto lo tengo en mi laptop es una amiaza eso es lo que iba a decir si estás trabajando en inteligencia artificial dudo mucho que tú empresas así no eres tú el que lo compras te de un laptop con la última tarjeta gráfica que hay en el mercado lo cual puedes tener fácilmente en una plataforma nube entonces también o sea para que gastar tu laptop en eso si puedes darle el músculo o sea dejar la parte pesada a OpenSheet y para eso es OpenSheet para ayudar a los desarrolladores o que bueno puedes tener un laptop pero ni las empresas más generosas te hacen terrotón en la laptop todos los años o cada seis meses no entonces igual mantenerse al día carlos me encantó esto y nada más estamos corriendo un video me encantó esta presentación en lo personal como te digo me la paso en la parte de OpenSheet pero más en la parte de la plataforma más en Kubernetes y me encantó ver toda la aplicación todas las aplicaciones que esto puede tener toda la diversión que sucede en niveles de abstracción más más altos a donde yo generalmente vivo y y el poder de OpenSheet de saber que provee esta abstracción en distintas arquitecturas y tu y tu como desarrollador puede sentirte digamos en casa sin importar a dónde cuál es tu target no cuál es tu destino me encantó y me hace Scott no lo tiene pero yo sí tengo unos accesora ciertos clusters OpenSheet con con unos juguetitos tengo que con quién tengo que hablar a la gente entrar a este stream acabo de tener acceso a un cluster con NVIDIA's A100 para trabajar OpenSheet en NVIDIA's A100 así que tengo acceso a OpenSheet con unos juguetitos muy interesantes si mi laptop está caliente solo con este video y todo todo todo en verdad lo habilito gracias a OpenSheet builds a mí la verdad es una de los features que más me encantan de OpenSheet porque hace mi trabajo más fácil y me permite compilar los drivers de testas tarjetas gráficas todos los días y luego simplemente yo entrar a hacer mi trabajo. Si tiene razón. Ok bueno muchísimas gracias por este demo Scott tienes algunas palabras de ver tu trabajo en la celo. Verón acción y cómo está. A mí me encanta ver cómo la gente lo utiliza para distintos casos y sobre todo esta parte de ingeniería artificial y un montón de aplicaciones que se puede tener. Gracias Carlos gracias. En la 29 de octubre hablando de los próximos episodios también vamos a tener a otro Carlos que sabe en español son muy pocos Carlos. Es un hombre otro Carlos. Este Carlos no es de Colombia pero es de Venezuela que está al lado también y está viviendo en Madrid pero vamos a hablar de Cubinix que también es otra herramienta que él utiliza para poder desplegar OpenSheet mucho más seguido y me encanta porque esto es construido cosas para para mejorar mejor en OpenSheet y él lo hace con buenas prácticas que ya venían del ecosistema de OpenStack. Es súper interesante y en noviembre vamos a hablar con Ramón él está en Londres pero es español y vamos a hablar sobre OpenSheet en OpenStack como como ha evolucionado en esta plataforma así que para recuperar mal esto próximos capítulos. Gracias. Bueno gracias. Gracias.