Re: [openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate
On 07/05/15 19:19 -0500, Dolph Mathews wrote: We didn't pick Falcon because Kurt was Marconi's PTL and Falcon's maintainer. The main reason it was picked was related to performance first[0] and time (We didn't/don't have enough resources to even think of porting the API) and at this point, I believe it's not even going to be considered anymore in the short future. I'm just going to pipe up and say that's a terribly shallow reason for choosing a web framework, and I think it's silly and embarrassing that there's not a stronger community preference for more mature frameworks. I take that as a sign that most of our developer community is coming from non-Python backgrounds, which is fine, but this whole conversation has always felt like a plague of Not-Invented-Here, which baffles me. Not sure how to parse your email but, FWIW, the community did what was necessary to promote Pecan and the team decided to stick with Falcon. I don't believe performance and good fit for your use-case are shallow reasons to pick a framework. Most of the projects are using Pecan and it works very well for them and I believe, as I mentioned in my previous email, it's the framework projects should default to. Flavio There were lots of discussions around this, there were POCs and team work. I think it's fair to say that the team didn't blindly *ignored* what was recommended as the community framework but it picked what worked best for the service. [0] https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation pecan is a wsgi framework written by Dreamhost that eventually moved itself into stackforge to better enable collaboration with our community after we settled on it as the API for things moving forward. Since the decision that new REST apis should be written in Pecan, the following projects have adopted it: openstack: barbican ceilometer designate gnocchi ironic ironic-python-agent kite magnum storyboard tuskar stackforge: anchor blazar cerberus cloudkitty cue fuel-ostf fuel-provision graffiti libra magnetodb monasca-api mistral octavia poppy radar refstack solum storyboard surveil terracotta On the other hand, the following use falcon: stachtach-quincy zaqar To me this is a strong indicator that pecan will see more eyes and possibly be more open to improvement to meet the general need. +1 That means that for all of the moaning and complaining, there is essentially one thing that uses it - the project that was started by the person who wrote it and has since quit. I'm sure it's not perfect - but the code is in stackforge - I'm sure we can improve it if there is something missing. OTOH - if we're going to go back down this road, I'd think it would be more useful to maybe look at flask or something else that has a large following in the python community at large to try to reduce the amount of special we are. +1 Please, lets not go back down this road, not yet at least. :) But honestly - I think it matters almost not at all, which is why I keep telling people to just use pecan ... basically, the argument is not worth it. +1, go with Pecan if your requirements are not like Zaqar's. Contribute to Pecan and make it better. Flavio -- @flaper87 Flavio Percoco -- @flaper87 Flavio Percoco pgpk4hx7XYxDc.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate
On Monday, May 4, 2015, Flavio Percoco fla...@redhat.com wrote: On 02/05/15 12:02 -0700, Morgan Fainberg wrote: On May 2, 2015, at 10:28, Monty Taylor mord...@inaugust.com wrote: On 05/01/2015 09:16 PM, Jamie Lennox wrote: Hi all, At around the time Barbican was applying for incubation there was a discussion about supported WSGI frameworks. From memory the decision at the time was that Pecan was to be the only supported framework and that for incubation Barbican had to convert to Pecan (from Falcon). Keystone is looking to ditch our crusty old, home-grown wsgi layer for an external framework and both Pecan and Falcon are in global requirements. In the experimenting I've done Pecan provides a lot of stuff we don't need and some that just gets in the way. To call out a few: * the rendering engine really doesn't make sense for us, for APIs, and where we are often returning different data (not just different views or data) based on Content-Type. * The security enforcement within Pecan does not really mesh with how we enforce policy, nor does the way we build controller objects per resource. It seems we will have to build this for ourselves on top of pecan and there are just various other niggles. THIS IS NOT SUPPOSED TO START A DEBATE ON THE VIRTUES OF EACH FRAMEWORK. Everything I've found can be dealt with and pecan will be a vast improvement over what we use now. I have also not written a POC with Falcon to know that it will suit any better. My question is: Does the ruling that Pecan is the only WSGI framework for OpenStack stand? I don't want to have 100s of frameworks in the global requirements, but given falcon is already there iff a POC determines that Falcon is a better fit for keystone can we use it? a) Just to be clear - I don't actually care Just to be super clear, I don't care either. :) That said: falcon is a wsgi framework written by kgriffs who was PTL of marconi who has since being involved with OpenStack. My main perception of it has always been as a set of people annoyed by openstack doing their own thing. That's fine - but I don't have much of a use for that myself. ok, I'll bite. We didn't pick Falcon because Kurt was Marconi's PTL and Falcon's maintainer. The main reason it was picked was related to performance first[0] and time (We didn't/don't have enough resources to even think of porting the API) and at this point, I believe it's not even going to be considered anymore in the short future. I'm just going to pipe up and say that's a terribly shallow reason for choosing a web framework, and I think it's silly and embarrassing that there's not a stronger community preference for more mature frameworks. I take that as a sign that most of our developer community is coming from non-Python backgrounds, which is fine, but this whole conversation has always felt like a plague of Not-Invented-Here, which baffles me. There were lots of discussions around this, there were POCs and team work. I think it's fair to say that the team didn't blindly *ignored* what was recommended as the community framework but it picked what worked best for the service. [0] https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation pecan is a wsgi framework written by Dreamhost that eventually moved itself into stackforge to better enable collaboration with our community after we settled on it as the API for things moving forward. Since the decision that new REST apis should be written in Pecan, the following projects have adopted it: openstack: barbican ceilometer designate gnocchi ironic ironic-python-agent kite magnum storyboard tuskar stackforge: anchor blazar cerberus cloudkitty cue fuel-ostf fuel-provision graffiti libra magnetodb monasca-api mistral octavia poppy radar refstack solum storyboard surveil terracotta On the other hand, the following use falcon: stachtach-quincy zaqar To me this is a strong indicator that pecan will see more eyes and possibly be more open to improvement to meet the general need. +1 That means that for all of the moaning and complaining, there is essentially one thing that uses it - the project that was started by the person who wrote it and has since quit. I'm sure it's not perfect - but the code is in stackforge - I'm sure we can improve it if there is something missing. OTOH - if we're going to go back down this road, I'd think it would be more useful to maybe look at flask or something else that has a large following in the python community at large to try to reduce the amount of special we are. +1 Please, lets not go back down this road, not yet at least. :) But honestly - I think it matters almost not at all, which is why I keep telling people to just use pecan ... basically, the argument is not worth it. +1, go with Pecan if your requirements are not like Zaqar's. Contribute to Pecan and make it better. Flavio --
Re: [openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate
On 02/05/15 12:02 -0700, Morgan Fainberg wrote: On May 2, 2015, at 10:28, Monty Taylor mord...@inaugust.com wrote: On 05/01/2015 09:16 PM, Jamie Lennox wrote: Hi all, At around the time Barbican was applying for incubation there was a discussion about supported WSGI frameworks. From memory the decision at the time was that Pecan was to be the only supported framework and that for incubation Barbican had to convert to Pecan (from Falcon). Keystone is looking to ditch our crusty old, home-grown wsgi layer for an external framework and both Pecan and Falcon are in global requirements. In the experimenting I've done Pecan provides a lot of stuff we don't need and some that just gets in the way. To call out a few: * the rendering engine really doesn't make sense for us, for APIs, and where we are often returning different data (not just different views or data) based on Content-Type. * The security enforcement within Pecan does not really mesh with how we enforce policy, nor does the way we build controller objects per resource. It seems we will have to build this for ourselves on top of pecan and there are just various other niggles. THIS IS NOT SUPPOSED TO START A DEBATE ON THE VIRTUES OF EACH FRAMEWORK. Everything I've found can be dealt with and pecan will be a vast improvement over what we use now. I have also not written a POC with Falcon to know that it will suit any better. My question is: Does the ruling that Pecan is the only WSGI framework for OpenStack stand? I don't want to have 100s of frameworks in the global requirements, but given falcon is already there iff a POC determines that Falcon is a better fit for keystone can we use it? a) Just to be clear - I don't actually care Just to be super clear, I don't care either. :) That said: falcon is a wsgi framework written by kgriffs who was PTL of marconi who has since being involved with OpenStack. My main perception of it has always been as a set of people annoyed by openstack doing their own thing. That's fine - but I don't have much of a use for that myself. ok, I'll bite. We didn't pick Falcon because Kurt was Marconi's PTL and Falcon's maintainer. The main reason it was picked was related to performance first[0] and time (We didn't/don't have enough resources to even think of porting the API) and at this point, I believe it's not even going to be considered anymore in the short future. There were lots of discussions around this, there were POCs and team work. I think it's fair to say that the team didn't blindly *ignored* what was recommended as the community framework but it picked what worked best for the service. [0] https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation pecan is a wsgi framework written by Dreamhost that eventually moved itself into stackforge to better enable collaboration with our community after we settled on it as the API for things moving forward. Since the decision that new REST apis should be written in Pecan, the following projects have adopted it: openstack: barbican ceilometer designate gnocchi ironic ironic-python-agent kite magnum storyboard tuskar stackforge: anchor blazar cerberus cloudkitty cue fuel-ostf fuel-provision graffiti libra magnetodb monasca-api mistral octavia poppy radar refstack solum storyboard surveil terracotta On the other hand, the following use falcon: stachtach-quincy zaqar To me this is a strong indicator that pecan will see more eyes and possibly be more open to improvement to meet the general need. +1 That means that for all of the moaning and complaining, there is essentially one thing that uses it - the project that was started by the person who wrote it and has since quit. I'm sure it's not perfect - but the code is in stackforge - I'm sure we can improve it if there is something missing. OTOH - if we're going to go back down this road, I'd think it would be more useful to maybe look at flask or something else that has a large following in the python community at large to try to reduce the amount of special we are. +1 Please, lets not go back down this road, not yet at least. :) But honestly - I think it matters almost not at all, which is why I keep telling people to just use pecan ... basically, the argument is not worth it. +1, go with Pecan if your requirements are not like Zaqar's. Contribute to Pecan and make it better. Flavio -- @flaper87 Flavio Percoco pgp7Mf9zCWPWn.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate
Hi all, To be clear, both Pecan and Falcon are actively maintained and have healthy communities. In any case, I tend to point OpenStack projects toward Pecan as the default choice, since that lets you take advantage of all the benefits standardization has to offer. Of course, you need to quantify and balance those benefits against Keystone’s specific requirements, but Pecan should be able to do what you need. -Kurt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate
On 05/01/2015 09:16 PM, Jamie Lennox wrote: Hi all, At around the time Barbican was applying for incubation there was a discussion about supported WSGI frameworks. From memory the decision at the time was that Pecan was to be the only supported framework and that for incubation Barbican had to convert to Pecan (from Falcon). Keystone is looking to ditch our crusty old, home-grown wsgi layer for an external framework and both Pecan and Falcon are in global requirements. In the experimenting I've done Pecan provides a lot of stuff we don't need and some that just gets in the way. To call out a few: * the rendering engine really doesn't make sense for us, for APIs, and where we are often returning different data (not just different views or data) based on Content-Type. * The security enforcement within Pecan does not really mesh with how we enforce policy, nor does the way we build controller objects per resource. It seems we will have to build this for ourselves on top of pecan and there are just various other niggles. THIS IS NOT SUPPOSED TO START A DEBATE ON THE VIRTUES OF EACH FRAMEWORK. Everything I've found can be dealt with and pecan will be a vast improvement over what we use now. I have also not written a POC with Falcon to know that it will suit any better. My question is: Does the ruling that Pecan is the only WSGI framework for OpenStack stand? I don't want to have 100s of frameworks in the global requirements, but given falcon is already there iff a POC determines that Falcon is a better fit for keystone can we use it? a) Just to be clear - I don't actually care That said: falcon is a wsgi framework written by kgriffs who was PTL of marconi who has since being involved with OpenStack. My main perception of it has always been as a set of people annoyed by openstack doing their own thing. That's fine - but I don't have much of a use for that myself. pecan is a wsgi framework written by Dreamhost that eventually moved itself into stackforge to better enable collaboration with our community after we settled on it as the API for things moving forward. Since the decision that new REST apis should be written in Pecan, the following projects have adopted it: openstack: barbican ceilometer designate gnocchi ironic ironic-python-agent kite magnum storyboard tuskar stackforge: anchor blazar cerberus cloudkitty cue fuel-ostf fuel-provision graffiti libra magnetodb monasca-api mistral octavia poppy radar refstack solum storyboard surveil terracotta On the other hand, the following use falcon: stachtach-quincy zaqar That means that for all of the moaning and complaining, there is essentially one thing that uses it - the project that was started by the person who wrote it and has since quit. I'm sure it's not perfect - but the code is in stackforge - I'm sure we can improve it if there is something missing. OTOH - if we're going to go back down this road, I'd think it would be more useful to maybe look at flask or something else that has a large following in the python community at large to try to reduce the amount of special we are. But honestly - I think it matters almost not at all, which is why I keep telling people to just use pecan ... basically, the argument is not worth it. Monty __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate
On May 2, 2015, at 10:28, Monty Taylor mord...@inaugust.com wrote: On 05/01/2015 09:16 PM, Jamie Lennox wrote: Hi all, At around the time Barbican was applying for incubation there was a discussion about supported WSGI frameworks. From memory the decision at the time was that Pecan was to be the only supported framework and that for incubation Barbican had to convert to Pecan (from Falcon). Keystone is looking to ditch our crusty old, home-grown wsgi layer for an external framework and both Pecan and Falcon are in global requirements. In the experimenting I've done Pecan provides a lot of stuff we don't need and some that just gets in the way. To call out a few: * the rendering engine really doesn't make sense for us, for APIs, and where we are often returning different data (not just different views or data) based on Content-Type. * The security enforcement within Pecan does not really mesh with how we enforce policy, nor does the way we build controller objects per resource. It seems we will have to build this for ourselves on top of pecan and there are just various other niggles. THIS IS NOT SUPPOSED TO START A DEBATE ON THE VIRTUES OF EACH FRAMEWORK. Everything I've found can be dealt with and pecan will be a vast improvement over what we use now. I have also not written a POC with Falcon to know that it will suit any better. My question is: Does the ruling that Pecan is the only WSGI framework for OpenStack stand? I don't want to have 100s of frameworks in the global requirements, but given falcon is already there iff a POC determines that Falcon is a better fit for keystone can we use it? a) Just to be clear - I don't actually care That said: falcon is a wsgi framework written by kgriffs who was PTL of marconi who has since being involved with OpenStack. My main perception of it has always been as a set of people annoyed by openstack doing their own thing. That's fine - but I don't have much of a use for that myself. pecan is a wsgi framework written by Dreamhost that eventually moved itself into stackforge to better enable collaboration with our community after we settled on it as the API for things moving forward. Since the decision that new REST apis should be written in Pecan, the following projects have adopted it: openstack: barbican ceilometer designate gnocchi ironic ironic-python-agent kite magnum storyboard tuskar stackforge: anchor blazar cerberus cloudkitty cue fuel-ostf fuel-provision graffiti libra magnetodb monasca-api mistral octavia poppy radar refstack solum storyboard surveil terracotta On the other hand, the following use falcon: stachtach-quincy zaqar To me this is a strong indicator that pecan will see more eyes and possibly be more open to improvement to meet the general need. That means that for all of the moaning and complaining, there is essentially one thing that uses it - the project that was started by the person who wrote it and has since quit. I'm sure it's not perfect - but the code is in stackforge - I'm sure we can improve it if there is something missing. OTOH - if we're going to go back down this road, I'd think it would be more useful to maybe look at flask or something else that has a large following in the python community at large to try to reduce the amount of special we are. +1 But honestly - I think it matters almost not at all, which is why I keep telling people to just use pecan ... basically, the argument is not worth it. Monty __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
