fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

last time it took 3 weeks to reimplement using Flask, code had 3k lines of
changes, and we never ended up merging it due to FF.
Then it was forgotten.

On Thu, Sep 11, 2014 at 4:20 PM, Nikolay Markov <nmarkov@xxxxxxxxxxxx>
wrote:

> 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
>
> --
> 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