Open Stack

On Sep 10, 2012, at 8:49 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> Hey,
> 
> On Mon, 2012-09-10 at 21:58 +1000, Angus Salkeld wrote:
>> On 10/09/12 07:23 -0400, Doug Hellmann wrote:
>>> 
>>> 
>>> On Sep 10, 2012, at 5:23 AM, Julien Danjou <julien at danjou.info> wrote:
>>> 
>>>> On Mon, Sep 10 2012, Angus Salkeld wrote:
>>>> 
>>>>> How do you guys feel about me changing flask to a more openstack style
>>>>> wsgi implementation? So the suggestion is not flask sucks, but it is not
>>>>> used anywhere else. We should really use it everywhere or nowhere. I think
>>>>> the consistency across the openstack projects is really nice for people
>>>>> that work across projects.
>>>> 
>>>> Sure, one of our principles is to blend with others OS projects, so
>>>> obviously Flask choice can seem weird.
>>>> 
>>>> But actually, IIRC, I've discussed this with Doug, and we decided to go
>>>> with Flask because it seemed that WSGI was a dead-end, and that other
>>>> projects would be moving away from it. So what's the roadmap for other
>>>> projects about this?
>>> 
>>> Not WSGI, paste.deploy. At the last summit we discussed dropping paste because it does not have python 3 support. No timetable was set.
>>> 
>>> I pushed the use of flask in ceilometer because when I looked at the WSGI libraries in nova they were not available in common and I didn't feel I had time to figure out which bits needed to be extracted to copy them into our project. I also found them to be more complex than I wanted to deal with, since I didn't find any tutorials for using them.
>> 
>> Yea, I was going to start on this blueprint soon:
>> https://blueprints.launchpad.net/openstack-common/+spec/wsgi-common
>> but if this is the case (moving away from wsgi.py) then this probably needs to be
>> scrapped.
>> 
>> Is there a wiki page/blueprint somewhere that explains this decision?
> 
> Summary of ceilometer's decision to use Flask seems to be:
> 
>  - some people are advocating for dropping paste.deploy
> 
>  - the WSGI code in Nova is complex and not in openstack-common
> 
>  - let's use Flask instead

Those statements are true, but a bit of an over-simplification of what happened.

When it came time to start the api for ceilometer, I spent an afternoon reading the nova API implementation. At some point during that process I decided that the complexity of the exiting framework didn't seem to come with any specific benefit (at least none I perceived to be relevant to ceilometer). I knew of a couple of other tools for building WSGI apps and chose flask because it was well documented, fairly simple, and had the features I expected to need. 

I have no reason to suggest using flask to rewrite any existing API services, but would like to have it considered for new applications. Previous experience had shown me that suggestions to adopt new tools are, rightfully, met with some form of "build something and let's see how it works." So, I thought version 1 of the ceilometer API could work as an example app for that purpose, as well as for figuring out how paste.deploy could be replaced (since we are not using it, but still will need to solve deploy issues). 

> 
> I haven't noticed anyone actually making progress towards dropping
> paste.deploy beyond this:
> 
>  https://github.com/termie/shred/blob/master/paste/deploy.py

I expect more effort will be applied to that when/if we agree to start moving to python 3, since lack of python 3 support was a key motivation for thinking about getting rid of paste (in addition to the packaging issues it raisesm IIRC). 

> 
> As for WSGI support in openstack-common, I basically considered the
> current code in openstack-common to be dead since no other projects use
> it even though most projects have very similar code. Angus has done some
> work bring it back to life, so hopefully we'll see a project or two
> switched over to using it soon.
> 
> I don't have any strong opinion on this approach vs Flask except that
> the wsgi-common approach looks more like something which we can have
> most projects adopt sooner.

That makes more sense for existing projects, yes. 

Doug

> 
> Cheers,
> Mark.
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev