fuel-dev team mailing list archive

[Igor Kalnitsky <ikalnitsky@xxxxxxxxxxxx>]

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
<akislitsky@xxxxxxxxxxxx> 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 <ikalnitsky@xxxxxxxxxxxx>
> 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
>> <mscherbakov@xxxxxxxxxxxx> 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 <nmarkov@xxxxxxxxxxxx>
>> > 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 <nmarkov@xxxxxxxxxxxx>
>> >> 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
>> >> > <nmarkov@xxxxxxxxxxxx>
>> >> > 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
>> >> >> <mscherbakov@xxxxxxxxxxxx> 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
>> >> >>> <mscherbakov@xxxxxxxxxxxx> 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
>> >> >>>> <tnapierala@xxxxxxxxxxxx> wrote:
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On 20 Aug 2014, at 18:14, Nikolay Markov <nmarkov@xxxxxxxxxxxx>
>> >> >>>>> 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
>> >> >>>>> tnapierala@xxxxxxxxxxxx
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> Mailing list: https://launchpad.net/~fuel-dev
>> >> >>>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> >> >>>>> 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@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~fuel-dev
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>
>