Re: Announcing a New Committer Michał Słowikowski
Thank you all. :) śr., 21 paź 2020 o 17:59 Tomasz Urbaszek napisał(a): > Congrats Michał! > > Tomek > > On Wed, Oct 21, 2020 at 4:39 PM Sharan Foga wrote: > > > Hi All > > > > The Kibble PMC has invited Michał Słowikowski as new committer to the > > project and are happy to announce that he has accepted. > > > > Welcome and congratulations Michał! > > > > Thanks > > Sharan > > > > >
Re: Announcing a New Committer Michał Słowikowski
Congrats Michał! Tomek On Wed, Oct 21, 2020 at 4:39 PM Sharan Foga wrote: > Hi All > > The Kibble PMC has invited Michał Słowikowski as new committer to the > project and are happy to announce that he has accepted. > > Welcome and congratulations Michał! > > Thanks > Sharan > >
Announcing a New Committer Michał Słowikowski
Hi All The Kibble PMC has invited Michał Słowikowski as new committer to the project and are happy to announce that he has accepted. Welcome and congratulations Michał! Thanks Sharan
Re: [DISCUSS] Restructure the Apache Kibble project
+1 to use 3.9 as base python. Python community hints that they will drop support for old version faster than now, so the 3.6py is going to be the "old" one soon. Tomek On Wed, Oct 21, 2020 at 11:02 AM Daniel Gruno wrote: > On 21/10/2020 10.42, Tomasz Urbaszek wrote: > > Yesterday I took a deeper look at the api. And if I correctly > > understand, currently we are generating open API spec from python > > code. > > > > If we would like to preserve it, I would like to suggest considering > > the FastAPI framework https://fastapi.tiangolo.com . It has many > > advantages including using native type hints from python 3 for data > > validation as well as generating OpenAPI spec. > > mhmm, I was even hoping to go as far as py3.9 for annotations to help > "documenting as you code" :) I am very much for a type hint solution, > especially as we could use mypy for tests then. > > > > > Tomek > > > > On Mon, Oct 19, 2020 at 9:02 PM Tomasz Urbaszek > wrote: > >> > >> Thanks for the replies! > >> > >>> I'm not too concerned about breaking API, we _could_ make the next one > a version 2 with a version 2 API, a clean break from version 1 > >> > >> My main point in preserving the compatibiliy is to be sure that the ui > >> will work as expected. This will also limit the scope of the changes. > >> > >>> Whichever framework we pick, I would prefer if we could auto-generate > the JSON/GraphQL API from the source. > >> > >> +1 for automating as much as possible, probably I would lean to first > >> do the JSON as it is now and the consider adding GraphQL. > >> > >> If there is no objections to merging scanners with server I will do > >> this as a first step. Here is a Github issue so we can manage all the > >> work: > >> https://github.com/apache/kibble/issues/64 > >> > >> As per the ideas - I created issues to keep it for future reference :) > >> > >> Bests, > >> Tomek > >> > >> > >> On Mon, Oct 19, 2020 at 7:54 PM Sharan Foga wrote: > >>> > >>> Hi Tomek > >>> > >>> Thanks for the initiative and ideas! > >>> > >>> Anything that makes things simpler or easier is OK with me :-) and > consolidating things seems like a good idea. I am guessing that a lot of > the changes would probably be behind the scenes rather than at the user end > - right? > >>> > >>> On the wishlist - I saw a talk by Myrle at ApacheCon@Home and she had > done some initial work linking contributions to affiliation and I mentioned > seeing if that could be something we could look at including into Kibble. I > think we tried to do it with Meta Pony Factor but dont think it is > complete. Anyway lots of ideas to keep us going! > >>> > >>> Thanks > >>> Sharan > >>> > >>> > >>> On 2020/10/18 14:28:33, Tomasz Urbaszek wrote: > Hello all, > > I would like to propose a few things that I think are worth > considering: > > 1. Merge all three repositories (kibble, kibble-scanners, > kibble-docker) into one. In this way I think we may simplify > development, dependency management, and distribution. Our project is > rather small and increasing places needing management probably won't > help. > > 2. Once we have the API server and scanner in one repo we can make > Kibble a python package. This will not only simplify installation and > setup but also may help us create a nice CLI to manage all components > (setup, server, scanners). By doing this users will be able to run > something like `kibble server` or `kibble scanners ponymail`. > > 3. Rewrite kibble API server to use a framework (for example FastAPI > which supports OpenAPI specs). This point is probably the hardest one > to implement as it will require adding tests to preserve compatibility > with kibble ui. > > What do you think? Do you have anything that you would love to see in > Apache Kibble? :) > > Cheers, > Tomek > > >> > >> > >> > >> -- > >> > >> Tomasz Urbaszek > >> Polidea | Software Engineer > >> > >> M: +48 505 628 493 > >> E: tomasz.urbas...@polidea.com > >> > >> Unique Tech > >> Check out our projects! > >
Re: [DISCUSS] Restructure the Apache Kibble project
On 21/10/2020 10.42, Tomasz Urbaszek wrote: Yesterday I took a deeper look at the api. And if I correctly understand, currently we are generating open API spec from python code. If we would like to preserve it, I would like to suggest considering the FastAPI framework https://fastapi.tiangolo.com . It has many advantages including using native type hints from python 3 for data validation as well as generating OpenAPI spec. mhmm, I was even hoping to go as far as py3.9 for annotations to help "documenting as you code" :) I am very much for a type hint solution, especially as we could use mypy for tests then. Tomek On Mon, Oct 19, 2020 at 9:02 PM Tomasz Urbaszek wrote: Thanks for the replies! I'm not too concerned about breaking API, we _could_ make the next one a version 2 with a version 2 API, a clean break from version 1 My main point in preserving the compatibiliy is to be sure that the ui will work as expected. This will also limit the scope of the changes. Whichever framework we pick, I would prefer if we could auto-generate the JSON/GraphQL API from the source. +1 for automating as much as possible, probably I would lean to first do the JSON as it is now and the consider adding GraphQL. If there is no objections to merging scanners with server I will do this as a first step. Here is a Github issue so we can manage all the work: https://github.com/apache/kibble/issues/64 As per the ideas - I created issues to keep it for future reference :) Bests, Tomek On Mon, Oct 19, 2020 at 7:54 PM Sharan Foga wrote: Hi Tomek Thanks for the initiative and ideas! Anything that makes things simpler or easier is OK with me :-) and consolidating things seems like a good idea. I am guessing that a lot of the changes would probably be behind the scenes rather than at the user end - right? On the wishlist - I saw a talk by Myrle at ApacheCon@Home and she had done some initial work linking contributions to affiliation and I mentioned seeing if that could be something we could look at including into Kibble. I think we tried to do it with Meta Pony Factor but dont think it is complete. Anyway lots of ideas to keep us going! Thanks Sharan On 2020/10/18 14:28:33, Tomasz Urbaszek wrote: Hello all, I would like to propose a few things that I think are worth considering: 1. Merge all three repositories (kibble, kibble-scanners, kibble-docker) into one. In this way I think we may simplify development, dependency management, and distribution. Our project is rather small and increasing places needing management probably won't help. 2. Once we have the API server and scanner in one repo we can make Kibble a python package. This will not only simplify installation and setup but also may help us create a nice CLI to manage all components (setup, server, scanners). By doing this users will be able to run something like `kibble server` or `kibble scanners ponymail`. 3. Rewrite kibble API server to use a framework (for example FastAPI which supports OpenAPI specs). This point is probably the hardest one to implement as it will require adding tests to preserve compatibility with kibble ui. What do you think? Do you have anything that you would love to see in Apache Kibble? :) Cheers, Tomek -- Tomasz Urbaszek Polidea | Software Engineer M: +48 505 628 493 E: tomasz.urbas...@polidea.com Unique Tech Check out our projects!
Re: [DISCUSS] Restructure the Apache Kibble project
Yesterday I took a deeper look at the api. And if I correctly understand, currently we are generating open API spec from python code. If we would like to preserve it, I would like to suggest considering the FastAPI framework https://fastapi.tiangolo.com . It has many advantages including using native type hints from python 3 for data validation as well as generating OpenAPI spec. Tomek On Mon, Oct 19, 2020 at 9:02 PM Tomasz Urbaszek wrote: > > Thanks for the replies! > > > I'm not too concerned about breaking API, we _could_ make the next one a > > version 2 with a version 2 API, a clean break from version 1 > > My main point in preserving the compatibiliy is to be sure that the ui > will work as expected. This will also limit the scope of the changes. > > > Whichever framework we pick, I would prefer if we could auto-generate the > > JSON/GraphQL API from the source. > > +1 for automating as much as possible, probably I would lean to first > do the JSON as it is now and the consider adding GraphQL. > > If there is no objections to merging scanners with server I will do > this as a first step. Here is a Github issue so we can manage all the > work: > https://github.com/apache/kibble/issues/64 > > As per the ideas - I created issues to keep it for future reference :) > > Bests, > Tomek > > > On Mon, Oct 19, 2020 at 7:54 PM Sharan Foga wrote: > > > > Hi Tomek > > > > Thanks for the initiative and ideas! > > > > Anything that makes things simpler or easier is OK with me :-) and > > consolidating things seems like a good idea. I am guessing that a lot of > > the changes would probably be behind the scenes rather than at the user end > > - right? > > > > On the wishlist - I saw a talk by Myrle at ApacheCon@Home and she had done > > some initial work linking contributions to affiliation and I mentioned > > seeing if that could be something we could look at including into Kibble. I > > think we tried to do it with Meta Pony Factor but dont think it is > > complete. Anyway lots of ideas to keep us going! > > > > Thanks > > Sharan > > > > > > On 2020/10/18 14:28:33, Tomasz Urbaszek wrote: > > > Hello all, > > > > > > I would like to propose a few things that I think are worth considering: > > > > > > 1. Merge all three repositories (kibble, kibble-scanners, > > > kibble-docker) into one. In this way I think we may simplify > > > development, dependency management, and distribution. Our project is > > > rather small and increasing places needing management probably won't > > > help. > > > > > > 2. Once we have the API server and scanner in one repo we can make > > > Kibble a python package. This will not only simplify installation and > > > setup but also may help us create a nice CLI to manage all components > > > (setup, server, scanners). By doing this users will be able to run > > > something like `kibble server` or `kibble scanners ponymail`. > > > > > > 3. Rewrite kibble API server to use a framework (for example FastAPI > > > which supports OpenAPI specs). This point is probably the hardest one > > > to implement as it will require adding tests to preserve compatibility > > > with kibble ui. > > > > > > What do you think? Do you have anything that you would love to see in > > > Apache Kibble? :) > > > > > > Cheers, > > > Tomek > > > > > > > -- > > Tomasz Urbaszek > Polidea | Software Engineer > > M: +48 505 628 493 > E: tomasz.urbas...@polidea.com > > Unique Tech > Check out our projects!
