fuel-dev team mailing list archive

[Nikolay Markov <nmarkov@xxxxxxxxxxxx>]

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