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