Hello, I think, this will take 4-5 days for me to rewrite Nailgun code. There are some things that bother me now in testing part, but I think they all can be solved.
On Thu, Sep 11, 2014 at 4:07 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi, > > So, we agreed that we need to rewrite nailgun on some alive web framework. > But for sure it's not critical, Nick could you please clarify, how long will > it take to > rewrite our code in order to use Flask? > > Thanks, > > On Wed, Sep 10, 2014 at 4:26 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> 1/ As far as I know, thanks to Dima Shulyak Naillgun doesn't hang when >> we're trying retrieve information for 100 nodes. He has improved SQL >> request for this. I think the more important performance issue is data >> updating by fuel agents, but pagination isn't solution here. >> >> 2/ We have objects layer now, therefore the implementation is mostly >> confined to adding parameters to our methods. I think it should not be >> a problem to retrieve GET params regardless of used framework. >> >> On Wed, Sep 10, 2014 at 1:48 PM, Alexander Kislitsky >> <akislit...@mirantis.com> wrote: >> > If we want to work with 100 and other nodes we should implement paging >> > in >> > the API. Nick, is it possible to implement on web.py and what is >> > improvement, if we will use Flask in this case? >> > >> > On Wed, Sep 10, 2014 at 2:38 PM, Igor Kalnitsky >> > <ikalnit...@mirantis.com> >> > wrote: >> >> >> >> I believe it doesn't affect us strong. Indeed, web.py is dead and >> >> requires some hacks in our side, but we have abstractions for dealing >> >> with it, so it's not hard to add features. >> >> >> >> Moving to Flask/Pecan is about improving code quality, readability and >> >> getting community support. >> >> >> >> We're delaying 5.1 and have small amount of time for 6.0, so I'm +1 >> >> for postpone it to 7.0. >> >> >> >> - Igor >> >> >> >> On Wed, Sep 10, 2014 at 10:43 AM, Mike Scherbakov >> >> <mscherba...@mirantis.com> wrote: >> >> > So how strong are we affected by this? >> >> > It seems like there is no future with web.py, but I'm trying to >> >> > understand >> >> > if we can delay reimplementation to other framework to 7.x, for >> >> > example. >> >> > We >> >> > need to know if it blocks us from delivering some certain features, >> >> > or >> >> > it is >> >> > only part of tech debt, and slows us down. In case of the latter, I'd >> >> > like >> >> > to know how much are we affected in numbers, i.e. we would do feature >> >> > (name >> >> > of real feature) in 3 man/weeks with Flask, but it takes 4 man/weeks >> >> > with >> >> > web.py. >> >> > >> >> > On Mon, Sep 1, 2014 at 8:17 PM, Nikolay Markov <nmar...@mirantis.com> >> >> > wrote: >> >> >> >> >> >> Adding a couple of topics why we need to get rid of web.py: >> >> >> >> >> >> 1. It doesn't fully support REST. I mean, it supports >> >> >> GET/POST/PATCH/PUT/DELETE requests, but all the logic needs to be >> >> >> written by hand. >> >> >> 2. It is old and almost unsupported at the present moment. This >> >> >> means, >> >> >> we may never contribute to it to fix any issues (and there are >> >> >> plenty). Some of them are fixed in unstable development version >> >> >> (master branch), but no new release is planned, and last commit was >> >> >> uploaded almost a year ago. >> >> >> 3. It doesn't support Python 3 at all and probably never will. >> >> >> 4. It's becoming hard to find any documentation or help topics on it >> >> >> if issues occured, because it became obsolete and unpopular among >> >> >> developers. >> >> >> 5. It has some strange HTTP error processing in certain places, >> >> >> like, >> >> >> developer needs to build 204 No Content response by hand, because >> >> >> default version works wrong. >> >> >> >> >> >> On Fri, Aug 22, 2014 at 4:32 PM, Nikolay Markov >> >> >> <nmar...@mirantis.com> >> >> >> wrote: >> >> >> > I created a little comparison table on major issues: >> >> >> > >> >> >> > >> >> >> > >> >> >> > https://docs.google.com/a/mirantis.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing >> >> >> > , feel free to comment. >> >> >> > >> >> >> > >> >> >> > On Thu, Aug 21, 2014 at 5:02 PM, Nikolay Markov >> >> >> > <nmar...@mirantis.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> Yes, but it took almost a week for me to rewrite current API to >> >> >> >> it, >> >> >> >> and >> >> >> >> there are still a lot of gaps even then tests are mostly passed. >> >> >> >> >> >> >> >> For example, URL "/api/clusters/1/network_configuration/" works >> >> >> >> properly, >> >> >> >> but also the same handler (by Pecan design) should work with URL >> >> >> >> "/api/clusters/network_configuration/", and of course it fails >> >> >> >> with >> >> >> >> HTTP >> >> >> >> 500, because cluster_id is not passed (it is a required >> >> >> >> argument). I >> >> >> >> know >> >> >> >> it's simple to add another check for that, but I don't know why >> >> >> >> Pecan >> >> >> >> even >> >> >> >> allow cases like this and has no correct built-in routing >> >> >> >> mechanism. >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Aug 21, 2014 at 2:23 PM, Mike Scherbakov >> >> >> >> <mscherba...@mirantis.com> wrote: >> >> >> >>> >> >> >> >>> Also, is it your POC using Pecan? >> >> >> >>> https://review.openstack.org/#/c/99069/ >> >> >> >>> >> >> >> >>> >> >> >> >>> On Thu, Aug 21, 2014 at 9:55 AM, Mike Scherbakov >> >> >> >>> <mscherba...@mirantis.com> wrote: >> >> >> >>>> >> >> >> >>>> Nick, >> >> >> >>>> if you've got a time for it - I would love to see more formal >> >> >> >>>> approach >> >> >> >>>> to the analysis. We know our requirements for Fuel already (we >> >> >> >>>> do, >> >> >> >>>> right?)), >> >> >> >>>> so I believe we could have a comparison table, with features we >> >> >> >>>> need >> >> >> >>>> in rows >> >> >> >>>> and frameworks in columns. >> >> >> >>>> You mentioned some of the features already, such as PATCH, >> >> >> >>>> application/json type without monkey-patching, etc. >> >> >> >>>> >> >> >> >>>> If we follow this way and collaboratively feel up such a table, >> >> >> >>>> there >> >> >> >>>> will be no question what to take when it comes to finally >> >> >> >>>> choose >> >> >> >>>> framework >> >> >> >>>> and start development. >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> On Thu, Aug 21, 2014 at 1:42 AM, Tomasz Napierala >> >> >> >>>> <tnapier...@mirantis.com> wrote: >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> On 20 Aug 2014, at 18:14, Nikolay Markov >> >> >> >>>>> <nmar...@mirantis.com> >> >> >> >>>>> wrote: >> >> >> >>>>> >> >> >> >>>>> > Lukasz, >> >> >> >>>>> > >> >> >> >>>>> > I did try this configuration and it was hell. I shared my >> >> >> >>>>> > experience >> >> >> >>>>> > in previous letters in this thread. Please don't hesitate to >> >> >> >>>>> > share >> >> >> >>>>> > your >> >> >> >>>>> > experience If you have some other thoughts. >> >> >> >>>>> > >> >> >> >>>>> > The thing is, we won't really have much time after 5.1 and >> >> >> >>>>> > before >> >> >> >>>>> > 6.0, so all big-size decisions should be done as early as >> >> >> >>>>> > possible. >> >> >> >>>>> >> >> >> >>>>> I agree that it might be too late after release. So maybe we >> >> >> >>>>> should >> >> >> >>>>> wait until after HCF - most people will have some spare time >> >> >> >>>>> to >> >> >> >>>>> do >> >> >> >>>>> research >> >> >> >>>>> / familiarize themselves with various frameworks. What do you >> >> >> >>>>> think >> >> >> >>>>> about >> >> >> >>>>> it? >> >> >> >>>>> >> >> >> >>>>> Regards, >> >> >> >>>>> -- >> >> >> >>>>> Tomasz Napierala >> >> >> >>>>> Sr. OpenStack Engineer >> >> >> >>>>> tnapier...@mirantis.com >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> -- >> >> >> >>>>> Mailing list: https://launchpad.net/~fuel-dev >> >> >> >>>>> Post to : fuel-dev@lists.launchpad.net >> >> >> >>>>> Unsubscribe : https://launchpad.net/~fuel-dev >> >> >> >>>>> More help : https://help.launchpad.net/ListHelp >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> -- >> >> >> >>>> Mike Scherbakov >> >> >> >>>> #mihgen >> >> >> >>>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> -- >> >> >> >>> Mike Scherbakov >> >> >> >>> #mihgen >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> >> >> Nick Markov >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Best regards, >> >> >> > Nick Markov >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Best regards, >> >> >> Nick Markov >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Mike Scherbakov >> >> > #mihgen >> >> > >> >> > >> >> > -- >> >> > Mailing list: https://launchpad.net/~fuel-dev >> >> > Post to : fuel-dev@lists.launchpad.net >> >> > Unsubscribe : https://launchpad.net/~fuel-dev >> >> > More help : https://help.launchpad.net/ListHelp >> >> > >> >> >> >> -- >> >> Mailing list: https://launchpad.net/~fuel-dev >> >> Post to : fuel-dev@lists.launchpad.net >> >> Unsubscribe : https://launchpad.net/~fuel-dev >> >> More help : https://help.launchpad.net/ListHelp >> > >> > >> >> -- >> Mailing list: https://launchpad.net/~fuel-dev >> Post to : fuel-dev@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~fuel-dev >> More help : https://help.launchpad.net/ListHelp > > > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : fuel-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > -- Best regards, Nick Markov -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp