fuel-dev team mailing list archive

[Nikolay Markov <nmarkov@xxxxxxxxxxxx>]

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 <eli@xxxxxxxxxxxx> 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 <ikalnitsky@xxxxxxxxxxxx>
> 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
>> <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
>> >
>> >
>>
>> --
>> 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
>



-- 
Best regards,
Nick Markov