New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New lite-server implementation #407
Conversation
902ab13
to
d40069c
Compare
|
Shouldn't we rather remove lite sever completely? |
|
I always found the lite-server to be incredibly helpful for server-side plugin development. If it isn't being used any more then I'd wonder what is being used instead. |
|
@rcritten AFAIK most of us develop plugins locally, then build RPMs which we sync to a VM, install IPA server and use ipa-run-tests to test the new plugin. I personally used lite-server only once or twice when I started out with my contribution. We had some discussion earlier in which we concluded that lite-server is not used anymore and should be removed (this is probably what @pvoborni is referring to). If you can provide compelling arguments against this decision then we can reconsider. |
|
Right, and IMHO that development process is inefficient and prone to error. Rather than copying bits around and doing full installs over and over you can run the server in-tree and have vastly improved debugging available. Certainly a "final" test of a full server install loop is necessary but for initial development and testing the lite-server is far easier and efficient. At one time the tests were also run almost exclusively in-tree (which was faster at the time). |
|
When I was still developing server-side then I used lsyncd to rsync files from my local laptop working git repo to their location on vm in a lab. So the process for me was just:
Lite sever covers only API changes. Solution above covered also installs and updates (to some extend). So it was much more usable because API changes is only a small part of FreeIPA development. For Web UI, there is older /install/ui/util/sync.sh which does similar thing. Build system refactoring enabled to use This covers all use cases. So it might be better to talk if we should rather promote this method with e.g. containerized IPA instance. I.e. Before we ACK or NACK this PR. I'd rather have a conversation, what is the issue and what is the right solution. How we can make the whole process better. And then update http://www.freeipa.org/page/Contribute/Code which is rather obsolete and doesn't describe any method. |
|
I put some effort into the dev server because I find it very useful during development. The werkzeug WSGI adds some useful features, e.g. auto-reloader and through-the-web debugger (soon). I can maintain a copy of the dev server for me personally but I'd rather have a copy in the source tree. It doesn't have to be |
|
Maybe the lite-server approach is great and other people would appreciate that. I shouldn't be the one to judge it. What about demonstrating it to the rest of the team and showing the value? |
afca7ec
to
9bce64a
Compare
9bce64a
to
88f8c15
Compare
|
PR #314 has landed. I have rebased the branch and made the lite-server even more convenient to use. You can now run it with With the help of the lite-server, I found issue pyldap/pyldap#84 within ten seconds. Now with WSGI profiler! |
The new development server depends on werkzeug instead of paste. The werkzeug WSGI server comes with some additional features, most noticeable multi-processing server. The IPA framework is not compatible with threaded servers. Werkzeug can serve static files easily and has a fast auto-reloader. The new lite-server implementation depends on PR 314 (privilege separation). For Python 3 support, it additionally depends on PR 393. Signed-off-by: Christian Heimes <cheimes@redhat.com>
88f8c15
to
468c3e8
Compare
|
Example of a single request profile with new lite-server: |
|
Fixed upstream |
The new development server depends on werkzeug instead of paste. The
werkzeug WSGI server comes with some additional features, most
noticeable multi-processing server. The IPA framework is not compatible
with threaded servers. Werkzeug can serve static files easily and has a
fast auto-reloader.
The new lite-server implementation depends on PR #314 (privilege
separation). For Python 3 support, it additionally depends on PR #393.
Signed-off-by: Christian Heimes cheimes@redhat.com