fuel-dev team mailing list archive

[Igor Kalnitsky <ikalnitsky@xxxxxxxxxxxx>]

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
>