Re: [openstack-dev] How-to and best practices for developing new OpenStack service
Thanks for the links, cookiecutter template is useful for obtaining initial project structure. Short tutorial for developers not familiar with OpenStack infrastructure still would be useful. My task is to help Python developers that haven't worked with OpenStack before start an OpenStack service development in the shortest possible period. If none will come up, I'll be thinking about writing one :) On Wed, May 7, 2014 at 4:08 PM, Ruslan Kamaldinov rkamaldi...@mirantis.comwrote: Hi Ruslan! I can recommend two resources: 1. cookiecutter [1] - template for a new OpenStack project 2. http://ci.openstack.org/stackforge.html - this page helps to setup a project in OpenStack infrastructure, including code-review, Jenkins automation, etc. [1] http://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/README.rst Regards, Ruslan On Wed, May 7, 2014 at 4:08 PM, Ruslan Kiianchuk ruslan.kiianc...@gmail.com wrote: Hello, community. There are numerous open projects evolving that are designed to work with OpenStack and follow OpenStack development principles (technologies stack, architecture, etc.). There are even more efforts within many companies working with cloud technologies. However it is hard to quick-start with all the practices developed at OpenStack community and start developing an OpenStack service the right way. So are there any resources, tutorials, guides on how to start an OpenStack service from scratch? Something that would describe correct usage of Oslo project, common architecture and give recommendations for developers. Thank you. -- Sincerely, Ruslan Kiianchuk. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely, Ruslan Kiianchuk. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] How-to and best practices for developing new OpenStack service
Hello, community. There are numerous open projects evolving that are designed to work with OpenStack and follow OpenStack development principles (technologies stack, architecture, etc.). There are even more efforts within many companies working with cloud technologies. However it is hard to quick-start with all the practices developed at OpenStack community and start developing an OpenStack service the right way. So are there any resources, tutorials, guides on how to start an OpenStack service from scratch? Something that would describe correct usage of Oslo project, common architecture and give recommendations for developers. Thank you. -- Sincerely, Ruslan Kiianchuk. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Split of the openstack-dev list (summary so far)
Definitely +1 for splitting -- it becomes overwhelmed. We'll soon need regexps just to handle the incoming emails :) Having separate mailing lists would make it easier to stay focused and concentrate on needed projects. On Fri, Nov 15, 2013 at 12:18 PM, Flavio Percoco fla...@redhat.com wrote: On 15/11/13 11:06 +0100, Thierry Carrez wrote: Wow, lots of different opinions! let's try to summarize: Arguments in favor of splitting openstack-dev / stackforge-dev * People can easily filter out all non-openstack discussions * Traffic would drop by about 25% * Removes confusion as to which projects are actually in openstack Again, +1 for splitting! Arguments in favor of keeping it the same * Provides a cross-pollination forum where external projects can learn This can still happen. People can still subscribe to both lists and reply / create threads as long as they belong to that list. This 'split' is more an 'organization' of emails than an actuall 'split' because it's not intended to split the community but to ease the interaction among it. Cheers, FF * More chaos creates more innovation Personally I was fine with having everyone in the same burgeoning city (to quote the lyrical Clint) until we recently crossed the bar of making that city painful for a lot of people. Especially the people who work on serving the needs of all OpenStack projects (think release management, doc, QA, infra) and who have to pay some level of attention to every thread. Yes, those people can filter out all stackforge discussions into a separate folder: identify all the corresponding prefixes and setting filters for them (and praying that they would all just use the right suffixes). But rather than forcing everyone to go through that setup, why not set up a list and make it more convenient for everyone to apply different (or similar !) reading rules to the two different groups. Because they ARE two different groups. One is OpenStack and must get the extra attention of all the people working on horizontal functions (that is what incubation is about, carefully controlling access to extra common resources). The other is not yet OpenStack, free-for-all. The latter group clearly benefits from being on the same list: they get extra attention from all those smart OpenStack people, and their marketing can benefit from the very blurry line between openstack and not-yet-openstack we maintain on the list. In summary, I certainly see the benefits of a single list for stackforge developers (and why people working on a limited number of vertical projects don't really mind either way...). But I fear that we maintain those benefits at the expense of the sanity of the horizontal programs in openstack, and therefore lower the quality of OpenStack as a result. PS: I don't think we can reach consensus on that one -- we might need to push it to the TC to make a final call. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely, Ruslan Kiianchuk. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Remove vim modelines?
If someone takes effort to learn Vim to the point when he/she develops code in it, they most definitely have their preferred settings already, why overwrite them? If those settings conflict with the style guide -- it has been said, pep8 and hacking check will notify. I always thought that leaving some hints to text editor by adding specific content to file content is just a dirty hack -- files should not be editor agnostic, the editor should be smart enough to figure everything out by himself. And yeah, also a happy Vim user for 4 years. Replacing the long paragraph with a short response: +1, remove them :) On Fri, Oct 25, 2013 at 4:45 PM, Vishvananda Ishaya vishvana...@gmail.comwrote: Interesting Background Information: Why do we have modelines? Termie put them in all the files of the first version of nova Why did he put in modelines instead of configuring his editor? Termie does a lot of python coding and he prefers a tabstop of 2 on all his personal projects[1] I really don't see much value outside of people who prefer other tabstops +1 to remove them Vish [1] https://github.com/termie/git-bzr-ng/blob/master/git-bzr On Oct 24, 2013, at 5:38 AM, Joe Gordon joe.gord...@gmail.com wrote: Since the beginning of OpenStack we have had vim modelines all over the codebase, but after seeing this patch https://review.opeenstack.org/#/c/50891/https://review.openstack.org/#/c/50891/I took a further look into vim modelines and think we should remove them. Before going any further, I should point out these lines don't bother me too much but I figured if we could get consensus, then we could shrink our codebase by a little bit. Sidenote: This discussion is being moved to the mailing list because it 'would be better to have a mailing list thread about this rather than bits and pieces of discussion in gerrit' as this change requires multiple patches. https://review.openstack.org/#/c/51295/. Why remove them? * Modelines aren't supported by default in debian or ubuntu due to security reasons: https://wiki.python.org/moin/Vim * Having modelines for vim means if someone wants we should support modelines for emacs ( http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables) etc. as well. And having a bunch of headers for different editors in each file seems like extra overhead. * There are other ways of making sure tabstop is set correctly for python files, see https://wiki.python.org/moin/Vim. I am a vIm user myself and have never used modelines. * We have vim modelines in only 828 out of 1213 python files in nova (68%), so if anyone is using modelines today, then it only works 68% of the time in nova * Why have the same config 828 times for one repo alone? This violates the DRY principle (Don't Repeat Yourself). Related Patches: https://review.openstack.org/#/c/51295/ https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:noboilerplate,n,z best, Joe ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely, Ruslan Kiianchuk. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
